特征平台是什么？

特征平台的定义通常是模棱两可的。我们将首先提供一个具体的定义，然后讨论它的常见的特征和好处。

简而言之，特征平台是一种数据管理系统，用于管理和提供机器学习模型的特征。你问什么是特征？用外行的话来说，特征是一种描述性属性，与预测事物在世界中的行为方式有关。例如，客户的购买历史与预测该客户接下来会购买什么有关，而与客户姓名的第一个字母则无关。对于更倾向于技术的人来说，特征是机器学习模型的一个输入。在表格数据的常见用例中，一个特征对应于表中的一列。例如，对于客户流失模型，一个好的特征可能是过去 30 天的客户页面浏览量。或者对于销售预测用例，一个特征可能是某一天是否是节假日。

特征通常被收集到特征集中。 再次使用我们的表格数据示例，特征集就是表格本身。 在这种情况下，特征平台了解模型所需的数据（即特征），无论是用于模型训练还是用于预测，以及该数据如何连接到其他数据以及将其转换为正确格式所需的转换. 希望这听起来很简单！ 但是，事实是，设计和构建特征平台实际上是一项相当复杂的工作。

特征平台的概念在 Uber 的 Michaelangelo ML 平台上得到了最显著的推广，它在帮助 Uber 实施 ML 方面发挥了重要作用。用他们自己的话来说：

我们发现构建集中式特征平台非常有价值，Uber 周围的团队可以在其中创建和管理典型的特征，供其团队使用并与其他人共享……目前，我们在特征平台中拥有大约 10,000 个特征用于加速机器学习项目，整个公司的团队一直在添加新项目。特征平台中的特征每天都会自动计算和更新。

当时，像 Uber 这样快速创新以使机器学习成为其业务重要组成部分的公司发现了传统机器学习方法存在的几个障碍：

• 数据科学家在开始构建模型之前会花费大量时间来转换数据。
• 更糟糕的是，当他们开始一个新的用例时，他们经常发现没有干净的数据可以使用。
• 基于Notebook的数据科学可能难以跟踪和管理正在使用的数据。而且，如何将完成的工作写入notebook并将其转换为生产作业（job）也不太清楚。
• 数据团队中不是数据科学家的人使用 ML 工具完成任何事情的机会几乎为零。
• 数据的线上线下需求缺乏统一的数据层。

特征平台有助于解决这些问题。我们将在下一节中更详细地讨论这一点。

在 Uber 的 Michaelangelo 博客文章发布后不久，Google 和 Gojek 发布了 Feast，一个开源的特征平台。在随后的几年里，许多其他公司开始讨论他们的内部 ML 平台，并且看到特征平台或类似组件是 ML 平台运营的核心并不少见。鉴于如此多的公司都在努力从他们的 ML 投资中寻找价值，因此、特征平台可能是简化运营 ML 的关键组成部分。

特征平台常见的特点是什么？

在过去的几年里，特征平台已经开始渗透到商业产品中，无论是作为独立产品（如：Tecton）、现有平台的附加产品（如：Sagemaker 和 Databricks），还是作为运营 ML 平台的一部分（如：Continual）。现在特征平台空间有很多种类，它们有各种形状和大小。在本节中，我们将分解我们认为是特征平台的基本功能。

特征转换

特征平台最重要的方面之一是跟踪哪些数据源发生了哪些转换。这可以是相当普通的东西，比如：简单的连接和聚合，或者更复杂的东西，比如：窗口操作。此外，可以在自动特征工程中提供高级功能，例如：特征编码、日期提取，甚至深度特征合成。

需要注意的是，特征平台不需要

1. 实际执行这些操作
2. 存储结果数据。

ML 平台的其他部分可能负责这项工作。但无论物理机制如何，数据团队都应该很容易添加和使用共享存储库中的特征。

支持在线和离线模式

除了管理特征之外，特征平台的另一个主要任务是将这些特征提供给模型。这要么在在线预测期间实时发生，要么在批量预测或批量训练期间离线发生。

这两个用例（场景）之间有一个重要的区别：

• 离线模式需要生成一个（可能很大）包含许多不同特征的许多记录的数据集，并将其提供给模型进行训练/预测。它执行此操作的速度通常不是特别紧迫，但它需要能够处理大型数据集。
• 在线模式需要为一条或多条记录生成特征以进行实时预测。速度非常重要，在某些用例中，整个过程需要在一秒钟内完成。

