使用我们新完成的模型和特征集，我们可以为数据集中的每个用户训练一个个性化的分类器。确切地说，对每个用户的训练集，我们为每封邮件计算活跃的特征桶 featureIndices 以及它们的特征值 featureValue。给定这些已观测变量，我们随后可以应用期望传播来学习每个桶的后验 weight 分布，以及对 threshold 值的单个后验分布。但首先我们需要看看如何为我们的模型安排消息传递。

并行调度与顺序调度

推断深入

在这个可选小节中，我们看看如何为我们的模型安排期望传播消息的调度。如果你想直接去看运行期望传播的结果，尽可跳过本节。

在这个模型中运行期望传播时，选择一个好的消息传递调度很重要。在这种模型中，糟糕的调度很容易导致消息传递算法无法收敛或收敛得非常慢。当你有一个带重复结构的模型（例如我们的分类模型）时，可以使用两种主要的消息传递调度：顺序调度或并行调度。为理解这两种调度，让我们看看在一个简化形式的模型上的消息传递，它有两个特征和两个权重：

图 4.13 两种调度

在这幅图中，我们没有使用跨越各桶的板，而是为每个权重复制了模型的相应部分。在这个模型中做消息传递时，两种调度选择是：

  • 顺序调度，依次处理两个权重。对第一个权重，这种调度按 A、A1、B1、B 的顺序传递消息。处理完这个权重后，消息传递在图的下半部分发生（未显示）。然后调度转到第二个权重，按 A、A2、B2、B 的顺序传递消息。
  • 并行调度，一次处理两个权重。在这种调度中，首先传递标记为 A 的消息。然后同时传递两组消息（A1 和 B1）与（A2 和 B2），其中来自加号因子的消息使用之前的 B1 和 B2 消息来计算。最后，传递标记为 B 的消息。

为看出两种调度的差异，看看从加号因子出来的第一条 A2 消息是如何计算的。在顺序调度中，它使用本次调度迭代中刚刚更新的 B1 消息来计算。在并行调度中，它使用上一次迭代中计算的 B1 消息，换句话说，是一个较旧版本的消息。因此，并行调度比顺序调度收敛得更慢，也更可能完全无法收敛。那么我们为什么会想使用并行调度呢？主要原因是如果你想把推断计算并行分布到若干台机器上以加速它。在这种情况下，最好的选择是使用一种组合调度：在每台机器内部处理的模型部分上是顺序的，但跨机器是并行的。

可视化学到的权重

为确保这个顺序调度工作良好，我们可以可视化学到的权重分布，以检查它们是否符合我们的预期。图 4.13 显示了 User35CB8E5 每个特征桶权重上学到的高斯分布（为节省空间，只显示了最频繁的十五个 Sender 权重）。

图 4.13

图 4.13：User35CB8E5 各特征桶权重上学到的高斯分布。对每个特征桶，蓝色条表示高斯权重分布的均值，显示系统期望该特征桶使一封邮件的 score 增加或减少多少。误差条通过显示均值上下各一个标准差来表示这个学到的值的不确定性。

依次查看每个权重，我们可以看到，鉴于上一节的直方图，更正的权重通常对应于那些我们预期有更高回复概率的特征桶。例如，看看图 4.12c 的 SubjectLength 直方图，你可以看到正的和负的学到的权重对应于直方图的峰和谷。你还可以看到，对于像 SubjectLength [33-64] 这样常见的特征桶，误差条比像 SubjectLength [1-2] 这样罕见的特征桶更窄。这是意料之中的，因为如果某个特征桶处于活跃状态的邮件更少，关于该桶权重的信息就更少，因此学到的权重后验就更不确定。对于非常罕见的桶，训练集中相关的邮件如此之少，以至于我们应当预期权重后验非常接近 Gaussian(0,1) 先验。例如，你可以看到 SubjectLength [1-2] 就是这样，其权重均值接近 0.0，标准差接近 1.0。所以，总体而言，对学到的权重的人工检查与我们可能预期的情况一致。检查其他用户学到的权重也显示出合理的权重分布。

