既然我们的建模工具箱里有了门，我们就可以扩展过敏模型，让不同的孩子能够拥有不同的过敏获得与丢失模式。你也许还记得，在第 6.2 节中，我们想要做的模型改动是编码这个修改后的假设：

5 与特定过敏原初始致敏、获得致敏或保持致敏相关的概率，对每个致敏类别中的所有孩子都是相同的。

这个假设要求每个孩子都属于某个致敏类别，但我们并不知道每个孩子属于哪个类别。我们可以用一个针对每个孩子的 sensClass 随机变量来表示这种未知的类别归属，它取值为 $0, 1, 2, \dots$，取决于孩子在类别 0、类别 1，等等。因为这个变量可以取多于两个的值，我们不能用 Bernoulli 分布来表示它的不确定取值。相反，我们需要一个离散分布（discrete distribution），它是 Bernoulli 分布向“取多于两个值的变量”的推广。

门允许因子图的一部分被打开或关闭。

在上一节中，我们看到了如何通过手工推断一个“在多个可选过程之间做选择”的随机变量上的后验分布，来比较这些可选过程。现在我们将看到如何通过定义一个合适的模型、并在该模型内执行推断来完成同样的计算。为此，我们需要一种新的建模结构，它允许在模型中表示各种可选项。我们可以用来做这件事的建模结构称为门（gate），如 Minka and Winn [2009] 所述。

门把因子图的一部分包围起来，并根据一个称为选择变量（selector variable）的随机变量的状态来打开或关闭这部分。当选择变量取某个特定值（称为键，key）时，门是打开的；对所有其他取值，门是关闭的。图 6.11 的因子图中展示了一个门的例子。门以一个虚线矩形表示，键值（true）位于左上角。选择变量 selector 有一条边连接到门——边上的箭头表明门被视为选择变量的子节点。当 selector 等于 true 时，门是打开的，于是 x 服从 Bernoulli(0.2) 分布。否则门是关闭的，x 服从均匀分布，因为此时它没有连接到任何因子。

在前面所有章节中，我们都假设数据源自单一的潜在过程。但现在我们不能再这样假定了，因为我们预期：会发展出过敏和哮喘的孩子与不会发展出的孩子，遵循的是不同的过程。为了处理这类可选过程，我们需要引入一种新的建模技术。

这种技术将使我们能够：

• 在单个模型中表示多个可选过程；
• 评估每个可选过程产生某个特定数据项（例如某个特定孩子的数据）的概率；
• 比较两个或更多不同的模型，看看哪一个最能解释某些数据。

为了介绍这项新技术，我们暂时把哮喘项目放在一边，转而看一个双过程情形的简单例子（如果你更愿意继续聚焦于哮喘项目，可以直接跳到第 6.5 节）。既然我们身处医学领域，有一个绝佳的双过程情形可用：随机对照试验。随机对照试验是一种临床试验，常用于检验各类医疗干预（如新药）的有效性。在这类试验中，每个受试者被随机分配到治疗组（接受实验性干预）或对照组（不接受干预）。试验的目的是判断实验性干预是否对一个或多个关注的结局有影响，并理解这种影响的性质。

现在我们有了一个完整的模型，可以在一些研究数据上试验它了。正如本书前面多次强调的，在使用真实数据集时，务必仔细查看数据集，确保它是完整、正确且符合你预期的形式。请记住，许多常见的机器学习问题都是由数据问题引起的（例如第 2.5 节中列举的那些）。检查数据集的一个好办法是构建可视化，让你一眼就能看清它的样子。在本例中，我们需要为每个孩子、每种过敏原和每个时间点创建检测结果的可视化。然而，这个研究数据集包含私密的医疗数据，因此我们无法在本书中公开分享这些数据，哪怕是以可视化的形式。从这次可视化中我们学到的最重要一点是：数据集中有大量检测结果缺失。

当存在缺失数据时，总是值得分析一下它们为什么缺失。在图 6.6 中，我们绘制了数据集中每个年龄、每种检测类型的检测结果数量（无论阳性还是阴性）。

图 6.6：为两类检测各自记录的检测结果，按孩子的年龄拆分。

