例如，假设我们正在尝试构建一个使用图像作为输入的模型。我们的图像为 2048 x 1536 像素，每个像素都以 RGB 颜色格式存储，这意味着图像以数字方式表示为超过 900 万个整数。显然，这不会是处理数据的有效方式。但是，如果我们将这项任务交给人类并告诉他们我们正在尝试构建面部识别系统，他们可能会决定将每张图像表示为一组特征：头发颜色、眼睛之间的距离、鼻子之间的距离和皮肤、头发的厚度等。在构建了几十个特征之后，我们可能会拥有一个相当好的系统，可以用来对人脸进行分类，而且我们使用的特征要少于 900 万个。本质上，这就是特征提取的作用：它采用高度复杂的数据，例如：文本或图像，同时能够提取仍然准确表示数据的较小的特征集。

特征提取可用于机器学习和深度学习问题，如下图所示：

特征提取很快变得复杂。这些是即使是数据科学家也难以解决的话题，尽管在处理复杂数据时，这些问题对于获得好的结果是绝对必要的，但在执行方面它们仍然可能让专家绊倒。 我们相信一个好的第 3 代 ML 平台将采用类似于编码的方式提取特征：实现应该是自动化的，用户应该能够通过配置根据每个用例的需要打开和关闭它们。 另外，特征提取通常与复杂数据类型相关联。对于在表格数据之上执行 ML 的用户，特征提取可能是不需要的。

特征选择

特征选择是选择要在 ML 模型构建中使用的特征子集的过程。例如，我最初可能选择在模型中包含 100 个特征，但随后将范围缩小到 20 个以供生产使用。为什么我们要减少在模型中使用的特征数量呢？更多的特征不是更好吗？使用特征选择有各种争论，包括简化模型、减少训练时间以及试图通过降低特征空间的维数来防止过度拟合。

有许多不同的特征选择技术。有些是内置在算法中的，例如：随机森林，它有一个参数来表示要使用的最大特征数，以及 LASSO 回归，它增加了一个 L1 惩罚，开始将不重要特征的贡献降低到 0；其他的则独立于模型。例如，我们可以采用一种方法对特征子集进行评分，直到发现最佳组合，就像在逐步回归中所做的那样，或者只是在特征和目标之间进行统计测试，然后根据结果选择有限数量的特征，就像有时使用卡方检验一样。

需要注意的是，模型性能并不是模型选择的已知好处之一。这是一个有争议的话题，但可以说没有普遍共识认为我们需要进行特征选择以获得更好的模型，而且似乎有几家高科技公司可能不会积极参与这种行为。此外，如果特征选择不正确，它可能对模型性能非常不利。此时，一个好的策略是利用 ML 算法中的任何内置特征选择，并对模型结果进行手动检查，以查看是否需要任何额外的干预。

对于 Continual ，我们通常的建议以下：

• 删除具有负面特征重要性的特征是安全的。众所周知，这些会损害模型性能。
• 删除与其他特征密切相关的特征也是安全的。与另一个特征具有强相关性的特征可能对模型性能贡献不大，但它们可能会降低特征重要性分析的质量。
• 调查任何模型版本的数据分析和数据检查的结果，并使用此信息采取适当的措施。也就是说，如果一个列大部分是空值，或者如果一个特征集的时间索引与模型定义几乎没有重叠，这些都是可能从模型中删除的东西。

预测工程

特征创建侧重于构建机器学习模型的输入，而预测工程侧重于创建标签。这是机器学习的一个新趋势，主要是从特征平台（feature stores）的创建中演变而来的。在特征平台之前，从来没有真正需要单独创建与标签分开的特征。对于任何用例，都需要特征和标签，因此它们将在同一个工作流程中一起创建。然而，使用特征平台，可以独立于使用它们的模型自由生成特征，因此它开辟了一个独立于特征的模型标签工程的新领域。将预测工程作为“特征工程”的一部分包括在内似乎有点奇怪，但工作流程非常相似，并且它是与模型训练本身不同的一项不同任务。

