113 篇博文 含有标签「evals」

绿色 CI 并不意味着“这个提示词有效”。绿色 CI 的本质是“编写评测的工程师想不出这个提示词会如何出错”。这是两个截然不同的断言，而它们之间的差距正是生产事故的温床。一个评测套件并不是对模型的测量——它是对编写者的冰冷写照。他们的方言、领域知识、资历、偏好的失败模式，以及他们在编写测试用例时恰好使用的模型。根据构造，工程师没想到的测试内容统统未经测试。更糟糕的是：他们会从同一个视角不断扩展套件，因此随着套件的增长，盲点并不会缩小，反而会变得根深蒂固。

这就是评测作者单一化（eval-author monoculture）问题，也是当今 AI 工程中讨论最少、风险最高的可靠性问题。团队痴迷于裁判偏差、位置偏差、冗长偏差、泄漏和污染——但上游偏差其实是最初决定测试用例的人的偏见。其他任何评测误差来源都会被它放大。如果你的套件是由一个人编写的，那么你就拥有了一个带有性格的基准测试，而这种性格正是你的 CI 能够捕获风险的无形天花板。

商业计划书中每一个“如果需要，我们会直接更换供应商”的计划，其预算表中都有提示词改写的支出。但没有一个计划包含评估套件的预算。这就是问题所在。提示词是显性耦合——那是你编写的部分，你可以通过 grep 搜索到的部分，也是一个初级工程师在一个下午就能改写的部分。而评估框架（eval harness）则是隐性耦合，当你真正尝试迁移时，它会吞掉你四分之一的路线图进度。

这种模式在议价能力变得至关重要时就会显现。你的合同到期了。竞争对手发布了一个在你的领域基准测试表现更好的模型。输出 token 的定价发生了变化。你准备让候选模型跑一遍评估套件来做决定，结果不到一天你就发现，你无法信任该框架产生的任何评分，因为框架本身是针对现有供应商编写的。你不是在比较模型，而是在拿一个模型与一个针对另一个模型校准过的测量工具进行比较。

LLM 产品中最昂贵的失败模式并不是一次糟糕的发布。而是连续六次好的发布——从内部所有计分板来看都是如此——而与此同时，用户的信任却在悄悄流失。离线评估分数在每个周五的演示中稳步上升。每周业务回顾中的 CSAT 曲线先是持平，然后下降，接着没人知道它是什么时候开始下降的，因为没人在交叉分析这两张图表。等到复盘总结（postmortem）点出问题时，团队已经花了两个季度的时间，针对一个在第三个月左右就不再符合现实的数据集来调优提示词（prompt）。

这就是“评估集即模拟器漂移”（eval-set-as-simulator drift），也是我所知道的一个最典型的例子：一群跳过了必读清单的 LLM 团队，正以极其惨痛的代价重新发现一个古老的机器学习教训。评估套件（eval suite）并不是一个固定的基准。它是一个模拟器，而一个从未根据它声称要预测的系统进行重新校准的模拟器，最终预测的将是另一个不同的系统。

这是周二的早晨，也就是 Prompt 更改上线到一半流量后的那一周。你打开四个仪表板。LLM 评审员（LLM judge）评分的留存黄金集显示 +8%。每周对生产流量进行抽样的真人评估小组显示无变化。下游转化率的 A/B 测试显示 -2%。点赞率（thumbs-up rate）持平。四个信号，四个结论，而十五分钟后就有一个站会，会上有人会问你到底是发布这个 Prompt 还是回滚。

你很容易倾向于选择那个能证实你原本意图的数字——团队也会这样做，因为会议上没有人拥有一套关于哪个信号获胜的书面规则。这种不一致并非测量错误。这是一个在没有层级体系的情况下强行把四个评估器凑在一起的系统的必然产物。缺乏这种体系的代价是，每个发布周都会变成一场关于该信任谁的数据的辩论。

当今大多数智能体 (agent) 产品都达成了一个简单的契约：模型决定做什么，用户点击“批准”。对于低风险的消费者聊天场景 —— 预订餐厅、摘要收件箱、起草非正式回复 —— 这确实是正确的形式。但对于法律起草、财务咨询、医疗分诊和事件响应来说，这却是灾难性的错误。在这些场景中，用户承担着模型永远无法承担的问责，而且错误 计划 的成本远高于任何单个 步骤 的成本。

