软件工程作为一门学科，在过去 50 多年中不断成熟。现代世界高度依赖软件工程，因此软件工程的日益成熟是必然趋势。测试和可靠技术等实践帮助软件工程变得足够可靠，足以支撑行业的构建。与此同时，机器学习 (ML) 在过去 20 多年中也取得了长足发展。机器学习越来越多地用于研究、实验和生产工作负载。现在，机器学习已成为我们生活中不可或缺的广泛使用的产品的重要动力。
但是，机器学习工程作为一门学科，并没有像其软件工程祖先那样广泛成熟。我们能否借鉴经验，帮助应用机器学习这一新兴领域像编程发展为软件工程一样，发展为机器学习工程呢？
在本文中，我们将简要介绍Sibyl 和 TensorFlow Extended (TFX)，这是 Alphabet 的两个连续端到端 (E2E) 机器学习平台。我们将分享从基于这些平台构建的十多年应用机器学习中汲取的经验教训，解释它们之间的相似之处和不同之处，并阐述帮助我们完成这一旅程的思维和技术转变。此外，我们将重点介绍 TFX 的一些功能，这些功能有助于实现机器学习工程的多个方面。我们认为，为了释放机器学习所能带来的收益，组织应通过投资稳健的机器学习基础设施和推动机器学习工程教育来提高其机器学习团队的成熟度。我们还建议，产品负责人应在专注于尖端的机器学习建模技术之前，投入更多时间在组织中采用互操作的机器学习平台。最后，我们将展望 TFX 的未来。
在过去十年中，应用机器学习一直是谷歌产品和服务的组成部分，并且随着时间的推移，它变得越来越重要。从我们努力将机器学习应用于生产的过程中，我们很早就发现，虽然机器学习算法很重要，但它们通常不足以实现机器学习在产品中的成功应用。特别是，端到端机器学习平台可以帮助机器学习生命周期的所有方面，通常需要它们来加速机器学习的采用，并使其使用持久且可持续。
端到端机器学习平台在谷歌并非新鲜事物。Sibyl 成立于 2007 年，是一个支持大规模机器学习的平台，面向生产使用。Sibyl 在“广泛”模型（线性、逻辑、泊松回归以及后来的分解机）的基础上提供了相当多的建模灵活性，并与非线性变换以及可定制的损失函数和正则化相结合。重要的是，Sibyl 还为机器学习工作流程的多个方面提供工具，包括数据摄取、数据分析和验证、训练（当然）、模型分析和训练服务偏差检测。所有这些都打包成一个单一集成产品，允许进行迭代实验。这种全面的产品供应以及 Sibyl 团队以用户为中心的理念使得 Sibyl 一度成为谷歌使用最广泛的端到端机器学习平台之一。Sibyl 现已停用。它运行了大约 14 年，其绝大多数工作负载已迁移到 TFX。
虽然我们中的许多人仍在开发 Sibyl，但机器学习算法领域正在发生一场重大变革，深度学习 (DL) 正在普及。2015 年，谷歌公开发布了 TensorFlow（它本身是之前名为DistBelief 的系统的继任者）。自成立以来，TensorFlow 一直支持各种应用，重点是深度学习训练和推理。其灵活的编程模型使其能够用于比深度学习更多的事情，并且它在研究和生产中的流行程度使其成为编写机器学习算法的通用语言。虽然 TensorFlow 提供了灵活性，但它缺少一个完整的端到端生产系统。另一方面，Sibyl 具有强大的端到端功能，但缺乏灵活性。很明显，我们需要一个针对 TensorFlow 的端到端机器学习平台，以便在谷歌加速机器学习；在 Sibyl 诞生近十年后的 2017 年，我们在谷歌内部推出了 TFX。TFX 现在是 Alphabet（包括谷歌）使用最广泛的通用端到端机器学习平台。
自推出以来，TFX 在三年内帮助 Alphabet 实现了一种被称为“工业规模”的机器学习：TFX 被 Alphabet 内部的数千名用户使用，并支持数百种流行的 Alphabet 产品，包括 Google Cloud Platform (GCP) 上的 Cloud AI 服务。在任何一天，都有数千个 TFX 管道运行，处理着艾字节级数据，并生成数万个模型，这些模型又以每秒数亿次的速率执行着数百万次推理。TFX 的广泛采用帮助 Alphabet 实现研究到生产的流程，并为直接和间接 TFX 用户提供各种各样的用例。这种广泛的采用还使团队能够专注于模型开发，而不是机器学习平台开发，从而使机器学习更易于应用于新产品领域，并创造了机器学习平台从机器学习应用中演进的良性循环。
基于我们内部的成功，以及我们对世界各地组织和个人都需要类似机器学习工程的预期，我们决定公开描述 TFX 在谷歌内部的设计和初始部署，并逐步使我们的更多经验和技术公开可用（包括开源），同时我们继续构建更多内容。我们之所以能够做到这一点，部分原因是像 Sibyl 一样，TFX 建立在强大的基础设施依赖项之上。例如，Sibyl 充分利用了MapReduce 及其继任者Flume 来进行分布式数据处理，而现在 TFX 大量使用了它们的便携式继任者Apache Beam 来执行相同操作。
在 TensorFlow 的步伐下，公共 TFX 产品 于 2019 年初发布，并在不到一年的时间里被广泛采用，包括在内部部署和 GCP 上与Cloud AI Platform Pipelines 一起使用。我们的一些合作伙伴也公开了他们使用 TFX 支持的用例，包括 TFX 如何从根本上提高了他们的应用机器学习速度。
虽然谷歌的机器学习平台演进旅程漫长而激动人心，但我们预计大部分激动人心的时刻还在后面！为此，我们想分享我们的一些经验，其中一些比其他一些经验更痛苦。这些经验可以分为两类，即演进过程中保持不变的部分，以及发生变化的部分，以及它们发生变化的原因！我们将在两个连续平台 Sibyl 和 TFX 的背景下介绍这些经验教训，但我们相信它们具有广泛的适用性。
本节中讨论的领域包含了一些似乎持久且经受时间考验的事例。因此，我们预计这些内容在未来也将在机器学习平台和框架的不同版本中适用。我们将从应用机器学习的角度和基础设施的角度看待这些内容。
将机器学习成功应用于产品本身就是一门学科。它涉及一个陡峭的学习曲线，需要进行一些思维模型的转变（或者可能是增强）。为了使这项具有挑战性的任务更容易，我们公开了机器学习的规则。这些规则代表了将机器学习迭代应用于谷歌众多产品的经验教训。值得注意的是，机器学习在谷歌产品的应用说明了常见的演变
我们发现机器学习规则在不同平台和时间跨度上都非常稳固，我们希望它们能像对我们和我们的用户一样，对其他人也有价值。特别是，我们相信遵循这些规则将帮助其他人更擅长机器学习工程这一学科，包括帮助他们避免我们和我们的用户过去犯过的错误。TFX 试图将这些规则（实际上）用代码来编纂。我们希望能够从中获益，但也希望推动整个行业以更有效的方式进行机器学习。
在开发机器学习规则的过程中，我们意识到，构建健壮系统的学科，其中核心逻辑是由涉及代码和数据的复杂过程产生的，需要比软件工程提供的更多审查。因此，我们将机器学习工程定义为软件工程学科的超集，旨在处理机器学习实际应用中独特的复杂性。
试图总结机器学习工程学科的全部内容将是相当困难的，如果不是不可能的话，特别是考虑到我们对它的理解仍然有限，而且学科本身还在不断发展。不过，我们还是从以下几点中得到了一些慰藉
我们早期的认识如下：在机器学习中，工件是与生产和消费它们的流程同等重要的第一类公民。
这一认识影响了 Sibyl 的实现和发展；当我们公开写关于它的时候，它已经深深地植根于 TFX 中，最终在机器学习元数据中得到了概括和形式化，现在为 TFX 提供支持。
下面我们将介绍机器学习工程的基本要素，一些机器学习工件及其第一类公民身份的例子，并尝试尽可能地与软件工程进行类比。
数据就像代码是软件的核心一样，数据是机器学习的核心。数据管理代表了生产机器学习中严峻的挑战。也许最简单的类比是考虑什么是数据的单元测试。单元测试通过测试相关代码的契约并为这些契约灌输可信度，来验证对代码行为的预期。类似地，对数据的形式（包括其模式、不变性和值分布）设定明确的预期，并检查数据是否符合嵌入在训练代码中的隐式预期，这两者结合起来可以使数据足够可信，可以使用它来训练模型。尽管单元测试可以是详尽的并验证强契约，但数据契约通常要弱得多，即使它们是必要的。尽管单元测试可以由人类详尽地使用和验证，但数据通常只有在总结形式下才能对人类有意义。
就像代码仓库和版本控制是软件工程中管理代码演变的支柱一样，数据演变和理解管理系统是机器学习工程的支柱。
TFX 的 ExampleGen、StatisticsGen、SchemaGen 和 ExampleValidator 组件帮助人们将数据视为第一类公民，通过在（连续）机器学习管道中进行数据管理、分析和验证来实现这一点。
模型就像软件工程师会生成被编译成程序的代码一样，机器学习工程师会生成被“编译”成机器学习程序的数据和代码，这些程序更常被称为模型。然而，这两种程序的本质却截然不同。虽然软件生成的程序通常具有强契约，但模型的契约要弱得多。这些弱契约通常是统计性质的，因此只能在某种总结形式中进行验证（例如，模型在标记数据子集上具有足够的准确性）。这并不令人惊讶，因为模型是代码和数据的产物，而数据本身没有强契约，而且也只在总结形式下才能被消化。
就像代码和数据会随着时间的推移而演变一样，模型也会随着时间的推移而演变。但是，模型演变比其组成代码和数据的演变要复杂得多。例如，高测试覆盖率（使用模糊测试）可以很好地保证一段代码的正确性和正确演变，但模型评估的分布外和反事实但现实的数据却很难生成。
就像将多个程序整合到一个系统中需要集成测试，而集成测试是软件工程的支柱一样，将代码和数据整合在一起需要端到端的模型验证和理解，这是机器学习工程的支柱。
TFX 的 Evaluator 和 InfraValidator 组件提供模型的验证和理解，将它们视为机器学习工程的第一类公民。
可合并的片段就像软件工程师将预先存在的库（或系统）与他们的代码合并在一起以构建有用的程序一样，机器学习工程师会定期将代码片段、数据片段、分析片段和模型片段合并在一起以构建有用的机器学习管道。软件工程和机器学习工程之间的一个显著区别是，即使代码对于后者来说是固定的，数据对于后者来说通常是易变的（例如，新数据会定期到达），因此下游工件需要频繁且有效地生成。例如，如果模型的任何输入数据部分发生了变化，通常需要生成模型的新版本。因此，机器学习管道生成可合并的工件非常重要。例如，一个数据集的统计摘要应该很容易与另一个数据集的统计摘要合并，以便轻松地对这两个数据集的联合进行统计摘要。同样，应该很容易将一个模型的学习成果转移到另一个模型，特别是将之前版本模型的学习成果转移到同一模型的下一个版本。
但是，这里有一个问题，这与之前关于模型测试覆盖率等效性的讨论有关。将新的片段合并到模型中可能会需要创建新的分布外和反事实评估数据，这会导致（有效）模型演变的难度增加，因此比纯粹的代码演变要难得多。
TFX 的 ExampleGen、Transform、Trainer 和 Tuner 组件，以及 TensorFlow Hub，帮助人们将工件视为第一类公民，通过在执行数据缓存、分析器缓存、热启动和迁移学习的工作流中生成和使用可合并的片段来实现这一点。
工件血统尽管软件工程存在所有先进的方法和工具，但构建的程序和系统仍然需要调试。机器学习程序也是如此，但调试它们却难得多，因为由于涉及大量的工件，机器学习程序的非近端效应要普遍得多。模型可能由于来自多个错误来源的错误工件而导致不准确，包括代码缺陷、学习算法、训练数据、服务路径或服务数据，仅举几例。就像堆栈跟踪对于识别软件程序缺陷的根本原因至关重要一样，机器学习管道生成和使用的所有工件的血统对于识别机器学习模型缺陷的根本原因至关重要。此外，通过了解哪些下游工件是从有问题的工件中生成的，我们可以识别所有受影响的系统和用户，并采取缓解措施。
TFX 使用 机器学习元数据 (MLMD) 帮助将工件视为第一类公民。MLMD 支持对与工件相关的元数据和血统进行高级目录编制和查询，这两者结合起来可以提高在管道边界之外共享工件的信心。MLMD 还帮助进行高级调试，并且与底层数据存储层结合使用时，构成了 TFX 机器学习合规机制的基础。
持续学习和遗忘机器学习生产管道在动态环境中运行
当发生变化时，管道需要做出反应，通常是在新环境中重新运行其步骤。这种动态性增加了血统跟踪的重要性，以便促进调试和根本原因分析。例如，为了调试模型故障，不仅需要知道用来训练模型的数据，还需要知道建模代码和任何周围基础设施的版本。
机器学习管道还必须支持低摩擦机制来处理这些变化。例如，考虑新数据的到来，这需要重新训练模型。这是在快速变化的环境（如推荐系统或对抗性系统）中的一项自然需求。考虑到数据可能会以规律和频繁的速率到达，要求用户手动重新训练模型可能不切实际。相反，我们可以通过“持续训练”来采用自动化，其中管道检测到新数据的出现，并自动安排生成更新的模型。反过来，此功能需要自动执行：根据工件（包括数据）的存在情况安排工作，从间歇性故障中恢复，并在恢复时赶上实时数据。机器学习管道通常会运行数年，不断摄取代码和数据，并持续生成模型，这些模型会做出预测，从而影响决策。
低摩擦机制的另一个例子是支持机器学习管道的“回填”。在这种情况下，用户可能需要使用更新版本的组件在现有工件上重新运行管道，例如使用建模代码/库的新版本在现有数据上重新运行训练器。回填的另一个用途是在现有数据的新版本上重新运行管道，例如，修复数据中的错误。这些回填与持续训练是正交的，可以一起使用。例如，用户可以手动触发训练器重新运行，然后生成的模型工件可以自动触发模型评估和验证。
TFX 从一开始就以一种支持持续学习（和遗忘）的方式构建，从根本上塑造了它的设计。与此同时，这些先进的功能也允许它以“一次性”、非连续的方式使用。事实上，在 Alphabet 内部，这两种部署模式都被广泛使用。此外，TFX 还支持不同类型的回填操作，以便在正常的管道执行过程中进行细粒度的干预。
即使公开的 TFX 产品尚未提供持续的机器学习管道，我们也正在积极努力使我们现有的技术可移植，以便可以将其公开发布（例如RFC）。
实现雄心勃勃的目标需要建立在坚实的基础之上，与他人合作，利用彼此的工作。TFX 重新利用了 Sibyl 的许多系统设计，这些设计经过了十年 Sibyl 生产机器学习经验的磨练。此外，TFX 在出现健壮标准的领域中整合了新技术
在出现稳健标准的依赖项时，TFX 及其用户能够实现无缝的性能和可扩展性。它还使 TFX 能够专注于构建应用 ML 所需的差异，而不是重新实现难以正确实现的技术。我们的一些依赖项，例如 Kubeflow Pipelines 或 Apache Airflow，是由 TFX 的用户在他们从中获得的价值/功能超过额外依赖项带来的成本时自行选择的。
采用依赖项会带来成本。我们发现，采用依赖项需要付出的努力与依赖项数量成超线性关系。这些成本通常由我们和我们的姐妹团队承担，但可能会（有时确实会）泄漏给我们的用户，通常表现为冲突的（版本）依赖项或环境与依赖项之间的不兼容性。
ML 平台并非孤立运作。它们在更大的系统或基础设施的上下文中运行，连接到上游的数据生产源和下游的模型消费接收器，而这些接收器又经常会生成馈送到 ML 平台的数据，从而闭合循环。平台的广泛采用通常需要与环境中的其他重要技术进行互操作。
互操作性需要一定程度的抽象和标准化，通常会产生“1+1>2”的效果。TFX 既是这种互操作性产生的正外部性的受益者，也是贡献者，无论是在 Alphabet 内部还是外部。TFX 的用户也是互操作性的受益者，因为他们可以更轻松地在现有的安装基础之上部署和使用 TFX。
互操作性也会带来成本。多个技术堆栈的组合会导致指数级的不同部署配置。虽然我们对一些不同的部署配置进行了端到端的规模测试，例如 TFX on GCP，但我们既没有专业知识，也没有资源来针对所有可能的部署选项的组合爆炸进行测试。因此，我们 鼓励社区与我们合作，完成对他们最有用的部署配置。
本节讨论的领域涵盖了为了使我们的 ML 平台适应新现实并因此保持有用和有影响力而需要更改的一些事项的示例。
Sibyl 是一个大型规模 ML 平台，旨在部署在 Google 的大型规模集群上，即 Borg。这很有道理，因为 Google 的应用 ML 最初主要用于广泛使用的产品中。随着全球范围内 ML 专家队伍的壮大和 ML 可以应用于 Google 内部和外部环境中更多（大大小小的）用例，可移植性的需求逐渐但肯定地成为一个硬约束。
TFX 的可移植性使其能够在各种环境和设备中使用，以解决从小型规模到大型规模的问题。
不幸的是，可移植性也会带来成本。我们发现，维护一个具有环境特定和设备特定特性的可移植核心需要付出的努力与环境/设备数量成超线性关系。然而，这些成本在很大程度上由我们和我们的姐妹团队承担，因此用户通常不会注意到。
尽管 Sibyl 作为集成产品的产品具有巨大价值，但其结构和接口在某种程度上是单体的，将其限制在必须整体采用它的特定“直接”用户。相反，TFX 演变为一个模块化和分层架构，并且随着与其他团队和产品的合作关系的增长，它变得更加模块化。TFX 中值得注意的层（以及示例）包括
| 层 | 示例 |
| ML 服务 | |
| 管道 （可组合组件的） |
|
| 二进制文件 |
|
| 库 |
|
TFX 的分层架构使其能够被各种各样的用户使用，无论是通过其库逐块使用，还是通过其管道整体使用（是否使用相关服务），还是以对最终用户完全透明的方式使用（例如，通过他们使用 TFX 在幕后支持的 ML 服务）！
不幸的是，分层也会带来成本。我们发现，维护产品的多层公开访问层需要付出的努力与层数大致成线性关系。这些成本偶尔会以用户对哪个层最适合他们使用的困惑的形式泄漏给用户。
尽管 Sibyl 在建模能力方面比当时可用的替代方案更灵活，但其在 ML 工作流的多个部分中的灵活性的某些方面未能满足 Google 加速新用例 ML 的需求，从而导致了 TFX 的开发。
所有这些方面灵活性的提高都促进了改进的实验、更广泛的覆盖范围、更多用例，以及从研究到生产的加速流程。
灵活并非没有成本。更灵活的系统是一个一开始就更难正确实现的系统，并且对于我们来说，作为 ML 平台的开发人员，它也更难维护和发展。用户在利用这种灵活性时也可能需要管理更多复杂性。此外，我们可能无法在对图灵完备的 ML 平台提供像以前一样强大的支持故事。
有了过去经验的积累，我们对 未来计划 做出了一些展望，即 2020 年的 TFX 未来。我们将继续努力实现 ML 工程，以使应用 ML 民主化，并帮助每个人练习 负责任的 AI 并以维护 Google AI 原则 的方式应用它。
为了满足对不断涌现的各种 ML 解决方案的需求，我们将继续提高技术的互操作性。我们对互操作性和标准化以及开源我们更多技术的工作，反映了我们“对社会有益”以及“可用于符合这些原则的用途”的原则，使每个人更容易遵循这些实践。作为这项使命的一部分，我们将通过开源我们更多的技术，以及通过标准化 ML 工件和元数据，来赋能行业构建高级 ML 系统。这项工作的一些精选示例包括
自动化是可靠生产系统的支柱，TFX 致力于改进和扩展其自动化使用。我们在提高自动化方面的工作反映了我们的原则：帮助 ML 部署“为安全而构建和测试”以及“避免创造或强化不公平的偏见”。一些即将推出的工作包括 TFX 管道测试框架，TFX Tuner 中的自动模型改进，自动检测多维切片上的意外模型行为，促进自动生成模型卡，以及改进我们的训练服务偏差检测能力。TFX on GCP 还将继续推动对新自动化功能的需求（以及更好地利用现有功能）的需求，这些功能是相关服务的必要组成部分。
ML 理解是部署生产 ML 的重要方面，TFX 处于有利位置，可以在这个领域取得显著的进步。我们关于改进 ML 理解的工作反映了我们的原则，即帮助“避免创造或强化不公平的偏见”并帮助 ML 部署“对人们负责”。理解的关键是能够跟踪用于生成模型的工件的谱系，这是 TFX 将继续投入的领域。对struct2tensor 等 TFX 技术的改进将进一步使训练、服务和分析结构化数据上的模型成为可能，从而允许对更接近原始数据语义的模型进行推理。我们还计划利用 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 项目是通过 Google 内部多个组织的协作实现的。不同的组织通常专注于不同的技术和产品层，尽管我们的技术中有很多可移植部分存在重叠。总的来说，我们认为自己是一个团队，下面列出了当前 TFX 团队成员的字母排序列表，他们为 TFX 的构思、研究、设计、实现、执行、部署、管理和宣传（仅举几例）做出了贡献；他们不断激励、帮助、教学和挑战彼此以推动我们领域的发展。
Abhijit Karmarkar、Adam Wood、Aleksandr Zaks、Alina Shinkarsky、Neoklis 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 团队成员之外，还有许多来自 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
谢谢大家！
2020 年 9 月 25 日 — 由Konstantinos (Gus) Katsiapis 代表 TFX 团队发布 目录摘要我们来自何处Sibyl (2007 - 2020)TFX (2017 - ?)来自我们 10 多年 ML 平台演变之旅的教训保持不变的原因不同的原因我们要去哪里推动互操作性和标准提高自动化改善 ML 理解坚持高标准和最佳实践Impr…