假如我们在这里发现了一些出乎意料的权重值，最可能的解释会是特征计算中的一个 bug。不过，出乎意料的权重值也可能揭示出我们对用户可能回复哪类邮件的错误直觉，甚至让我们发现我们可能没有猜到的新型邮件回复行为。

评估回复预测

使用为每个用户训练好的模型，我们现在可以为用户验证集中的每封邮件预测一个回复概率。正如我们在第 2 章中看到的，我们可以绘制一条 ROC 曲线来评估这些预测的准确性。对每个用户这样做，得到图 4.14 中的图。

图 4.14

图 4.14：使用每个用户验证集上的预测所计算的、数据集中每个用户的 ROC 曲线。图例给出了每个用户的曲线下面积（AUC）。

这些曲线看起来非常有希望——用户之间有一些变化，但所有曲线都在 ROC 图的左上方，正是我们想要它们所在的位置。但这些图告诉我们所需知道的了吗？鉴于我们的目标是识别具有特定行为（或没有行为）的邮件，我们需要知道两件事：

  • 在所有被回复的邮件中，我们预测会被回复的占多大比例？

这是真正例率，ROC 曲线已经在其 y 轴上给出了它。在这个语境中，真正例率也被称为召回率（recall），因为它衡量系统成功“召回”了多少被回复的邮件。

  • 在我们预测会被回复的邮件中，实际被回复的占多大比例？

这是一个新的量，称为精确率（precision），未显示在 ROC 曲线上。注意，这里的 precision 一词与它作为描述高斯分布逆方差的参数（精度）的用法含义不同——通常从上下文可以清楚是哪个含义。为可视化精确率，我们必须改用精确率-召回率曲线（precision-recall curve，P-R 曲线），它是 y 轴为精确率、x 轴为召回率的图。图 4.15 显示了与图 4.14 中 ROC 曲线完全相同的预测结果的精确率-召回率曲线。关于精确率和召回率的更多讨论，见 [Powers, 2008]。

要为精确率-召回率曲线得到一个概括的准确性数字（类似于 ROC 曲线下的面积），我们可以在一段召回率范围内计算平均精确率（average precision，AP）——这些显示在图 4.15 的图例中。精确率-召回率曲线在左端往往非常嘈杂，因为在这一点上精确率是从非常少量的邮件计算得来的——因此，我们在 0.1 到 0.9 的召回率之间计算平均精确率，以给出一个更稳定、更可靠的准确性指标。同样省略图的右端有助于修正因忽略图左端而导致的平均精确率下降。

图 4.15

图 4.15：与图 4.14 的 ROC 曲线相同预测结果的精确率-召回率曲线。图例给出了每个用户的平均精确率（AP），以及该用户回复的验证集邮件的百分比。

比较 ROC 曲线和精确率-召回率曲线——我们再一次看到使用不止一个评估指标的价值：精确率-召回率曲线讲述了一个非常不同的故事！它们显示，我们为不同用户所达到的精确率有相当大的变异性，而且拥有最高精确率-召回率曲线的用户（例如 User68251CD）并非拥有最高 ROC 曲线的用户（例如 User6AACED）。那么这是怎么回事呢？

为帮助理解这个差异，考虑一个随机预测回复或不回复的分类器。这样一个分类器的 ROC 曲线就是图 4.14 中标记为“Random”的对角线。为绘制一个随机分类器的 P-R 曲线，我们需要考虑它会把邮件的某个随机子集分类为正例，因此这些邮件中真正例的比例（精确率）就是用户总体上回复的邮件比例。所以如果一个用户回复其 20% 的邮件，我们会预期一个随机分类器有 20% 的精确率。如果另一个用户回复其 2% 的邮件，我们可能预期一个随机分类器有 2% 的精确率。我们每个用户回复的邮件比例在图 4.15 的图例中给出，跟在平均精确率之后。User68251CD 回复的邮件百分比最高，为 23.6%，这意味着我们可能预期为该用户得到更高的精确率会更容易——而该用户确实有最高的平均精确率，尽管其 ROC 曲线只是中等。反过来，拥有最高 ROC 曲线之一的 User6AACED，却只有中等的 P-R 曲线，因为这个用户只回复其 3.2% 的邮件。鉴于我们的两个误差指标给了我们不同的信息，我们如何用它们来评估成功？我们如何为这些指标设定目标值？答案在于记住，我们把像 AP 和 AUC 这样的指标只当作我们真正关心的东西——用户的幸福感和生产力——的代理。因此我们需要理解我们指标的值如何映射到用户对系统的体验。

