可视化步骤

作为我们在前面的章节中已经看到，虽然指标是建模工作的重要组成部分，但定期检查和调查我们的数据同样重要。开始时只观察几个例子可以更容易地注意到变化或不一致。

此过程的目标是定期检查更改。如果您将数据管道视为装配线，您会希望在每次有意义的更改后检查产品。这意味着在每一行检查数据点的值可能过于频繁，并且仅查看输入和输出值肯定不足以提供足够的信息。

在图 6-3中，我展示了几个示例检查点，您可以使用它们来查看数据管道。在此示例中，我们分多个步骤检查数据，从原始数据开始一直到建模输出。

接下来，我们将介绍一些通常值得检查的关键步骤。我们将从数据加载开始，然后继续进行清理、特征生成、格式化和模型输出。

数据加载

无论您正在从磁盘或通过 API 调用加载数据，您需要验证其格式是否正确。此过程与您在执行 EDA 时经历的过程类似，但在您构建的管道上下文中完成，以验证没有错误导致数据损坏。

它是否包含您期望的所有字段？这些字段中是否有任何字段为空或具有常量值？是否有任何值位于看似不正确的范围内，例如年龄变量有时为负数？如果您正在处理文本、语音或图像，这些示例是否符合您对它们的外观、声音或读起来的期望？

我们的大部分处理步骤都依赖于我们对输入数据结构所做的假设，因此验证这方面至关重要。

因为这里的目标是识别我们对数据的期望与现实之间的不一致，所以您可能想要可视化不止一个或两个数据点。可视化一个有代表性的样本将确保我们不仅观察到一个“幸运”的例子，而且错误地假设所有数据点都具有相同的质量。

图 6-4显示了本书 GitHub 存储库中数据集探索笔记本中的案例研究示例。在这里，我们存档中的数百篇帖子属于未记录的帖子类型，因此需要过滤掉。在图中，您可以看到 PostTypeId 为 5 的行，数据集文档中未引用该行，因此我们将其从训练数据中删除。

图 6-4。可视化几行数据

一旦您确认数据符合数据集文档中规定的预期，就可以开始处理它以用于建模目的了。这从数据清理开始。

清洁和功能选择

这大多数管道的下一步是删除任何不必要的信息。这可以包括模型不会使用的字段或值，也可以包括任何可能包含我们的模型在生产中无法访问的标签信息的字段（请参阅“拆分数据集”）。

什么时候生成新功能，例如在 kickstarter 活动的描述中添加对产品名称的引用频率，检查其值很重要。您需要检查特征值是否已填充以及这些值是否合理。这是一项具有挑战性的任务，因为它不仅需要识别所有特征，还需要为这些特征中的每一个估计合理的值。

作为我们在前面的章节中已经讨论过，在将数据点传递给模型之前，您需要将它们转换为模型可以理解的格式。这可以包括规范化输入值、通过以数字方式表示文本来矢量化文本，或将黑白视频格式化为 3D 张量（请参阅“矢量化”）。

在我在处理多个图像分割问题方面的经验，例如，标签和模型预测之间的数据不匹配是最常见的错误原因之一。分割模型使用分割掩码作为标签。这些掩码与输入图像大小相同，但它们包含每个像素的类标签，而不是像素值。不幸的是，不同的库使用不同的约定来表示这些掩码，因此标签通常以错误的格式结束，从而阻碍了模型的学习。

我在图 6-5中说明了这个常见的陷阱。假设一个模型期望为某个类别的像素传递值为 255 的分割掩码，否则为 0。如果用户假设掩码中包含的像素值应为 1 而不是 255，则他们可能会以“提供”中看到的格式传递其标记的掩码。这将导致面具被认为几乎完全是空的，并且模型将输出不准确的预测。

图 6-5。格式不正确的标签将阻止模型学习

同样，分类标签通常表示为零列表，在真实类别的索引处有一个零。一个简单的差一错误可能导致标签被移动，并且模型学习始终预测偏移一的标签。如果您不花时间查看您的数据，则此类错误很难排除。

因为 ML 模型将设法适应大多数数字输出，无论它们是否具有准确的结构或内容，所以这个阶段是许多棘手错误发生的地方，而这种方法对于找到它们很有用。

这是我们案例研究中此类格式化函数的示例。我生成了我们问题文本的矢量化表示。然后，我将附加功能附加到此表示中。由于该函数由多个转换和向量运算组成，可视化该函数的返回值将使我能够验证它是否按照我们预期的方式格式化数据。

def get_feature_vector_and_label(df, feature_names):
    """
    Generate input and output vectors using the vectors feature and
     the given feature names
    :param df: input DataFrame
    :param feature_names: names of feature columns (other than vectors)
    :return: feature array and label array
    """
    vec_features = vstack(df["vectors"])
    num_features = df[feature_names].astype(float)
    features = hstack([vec_features, num_features])
    labels = df["Score"] > df["Score"].median()
    return features, labels

