检查输入

一些当面对数据分布的微小差异时，模型可能仍然表现良好。但是，如果一个模型接收到的数据与其训练数据有很大不同，或者如果某些特征缺失或属于意外类型，它将难以执行。

正如我们之前看到的，即使输入不正确（只要这些输入的形状和类型正确），ML 模型也能够运行。模型会产生输出，但这些输出可能非常不正确。考虑图 10-1中所示的示例。管道首先将句子矢量化并在矢量化表示上应用分类模型，从而将句子分类为两个主题之一。如果管道接收到一串随机字符，它仍然会将其转换为向量，模型会进行预测。这种预测是荒谬的，但是仅仅通过观察模型的结果是没有办法知道的。

为了防止模型在不正确的输出上运行，我们需要在将这些输入传递给模型之前检测这些输入是否不正确。

这些检查涵盖与“测试您的 ML 代码”中的测试类似的领域。按照重要性顺序，他们将：

1. 验证是否存在所有必要的功能

2. 检查每个功能类型

3. 验证特征值

孤立地验证特征值可能很困难，因为特征分布可能很复杂。执行此类验证的一种简单方法是定义一个特征可以采用的合理值范围，并验证它是否落在该范围内。

如果任何输入检查失败，则模型不应运行。您应该做什么取决于用例。如果丢失的数据代表了一条核心信息，您应该返回一个错误，说明错误的来源。如果你估计你仍然可以提供一个结果，你可以用启发式代替模型调用。这是通过构建启发式来启动任何 ML 项目的另一个原因；它为您提供了一个后退的选择！

在图 10-2中，您可以看到此逻辑的示例，其中采用的路径取决于输入检查的结果。

以下是来自 ML Editor 的一些控制流逻辑示例，用于检查缺失的特征和特征类型。根据输入的质量，它要么引发错误，要么运行试探法。我在这里复制了示例，但您也可以在 本书的 GitHub 存储库中找到它以及其余的 ML Editor 代码。

def validate_and_handle_request(question_data):
    missing = find_absent_features(question_data)
    if len(missing) > 0:
        raise ValueError("Missing feature(s) %s" % missing)

    wrong_types = check_feature_types(question_data)
    if len(wrong_types) > 0:
        # If data is wrong but we have the length of the question, run heuristic
        if "text_len" in question_data.keys():
            if isinstance(question_data["text_len"], float):
                return run_heuristic(question_data["text_len"])
        raise ValueError("Incorrect type(s) %s" % wrong_types)

    return run_model(question_data)

验证模型输入允许您缩小故障模式并识别数据输入问题。接下来，您应该验证模型的输出。

模型输出

一次模型做出预测后，您应该确定是否应将其显示给用户。如果预测超出模型可接受的答案范围，您应该考虑不显示它。

例如，如果您根据照片预测用户的年龄，则输出值应介于 0 到 100 多岁之间（如果您在 3000 年阅读本书，请随意调整界限）。如果模型输出的值超出此范围，则不应显示它。

在这种情况下，可接受的结果不仅由合理的结果来定义。它还取决于您对对我们的用户有用的结果类型的估计。

对于我们的 ML 编辑器，我们只想提供可操作的建议。如果一个模型预测用户写的所有内容都应该被完全删除，这将包含一个相当无用（和侮辱）的建议。以下是验证模型输出并在必要时恢复为启发式的示例片段：

def validate_and_correct_output(question_data, model_output):
    # Verify type and range and raise errors accordingly
    try:
        # Raises value error if model output is incorrect
        verify_output_type_and_range(model_output)
    except ValueError:
        # We run a heuristic, but could run a different model here
        run_heuristic(question_data["text_len"])

    # If we did not raise an error, we return our model result
    return model_output

当模型失败时，您可以恢复到我们之前看到的启发式方法，或者恢复到您之前构建的更简单的模型。尝试早期类型的模型通常是值得的，因为不同的模型可能有不相关的错误。

