53 篇博文 含有标签「evals」

我今年雇佣的三位最优秀的 AI 工程师，如果让他们互相面试，可能都会被刷掉。那个能写出在模型升级后依然稳健的提示词（prompt）的人，这辈子没写过一个有用的评估（eval）用例。那个能设计出捕捉到关键故障的评估集的人，写的提示词其他工程师根本不想去维护或扩展。那个能设计出既能“故障闭合”（fail closed）又不阻塞正常路径的护栏（guardrail）的人，对另外两个人的看法我在这里不便多说。

职级体系将他们三人都称为“AI 工程师”。定级委员会在对比他们的晋升材料时，仿佛他们做的是同样的工作。其实不然。

调取任何生产环境智能体（agent）的一周工具调用追踪（tool-call traces），你会发现其规律如出一辙：三四个工具处理了 90% 的调用，其余数十个工具则瓜分了剩下的 10%。工具目录呈现幂律分布（power law），但框架却将其视为均匀列表。每个工具描述都会出现在每个系统提示词（system prompt）中，每个选择准则都对工具一视同仁，每个评估（eval）在对目录进行采样时，都仿佛 search-files 调用和 refund-issue 调用来自同一分布。事实并非如此。

这种“扁平化”处理的代价在爆发前往往是隐形的。团队增加第 18 个工具，规划器（planner）对最初三个工具的准确率下降了两个百分点，却没人能将这种退化归因于特定变更，因为所有指标都同时发生了偏移。而评估套件本身在目录中也是均匀分布的，它将这些下滑平均成一个看起来依然正常的数字。与此同时，本轮对话中模型不会调用的工具描述所消耗的 token，已经超过了用户实际提示词的 token。

大多数生产环境中的 AI 功能在发布时只带有一个置信度阈值。在阈值之上，模型给出回答；在阈值之下，用户会得到一句生硬的“我不确定”。这个单一的数值同时承担着两个完全不同的任务，这就是为什么即便你对已回答查询的准确率看起来不错，但信任度指标却已经连续两个季度下滑的原因。

正确的设计至少应该有两个切分点。一个“弃权”（abstain）阈值设在低位：低于该值时，模型拒绝回答，因为此时保持沉默比给出任何答案都更有价值。一个“升级”（escalate）阈值设在中间：在两个切分点之间，系统将案例交给人工审核员，而不是直接将其丢弃。将它们合并成一个刻度盘，你发布的产品在出错时和不确定时会让人感到同样无用——在用户只需打开另一个标签页就能找到免费替代品的市场中，这是最糟糕的处境。

这并不是什么新鲜想法。拒绝选项分类器（reject-option classifier）的文献自 20 世纪 70 年代以来就一直在主张拆分阈值，将“歧义”拒绝（输入介于已知类别之间）与“距离”拒绝（输入远离任何训练数据）区分开来。生产环境中的 AI 团队总是在以惨痛的方式重新学习这一教训，通常是在首次发布大约六个月后，当支持队列中挤满了询问“这玩意儿是坏了还是怎么了”的人时。

在一个严肃的 LLM 项目进行到第六周时，总会有那么一个时刻，Prompt 迭代日志开始变得像一本心理治疗日志。每一次微调都是在用一种失败模式交换另一种。增加一个更严格的 “do not”（不要）条款，模型在以前能处理的情况下就开始回避。放软语气，另一类幻觉又回来了。评测得分板在三四个点的范围内徘徊，拒绝突破。有人说，“让我再试一次重新排序，”于是又是半天时间烟消云散。

这就是局部最优陷阱（local-maximum trap）。团队正在爬山，但这山头已经到顶了。残忍的是，这座山是真的——每一次 Prompt 的改动确实会在某些案例子集上产生可衡量的变化，而这正是让每个人持续微调的信号。被忽略的是：上方的天花板根本不是 Prompt 的天花板。