理解用户的体验

用户体验

一旦系统被大量用户进行 beta 测试，我们就可以使用显式反馈（例如问卷）或隐式反馈（例如人们处理邮件的速度或有多少人关闭了这个特征/功能）来评估在评估指标的特定值下，用户有多幸福/多高效。然而，在开发系统的早期阶段，我们必须使用我们自己对系统在我们自己邮件上表现如何的判断。

为理解我们的评估指标如何映射到真实用户的体验，尽快让一些用户使用系统是至关重要的，即使这些用户只是团队成员。为此，我们需要一个可工作的端到端系统，包括一个用户界面，可用于定性地评估系统表现如何。拥有一个可工作的用户界面尤为重要，因为用户界面的选择对底层机器学习系统施加了要求。例如，如果邮件要在不给出任何视觉提示的情况下从用户收件箱中移除，那么非常高的精确率就是必不可少的。反过来，如果邮件只是被轻轻地弱化但仍留在原处，那么可以容忍较低的精确率，这允许较高的召回率。这些例子表明，用户界面和机器学习系统需要彼此很好地匹配。用户界面应被仔细设计以容忍机器学习组件所犯的任何错误，同时最大化其对用户的价值（见 [Patil, 2012]）。一个精心设计的用户界面很容易决定用户是否采用某个特定的机器学习系统。

为我们的目的，我们需要一个模拟邮件客户端、但也以某种视觉方式显示回复预测概率的用户界面。图 4.16 显示了作为一个评估和调试工具而创建的合适用户界面。

图 4.16

图 4.16：评估和调试工具用户界面的截图，它允许在真实邮件上评估系统的准确性。该工具还为每封邮件暴露了计算出的特征、学到的权重和预测的回复概率，这使调试系统更容易。回复概率的彩色背景表示，对于当前的截断阈值，预测是真正例（绿色）、假正例（橙色）、还是真负例或假负例。为保护此处所示邮件用户的隐私，邮件内容已被隐藏，所有发件人和收件人的身份已被匿名化。

该工具有一个截断回复概率阈值，可通过滑块调整——预测回复概率高于此阈值的邮件被预测为会被回复，所有其他邮件被预测为不会被回复。给定这个截断阈值，该工具还标记哪些邮件被正确分类、哪些是假正例或假负例。对预测概率使用阈值再次强调了良好校准的重要性。如果系统的校准很差，或者因用户而异，那么就更难找到一个能带来良好体验的截断阈值。我们预测的校准可以被绘制和评估，如专栏 4.3 所述。

专栏 4.3　校准

如果一个机器学习系统给出的预测概率是准确的，那么它就是良好校准的 [Dawid, 1982]。例如，如果一个良好校准的系统以 90% 的概率预测某个事件，那么我们应当预期这个事件有 90% 的时间会发生。评估任何机器学习系统的校准都很重要，因为：

  • 我们经常需要能够信赖来自系统的概率。例如，它们可能被用来驱动一个随预测概率而变化的用户界面（例如只标记某个概率以上的邮件）。如果这些概率要被用作另一个机器学习系统的输入，那么准确的概率就尤为重要。
  • 如果一个机器学习系统校准很差，那么它提示要么模型有问题（例如一个过于严格的假设），要么近似推断有问题。修复这个问题不仅会改善校准，通常也会改善预测准确性。

