134 篇博文 含有标签「evals」

周二下午，一个只有六行代码的系统提示词（system prompt）编辑出现在了一个 Pull Request (PR) 中。Diff 只是普通的英文。两位评审者扫了一眼新的措辞，觉得读起来更自然，于是点击了批准。PR 在不到一分钟内合并。到了周五，客服开始收到关于智能体的工单：它突然拒绝总结超过一定长度的文档，不再引用来源，并莫名其妙地在每句回复开头都加上 “Certainly!” —— 这种行为没人要求过，Diff 中也无法预见。

当一个花了十年时间学习如何评审代码的团队，在面对提示词这一产物时，竟然退化到了第一周的水平，结果就是这样。Diff 看起来 毫无害处，因为它读起来像英语，而人类正是用眼睛来审阅英语的。让代码评审发挥作用的规范 —— 运行测试、检查影响范围、对 “小改动” 保持适当的怀疑 —— 并没有悄然转化。措辞变好了，但行为变差了，直到用户发现之前，没人注意到。

周二还能用的提示词（prompt），到周四就返回了“我无法提供帮助”。CI 评估依然是绿色的。你配置中的模型名称没变。提示词在字节层面完全一致，在源码控制中也经过了哈希处理和固定。然而，一个围绕新出现的拒绝回答（refusal）的客户支持线程正在形成——AI 团队在两周内都不会察觉到这一点，因为它必须经过一级支持、分类，最后才落到能读取追踪信息（trace）的人手中。

这就是服务商侧的安全漂移（provider-side safety drift），它是当今生产环境 AI 中构建最不完善的监控缺口。前沿服务商会以不在你发布日程上的频率，在服务端调整安全过滤器、拒绝阈值和内容分类器。你的团队没有订阅这些变更，通常也没有发布说明。而且这种退化是具有非对称性的，以一种确实难以察觉的方式呈现：正当意图的拒绝率悄悄爬升，而你认为服务商会过滤的有害查询却开始悄悄溜过。边界在两端独立移动，且毫无预警。

打开任何生产环境 LLM 功能的安全仪表盘，你都会看到拒绝率（refusal rate）被绘制成一条单线，并带有颜色标记：下降是坏事，上升是好事。这背后的隐含逻辑是：拒绝是系统对不该做的事情说“不”，因此拒绝率越高，产品就越安全。这种说法只反映了事实的一半，而缺失的另一半，正是已部署助手中大多数无形质量损伤的根源。

拒绝率是一个双面分布。右尾是安全团队痴迷的部分：模型同意编写恶意软件、伪造药物剂量或生成政策明确禁止的内容。左尾则是相反的失败——错误拒绝（false refusals），即模型因为某些表面特征与禁止类别模式匹配，从而拒绝了良性请求。客户询问如何对费用提出异议，却收到“我无法提供财务建议”的样板回复。护士询问药物相互作用，却被引导至“请咨询医疗保健专业人员”。开发者询问如何解析邮件头，却因为提示词中包含 “exploit” 一词而被拒绝。

三个团队正在查看同一个事件流，每个团队都有一个名为 session_id 的列，但每个团队对什么是“会话”都有不同的定义。计费（Billing）继承了来自认证库的 30 分钟空闲窗口。评估（Eval）从聊天机器人框架中继承了“直到用户说‘再见’或停止打字 10 分钟为止”的定义。记忆（Memory）则使用 UI 在用户点击“开启新聊天”时生成的线程 ID —— 而大多数用户从不点击这个按钮。三列数据，三种语义，一个汇总仪表盘，以及三个共用一个根因但互不相关的 Bug。

这就是会话边界问题（session boundary problem）。它看起来像是一个埋点琐事，但实际上是一个披着基础设施外衣的产品问题：一段对话在哪里结束？坦诚的回答是没有单一的标准答案 —— 计费会话、评估会话和记忆会话并不是同一种对象 —— 如果一个团队选择了一个默认定义并让另外两个团队继承它，那么他们交付的就是具有相同根因的计费纠纷、评估偏见和内存泄漏。

