迈向 ML 工程：TensorFlow Extended (TFX) 简史

会员服务 ·

迈向 ML 工程：TensorFlow Extended (TFX) 简史

2020 年 11 月 10 日 TensorFlow

文 / 由 Konstantinos (Gus) Katsiapis 代表 TFX 团队发布

— 目录 —

摘要
我们从何而来

Sibyl (2007 - 2020)
TFX (2017 - ?)

从我们 10 多年的 ML 平台发展历程中获得的经验教训

保持不变的方面以及原因
有所不同的方面以及原因

我们去往何处

推动互操作性和标准发展
提高自动化程度
加深对 ML 的理解
坚持高标准和最佳做法
改进工具

共同的旅程

TFX 团队
TFX 团队（延伸）

摘要

50 多年以来，软件工程作为一门学科发展日趋成熟。现代世界非常依赖这门学科，因此软件工程的日益成熟也是大势所趋。诸如测试和可靠性技术等的实践与发展使得软件工程可以在其之上继续延伸，更好的与各行业相结合。同时，在过去 20 多年中，机器学习 (ML) 也在不断发展。ML 已越来越多地应用于研究、实验和生产任务中。ML 现在能够助力为我们生活中常用的必备产品。

但作为一门学科，ML 工程尚未像其前身软件工程那样得到广泛而成熟的应用。我们能否利用我们学到的知识，就像编程发展为软件工程一样，帮助应用 ML 这一新兴领域向 ML 工程发展？

软件工程
http://shop.oreilly.com/product/0636920296423.do

在本文中，我们将对 Alphabet 的两个连续端到端 (E2E) ML 平台 Sibyl 和 TensorFlow Extended (TFX) 进行一次快速入门介绍。我们将分享十多年来我们在这些平台上构建与应用 ML 中学到的经验教训，区分两个平台的异同，并详细介绍技术的变革给我们带来的一些思考与转变（精神上和技术上）。同时，我们将重点介绍 TFX 的一些功能，这些功能有助于从多方面助力实现 ML 工程。我们认为，为了释放 ML 的潜力，企业与组织应当通过投资于可靠的 ML 基础架构并推动 ML 工程教育来帮助 ML 团队发展成熟。我们还建议，在专注于前沿 ML 建模技术之前，产品负责人还应当投入更多时间来为推动企业内采用可互操作的 ML 平台。最后，我们还将分享 TFX 的未来愿景。

Sibyl
https://www.datanami.com/2014/07/17/inside-sibyl-googles-massively-parallel-machine-learning-platform/
TensorFlow Extended
https://tensorflow.google.cn/tfx

我们从何而来

在过去十年中，我们将 ML 结合到 Google 产品和服务中，并且随着时间的推移，ML 变得越来越重要。我们从早期在生产环境中应用 ML 所做的努力中发现，尽管 ML 算法相当重要，但它们通常难以成功实现 ML 的顺利落地。特别的是，这通常需要借助端到端 (E2E) ML 平台（为 ML 生命周期的各阶段提供帮助）来加速 ML 的应用并使其持久且可持续。

难以成功实现 ML 的顺利落地
https://research.google/pubs/pub43146/

Sibyl (2007 - 2020)

E2E ML 平台在 Google 并非新鲜事物。Sibyl 平台创建于 2007 年，以实现大规模 ML 满足生产需求为目标。在“宽”模型（线性、逻辑、泊松回归和后来的因式分解机）的基础上，再加上非线性变换、可自定义的损失函数和正则化，Sibyl 极大提供了建模的灵活性。重要的是，Sibyl 还为 ML 工作流的多个方面提供了工具，如数据提取、数据分析与验证、训练（必备）、模型分析以及训练：应用偏差检测。所有这些均打包为支持迭代实验的单个集成产品。这种全方位的产品组合，再加上 Sibyl 团队对用户的专注，使 Sibyl 一度成为 Google 使用最广泛的 E2E ML 平台之一。此后，Sibyl 被弃用。它在生产环境中使用了大约 14 年，其大部分工作任务已迁移到 TFX。

TFX (2017 - ?)

当我们中的一些人仍在研究 Sibyl 时，随着深度学习 (Deep Learning，DL) 的普及，ML 算法领域发生了一场引人瞩目的革命。2015 年，Google 公布了 TensorFlow（TensorFlow 本身是先前名为 DistBelief 的系统的后继者）。

公布了 TensorFlow
https://research.google/pubs/pub45381/
DistBelief
https://research.google/pubs/pub40565/

自发布以来，TensorFlow 便一直专注于支持 DL 训练和推断的各种应用。它灵活的编程模型使其可用于 DL 之外的许多领域，而它在研究和生产中的普及则使其成为编写 ML 算法的通用语言。尽管 TensorFlow 提供了较大的灵活性，但它缺乏完整的端到端生产系统。

另一方面，Sibyl 具有可靠的端到端功能，但缺乏灵活性。很明显，我们需要适用于 TensorFlow 的 E2E ML 平台，以便加快 Google 内部的 ML 进程；在 Sibyl 诞生近十年后的 2017 年，我们在内部推出了 TFX。TFX 现在是 Alphabet（包括 Google）中使用最广泛的通用 E2E ML 平台。