我们可以使用一个校准图来评估我们的邮件模型校准得如何。为此，我们取为每个用户做出的所有验证集预测，并按预测的回复概率（0-10%、11-20% 等）把它们分到各个箱中。对每个箱，我们随后计算实际被回复的邮件比例（我们丢弃邮件太少的箱，因为那样这个比例会非常嘈杂）。最后，我们把这个比例在各用户上的平均值对预测概率作图，如下所示。

平均校准曲线

该图还显示了一个完美校准系统的线，即一条对角线。我们的系统校准得相当好（在这条对角线约 0.1 以内）。我们可以通过测量我们离这条对角线有多远来得到一个总体校准指标——例如，使用均方根误差（RMSE）差异，对我们的系统给出 0.094。

出于调试目的，该工具显示每封邮件活跃的特征桶以及相应的特征值和学到的权重分布。这对于检查特征计算是否正确极有帮助，因为原始邮件和计算出的特征被并排显示在一起。

使用这个工具，我们可以定性地评估系统在回复概率某个特定阈值下工作得如何。看了许多不同的邮件后，我们发现尽管精确率表面上看起来中等，系统似乎工作得非常好。这是因为一部分表面上不正确的预测实际上是合理的，例如：

  • 假正例：用户“回应”了邮件，但不是通过直接回复。这可能是因为他们没有使用邮件就回应了发件人（例如：当面、通过电话或通过即时消息），或者通过给发件人写一封新邮件、或通过回复另一封不同的邮件来回应。
  • 假正例：用户打算回复，但忘记了或没有时间。
  • 假负例：用户回复了一封邮件，作为回复会话线程中更早一封邮件的手段。
  • 假负例：用户回复了一封邮件并删除了内容/主题，作为给发件人开始一封新邮件的方式。

在这全部四种情况下，预测实际上是正确的：在前两种情况下这是用户想要回复的邮件，在后两种情况下则不是。问题在于我们对该项目所持有的“真实标签”不正确，因为一个用户是否想要回复一封邮件被假定为与他们实际是否回复相同。但在这四种情况下，并非如此。在本章稍后我们将看看如何处理这种带噪声的真实标签。

由于真实标签被用来评估系统，这种不正确的标签会对测得的准确性产生很大的不利影响。例如，如果 25% 的正例邮件被错误地标记为负例，那么一个完美分类器测得的精确率将只有 75% 而非 100%。如果 5% 的负例邮件也被错误地标记为正例，那么对于一个回复其 10% 邮件的用户，一个完美分类器的召回率将只有 62.5%！为看出这个数字从何而来，考虑用户收到的 1000 封邮件。用户会回复其中 100 封（10%），因此不会回复 900 封。在被回复的邮件中，只有 75%（=75 封）会被标记为正例；在未被回复的邮件中，900 封的 5% = 45 封会被错误地标记为正例。所以一个完美分类器会在被标记为正例的 75+45=120 封邮件中的 75 封上做出正例预测，这意味着测得的召回率将是 $\frac{75}{120} = 62.5\%$。

然而，即使考虑到带噪声的真实标签，仍然有若干个真正错误的不正确预测。这些的例子有：

  • 假负例：邮件是对用户所发邮件的回复，但发件人是新的或通常不被回复的。
  • 假负例：邮件是一封转发，但发件人是新的或通常不被回复的。
  • 假负例：发往用户所拥有或管理的分发列表的邮件，因此很可能会被回复。
  • 假正例：直接发给用户的时事通讯/营销/社交网络邮件（有时被称为“灰色邮件”，graymail），特别是当发件人是新的时候。

我们现在来看看如何修改特征集来处理其中一些不正确的预测。

改进特征集

