Evaluations | The .NET Blog

Model router 的 eval 是太多团队跳过的一步

Emiliano Montesdeoca — Fri, 29 May 2026 00:00:00 +0000

本文已自动翻译。原文请点击这里。

自动模型路由听起来很棒，直到你意识到，你仍然需要证明它对你的 workload 来说确实是正确选择。

这就是新的 model router evaluation repo 有用的原因。

它为团队提供了更具体的方式来回答那些真正重要的问题：

路由是否保留了质量？
它是否改善了成本？
它对延迟有什么影响？
如果我限制 model subset，会发生什么变化？

原文提出了正确的问题

我特别喜欢原文的一点是，它没有把 model router 当成理所当然的好东西。

相反，它提出了那些让人不舒服但正确的问题：

“在我的 prompts 上，model router 自动选择的 model 是否能与我原本会选择的 single model 持平甚至更好？”
“我到底是真的在端到端节省钱，还是只是把支出从一个地方转移到另一个地方？”

这才是正确的态度。

因为自动路由虽然很有吸引力，但它仍然是一个 system decision。而 system decision 应该被衡量，而不是被欣赏。

为什么这个 repo 比第一眼看到的更重要

在一个层面上，这只是一个 evaluation repo。

在另一个层面上，它是成熟度的信号。

它在说：如果你想采用自动路由，这里有一种更有纪律的测试方式：

质量
成本
延迟
subset trade-off
model distribution 行为

这比把 routing 当成一个有好品牌的黑盒要好得多。

我的看法

这是 AI platform 更需要的那类 tooling 的一个好例子：不是更多魔法，而是在信任魔法之前，提供更多验证它的方法。

这就是团队避免在未经测试的假设上建立昂贵信心的方式。

原文： How to run evals for the model router

AI 开发最难的部分已经不再是访问，而是把正确的模型运营好

Emiliano Montesdeoca — Tue, 26 May 2026 00:00:00 +0000

本文已自动翻译。查看原文，请点击这里。

我们早就过了“只要能访问一个强大的模型就足够”的阶段。

这正是这份新的 Foundry 模型、成本与质量管理指南 抓住的重点。

真正的挑战现在是运营层面的：

为每个 workload 选择正确的模型
用自己的数据对它进行验证
管理延迟和支出
管理升级和回归风险

这正是严肃团队必须擅长的事情。

原文把问题定义得很准确

原文中的一句话非常好地概括了这种变化：

“如今构建 AI 系统最难的部分已经不再是获得一个有能力的模型。而是知道如何在真实应用的整个生命周期中选择、验证、优化并运营正确的模型。”

这就是完全正确的诊断。

太多团队仍然认为模型选择才是最主要的决定。

并不是。

模型运营才是更大的问题：

哪个 workload 用哪个模型？
质量如何验证？
什么样的成本结构是可接受的？
当新模型出现，或者旧模型开始漂移时，会发生什么？
如何在不破坏真实工作流的情况下测试变更？

这才是现在真正的工程工作。

为什么这篇 Foundry 内容有用

我喜欢这篇文章，因为它谈论 AI 系统的方式，正是有经验的平台工程师真正需要思考的方式。

不是“挑最聪明的模型然后继续”。

而是作为生活在各种权衡下的系统：

能力
延迟
成本
安全
治理
升级压力

这比只看 benchmark 的乐观主义有用得多。

最重要的转变是先看标准

原文建议在打开模型目录之前先定义成功标准。

我认为这是团队最应该养成的习惯之一。

如果先打开目录，你会锚定在声誉上。

如果先定义标准，你会锚定在 workload 的现实上。

这是一种更健康的流程。

因为在 benchmark 中获胜的模型，不一定就是在以下方面获胜的模型：

你的 prompts
你的延迟预算
你的成本 guardrails
你的治理要求

这种区别，正是成熟 AI engineering 的起点。

多模型故事正在变成真正的优势

另一个我喜欢的点，是它明确采用了 model-agnostic 的 framing。

文章把 Foundry રજૂ出来，不是作为单一模型的终点，而是作为一个跨越以下内容的 operational surface：

Microsoft 模型
合作伙伴模型
开源模型
后训练变体
routing 和 optimization 策略

这很重要，因为模型灵活性已经不再是奢侈品。它是风险管理的一部分。

如果质量变化、价格波动，或者 quota 紧张，团队就需要可选方案。

成本控制不是次要问题

文章把成本看作架构问题，这一点也很对。

这不是“以后再优化”的问题。

如果默认把每个任务都发给最重的模型，它在 demo 里可能表现很好，但在生产经济性面前会崩掉。

所以我认为关于以下内容的部分，比很多人想象的更重要：

routing
batching
caching
provisioned throughput
quota 管理

把成本纪律当作系统设计的一部分的团队，会比把它当作事后清理工作的团队更能长期发展。

我的看法

