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

基准测试指标连续四个季度上升。用户满意度却没有。团队中没有人能解释这种差距，直到有人对提示词模板进行了 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 功能流失的主要原因，这些功能通过了安全审查，却从未针对“有用性”进行过衡量。

一名用户请求“一首关于 Postgres 复制的俳句”。模型返回了一首关于数据库的五行诗，其中提到了服务器和同步，听起来很有信心，读起来像模像样的英语，但并不是俳句。另一名用户请求“一个匹配 IPv6 地址但明确拒绝 IPv4 映射形式的正则表达式”。模型返回了一个匹配 IPv6 地址（包括它被要求拒绝的 IPv4 映射形式）的正则表达式，并用文字断言该正则符合规范。第三名用户请求“仅使用烹饪隐喻来解释 Monad（单子），不提及函数（function）或类型（type）”。模型给出了一个主要基于烹饪的解释，但其中使用了两次“函数”和三次“类型”。

这些都不是拒绝回答。这些也不是明显的幻觉。模型并没有说“我做不到”。它产生了一个自信、格式良好的响应，悄悄地放宽了请求中距离其训练分布众数最远的部分，而用户必须非常仔细地观察才能注意到。这种失效模式有一个值得使用的名称：强制符合偏见 (forced conformance bias) —— 模型将你的意图向典型答案“取整”，用户将结果视为忠实的响应，而本应捕捉到这一问题的评估套件本身也是从典型表述中提取的。

这在通常意义上并不是模型质量问题。模型正在做其训练推动它去做的事情。这是一个产品可靠性问题，如果评估团队的测试用例处于意图分布的众数位置，那么他们实际上只是针对其真实工作负载中简单的后半部分进行校准。

大多数 AI 功能发布延迟，并不是因为它们有缺陷。它们延迟，是因为团队仍在针对一套不能反映真实用户行为的测试集进行优化。每周基准分数都在提升，评估指标持续向好。而"实验室表现"与"生产价值"之间的差距，却在悄悄扩大。

令人不安的事实是：最初的 500 名真实用户，在两周内发现的可操作问题，远比再花四周调优提示词要多。这不是在为发布劣质产品辩护，而是在说：你当前对"准备好了"的判断，几乎肯定是错误校准的——只有真实的使用数据才能纠正它。

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

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

一个中型公司的团队在发布文档摘要功能三个月后，对提示词进行了优化。新提示词在他们手动测试的 5 个示例上表现更好。他们在周五下午部署了它。周一上午，Slack 里堆满了用户反馈：摘要现在会截断一半文档，却将截断后的内容呈现为完整版本。功能看起来没问题，变更通过了代码审查，没有人发现，因为根本没有评估机制——没有黄金测试集，没有回归基线，没有自动检查。棘轮已经悄悄转动了数月。

这就是评估债务最典型的表现形式。团队跳过评估并非因为粗心大意，而是因为为 AI 功能编写评估比听起来难得多，功能发布快且看起来运行良好，没有人想拖慢一个高速运转的团队。现在，他们正在偿还复利。