160 篇博文 含有标签「evaluation」

一次隐私评审批准了你的脱敏层。姓名、邮箱、账号、电话——所有这些都在提示词送达模型之前被清理掉了。你的单轮分类器仍然能跑到 94% 的准确率。六周后，你的多步骤智能体开始对类似"Sarah 用于登录的邮箱和她账单记录里的邮箱是同一个吗？"这样的问题给出自信但错误的答案，而且没人能在开发环境里复现。

脱敏层做到了 infosec 团队要求它做到的一切。它同时也悄悄地摧毁了你的智能体推理所依赖的性质：在不同轮次中出现的两个实体指代是同一回事。这个智能体并没有产生幻觉，它读到的是一份转录文本，其中 Sarah 变成了三个不同的人，"同一个"邮箱地址变成了两个互不相同的占位符。

你对两个 prompt 变体跑了一次 A/B 实验。你的 LLM 评审——因为图省事,默认就用了和候选模型同一家厂商的模型——一致地偏好变体 A,差距大到足以被称为统计显著。你上线了 A。一周后,满意度指标下降了,退款队列上升了,没人能解释原因。终于有人用另一个模型家族的评审重新跑了一遍评测,偏好翻转了。

评审根本不是在衡量质量,评审只是在衡量候选模型听起来有多像评审自己。

你在实验中上线了一个模型替换。两周过去了，控制面板只变动了 0.1%，读数显示“无显著差异”。你得出结论，新模型与旧模型基本相同，然后继续进行其他工作。

它们并不相同。你的指标从未敏感到足以区分它们。

在过去一个季度，你的评估分数从 0.81 上升到了 0.87。团队上线了一个路由器 (router)，在困难意图上更换了更强大的模型，微调了系统提示词 (system prompt)，并从“处理时间超过一天的工单”中提取并添加了 40 个新的测试用例。仪表盘显示系统变得更好了。NPS 持平。活跃用户数下降了 2%。

有一个简洁的故事可以解释这两个数字，但你可能并不想听：你的评估集只包含你已经解决的问题。那些失败得如此彻底，以至于用户从未提交工单、从未回来、甚至从未出现在你 grep 的任何日志中的查询 —— 它们不在你的测试套件中。它们不在任何人的套件中。评估分数的上升不仅与你在可见的事物上做得更好相一致，也与你在可见的事物上做得更好、但在不可见的事物上依然糟糕透顶相一致。

部署在 Web 集群前的负载均衡器之所以有效，是因为每台机器都会上报信息：CPU、队列深度、错误率、延迟。均衡器根据这些负载信息进行路由。模型路由器（Model Router）则拿不到这些遥测数据。它在模型执行任何操作之前，仅凭查询内容就决定由哪个模型来处理。路由器根据提示词（Prompt）预测难度。但真正的难度只有在生成答案时才会显现。当信号产生时，路由决策已经过去三秒钟了，而廉价模型可能已经向你的用户发送了一个自信但错误的回复。

这是模型路由核心的结构性缺陷，但大多数团队在发布路由器时从未这样审视过它。他们将其视为一个分类器——训练一个模型将查询标记为“简单”或“困难”，在预留集上进行验证，当准确率超过 90% 时就发布。分类器的隐喻在关键之处是错误的。分类器预测的是一个已经存在的标签。而路由器预测的是一个尚不存在、直到被路由的模型给出答案后才会存在、且可能永远不会以足够干净的形式存在以便学习的标签。

一个 PR（合并请求）进入了你的评审队列。Diff 显示系统提示词（system prompt）中修改了三个词：Output strictly valid JSON 变成了 Always respond using clean, parseable JSON。这看起来就像是一次文案润色。你快速浏览了一下，CI 检查勾标是绿色的，于是你点击了批准。总耗时：90 秒。

六个小时后，下游解析器开始拒绝带有尾随逗号和缺失字段的响应。结构化输出的错误率从接近零飙升至两位数，一个创收工作流陷入停滞。Diff 中没有任何迹象预示到这一点。Diff 中也不 可能 预示到这一点，因为 Diff 衡量的是错误的东西。

这就是评审提示词变更的核心问题：提示词 Diff 的大小完全无法说明其影响范围的大小。三五个词的修改与三段话的重写都只是文本，而文本 Diff 以相同的视觉权重呈现它们，就像对待任何其他编辑一样。但提示词并不是 描述 行为的文本 —— 它是 导致 行为的文本，而一次编辑所产生的因果爆炸半径在你评审的产物中是不可见的。

你开启了一个“评测工程师 (eval engineer)”的招聘需求。一周后，你的招聘人员问了一个显而易见的问题：这个岗位的职级是什么，一份优秀的简历长什么样？你给不出答案。两年前，这个头衔还不存在。没有职级评定标准，没有标准的面试流程，LinkedIn 上也没有现成的“评测工程师”人才库。你在为一个行业尚未达成共识是否存在的职位进行招聘。

这是交付 AI 系统过程中一个隐形的瓶颈。模型是现成的，基础设施是可租用的。你无法从市面上直接买到的是这样一种人：他们的实际工作是确保基于 Prompt 的系统保持“诚实”——而你那套为拥有数十年先例的岗位而构建的招聘机制，并没有给他们留位置。

