无论你钟情于音乐、书籍、电影还是电子游戏，一条好的推荐都能带来实实在在的乐趣——还能帮助那些名气不大的作品走入聚光灯下。但一个人眼中的新经典，另一个人可能会一口断定为烂作。能否用一个模型来理解一个人的喜好与厌恶，理解得足够透彻，从而提供量身定制的推荐呢？

各行各业的零售商都渴望向他们的顾客做出准确、个性化的推荐。然而，开发一套自动推荐系统所需的专业能力和投入，超出了许多零售商——尤其是较小的零售商——的承受范围。作为替代方案，这类零售商可以转向云端，利用在线推荐服务。

阅读全文

到目前为止，我们能够一次性在大量邮件上训练我们的模型。但对我们的应用而言，我们需要能够在用户回复一封新邮件时、或在明确用户不会回复它时，立即从这封邮件中学习。我们不能等到收到大量邮件后，再一次性在它们上面训练、然后永远使用训练好的模型。相反，我们必须随着新邮件的到来持续训练模型，并始终使用最新训练好的模型来做预测。

正如我们在上一章第 3.3 节中看到的，我们可以使用在线学习在收到新训练数据时持续更新我们的模型。在我们的模型中，在线学习很直接：对每一批自上次训练以来到达的邮件，我们把之前对 weight 和 threshold 的后验分布用作训练的先验。一旦对这一批的训练完成，对 weight 和 threshold 的新后验分布就可以用来做预测。之后当训练下一批邮件时，这些后验分布将充当新的先验。我们可以通过把训练数据分成若干批、并在每一批到来时运行在线学习，来检查这个过程工作得如何。然后我们可以把这种方法与离线训练相比较，离线训练一次性呈现到该时间点为止见过的所有训练数据。图 4.20 显示了使用离线训练、或使用不同批量大小的在线训练时，在全部 10 个用户上平均的 AUC 和 AP。

(a) 曲线下面积

(b) 平均精确率

图 4.20：随着越来越多训练邮件变得可用时的预测准确性，在全部 10 个用户上平均。对每个指标，离线曲线显示如果我们在到该时间点为止收到的所有邮件上从头重新训练模型的准确性。另外四条曲线显示如果我们改为在每 1、5、10 或 50 封邮件后做在线训练以增量更新模型的准确性。

阅读全文

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

并行调度与顺序调度

推断深入

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

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

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

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

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

阅读全文

要使用我们的分类模型，我们需要设计特征来变换数据，使其尽可能贴近地符合模型中内置的假设（表 4.3）。例如，为满足假设 4.7（即特征包含与用户行为相关的所有信息），我们需要确保我们的特征集包含所有与预测回复相关的特征。由于一封邮件几乎任何部分都可能有助于做出这样的预测，这意味着我们将不得不在特征中编码邮件的几乎所有方面。这将包括谁发送了邮件、收件人栏和抄送栏上的收件人、邮件的主题以及邮件的正文，还有关于该邮件所属会话的信息。

在设计一个新特征时，我们需要确保：

• 该特征捕捉到数据中某个有信息量的方面；
• 该特征的输出具有适合输入到模型的正确形式；
• 该特征提供了关于标签的新信息，超出了既有特征所提供的信息。

在本节中，我们将展示如何为我们的特征集设计若干新特征，同时确保它们满足上述前两条标准。在下一节中，我们将展示如何通过在有和没有某些特征的情况下评估系统，来检查第三条标准。

具有多个状态的特征

到目前为止，我们用一个 ToLine 特征来表示用户出现在邮件中的位置。这个特征只有两个状态：用户要么在收件人栏中，要么不在。因此这个特征忽略了用户是否在抄送栏中，尽管我们可能预期用户在出现在抄送栏中时比完全不出现时更有可能回复邮件。这个特征还忽略了用户在收件人/抄送栏上的位置。如果用户排在收件人栏的第一位，我们可能预期他比排在一长串收件人末尾时更有可能回复。我们可以用我们的数据集来检验这些直觉，方法是找出在若干情形下所有训练/验证邮件中实际被回复的比例：当用户在收件人栏中排第一、第二或第二之后时，当用户在抄送栏中排第一或其他位置时，以及当用户既不在收件人栏也不在抄送栏时（例如，如果他通过邮件列表收到邮件）。

图 4.8 绘制了这些比例，显示回复概率确实会根据适用于哪种情形而有很大变化。这幅图表明，一个能够区分这些情形的特征确实会捕捉到数据中有信息量的方面（即我们上面的第一条标准）。在评估回复比例（例如图 4.8 中的那些）时，重要的是要考虑该比例是从多少封邮件计算得来的，因为从少量邮件计算出的比例不会很准确。为检查这一点，在图 4.8 中我们在每个条形标签下方的括号中显示了邮件数量，表明每个情形都有足够的邮件来准确计算比例，因此我们可以信赖所计算的值。

阅读全文

仅用一个特征时，我们的分类模型在预测回复方面并不太准确，因此我们现在将扩展它以处理多个特征。我们可以通过改变模型、使多个特征对一封邮件的 score 都有贡献来做到这一点。我们只需决定如何做，这涉及做出一个额外的假设：

• 某个特征值的某个特定变化，无论其他特征的值是多少，都会引起相同的 score 变化。

让我们考虑把这个假设应用于 ToLine 特征，并考虑把它从 0.0 改为 1.0。这个假设是说，无论其他特征值是多少，由这个特征值变化所导致的 score 变化总是相同的。这个假设可以在模型中这样编码：确保 ToLine 特征对 score 的贡献总是被加到所有其他特征的贡献之上。由于同样的论证对其他每个特征也成立，这个假设意味着一封邮件的 score 必须是各个特征各自 score 贡献之和。

