关键要点

• 产品团队、CI/CD、自动化测试和 IT 与业务团队之间的合作越来越紧密。但是，数据科学家和 ML 工程师在哪里？让他们也加入进来，但没有必要把这叫作 DevMLOps。

• 数据科学家通常来自学术背景，并且害怕分享他们认为不够好的模型，所以要为他们创造一个可以允许他们失败的环境！

• 持续集成和持续部署（CI/CD）是令人惊叹的最佳实践，也可以被应用在机器学习组件上。

• 除了 CI/CD，我们应该对模型进行持续评估——版本算法、参数、数据及其结果。

• 机器学习的 bug 并不只是返回错误值的函数，它们还会导致偏见、精度漂移和脆弱的模型。

机器学习开发侧重于超参数调整和数据管道，但这并不意味着我们需要重新发明轮子或寻找一种全新的方式。Thiago de Faria 说，DevOps 为此奠定了坚实的基础：为支持实验而进行的文化变革、持续评估、共享、抽象层、可观察性以及产品和服务方面的工作。

来自 LINKIT 的 DataOps 和 AI 负责人 Thiago de Faria 在 Codemotion Berlin 2018 大会上谈到了人工智能与 DevOps 的思维方式。InfoQ 通过问答、摘要和文章的形式报道了这次会议。

使用 if/elses、循环和确定性函数开发应用程序的方式已经涵盖了业界绝大多数的用例。我们为支持生态系统、调试和测试而构建的工具都考虑到这些用例。de Faria 认为，对于 ML 应用程序，我们必须从不同的视角来考虑问题。

de Faria 说，数据科学从业者应该从去年就开始从 DevOps 文化的直接结果中获得好处：可部署的工件、可观察性、共享文化、核心的实验/失败，以及产品和服务方面的工作。

de Faria 认为，让人们进入“运营的地狱”有助于提高产品质量。

InfoQ 采访了 de Faria，谈论了在机器学习中应用 DevOps 的相关问题。

InfoQ：你对人工智能和机器学习的定义是什么？

Thiago de Faria：我对它们的定义不一定是对的，也不一定有多特别。我通常会在演讲开始时指出这一点，以便与观众达成一种共识，因为我注意到，有时候 ML、AI、数据科学、深度学习和所有这些都被视为同一个东西。

人工智能（AI）让计算机能够处理由人类完成的事情，它们需要独特的智能。机器学习（ML）是构建智能的一种方法，确保这些机器可以在不需要人类对其进行编程的情况下自己找到模式。

更确切地说，特别是对于 ML 部分，我们可以这样想：

1. 数字图像是由像素的 RGB 值（从 0 到 255）组成。

2. 如果你想创建一个规则来识别图片中的猫，你也可以试着使用传统的循环、if/else 和规则来实现。

3. 假设第 4 个像素的 RGB 值为（24,42,255），第 5 个像素是（28,21,214），等等等等——那么这些像素就表示是一只猫！

4. 你能想象你要写多少个 if/else 吗？无穷多！此外，当你获得一张从未见过的新照片时，你该怎么办？你的世界现在是灰暗的！

机器学习让我们拥有基于统计学的算法（根据你拥有的数据尝试找到预测函数的过程），可以为你提供从图片中识别猫的可能性，并且可以基于数据进行训练。

InfoQ：人工智能和机器学习在集成开发和部署方面面临哪些挑战？

De Faria：它们与我们在传统软件开发中遇到的问题是一样的，但视角不同：版本控制、打包、部署、协作和服务。主要问题是我们正试图将我们之前在软件开发中使用的解决方案强制应用在这个生态系统上。

去年，我们看到试图解决 ML 开发生命周期的产品（特别是开源的）数量大幅增加——运行在 Kubernetes 上的 Spark、tensorflow、kubeflow、MLflow、Uber 的 Michelangelo，以及云供应商提供的模型训练和服务工具。我们正在目睹这个生态系统的不断成熟，这是一个不断发展的环境。

InfoQ：bug 和测试呢…ML 组件如何处理这些问题？

De Faria：机器学习领域最值得注意的 bug 是：偏见、漂移和脆弱性。

偏见来自用于构建特征的数据集，它们早已存在，并且可能带来灾难性的结果，尤其是当它们被用在类似黑盒的模型上时——被亚马逊报废的“最性感的 AI”工具就是这类 ML 模型的一个示例，它通过了公司的所有测试，被认为是高质量的一款工具。然而，在过滤和招聘软件工程师的过程中，数据存在偏见，因为在软件技术行业，女性的代表性不足，这已经成为该行业的一个偏见。这意味着工具的算法对女性候选人不利，因为用来训练它的数据集中包含的样本太少。这也可能发生在抵押贷款评分系统和很多其他业务中。Cathy O’Neil 在 2016 年出版了“Weapons of Math Destruction”一书，书中列出了很多算法中存在的问题，但人们用这些算法在招聘、人类分类和其他方面做出重要的决定——这是一本很好的书！

在构建模型，运行模型和部署模型时都会发生漂移。你可能已经仔细考虑到所有的细节，一切都没问题，对吗？可惜的是，事实不是这样的。我们必须根据使用情况和数据对模型进行重新校准，以保持准确率。否则，随着时间的推移，它会漂移并变得更糟。

脆弱性与偏见有关，但更多的是与团队无法掌控的变化有关。定义的变化、变得不可用的数据、不应该存在的空值……你的模型如何应对这些问题，它有多脆弱？

