113 篇博文 含有标签「evals」

每个 AI 组织都有一个坟场。不是服务的坟场——服务会有操作手册（runbook）、弃用横幅、30 天的迁移窗口，以及在平台团队季度路线图上的位置。这个坟场是属于 功能 的：从未转正的智能摘要 Beta 版、两个大客户据此构建了工作流的自动分类器、演示效果极佳但在灰度发布后无人问津的 Agent 流程。弃用一个端点很容易。但与之关联的其他四个东西——提示词（prompt）、评测员（judge）、回归测试集（regression set）和事故记忆（incident memory）——才是真正需要一个季度才能搞定的，而且团队中没人写过这种手册，因为没人会因为下线某个功能而获得晋升。

这就是差距。大多数关于“模型弃用”的公开讨论都是针对供应商侧的下线：GPT-4o 在某天停止服务，Assistants API Beta 版在 8 月 26 日下线，DALL-E 3 在 5 月 12 日退休，而你的平台团队有一个通知期来进行迁移。这个问题有现成的手册，因为供应商发布了日期，迁移是被迫的，而且工作量可以塞进一个 Sprint 中。而“内部”版本——当你决定你构建的一个功能未能转正并必须将其撤除时——则没有任何这类强制因素。弃用日期由你说了算。迁移路径由你来构建。而且你必须退役的产物不是单个端点，而是一堆纠缠在一起的、与模型相关的资产，你的监控系统几乎感觉不到它们的存在。

团队最开始有 5 个工具和一个在生产流量中命中率达 95% 的规划器（planner）。18 个月后，他们有了 51 个工具，而规划器的命中率降到了 26%，原本那 5 个工具能干净利落处理的简单案例——预订会议、查询客户、提交工单——现在有时会路由到错误的工具，因为目录中有三个听起来很像的“替代品”。没有人故意让规划器变差。每一次工具的增加在当时看来都是合理的。这种累积的代价就是“可组合性税”（composability tax），每一个在工具目录增长过程中缺乏淘汰机制的产品都在支付这笔费用。

这笔“税”是一条曲线，而不是悬崖。Berkeley Function Calling Leaderboard 直接测量了这一点：在日历调度任务中，当跨多个领域的工具从 4 个增加到 51 个时，准确率从 43% 下降到了 2%。在客户支持类任务中，GPT-4o 从 58%（单一领域，9 个工具）下降到 26%（7 个领域，51 个工具）。Llama-3.3-70B 在同样的扩张下从 21% 降到了 0%。这种趋势在不同模型和任务类型中不断重复：每增加一个工具，规划器就会在曲线上进一步下滑，而且随着目录变大，边际损害会变得更严重，因为新加入的条目与现有的条目越来越难以区分。

你公司最昂贵的评测集 (eval set) 并不在你的代码仓库里。它藏在销售工程师六个月前整理的一份幻灯片里，外加三个以你前五大客户命名的演示账号，以及一段半记不清的脚本，上面写着“点击这里，让智能体总结上个季度，见证奇迹的时刻”。它每周运行一两次，面向价值六位数或七位数的潜在客户。AI 团队里没有人曾为它完整跑过一次。

接着，你在某个周二发布了模型迁移。周四下午 4 点，销售工程师在值班频道发消息：摘要输出现在以“当然可以！这是摘要……”开头，而不是直接进入要点；数字被拼写成了单词而非阿拉伯数字；而潜在客户 —— 一位在四周前就预约了这次会议的财富 500 强 CFO —— 刚刚询问该产品是否一直这么啰嗦。发布说明称这是一次 1.2 个百分点的评测提升 (eval lift)。

评估集（eval set）是你的 AI 团队产出的阅读量最高的工件，而你几乎肯定不知道谁在阅读它。代码库是私有的，CI 任务是内部的，文件就在 prompts/ 目录的上一级——然而，上个季度一名销售工程师为了演示抓取了六个案例，一名市场分析师将三个失败案例放进了“看看我们的系统有多健壮”的幻灯片中，客户成功部门在续约电话中逐字引用了评估通过率，而产品部门则将该文件视为 AI 团队不愿分享的隐藏规范。阅读这些案例文件的人比阅读生成它们的代码的人还要多，而 AI 团队中却没人在意。

