TensorFlow Extended(TFX)是Google提供的基于TensorFlow可大规模扩展的机器学习平台。2020年Google团队通过一篇论文公开了TFX的发展历程，好奇这些先进技术工具的发展演变历史，作者的行文并没那么学术化，偏自然表述的方式。论文值得一看。自己尝试翻译了一部分，后来看到了Google官方账号的中文译文，对比了一下自己译文的差距（o(╥﹏╥)o），都是辛酸泪啊（博文中引用来自官方翻译）。
软件工程作为一门学科，在过去的50多年中有了充分的发展。现代世界严重依赖于软件工程技术，因此软件工程技术的日益成熟成为一种可能的趋势。像测试和可靠技术这样的实践使软件工程在工业上的表现更加可靠。与此同时，机器学习（ML）在过去20多年中也在不断的成长。ML越来越多地用于研究、实验和生产工作负载。现在ML广泛的为生活中我们使用的产品提供动力。
但是ML工程作为一门学科，并没有像软件工程那样成熟。我们能把我们所学到的东西，帮助新兴的ML领域发展成ML工程，就像编程发展成软件工程一样吗？
在本文中，我们将快速了解Sibyl[2]和TensorFlow Extended（TFX）[3]，两个连续的端到端（E2E）ML平台。我们将分享近十多年来在这些平台上部署ML工程的经验教训，解释它们的相似性和差异，以及在这个过程中从心理或者技术上我们的转变历程。此外，我们将重点介绍TFX的一些功能，这些功能有助于实现ML工程的几个方面。我们认为，组织者应该通过投资强大的ML基础设施和促进ML工程教育，让ML可以带来更多的收益。我们还建议，在关注前沿技术之前：对于ML建模技术，产品领导者应该为他们的企业投入更多时间在采用可互操作的ML平台上。最后，我们还将展开一些对TFX未来的畅想。
在过去十年里，ML应用已经成为Google提供的产品和服务中不可或缺的一部分，并且随着时间的推移变得越来越重要。我们在很早时候就发现，如果将ML应用于生产中，尽管算法很重要，但对于实现ML在一个产品的成功应用，却不是充分的条件。特别是，E2E ML平台为了有助于ML生命周期的各个方面，通常需要在ML的采用和使用持久，可持续性两个方面进行加速。
端到端ML平台并不是Google的新事物，Sibyl成立于2007年，是一个可以满足大规模ML生产和使用的平台。Sibyl在“wide”模型上结合非线性变换和可定制的损失函数与正则化上提供了相当大的建模灵活性(线性、逻辑、泊松回归和因子分解机)。重要的是，Sibyl还为ML工作流的几个方面提供了工具，包括数据获取，分析和验证，训练，模型分析，以及不平衡样本的检测训练任务。所有这些都被打包为一个允许迭代的集成产品中。这种全面的产品服务提供，以及Sibyl团队以用户为中心的理念，Sibyl曾一度成为Google中使用最广的E2E ML平台之一。Sibyl投入生产约有14年后，现在已经正式停用了，其绝大多数工作已经迁移到TFX。
当我们几个人还在研究Sibyl时，随着深度学习（DL）技术的普及，ML算法领域发生了一场显著的革命。2015年，Google公开发布了TensorFlow（它本身就是之前一个名为“DistBelief”的系统的继承者）。自成立以来，TensorFlow在DL训练和推理任务上支持多种应用。它灵活的编程模型使得它具有比DL更广泛地使用，并且因为在研究和生产领域的流行使TensorFlow定位为开发者在ML上的通用框架语言。尽管TensorFlow提供了灵活性，但它缺乏完整的端到端生产系统。另一方面，Sibyl具有强大的端到端能力，但缺乏灵活性。很明显，我们需要一个兼容TensorFlow的E2E ML平台，以加速Google的ML应用；2017年，在Sibyl诞生近十年后，我们在谷歌内部推出了TFX。TFX现在是包括Google在内行业内使用最广泛的端到端的ML平台。
自从推出的3年来，TFX成为工业级ML部署的平台，被业内成千的使用者使用。并且可以赋能业内诸多AI云服务的产品，包括Google云的人工智能云服务平台（GCP）。任何一天，TFX管道都在工作，产生百兆级别的数据，生产数以万计的模型，这些模型又在每秒执行数亿次推理任务。TFX的广泛使用有助于从研究到生产的流程，多样的使用场景也帮助TFX团队更加专注于模型本身的研发而不是ML平台的发展，使ML更容易用于新产品领域，并实现从ML应用到创建ML平台演变的良性循环。
TensorFlow的流行和在业内的影响，使得我们不能忽视这一点：世界各地的组织和个人开发者都需要部署ML工程，所以我们选择公开描述TFX的设计和TFX在Google的最开始部署（开源）。与Sibyl一样，TFX的构建也是基于强大的基础设施依赖性。例如，Sibyl大量使用MapReduce其后继Flume用于分布式数据处理，现在TFX很强的依赖其后继产品。
随着TensorFlow的步伐，TFX从2019年发布的一年时间里被广泛的在各个场景中使用。我们的一些合作伙伴也公开分享了他们基于TFX支持的用例，包括如何从根本上改进了他们的ML应用。
尽管Google ML平台的演变漫长而激动人心，但是我们预计大部分激动人心的时刻还没到来！为此，我们想分享我们的经验总结，其中一些经验尤为痛苦。第一类是什么作为发展的一部分保持不变，第二类是什么改变了，以及为什么改变！我们在两个平台（Sibyl和TFX）的背景下介绍这些经验，尽管它们被广泛使用。
本节重点讨论那些似乎经得起时间考验的例子。因此，我们期望这些在未来也将适用于不同版本的ML平台和框架。我们会从应用ML的角度和基础设施的角度来看待这些问题。
机器学习的一些规则
成功地将ML应用于产品在是一门较大的学科。它涉及一个陡峭的学习曲线，需要一些心理模型转换（或增强）。为了使这项具有挑战性的任务更容易，我们公开分享了机器学习的规则。这些规则是从迭代中学习的内容，将ML应用于Google的许多产品。值得注意的是，在Google产品中采用ML说明了一个共同的演变。
- 从简单的规则和启发式方法开始，随后生成用于学习的数据；这一过程通常从服务端开始。
- 使用简单的 ML（即简单模型）并实现巨大收益；这通常是引入 ML 流水线的切入点。
- 使用具有更多功能和更高级模型的 ML，以实现可观的收益。
- 探索最前沿 (SOTA) 的 ML，精细化管理和复杂性（旨在解决值得处理的问题），并实现较小的收益。
- 牢记投资回报（和收益递减），将上述启用-迭代的循环应用于产品的更多方面并解决更多问题。
我们发现机器学习的规则在平台和时间上维度上都是稳定的，我们希望它们最终对其他人和我们的用户一样有价值。特别地，我们相信遵守规则会帮助他人更好地掌握ML工程学科，包括帮助他们避免我们和我们的用户过去犯的错误。TFX试图将这些规则编码成代码。确切的说，我们希望为自己带来好处，但也希望加速ML的整个行业发展。
ML工程的学科
在开发机器学习规则时，我们意识到，在核心逻辑由涉及代码和数据的复杂过程生成的情况下，构建健壮系统的规程需要软件工程所提供额外审查。因此，我们将ML工程定义为软件工程学科的超集，旨在处理ML实际应用的独特复杂性。
试图总结ML工程学科的整体是有些困难的，特别是考虑到我们对它的理解仍然有限，学科本身也在不断发展。不过，我们确实从以下几点中得到安慰：
- 我们拥有的有限理解似乎可以跨越平台和时间经久不衰。
- 类比可以成为一种强大的工具，因此，更好地理解软件工程学科的几个方面已经帮助我们发现了 ML 工程如何从 ML 编程中发展而来的相似之处，就像软件工程如何从编程中发展而来一样。
我们的早期认识如下：构建物（artifacts）是ML中的一级公民，与生产和使用它们的过程一样。这一认识影响了Sibyl的实施和发展；在我们公开发表文章时，它已经在TFX中根深蒂固，并且最终在ML元数据中进行了概括和形式化，现在为TFX提供了支持。
下面，我们介绍了ML工程的基本元素、ML工件的一些示例及其一级公民身份，并尝试在可能的情况下与软件工程进行类比。
数据
类似于代码是软件的核心，数据是ML的核心。数据管理代表了生产ML的严重挑战。也许最简单的类比是考虑什么构成了数据的单元测试。单元测试通过测试相关代码的契约并在所述契约中灌输可信度来验证对代码应该如何表现的期望。类似地，对数据的形式（包括其模式、不变量和值分布）设置明确的期望，并检查数据是否与嵌入训练代码中的隐含期望一致，可以使数据足够可信，从而在上训练模型。
尽管单元测试可以是详尽的，并验证强契约，但数据契约通常要弱得多，即使它们是必要的。尽管单元测试可以被人类穷尽地消耗和验证，但数据通常只能以概括的方式对人类有意义。
正如代码库和版本控制是软件工程中管理代码演化的支柱，管理数据演化和理解的系统也是ML工程的支柱。
模型
类似于软件工程师通过编译生成程序的代码，ML工程师 “编译”生成ML程序的数据和代码的行为，称为模型。这两种程序在性质上非常不同。虽然来自软件工程的程序通常有很强的关联，但模型的关联要弱得多。这些弱关联通常是统计性质的，因此只能以某种概括形式进行验证（例如，在标记数据集上模型的精度情况）。模型是代码和数据的产物，这一点也不奇怪，而数据本身没有强大的关联，也只能以总结形式进行处理。
正如代码和数据随着时间发展，模型也随着时间发展。然而，模型演化比其组成代码和数据的演化更复杂。例如，高测试覆盖率（使用模糊化）可以对一段代码的正确性和正确演化提供良好的置信。
以同样的方式，将多个程序放在一个系统中需要作为软件工程支柱的集成测试，将代码和数据放在一起需要端到端的模型验证和理解，这是ML工程的支柱。
TFX的Evaluator 和InfraValidator组件提供模型的验证和理解。
------------------
此处是未翻译的框架。
从我们 10 多年的 ML 平台发展历程中获得的经验教训
我们去往何处？
-------------------
尽管 TFX 为 ML 工程的各个方面以及 ML 生命周期的多个阶段提供了工具，但我们认为这仍然是一个新兴领域。虽然改进工具与 TFX 天然契合，但它也反映了我们的原则，即帮助 ML 部署“用于符合这些原则的用途”、“为科学卓越提供支持”以及“以安全方式构建和测试”。
改进的一个方面是将 ML 应用于数据本身，无论是通过感知异常还是在数据中查找模式，或者通过 ML 模型的预测来丰富数据。让大量数据轻松丰富起来（尤其是用于低延迟、高容量操作的关键流式传输数据）一直是一种挑战。将 TFX 功能引入数据处理框架是我们的第一步。我们已经可以用标签来丰富流式传输事件，或者在 Apache Beam 以及通过扩展程序在 Cloud Dataflow 中进行预测。我们计划通过利用预先构建的模型（由 Cloud AI Pipelines 和 TensorFlow Serving 应用）来跟踪这项工作，以便简化在表示来自模型流的预测的分布式数据集中添加新字段的过程。
此外，尽管有许多用于检测、发现与审核 ML 工作流的工具，但仍然需要以自动化（或辅助）方式缓解发现的问题，我们将在这一领域进行投入。例如，根据当前正在执行的流水线（甚至在训练之前）主动预测哪个流水线运行不会生成更好的模型，可以显著减少在创建不良模型上花费的时间和资源。
尽管TFX为ML工程和ML生命周期的几个阶段提供了工具，我们认为这仍然是一个新兴领域。虽然改进工具是TFX的自然选择，但它也反映了我们的原则，即帮助ML部署“可用于符合这些原则的用途”，“支持科学卓越”，以及“为安全而构建和测试”。
改进的一个方向是将ML应用于数据本身，无论是通过感知异常或发现数据中的模式，还是通过ML模型的预测来丰富数据。使丰富大尺度的数据（特别是用于低延迟、高容量的关键流数据）变得容易一直是一个挑战。将TFX功能引入数据处理框架是我们的第一步。我们已经可以用标签来丰富流事件，或者在Apache Beam中进行预测，扩展到云数据流。我们计划通过利用预先构建的模型（由云人工智能管道和TensorFlow服务提供服务），在分布式数据集中添加一个新字段，表示来自模型流的预测，从而完成这项工作。
此外，尽管存在许多用于检测、发现和审核ML工作流的工具，仍然需要更自动（或辅助）缓解发现的问题，我们将在这方面进行探索。例如，基于当前执行的管道，主动预测哪些管道运行不会产生更好的模型，也许甚至在训练之前，就可以显著减少因为创建了差的模型话费的时间和资源。
构建 TFX 和探索 ML 工程的基本原理是许多人多年来努力的累积。随着我们不断取得进展并进一步发展这一领域，重要的是，我们要意识到这是那些让我们走到今天这一步的前辈的共同努力。
当然，我们将需要更多的合作来驾驭这一领域的未来，因此，我们邀请您与我们携手，一同“迈向 ML 工程”！
构建TFX和探索ML工程的基础建设是许多人多年来的累积努力。随着我们在这一领域的不断进步和进一步发展，我们必须认识帮我们一路走来的合作者的重要。
当然，要推动这一领域的未来，还需要更多的合作，因此，我们邀请您加入我们的“迈向ML工程”之旅！