在随后的 3 年里，TFX 使 Alphabet 能够实现所谓的“工业级”ML：TFX 在 Alphabet 内有数千名用户，它为数百款流行的 Alphabet 产品提供支持，包括 Google Cloud Platform (GCP) 上的 Cloud AI 服务。每一天，都有成千上万个 TFX 流水线在运行，它们处理 EB 级数据，并生成数以万计的模型，而这些模型又每秒执行达数亿次的推理。TFX 的广泛采用有助于 Alphabet 实现从研究到生产的流程，并直接和间接地为 TFX 用户提供非常多样化的用例。此外，广泛的采用 TFX 还使团队能够专注于模型开发而不是 ML 平台开发，从而使 ML 可以更轻松地在全新的产品领域中使用，同时步入了以 ML 应用推动 ML 平台发展的良性循环。

在我们内部取得成功的基础上，再加上对世界各地的组织和个人都将需要 ML 工程等效产品的预期，我们决定公布 TFX 的设计和在 Google 内部的初始部署，并逐步公开更多的学习成果和技术（包括开放源代码），同时我们会继续构建更多内容。我们之所以能够做到这一点，部分原因在于，像 Sibyl 一样，TFX 基于可靠的基础依赖项构建。例如，Sibyl 大量使用 MapReduce 及其后继项目 Flume 进行分布式数据处理，而现在 TFX 大量使用其可移植的后继项目 Apache Beam。

公布 TFX 的设计和在 Google 内部的初始部署
https://research.google/pubs/pub46484/
MapReduce
https://research.google/pubs/pub62/
Flume
https://research.google/pubs/pub35650/

紧随 TensorFlow 的脚步，公开的 TFX 产品于 2019 年初发布，并在不到一年的时间内通过 Cloud AI Platform Pipelines 在各种环境（包括本地部署和 GCP）中广泛应用。我们的一些合作伙伴还公开分享了由 TFX 提供支持的用例，包括如何从根本上提升其应用 ML 速度。

公开的 TFX 产品
https://tensorflow.google.cn/tfx
Cloud AI Platform Pipeline
https://cloud.google.com/blog/products/ai-machine-learning/introducing-cloud-ai-platform-pipelines
从根本上提升其应用 ML 速度
https://engineering.atspotify.com/2019/12/13/the-winding-road-to-better-machine-learning-infrastructure-through-tensorflow-extended-and-kubeflow/

十余年 ML 平台发展中获得的经验与教训

尽管 Google ML Platform(s) 的发展历程漫长而激动人心，但我们预计大部分激动人心的时刻还在后头！为此，我们希望分享我们的学习成果，其中一些成果的获得过程格外艰辛。这些学习成果可分为两类，一类是在发展历程中保持不变的部分，另一类是发生变化的部分以及相关原因！我们将在两个连续的平台 Sibyl 和 TFX 的背景下介绍这些学习成果，其中会有一些普适性的内容，大家可以参考。

保持不变的方面以及原因

本节中探讨的领域列举了一些看起来很持久并且历经时间考验的示例。因此，我们希望这些示例将来在不同形式的 ML 平台和框架中也仍然适用。我们将从应用 ML 和基础架构这两个角度来展示。

应用 ML

机器学习的规则

成功将 ML 应用于产品本身就是一门学科。学习曲线陡峭，并且需要进行一些心智模型转换（或扩展）。为了简化这项颇具挑战性的任务，我们公开分享了 机器学习规则。这些规则总结了 ML 如何迭代并应用于 Google 许多产品的经验。值得注意的是，在 Google 产品中采用 ML 说明了一个共同的发展过程：

从简单的规则和启发式方法开始，随后生成用于学习的数据；这一过程通常从服务端开始。
https://developers.google.com/machine-learning/guides/rules-of-ml#before_machine_learning
使用简单的 ML（即简单模型）并实现巨大收益；这通常是引入 ML 流水线的切入点。
https://developers.google.com/machine-learning/guides/rules-of-ml#ml_phase_i_your_first_pipeline
使用具有更多功能和更高级模型的 ML，以实现可观的收益。
https://developers.google.com/machine-learning/guides/rules-of-ml#ml_phase_ii_feature_engineering
探索最前沿 (SOTA) 的 ML，精细化管理和复杂性（旨在解决值得处理的问题），并实现较小的收益。
https://developers.google.com/machine-learning/guides/rules-of-ml#ml_phase_iii_slowed_growth_optimization_refinement_and_complex_models
牢记投资回报（和收益递减），将上述启用-迭代的循环应用于产品的更多方面并解决更多问题。

机器学习规则
https://developers.google.com/machine-learning/guides/rules-of-ml

我们发现，机器学习规则无论是跨越平台或时间变换都保持不变，我们希望它们最终对其他人也带来同样的价值。特别是，我们坚信，遵守规则将帮助其他人更好地掌握 ML 工程学科，包括帮助他们避免我们和我们的用户曾经犯下的错误。TFX 试图按照字面意义将这些规则编写成代码。我们希望在从中受益的同时也能帮助整个行业加快 ML 的发展。

ML 工程学科

