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

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

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

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

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

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

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

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

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

我们已经看到，置信传播使我们能够在图 3.10 的模型中计算变量 Jskill 的精确边缘后验分布。虽然 Jskill 的先验分布是一个由两个参数描述的高斯，但后验分布不是高斯，而是一个需要四个参数的更复杂分布。为阻止参数数量在每局游戏后不断增加，我们需要一种方法用具有固定数量参数的分布来近似这个真实的后验，为此我们选择高斯。这样后验分布就会与先验具有相同的函数形式，模仿共轭先验的行为。如果我们能做到这一点，就能把所得的近似后验分布当作下一局游戏的先验分布。这样，每个玩家的技能将始终由一个仅受两个参数支配的高斯分布表示。

第一个问题是如何用一个高斯来近似一个非高斯分布。一个简单的解法是求出该非高斯分布的均值和方差，然后选一个具有相同均值和方差的高斯作为我们的近似。事实证明这是一个合理的近似，它可以通过优化两个概率分布不相似性的某种度量来形式化地推导出来 [Bishop, 2006; Minka, 2005]。

我们也许会因此想干脆直接用一个高斯来近似 Jskill 的精确后验分布。虽然这对图 3.10 的因子图会令人满意地奏效，但当我们转向更复杂的因子图（例如本章后面将遇到的那些）时，它又会失效。具有简单函数形式的消息在穿过因子后往往会变得更复杂。当我们把模型扩展到更大、更精巧的图时，很快就会遇到消息无法被精确计算的情形。这类问题可以通过在每个因子节点处局部地做近似来避免，从而使所有消息都具有所需的分布类型。这确保了只要每个因子都能使用适当的分布类型向所有相邻的变量节点发送近似消息，因子就可以被组合成任意的图。

下面这一小节会深入这类近似推断算法的数学细节。如果你想跳过这些细节，尽可直接看下一节。

推断深入探讨

在这个可选小节中，我们引入期望传播这一近似推断技术，我们将在本书中广泛使用它。如果你想专注于建模，尽可跳过本小节。

回到图 3.12（为方便起见在图 3.21 中重现），我们看到消息 (6) 是我们遇到的第一个非高斯消息。

……

到目前为止，我们假设已经知道 Jill 和 Fred 的技能，并用这些技能计算了每个玩家成为胜者的概率。在实践中，我们必须反向推理：我们观察到谁赢得了游戏，并需要用这个信息来了解玩家的技能值。因此，我们转向学习玩家技能这一问题。

在任何游戏中，看到谁胜谁负都会告诉我们关于玩家技能的信息。

给定一局游戏的结果，提高胜者的技能值、降低败者的技能值似乎是合理的。然而，不太清楚的是我们应当做多大的调整。直觉上我们可以这样推理。假设 Jill 是这局游戏的胜者。如果 Jill 的技能显著高于 Fred，那么 Jill 获胜并不令人意外，因此技能值的变化应当相对较小。如果技能相近，那么较大的变化就有道理。然而，如果 Jill 的技能显著低于 Fred，那么这个游戏结果就非常令人意外。这个结果表明我们当前对技能值的评估不太准确，因此我们应当对技能值做大得多的调整。简而言之，意外的程度指示了应当对技能值做多大的改变。我们将看到，在一个合适的模型中执行推断会自动给出这种行为。

我们的目标是构建一个能够评估在线游戏玩家技能的系统。作为迈向这一目标的第一步，我们需要先考察一个更简单的问题：在已经知道相关玩家技能的情况下，预测一局游戏的结果。这将使我们发展出解决“确定技能”这一更复杂问题所需的许多概念。

假设 Jill 将在 Xbox Live 上与 Fred 玩一局《光环》。在第 2 章中，我们用一个二值变量来表示一个人的软件开发技能，指示此人是否具备某项特定技能。当我们考虑一个人在《光环》这类典型 Xbox 游戏中的技能时，这种做法就不够用了，因为可能的技能水平存在很宽的谱系。相反，用一个连续值来表示一个人的技能更为合适。因此，我们的第一条建模假设是：

每一天，全世界数以百万计的玩家登录 Xbox Live®，在数百款不同的游戏里彼此对战。他们的乐趣取决于是否能被匹配到实力相当的其他玩家，从而获得良好的游戏体验。那么，我们如何用基于模型的机器学习来自动匹配实力相近的玩家呢？