系统提示词写着：“你是一名金融分析师——保持保守，永远不要给出具体的买入/卖出建议，始终披露不确定性。”在最初的二十轮对话中，智能体的表现确实像一名金融分析师。到了第五十轮，它开始推荐具体的股票，模仿用户随意的语气，且比起第三轮时更少做风险对冲。没有人修改过系统提示词。没有人注入任何恶意指令。角色只是在对话的重压下被侵蚀了，就像河岸在没有任何东西越过“攻击”阈值、但流水从未停止移动时所发生的那样。

这就是人格漂移（Persona Drift），也是你的评估套件未能捕获的退化。能力评估衡量模型是否能完成任务。而身份评估——即模型是否仍在按照系统提示词要求的方式执行任务——在研究论文之外几乎不存在。其结果是产生了一类生产环境下的失败：它们在逐轮查看时显得正确，只有当你从头到尾阅读完整记录时才会发现问题。

一个团队发布了一次提示词重构（prompt refactor）。离线评估显示准确率提高了三个百分点。产品经理（PM）在 Slack 上发布了图表。两周后，支持工单激增，出现了一个没有任何仪表盘记录的模式：用户信任了他们不该信任的答案，并据此采取了行动，结果蒙受了损失。模型比以前更准确了，但对模型的信任却变差了。

这就是“校准崩溃”（calibration collapse）。模型的置信度不再与其错误率相匹配，但由于准确率数字上升了，团队认为他们发布了一个成功的更新。其实不然。他们发布的是一个更加“自信地犯错”的系统，而用户——他们是根据模型的语气（含糊表达、确定性、拒绝回答）而不是他们从未见过的准确率数字来校准信任的——现在在那些被误导后果最严重的查询中被误导了。

准确率（Accuracy）和校准（Calibration）是独立的维度。你可以改变其中一个而不影响另一个。你可以在提高一个的同时摧毁另一个。大多数团队只测量第一个维度并以此为基准发布产品，而大语言模型（LLM）系统中的大多数生产事故都发生在第二个维度上。

你上线了新模型。综合评估通过率从 91% 提升到了 96%。产品团队在全体员工大会上宣布这是一次重大胜利。六周后，可靠性团队却迎来了有史以来最糟糕的一个季度——并不是因为故障变多了，而是因为现在每一个故障都需要三名工程师花上两天时间才能解决。

这就是智能体能力悬崖 (agent capability cliff)，它是生产环境 AI 中最反直觉的失败模式之一。模型升级并不会均匀地提升所有任务的表现。它们将增益集中在大部分流量上——即那些旧模型原本就能在大部分时间内处理正确的简单和中等案例——而长尾中真正困难的输入却只看到了微乎其微的改进。你的失败面缩小了，但剩下的每一次失败都是能力边界案例，这些案例旧模型也处理不了，而且简单的提示词工程 (prompt engineering) 也无法修复。

这个“悬崖”并不是新模型的缺陷。它是我们衡量模型改进的方式（混合难度评估集的平均通过率）与值班排班中实际遇到的问题（最难流量的残差集，现在已经没有了以前占据主导地位的简单故障的缓冲）之间的不匹配。

你的评估套件通过了。质量仪表板显示为绿色。一周后，用户正在悄悄流失，没人能解释原因。评估集并没有通过犯错来撒谎——它的谎言在于它是一面镜子。你用来评分的标签，可以追溯到正是由你试图评估的那个模型家族生成或过滤的。通过这项评估并不是质量的证明。它证明了你的模型与其过去的输出是一致的。

这是成熟 LLM 流水线中一种隐蔽的失败模式：通过生产泄漏导致的评估集污染。这不同于著名的基准测试污染（即在 GSM8K 上训练的模型又在 GSM8K 上进行评分）——那个故事已经被讲烂了。更微妙的一种发生在下游。你的黄金标签来自用户反馈、来自先看到模型草稿的人类标注员、来自 RLHF 奖励追踪、来自 LLM-as-judge（模型即评委）的偏好数据。这些流水线中的每一个都将当前模型习语的指纹带回到了你的“基准真值”中。几个季度下来，测试集悄悄地记住了你模型的偏好，评估变成了一个自我表扬的循环。

