构建企业级 AI 平台的架构策略和实践
李欣约 17 分钟整个内容主要分为三个部分。第一部分是关于 eBay 在机器学习方面的用例介绍，包括用例分类和对平台的要求；第二部分是关于 eBay 平台的架构和核心能力，以及一些重要的设计。第三部分是关于数据平台上的机器学习能力，数据策略对应用落地和时间的重要性，因此会重点介绍统一的数据策略。
eBay 机器学习平台应用实践
最近几年，机器学习模型在各个业务领域得到广泛应用，特别是在处理不同类型的数据方面。数据的分类对于模型学习至关重要，其中最主要的区分是结构化数据、非结构化数据和半结构化数据。
结构化数据指的是具有明确定义和组织的数据，而非结构化数据指的是没有固定格式和组织的数据，半结构化数据则介于两者之间。eBay 的主要数据来源于用户提交的内容，以图片为例。一旦用户提交了图片，我们首先会使用一些模型对其进行美化处理，如高亮或背景消除等。
接着，我们会对图片进行合规性审查，检查是否涉及违禁品、色情内容等。然后，我们会使用一个统一的数据获取管道，通常是一个流式处理过程，对所有图片进行集中处理。这个处理过程包括进行光学字符识别（OCR），即识别图片中的文字，并对前面提到的多模态或多媒体内容进行 embedding。
针对这些嵌入式 embedding，我们可以使用流式处理的方式将其进行索引，以便在实时情况下进行查询。这种索引在广告推广和搜索等方面有广泛的应用。这些模型需要在离线环境下进行训练，因此我们需要建立一条链路，将流式处理的结果最终落地到离线的内容存储（content storage）中。在这一阶段，当我们要对这些模型进行训练时，我们会生成一些标签。这些标签可以通过与第三方购买或进行一些人工努力进行标注，或者使用自动化的标注方法。
一旦我们有了这些标签，我们就可以开始训练模型。但对于一些计算机视觉（CV）模型来说，数据清洗完成后，可能面临着大量的数据。如果要充分利用 GPU 的性能，需要在大数据平台上拥有高效的数据混洗、预处理和访问能力。
对于结构化数据（structured data）的应用场景非常广泛，比如风险控制、支付风控、推广推荐和市场营销等。在很多使用情况中，如风险控制，有三个主要的模型：欺诈检测、团伙作案检测和账号盗窃检测。这些模型都是基于结构化数据进行建模和分析。
与非结构化数据不同，结构化数据具有一些独特的特点，首先是特征工程方面的差异。在结构化数据中，需要进行一些特征工程的处理。在这个过程中，首先需要考虑数据源的问题。数据源可以来自三个部分：离线数据、ETL 以及数据仓库。第二部分涉及到流式数据（streaming）。离线特征的延迟较长，可能需要一天或一周的时间，因此数据的新鲜度并不好。而流式数据完全不同，它以流式方式传输，延迟时间非常短，可以使得特征的新鲜度非常高。此外，如果离线特征无法满足需求，可能需要调用在线服务来获取一些新的数据作为特征，并将其作为模型的输入。
面临的重要挑战是构建统一的特征存储。其核心问题在于，当你在离线环境中获取特征时，如何确保在线环境中在同一时刻看到的数值是一致的。
另一个重要方面是"point in time"（时点）和"feedback loop"（反馈循环），它们非常有意思且特别。"Feedback loop"指的是模型、标记或反馈的集成方式。对于长反馈循环和短反馈循环，对平台的要求也不同。
短反馈循环如网页推荐，可以迅速收集用户的搜索、点击和购买行为，并通过快速的反馈迭代模型。然而，某些反馈循环可能较长，例如风险支付，因为需要等待用户投诉并处理投诉，这可能需要数月甚至半年的时间。对于这种情况，模型的迭代和验证就变得困难，因此在上线之前，可以通过离线环境的模拟来确保离线和在线的结果基本一致。
对于 GPU 来说，平台可以提供更多的优化选项，因为不同模型的执行情况可能存在差异。例如，在量化操作方面，整个模型的性能可能会提高数倍。另外，某些模型可能包含 CPU 和 GPU 两部分，根据使用场景的不同，对吞吐量或延迟的关注程度也会有所不同。平台应该能够智能地提供部署优化策略。
在构建这样一个平台时，首先是要明确平台解决方案和平台本身的边界。我们应该以目标为导向，而不是过分追求可重用性。如果我们过于关注业务驱动的解决方案，可能会限制平台的能力。因此，我们需要明确平台和解决方案之间的边界，确定适当的边界。
此外，平台的自助服务成熟度也是需要考虑的问题。如果平台一直需要人员介入、沟通并提供大量帮助来支持解决方案，而没有实现自助服务，那么平台的扩展性就会受到限制，说明平台的自助服务成熟度还不够。
传统的 AI 平台和机器学习平台更多地关注于训练方面，但在企业级应用中，它们需要将关注点扩展到特征工程、推理和监控等方面。所有这些方面都需要进行无缝集成，整个过程应该是连贯的，而不是断断续续的。平台应该提供支持，使这些方面能够无缝集成，确保整个流程的连贯性。
在机器学习用例的生命周期中，解决方案和平台有不同的关注点。解决方案首先面临业务问题，需要定义问题、确定指标和衡量标准，并评估数据的可用性。他们进行训练时可能需要工程师的帮助来进行量化和优化，并考虑模型集成和调整策略，确保模型上线后符合预期并了解其对业务的影响。解决方案还关注自动化特征重新训练。
机器学习平台（MLP）则专注于解决训练、特征工程、数据和部署等方面的问题。平台的目标是实现自助服务，让所有参与机器学习的人能够快速创建、训练和部署模型，并进行有效的管理。为了建设这样的平台，需要确定核心能力和规划，包括建设数据目录和特征目录。特征平台负责处理特征的生命周期，包括发现、重用和创建特征，并通过 API 提供统一的数据管理、特征交叉、训练和推断服务。
平台通过 API 不仅可以通过 AI Web Portal 操作，还可以与其他领域的自定义 Portal 集成。在训练方面，标注任务通常由解决方案负责，平台需要支持自动创建训练集、监控数据分布，并与训练流水线进行无缝集成。平台还需要管理参数化、实验性能和优化建议等训练相关任务。
训练完成后，模型及其规范需要注册到模型管理服务中，并记录使用的特征和相关 API。由于所有特征由平台管理，推断 API 的请求和响应格式可以自动生成。这些操作和管理任务由平台的三个子平台管理服务支持。
架构、核心能力及重要设计
我们的机器学习平台的目标是使所有参与者能够以自服务的方式快速创建、训练和部署模型。平台具有强大的管理功能，确保可扩展性和可靠性，从而实现快速的上线和缩短上市时间。为了构建这样的平台，我们需要明确核心能力和规划。
在构建机器学习平台时，首先需要关注数据源和数据目录。数据目录包括了哪些数据，并且我们还需要构建特征目录。通过特征目录，我们可以发现已有的特征并确定是否可以重用，或者是否需要创建新的特征。在特征的整个生命周期中，我们希望最大限度地避免重复创建特征，而是利用已有的特征进行重叠。
当我们创建新特征时，我们需要考虑如何部署和发布它，以便与模型实现无缝集成。特征平台会通过 API 提供相应的操作和服务，包括元数据的交叉比较、特征交叉、训练和模型推断等。这些操作都是集中化管理的，确保平台的统一性，而不是分散的。
我们的机器学习平台通过 API 的方式提供灵活性，不仅限于 AI 的 Web 门户。对于某些领域，可能存在大量的用例，它们可以选择自己构建自己的门户，但通过 API 集成，避免了重复工作。对于训练来说也是如此，尽管标签可能不是我们的主要责任，而是由解决方案团队负责。一旦有了标签，我们需要自动创建训练数据集，管理数据分布的可见性，并实现与训练流程的无缝集成，包括调整建议的优化。训练还涉及参数化和实验性能的管理，这些都应该得到有效的管理。
在训练之后，训练得到的模型规范将被注册到我们的模型管理服务中，并记录所使用的特征。由于这些特征都是被管理的，因此可以根据模型规范中的特征列表自动生成推断 API 的数据源，而无需用户定义。这些操作和知识支持都由这三个子平台的管理服务提供。
设计原则的重点是"centralize conversion management"，这对平台来说非常重要。它需要包括有效的治理和自动化，这是建立在集中冲突管理设计的基础上的。此设计还应该使自助服务成为可能。此外，数据策略也是必不可少的，特别是在 API 集成方面，应避免通过库进行集成。
API 集成的好处是，在进行升级或添加新功能时，用户不会察觉到变化，无需提供额外的支持。良好的治理体系可以通过目录实现，因为用户需要一个良好的目录来进行数据发现、探索、特征重用或模型解决方案重用。此外，数据血缘也非常重要，因为我们需要知道依赖的特征是否可信、它们依赖的源数据是什么，以及如何对其进行探索以评估数据质量是否符合要求。另外，我们还需要了解特征是否已被大量其他模型使用，如果是这样，那么我们可以认为该特征的质量得到了认可。因此，数据血缘也是非常重要的。
最后，还有监控和报警功能，它们也是非常重要的。
整个架构中，左边是控制域，右边是数据，所有操作都通过 API 进行控制。例如，发布特征定义、模拟和部署模型等操作都通过 API 和最小服务进行。数据计划方面，我们有网关服务来屏蔽部署的复杂性，并提供统一的终端供用户调用。
每个模型推理服务会调用在线特征存储，其中在线特征存储是由 AI 平台管理的。如果某个特征不在 AI 平台的特征存储中，而是由其他领域的服务提供，也是可以的，我们将其称为即时特征（on the fly feature）。然而，这种集成方式不能在我们的平台内部发生，它必须在用户先调用该服务并准备好特征后，通过推理请求传递给我们。
这样做的好处是，对于推理平台来说，除了特征存储之外，我们的解决方案不会依赖其他任何服务。我们的机器学习平台不会因为特征需要重用而要求与其他服务进行协商或调整，例如在处理来自不同领域的新用例时。我们的平台不会要求领域团队准备额外的容量来满足特定的服务水平协议（SLA），以确保平台的扩展性。
另一个需要考虑的因素是即时特征（on the fly feature）。使用即时特征可能会对整个特征的上线时间（TTM）产生影响，因此更应该考虑数据策略的变化。如果你依赖于其他服务来获取相应的数据作为模型输入，那么你在离线环境下如何获取这些数据？
更好的策略是通过实时（NRT）方式提前计算好这些特征，并将其准备在一个键值存储（如特征存储）中，这样做的好处是，整体的可扩展性、复用性和 SLA 会更好。
在模型的基础设施服务方面，我们处理请求、特征值和模型得分时，会进行快照。快照有两个目的。第一个目的是将快照存储在离线的特征存储中。一旦记录下来，如果用户有标签信息和数据集，我们的平台可以快速为用户准备好所需的特征。
第二个目的是监控。当特征经过推理时，我们需要了解在线推理的特征分布是否与训练时的分布一致。因此，我们会建立一个持续的管道，对在线特征或模型的分布进行统计，并进行相应的监控和警报。
在构建机器学习平台（MLP）和人工智能平台（AIP）时，需要进行实体建模，包括模型和相应流程的建模。这些模型可能依赖于批处理特征、即时特征和实时特征，而平台会管理相应的特征存储，并准备存储变量。当收到推理请求时，平台会加载对应的键，进行派生计算并提供给模型。
建模过程中，需要完整地建模整个依赖关系，甚至到字段级别。这对于良好的平台治理至关重要，因为离线存储变量的模式演变需要向后兼容，以满足特征被其他用例复用的需求。确保向后兼容性对于已经使用该特征的用例至关重要，因此需要进行监管和验证。
完成依赖建模后，就形成了一个模型，它有自己的特征列表，可能是即时特征、批处理特征或实时特征，并具有基于实体的依赖 DAG。如果将多个模型组合在一起，例如挑战模型，可以统一执行它们。
将所有依赖的实体组合在一起形成一个庞大的依赖数据集。这个依赖 DAG 可以帮助了解数据的血统并进行治理控制。同时，它可以转换为执行计划，基于依赖关系进行一些优化。
通过优化执行计划，例如将来自同一存储变量的特征一起执行，或异步计算挑战模型并进行比较，可以提高效率。对于只适用于挑战模型的特征，可以延迟执行；对于 Champion 模型的依赖，可以提前执行。在最长链路上进行识别后，可以提前调度和执行相应的项。
通过这些优化措施，整个匹配过程可以暴露出来，可以持续迭代优化执行 DAG。
过去，由于 GPU 相对昂贵且不支持虚拟化，这导致在部署时需要共享一张卡，给隔离性带来问题。不同应用对 CPU 内存的需求各不相同，如何有效进行调度、管理和故障转移成为挑战。这种管理任务通常不能仅依赖原生的云服务，需要自行处理，且开销较大。
现在新的 GPU 硬件已经支持滑动虚拟化，我们期望实现隔离部署的能力，一旦实现隔离部署，GPU 对 CPU 的影响就不会有太大区别。因此，我们的目标是统一管理数据和部署流程，通过统一的管理和部署流程以及统一的模型规范，建立一个服务于 CPU 和 GPU 推断的统一架构和堆栈。
另外，在监控方面，应该进行分层监控，包括基础设施级别、Python 级别、数据级别和业务级别。在基础设施级别，可以利用基于云的平台即服务（PaaS）或服务框架进行监控，覆盖 CPU、内存、吞吐量、流量、异常率等方面。然而，由于机器学习更关注数据，需要特别关注数据的漂移和偏移，以及与特定特征或数据相关的问题。为了快速定位问题，我们在监控平台进行了集成。在特征和模型中，我们有一个快照链路，通过预先聚合，可以观察训练时的分布与生产环境中的分布之间是否存在差异。如果出现快速变化或显著的数据偏移，可以快速检测并进行报警通知。
数据策略
在业界中，数据处理占据了大部分时间（可能为 60% 到 80%），因此对数据的处理和数据策略至关重要。举个例子，对于数据科学家来说，批处理特征通常非常友好。这些特征来自离线数据，数据科学家对其非常熟悉，他们知道如何查看和发现数据，以及如何处理数据生成所需的数据集。随后，我们的平台能够将这些数据推送到在线 KV 存储，同时也可以将其推送到离线 KV 存储。
我们首先需要定义一个特定领域的语言（DSL），用于描述在在线环境中将存储变量的数据集转换为特征的逻辑。这个 DSL 应该包括加载数据所需的键（key）以及相应的计算方法（computation）。
我们自主开发了这个 DSL，它具有强类型感知的能力，在静态环境中可以提取出依赖项。对于每个字段，我们可以精确地知道它依赖于哪个数据集，以及它依赖于哪个字段进行计算。因此，在定义和构建特征时，我们可以确定是否可以进行模拟。
在生产环境中，当将特征推送到离线特征存储时，会带有一个时间戳。在离线特征存储中，通过这个时间戳，我们可以获取到该时刻特征的值。这种能力使得我们的 DSL 在在线和离线方面具有统一性。只要有统一的定义，我们就可以确保离线模拟的准确性。通过给定一个时间，我们可以获取到该时刻特征的状态，并进行计算，从而实现在线和离线数据的一致性。
流式处理
流式处理（streaming）通常涉及近实时（NRT）的特征工程，其中与数据的"roll up"相关。在"roll up"过程中，我们通常涉及状态和增量（Delta）的抽象关系，即当前状态加上增量等于新的状态。这个状态通常存储在键值存储（KV store），例如特征存储（feature store），而增量则通常通过事件（event）进行提取。需要注意的是，在提取增量时，它们可以是无序的，即以任意顺序。
第五个公式表示我们可以进行后向填充（backfill）。假设我们要发布一个新的 NRT 变量，我们可以首先在 NRT 端进行处理，然后在离线环境中进行后向填充。我们会有先前的状态，再加上新的 NRT 增量（Delta），将它们合并以进行相应的后向填充。
第六个公式表示状态是可聚合的，尤其是对于滑动窗口（sliding window）。对于每个小时或每天，我们可以获取一个值，并且可以对最近的两三天、最近五天、最近十天或最近一个月的状态进行聚合，以获取最近一段时间的状态。通过这些抽象，整个竞赛范式变得更加容易。
在事件方面，我们生成增量（Delta），其中包含时间和键（key）。根据键，我们可以对这个增量进行预聚合，然后将聚合的增量应用到状态中。这个状态存储在键值存储中，并生成新的状态。这是一种典型的抽象形式，常见的 NRT 变量包括滑动窗口和最近 K 次衰减（last k time decay），以及事件排序（event sequencing）等技术。
在架构层面上，领域团队或数据平台团队会处理原始事件（raw events），对其进行增强（enrichment），将数据科学家所需的所有字段都包含在增强事件中。拥有增强事件的优势在于，它的计算不再依赖于其他任何数据源，它自身的数据源已经足够进行计算。
一个重要的数据策略是将增强事件同步到数据工程师（DI）进行的称为"测量摄取"的过程中，以便将其高质量地离线化。换句话说，在线和离线的增强事件具有数据的一致性。这实际上是一种思维方式的改变，我们要求数据科学家不仅仅查看数据仓库中的数据，而是查看数据湖中的增强事件。
我们提供了相应的目录和探索工具，让他们查看这些事件。我们的平台具备这样的能力，当你定义一个新的变量时，我们可以通过重放历史事件来模拟这个变量。我们能够确保当你将这个变量发布到生产环境时，在线和离线数据之间具有一致性，匹配率可以达到 99% 以上。对于大多数机器学习用例来说，这已经足够了。在这方面，我们的系统能够自动保证后向填充和计算，从而对整个特征的生命周期进行良好的控制。
数据处理和特征工程在数据处理和特征工程方面，我们通过批处理和近实时（NRT）的特征来管理和提供自助服务，以满足不同国家市场的需求，并通过端到端模拟支持可重用性。同时，我们也支持 on the fly 特征，并将其快照到离线的 Fish 表中，以便准备相应的特征训练集。我们的增强战略强调与数据科学家的合作，通过公开事件数据和共享的事件日志，加快特征构建和重用的速度。对于非结构化数据的嵌入特征，我们提供近实时的构建和自动化处理，以实现无缝切换和升级。整个流程从特征到训练再到推断都得到打通，我们提供一致的数据管理和支持，无论是结构化数据还是非结构化数据，从数据集准备到模型管理都在我们的平台上完成。这样的整合和自动化保证了数据流和策略的一致性，提高了特征工程的效率和可靠性。
在机器学习中，有一种称为“on the fly”的特征，它的重用能力是最差的，因为它需要领域团队先准备好，然后通过请求传递给我们。当然，我们也会支持它，并提供快照到离线的 Fish 表。所以，请大家看一下批处理的特征和近实时的特征。前两者由我们管理，我们提供自助服务来定义和监管，我们将进行端对端的模拟来支持可重用性。
对于 on the fly 这种特征来说，对数据的实时性要求并不是那么高。与其依赖一个服务，不如将该服务的变更日志作为事件公开。然后基于这些事件，我们已经可以进行很多计算了。另一个对于非结构化数据非常有用的特征是嵌入。如果你有一个特征需要进行嵌入，不要等到离线再进行处理，因为这样的时序会太慢。你可以在近实时上进行嵌入，构建好 KN 索引。
当你说你有一个嵌入模型需要升级时，平台会自动化地处理。旧版本的模型会继续运行，新版本的模型会在 NRT 上开始运行，并自动进行回填和校验。等到一切准备好并校验通过后，会无缝切换，并将旧的索引废弃掉，所有这些都是自动化的。
最后，我想讲的是将整个流程从特征到训练再到推断打通。无论是结构化数据还是非结构化数据，Java Set 的管理都是一致的。例如图像模型，我们帮助准备相应的图像数据集，进行当天的下载和预处理。对于结构化数据，一旦数据集准备好，用户只需要指明特征列表，只要在我们这边注册，我们就知道它是在 NRT、批处理还是非实时的。
直播推荐 AI 大模型时代，架构师面临哪些机遇和挑战？ 今晚 20:00，Mobvista 技术 VP 蔡超，直播连线科大讯飞 AI 研究院副院长李鑫，为你揭晓答案！更有 ArchSummit 深圳站精彩专题提前剧透，知识豪礼送不停！抓紧预约！ 点击 「阅读原文」 查看 ArchSummit 深圳站讲师阵容。