features = [
    "action_verb_full",
    "question_mark_full",
    "text_len",
    "language_question",
]

X_train, y_train = get_feature_vector_and_label(train_df, features)

什么时候特别是处理文本数据时，在为模型正确格式化数据之前通常涉及多个步骤。从文本字符串到标记化列表再到包含潜在附加功能的矢量化表示是一个容易出错的过程。即使在每一步检查物体的形状也有助于发现许多简单的错误。

一旦数据采用适当的格式，您就可以将其传递给模型。最后一步是可视化和验证模型的输出。

模型输出

在首先，查看输出有助于我们了解模型的预测类型或形状是否正确（如果我们预测房价和市场持续时间，我们的模型是否输出两个数字的数组？）。

此外，当仅将模型拟合到几个数据点时，我们应该看到它的输出开始与真实标签相匹配。如果模型不适合数据点，这可能表明数据格式不正确或已损坏。

如果模型的输出在训练期间根本没有改变，这可能意味着我们的模型实际上没有利用输入数据。在这种情况下，我建议参考“站在巨人的肩膀上”来验证模型是否被正确使用。

一旦我们完成了几个示例的整个管道，就该编写一些测试来自动化一些可视化工作了。

系统化我们的视觉验证

去通过前面描述的可视化工作有助于捕获大量错误，并且是对每个新管道的良好时间投资。验证关于数据如何流经模型的假设有助于节省大量时间，现在可以将这些时间用于专注于训练和泛化。

然而，管道经常变化。当您迭代更新不同方面以改进您的模型并修改一些处理逻辑时，您如何保证一切仍按预期工作？每次进行任何更改时，通过管道并在所有步骤中可视化一个示例很快就会让人厌烦。

这就是我们之前讨论的软件工程最佳实践发挥作用的地方。是时候隔离这个管道的每个部分，并将我们的观察结果编码成测试，我们将能够在我们的管道发生变化时运行这些测试，以验证它。

分离你的顾虑

只是与常规软件一样，ML 从模块化组织中受益匪浅。为了使当前和未来的调试更容易，请将每个函数分开，以便您可以在查看更广泛的管道之前检查它是否单独工作。

一旦管道被分解成单独的功能，您就可以为它们编写测试。

数据通常在磁盘或数据库中序列化。将数据从存储移动到我们的管道时，我们应该确保验证数据的完整性和正确性。我们可以从编写测试开始，以验证我们加载的数据点是否具有我们需要的所有功能。

以下是三个测试，用于验证我们的解析器是否返回正确的类型（数据框），是否定义了所有重要的列，以及是否所有功能都为空。您可以在本书的 GitHub 存储库的测试文件夹中找到我们将在本章（以及其他内容）中介绍的测试。

def test_parser_returns_dataframe():
    """
    Tests that our parser runs and returns a DataFrame
    """
    df = get_fixture_df()
    assert isinstance(df, pd.DataFrame)


def test_feature_columns_exist():
    """
    Validate that all required columns are present
    """
    df = get_fixture_df()
    for col in REQUIRED_COLUMNS:
        assert col in df.columns


def test_features_not_all_null():
    """
    Validate that no features are missing every value
    """
    df = get_fixture_df()
    for col in REQUIRED_COLUMNS:
        assert not df[col].isnull().all()

我们还可以测试每个特征的类型并验证它不为空。最后，我们可以通过测试它们的平均值、最小值和最大值来编码我们对这些值的分布和范围的假设。最近，出现了诸如Great Expectations之类的库，可以直接测试特征的分布。

在这里，您可以看到如何编写一个简单的均值检验：

ACCEPTABLE_TEXT_LENGTH_MEANS = pd.Interval(left=20, right=2000)

def test_text_mean():
    """
    Validate that text mean matches with exploration expectations
    """
    df = get_fixture_df()
    df["text_len"] = df["body_text"].str.len()
    text_col_mean = df["text_len"].mean()
    assert text_col_mean in ACCEPTABLE_TEXT_LENGTH_MEANS

这些测试使我们能够验证，无论在存储端或数据源的 API 上进行了哪些更改，我们都可以知道我们的模型可以访问它最初训练的同类数据。一旦我们对我们摄取的数据的一致性有信心，让我们看看管道中的下一步，即数据处理。

测试数据处理

后测试进入管道起点的数据是否符合我们的预期，我们应该测试我们的清理和特征生成步骤是否符合我们的预期。我们可以从为我们拥有的预处理功能编写测试开始，验证它确实按照我们的预期进行。此外，我们可以为数据摄取测试编写类似的测试，并专注于保证我们对进入模型的数据状态的假设是有效的。

