32 篇博文 含有标签「llm-evaluation」

一项提示词变体（prompt-variant）实验在某款 AI 辅助搜索产品的生产流量上运行。成功指标是点击响应中的任何建议操作。变体 B 交付的响应长度增加了大约 40%，且包含更多列举出的选项。点击率（CTR）高出 11%，且具有三个九（99.9%）的统计显著性。该实验被判定为获胜并上线。

一个月后，每周客户满意度调查下降了两个点。没人将其与上线联系起来，因为实验已被记录为成功，团队已经转向其他工作。季度复盘最终将满意度下降追溯到提示词的更改，诊断结果令人难以接受：变体 B 胜出并不是因为它给了用户更好的答案，而是因为更长的回答包含了更多的点击表面（clickable surfaces）。点击处理器在每次展示中触发得更频繁，是因为有更多可点击的内容，而不是因为你阅读的内容更值得采取行动。

“点赞”按钮是你所能埋点的最廉价信号。它也是最危险的信号之一，因为没有任何迹象表明它正在重塑你的评估集本应代表的分布。这个按钮作为正向信号被收集——策展流水线将其解读为高质量——而六个月后，评估集就被一群不包含最可能流失的客户的用户所选择的案例占据了。

这种失败很少表现为回归。它表现为一种偏离：每周评估趋势向好，企业级用户的 NPS 下滑，而团队只有在一个流失的账户指出了其团队一直遇到错误回答的具体问题类型时，才会诊断出这种差距。评估集中根本没有这种类型的案例。你正在优化的信号是真实的。它只是测量了错误的分布。

你设置了 seed=42。你设置了 temperature=0。你记录了运行情况，发布了仪表板，并在模型更换上签了字。第二天早上，重新运行相同的提示词却返回了不同的数字，你给出的解释——“肯定是采样噪声”——错得离谱：根本没有采样，而且噪声是结构性的。Seed 离开了你的客户端，网关将其丢弃，内核将你的请求与 17 个不相关的请求打包在一起，浮点归约（floating-point reduction）顺序在你眼皮底下发生了变化。你所谓的“可复现”基准测试，距离变成另一个基准测试其实只差一个批次（batch）。

这种失败模式是悄无声息的，因为技术栈中的每一层在技术上都是正确的。SDK 接受了 seed。供应商记录了 seed。模型返回了 system_fingerprint。评估工具记录了这三者。没有 5xx 错误，没有警告，没有抗议。仪表板上的数字只是发生了偏移，而团队将这种偏移合理化为一直存在的某种抖动——因为他们没有工具能告诉他们，他们看到的究竟是随机解码（stochastic decoding），还是导致三周的对比实验全部失效的后端轮换（backend rotation）。

影子部署（Shadow deployment）是每个人都公认的负责任的验证方式。你将实时流量镜像到一个候选模型中，记录其输出，但从不向用户展示结果。仪表盘数据一致，候选模型的响应在聚合质量指标上看起来与现有模型（incumbent）一样好，团队收到了新模型是“生产等效”的绿色信号，然后你将其推广到一小部分真实的流量中。在一天之内，在那些影子运行评估为匹配的查询类别上，面向用户的指标全面崩溃。

团队的第一反应是归咎于发布过程：也许是功能标志（feature flag）出错了，也许是路由器（router）路由错误，或者新模型在生产环境中的性能在某种程度上悄无声息地下降了，而影子部署时却没有发现。这些都不是真的。影子部署完全按设计运行。团队衡量的是候选模型孤立的输出——字符串对字符串——而推向生产环境的候选模型，其输出会重塑用户的下一条消息、下一轮对话、放弃决策以及整个会话的路径。影子部署衡量的是模型。生产环境衡量的是对话。这两者并非同一维度。

基准测试指标连续四个季度上升。用户满意度却没有。团队中没有人能解释这种差距，直到有人对提示词模板进行了 diff，并注意到 Few-shot 示例正从评估器读取的同一个 CSV 文件中获取。评估集已悄然变成了上下文示例。这个指标不再衡量泛化能力。它衡量的是模型在刚被告知答案的情况下，复制与之最接近问题的能力。

这就是我想命名的失效模式：评估集到提示词的泄露 (eval-to-prompt leakage)。它在结构上与传统机器学习中的测试集污染 (test-set contamination) 完全一致，但它是通过团队刻意构建的后端通道发生的。Few-shot 检索是一个合理的工程举措。评估库是一个合理的工程产物。当两者在没有人划定界限的情况下汇集到同一个存储层时，污染就产生了。

你在周二升级了模型。到了周五，“任务完成率”仪表盘从 71% 爬升到了 78%。领导层注意到了。有人在全员大会上截图展示了它。两周后，客服部门悄悄反馈说，特定一批复杂工单的流失率翻了一番。没人把这两件事联系起来，因为从纸面上看，智能体（agent）变得更好了。而现实情况是，新模型只是变得更擅长拒绝了。

这就是指标脱钩问题，也是以 LLM 为动力的产品欺骗其开发者的最昂贵方式之一。你的成功率并没有衡量你认为它在衡量的东西。它衡量的是“模型尝试的内容”与“模型尝试时做对的内容”的交集。当模型升级、提示词更改或安全调优（safety-tuning）改变了“尝试”的边界时，你的分子和分母会同步移动——即使在用户感知的质量一落千丈时，该比率也可能上升。