我认识的一个团队在某个周二向他们的支持智能体目录发布了一个新的 lookup_customer_v2 工具。这个工具的作用范围很窄，经过了充分的隔离测试，并通过了评审。到了周四，一个毫不相关的流程——退款处理——在之前一直运行良好的案例中出现了约 4% 的失败。退款工具没有变。退款提示词没有变。模型也没有变。改变的是规划器（planner）现在在处理退款资格查询时选择了 lookup_customer_v2，而以前这些查询都会清晰地路由到 get_account_status。原因是新工具的描述中恰好包含 "eligibility"（资格）这个词，并在模型内部使用的某种相似性启发式算法下获得了更高的排名。

这就是依赖炸弹。团队通常将工具注册表视为增量式的——“我们只是增加了一个东西，能出什么问题”——但规划器并不将你的注册表视为独立能力的列表。它看到的是各种选择上的概率分布，而每一个条目都会重新分配权重。增加一个工具可能会悄悄地削弱其他地方的行为，而你的评估套件（eval suite）可能会漏掉这一点，因为没有人写过回归测试来规定“在这种情况下，智能体应该仍然选择 旧 工具”。

这是一个大多数 AI 团队都不愿面对的发现：在一项生成了超过 150,000 个评估实例、涵盖 22 个任务的大规模研究中，大约 40% 的 LLM 作为裁判（LLM-as-judge）的对比显示出可衡量的偏见。这种偏见并非随机噪声，而是系统性的、可复现的，并且与模型的训练方式相关。当你使用一个模型来生成评估集，然后使用同一个模型（或其近亲）来对其进行评分时，你测量的并不是质量，而是一个系统与其自身的一致程度。

合成评估数据之所以成为标准实践，是有充分理由的。人工标注速度慢、成本高且难以规模化。LLM 生成的测试用例让团队能够在夜之间生成数千个示例。问题出现在生成器和裁判拥有共同祖先时——在 2025 年，这几乎是常态。结果是一个评估流水线在自信地报告高分的同时，却隐藏了你构建它原本想要捕捉的失败模式。

一个构建基于LLM的文献筛选工具的团队在测试集上庆祝96%的准确率。按照任何标准工程指标，他们的模型表现都非常出色。但有一个问题：它找到了零个真正的阳性结果。该模型学会了将所有内容归类为无关内容，但仍然获得了近乎完美的准确率，因为相关论文在数据集中极为罕见。失败不在于模型——而在于指标。

这种失败模式并不罕见。它每周都在AI团队中悄然上演，工程师在没有产品输入的情况下选择评估指标——就像选择排序算法一样，视其为有正确答案的技术选择。这种框架是错误的。指标选择是一个产品决策。它编码了你愿意容忍哪些失败模式、你在为哪些用户优化，以及在你的特定场景中"好"究竟意味着什么。搞错这一点会产生看起来严谨却衡量了错误事物的评估套件。

我合作过的一个团队花了六个月的时间，将一个系统提示词（system prompt）调整到大约 4000 个 token。这是他们的镇店之宝——通过不断累积边缘情况处理、格式规则、人设指令、回退行为以及十几个 few-shot 示例而精心打造。后来，一名初级工程师加入，问为什么提示词这么长，并用一个下午的时间重写了它。新版本只有 200 个 token。在他们现有的评估集上，它的得分高出了 4 分。运行成本也降低了 40 倍，而且速度明显变快。

这并不是一个关于神奇短提示词的轶事。这是我几乎在每次阅读运行超过一个季度的生产级系统提示词时都会看到的模式。长提示词是随意的累加，而非设计的结果。QA 中出现的每个失效模式都贡献了一个段落。观看演示的每位利益相关者都贡献了一条语气指令。每个“似乎有帮助”的例子都被固定在了底部。结果就是，提示词比它要引导的用户输入还要长，充斥着模型在推理时必须默默解决的内部矛盾，注意力被稀释在各种相互竞争的需求中。

1964 年，三十八个人在皇后区的公寓楼外目睹了 Kitty Genovese 遭到袭击。直到为时已晚，才有人报警。Latané 和 Darley 在接下来的十年里一直在解释其中的原因：看到问题的人越多，其中任何一个人采取行动的可能性就越小。他们称之为“责任分散效应”。在他们著名的癫痫实验中，当参与者认为只有自己和受害者在一起时，85% 的人会介入。当他们相信另外四个人也能听到受害者发病时，只有 31% 的人采取了行动。

