143 篇博文 含有标签「evals」

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

一家世界 500 强公司的采购主管打开了你的支持智能体，询问为什么 SOC 2 报告中提到的某个合规控制项在你的产品中已不再执行。你的智能体用对待免费版个人用户的语气回答了她——带着三个感叹号、一个表情符号，以及一个“联系我们团队”的愉快建议，既没有升级路径，也没有引用出处。采购主管把这张截图转发给了她的首席信息安全官（CISO），只写了一行字：“这就是他们派来处理我们合规问题的东西。”你失去了续约机会，不是因为答案错了，而是因为语气在那个场合不对。

大多数团队之所以只发布一种智能体人格面具，是因为组织架构中只有一个支持团队。然而，客户群体很少是单一的。企业买家期望正式感、引用来源和明确的人员升级路径。自助服务用户想要快速回答和零摩擦。开发者想要代码，而不是长篇大论。单一的人格面具在某些群体看来是居高临下的，而在另一些群体看来则是不专业的。而“让用户选择语气”则是将一个本不该由用户承担的产品决策推卸给了用户。

确定性软件的 PRD 模板已经演变成了一种肌肉记忆。问题陈述、用户故事、验收标准、边缘情况、成功指标、范围削减。工程师知道如何阅读它，产品经理（PM）知道如何填写它，设计师知道该从哪些章节提取原型图。这是一个被磨损得恰到好处的产物，它交付了一代又一代的 CRUD 应用、仪表盘和 SaaS 工作流。

它也没有“模型在 5% 的情况下会出错”的字段，没有“我们接受的评估（Eval）合格分”的字段，没有“当模型拒绝回答时用户会看到什么”的字段，也没有“该 PRD 锁定了哪个提示词（Prompt）版本，以及发布后允许谁进行更改”的字段。每一个按照这种模板交付的 AI 功能，都带有一份谁也没写下来的隐性契约。复盘总是让人们在遭遇挫折后才痛苦地意识到这一点。

你账单上的模型名称与上季度完全一致。API 响应中的版本字符串也没有改变。模型卡片和定价页面看起来也一模一样。然而，你的评估得分却下降了 0.5 分，拒绝模式以你提示词中未要求的方式发生了偏移，上周二还收到了几起客户投诉，称输出结果“感觉不一样”。你调试了代码，却一无所获。代码没变。权重变了。

静默量化（Silent quantization）是你合同约定的模型与供应商实际交付的模型之间的差距。之所以发生这种情况，是因为推理经济学持续收紧——每一美元的 GPU 算力在本季度必须承载比上季度更多的请求——而消化这种压力的最廉价方式，就是在更廉价的精度层级上重新托管同一个模型。FP16 变成了 FP8。在某些路由中，FP8 变成了 FP4。混合精度分片被替换进来。版本字符串没有变动，因为版本字符串从来都不是精度合约，而是一份营销合约。