前两种不正确的预测是假负例预测，其中邮件是对来自用户的一封邮件的回复、或对发给用户的一封邮件的转发。这些错误发生是因为没有既有的特征能区分这些情况和来自同一发件人的一封新邮件——然而如果邮件是回复或转发，回复概率很可能非常不同。这违反了假设 4.7，即用户是否会回复仅取决于特征值。为修复这个问题，我们需要引入一个新特征来区分这些情况。我们可以通过检查主题行上的前缀——它是“re:”、“fw:”、“fwd:”等等——来检测回复和转发。图 4.17 显示了训练集和验证集中，对已知前缀、未知前缀（other）或完全没有前缀的邮件被回复的比例。该图显示，用户确实更有可能回复作为回复或转发的消息，因此一个 SubjectPrefix 特征可能是有信息量的。

图 4.17

图 4.17：对于具有不同主题前缀（re、fw/fwd）、未知前缀（other）或完全没有前缀的邮件，被回复的邮件比例。

这幅图没有告诉我们的是，这个新特征是否在我们特征集中已有特征之外提供了额外信息。为检查它是否如此，我们需要在有和没有这个新特征的情况下评估特征集。图 4.18 给出了在我们的特征集有和没有 SubjectPrefix 特征的情况下，每个用户和平均的 ROC 曲线下面积和平均精确率。

图 4.18a 初始结果

(a) 初始结果

图 4.18b 加入 SubjectPrefix 特征

(b) 加入 SubjectPrefix 特征

图 4.18：对每个用户和总体，先前特征集以及加入了新 SubjectPrefix 特征的特征集的评估结果。平均而言，加入 SubjectPrefix 特征使曲线下面积和平均精确率都略有改善。

这些结果表明，这个新特征有时增加准确性，有时降低准确性，取决于用户（无论你看哪个指标）。然而，平均而言，加入这个特征后准确性有所改善，这表明我们应当把它保留在特征集中。注意，平均精确率是比曲线下面积更敏感的指标——因此在判断一个特征的有用性时它更有帮助。还值得记住的是，任一评估指标都只给出一个总体图景。虽然像这样的头条准确性数字很有用，但始终也查看底层预测同样重要。为此我们可以回到工具，检查加入这个特征是否减少了回复/转发邮件的假负例数量。使用工具，我们发现情况确实如此，但也发现我们现在对一次会话的最后一封邮件稍微更可能得到假正例。这是因为一次会话的最后一封邮件与之前几封之间唯一的差异是消息内容，而我们通过特征集对它的访问有限。虽然不正确，但这样的假正例对用户来说可以相当可接受，因为用户界面会把这次会话带到用户的注意范围内，允许他们决定是否继续这次会话。所以我们以增加较少数量的、用户可接受的假正例为代价，去除了一些对用户来说相当刺眼的假负例。

我们发现的下一种错误是通过分发列表收到的邮件的假负例。在这些情况下，用户很可能回复在某些分发列表上收到的邮件，但不回复其他分发列表上的。我们面对这种错误的挑战是，邮件往往有多个收件人，而如果用户没有被明确命名，可能无法判断哪些收件人是分发列表、以及这些分发列表中哪个包含用户。例如，如果一封邮件被发往三个不同的分发列表，而用户在其中一个上，可能无法判断是哪一个。

为绕过这个问题，我们可以添加一个 Recipients 特征，捕捉邮件的所有收件人，理由是它们中（至少）会有一个对应于用户。同样，这有助于符合假设 4.7，因为我们将不再忽略一个相关的信号：邮件收件人的身份。我们可以类似于 Sender 特征那样设计这个特征，只不过该特征的多个桶会同时有非零值，每个收件人一个。这样做时我们必须非常小心，以确保我们新的 Recipients 特征符合我们模型的假设。一个关键假设是单个特征对总 score 的贡献通常在 -1.0 到 1.0 的范围内，因为一个桶的权重通常取该范围内的值，而我们一直使用 1.0 的特征值。但现在，如果我们有一封有二十个收件人的邮件，那么就有二十个桶活跃——如果每个桶的特征值为 1.0，那么 Recipients 特征通常会对总 score 贡献 -20.0 到 20.0 之间。换句话说，Recipients 特征对最终预测的影响，对一封有二十个收件人的邮件会是一封有一个收件人的邮件的二十倍。直觉上这没有道理，因为一封有更多收件人的邮件不应仅因为收件人多就获得系统性更高或更低的 score。为解决这个问题，我们对每个特征桶使用 1.0 除以活跃桶数量的特征值，使得特征值之和总是为 1.0。这就是我们计算 Recipients 特征值的方式。