对于游戏而言，在线世界的一大优势在于随时随地都能找到对手，无论白天黑夜。Xbox Live 的一项重要需求，是能够找到技能水平相当的对手，以便让玩家获得愉快的游戏体验。这一需求意味着系统必须有办法估计玩家的技能。然而，要做到这一点会面临一些重大挑战——尤其是，实力更强的玩家并不总能赢得一局游戏。许多游戏都带有运气成分，在某一局中运气可能会偏向较弱的玩家。更普遍地说，一名玩家的表现会因疲劳或热情起伏等因子而在不同对局之间发生变化。因此，我们不能假设某一局的胜者一定比败者技能更高。另一方面，我们确实预期实力更强的玩家在与较弱玩家的对局中，赢的次数会多于输的次数，所以对局结果确实能提供关于玩家相对技能的有用信息。

回到第 1 章处理谋杀之谜时，我们首先从犯罪现场收集证据，然后运用我们自己的知识来构建这起谋杀的概率模型。我们以观测变量的形式，把犯罪现场的证据整合进模型，并执行推断来回答我们关心的查询：每个嫌疑人是凶手的概率是多少？随后我们评估推断的结果是否足够好——也就是说，概率是否高到足以认定谋杀已被侦破？当结果不够好时，我们便收集更多数据、扩展模型、重新运行推断，最终达到了我们的目标概率。

在第 2 章评估求职者技能时，我们从参加真实测试的人那里收集数据并对这些数据进行了可视化。然后我们基于对人们如何做测试的知识建立了一个模型。我们运行了推断，并评估出结果不够好。我们诊断了问题、扩展了模型，然后对原始模型和扩展后的模型都进行了评估，以量化改进程度，并检查改进后的模型是否达到了我们的成功标准。

我们可以从这两个例子出发进行归纳，定义出任何基于模型的机器学习应用所需的步骤：

1. 收集用于训练和评估模型的数据。
2. 收集知识，以帮助做出恰当的建模假设。
3. 可视化数据，以更好地理解它、检查数据问题，并获得对有用建模假设的洞见。
4. 构建一个模型，使其捕捉关于问题领域的知识，并与你对数据的理解相一致。
5. 执行推断，利用数据来固定其他变量的取值，从而对我们关心的变量做出预测。
6. 使用某种评估指标来评估结果，看它们是否满足目标应用的成功标准。

在（通常的）系统第一次未能满足成功标准的情况下，还需要额外的两个步骤：

你可能以为，推断猜测概率需要用到与我们目前所用完全不同的技术。事实上，我们的做法将完全相同：我们把想要学习的概率值作为新的连续随机变量加入模型，并用概率推断来计算它们的后验分布。这展示了基于模型方法的威力——每当我们想知道某个东西时，我们就把它作为一个随机变量引入模型，然后用概率推断去求出它。

让我们看看如何修改模型，把猜测概率作为随机变量纳入进来。为了保持一致，我们也会为犯错概率（实际上是不犯错概率）添加一个变量，但我们会把它固定在 10% 的犯错几率上。首先，我们要改变书写 AddNoise 因子的方式。

(a) 内置概率的自定义因子

(b) 通用的 Table 因子

图 2.25：书写 AddNoise 因子的两种方式：(a) 作为一个把猜测和犯错概率“内置”其中的自定义因子。(b) 使用一个通用的 Table 因子，它带有两个参数：给定父节点为 false 时子节点为 true 的概率（左参数），以及给定父节点为 true 时子节点为 true 的概率（右参数）。这种书写因子的方式让我们可以把这些概率作为变量提供给因子。

图 2.25 展示了如何把现有的 AddNoise 因子（其中猜测和不犯错概率被硬编码为 0.2 和 0.9）替换为一个通用的 Table 因子，后者把这些概率作为额外的参数。然后我们可以用两个新的随机变量来设置这些参数，我们把它们命名为 probGuess 和 probNoMistake。推断这些变量的后验分布，就会给出我们所需的猜测和不犯错概率的学习值——但为此，我们首先需要一种能表示这类变量不确定性的分布。

只要跟正在把 Microsoft Foundry 往生产环境搬的企业团队聊过，我几乎都会听到同一条底线：智能体不能跑在公网上。它一旦碰到专有数据、内部 API 或者受监管的负载，安全团队就要求把它塞进公司自己的虚拟网络里，藏在专用终结点、中心防火墙和受控 DNS 后面。这种拓扑，也就是一个 Foundry Standard 智能体被注入到 自带（BYO）VNet 里，正是大多数大型组织真正推到生产的形态。也恰恰是在这里，很多团队的首次部署悄无声息地卡住了。