题图来自 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 年，并持续至今，不断收集有关研究参与者的最新数据，如今这些参与者已是青年人。可以想见，这些参与者及其家庭为此付出了巨大的奉献与投入——我们和研究团队都对他们心怀由衷的感激！

本文参考了 Microsoft Community Hub 上 Robin Lester 的文章 Using Jev with Agents in Microsoft Foundry for Model Evaluation，下面是我整理的理解和步骤。

Jev 是什么

Jev 是 TypeSafe AI 推出的新模型，2026 年 9 月 15 日开放了抢先体验。TypeSafe 把它称为自家第一个“System One”模型，它不写长篇文字，只负责又快又结构化地做判断。

用法很直接：把一段状态或上下文交给它，再说明你想让它做什么判断，它会返回一个带类型的概率化结果。结果有三种形式：

当我们绘制电影在特质空间中的位置时（之前的图 5.14），我们只展示了那些位置能被合理准确地知道的电影（也就是后验方差较低的那些）。由此可知，有许多电影的后验方差较大，甚至可能大得多。这意味着我们基本上不知道某些电影在特质空间中的位置。我们可能会预期这些是那些没有很多评分的电影。如果我们不知道某些电影在特质空间中的位置，那么我们可能会预期与这些电影相关的推荐准确性会很低。我们该如何诊断是否属于这种情况呢？

首先，了解每部电影通常有多少评分会很有用。图 5.25 展示了整个数据集中每部电影的评分数量，电影从左边评分最多到右边评分最少排序。

图 5.25：整个数据集中为每部电影给出的评分数量。电影从左边评分最多到右边评分最少排序。

我们的模型把完整的星级评分范围变成了简单的喜欢或不喜欢，这意味着它丢弃了大量有用的信息。给一部电影打 3 星和打 5 星之间有天壤之别，然而我们却把这两种情况同等对待。为了利用不同的星级评分，我们需要改变模型，使其能够处理完整的评分范围，而不是二值的喜欢/不喜欢。这不仅让我们能够在星级评分上训练，还让我们能够预测星级评分——一举两得！

我们可以在已经设计好的二值喜欢/不喜欢模型的基础上做出这一改变。在这个模型中，我们有一个 affinity（好感度）变量，它是一个连续的数字，表示一个人对一部电影的喜欢程度。目前我们在零处对这个好感度取阈值，说大于零的值意味着这个人喜欢这部电影，小于零的值意味着他们不喜欢这部电影。为了建模不同的星级评分，我们可以假设更高的好感度意味着一个人会给出更高的星级评分。更确切地说，我们现在不再只在零处取阈值，而是为每一个星级评分引入一个阈值。如果一个人对一部电影的好感度高于某个特定星数的阈值，那么我们就预期他们会给这部电影至少那么多星。

最近我在研究 Microsoft Foundry 的多智能体能力时，注意到一个变化：智能体之间的协作终于不用再靠一堆自定义 API 拼凑了。A2A 工具和新的入站 A2A 端点现在支持 A2A 协议 1.0 版本，这个版本已经正式发布（GA）。之前预览阶段用的 a2a_preview 工具类型和 0.3 版协议依然保留，给已有的集成留了一条兼容路径。托管智能体（Hosted Agents）也可以通过暴露在 MCP 上的 Foundry 工具箱来使用 A2A 工具。

有了我们训练好的两特质模型，我们现在准备好做一些推荐了！在训练期间，我们学到了每部电影和每个人在特质空间中（不确定的）位置。我们现在可以为验证集中每一条被留出的评分做预测。我们一次做一条评分——也就是说，一次针对一个人和一部电影。首先，我们把电影 trait 和人的 preference 的先验设为训练期间学到的后验。然后我们运行期望传播来推断 likesMovie 上的后验分布，以计算这个人会喜欢这部电影的概率。在验证集中所有评分上重复这一过程，就得到了每个人喜欢每部电影的概率，如图 5.15a 所示。图 5.15b 显示了对应的真实标签喜欢/不喜欢的值。

(a) 推断的喜欢概率

(b) 真实标签喜欢/不喜欢

图 5.15：我们推荐模型的初步结果。(a) 计算得到的每个人喜欢每部电影的概率。白色方块对应概率 1.0，黑色对应概率 0.0，灰色的深浅表示介于两者之间的概率值。(b) 真实标签——白色表示这个人喜欢这部电影，黑色表示他不喜欢。

从图 5.15b 中最先引人注意的一点是，人们大多喜欢电影，而不是不喜欢它们。因此从某种意义上说，我们给推荐系统设定的任务，是试图找出一个人不喜欢的少数几部电影。看图 5.15a 中预测的概率，我们可以在这个任务上看到一些成功——因为某些较暗的方块确实与真实标签中的黑色方块正确对齐了。此外，某些行总体上比平均更暗或更亮，表明我们能够学到每个人总体上有多可能喜欢或不喜欢电影。然而，这些预测并不完美——有许多不喜欢的电影被漏掉了，也有一些不喜欢的预测是错误的。但在我们对模型做任何改进之前，我们需要先决定用哪些评估指标来度量和追踪这些改进。

在能够训练我们的模型之前，我们需要一些数据来训练它。好消息是，有一些高质量的公开数据集可以用来训练推荐模型。我们将使用明尼苏达大学 GroupLens Research 提供的、极为出色的 MovieLens 数据集之一 [Harper and Konstan, 2015]。我们将使用一个已经免费提供、供教育和开发用途的数据集——谢谢你，MovieLens！你可以自己使用这个链接下载该数据集。

认识我们的数据

与任何新数据集一样，我们的首要任务是认识数据。首先，这里是数据集中 10 条评分的样本：

表 5.3：来自 MovieLens 数据集的评分样本。