我已经在图 10-3中的玩具示例中说明了这一点。在左侧，您可以看到具有更复杂决策边界的性能更好的模型。在右侧，您可以看到一个更糟糕、更简单的模型。较差的模型会犯更多的错误，但由于其决策边界的形状不同，其错误与复杂模型不同。正因为如此，更简单的模型得到了一些正确的例子，而复杂的模型却出错了。这就是为什么在主模型失败时使用简单模型作为备份是一个合理想法的直觉。

如果您确实使用更简单的模型作为备份，您还应该以相同的方式验证其输出并回退到启发式或如果它们未通过您的检查则显示错误。

验证模型的输出是否在合理范围内是一个好的开始，但这还不够。在下一节中，我们将介绍我们可以围绕模型构建的额外保护措施。

过滤模型

除了不总是值得信赖之外，使用模型的置信度分数还有另一个严重的缺点。为了获得这个分数，无论是否使用其预测，都需要运行整个推理管道。例如，当使用需要在 GPU 上运行的更复杂的模型时，这尤其浪费。理想情况下，我们希望在不运行模型的情况下估计模型在示例上的表现如何。

这就是过滤模型背后的想法。由于您知道模型难以处理某些输入，因此您应该提前检测它们，而不用在它们上运行模型。过滤模型是输入测试的 ML 版本。它是一个二元分类器，经过训练可以预测模型是否会在给定示例上表现良好。这种模型之间的核心假设是，对于主要模型来说很难的数据点类型存在趋势。如果这些困难的例子有足够多的共同点，过滤模型可以学习将它们与更简单的输入分开。

以下是您可能希望过滤模型捕获的一些类型的输入：

• 与主模型在其上表现良好的输入在质量上不同的输入

• 模型接受过训练但遇到困难的输入

• 意在愚弄主要模型的对抗性输入

在图 10-4中，您可以看到图 10-2中逻辑的更新示例，其中现在包含一个过滤模型。如您所见，过滤模型仅在输入检查通过时运行，因为您只需要过滤掉可能进入“运行模型”框的输入。

要训​​练过滤模型，您只需收集包含两类示例的数据集；您的主要模型成功的类别和它失败的其他类别。这可以使用我们的训练数据来完成，不需要额外的数据收集！

图 10-4。在我们的输入检查中添加过滤步骤（粗体）

在图 10-5中，我展示了如何通过利用经过训练的模型及其在数据集上的结果来做到这一点，如左图所示。对模型正确预测的一些数据点和模型预测失败的一些数据点进行采样。然后，您可以训练一个过滤模型来预测哪些数据点是原始模型失败的数据点。

图 10-5。获取过滤模型的训练数据

一旦你有了训练有素的分类器，训练过滤模型就相对简单了。给定一个测试集和一个训练有素的分类器，下面的函数就可以做到这一点。

def get_filtering_model(classifier, features, labels):
    """
    Get prediction error for a binary classification dataset
    :param classifier: trained classifier
    :param features: input features
    :param labels: true labels
    """
    predictions = classifier.predict(features)
    # Create labels where errors are 1, and correct guesses are 0
    is_error = [pred != truth for pred, truth in zip(predictions, labels)]

    filtering_model = RandomForestClassifier()
    filtering_model.fit(features, is_error)
    return filtering_model

这个方法被谷歌用于他们的智能回复功能，它建议对收到的电子邮件进行一些简短的回复（参见 A. Kanan 等人的这篇文章，“智能回复：电子邮件的自动回复建议”）。他们使用他们所谓的触发模型，负责决定是否运行建议响应的主模型。在他们的案例中，只有大约 11% 的电子邮件适合这种模式。通过使用过滤模型，他们将基础设施需求减少了一个数量级。

过滤模型通常需要满足两个标准。它应该很快，因为它的全部目的是减少计算负担，并且应该善于消除困难的情况。

试图识别疑难案例的过滤模型不需要能够捕获所有案例；它只需要检测到足以证明在每次推理时运行它的额外成本是合理的。通常，过滤模型越快，所需的效率就越低。原因如下：

假设您仅使用一个模型的平均推理时间是i.