这不仅仅是权限管理的失效。评估集与代码库的其他部分位于同一个 Git 服务器上，拥有与其他工程产物相同的访问控制。问题在于，AI 团队是唯一将评估集视为代码的群体。其他所有人都会将其视为文档、营销材料、产品规范或客户投诉日志——而这些解读中的每一项都会从同一个文件中提取不同的片段，针对不同的受众进行包装，并将其发送到 AI 团队观察不到的地方。

新员工打开入职文档。文档指向了十一个月前的一个服务架构图、一个最后更新于十月的名为 “我们的 LLM 技术栈” 的 Confluence 页面，以及一个 “我们使用的模型供应商” Notion 表格。这些文档都没有告诉他们哪个提示词是针对哪种失败模式优化的，哪些评估案例是在哪次事故后添加的，当模型从 4.5 升级到 4.6 时哪个评判模型被重新校准了，或者为什么支持代理的系统提示词有一段谁都不敢动的奇怪的三行前导内容。入职两周后，他们提交了一个 “小的提示词清理” PR，删除了这段前导内容。评估套件通过了。不到一天，生产环境的准确率下降了四个百分点。

标准的新员工入职指南 —— 阅读架构文档、配置电脑、在第二周前完成第一个 PR —— 是为加入服务端的工程师设计的。AI 工程师加入的是一种不同的制品。他们要编辑的不是某个主任工程师写的 5000 行 Go 服务；而是一个经历了 11 次事故和 17 次评估驱动重写的 30 行提示词，而这 30 行代码的意义只存在于团队中两个人的脑子里。你的入职文档无法捕捉到这些，而尝试写一份更长的文档是错误的修复方案。

针对付费用户群追踪数据进行模型优化的团队，其实是在一个“简单分布”上给自己打分。付费用户已经形成了一套工作流。他们之所以选择这款产品，是因为产品中的某些特质证明了刷信用卡付费的合理性，这意味着当他们进入评估集（eval set）时，已经学会了哪些提示词（prompts）有效，哪些功能给力，以及哪些“坑”不该踩。而免费层用户完全不是这样。他们是匿名的、探索性的，通常带有对抗性，且往往是非英语母语者，正在用第二语言对产品进行压力测试，他们触发了评估集从未涵盖的长尾失败模式。

这种不对称性正悄无声息地吞噬着每一个免费增值（freemium）AI 产品的转化漏斗。团队针对主要从付费追踪数据中提取的精选样本对模型进行评分。而免费层的那些“古怪”追踪数据——那些没有模板、用户正真诚地试图搞清楚产品能做什么的数据——从未被标注，从未进行回归测试，也从未为下一次提示词修改提供参考。模型在付费分布上变得越来越好，但在决定免费用户是否升级的分布上却慢慢变差。

在最近一次 prompt 变更后，你的综合评估分数上升了 1.2 个点。但在同一周，法语查询的 CSAT（客户满意度）下降了 4 个点。这两个数字都是正确的。它们之所以不一致，是因为评估集（eval set）中 88% 是英语，6% 是西班牙语，其余的是长尾语言，其中任何一种语言的流量都不足以触动汇总数据的变化。法语的性能回归就在你的数据中 —— 它只是恰好位于顶级指标（top-line metric）噪声基底以下三个小数点位。

这是我在生产级 AI 系统中看到的最常见的区域漂移（locale drift）形式：不是突然的崩溃，也不是翻译字符串的 bug，而是一种被汇总数据掩盖、并最终在支持队列中浮现的持续性能差距。当巴黎办公室的人转发一张截图时，你已经在那个回归之上又发布了两个 prompt 变更，而二分查找（bisect）的成本需要耗费三个工程师工作日。

每次模型升级都会被当作一种简单的“替换”推销给团队：一行配置更改、在延迟、成本或质量上可衡量的提升，以及几天用于吸收新模型怪癖的提示词微调。采购方案展示了每 token 的差值，工程工单列出了发布阶段，FP&A 团队预记了季度节省。接着，评估分值出炉，却没人认得出来。质量在理应提升的地方毫无波动。曾经达成一致的两个评分员现在分歧达 10 分之多。快照套件显示为红色，但差异看起来只是措辞调整。站会上有人提出了那个本应从迁移计划第一天就该出现的问题：模型到底是在针对什么评分？

