机器学习：问题构建及框架化

机器学习作为一种解决方案，并不是“万金油”，它只适用于一些特定的场景。在实际应用中，我们首先需要进行问题构建——即通过分析问题以隔离需要解决的各个元素的过程。问题构建有助于确定项目的技术可行性，并提供一组明确的目标和成功标准。在考虑机器学习解决方案时，有效的问题构建可以确定您的产品最终是否成功。

正式的框架构建是解决机器学习问题的关键开始，因为它会迫使我们更好地了解问题和数据，从而设计出问题和数据并架起桥梁。-  TensorFlow 工程师

目录

1. 明确问题

1.1 描述目标

1.2 明确用例

1.3 分析数据

1.3.1 预测能力

1.3.2 预测对比

2. 对问题进行框架处理

2.1 确定理想的结果和模型目标

2.1.1 选择合适的模型类型

2.2 确定模型的输出

2.2.1 代理标签

2.3 设定效果指标

3. 实施模型

3.1 训练自己的模型与使用预训练模型

3.2 监控

3.2.1 模型部署

3.2.2 训练-服务偏差

3.2.3 推理服务器

---

1. 明确问题

在使用机器学习之前，首先要明确问题，以确定是否有必要且适合采用机器学习来解决问题，具体而言，需要完成以下任务：

• 明确正在开发或重构的产品的目标。
• 确定目标是否最好使用 ML 来解决。
• 确认您拥有训练模型所需的数据。

1.1 描述目标

没有目标的前行犹如黑暗中的远征。首先以非 ML 术语描述目标。目标是对“我想要完成什么？”这个问题的回答。如下表所示，列举了几个虚拟应用程序的目标：

应用	目标
天气应用	以六小时为增量计算一个地理区域的降水量
视频应用	推荐有用的视频
邮件应用	检测垃圾邮件
地图应用	计算旅行时间
银行应用程序	识别欺诈交易
餐饮应用	通过餐厅的菜单识别菜系

1.2 明确用例

有些人将 ML 视为可以应用于所有问题的通用工具。实际上，ML 是一种仅适用于特定问题的专用工具。当更简单的非 ML 解决方案足以满足需要时，则完全没有必要实施复杂的 ML 解决方案，须知，我们应该根据问题来设计解决方案，而不是先入为主，以解决方案来迎合问题。

那么，该如何确认 ML 是正确的方法呢？首先，需要验证当前的非 ML 解决方案是否足以满足需要。如果从未采用过非 ML 解决方案，那么，应先尝试使用非 ML 方案来解决问题。

非 ML 解决方案的效果可以作为“基线”，用来确定 ML 方案是否适用。在将非 ML 方法与 ML 方法进行比较时，需要考虑以下问题：

• 质量。预期 ML 解决方案可以好到什么程度？如果预期 ML 解决方案只能带来微弱的优化，那么，当前的解决方案更合适，毕竟 ML 方案的成本很高，为了微弱的优化使用 ML 并不划算。

• 成本和维护。ML 解决方案的短期和长期成本如何？在某些情况下，实施 ML 在计算资源和时间方面的成本要高得多。考虑以下问题：

  • 机器学习解决方案能否证明成本增加是合理的？请注意，大型系统中的小改进很容易证明实施 ML 解决方案的成本和维护是合理的。
  • 该解决方案需要多少维护？在许多情况下，ML 实施需要专门的长期维护。
  • 相关产品是否有资源来支持培训或雇用具有 ML 专业知识的人员？

1.3 分析数据

数据是 ML 的驱动力。在实际应用中，为了做出好的（准确的） 预测，需要包含具有预测能力的特征的数据。具体而言，数据应具有以下特征：

• 丰富。数据集中的相关和有用的用例越多 ，训练的模型就越好。

• 一致且可靠。拥有一致且可靠地收集的数据将产生更好的模型。例如，基于 ML 的天气模型将受益于多年来从相同可靠仪器收集的数据。

• 值得信赖。获取数据的途径应是受控的可信来源，例如来自产品的日志（典型如用户点击、浏览数据）。如果数据来源不可控，则不适合采用 ML 。

• 可用。确保所有输入在预测时都以正确的格式提供。如果在预测时难以获得某些特征值，请从数据集中忽略这些特征。