在开发机器学习规则时，我们意识到，用于构建稳健系统（其中的核心逻辑由涉及代码和数据的复杂过程生成）的学科比软件工程需要更多的审视。因此，我们将 ML 工程定义为旨在处理 ML 实际应用的独特复杂性的软件工程学科的超集。

试图总结 ML 工程学科的整体即便并非不可能，也会有些困难，特别是考虑到我们对它的理解仍然有限，而且这门学科本身还在继续发展。不过，我们在以下方面确切感到了安慰：

我们拥有的有限理解似乎可以跨越平台和时间经久不衰。
类比可以成为一种强大的工具，因此，更好地理解软件工程学科的几个方面已经帮助我们发现了 ML 工程如何从 ML 编程中发展而来的相似之处，就像软件工程如何从编程中发展而来一样。

软件工程如何从编程中发展而来一样
http://shop.oreilly.com/product/0636920296423.do

我们的早期认识是这样的：构建物 (Artifacts) 是 ML 中的一等公民，与生成和使用它们的过程同等重要。

这一认识影响了 Sibyl 的实现和发展；截至我们公开编写相关内容时，它已经在 TFX 中根深蒂固，并最终在 ML Metadata 中进行了泛化和形式化，现在为 TFX 提供支持。

公开编写相关内容
https://research.google/pubs/pub46484/
ML Metadata
https://www.tensorflow.org/tfx/guide/mlmd

我们下面将介绍 ML 工程的基本元素、ML 构建物的一些示例及其一等公民身份，并在可能的情况下尝试与软件工程进行类比。

数据

同比代码是软件的核心，数据也是 ML 的核心。数据管理代表了生产 ML 中的严峻挑战。也许最简单的类比是考虑数据的单元测试是由什么构成的。单元测试通过测试相关代码的协定，并在所述协定中灌输可信赖性来验证对代码应当如何表现的期望。类似地，对数据的形式（包括其架构、不变量和值分布）设置明确的期望，并检查数据与嵌入在训练代码中的隐式期望是否相符，可以使数据的可信度足以训练模型。尽管单元测试可以详尽无遗并验证强协定，但即使在必须使用时，数据协定通常也弱得多。尽管人类可以详尽无遗地使用和验证单元测试，但数据通常仅在采用汇总方式时才对人类有意义。

生产 ML 中的严峻挑战
https://research.google/pubs/pub46178/
可以使数据的可信度足以训练模型
https://research.google/pubs/pub47967/

正如代码库和版本控制是软件工程中用于管理代码演化的支柱一样，用于管理数据演化和理解的系统也是 ML 工程的基础。

通过在（连续）ML 流水线中实现数据管理、分析和验证，TFX 的 ExampleGen、StatisticsGen、SchemaGen 和 ExampleValidator 组件可以帮助人们将数据视为一等公民。

在（连续）ML 流水线中实现数据管理、分析和验证
https://research.google/pubs/pub48974/

模型

与软件工程师如何生成被编译为程序的代码类似，ML 工程师也会生成“编译”为 ML 程序（通常称为模型）的数据和代码。但是，这两种程序在本质上极为不同。尽管由软件生成的程序通常具有强协定，但是模型的协定却弱得多。这些弱协定在本质上通常是统计性的，因此只能以某种摘要形式进行验证（例如，在带标签数据的子集上具有足够准确率的模型）。这并不奇怪，因为模型是代码和数据的产物，而后者本身并没有强协定，而且只能以摘要形式来理解。

正如代码和数据随着时间的推移不断演化，模型也会随着时间演化。但是，与构成模型的代码和数据的演化相比，模型本身的演化更加复杂。例如，较高的测试覆盖率（含模糊测试）可以使人们对一段代码的准确性和正确演化都充满信心，但是众所周知，很难为模型评估生成不均匀分布以及反事实但又很现实的数据。

正如将多个程序组合到一个系统中需要集成测试（软件工程的支柱）一样，将代码和数据组合起来则需要端到端模型验证和理解（ML 工程的支柱）。

端到端模型验证和理解
https://research.google/pubs/pub47966/

TFX 的 Evaluator 和 InfraValidator 组件提供了对模型的验证和理解，并将它们视为 ML 工程的一等公民。

可合并片段

与软件工程师如何将现有库（或系统）与其代码合并到一起以构建有用的程序类似，ML 工程师定期将代码片段、数据片段、分析片段和模型片段合并到一起来构建有用的 ML 流水线。软件工程与 ML 工程之间的显著区别在于，即使后者的代码是固定的，数据通常也不太稳定（例如，新数据定期到达），因此，需要频繁且高效地生成下游构建物。例如，如果模型输入数据的任何部分发生更改，通常需要生成新版本的模型。因此，ML 流水线生成可合并的构建物十分重要。例如，来自一个数据集的统计信息摘要应当易于与另一个数据集的统计信息合并，以便可以轻松汇总这两个数据集合并后的统计信息。类似地，将一个模型的学习转移到另一个模型通常应十分简单，尤其是将上一个版本模型的学习转移到下一个版本的同一模型。

不过，这里有一个陷阱，它与前面关于模型测试覆盖率的等效项的探讨有关。将新片段合并到模型中可能需要创建全新的不均匀分布和反事实评估数据，这会提高（高效）模型演化的难度，因此比纯代码演化要困难得多。