这两个用例（场景）需要非常不同的体系结构，但特征平台的工作是抽象出这种复杂性，并提供一个简单的服务层。

实体解析

如果设计得当，特征平台可以让数据专业人员停止根据表和列来解决问题，而是根据客户和产品等实际业务对象来解决问题。这将客户流失问题变成了一项关于获取和连接表（如：customer_info、customer_transactions、customer_interactions、product_info、product_usage等）的操作，以链接到客户和产品实体。特征平台可以了解组织中这些业务对象或实体的所有相关数据，并知道如何正确地将所有内容连接在一起。

特征血缘

随着特征平台开始增长并捕获更多用于 ML 工作的特征，自然会开始提出诸如“如果我更新此特征会影响哪些模型？”之类的问题。特征平台可能会在特征血缘中显示大部分此类信息，这并不奇怪。这允许用户以一种简单的方式来可视化特征/特征集/实体如何相互连接、所涉及的列/表/转换以及任何关联的模型。由于特征的可发现性和重用性是特征平台的一个重要卖点，特征血缘对于让用户了解如何使用不同的特征以及特征平台中存在的关系至关重要。

时间点正确性或特征时间旅行

虽然很容易习惯 Kaggle 风格的数据科学，它将 ML 问题呈现为静态平面文件，但重要的是要记住，现实生活中的问题不仅经常涉及许多不同的数据源，而且往往还包含时间成分。关于时间的推理很快就会变得复杂，甚至连最资深的数据科学家也会感到困惑。在 ML 问题中错误处理时间数据的风险可能很严重，，因为您可能会从未来开始泄漏数据，并使任何结果无效。

特征平台不仅有助于管理复杂的转换和理解特征集与实体之间的关系，而且还为时态数据提供了解决方案。当在特征平台中构建训练或服务数据时，它以时间一致的方式进行——这通常称为时间点正确性或“特征时间旅行”。这个想法是，对于数据集中的每条记录，我们可以将时间戳与该记录相关联。然后，特征平台将能够重建与该记录相关的所有支持的特征，因为它存在于时间戳指定的时间点。最终结果是数据始终是时间一致的，并且用户不必跨多个特征集或实体跟踪时间戳。

要了解为什么这如此重要，请考虑一个标准的客户流失预测。虽然用户当前的特征（例如：他们在过去 30 天内在您网站上的活动）对于预测未来的流失很重要，但他们的历史行为对于模型训练很重要。特征平台能够为这两个用例构建正确的数据集，而无需用户干预。

模型封装

正如我们在上面看到的，特征平台提供了一种为在线和离线场景提供预测的方法。在当今时代，ML 平台通过某种方式将模型部署为 API 端点的情况并不少见。这通常很好地演示：只需训练和部署模型，然后构造一个包含所有所需功能的 JSON 对象，端点将传递到模型中以进行快速评估。这看起来不错，但在实际生产场景中，你经常会发现下游应用程序开发人员并不太在意需要跟踪哪些特征是他的责任。更烦人的是，每当模型更新具有新特征的模型时，应用程序也必须更新以适应新的 API。

特征平台为这个问题提供了更优雅的解决方案。与其期望应用程序提供预测所需的所有基本特征，不如简单地为参与预测的实体（如：客户、驱动程序、产品）提供ID。然后，特征平台可以查找进行预测所需的任何特征，并将结果返回给应用程序。通过隐藏模型的确切特性依赖关系，这不仅可以大大简化应用程序开发人员的工作流程，还可以确保没有训练/服务偏差。

尽管特征平台是动态的并且总是在获取新数据，但预计特征平台中数据的最新程度可能会有一些滞后，具体取决于架构。某些场景需要应用程序在知道自己拥有最新数据并希望利用这些特征而不是特征平台中的内容时提供功能覆盖（例如，移动应用程序总是比功能商店将）。功能存储仍然允许有选择地添加这些客户端功能，而不会将完整的数据要求暴露给应用程序开发人员。

在某些场景中，当应用程序知道自己拥有最新的数据并希望利用这些特征而不是特征平台中的功能时，就必须提供特征覆盖（例如，移动应用程序总是比特征平台更了解用户的当前位置）。特征平台仍然允许有选择地添加这些客户端特征，而无需向应用程序开发人员公开完整的数据需求。

数据和模型漂移