只要翻开任何足够长的生产环境对话记录，你都会发现有用户会将同一个问题问上三遍。每一轮的措辞都会稍微改变——代词换成了名词，加上了限定词，到第三次尝试时，那些客气的委婉话也消失了——但底层的请求是完全相同的。他们不是在问三个问题。他们是在问同一个问题，而智能体没能给出答案，用户希望这一次表达的方式能产生不同的效果。

这里的对话记录级信号是如此响亮，以至于近乎显而易见。用户已经通过他们的键盘敲击告诉你，之前的回答没有帮助。他们不需要填写调查问卷，不需要点踩。他们通过再次输入问题直接告诉了你。而在大多数生产环境的 AI 技术栈中，这个信号被评估流水线默默丢弃了，因为这些流水线孤立地对每一轮对话评分，而满意度调查仅在会话结束时触发——到那时，那些重复提问三次的用户通常已经流失，永远不会进行任何评分。

每天，你的智能体（Agent）都会把失败案例打包成“礼物”发还给你。一名用户点击了“踩”。另一名用户读完答案后一言不发，直接关掉了标签页。第三名用户将同一个问题改写了三次，直到智能体终于答对。每一个都是带标签的失败案例 —— 真实的输入、真实的上下文、系统失误的真实时刻 —— 由那些最希望系统运行正常的人免费提供给你。

大多数团队都会把这些信息全部丢掉。并非故意为之。点击“踩”只是增加了仪表盘上的一个计数；放弃使用表现为留存图表中的一次下滑；改写问题看起来就像普通的日常使用。没有任何东西能将信号及其产生的上下文一并捕捉，因此也就无法进行回放、分选（Triage）或转化为测试用例。你所拥有的最丰富的评估数据源正擦肩而过，而团队却还在继续手动编写合成的评估（Eval）案例。

这就是你从未构建的智能体反馈循环。它不是你忘记购买的某种工具，而是一条流水线 —— 从用户信号，到分选后的失败案例，再到新的评估案例 —— 它之所以未能建立，与技术本身关系不大。

你发布了一个模型升级。评估套件的分数从 87% 提升到了 91%。更新日志信手拈来，领导层纷纷鼓掌，然而那些真正重要的仪表盘——用户满意度、工单升级率、点踩率——却毫无动静。毫无起色。甚至可能略微变差了。

这是 AI 工程中最令人迷惑的失败模式之一，因为表面上没有任何东西坏掉。评估运行正常。数字是真实的。在你测试的 600 个示例中，模型确实有所改进。问题在于，这 600 个示例是你构建套件那一周的流量快照，而在那之后的几个月里，你的用户已经走出了画面。

大多数团队对待 LLM 评审员（LLM judge）的方式就像对待单元测试运行器一样：将其视为产生可信数字的中性基础设施。你编写评分标准（rubric），让模型针对你的输出进行评估，然后评审员返回分数。分数会显示在仪表盘上。仪表盘的趋势线驱动着产品路线图（roadmap）。没有人认为评审员是一个具有“行为”的东西，因为自动化的全部意义就在于将人为行为从环节中剔除。

但评审员本质上是一个模型。它有版本，有偏差。一旦它发生变化——无论是评估平台团队为了省钱更换了模型，还是提供商在 -latest 别名后悄悄滚动了权重——它产生的所有历史分数与新分数之间都会变得不可比。你的季度质量趋势现在是用两种不同的货币计价的，而且没有人给出汇率。

这并非假设的边缘情况。如果不像对待测量仪器那样对 LLM 进行版本化管理，这就是将其作为测量工具的必然结果。

追踪单个质量信号在现代 AI 流水线中的路径。一个智能体（Agent）起草回复。第二个模型对其进行评审，打出 9 分（满分 10 分）。该评分被记录下来。在季度末，这些记录的评分成为新的评估集（eval set），而下一个模型则针对该评估集进行微调以获得高分。现在问一个显而易见的问题：在这一闭环中，人类在哪一个环节审视过实际输出？

在许多流水线中，诚实的回答是：无处寻觅。执行工作的智能体由另一个智能体评审，而该评审者的结论又会作为下一轮评估的输入。这个回路是封闭的。它持续运行，生成仪表盘，而仪表盘显示一片绿色（一切正常）。然而，它在任何阶段都不包含对现实情况的衡量。

有一类 LLM 失败，既不会出现在安全仪表板上，也不会触发故障工单。模型委婉地表示拒绝，并引用了一个听起来合理的政策。它提供了一段长达四段的对冲陈述，而不是直接给出答案。用户关闭了标签页。事后分析中的信任评分显示“无事故”。然而，六周后的留存率图表却显示了另一番景象。

拒绝率是大多数安全团队首先部署的指标，因为它最容易定义。模型要么遵循了指令，要么没有，而你可以统计那些“没有”的情况。这种二元法对于捕捉一种特定失败非常有用——即模型在生产环境中生成有害内容。但在结构上，它无法捕捉相反的失败：模型在生产环境中没有产出任何有用的东西，但从各项安全指标来看，它的表现却完美无缺。这种第二类失败现在已成为 AI 功能流失的主要原因，这些功能通过了安全审查，却从未针对“有用性”进行过衡量。