图 4.19a 无 Recipients 特征

(a) 无 Recipients 特征

图 4.19b 有 Recipients 特征

(b) 有 Recipients 特征

图 4.19：先前不含 Recipients 特征的特征集、以及含 Recipients 特征的特征集的评估结果。

图 4.19 中的对比结果比之前的更为明确：在大多数情况下，加入 Recipients 特征后准确性指标都上升了。即使在某个指标没有上升的地方，它也很少下降很多。平均而言，我们看到 AUC 上升 0.2%，AP 上升 0.8%。这些在指标上看起来可能是小的上升，但它们实际上相当显著。使用交互式工具告诉我们，平均精确率上升 1% 会给系统的感知准确性带来非常明显的改善，特别是如果这个变化纠正了特别刺眼的不正确预测。例如，假设某个用户拥有某个特定分发列表，并频繁回复列表上的帖子。没有 Recipients 特征时，系统很可能会对这样的邮件做出不正确的预测，这对作为分发列表所有者的用户来说会相当刺眼。通过加入 Recipients 特征来修复这个问题，尽管只带来头条 AUC 和 AP 准确性数字的微小改善，却会大幅改善用户的体验。

我们现在可以自由地去处理列表上的下一个问题，并修改特征集来尝试解决它。例如，处理“灰色邮件”问题会需要一个查看邮件内容的特征——事实上一个词特征在这个任务上工作得很好。对于与 Exchange 团队的项目，我们继续增加和优化特征集，在每个阶段确保评估指标在改善、且真实邮件上的错误正在使用工具被修复。最终我们达到了准确性指标非常好、定性准确性也很好的阶段。此时你可能认为我们准备好为一些 beta 测试者部署系统了——但在真实的机器学习系统中，事情从来没有那么容易……

本页引入概念回顾

召回率（recall）：真正例率的另一个术语，常在我们试图从一个大数据集中找出罕见的正例项时使用。召回率是这些项中被成功找到（“召回”）的比例，因此等于真正例率。

精确率（precision）：正例预测中正确的比例。精确率通常与召回率互补，即更高的精确率意味着更低的召回率，反之亦然。精确率常在关注正例预测准确性的应用中被用作评估指标。例如，在搜索引擎中，关注点是作为结果被检索到的文档的准确性，因此可能会用一个精确率指标来评估这个准确性。

这种精确率不应与也被称为精度的高斯分布逆方差相混淆。在实践中，这两个术语用在非常不同的语境中，因此两者之间的混淆很少见。

精确率-召回率曲线（precision-recall curve）：随系统某个参数（例如预测概率的阈值）变化时，机器学习系统的精确率对召回率的图。当正例预测的概率相对较低时，精确率-召回率曲线对评估预测准确性很有用。

下图显示了从图 4.15 复制的一些精确率-召回率曲线。

精确率-召回率曲线

平均精确率（average precision）：精确率-召回率曲线中一段召回率范围内的平均精确率，用作一个定量的评估指标。如果使用召回率的完整范围，这实际上就是 P-R 曲线下的面积。然而，曲线最左端往往被排除在这个平均之外，因为那里的精确率测量由于是从非常少量的数据项计算得来而不准确。

参考文献

[Powers, 2008] Powers, D. (2008). Evaluation: From Precision, Recall and F-Factor to ROC, Informedness, Markedness and Correlation. Machine Learning Technologies., 2:37–63.

[Patil, 2012] Patil, D. J. (2012). Data Jujitsu: The Art of Turning Data into Product. O’Reilly Media.

[Dawid, 1982] Dawid, A. P. (1982). The Well-Calibrated Bayesian. Journal of the American Statistical Association, 77(379):605–610.

下一节：随邮件到达而学习