这意味着在我们的处理管道之后测试数据点的存在、类型和特征。以下是对生成的特征是否存在、它们的类型以及最小值、最大值和平均值进行测试的示例：

def test_feature_presence(df_with_features):
    for feat in REQUIRED_FEATURES:
        assert feat in df_with_features.columns

def test_feature_type(df_with_features):
    assert df_with_features["is_question"].dtype == bool
    assert df_with_features["action_verb_full"].dtype == bool
    assert df_with_features["language_question"].dtype == bool
    assert df_with_features["question_mark_full"].dtype == bool
    assert df_with_features["norm_text_len"].dtype == float
    assert df_with_features["vectors"].dtype == list

  def test_normalized_text_length(df_with_features):
    normalized_mean = df_with_features["norm_text_len"].mean()
    normalized_max = df_with_features["norm_text_len"].max()
    normalized_min = df_with_features["norm_text_len"].min()
    assert normalized_mean in pd.Interval(left=-1, right=1)
    assert normalized_max in pd.Interval(left=-1, right=1)
    assert normalized_min in pd.Interval(left=-1, right=1)

这些测试使我们能够注意到管道的任何变化，这些变化会影响我们模型的输入，而无需编写任何额外的测试。当我们添加新功能或更改模型的输入时，我们只需要编写新测试。

我们现在可以对我们摄取的数据和我们对其应用的转换充满信心，所以是时候测试管道的下一部分，即模型了。

测试模型输出

相似地对于前两个类别，我们将编写测试来验证模型输出的值是否具有正确的维度和范围。我们还将测试特定输入的预测。这有助于主动检测新模型中预测质量的回归，并确保我们使用的任何模型始终根据这些示例输入产生预期的输出。当一个新模型显示出更好的综合性能时，很难注意到它的性能是否在特定类型的输入上变差了。编写此类测试有助于更轻松地检测此类问题。

在以下示例中，我首先测试模型预测的形状及其值。第三个测试旨在通过​​保证模型将特定措辞不佳的输入问题分类为低质量来防止回归。

def test_model_prediction_dimensions(
    df_with_features, trained_v1_vectorizer, trained_v1_model
):
    df_with_features["vectors"] = get_vectorized_series(
        df_with_features["full_text"].copy(), trained_v1_vectorizer
    )

    features, labels = get_feature_vector_and_label(
        df_with_features, FEATURE_NAMES
    )

    probas = trained_v1_model.predict_proba(features)
    # the model makes one prediction per input example
    assert probas.shape[0] == features.shape[0]
    # the model predicts probabilities for two classes
    assert probas.shape[1] == 2


def test_model_proba_values(
    df_with_features, trained_v1_vectorizer, trained_v1_model
):
    df_with_features["vectors"] = get_vectorized_series(
        df_with_features["full_text"].copy(), trained_v1_vectorizer
    )

    features, labels = get_feature_vector_and_label(
        df_with_features, FEATURE_NAMES
    )

    probas = trained_v1_model.predict_proba(features)
    # the model's probabilities are between 0 and 1
    assert (probas >= 0).all() and (probas <= 1).all()


def test_model_predicts_no_on_bad_question():
    input_text = "This isn't even a question. We should score it poorly"
    is_question_good = get_model_predictions_for_input_texts([input_text])
    # The model classifies the question as poor
    assert not is_question_good[0]

我们首先目视检查数据以验证它在我们的整个管道中仍然有用和可用。然后，我们编写测试以保证这些假设随着我们的处理策略的发展而保持正确。现在是处理图 6-2的第二部分的时候了，调试训练程序。

这您的问题越多样化和复杂，模型从中学习所需的数据就越多。对于您的模型学习模式，您的目标应该是为您拥有的每种数据类型提供许多示例。例如，如果您将猫的图片归类为一百种可能的品种之一，那么您需要的图片要比您只是想区分猫和狗需要的图片多得多。事实上，您需要的数据量通常会随着类别的数量呈指数级增长，因为类别越多意味着错误分类的机会就越大。

最后，大多数数据集包含异常值，即与其他数据点完全不同的数据点，模型很难处理。从训练集中移除异常值通常可以通过简化手头的任务来提高模型的性能，但这并不总是正确的方法：如果您认为您的模型可能会在生产中遇到相似的数据点，则应该保留异常值并集中注意力改进你的数据和模型，使模型能够成功地适应它们。

数据集越复杂，就越有助于研究表示数据的方法，这将使模型更容易从中学习。让我们看看这意味着什么。

数据表示

如何仅使用您为模型提供的表示来检测您关心的模式是否容易？如果一个模型在训练数据上表现不佳，您应该添加使数据更具表现力的特征，从而帮助模型更好地学习。

