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

这种技术将使我们能够：

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

为了介绍这项新技术，我们暂时把哮喘项目放在一边，转而看一个双过程情形的简单例子（如果你更愿意继续聚焦于哮喘项目，可以直接跳到第 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 模型的质量没有明显波动。我把它读完后觉得，数字好看是一回事，更有用的是它顺带给出了哪些评估器适合合并、哪些得留着单独跑。

题图来自 GitHub Blog 的 Project HydraFusion。

9 月初 GitHub 放出了 HydraFusion，一个在 Copilot 模型选择器里排着的"模型"，但它其实不是模型。我把官方博客、Changelog、社区讨论帖、HyDRA 论文和 Rubber Duck 的两篇文章放在一起读了一遍，想弄清楚三件事：它到底在每一轮里做了什么，那组"成本降 67%、质量还更高"的数字能信到什么程度，以及现在值不值得切过去用。

在全球范围内，每年约有 450,000 人死于哮喘。如果我们能够更好地理解是什么导致人们患上哮喘，这将对哮喘的检测、诊断和治疗产生巨大的积极影响。基于模型的机器学习能否帮助我们获得这种更深入的理解呢？

哮喘是一种非常常见的疾病，在英国约有 5% 的人受其影响 [Anderson et al., 2007]，在美国这一比例约为 7% [Fanta, 2009]。对于患者而言，哮喘可能造成极其严重的后果。发展成哮喘的一个已知风险因子是这个人是否患有过敏，但过敏与哮喘之间的关系尚未被充分理解。若能加深对这一关系的理解，就有可能实现对那类可能导致住院乃至更糟后果的严重哮喘的早期检测。

曼彻斯特哮喘与过敏研究（Manchester Asthma and Allergy Study，MAAS）是一项旨在帮助理解儿童哮喘和过敏成因的研究 [Custovic et al., 2002]。具体而言，该研究的目标是理解为什么有些患有过敏的儿童会发展成哮喘，而另一些却不会。MAAS 是一项出生队列研究——换句话说，参与者是在出生时被招募进入研究的——共包含约 1,000 人。该研究始于 1995 年，并持续至今，不断收集有关研究参与者的最新数据，如今这些参与者已是青年人。可以想见，这些参与者及其家庭为此付出了巨大的奉献与投入——我们和研究团队都对他们心怀由衷的感激！