因此，在我们的多特征模型（图 4.5）中，我们有一个 featureScore 数组，用于保存每封邮件中每个特征的 score 贡献。随后我们可以使用一个确定性求和因子把这些贡献加在一起，得到总 score。由于我们仍希望假设 4.3 对每个特征成立，一个特征的 featureScore 可以像之前一样定义为 featureValue 与该特征权重之积。注意，我们添加了一个跨越各特征的新板，其中包含该特征的权重、特征值和特征分数。值和分数也在各邮件板内，因为它们逐邮件变化，而权重在外面，因为它在所有邮件间共享。

阅读全文

为一个数据项预测标签（例如“回复”或“不回复”）的问题称为分类（classification）。执行分类的系统被称为分类器（classifier），它们大概是当今使用最广泛的机器学习算法。可用的分类算法有许多种，而对某个特定的预测任务，有些会比另一些效果更好。解决分类问题的一种常见做法是尝试几种不同的分类算法，看看哪一种效果最好。这种做法忽略了分类算法在相同数据上做出不同预测的根本原因：每个算法都隐含地对数据做出了不同的假设。遗憾的是，这些假设被隐藏在每个算法的内部。

你可能会惊讶地得知，许多分类算法都可以被解释为在某个概率模型中进行近似推断。因此，与其运行一个分类算法，我们不如构建相应的模型，并使用一个推断算法来做分类。我们为什么要这样做，而不直接使用分类算法呢？因为一种基于模型的分类方法给我们带来若干好处：

• 分类器中的假设被显式化。这有助于我们理解分类器在做什么，从而让我们可以改进使用它的方式以获得更好的预测准确率。
• 我们可以修改模型来提升其准确率，或赋予它超出原分类器能力之外的新能力。
• 我们可以使用标准的推断算法来同时训练模型和做出预测。这在修改模型时特别有用，因为训练和预测算法会与修改后的模型保持同步。此外，不同的算法在速度与准确率之间有不同的权衡。我们可以选择最适合我们需求的算法，同时保留我们所有的建模假设。

这些好处并不小——在本章中，你将看到这三点如何都对交付一个成功的系统至关重要。我们将展示如何从零开始、通过对给定数据项时标签如何产生做出一系列假设，来构建一个广泛使用的分类器的模型。随后我们将展示如何扩展这个最初的分类模型，以实现邮件分类系统所需的各种能力。在模型演化的整个过程中，我们将使用一个标准的推断算法（期望传播）来做训练和预测。

阅读全文

为了撰写本章，我们开发了一个工具，用于收集某个人在给定时间段内收到的全部电子邮件。随后我们用这个工具从 10 位志愿者那里收集了邮件，他们慷慨地同意分享自己的邮件数据——以匿名化的形式，我们稍后会讨论这一点。这是一个相当耗时的过程，因此我们需要仔细规划将如何使用这些宝贵的邮件数据。例如，我们需要决定用哪些数据来训练、用哪些数据来评估系统的准确率。极其重要的一点是，用于训练的数据不能用于评估。如果训练数据被用于评估，它会给出误导性的偏高准确率结果——因为当你已经被告知正确答案时，对一封邮件做出预测要容易得多！为避免这一点，我们需要把数据划分为不同的数据集：

阅读全文

收发电子邮件的庞大数量意味着，一名典型的办公室职员每天要花好几个小时来处理自己的收件箱。源源不断涌入的新邮件很容易让人应接不暇。同时，一封重要邮件淹没在杂乱信息中的可能性也比以往任何时候都大。基于模型的机器学习能否帮助减轻这种信息过载呢？

普通办公室职员每天花在处理电子邮件上的时间将近三个小时。这些时间中约 90% 花在阅读收到的邮件或管理已有的邮件上——只有剩下的 10% 用于撰写或回复邮件 [Outlook team, 2008]。一个能加快阅读和管理邮件速度的自动工具，将为人们腾出大量时间，让他们能够专注于重要任务，避免信息过载带来的压力。

阅读全文

至此，我们似乎已经为本章开头提出的问题找到了一个全面的解决方案。我们有了一个关于多支玩家队伍之间游戏（含平局）的概率模型，其中更简单的情形（两名玩家、个人而非队伍、无平局的游戏）作为特例出现。然而，当这个系统面向真实的 beta 测试者部署时，人们发现它的配对并不总是令人满意。特别是，某些玩家的技能值似乎“卡”在了较低的取值上，即使这些玩家已经打了很多游戏并有了很大进步，从而导致糟糕的配对。

阅读全文

到目前为止，我们已经为两名玩家之间、以其中一方获胜告终的一局游戏构建了一个概率模型。为处理 Xbox Live 所需的各种各样的游戏，我们需要扩展我们的模型以应对若干额外的复杂性。具体而言，真实游戏可能以平局结束、可能涉及超过两名玩家、并且可能在多支队伍之间进行。现在我们将展示如何扩展最初的模型以考虑这些复杂性。这种灵活性很好地说明了基于模型的机器学习方法的强大之处。

具体来说，我们需要扩展我们的模型，使它能够：

• 在结果为平局时更新技能；
• 对团队游戏，更新各个团队成员的技能；
• 适用于超过两名玩家的游戏。

基于模型的方法允许以透明的方式并入这些扩展，从而产生一个能够处理上述所有复杂性、同时仍保持可理解、可维护的解决方案。

如果一局游戏可能以平局结束怎么办？

在我们当前的模型中，在某一局游戏中表现值较高的玩家就是那局的赢家。对于也可能以平局结束的游戏，我们可以引入平局边界（draw margin）这一概念来修改这个假设：只有当一名玩家的表现超过另一名玩家至少一个平局边界的值时，他才是赢家。数学上这可以表达为

阅读全文