这篇 Foundry 内容有用，因为它谈论 AI 系统的方式，正是有经验的工程师真正需要去运营的方式。

不是 demo。不是一次性原型。也不是排行榜旅游。

而是面向 workloads、限制、权衡和持续变化的 operating systems。

我们需要继续把讨论提升到这个层次。

如果你正在构建生产级 AI 系统，这正是我希望团队尽早内化的 mindset。

原文链接： A Developer’s Guide to Managing Models, Cost and Quality in Microsoft Foundry

Foundry 从可观测性到 ROI 的故事，正是严肃代理平台所需要的

Emiliano Montesdeoca — Mon, 25 May 2026 00:00:00 +0000

本文已自动翻译。查看原文，请点击这里。

如果 AI agents 要在生产中长期运行，可观测性就不能停留在日志和追踪上。

这正是 Foundry 新的从可观测性到 ROI 的故事显得重要的原因。

真正的信息不是“我们加了更多仪表板”。

真正的信息是，严肃的代理平台需要一个持续的运行循环：

追踪发生了什么
评估结果是否良好
优化需要改进的部分
把结果和业务价值连接起来

这比常见的平台式空话要强得多。

原文中的关键句已经说明了一切

原文开头有一句话，我认为每个构建代理的团队都应该注意：

“发布一个 AI agent 是简单的部分。让它在 production 中保持准确、安全并且可问责，才是团队卡住的地方。”

这完全正确。

我们已经过了“我能不能让代理做点酷的事情？”才是主要问题的阶段。

更难、也更有价值的问题是：

当它开始与真实用户、真实工具和真实成本交互时，我还能不能运营它？

Foundry 正在试图把讨论推进到这个方向。

为什么这比另一个 agent demo 更重要

很多 AI agent 公告仍然聚焦于创建：构建代理、连接工具、路由任务、发布界面。

这些都没问题。

但正是运营问题决定了大多数严肃系统是变得可持续，还是变成昂贵的实验：

代理在生产中到底在做什么？
它做对了吗？
它会不会随着时间变差？
它的成本是否高于创造的价值？
哪些配置变更真正提升了质量？

所以我认为 Foundry 的公告比典型的功能汇总更重要。它试图定义的是一个 Agent DevOps 循环，而不只是一个代理创建故事。

四部分循环才是这里真正的产品

这篇文章基本上把平台组织成四种能力：

Trace
Evaluate
Monitor
Optimize

这才是正确的形态。

我甚至认为，任何想认真对待生产级代理工作负载的平台，最终都需要这四项全部具备。

只有 tracing 不够。

只有 evaluation 也不够。

没有证据的 optimization 只是猜测。

而没有 telemetry 的 ROI 讨论，通常都只是表演。

互操作性这个角度尤其聪明

这次公告最强的决策之一，是 Foundry 并没有假装所有代理都会在同一个 framework 里构建。

原文明确提到 tracing 和 evals 会扩展到：

LangChain
LangGraph
OpenAI SDK
Microsoft Agent Framework
通过 OpenTelemetry 的 custom frameworks

这一点很重要。

因为平台锁定是让原本有用的运维故事变得不那么吸引人的最快方式之一。

如果团队能保留自己的 framework 选择，同时仍然获得 production-grade 的 telemetry 和 evaluation surface，摩擦就会大幅降低。

评分式评估可能比很多人预期的更重要

评分式评估那部分也值得强调。

我认为这是整篇文章里最实用的新增内容之一。

为什么？因为“好”是有上下文的。

文章说，评分式评估会根据代理的预期行为生成“具备上下文感知的评估标准”。这正是这些系统需要的方向。

通用质量评分当然有用。

但最终团队需要按照自己的标准来评估代理：

语气
任务完成度
策略遵从性
延迟预期
成本边界
领域专属业务规则

评估真正开始变得具有运营意义，而不只是学术上有趣，就是在这里。

ROI 是最让人不舒服的部分，所以它才重要

我也认为公告里的 ROI 部分之所以重要，正是因为它让人不舒服。

原文直接提出了这个问题：

“这个 agent 值它的成本吗？”

在 AI 讨论里，这个问题经常被回避。

但这才是正确的问题。

如果平台真的能把成本、任务完成度、节省的时间和生产 traces 放在一个地方连接起来，那它就能给工程和领导层提供更好的共同语言。

老实说，这种共同语言非常需要。

我的看法

这是这一批里较好的平台级公告之一，因为它关注的是代理的运营，而不只是构建。

而真正困难的工作，正是从这里开始。

未来两年最强的 AI 平台，不会只是拥有更多模型或更多 demo 的那些。它们会是那些帮助团队追踪行为、评估结果、安全优化，并用证据来证明成本合理的平台。

Foundry 的这个故事正试图朝那个方向前进。

所以它值得认真对待。

原文链接： Build 2026: From observability to ROI for AI agents on any framework