TFX 的 ExampleGen、Transform、Trainer 和 Tuner 组件与 TensorFlow Hub 一起，通过在执行数据缓存、分析器缓存、热启动和迁移学习的工作流中实现可合并片段的产生和使用，可以帮助人们将构建物视为一等公民。

TensorFlow Hub
https://tensorflow.google.cn/hub/overview

构建物复用

尽管存在适用于软件工程的所有高级方法论和工具，但总是需要调试构建的程序和系统。对于 ML 程序也是如此，但是众所周知，调试它们更加困难，原因是由于涉及过多的构建物，非邻近效应对于 ML 程序更为普遍。由于来自几种错误源（举例来说，包括代码、学习算法、训练数据、应用路径或应用数据中的缺陷）的不良构建物，模型可能会不准确。就像堆栈轨迹对于确定软件程序中缺陷的根本原因意义重大一样，ML 流水线生成和使用的所有构建物的沿袭对于确定 ML 模型中缺陷的根本原因也意义重大。此外，通过了解用存在问题的构建物生成了哪些下游构建物，我们可以识别所有受影响的系统和用户并采取缓解措施。

TFX 对 ML Metadata (MLMD) 的使用有助于将构建物视为一等公民。MLMD 支持对与构建物相关联的元数据和沿袭进行高级编目和查询，即使在流水线边界之外，也可以共同提高共享构建物的可信度。MLMD 还可以帮助完成高级调试，而且与底层数据存储层配合使用时，可以构成 TFX ML 遵从机制的基础。

ML Metadata
https://tensorflow.google.cn/tfx/guide/mlmd

持续学习与反学习

ML 生产流水线在动态环境下运行：

新数据可以持续到达。
建模代码可能会更改，尤其是在模型开发的早期阶段。
周围的基础架构可能会更改，例如某些底层 (ML) 库的新版本。

发生更改时，流水线需要作出反应，方式通常是在新环境中重新运行其步骤。为了便于调试和分析根本原因，这种动态性提高了起源跟踪的重要性。作为一个简单的示例，要调试模型失效，不仅需要了解使用了哪些数据来训练模型，还需要了解建模代码的版本以及任何周围的基础架构。

此外，ML 流水线还必须支持低摩擦机制来处理这些更改。考虑新数据的到达等情况，这需要对模型进行重新训练。在快速变化的环境（例如推荐系统或对抗系统）中，这是一项自然的要求。假设数据可以定期且频繁地到达，那么要求用户手动重新训练模型可能不现实。作为替代，我们可以通过“连续训练”的方式来采用自动化，其中流水线可以检测到新数据的存在并自动调度更新模型的生成。反过来，此功能需要自动：基于构建物（包括数据）的存在来编排工作、从间歇失效中恢复以及在恢复时达到实时状态。ML 流水线经常连续运行数年来提取代码和数据，并不断生成模型，这些模型可做出有助于决策的预测。

低摩擦机制的另一个示例是支持“回填”ML 流水线。在这种情况下，用户可能需要在现有构建物上重新运行流水线，但需要使用组件的更新版本，例如使用新版本的建模代码/库基于现有数据重新运行训练器。回填的另一种用法是使用现有数据的新版本重新运行流水线，例如，目的是修复数据中的错误。这些回填与连续训练正交，可以一起使用。例如，用户可以手动触发训练器的重新运行，随后生成的模型构建物就可以自动触发模型评估和验证。

基于构建物（包括数据）的存在来编排工作、从间歇失效中恢复以及在恢复时达到实时状态
https://research.google/pubs/pub47978/

TFX 是从头开始构建的，它可以实现从根本上形成其设计的持续学习（和反学习）。同时，这些高级功能还允许以“一次性”、不连续的方式使用它。实际上，在 Alphabet 内部，两种部署模式都得到了广泛使用。此外，TFX 还支持不同类型的回填运算，以在常规流水线执行期间实现细粒度的干预。

即使公开的 TFX 产品尚未提供连续的 ML 流水线，我们仍在积极致力于实现我们现有技术的可移植性，以便可以将其公开发布（例如 RFC）。

公开的 TFX 产品
https://tensorflow.google.cn/tfx/guide
RFC
https://github.com/tensorflow/community/pull/253

基础架构

建立在巨人的肩膀上

要实现雄心勃勃的目标，就必须建立在坚实的基础之上，同时与他人合作并充分利用彼此的工作成果。TFX 重用了 Sibyl 的许多系统设计，这些设计在 Sibyl 十多年的生产 ML 经验中得到了巩固。此外，TFX 将新技术融入出现稳健标准的领域中：

与 Sibyl 基于 MapReduce 构建其算法和工作流的方式类似，TFX 将 TensorFlow 和 Apache Beam 都用于其分布式训练和数据处理工作流。
与 Sibyl 的柱状结构类似，TFX 采用 Apache Arrow 作为其计算密集型库的柱状内存表示。

通过在出现稳健标准的地方获取依赖项，TFX 及其用户可以轻松达到客观的性能和不错的可扩展性。此外，它还使 TFX 可以专注于构建应用 ML 所需的增量，而不是重新实现难以正确获得的技术。当 TFX 的用户从我们的某些依赖项中获得的价值/功能超过更多依赖项所带来的成本时，他们会自行选择这些依赖项，例如 Kubeflow Pipelines 或 Apache Airflow。

