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

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

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

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

企业里用 Azure OpenAI 的场景越来越多——内部知识库、自动化流程、客服助手、安全运营，几乎每个团队都想接进去用。但真正让AmalUBasnayake 停下来想一想的是这个问题：怎么让应用安全地访问 AI 服务，同时把不必要的网络暴露降到最低，还能保护好身份、凭据和敏感数据？

如果 AI 处理的是公司内部数据、敏感系统或者受保护的资源，这个问题就不只是"锦上添花"了。

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

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

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

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

有一次收到 Azure 的通知邮件，大体内容如下：

Important update: Eligibility for Quota Tier upgrade

We are pleased to inform you that, based on your recent usage and account standing, your subscription is now eligible for an upgrade from your current Tier (Free Tier) to the next Tier (Tier 1) within our AI Services platform.

我就去翻了翻 Microsoft Foundry 关于配额等级（Quota tiers）的文档，把这次邮件里真正发生的变化记下来，也顺便把几组常用模型的数字放在一起。

本文整理自 Microsoft Learn 的 Quotas and limits 文档。该页面显示的更新时间是 2026 年 7 月 29 日；配额表还会调整，部署前最好再看一眼 Foundry 门户里的实时值。

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

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

普通办公室职员每天花在处理电子邮件上的时间将近三个小时。这些时间中约 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，那么这个游戏结果就非常令人意外。这个结果表明我们当前对技能值的评估不太准确，因此我们应当对技能值做大得多的调整。简而言之，意外的程度指示了应当对技能值做多大的改变。我们将看到，在一个合适的模型中执行推断会自动给出这种行为。