使用过滤模型的平均推理时间为f+i(1-b)其中f是过滤模型的执行时间，b是它过滤掉的示例的平均比例（b 代表块）。

要通过使用过滤模型减少平均推理时间，您需要具备f+i(1-b)<i, 转化为fi<b.

这意味着您的模型过滤掉的案例比例需要高于其推理速度与较大模型速度之间的比率。

例如，如果您的过滤模型比常规模型快 20 倍（fi=5%), 它需要阻止超过 5% 的案例 (5%<b) 在生产中有用。

当然，您还需要确保过滤模型的精度良好，这意味着它阻止的大部分输入实际上对您的主模型来说太难了。

一种方法是定期让一些示例通过您的过滤模型会阻止并检查您的主要模型如何处理它们。我们将在“选择要监控的内容”中更深入地介绍这一点。

由于过滤模型不同于推理模型，专门为预测困难案例而训练，因此它可以比依赖主模型的概率输出更准确地检测这些案例。因此，使用过滤模型有助于降低出现不良结果的可能性并提高资源利用率。

由于这些原因，将过滤模型添加到现有的输入和输出检查中可以显着提高生产管道的稳健性。在下一节中，我们将通过讨论如何将 ML 应用程序扩展到更多用户以及如何组织复杂的训练过程来解决更多使管道健壮的方法。

笔记

如果您使用深度学习模型，您可能需要 GPU 才能在可接受的时间内提供结果。如果是这种情况，并且您希望有足够多的请求来需要多个支持 GPU 的机器，则您应该在两个不同的服务器上运行您的应用程序逻辑和模型推理。

由于 GPU 实例通常比大多数云提供商的常规实例贵一个数量级，因此使用一个更便宜的实例扩展您的应用程序，而 GPU 实例仅处理推理将显着降低您的计算成本。使用此策略时，您应该记住，您正在引入一些通信开销，并确保这不会对您的用例造成太大损害。

机器学习缓存

缓存是将结果存储到函数调用的做法，以便将来可以通过简单地检索存储的结果来更快地调用具有相同参数的此函数。缓存是加速工程流水线的常见做法，对 ML 非常有用。

图 10-8。部署同一模型的更新版本似乎是一个简单的更改

再现性

至跟踪并重现错误，您需要知道哪个模型正在生产中运行。为此，需要保留经过训练的模型和训练它们的数据集的存档。每个模型/数据集对都应分配一个唯一标识符。每次在生产中使用模型时都应记录此标识符。

在图 10-9中，我将这些要求添加到加载和保存框中，以表示这增加了 ML 管道的复杂性。

除了能够为现有模型的不同版本提供服务外，生产流水线还应该致力于在不造成重大停机的情况下更新模型。

弹力

启用应用程序在更新后加载新模型需要构建一个进程来加载更新的模型，理想情况下不会中断对用户的服务。这可能包括启动一个为更新模型提供服务的新服务器，并缓慢地将流量转移到它，但对于更大的系统来说，它很快就会变得更加复杂。如果新模型表现不佳，我们希望能够回滚到之前的模型。正确地完成这两项任务具有挑战性，并且传统上被归类在 DevOps 领域。虽然我们不会深入介绍这个领域，但我们将在第 11 章介绍监控。

生产变更可能比更新模型更复杂。它们可以包括对数据处理的大量更改，这些更改也应该是可部署的。

流水线灵活性

我们以前看到改进模型的最佳方法通常是通过迭代数据处理和特征生成。这意味着模型的新版本通常需要额外的预处理步骤或不同的特征。

这种变化不仅反映在模型二进制文件中，而且通常会与应用程序的新版本相关联。因此，当模型进行预测时，还应记录应用程序版本，以使该预测可重现。

这样做会给我们的流水线增加另一层复杂性，如图 10-10中添加的预处理和后处理框所示。这些现在也需要是可复制和可修改的。

部署和更新模型具有挑战性。在构建服务基础架构时，最重要的方面是能够重现模型在生产中运行的结果。这意味着将每个推理调用与运行的模型、训练模型的数据集以及为该模型提供服务的数据管道版本相关联。