这是第二张账单 —— 评估重锚税 (eval re-anchoring tax) —— 且它往往比第一张更昂贵。人工标注的参考分数锚定在旧模型的输出分布上。作为评委的 LLM 评分器针对旧模型的失败模式进行了校准。快照固定装置捕捉的是旧模型的措辞。团队对“优质输出”的直觉是基于旧模型的风格特征训练出来的。在模型替换中，这些都无法完好无损地保留下来。

传呼机在凌晨 3:02 响起。你眯起眼睛盯着手机，预料着那些常见故障：数据库故障转移、CDN 边缘节点失联，或者是某个八个月没人碰过的服务出现了 500 报错峰值。然而，警报显示的是：summarizer.eval-on-traffic.helpfulness rolling-1h: 4.21 → 4.05 (Δ -0.16)。没有 HTTP 错误。没有延迟峰值。没有服务宕机。系统在过去一小时内处理的每一个请求都返回了 200，并且响应体解析正常。然而，情况显然比午夜时分变糟了，而值班轮换要求你查明原因。

这种值班任务是标准的运维手册中从未提及的。出故障的东西并没有“坏掉”——它只是退化（regress）了。你多年来追踪的错误预算是以可用性和延迟来衡量的，而触发此次报警的故障模式在两者中都不可见。报警是真实的，客户受到的影响也是真实的，而你通常的诊断循环——检查部署日志、检查依赖图、查找错误的发布版本、执行回滚——在你意识到那个“错误的发布”可能只是昨天下午 4 点上线的一个 30 行系统提示词（system-prompt）的修改时，便碰了壁。在代码审查中，那次修改看起来完全无害。

一位资深工程师向 planner 提示词（prompt）提交了一个只有四个单词的修改——“if uncertain, ask first”（如果不确定，先询问）。Planner 自身的评估集（用于评分计划是否合理）提升了 0.5 分。他们合并了代码。两周后，verifier 的评估显示通过率出现了 3 个百分点的回归，且没人能复现。根本原因在于：planner 现在会提出更多澄清性问题，executor 在第二轮收到的任务描述变短了，而 verifier 的评分准则（rubric）是针对之前 executor 较长的输出进行隐式调优的。一个没人标记为高风险的修改，一次性改变了下游的三个分布。

当你把智能体（agent）内部的提示词看作一个扁平的文件文件夹，而不是一个带有“边”（edges）的图（graph）时，就会发生这种情况。提示词有负责人，但它们之间的“边”却无人看管。

一位客户询问你的支持代理如何执行某项操作。代理检索到了三个相关性评分很高的文档分块，合成了一个自信的答案，并引导客户完成一个五步操作流程。然而，这个流程的最后一步是一个在四个月前就已经不存在的按钮。客户提交了工单。值班工程师调出评估套件，发现结果是绿色的；调出检索追踪，发现结果也是绿色的——模型没有产生幻觉，它忠实地引用了描述产品团队在上个季度发布中重命名的功能的文档。

这就是我想命名的失败模式：不是幻觉，也不是检索未命中，而是幻影库存 (phantom inventory) 问题。你的检索语料库是已不存在的产品界面的快照。向量存储不知道产品发生了变化。评估套件也不知道。唯一能持续捕捉到这一点的系统是支持工单队列，而当工单提交时，客户已经被告知去点击一个并不存在的按钮了。

团队像规划服务一样规划评估集（eval suite）：梳理失败模式、起草评分标准（rubric）、争论样本量大小、安排评判员校准（judge calibration）时间表。然后，他们把评测员产能（rater capacity）当作脚注——“我们会让标注团队每周评测几百条”——然后就发布了剩下的部分。六周后，评测员队列堆积了 4,300 个条目，评估速度坍缩到每月仅一次评判员校准周期，在一次规划评审会上，有人道破了那个大家都心照不宣的事实：没有人对人力进行过产能规划。

在任何严肃对待人工评分的 AI 系统中，评测员吞吐量都是评估速度的约束性瓶颈。将标注视为 SRE 问题而非招聘问题的准则，才是产品发布的关键。一名人类评审员在专家难度下每小时处理 50–100 个样本，而一名专家标注员每周的上限约为 500–1,000 个样本——这些数字不是通过增加人头就能蛮力解决的招聘问题。它们是评估系统的运行属性，必须像建模数据库 IOPS 一样对其进行建模和预算编制。