最糟糕的是，ML 中的大多数错误在进入生产环境之前无法被识别出来。这就是为什么监控和可观察性、DevOps 的其他方面在机器学习组件中扮演着重要的角色。你必须度量用来识别 ML 组件对业务价值影响程度的代理。例如，你是否创建了推荐引擎，在上线之前是否应用了 AB 测试策略？有没有比较两组之间的变化？或者你可能有一个图像标记组件，人们有在使用以它为基础的功能吗？你无法直接跟踪 ML 组件，但你可以分析它们的度量代理。这些类型的指标和对度量的专注可以帮助你在早期检测和处理 ML 错误：偏见、漂移和脆弱性。

InfoQ：你谈到了数据科学与运营之间存在差距。是什么造成这个差距？

De Faria：同样的问题也影响（现在仍然如此）着业务，并“催生”了 DevOps 运动——业务与实际工业化/运营之间的距离。这个距离是由三个方面的因素造成的：速度慢（从想法转变为生产需要大量的时间）、大量的交接（X 与客户交谈、A 编写用户故事、B 构建、C 验证、D 批准、E 部署、F 运营、G 修复错误、H 重建……），以及以项目划分（而不是以产品划分）的大量团队。Nicole Forsgren 博士、Jez Humble 和 Gene Kim（DORA 的联合创始人）合著的“Accelerate: Building and Scaling High Performance Technology Organizations”一书和他们发布的 DevOps 状态报告是这方面非常好的参考资料。随着组织开始改变软件开发和交付生命周期的方式，这种距离越来越明显。为什么？因为我们可以看到，在采用新的实践、工具和改变文化（这是最难的）之后，很多组织都取得了成功。

InfoQ：我们可以做些什么来缩短距离和改善协作？

De Faria：仍然是组织最艰做到的事情：改变文化。对于 ML 工程师和数据科学家来说，文化方面的一些东西可能会产生很大的影响，但我所看到的最引人注目的一点是与专业人士的背景有关。他们中的大多数人都具有非常强的学术背景，这意味着他们习惯于长期处理一个问题，直到可以公开发布为止。他们的标准非常高，不仅仅是在一些指标上，还包括实验设计、数学严谨性，等等。在业务环境中，这也很重要，但重要性没有那么高……这意味着他们可以发布具有 60％准确性的模型，并使其处于可部署状态。他们希望最好尽快将模型投入生产，而不是等待几个月之后的“足够好”的模型。或许过了三个月，原先要解决的问题已经变成不值得解决的问题。快速灵活才是最好的方法。

InfoQ：对于想要从人工智能和机器学习中获益的公司，你有什么建议？他们应该做什么或不该做什么？

De Faria：培训数据科学家和从构建 AI 应用程序的 ML 技术中创造价值是非常困难的。为了让这些变得可行和有趣，并吸引这些专业人士，我们必须改变文化。为通往这种“最佳文化”设计出一条道路也是很难的，因为每家公司都有自己的方式，而且很难实现它们之间的互动。我所看到的一些可以缩短产品上市时间并且数据科学产生了很多价值的文化特征包括：

数据科学——“科学”部分包含了实验和失败的尝试。并非所有的试验都会成功，因此数据科学不会一直产生令人兴奋的解决方案。有时候你会掉入兔子洞。或者，业务可能会发生变化。所以问题就变成：如果你是一名数据科学家，你在一个项目上工作了几天却看不到它的未来，那么你是否有勇气告诉你的老板或利益相关者？同样，反过来，他们也可以随时来找你，然后告诉你说业务发生了变化，我们必须改变方向。

除了 CI/CD，我们需要关注 CE，即持续评估。每次测试新模型时——可能是同一算法或新算法的新超参数——我们必须能够将其与之前的运行进行比较。它有多准确？为什么结果会不一样？我们使用了相同的数据集吗？这是在公司内部充分利用资源和学习经验的基础。因此，我们需要实现 CI/CD/CE 管道！

分享。不仅要分享好的模型，还要分享那些完全不合时宜的模型！始终对你的代码和模型进行版本控制！学会使用 git！为什么？因为当别人看到它时，他们不会再使用相同的数据集和参数再试一次错……停止浪费！

为数据科学提供平台和工具，以抽象他们不知道的事物（他们不需要知道）。数据科学家可能不知道是通过 REST 还是 gRPC 来提供模型，也不知道如何打包模型，是否应该部署在 Kubernetes 集群上，或者每秒应该处理多少请求——这些不是他们应该知道的专业知识。团队必须提供一个平台，并提供一个管道来完成这件事。这里的问题是不要期待有“银弹平台”。每家公司都有自己的流程、工作方式和想法……但不要将文化归结为一种工具。

按照产品和服务来划分工作，而不是项目。开发人员、安全专家、SRE……每种角色都应该参与到产品和服务开发当中。这样就可以确保从第一天开始就拥有可部署的工件！但在部署之后，工作还没有结束……你还要对运行在生产环境中的 ML 模型进行运维、监控、重构、校准和执行其他的一些任务。

关于受访者

Thiago de Faria 是荷兰 LINKIT 解决方案工程的负责人。他从 Pure Mathematics 开始，转向预测，并意识到预测完全依赖于理解软件开发和数据管道的内部要素。因此，他的主要关注点发生了变化：如何缩小 ML 与生产环境之间的差距？是 DataOps！他是社区的积极参与者（devopsdays Amsterdam、ITNEXT 和 Codemotion）、知识分享者、一个父亲和蓝调音乐粉丝。Faria 拥有一颗好奇心，是一个不断学习的人。他知道，高绩效的数据团队必须能够缩短产品上市时间，并构建出生产就绪的应用程序！

查看英文原文：

https://www.infoq.com/articles/machine-learning-learn-devops