预测工程的真相是：这是 ML 用例的定义标准（quality）。尽管可以在不同的 ML 模型之间使用特征，但每个模型的标签本身都是唯一的。对于某些用例，这将像查找列一样简单，而其他用例可能需要更深思熟虑。最近我们写了一篇关于为基于时间的客户流失用例构建标签的文章，过程总结如下：在数据上定义客户流失需要业务背景，以及理解和推论销售流程中引人注目的事件的能力。

近年来，预测工程和标签解决方案也在兴起，开源项目和商业解决方案，如 Labelbox（图像）和 Snorkel（文本），提供了强大的功能来帮助用户完成这项任务。 对于专注于云数据仓库中表格数据的Continual 用户而言，预测工程通常相当于简单地构建正确的 SQL 查询以正确地为模型定义提供标签。 就像特征创建一样，我们认为这在很大程度上应该通过人的勇气来解决，而且，通常需要重要的业务背景来正确设置标签。

自动特征工程

我们在这里的最后一部分绝对是探索最少和最诱人的：自动特征工程。自动特征工程涉及特征创建的自动化，并且还可以包括特征选择和特征编码。

虽然许多特征可能需要人工交互才能构建，但有些特征可以自动化。例如，任何时候我们希望使用日期或时间戳作为特征，我们都可以自动将其分解为其组成部分：年、月、日、星期几、小时、“这一天是假期吗？”等。许多用例需要在现有功能之上计算窗口函数。构建大量滚动窗口可能既耗时又容易出错，但不难想象用户可以简单地为现有特征指定分区、窗口帧（frame）和聚合函数来定义新特征。根据数据存储的好坏以及底层数据仓库对窗口操作的支持程度，这些操作可能变得非常重要，自动化它们的构建可以节省大量时间和精力。

当然，存在更复杂的自动特征工程系统。两个流行工具的是 FeatureTools 和 tsFresh。 FeatureTools 设计用于处理表格数据，而 tsFresh 用于处理时间序列数据。两者都能够通过用户的少量输入轻松地从原始数据生成许多特征。例如，FeatureTools 使用一个称为深度特征合成 (DFS) 的特征创建系统。 DFS 的运行原理是相互堆叠操作以创建新特征。例如，如果我的一个特征集是销售数据，我可以为每个订单计算一个新特征 days_since_last_transaction，它给出了当前交易和最后交易之间的天数。然后，我可以计算我的新功能的滚动平均值，以提供另一个特征，average_days_since_last_transctions_over_one_year，等等。每增加一个操作，我们都会在特征上“堆叠”一个新操作，以创建一个全新的特征。对于任何给定的用例，我们可能希望使用许多不同的特征来做到这一点，而 DFS 的见解是这些操作非常普遍，并且可以通过少量配置快速自动化。

在上面的示例中，我们可以通过将操作堆叠在彼此之上来继续构建其他特征，如下图所示：

自动特征工程领域还很年轻。我们对自动特征工程的发展寄予厚望，并相信进步将继续使其更接近主流。与特征编码和特征提取类似，自动特征工程最好通过声明式系统在第 3 代 ML 系统中实现。将杂乱的细节从最终用户那里抽象出来并允许他们通过配置简单地定义所需的操作是理想的。虽然 Continual 目前提供了一些轻量级的自动特征工程，但我们目前正在评估更复杂的框架，例如：DFS，以便将来包含在该工具中。

总结

在本文中，我们提供了很多关于如何在第 3 代 ML 平台（如 Continuous）中实现特征工程变更的方法。

下图总结了我们设想在传统 ML 工作流程中扮演不同角色的地方，并根据上面提供的上下文扩展了特征工程。我们还将此与第 1 代和第 2 代 ML 平台的早期迭代进行了对比。在您规划自己的组织使用机器学习和 AI 的旅程时，请将此作为指南。