每个在没有评估（evals）的情况下发布 AI 功能的团队都会对自己讲同样的故事：我们会以后再添加衡量标准，等到找到产品与市场契合点（PMF）之后，等到提示词（prompt）稳定之后，等到下一次发布之后。六个月后，提示词已经被四位工程师和两名产品经理修改过，其行为支撑着三个客户集成，团队发现“以后添加评估”意味着要从从未为此目的结构化过的生产日志中重建意图。本应开发新功能的季度变成了考古季度。

这不是规划错误。而是一个复利错误。为了更快发布而跳过评估的团队，正是那个将花费十二周时间从不完整的追踪（traces）中重建评估基础设施、为二月份所谓的“正确”含义争论不休、并悄悄移除没人能证明依然有效的功能的团队。追赶的成本超过了内置的成本——不是一点点，而是随着每一次未经回归检查就发布的提示词修改而倍增。

一个在提示词未发生任何更改的情况下，测试结果由绿转红的回归测试套件，通常源于以下三种情况之一：测试框架损坏、检索库不稳定，或者评估模型（Judge）在周末学习了“新口味”。第三种情况最常见，也最难调试，因为你的代码仓库里没有任何提交记录与之相关。评分模型在静默状态下完成了质量更新，你与上个月仪表盘对比的所有分数，现在都已经是在用另一种“货币”计价了。

这是 LLM-as-judge 令人不安的地方：你有两个处于变动中的模型，而不仅仅是一个。待测模型（Candidate Model）是你发布的产物；评估模型（Judge Model）则是告诉你待测模型表现如何的工具。当两者独立演进时，分数的变化量（Score Deltas）不再具有以往的含义，你家产品经理每天早上刷新的仪表盘正在悄悄地撒谎。

每个复杂的 AI 产品最终都会产生一个谁也不敢碰的 prompt。它包含三个条件分支，两个在处理客户报告的事故时临时粘贴进去的内联示例，以及一个以 “IMPORTANT:” 开头的句子，后面跟着一段没人记得是谁写的语气指令。这个 prompt 长达 1,400 个 token。最后一次修改它的 PR 是由一名早已转岗的工程师审核的。当新模型发布时，没人敢保证这个 prompt 依然有效。当评估（evals）结果下降时，没人确定是 prompt、模型、检索流水线还是下游工具导致的。这个字符串被四个服务共享。每个团队都有自己的本地覆盖（override），而且这些覆盖都没有文档记录。

这就是 Prompt 所有权问题，它是多团队 AI 工程中讨论最少却最普遍的失效模式。这不只是一个技术问题，而是康威定律（Conway's Law）在 token 层面的体现。一个组织的 prompt 最终会反映出它的组织架构、RACI 缺口和协作成本——而模型并不关心你的 Jira 层级，它只会为同样不在乎这些的终端用户产生不连贯的行为。

你刚接入的前沿模型对你的竞争对手早有定见。对于你产品旨在反驳的那些难题，它有一套默认答案。它对你所在的领域有一套“最佳实践”，而这些实践往往源于训练语料库中占据主导地位的内容；对于你在设计文档中反复纠结的每一个争议性决策，它都暗自偏向于传统做法。这些都不会出现在你的系统提示词（system prompt）中，也不是你写的。在涉及到你产品核心差异化的查询上，模型会先倾向于那些默认设定，而不是你告诉它的内容。

大多数团队在发布产品时，都把模型当成了一张可以任意配置的白纸。写好角色设定（persona），列出规则，粘贴品牌语气指南，运行几个能产生正确回答形式的 QA 提示词，然后就大功告成了。通过审核的提示词往往是处理简单查询的——在这些查询中，模型的先验认知（prior）恰好与你的预期相符。而那些真正有趣的查询，即如果产生通用回答就会让你的产品惨败的查询，几乎从未进入提示词迭代循环。在这些查询中，先验认知正在悄无声息地取胜。