Kubeflow Pipelines
https://www.kubeflow.org/docs/pipelines/overview/pipelines-overview/
Apache Airflow
https://airflow.apache.org/

遗憾的是，获取依赖项会产生成本。我们发现，获取依赖项需要付出的努力与依赖项的数量呈超线性关系。所述成本通常由我们和我们的姊妹团队承担，但可能（有时确实如此）转移给我们的用户，形式通常是（版本）依赖项存在冲突或者环境与依赖项之间不兼容。

互操作性和正外部性

ML 平台不能在隔离的环境中运行。相反，它们在更大的系统或基础架构的上下文内运行，同时连接到上游的数据生成源和下游的模型使用接收器，后者又会频繁地生成馈入 ML 平台的数据，进而形成闭环。平台的强采用通常需要与环境中的其他重要技术进行互操作。

与 Sibyl 如何与 Google 的广告技术栈进行互操作来实现数据提取和模型应用类似，TFX 提供了许多用于数据提取的连接器，并允许在多个部署环境和设备中应用生成的模型。
跟 Sibyl 与 Google 的计算堆栈进行互操作类似，TFX 利用 Apache Beam 在 Apache Flink 和 Apache Spark 集群以及无服务器产品（如 Google Cloud Dataflow）上执行。
TFX 基于 MLMD 构建了编排抽象，并基于 Apache Airflow、Apache Beam、Kubeflow Pipelines提供编排选项以及要与用户的自定义编排器集成的基元。MLMD 本身可以使用多个关系型数据库，例如 SQLite 和 MySQL。

MLMD
https://tensorflow.google.cn/tfx/guide/mlmd

互操作性需要一定程度的抽象和标准化，并且通常能实现整体优于其各部分之和的效果。TFX 既是上述互操作性所产生的正外部性的受益者，也是助力者，无论是在 Alphabet 内部还是外部。TFX 的用户也是互操作性的受益者，因为他们可以在现有安装基础上更轻松地部署和使用 TFX。

互操作性也会产生成本。多个技术栈的组合可以导致大量不同的部署配置。虽然我们端到端和大规模测试了一些不同的部署配置，例如 GCP 上的 TFX，但我们既没有专业知识，也没有资源来测试所有可能部署选项的组合爆炸。因此，我们鼓励社区与我们合作确定对他们最有用的部署配置。

GCP 上的 TFX
https://cloud.google.com/blog/products/ai-machine-learning/introducing-cloud-ai-platform-pipelines
鼓励社区与我们合作
https://github.com/tensorflow/tfx/blob/master/CONTRIBUTING.md

有所不同的方面以及原因

本部分中探讨的领域列举了一些需要更改的示例，以便使我们的 ML 平台适应新的现实，并且继续有用且有影响力。

环境和设备可移植性

Sibyl 是一个大规模 ML 平台，适合部署在 Google 的大型集群 Borg 中。这样做很有意义，因为 Google 的应用 ML 最初主要在广泛使用的产品中使用。随着 ML 专业知识在全球范围内不断发展，并且 ML 可以跨 Google 内部和外部的环境应用于更多用例（无论大小），对可移植性的需求会逐渐但必然地成为硬性约束。

Sibyl 仅在 Google 的数据中心上运行，但 TFX 可在笔记本电脑、工作站、服务器、数据中心和公共云上运行。特别是，当 TFX 在 Google Cloud 上运行时，它将利用 GCP 服务提供的自动化和优化功能，而 GCP 则由 Google 独特的基础架构提供支持。
Sibyl 仅在 CPU 上运行，但 TFX 可利用 TensorFlow 在各种类型的硬件上运行，包括 CPU、GPU 和 Google 的 TPU。
Sibyl 的模型在服务器上运行，但 TFX 利用 TensorFlow 生成的模型可以通过 TensorFlow Serving 和 Apache Beam 在笔记本电脑、工作站和服务器上运行，通过 TensorFlow Lite 在移动设备和 IoT 设备上运行，以及通过 TensorFlow JS 在浏览器上运行。

TensorFlow Serving
https://tensorflow.google.cn/tfx/guide/serving
TensorFlow Lite
https://tensorflow.google.cn/lite/guide
TensorFlow JS
https://tensorflow.google.cn/js/tutorials

TFX 的可移植性使其能够用于各种环境和设备，以解决各种规模的问题。

遗憾的是，可移植性会产生成本。我们发现，要通过特定于环境和特定于设备的专业化维护可移植内核，需要付出与环境/设备数量呈超线性关系的努力。但是，上述成本大部分由我们和我们的姊妹团队承担，因此我们的用户经常看不到这些成本。

模块化和分层

尽管 Sibyl 作为集成产品提供的服务非常有价值，但其结构和界面在某种程度上是整体的，这将其限制为一组特定的“直接”用户，这些用户不得不整体采用此产品。相反，TFX 演化为模块化和分层的架构，随着与其他团队和产品的合作关系不断发展，TFX 的模块化和分层也不断增强。TFX 中值得注意的层（含示例）包括：

