在机器学习社区，越来越多的人开始讨论研究的可复现性，但这些讨论大多局限于学术界。如何保证ML在生产环境中的可复现性？近日，机器学习开发服务商maiot.io的CTOBenediktKoller发表了一篇博文，根据自己的经验介绍了开发可复现的生产级机器学习应该注意的12个要素。在过去的二十年里，我们对软件开发的理解有了显着的提高。这在很大程度上要归功于DevOps概念的出现及其在软件开发行业的广泛应用。领先的软件公司都遵循相同的模式：首先在软件开发过程中快速迭代，然后持续集成、持续交付、持续部署。每个功能都经过测试，以确定其提供价值的能力，软件始终处于就绪状态，并通过自动化方法进行部署。虽然机器学习领域不同于传统的软件开发，但我们也可以从软件开发行业中吸取很多实践经验。在过去的几年里，我们一直在开发生产机器学习项目。我们的目标不仅仅是概念验证，而是与软件开发相同的可重现性。因此，我们构建了一个流程编排器、强大的自动化功能和一个工作流来做到这一点。为什么不直接使用JupyterNotebook？从头开始构建包含所有处理步骤的笔记集需要多长时间？向团队添加新成员有多容易？你现在能重现两个月前的结果吗？它的复制速度有多快？你能将今天的结果与历史结果进行比较吗？训练过程中能不能注意数据的出处？如果您的模型已过时会怎样？我们遇到过所有这些问题。我们现在将这些课程归纳为成功构建生产机器学习的12个要素（类似于软件开发中的12要素应用程序）。1.版本控制对于软件工程师来说，版本控制基本上是理所当然的事情，但是这种方法论还没有被数据科学家广泛接受。让我引用Gitlab的一些人所说的话：版本控制促进了软件开发团队之间的协调、共享和协作。版本控制软件允许团队在分布式和异步环境中工作，管理代码和文件的修订和版本，并解决合并冲突和相关异常。简而言之，版本控制允许您安全地管理软件开发中不断变化的部分。机器学习实际上是一种特殊的软件开发，有其特定的要求。首先，机器学习中的变化部分不是一种，而是两种：代码和数据。其次，模型的训练方式是（快速）迭代，代码中的差异可能很大（如拆分、预处理、模型）。每当数据发生变化时，都需要保存一个版本，以确保可以重现结果并重复实验和训练模型。原始版本控制（硬拷贝）有很大的改进空间，但尤其是在团队共享的情况下，能够保持恒定的版本控制至关重要。代码版本控制更为重要。除了上面引用的内容之外，预处理代码不仅在训练阶段很重要，在服务阶段也很重要，需要对模型有持续的依赖性。要在数据科学家的工作流程和投入生产的要求之间创建一个中间地带，一种方便的方法是提供无服务器功能。简介：您需要对代码进行版本控制，并且需要对数据进行版本控制。2.明确的特征依赖在理想的世界中，产生输入数据的东西应该总是产生相同的数据，至少在结构上是这样。但世界并不完美，你从上游服务中获取的数据也是由人类构建的，因此它可能会发生变化。最终，特征也可能发生变化。在最好的情况下，你的模型会简单地失败并报告错误，但在最坏的情况下，你的模型会悄悄地继续工作，但你得到的结果是垃圾。明确定义的功能依赖关系会尽快揭示失败案例。如果系统设计得好，也可以在服务时不断训练，然后调整和适配依赖关系。总结：理清代码中的特性依赖。3.描述性训练和预处理好的软件有好的描述和注释——让阅读和理解代码功能变得容易，而不必阅读每一行代码。虽然机器学习是一种特殊的软件开发，但它并不鼓励从业者背离既定的编码原则。在代码编写标准中，最基本的就是让人在短时间内读起来毫不费力。预处理和模型代码都应遵循PEP8规范。代码应使用有意义的对象名称，并包含便于理解的注释。遵循PEP8规范可提高代码可读性、降低复杂性并加快调试速度。像SOLID这样的编程范例提供了一个经过深思熟虑的框架，可以提高代码的可维护性、可理解性和未来用例的灵活性。配置应该与代码分开。不要将数据分配比例硬编码到代码中，而是通过配置提供，以便在运行时修改。这在超参数调整方面众所周知：使用单独的配置文件可以显着加快迭代速度并使代码库可重用。总结：提高代码可读性，代码和配置分离。4.训练结果的可复现性如果你不能复现训练结果，那么这个结果就是不可信的。虽然这是本文的主题，但在再现性方面有一些细节需要澄清。不仅您需要能够重现训练结果，您的整个团队也需要能够做到这一点。在JupyterNotebooks中混淆训练结果与再现性相反，无论是在PC还是AWS虚拟机上。通过设置训练工作流程，整个团队都可以透明地访问已执行的实验和运行的训练。通过将可重用的代码库和单独的配置文件捆绑在一起，每个人都可以随时成功地重新训练。摘要：使用流水线工作流和自动化。5.测试测试有多种形式。两个示例：1)单元测试是在原子级别进行测试——根据各自的标准分别测试每个函数和功能。2）集成测试，相反，将代码库的所有元素放在一起进行测试，同时也测试上下游服务的克隆或模拟版本。两种范例都适用于机器学习。预处理代码是预先确定的，直到测试阶段-转换是否会针对不同的输入获得正确的结果？模型是集成测试的一个很好的例子——在生产中使用时，您的模型的性能是否与评估时一样好？总结：测试你的代码，测试你的模型。6.offset和continuoustraining在生产场景中，taskoffset是一个合理的问题。只要数据有可能发生变化，就需要考虑偏差的可能性。针对此问题的风险，您可以采取两种措施：1)监控生产系统中的数据。建立自动报告机制以在数据发生变化时通知团队，甚至可能超出明确定义的功能依赖性。2）基于新输入数据的持续训练。自动化良好的管道可以在新数据上重复运行，与历史训练结果进行比较，显示性能如何变化，并快速将经过训练的模型投入生产，使模型表现更好。摘要：如果您的数据发生变化，请使用持续训练管道。7.跟踪结果Excel不是跟踪实验结果的好方法。不仅是Excel，任何分散的手动跟踪方法都不那么权威，因此也不那么值得信赖。正确的做法是以数据集中存储的方式自动记录训练结果。自动化确保每个培训课程都得到可靠的跟踪，便于以后比较每个培训课程的结果。结果的集中存储可以为团队提供透明度并实现持续分析。摘要：通过自动化方法跟踪结果。8.实验模型与生产模型我们需要努力理解数据集。通常，我们通过实验获得理解，尤其是当我们关注的领域有很多隐含的领域知识时。创建一个JupyterNotebook，将部分/全部数据导入PandasDataframe，进行几个小时的非结构化研究，训练第一个模型，评估结果-任务完成。但幸运的是，情况并非如此。在机器学习生命周期中，实验有其自身的目的。这些目标不是模型，而是理解。基于探索性Jupyter笔记本的模型用于理解，而不是为生产而开发的成品。一旦理解，在开始构建生产就绪培训管道之前，需要进一步开发和调整。然而，所有独立于特定领域知识的理解都可以自动化。您可以根据您使用的数据的每个版本生成统计信息，从而跳过您在JupyterNotebooks中进行的那些一次性的临时探索，直接进入第一个管道。您越早在此过程中进行试验，就可以越早协作处理中间结果，并且可以越早获得可用于生产的模型。摘要：Notes无法投入生产，因此请尽早进行试验。9.训练和服务之间的方法差异训练和实际服务之间通常存在方法差异，需要减轻这些差异，以便将所有数据预处理适当地纳入模型服务环境。这当然是真的，你也需要坚持这一点。然而，这只是对问题的部分解释。让我们简单回顾一下DevOps的一段古老历史：2006年，亚马逊的CTOWernerVogels创造了一句话“Youbuildit,yourunit（构建你想运行的东西）”。这是一个描述性短语，意味着开发人员的责任不仅仅是编写程序，还包括运行程序。机器学习项目需要类似的机制——数据科学家有能力了解上游数据生成和下游模型使用。你们训练用的数据是什么系统生成的？会出错吗？系统的服务级别目标(SLO)是什么？这是否符合实际服务的目标？您的模型将如何服务？运行环境是什么样的？如何在服务时预处理函数？这些是数据科学家需要理解和回答的问题。总结：正确地将预处理嵌入到服务中，确保您了解数据的上游和下游。10.可比性从第二个训练脚本引入到项目中，可比性成为未来工作的重要组成部分。如果第二个模型的结果与第一个模型的结果不可比，则整个过程都被浪费了，其中至少有一个是多余的，可能两者都是。根据定义，所有试图解决同一问题的模型训练都需要具有可比性，否则它们就不是在解决同一个问题。虽然迭代过程可能会导致所比较的内容发生变化，但从一开始就需要将模型训练的技术可比性作为一流的功能构建到训练架构中。总结：构建自己的流水线流程，轻松比较各个流程的训练结果。11.监控粗略地说，机器学习的目标应该是通过从数据中学习来解决问题。为了解决这个问题，需要分配计算资源。首先是分配给模型的训练，然后是分配给模型的服务。无论培训期间负责提供资源的人员或部门，还负责将这些资源转移到服务中。模型在使用过程中可能会出现很多性能下降的问题。数据可能会倾斜，模型可能成为整体性能的瓶颈，而偏差是一个真正的问题。效果：数据科学家和团队负责监控他们创建的模型。他们不一定负责实施监控，特别是如果组织结构很大，但他们肯定需要负责理解和解释监控数据。至少，需要监控的是输入数据、推理时间、资源使用（CPU、RAM）和输出数据。简介：再次重申，“您构建它，您运行它（构建您想要运行的内容）”。生产中的监控模型是数据科学的一部分。12.模型可部署性从技术角度来看，每个模型训练过程都需要得到一个成品，可以部署到生产环境中。毫无疑问，这些模型的结果可能很糟糕，但需要将其做成可以部署到生产环境的形式。这是软件开发中的一种常见模式，也称为持续交付（ContinuousDelivery）。团队需要能够随时部署他们的软件，并且迭代周期需要足够快才能实现这一目标。机器学习也需要类似的方法。这迫使团队首先考虑现实与期望之间的平衡。所有利益相关者都应该清楚，根据模型结果，哪些结果在理论上是可能的。所有利益相关者都应该就如何部署模型并将其与更大的软件架构集成达成一致。然而，这可能还需要自动化，以及前面提到的一些元素。简介：每个训练过程都需要产生可部署的产品，而不仅仅是“模型”。