直觉是等待。等待头衔标准化，等待培训班批量产出候选人，等待别人写出你可以照搬的职级指南。这种直觉是错误的。无论头衔是否存在，工作就摆在那里，而现在就开始组建团队的人，会在竞争对手还没开启招聘需求之前，就摸索出什么是真正的“优秀”。

你在 18 个月前编写了这套评估集（eval set）。那时它是一个非常有用的工具：低价模型的得分是 71%，更好的模型得分是 84%，而当出现回归（regression）时，分数会下降并被察觉。这套测试套件在 CI 中赢得了一席之地。于是你不再关注它了。

今天再运行它，每个候选模型的得分都是 96、97、98。新版本的得分与旧版本相同。你怀疑表现较差的模型与你认为更好的模型得分也一样。仪表盘上的数字依然显示为绿色，检查依然通过，但它实际上什么也没告诉你。你的评估集并没有坏。它只是变简单了——因为底层的模型变强了——而没人在意它失去区分度的那个瞬间。

这就是评估饱和（eval saturation），这不仅是你可能遇到的失效模式，更是任何静态测试套件在足够长的时间跨度下必然走向的终局。一个所有模型都能通过的测试，已经不再是测试了。

每一个成熟的 AI 团队构建其评估套件的方式都如出一辙，而且几乎没有人会公开说出那个潜台词。生产环境中出现了一个故障。有人写了一份复盘报告。一名工程师将该事故提炼为一个测试用例，将其添加到评估套件中，于是仪表盘再次变绿。重复这个循环一年，你就会拥有几百个案例、一个令人满意的通过率，以及一个足以让你在演示幻灯片上感到无比安心的数字。

潜台词是：那个评估套件其实是一个博物馆。每一件展品都是团队已经挺过来的故障类别。98% 的通过率证明了你的系统可以抵御过去 —— 抵御那些已经发生过的特定破坏方式 —— 而对于模型迁移、提示词编辑或用户行为转变即将引入的新型故障模式，它几乎给不出任何参考。评估集是一个披着先行指标外衣的滞后指标。

打开任何成熟的智能体（agent）代码库，问一个简单的问题：需求文档在哪里？不是融资演示文稿，不是发布文档，也不是那个上次更新还在第三季度的 Notion 页面。那份具体且明确地规定了这个智能体应该做什么的产出物在哪里？

对于大多数团队来说，诚实的回答是：评测套件（eval suite）。那里有一个测试用例文件夹——输入与预期输出成对出现，还有评分标准、评判提示词——以及一个显示通过或失败的 CI 门禁。那个文件夹是唯一一个将“正确”定义得足够精确以供执行的地方。其他一切都是散文，而散文会随时间发生偏移。

这本身并不坏。一个可执行的规范比没人读的 PRD 更诚实。问题在于，几乎没有人将评测套件视为规范。它是由一名工程师在截止日期前拼凑出来的，只是为了让发布门禁显示为绿色。它编码了一百个从未被记录、从未被审查、也从未被达成共识的判断。而模型现在正针对它进行精确优化。

看看大多数智能体（Agent）评测集是从哪里来的。有人构建了智能体，向团队演示，演示成功了，于是演示脚本就变成了评测套件。那些通过评审的案例，正是有人已经亲眼看到它们运行成功的案例。评测集在构建之初，几乎就是“快乐路径”（Happy path）的录音——即在截屏当天成功运行的那一段工具调用序列。

所以，当仪表盘显示智能体得分为 94% 时，它实际上是在说：它通过了我们能想象到的案例。它完全没有提及搜索 API 在多步计划中途返回 429 错误的情况，或者用户推翻了两轮前设定的约束的情况，亦或是检索结果为空，智能体必须在胡乱猜测和承认不知道之间做出选择的情况。这些情况并非没有通过你的评测。它们压根就没在评测里。

这就是黄金路径偏见（Golden-path bias），除非你刻意对抗，否则它就是智能体评测套件的默认形态。解决方法不是增加案例数量，而是增加不同种类的案例——这些案例应根据失败模式（Failure mode）来选择，从生产环境中收集，并针对刻意引入的故障进行压力测试。

弃用通知看起来人畜无害。它以更新日志或邮件中一段平静的文字形式出现：该模型快照将在几个月后的某个日期从 API 中移除，这里是推荐的替代方案，感谢你与我们一起构建。其中暗含的工作量似乎只是一行代码的改动 —— 换掉模型字符串，重新部署，搞定。

这种设想是错误的，而且错得很昂贵。模型字符串是你损失的最小的东西。真正随着旧模型一起消失的，是你花了六个月调优的提示词（prompt） —— 每一个针对边缘案例的补丁、每一个重新排序的指令、每一个你因为那个特定模型会有特定烦人行为而添加的“仅以有效的 JSON 响应，不要用 Markdown 包装”。这些都不是可移植的。从统计学意义上讲，它是针对一个模型的行为进行拟合的。替代模型并不是“缺陷对缺陷”兼容的，因此这种拟合不再成立。

模型生命周期的结束是一个迁移项目。如果把它仅仅视为一次配置更改，你就会在生产环境中、在新模型上通过真实流量发现其中的差异。