• 正确。在大型数据集中，某些 标签的值不正确是不可避免的，但如果超过一小部分标签不正确，模型将产生糟糕的预测。这其实很好理解，试想，如果一本练习册的大部分参考答案都是错误的，那么根据这本练习册来训练是不可能取得好的结果的。

• 代表。数据集应尽可能代表现实世界。换句话说，数据集应该准确地反映事件、用户行为和/或被建模的现实世界的现象。当模型被要求对现实世界进行预测时，对不具代表性的数据集进行训练可能会导致性能不佳。

如果无法获得满足上述要求的数据，那么，采用 ML 方案将无法带来良好的预测结果。

1.3.1 预测能力

为了使模型做出良好的预测，数据集中的特征应该具有预测能力。特征与标签的相关性越高，预测它的可能性就越大。例如，在天气数据集中，诸如云层覆盖范围（cloud_coverage）、气温、露点（drew point）之类的特征就要比月相、日期更能预测降雨。对于视频应用程序，则可以假设诸如视频介绍、时长和评论之类的特征是预测用户想要观看哪些视频的指标。

需要注意的是，特征的预测能力可能会随着上下文或领域的变化而变化。例如，在视频应用程序中，“上传时间”这一特征通常与标签弱相关，然而，在游戏视频的领域中，“上传时间”则可能与标签密切相关。

确定哪些特征具有预测能力可能是一个耗时的过程。在实际应用中，一般可以在训练模型时通过删除和添加特征来手动探索特征的预测能力。您可以使用 Pearson 相关性、 调整互信息 (AMI)和 Shapley 值等算法自动查找特征的预测能力，这些算法提供用于分析特征预测能力的数值评估。

1.3.2 预测对比

ML 最终是需要服务于具体的业务场景的，因此，如果不能将预测结果转化为对用户有帮助的行动，那么预测就没有任何价值。换言之，ML 方案的预测结果应该有助于采取行动。

2. 对问题进行框架处理

在明确问题适合采用用机器学习来解决后，就可以用机器学习术语刻画具体的问题了。通常，需要完成以下任务，根据机器学习术语构建问题：

• 确定理想的结果和模型目标。
• 确定模型的输出。
• 设定成效指标。

2.1 确定理想的结果和模型目标

独立于机器学习模型的理想的结果是什么？换句话说，你希望产品或功能执行的确切任务是什么？这与前面【描述目标】部分中定义的语句相同。

通过明确定义希望模型执行的操作，将模型目标与理想结果相关联。如下表举例所示，说明了理想结果以及假设应用的目标。

应用广告系列	理想结果	模型的目标
天气应用程序	计算某个地理区域的降水情况（以六小时为增量）。	预测特定地理区域的 6 小时降水量。
视频应用	推荐有用的视频。	预测用户是否点击了视频。
“邮件”应用	检测垃圾内容。	预测电子邮件是否为垃圾邮件。
地图应用	计算行程时间。	预测两点之间将花费多长时间。
银行应用	识别欺诈性交易。	预测交易是否由持卡人进行。
“餐饮”应用	根据餐厅的菜单识别美食。	预测餐厅类型。

2.1.1 选择合适的模型类型

在实际应用中，选择的模型类型取决于问题的具体情况和限制。不同类型的问题适用的模型也不尽相同，通常需要“case by case”来分析。

分类模型——适用于预测输入数据属于哪个类别，例如，输入应归类为 A、B 还是 C。

图 1. 一种进行预测的分类模型。

在实际应用中，可能会根据模型的预测结果做出决定。例如，如果预测结果为类别 A，则执行 X；如果预测结果为类别 B，则执行 Y；如果预测结果为类别 C，则执行 Z。在某些情况下，预测结果是应用的输出。

图 2. 一个分类模型的输出在产品代码中做出决策。

回归模型——适用于预测将输入数据置于坐标轴的位置。

图 3. 进行数值预测的回归模型。

实际应用场景中，可能会根据模型的预测结果做出决定。例如，如果预测结果在范围 A 内，则执行 X；如果预测结果在范围 B 内，则执行 Y；如果预测结果在范围 C 内，则执行 Z。在某些情况下，预测结果是应用的输出。

图 4. 运用回归模型的输出来做出决策。

举个例子，假定存在如下场景：

假设需要根据视频的预测热门程度缓存视频。换言之，如果模型预测某个视频会比较受欢迎，则需要快速将其展示给用户。为此，这类视频可使用更高效、更昂贵的缓存。对于其他视频（非热门视频），则只需要使用普通缓存。综上，缓存条件如下：