反向智能体翻转了这种极性。用户将计划构思为一系列命名的、可重新排序的步骤。模型按需执行每个步骤 —— 拥有完整的上下文、工具访问权限和推理能力 —— 但绝不决定下一步该做什么。模型可以提供建议，但建议仅供参考，不具有自主性。这并不是一个更糟糕的自主智能体；它是一个完全不同的产品，虽然其成本和延迟表现绝对更差，但信任度绝对更高，专门针对那些否则会完全拒绝采用自主版本的用户。

团队一直在犯的错误是将“自主性”视为默认的努力方向。它其实是一个你在每个界面上选择的 UX 维度。如果搞错了极性，你交付的功能就会被那些承担最高风险的用户悄悄拒绝使用。

一个回归告警在周一早晨响了。你的留出评估集的忠实度（Faithfulness）在周末从 0.86 掉到了 0.78。没人发布新模型，没人动过提示词，也没人改过检索索引。值班工程师花了三个小时排查才发现，唯一改变的是裁判模型——自动评估器静默滚动到了一个更新的快照，它捕捉到了旧版本放过的细微委婉语。同样的答案，同样的模型，更低的分数。真实的数字，虚假的回归。

这就是评估困境：随着你的 LLM-as-judge（以 LLM 作为裁判）变得更敏锐，你在固定系统上的得分会下滑，而那个本应检测回归的仪表盘开始制造回归。没注意到这一点的团队会花上几个季度去追逐完全存在于“尺子”里的“质量偏移”。

一位资深工程师在周一加入你的团队。到了周五，他们已经交付了一个涉及 11 个文件的 TypeScript 重构，并在通过评审时仅有两个小细节（nits）需要修改。两周后，这位工程师打开了路由智能体（routing agent）的系统提示词——240 行指令、三个编号的示例块、四个“绝不允许”子句，以及底部一段读起来像道歉的段落——然后盯着它看了一个小时。他们无法告诉你如果删除第 87–94 行会发生什么。六个月前写下这些内容的工程师也无法告诉你。

这是没人会写在入职文档里的鸿沟。一个重度依赖提示词的代码库看起来像是个代码库：它存在于同一个仓库中，运行相同的 CI，并在相同的 PR 中接受评审。但它的语义却存在于别处：存在于一个团队中没人构建的模型观察到的行为中，针对的是一个没人能完全枚举的输入分布，其失败模式表现为添加一句话的 PR，而不是错误报告。传统的代码阅读工具——类型、签名、测试、命名——几乎不起作用。一个试图“阅读代码”的新员工无法了解为什么每一行都在那里，而一个只交给他们 Notion 文档和 Slack 频道的团队，实际上是在默认将入职培训“外包”给提示词的最初作者。

评测榜单的分数一夜之间掉了两分。在绿色运行（通过）和红色运行（失败）之间，唯一发布的内容就是上周的提示词 PR —— 那个包含了 17 处修改的 PR。两个章节调整了顺序。三个新的 few-shots。一个更严厉的拒绝条款。一个更换过的角色描述。还有一些人称之为“润色”的单词级改动。当复盘开始时，有人说了句显而易见的话：“肯定就是其中之一。”然后他们花接下来的两天时间去搞清楚到底是哪一个。

这两天时间是寻找单一回归最昂贵的方式。而另一种只需几分钟的方法则完全借用了一个有着 40 年历史的内核调试技巧：对补丁进行二分查找 (bisect)。将提示词视为一系列可回滚的变动块 (hunks)，将评测套件作为断言条件，让二分查找隔离出导致分数波动的代码行。其中的数学原理与 git bisect 在提交记录上运行的原理一致，而且它强制要求的提示词管理规范，其带来的收益甚至超过了二分查找本身。