层	示例
ML 服务	Cloud AutoML Cloud Recommendations AI Cloud AI Platform Cloud AI Hub Cloud Dataflow Cloud BigQuery
流水线（属于可组合组件）	TensorFlow Extended (TFX)
二进制文件	TensorFlow Serving (TFS)
库	TensorFlow Data Validation (TFDV) TensorFlow Transform (TFT) TensorFlow Hub (TFH) TensorFlow Model Analysis (TFMA) TFX Basic Shared Libraries (TFX_BSL) ML Metadata (MLMD)

TFX 的分层架构使其可以被各种各样的用户使用，无论是通过库以零碎方式和通过流水线以整体方式（使用或不使用相关服务），还是以完全不会被最终用户注意到的方式（例如，使用由 TFX 在后台提供支持的 ML 服务）！

遗憾的是，分层会产生成本。我们发现，维护产品的多个可公开访问的层需要付出的努力与层数大致呈线性关系。有时，上述成本会以令用户困惑哪些层最适合他们的方式转移给这些用户。

多方面的灵活性

与当时的可用替代方案相比，尽管 Sibyl 在建模功能方面更具灵活性，但它在跨 ML 工作流的多个部分的灵活性方面仍不足以满足 Google 对加速全新用例的 ML 的需求，这促进了 TFX 的发展。

Sibyl 仅提供特定种类的数据分析，但 TFX 的 StatisticGen 组件提供了更多内置功能，并且可以通过 TensorFlow Data Validation 实现自定义分析。
Sibyl 仅提供属于纯可组合映射器的转换，但 TFX 的 Transform 组件通过 TensorFlow Transform 提供了更多映射器、自定义映射器、更多分析器、自定义分析器，以及任意组合的（自定义）映射器和（自定义）分析器。
Sibyl 仅提供“宽”模型，但 TFX 的 Trainer 组件提供了可以基于 TensorFlow 实现的任何模型，包括可以通过 TensorFlow Hub 共享和迁移学习的模型。
Sibyl 仅基于“宽”模型提供自动特征交叉（又称特征联合），但 TFX 的 Tuner 组件允许根据最新算法对任意超参数进行优化。
Sibyl 仅提供特定种类的模型分析，但 TFX 的 Evaluator 组件通过 TensorFlow Model Analysis 提供了更多内置指标、自定义指标、置信区间和公平性指标。
Sibyl 的流水线拓扑是固定的（尽管有些可自定义），但 TFX 的 SDK 允许用户创建自定义（可选的容器化）组件，并将它们与标准组件一起在灵活且完全可自定义的流水线拓扑中使用。

TFX
https://tensorflow.google.cn/tfx/guide
公平性指标
https://tensorflow.google.cn/tfx/fairness_indicators

所有这些维度上灵活性的提高都有助于改进实验、扩大范围、增加用例以及加速从研究到生产的流程。

灵活性并非没有成本。更灵活的系统最初更加难以正确实现，而且对于 ML 平台的开发者而言，也更加难以维护和演化。用户可能还必须管理增加的复杂性，因为他们需要利用这种灵活性。此外，我们可能无法基于图灵完备的 ML 平台提供如此强大的支持故事。

我们去往何处

凭借对过去的了解，我们可以大致看到从 2020 年开始的 TFX 未来计划。我们将继续开发 ML 工程，以便使应用 ML 大众化，并帮助每个人实践负责任的 AI 以及以坚持 Google AI 原则的方式来应用它。

TFX 未来计划
https://github.com/tensorflow/tfx/blob/master/RFCs.md
负责任的 AI
https://tensorflow.google.cn/resources/responsible-ai
Google AI 原则
https://ai.google/principles/

推动互操作性和标准发展

为了满足迅速发展的各种 ML 解决方案的需求，我们将继续提高技术的互操作性。我们在互操作性和标准方面的工作以及我们将更多技术开放源代码有助于让每个人都能更轻松地遵循这些做法，这反映了我们“对社会有益”以及“可用于符合这些原则的用途”这两项原则。作为这项使命的一部分，我们将通过开放更多技术的源代码以及实现 ML 构建物和元数据标准化，为业界构建高级 ML 系统提供支持。这项工作的一些精选示例包括：

TFX 标准化输入。
高级 TFX DSL 语义、数据模型和 IR。
ML 构建物和元数据的标准化。
异构运行时环境上的分布式工作任务的标准化。
推断分布式模型和流式传输模型。
改进与移动和边缘 ML 部署互操作性。
改进 ML 框架的互操作性和构建物共享。

提高自动化程度

自动化是可靠生产系统的基础，TFX 在改进和扩展其自动化使用方面投入了大量资源。我们在提高自动化程度方面的工作反映了我们的原则，即确保 ML 部署“以安全方式构建和测试”并“避免造成或加强不公平的偏见”。即将开展的一些工作包括 TFX 流水线测试框架、TFX Tuner 中的自动化模型改进、自动检测多维切片上的意外模型行为、促进模型卡的自动化生产以及改进我们的训练-应用偏差检测功能。GCP 上的 TFX 还将继续推动对相关服务的全新（以及更好地利用现有）高级自动化功能的需求。

加深对 ML 的理解