• 如果视频预计可获得 50 次或更多次观看，则可以使用高性能缓存。
• 如果视频预计的观看次数会介于 30 到 50 之间，将使用普通缓存。
• 如果视频预计获得的观看次数不足 30 次，不必缓存视频。

根据直观感受，上述场景适用回归模型，因为要预测一个数值（观看次数）。然而，在训练回归模型时，会发现对于观看次数为 30 次的视频，它的预测损失也为 28 和 32。换言之，如果预测结果为 28 与 32，应用的行为将截然不同。

图 5. 训练回归模型。

回归模型不了解产品定义的阈值。因此，如果应用因回归模型的预测结果存在细微差异而出现显著变化，则应考虑实现分类模型。在这种情况下，分类模型会产生正确的行为，因为分类模型的预测损失高于 32。从某种意义上讲，分类模型在默认情况下会生成阈值。

此场景着重说明了两个要点：

• 预测决策。尽可能预测你的应用会做出的决策。在视频示例中，分类模型会预测将视频归为“无缓存”、“便宜缓存”和“昂贵缓存”的类别。从模型中隐藏应用的行为可能会导致应用产生错误的行为。

• 了解问题的约束条件。如果你的应用根据不同的阈值执行不同的操作，请确定这些阈值是固定的还是动态的。

  • 动态阈值：如果阈值是动态的，请使用回归模型并在应用代码中设置阈值。这样，您就可以轻松更新阈值，同时仍使模型做出合理的预测。
  • 固定阈值：如果阈值固定，请使用分类模型并根据阈值限制为数据集添加标签。

  一般情况下，大多数缓存预配都是动态的，并且阈值会随着时间而变化。因此，由于这专门是一个缓存问题，因此回归模型是最佳选择。但是，对于许多问题，阈值将得到修复，从而使分类模型成为最佳解决方案。

2.2 确定模型的输出

模型的输出应能实现理想结果中定义的任务。如果使用的是回归模型，数值预测应提供实现理想结果所需的数据；如果使用的是分类模型，则分类预测应提供实现理想结果所需的数据。存在多种分类和回归模型子类型。使用相应流程图来识别使用的子类型。

分类流程图

图 6. 分类流程图。

回归流程图

图 7. 回归流程图。

在天气应用中，理想的结果是告知用户在接下来的六小时内会下雨。我们可以使用回归模型来预测标签——降雨量.

理想结果	理想的标签
告知用户未来 6 小时内该地区会下雨，	降雨量

在天气应用示例中，标签直接说明了理想结果。在某些情况下，理想的结果与标签之间不明显的一对一关系。例如，在视频应用中，理想的结果是推荐用户感兴趣的视频。但是，数据集中没有名为 useful_to_user 的标签。

理想结果	理想的标签
推荐有用的视频。	?

因此，在这种情况下，我们需要寻找代理标签。

2.2.1 代理标签

代理标签用于替代数据集中不存在的标签。如果无法直接衡量要预测的内容，则需要使用代理标签。在视频应用中，我们无法直接衡量用户是否认为视频有用（用户是否感兴趣或者感兴趣的程度）。如果数据集具有 useful 功能，并且用户标记了自己认为有用的所有视频，那就再好不过了，但是由于数据集没有这样的标签，因此需要使用代理标签来替代实用性。实用性的代理标签可能是用户是否会分享或顶过（赞过）视频。

理想结果	代理标签
推荐有用的视频。	分享 或 点赞

需要说明的是——请谨慎使用代理标签，因为它们不能直接衡量需要预测的内容。例如，下表概述了推荐实用视频的潜在代理标签问题：

代理标签	问题
预测用户是否会点击“赞”按钮。	大多数用户从未点击“赞”。
预测某个视频是否会受欢迎。	未进行个性化设置。某些用户可能不喜欢热门视频。
预测用户是否分享视频。	部分用户不分享视频。有时，人们会因为不喜欢视频而分享视频。
预测用户是否会点击播放。	最大限度地增加点击诱饵。
预测他们观看视频的时长。	他们喜欢长视频而非短视频。
预测用户会重新观看该视频的次数。	更喜欢“可重复观看”的视频，而不是不可能重复观看的视频类型。

没有代理标签能完全替代您期望的成果。这一切都有潜在问题。请选择对您的用例而言问题最少的一个。

2.3 设定效果指标