数据和模型漂移是 MLOps 中越来越重要的概念，并为用户提供了一种了解数据状态何时发生变化的方法。对于运营的场景，特征平台是开始跟踪有关特征的其他信息的天然的场所，例如：数据的分布是什么？有多少个空值？特征的边界是什么？特征平台可以定期分析最新数据，然后操作系统可以在开始训练模型和进行预测时利用这些信息。预测时的数据与模型训练时的数据相比如何？如果它发生了很大的变化，这可能表明是时候重新训练了。

使用特征平台的利弊

现在我们对特征平台的功能有了更好的了解，我们可以谈谈使用它们的好处。

• 强制隔离数据科学和数据工程以及 MLOps：ML 工作流往往很复杂，并且包含许多不同的步骤。 特征平台自然地将数据工程与数据科学分离，因为它为数据工程工作流的输出提供了一个目的地，并为 ML 用例提供了一个自然的起点。 同样，特征平台将模型训练与特征服务分开，这在数据科学和 MLOps 之间提供了天然屏障。 这在 ML 工作流程周围强加了结构，从而提高了效率并避免了复杂的“流水线丛林”。
• 支持特征共享：通过支持特征重用和可发现性，特征平台可帮助组织更好地协作处理 ML 用例。领域专家可以在特征平台中快速注册特征，然后可以很容易地在跨团队的各种用例中使用。最终结果是强大的特征共享消除了重复的特征工程工作，并使每个人都更有效率。
• 防止数据泄漏和训练/服务偏差：数据泄露和训练/服务偏差是尝试将 ML 用例投入生产时最常见的两个障碍。正如我们之前所讨论的，特征平台为这两个问题提供了优雅的解决方案。
• 加速用例的采用：当特征平台是运营 ML 系统的一部分时，更新用例通常就像修改特征集一样简单。用户可以快速对用例进行原型设计和迭代，并迅速将最佳模型投入生产。如果没有特征平台，这将是不可能的。
• 使 ML 民主化：许多 ML 工具大胆声称有助于使 ML 工作流程民主化，但最终用户常常被困在编写代码或构建复杂的流水线，更不用说试图理解复杂的 ML 概念了。由于特征平台可以通过实体说出业务语言，这允许许多用户开始为 ML 用例做出贡献，无论是通过注册新特征以供使用，还是通过数据优先的 ML 运营平台显式构建模型。

当然，并非一切都是完美的。在进入特征平台世界之前，需要考虑以下几点：

• 难以构建和维护：特征平台对于ML工作流来说非常棒，但它们的构建和维护可能非常具有挑战性。尽管许多高科技公司都在利用它们，但是多年的开发工作已经再开始创造它们，而这并不是许多组织都想要的。我强烈建议你在创建自己的产品之前，先查看“购买”选项。
• 需要专业知识才能使用：并非所有特征平台都是平等的。快速浏览一些文档可以发现这些系统非常复杂，您的组织需要时间来掌握这些系统。理想情况下，尝试选择一个易于使用且与现有数据堆栈配合良好的特征平台，因为它可以让您的团队更快地迭代并让更多的数据专业人员参与协作。
• 可能是“又一个”集成点：如果您一直关注我的博客文章，您就会知道我不是机器学习系统的拥护者，因为这些系统需要复杂的集成，从而产生大量的技术债务。独立的特征平台可能很难有效地集成到您的 ML 工作流程中，并且无法完全实现真正的数据优先方法来操作 AI/ML 的潜力。
• 避免以研究为重点：如果您的 ML 团队完全专注于研究主题并且不担心其工作的可操作性，那么特征平台很可能是矫枉过正的，您可能可以避免复杂性，而不会错过太多。
• 谨防冒名顶替者：由于特征平台非常流行，许多人声称“具有相同的功能”，即使他们不会称其为特征平台。不要落入这些陷阱，不要接受模仿！以下是非特征平台的列表：数据目录（data catalogs）、静态数据集合、ETL/ELT 工具、数据仓库。

此外，虽然特征平台对于可操作的 ML 平台至关重要，但拥有特征平台并不一定意味着您也拥有可操作的 ML 平台（这是必要条件，而非充分条件）。

将特征平台带到现代数据堆栈中

如今，特征平台有许多不同的形式因素。作为 Continuous 的一部分，我们提供了一个特征平台，它直接构建在您的云数据仓库上，并支持一个完全声明式的工作流，从根本上简化了操作人工智能。通过将数据放在首位，并考虑端到端的 ML 工作流，Continuous 使数据团队能够在数小时或数天内，而不是数周或数月内部署不断改进的预测模型，从客户流失到库存预测。当完全集成到声明式人工智能工作流中时，这就是特征平台的真正潜力。