我在上个季度交流过的一个团队在 8 周内发布了 4 轮偏好微调（preference fine-tuning）。每一轮，他们相对于上一个 Checkpoint 的离线胜率都在上升。每一轮，他们的 LLM-as-judge 都确认模型变得更好了。每一轮，他们的留存曲线（retention curve）都下垂得更厉害了一点。到第 4 轮时，裁判（judge）表示模型比 v0 基准提升了 71%；而用户的流失速度比开始前快了 9%。这就是一段话总结的 RLAIF 毁灭循环（doom loop），而残酷的是：该团队的流水线在技术上没有任何错误。

来自 AI 反馈的强化学习（RLAIF）—— 即使用更强的模型来生成你以前付钱请人标记的偏好标签 —— 是现代后训练（post-training）中最具经济合理性的决策之一。AI 生成的标签每个不到 1 美分；而人工标签则需要 1 美元甚至更多，对于特定领域的工作，价格通常是这个数字的 10 倍。在偏好数据集规模（数十万对数据）下，这就是六位数预算与五位数预算的区别。已发布的 RLAIF 基准测试显示，在摘要和对话任务上，其胜率在统计学上与 RLHF 无法区分。数学计算的结果是：切换到 RLAIF。

在单位成本方面，数学计算是对的；但在你购买的内容本质上，它错了。你买的不是偏好数据。你买的是裁判的偏好，并将其投影到你的数据上 —— 经过多轮训练，这种区别就体现为“与用户对齐”和“与另一个模型的审美对齐”之间的鸿沟。

我上个季度接触的一个团队上线了一个他们称之为“路由项目”的东西：在他们的旗舰模型前端放了一个微型 BERT 分类器，用来判断查询是否足够简单，以便分流给更便宜、更快速的备选方案。这个项目在三周内就回本了。成本仪表盘上绿光一片。旗舰模型的评估套件——包含三百个对抗性案例、每周的评分运行等等——依然在每个周五稳稳通过。

上线六周后，某个特定产品界面的留存率下降了四个百分点，没人能找到原因。旗舰模型表现正常。延迟也正常。结果发现，路由竟然将 71% 的查询发送到了廉价模型。这种情况从第二周就开始了。对于大多数用户来说，这个廉价模型才是真正的产品，而这个廉价模型根本没有任何评估套件。

这是我在 2026 年看到的采用 LLM 路由进行成本控制的团队中最常见的失败模式：评估规范被绑定在系统的昂贵长尾部分，而廉价的头部部分——即承载大部分请求量、定义了产品体验的部分——却处于盲跑状态。

一个在 8% 的情况下会推翻自己答案的验证器（verifier）并不是一个表现不稳定的模型。这是一个由于框架默认采用继承机制而进入生产环境的采样配置 Bug。规划器（planner）需要 temperature=0.7 来头脑风暴子任务的分解。而验证器 —— 其全部工作就是针对答案是否符合评分标准给出低方差的“是”或“否” —— 却是通过同一个 harness 调用实例化的，并默默地沿用了相同的温度设置。没有人故意这么设置。甚至根本没有人去设置它。

这是你的技术栈中最昂贵却无人认领的参数。它在调用树中不断累积：验证器上方的总结器、下方的结构化输出提取器，以及包裹整个流程的重试循环，都像使用全局变量一样沿用着规划器的“保持创意”旋钮。这笔账会同时体现在三个地方：评估的不稳定性、Token 支出，以及资深工程师花半天时间对一个结果发现根本不是退化的“性能退化”进行二分法排查。

一名用户在上午 9 点开始在她的电脑上与你的智能体谈判合同。她收到一条 Slack 消息，在午休时间切换到手机问了一个澄清问题，并在下午 4 点重新打开电脑标签页来修改草案。对她来说，这是一项任务 —— 处理一份合同的三个小时工作。对你的系统来说，这是两个设备上的三个会话，每个都有自己的 conversation-id，每个都有自己的记忆窗口，每个都呈现全新的问候并要求她重新粘贴已经讨论过两次的草案。

Bug 不在模型中。Bug 在于你的平台将“会话 (session)” —— 一个关于单一连接的传输层产物 —— 编码为上下文单位，而你的用户将“任务 (task)” —— 即合同 —— 编码为上下文单位。市面上的每个框架都悄悄地混淆了这两者，而它们之间的差距正是智能体 UX 损耗了一半的地方。