在之前的文章里我提过，现在的大模型已经足够聪明，却始终解决不了一件事：怎么跟使用者的价值观对齐。这段时间我又留意到一个更具体的现象，我们一边拼命教大模型像人一样思考、像人一样做事，一边又受不了它真的需要跟人商量。

这个要求本身没问题。让大模型学会像人一样处理事情，是脑力劳动能被替代、人的负担能被减轻的前提，方向没有错。但只要往前多走一步就会发现，大模型给出的任何规划都绕不开跟人协同这件事。总有一些关键的判断和决策，只能由人来拿主意，它自己走不出电脑那一步，那一步还得人去补。可我们一边希望它像机器一样不吃不睡、连轴转，一边又见不得它真的需要人插手：它做的事总有需要收尾、需要人兜底的地方，让人没法完全放心；等它真按要求把决策权交回来，跟人配合，我们又嫌它一点人味都没有，理解不了它为什么非要这样。这个矛盾挺有意思，我们既想要一个像人一样思考的工具，又不想承担一个像人一样需要沟通的伙伴该有的成本。

过去一年多，大模型的变化越来越明显。它们不再只是等待提问、生成答案的语言工具，越来越像 agent 的执行引擎。以前我们要让一个模型真正做事，往往需要在外围搭很多东西：上下文管理、检索、工具调用、流程编排，每一步都要由开发者事先安排好。现在，不少模型已经能够自己理解目标，判断是否需要调用工具，再根据工具返回的结果继续往下做。

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

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

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

正如我们在上一章第 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 消息，换句话说，是一个较旧版本的消息。因此，并行调度比顺序调度收敛得更慢，也更可能完全无法收敛。那么我们为什么会想使用并行调度呢？主要原因是如果你想把推断计算并行分布到若干台机器上以加速它。在这种情况下，最好的选择是使用一种组合调度：在每台机器内部处理的模型部分上是顺序的，但跨机器是并行的。

最近在给 Foundry 上的托管代理配置对外能力时，碰到了一个绕不开的问题：怎么让别的 agent 框架也能发现我这个代理、跟它对话。翻了一圈 Microsoft Foundry 的文档，发现官方已经把 Agent-to-Agent（A2A）协议接进了托管代理里，跨框架、跨技术栈的代理之间能直接打通。原文在这儿：Enabling A2A endpoint and Agent Card for a Hosted Agent（原文作者 srisatyakrishna5，发布于 2026 年 8 月 24 日）。我把自己跑通的过程和踩的坑整理了一下。

要使用我们的分类模型，我们需要设计特征来变换数据，使其尽可能贴近地符合模型中内置的假设（表 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 与该特征权重之积。注意，我们添加了一个跨越各特征的新板，其中包含该特征的权重、特征值和特征分数。值和分数也在各邮件板内，因为它们逐邮件变化，而权重在外面，因为它在所有邮件间共享。

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

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

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

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

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

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