你可以在图 6.6 中看到几种不同的缺失数据模式。首先，图中显示某些年龄和检测类型对特定过敏原完全没有数据。例如，花生在 1 岁和 3 岁完全没有结果，5 岁时只有 IgE 结果。霉菌完全没有 IgE 结果，1 岁时也没有皮肤试验结果。其次，越早的年龄缺失数据越多，尤其是 1 岁。第三，图中显示 IgE 检测总体上比皮肤试验缺失得多。我们需要把所有这些缺失数据点的影响考虑进来。

原文：Voice agents in Foundry Agent Service: architecture, trust boundaries, and real-audio latency

以前做企业语音智能体，得自己把语音服务、实时模型、轮次检测和工具编排拼在一起，每个环节出问题也都得自己兜底。Foundry Agent Service 里的语音智能体（voice agents）把这一整套多服务方案收拢成一个带版本的托管智能体，运行时的工程量少了很多，但身份、授权、数据、网络、留存和运维这些事仍然得企业自己扛。

本文整理自 Microsoft Foundry 博客的 Evaluating Voice Agents: How Reliable Are Foundry’s Multi-turn Evaluators?，作者是 Sheng Liu、Shivank Goel 和 Morteza Ziyadi。

做语音 Agent 的团队迟早会撞上一个现实：每天几千通电话，Agent 还隔三差五更新，光靠人工听录音根本跟不上，只能上自动评估。Microsoft Foundry 给的办法是多轮评估器，它会看完整段对话，评估 Agent 的行为和结果。

本文整理自 Microsoft Foundry 博客的 Closing the AI Agent Governance Gap with Microsoft Foundry，作者是 Alexandra Miller-Browne。

开发者上线 Agent 的速度，已经快过安全团队给它们登记造册的速度。组织从试点走向同时运行几十个甚至上百个 Agent 之后，总会反复冒出同一个问题：我到底怎么才能看清整个环境里有哪些 AI Agent？

这篇文章讲的是如何借助 Azure 的现有服务，为 AI 资产建立可见性、护栏和成本归属。读完我最大的感受是，它并没有让你另起炉灶，而是把大多数组织手上已经有的身份、网络和合规控制，接到 Agent 这套新东西上。

我们的首要目标是通过在 MAAS 数据中寻找规律，来加深对过敏发展（及其与儿童哮喘之间关系）的理解。为了理解本研究中的相关数据，我们需要先了解一点关于过敏诊断的知识。研究中的医生使用两类检测来尝试判断一个人是否对某种特定的过敏原（如猫毛或花生）过敏。这两类检测是：

皮肤点刺试验，即把一滴过敏原溶液滴在患者的皮肤上（见下图），然后用针刺破皮肤。如果皮肤出现免疫反应，表现为一定大小的红色隆起，则该检测为阳性，否则为阴性。

题图来自 Microsoft Foundry 博客的 How to make AI responses faster on Microsoft Foundry: lessons from 2,040 measurements，作者是 Yassine El Ghali。

模型换得更快，应用不一定就更快。这篇文章的作者在 Microsoft Foundry 上把文本、图片、文件、工具和 MCP 几类工作负载都测了一遍，想知道哪些改动真能降低延迟，又不牺牲正确性。我读下来最大的感受是，延迟的来源比我平时想的杂得多：输出长度、重复的 prompt 内容、图片和文档处理、工具选择、连接建立、串行等待，还有多出来的模型请求，都会占时间。

题图来自 Microsoft Foundry 博客的 Evaluate More, Spend Less: Batching Microsoft Foundry Evaluators for Efficient Evaluation，作者是 Salma Elshafey、Ali Mahmoudzadeh、Kayla Ames、Ahmad Qardahji、Vivek Bhadauria、Morteza Ziyadi 和 April Kwong。

给 Agent 做评估时，同一段对话往往要分别发给好几个评估器。这篇文章讲的是微软 Foundry 团队的一项实验：用一次 Judge 调用同时跑五六个 Microsoft Foundry 评估器，总输入 token 少了 61.25% 到 71.07%，实测运行耗时少了 35.74% 到 46.10%，而且在几个价值较高的评估维度上，前沿 Judge 模型的质量没有明显波动。我把它读完后觉得，数字好看是一回事，更有用的是它顺带给出了哪些评估器适合合并、哪些得留着单独跑。