对 ML 的理解是部署生产 ML 的重要方面，而 TFX 可以在这一领域提供可观的收益。我们在加深对 ML 的理解方面的工作反映了我们的原则，即帮助“避免造成或加强不公平的偏见”，并确保 ML 部署“对人们负责”。对理解至关重要的一点是能够跟踪用于生成模型的构建物的沿袭，而 TFX 将继续在这一领域进行投入。对 TFX 技术（如 struct2tensor）的改进将进一步基于结构化数据实现训练、应用和分析模型，从而使关于模型的推理更接近原始数据语义。此外，我们还计划将 TFX 作为工具来扩展对公平性评估、补救和文档的支持。

坚持高标准和最佳做法

作为扩大 ML 技术的工具，TFX 必须继续“坚持高标准的科学卓越”并推广最佳做法。团队将继续通过我们现有的渠道发表科学论文和开展公众宣传，并与知名机构合作提供教育课程。此外，我们还将通过使用集成的不确定性度量来提高对模型分析工具的信任度，例如，通过对模型指标的置信区间进行可扩展计算，我们将提高训练-应用偏差检测能力。对于研究和生产而言，拥有可重现的 ML 构建物也至关重要，这要归功于我们在为审核与复制模型而进行精确的起源跟踪方面开展的工作。同样重要的一点是测量的再现性，它由像 NitroML 这样的成果推动，将为基准 AutoML 流水线提供工具。

鉴于我们扩展技术的几个领域对我们来说有些陌生，我们将努力区分技术的实际测试和实验性方面，以便使我们的用户有信心选择满足他们的愿望和需求的功能集。

改进工具

尽管 TFX 为 ML 工程的各个方面以及 ML 生命周期的多个阶段提供了工具，但我们认为这仍然是一个新兴领域。虽然改进工具与 TFX 天然契合，但它也反映了我们的原则，即帮助 ML 部署“用于符合这些原则的用途”、“为科学卓越提供支持”以及“以安全方式构建和测试”。

改进的一个方面是将 ML 应用于数据本身，无论是通过感知异常还是在数据中查找模式，或者通过 ML 模型的预测来丰富数据。让大量数据轻松丰富起来（尤其是用于低延迟、高容量操作的关键流式传输数据）一直是一种挑战。将 TFX 功能引入数据处理框架是我们的第一步。我们已经可以用标签来丰富流式传输事件，或者在 Apache Beam 以及通过扩展程序在 Cloud Dataflow 中进行预测。我们计划通过利用预先构建的模型（由 Cloud AI Pipelines 和 TensorFlow Serving 应用）来跟踪这项工作，以便简化在表示来自模型流的预测的分布式数据集中添加新字段的过程。

此外，尽管有许多用于检测、发现与审核 ML 工作流的工具，但仍然需要以自动化（或辅助）方式缓解发现的问题，我们将在这一领域进行投入。例如，根据当前正在执行的流水线（甚至在训练之前）主动预测哪个流水线运行不会生成更好的模型，可以显著减少在创建不良模型上花费的时间和资源。

共同的旅程

构建 TFX 和探索 ML 工程的基本原理是许多人多年来努力的累积。随着我们不断取得进展并进一步发展这一领域，重要的是，我们要意识到这是那些让我们走到今天这一步的前辈的共同努力。

当然，我们将需要更多的合作来驾驭这一领域的未来，因此，我们邀请您与我们携手，一同“迈向 ML 工程”！

TFX 团队

TFX 项目是 Google 内部多个组织协作来实现的。尽管我们技术的可移植部分有许多重叠之处，但不同的组织通常关注不同的技术和产品层。总体而言，我们认为自己是一个单独的团队，我们在下面按字母顺序列出了目前的 TFX 团队成员，这些成员对 TFX 的构想、研究、设计、实现、执行、部署、管理和宣传等做出了贡献；他们不断地相互启发、帮助、教导和挑战，旨在推动这一领域的发展：