现在想象一下你最近一次 AI 功能的发布。产品团队编写了 Prompt。工程团队选择了模型并连接了网关。数据团队整理了检索语料库。安全团队加上了输入和输出过滤器。客服团队起草了升级方案。房间里有五个团队。每个团队都按时完成了各自的部分。三个月后，该功能的准确率悄悄从 89% 滑落到 71%，评估套件自发布周以来就没运行过，当你询问谁负责处理这一回归问题时，每个团队都能点出另外三个比自己更有责任负责的团队。

经典的 Bug Bash 是一种为确定性软件量身定制的确定性仪式。十名工程师挤在一个 Slack 频道里两小时，对照着黄金路径流程清单疯狂测试，然后提交带有清晰复现步骤的工单：“点击 X，看到 Y，预期 Z。” 这套方法之所以奏效，是因为被测系统是可复现的——相同的输入，相同的输出，相同的 Bug，次次如此。

如果针对 AI 功能运行完全相同的仪式，你最终会得到 200 张工单，其中 180 张会因为“符合预期的随机波动”而被关闭，同时还会漏掉那 20 张预示着真正的群体性回归（cohort regression）的工单。这种形式不仅陈旧，而且完全错位了。针对基于 LLM 的功能进行 Bug Bash 并不是一场捕捉缺陷的会议。它是一场针对概率分布的抽样练习，如果团队像运行确定性测试那样运行它，就是在收集噪声并将其视为信号。

这篇文章讨论的是如何为随机系统重新设计 Bug Bash——包括流程形式、参与者、分级准则以及什么才算“完成”等方面需要做出哪些改变。

一个基于前沿模型的聊天功能，单次对话成本大约是 30 美分。而同功能的蒸馏版本，单次对话成本大约只有 0.3 美分。这并不是同一个产品的两种实现方式，而是两个截然不同的产品。它们有着不同的免费层级经济模型、不同的获客成本、不同的市场定位以及不同的竞争护城河。如果一个团队只是将蒸馏版本当作“更便宜的同款功能”发布，那就白费了这一招。

大多数工程组织仍将蒸馏视为研究团队的优化任务，认为是在功能“完成”后，为了挤出推理成本而对已经按前沿模型规格设计好的东西进行的后期处理。这种理解在数量级上就是错误的。Teacher 模型（教师模型）的选择、Student 模型（学生模型）的选择、用于评测 Student 的评估套件，以及 Student 最终部署的产品界面，本质上都是产品决策。它们决定了你同意放弃哪些能力、你为哪种流量形态进行设计，以及你正在开启哪种价格底线。如果把这些交给研究团队去针对 MMLU 进行优化，你最终发布的模型虽然在榜单上表现优异，但对产品本身毫无意义。

决定一个模型是否上线生产环境的数字，是由运行在某个工程师 MacBook 上的 Jupyter Notebook 生成的。数据来源是 Slack 私聊中的一个 CSV 文件，评分则由一个没人固定版本的裁判模型完成。两周后，在工程师又动了三次 Notebook，且 API 供应商悄悄发布了一个微小的模型更新后，团队里已经没人能重现那个数字了——包括当初生成它的那个工程师。然而，那个数字就是准入闸门。它决定了 GPT-4o-mini 是否足以在客户支持流程中取代 GPT-4；它决定了新提示词模板的发布；它决定了微调模型的晋升。团队把它视为核心承重构件，却像对待便利贴一样存储它。

这就是“评估差距”（eval gap）。五年来，业界一直在将评估视为一个方法论问题——哪种评分技术、哪种裁判模型、哪种评分标准、哪种数据集——却几乎从未将其视为一个工程问题。但是，一旦你的评估套件开始充当生产发布的守门员，它就继承了生产栈其余部分所遵循的所有要求：可重现性、版本控制、所有权、可观测性、依赖管理、延迟与可靠性预算，以及一套在构建它的工程师离职后依然能运行的流水线。大多数团队完全跳过了这一层，只有在发生重大事故后才发现它的缺失——通常是评估分数显示绿色，而用户体验却是一片红色。