这可能包括我们之前决定忽略但可能具有预测性的新特征。在我们的 ML Editor 示例中，模型的第一次迭代仅考虑了问题正文中的文本。在进一步探索数据集之后，我注意到问题标题通常可以提供很多关于问题好坏的信息。将该特征重新合并到数据集中可以让模型表现得更好。

通常可以通过迭代现有功能或以创造性的方式组合它们来生成新功能。我们在“让数据为特征和模型提供信息”中看到了一个这样的例子，当时我们研究了将星期几和月份中的某一天结合起来以生成与特定业务案例相关的特征的方法。

在某些情况下，问题出在您的模型上。接下来我们看看这些案例。

型号容量

增加数据质量和改进功能通常会带来最大的好处。当模型是性能不佳的原因时，通常意味着它不足以完成手头的任务。正如我们在“从模式到模型”中看到的，特定的数据集和问题需要特定的模型。一个不适合某项任务的模型将难以对其执行，即使它能够过拟合一些示例。

看的时候在训练完成之前验证损失和训练损失，验证性能可能看起来比训练性能更好。这是因为随着模型的训练，训练损失在整个时期累积，而验证损失是在时期完成后使用最新版本的模型计算的。

图 6-10。过度拟合与欠拟合

正则化

正则化增加对模型表示信息的能力的惩罚。正则化旨在限制模型关注许多不相关模式的能力，并鼓励它选择更少、更具预测性的特征。

不同的正则化方法有不同的效果。L1 正则化可以通过将无信息的功能设置为零来帮助选择信息功能（在“套索（统计）”维基百科页面上信息）。当通过鼓励模型仅利用其中一个特征来关联某些特征时，L1 正则化也很有用。

正则化方法也可以是特定于模型的。神经网络通常使用 dropout 作为正则化方法。Dropout 在训练期间随机忽略网络中一定比例的神经元。这可以防止单个神经元变得过于有影响力，从而使网络能够记住训练数据的各个方面。

对于基于树的模型，例如对于随机森林，减少树的最大深度会降低每棵树对数据过度拟合的能力，从而有助于规范森林。增加森林中使用的树木数量也会使其正规化。

防止模型过度拟合训练数据的另一种方法是使数据本身更难过度拟合。我们可以通过称为数据扩充的过程来做到这一点。

数据扩充

数据扩充是通过稍微改变现有数据点来创建新训练数据的过程。目标是人为地生成不同于现有数据点的数据点，以便将模型暴露给更多样化的输入类型。增强策略取决于数据类型。在图 6-11中，您可以看到一些潜在的图像增强。

图 6-11。图像数据增强的几个例子

数据增强使训练集不那么均匀，因此更复杂。这使得训练数据的拟合更加困难，但在训练期间将模型暴露给更广泛的输入。数据增强通常会降低训练集的性能，但会提高未见数据（例如验证集和生产中的示例）的性能。如果我们可以使用扩充使我们的训练集更类似于自然环境中的示例，则此策略特别有效。

我曾经帮助一位工程师使用卫星图像来检测飓风过后被洪水淹没的道路。该项目具有挑战性，因为他只能访问非洪水城市的标记数据。为了帮助提高他的模型在飓风图像上的表现，飓风图像明显更暗且质量更低，他们建立了增强管道，使训练图像看起来更暗和更模糊。这降低了训练性能，因为现在道路更难被发现。另一方面，它提高了模型在验证集上的性能，因为增强过程将模型暴露在与它在验证集中遇到的图像更相似的图像中。数据增强有助于使训练集更具代表性，从而使模型更加健壮。

如果在使用前面描述的方法后模型在验证集上仍然表现不佳，您应该迭代数据集本身。

在在某些情况下，困难的训练/验证拆分会导致模型欠拟合并在验证集上挣扎。如果一个模型在其训练集中仅暴露于简单的示例而在其验证集中仅暴露于具有挑战性的示例，则它将无法从困难的数据点中学习。类似地，某些类别的示例在训练集中的代表性可能不足，从而阻止模型从中学习。如果训练模型以最小化聚合指标，则它可能适合大多数类，而忽略少数类。

虽然增强策略可以提供帮助，但重新设计训练分组以使其更具代表性通常是最好的前进道路。这样做时，我们应该小心控制数据泄漏，并使拆分在难度方面尽可能平衡。如果新的数据拆分将所有简单的示例分配给验证集，则模型在验证集上的性能会人为地高，但不会转化为生产结果。为了减轻对数据拆分可能质量不均的担忧，我们可以使用k 折交叉验证，我们执行 k 个连续的不同拆分，并测量模型在每个拆分上的性能。

一旦我们平衡了我们的训练和验证集以确保它们具有相似的复杂性，我们的模型的性能应该会提高。如果性能仍然不令人满意，我们可能只是在解决一个非常困难的问题。