定义效果指标将用于确定机器学习实现是否成功的指标。成功指标定义了产品关注的方面，例如互动或帮助用户采取适当的措施，例如观看他们认为有用的视频。成功指标不同于模型的评估指标，例如准确度、精确率、召回率或AUC。

例如，天气应用的成功和失败指标可能定义如下：

成功	用户打开“会下雨吗？”功能的频率比之前要高 50%。
失败	用户打开“会下雨吗？”功能的频率不会超过之前。

视频应用指标可能定义如下：

成功	用户在网站上停留的时间平均增加了 20%。
失败	用户在网站上停留的平均时间比以前要长。

通常，制定的成功指标应具有显著性，即成功和失败之间有显著差距。例如，用户在网站上停留的时间比之前平均增加了 10%，这既不是成功，也不是失败。未定义的间隔并不重要。

重要的是，模型能否更接近（或超出）成功的定义。例如，分析模型的性能时，请考虑以下问题：改进模型是否能让你更接近定义的成功标准？例如，模型可能有很棒的评估指标，但不会更接近你的成功标准，这意味着，即使是一个完美的模型，也无法满足你定义的成功标准。另一方面，模型可能具有低下的评估指标，但会更接近你的成功标准，表明改进模型会让你更接近成功。

在确定模型是否值得改进时，需要考虑以下维度：

• 还不够好，但请继续操作。模型不应在生产环境中使用，但随着时间的推移，这可能会得到显著改进。

• 足够好了，请继续。该模型可以在生产环境中使用，并可进一步改进。

• 足够好了，但无法改进。该模型已在生产环境中，但可能得到了理想的效果。

• 不够好，永远不会。模型不应该在生产环境中使用，且经过一定数量的训练都可能无法获得该模型。

在决定改进模型时，请重新评估资源增加情况（例如工程时间和计算费用）的合理性，看看是否有合理的改进模型。

在定义成功和失败指标后，需要确定衡量这些指标的频率。例如，可以在实现系统六天、六周或六个月后衡量您的成效指标。

在分析故障指标时，请尝试确定系统出现故障的原因。例如，模型可能会预测用户会点击的视频，但可能会开始推荐导致用户互动度下降的点击诱饵标题。在天气应用示例中，模型可能会准确预测何时会下雨但地理区域过大。

3. 实施模型

实施模型时，从简单开始。ML 中的大部分工作都在数据方面，因此为复杂模型运行完整的管道比在模型本身上迭代更难。在设置数据管道并实施使用一些功能的简单模型后，可以迭代创建更好的模型。简单的模型提供了一个很好的基线，即使你最终没有启动它们。事实上，使用简单模型可能比想象的要好。从简单开始可以帮助确定复杂模型是否合理。

3.1 训练自己的模型与使用预训练模型

许多预训练模型适用于各种用例，并提供许多优势。但是，预训练模型只有在标签和特征与数据集完全匹配时才真正起作用。例如，如果预训练模型使用 25 个特征，而数据集仅包含其中的 24 个特征，则预训练模型很可能会做出错误的预测。

通常，机器学习从业者使用来自预训练模型的匹配输入部分进行微调或迁移学习。如果您的特定用例不存在预训练模型，请考虑在训练您自己的模型时使用预训练模型的子部分。

有关预训练模型的信息，请参阅 TensorFlow Hub 中的预训练模型

3.2 监控

在问题框架中，考虑您的 ML 解决方案所需的监控和警报基础设施。

3.2.1 模型部署

在某些情况下，新训练的模型可能比当前生产中的模型更差。如果是，您将希望阻止它被发布到生产环境中，并收到您的自动化部署失败的警报。

3.2.2 训练-服务偏差

如果用于推理的任何传入特征的值超出训练中使用的数据的分布范围，您将需要收到警报，因为模型可能会做出糟糕的预测。例如，如果模型经过训练可以预测海平面上赤道城市的温度，那么服务系统应该提醒传入的经纬度数据和/或超出模型训练范围的海拔高度。相反，如果模型做出的预测超出训练期间看到的分布范围，服务系统应该发出提醒。

3.2.3 推理服务器

如果通过 RPC 系统提供推理，需要监视 RPC 服务器本身，并在它停止提供推理时收到警报。

4. 引用说明

本文源自谷歌机器学习资料（资料链接），笔者对其中内容进行了整理和翻译。感兴趣的读者可以点击资料链接，查看原文。