Abhijit Karmarkar、Adam Wood、Aleksandr Zaks、Alina Shinkarsky、Alkis Polyzotis、Amy Jang、Amy McDonald Sandjideh、Amy Skerry-Ryan、Andrew Audibert、Andrew Brown、Andy Lou、Anh Tuan Nguyen、Anirudh Sriram、Anna Ukhanova、Anusha Ramesh、Archana Jain、Arun Venkatesan、Ashley Oldacre、Baishun Wu、Ben Mathes、Billy Lamberta、Chandni Shah、Chansoo Lee、Chao Xie、Charles Chen、Chi Chen、Chloe Chao、Christer Leusner、Christina Greer、Christina Sorokin、Chuan Yu Foo、CK Luk、Connie Huang、Daisy Wong、David Smalling、David Zats、Dayeong Lee、Dhruvesh Talati、Doojin Park、Elias Moradi、Emily Caveness、Eric Johnson、Evan Rosen、Florian Feldhaus、Gal Oshri、Gautam Vasudevan、Gene Huang、Goutham Bhat、Guanxin Qiao、Gus Katsiapis、Gus Martins、Haiming Bao、Huanming Fang、Hui Miao、Hyeonji Lee、Ian Nappier、Ihor Indyk、Irene Giannoumis、Jae Chung、Jan Pfeifer、Jarek Wilkiewicz、Jason Mayes、Jay Shi、Jiayi Zhao、Jingyu Shao、Jiri Simsa、Jiyong Jung、Joana Carrasqueira、Jocelyn Becker、Joe Liedtke、Jongbin Park、Jordan Grimstad、Josh Gordon、Josh Yellin、Jungshik Jang、Juram Park、Justin Hong、Karmel Allison、Kemal El Moujahid、Kenneth Yang、Khanh LeViet、Kostik Shtoyk、Lance Strait、Laurence Moroney、Li Lao、Liam Crawford、Magnus Hyttsten、Makoto Uchida、Manasi Joshi、Mani Varadarajan、Marcus Chang、Mark Daoust、Martin Wicke、Megha Malpani、Mehadi Hassen、Melissa Tang、Mia Roh、Mig Gerard、Mike Dreves、Mike Liang、Mingming Liu、Mingsheng Hong、Mitch Trott、Muyang Yu、Naveen Kumar、Ning Niu、Noah Hadfield-Menell、Noé Lutz、Nomi Felidae、Olga Wichrowska、Paige Bailey、Paul Suganthan、Pavel Dournov、Pedram Pejman、Peter Brandt、Priya Gupta、Quentin de Laroussilhe、Rachel Lim、Rajagopal Ananthanarayanan、Rene van de Veerdonk、Robert Crowe、Romina Datta、Ron Yang、Rose Liu、Ruoyu Liu、Sagi Perel、Sai Ganesh Bandiatmakuri、Sandeep Gupta、Sanjana Woonna、Sanjay Kumar Chotakur、Sarah Sirajuddin、Sheryl Luo、Shivam Jindal、Shohini Ghosh、Sina Chavoshi、Sydney Lin、Tanya Grunina、Thea Lamkin、Tianhao Qiu、Tim Davis、Tris Warkentin、Varshaa Naganathan、Vilobh Meshram、Volodya Shtenovych、Wei Wei、Wolff Dobson、Woohyun Han、Xiaodan Song、Yash Katariya、Yifan Mai、Yiming Zhang、Yuewei Na、Zhitao Li、Zhuo Peng、Zhuoshu Li、Ziqi Huang、Zoey Sun、Zohar Yahav

谢谢大家！

TFX 团队（延伸）

除了目前的 TFX 团队成员外，Alphabet 的内部和外部还有许多协作者，他们的讨论、技术以及直接和间接贡献对我们的旅程产生了重大影响。我们在下面按字母顺序列出了这些协作者：

Abdulrahman Salem、Ahmet Altay、Ajay Gopinathan、Alexandre Passos、Alexey Volkov、Anand Iyer、Andrew Bernard、Andrew Pritchard、Chary Aasuri、Chenkai Kuang、Chenyu Zhao、Chiu Yuen Koo、Chris Harris、Chris Olston、Christine Robson、Clemens Mewald、Corinna Cortes、Craig Chambers、Cyril Bortolato、D. Sculley、Daniel Duckworth、Daniel Golovin、David Soergel、Denis Baylor、Derek Murray、Devi Krishna、Ed Chi、Fangwei Li、Farhana Bandukwala、Gal Elidan、Gary Holt、George Roumpos、Glen Anderson、Greg Steuck、Grzegorz Czajkowski、Haakan Younes、Heng-Tze Cheng、Hossein Attar、Hubert Pham、Hussein Mehanna、Irene Cai、James L. Pine、James Pine、James Wu、Jeffrey Hetherly、Jelena Pjesivac-Grbovic、Jeremiah Harmsen、Jessie Zhu、Jiaxiao Zheng、Joe Lee、Jordan Soyke、Josh Cai、Judah Jacobson、Kaan Ege Ozgun、Kenny Song、Kester Tong、Kevin Haas、Kevin Serafini、Kiril Gorovoy、Kostik Steuck、Kristen LeFevre、Kyle Weaver、Kym Hines、Lana Webb、Lichan Hong、Lukasz Lew、Mark Omernick、Martin Zinkevich、Matthieu Monsch、Michel Adar、Michelle Tsai、Mike Gunter、Ming Zhong、Mohamed Hammad、Mona Attariyan、Mustafa Ispir、Neda Mirian、Nicholas Edelman、Noah Fiedel、Panagiotis Voulgaris、Paul Yang、Peter Dolan、Pushkar Joshi、Rajat Monga、Raz Mathias、Reiner Pope、Rezsa Farahani、Robert Bradshaw、Roberto Bayardo、Rohan Khot、Salem Haykal、Sam McVeety、Sammy Leong、Samuel Ieong、Shahar Jamshy、Slaven Bilac、Sol Ma、Stan Jedrus、Steffen Rendle、Steven Hemingray、Steven Ross、Steven Whang、Sudip Roy、Sukriti Ramesh、Susan Shannon、Tal Shaked、Tushar Chandra、Tyler Akidau、Venkat Basker、Vic Liu、Vinu Rajashekhar、Xin Zhang、Yan Zhu、Yaxin Liu、Younghee Kwon、Yury Bychenkov、Zhenyu Tan

谢谢大家！

— 推荐阅读 —

了解更多请点击 “阅读原文” 访问官网。

分享 💬 点赞 👍 在看 ❤️

以“三连”行动支持优质内容！

登录查看更多