160 篇博文 含有标签「evaluation」

你的工程团队已经开发文档摘要生成器三个月了。规范要求：“摘要生成器应返回准确的摘要。”你发布了它。用户抱怨摘要有一半时间是错误的。事后分析显示，在发布前没有人能以可测试的方式定义“准确”的含义。

这是 AI 功能开发的标准轨迹，之所以会发生，是因为团队将为确定性软件构建的验收标准模式，套用到了本质上是概率性的系统上。由 LLM 驱动的摘要生成器没有单一的“正确”输出 —— 它有一系列的输出分布，其中一些是可以接受的，另一些则不然。二元的通过/失败规范无法映射到分布上。

这个问题不仅是哲学上的，它还会导致切实的痛苦：功能发布时质量门槛模糊，回归测试在用户发现之前难以察觉，产品和工程团队在功能是否“完成”上无法达成一致，因为没有人规定对于随机系统来说，“完成”意味着什么。这篇文章将介绍真正有效的模式。

在传统软件中，发布功能以合并代码（merge）告终。单元测试通过。集成测试通过。QA 签字认可。你切换标志（flag），除非在生产环境中出现 bug，否则你就可以继续接下来的工作。这个功能就“完成”了。对于 AI 驱动的功能，那个时刻并不存在 —— 如果你假装它存在，你就是在累积稳定性债务，这最终会演变成用户信任问题。

原因很简单，但很少有人围绕它进行设计：确定性软件对于相同的输入每次都会产生相同的输出。AI 功能则不然。这并非因为 bug，而是因为其行为由一个存在于代码库之外的模型定义，该模型基于反映不断变化的世界的数据进行训练，并由那些随着看到更多可能性而不断提高期望的用户使用。

一个团队花了六个月时间训练一个情感分类器。留出集（holdout set）上的准确率看起来很稳健。他们发布了它。三个月后，一项审计显示，该模型一致地将非英语母语者的产品投诉评价为比母语者的相同投诉更负面——即使文本表达的意思完全相同。根源不在于模型架构，不在于训练过程，而在于标注团队：十二名身处同一个时区的英语母语者，没有人注意到某些表述在翻译后的文本中承载着不同的情感权重。

模型学到的是标注者的盲点，而非真实的信号。

这就是实践中的标注者偏差（annotator bias）。它不会自我宣告，而是表现为你信任的评估分数、看起来合理的基准排名，以及在未经过仔细测试的子组上表现怪异的已部署系统。基准真相（Ground truth）的污染处于机器学习流水线中所有其他环节的上游——而这是大多数团队发现得太晚的问题。

大多数 AI 团队把通过评估套件视为系统正常运行的信号。但事实并非如此——至少不全是。一个稳定得分 87% 的套件只做了一件事：告诉你系统在套件恰好覆盖的那 87% 的场景中表现良好。如果这套测试是六个月前手工整理的，基于团队能想到的示例，从未用真实流量更新过，那它正在以越来越高的置信度测量错误的东西。

这就是评估覆盖率问题。它与你的评估器是否准确无关——而是关于你测试集中的查询分布是否与用户实际发送的查询分布相匹配。当这两种分布出现偏差时，你会得到一个比评估失败更糟糕的结果：一个通过的评估，背后却是悄然劣化的产品。

在 AI 产品开发中，有一个常见的假设：如果一个模型能处理难题，它就一定能处理附近的简单任务。这个假设是错误的，它导致了一类生产环境下的失败，而无论你读多少基准测试报告都无法为此做好准备。

这一潜在现象的研究术语是“破碎边界”（jagged frontier）——AI 的能力边界并不是一条平滑的线，并非难题在界外、简单任务在界内。它是一个参差不齐、不可预测的形状。AI 系统可以编写生产级别的数据库查询优化器，却仍然会算错图中两条线段是否相交。它们可以通过博士级别的科学考试，却在涉及空间关系的儿童谜题上失败。它们可以综合 50 页的文档，然后对自己刚刚读过的一段文字产生充满自信的幻觉。

一个团队为内部文档构建了 RAG 流水线。检索效果看起来不错——相关段落都被召回了。但在生产环境中，用户持续收到过时的答案。深入查看日志后他们发现，模型返回的是训练数据中的事实，而非它被给予的文档内容。检索成功了，但模型就是没用上它。

这就是知识污染问题：模型的参数记忆——训练期间编码进权重的知识——压制了检索到的上下文。这种失败悄无声息、表现自信，也是生产环境 RAG 系统中最常见的故障模式之一。

你的评测集（eval suite）显示准确率为 94%。但用户反馈，对于名字不是 "John" 或 "Alice" 的情况，该功能是失效的。这两者都是事实，而它们之间的差距有一个专门的名字：你精心挑选的测试集只编码了你已经预料到的失败模式。

基于属性的测试（Property-based testing，简称 PBT）诞生于 1999 年，旨在揭示确定性软件中正是这一类的盲点。将其应用于 LLM 输出时，它会自动生成数以万计的对抗性输入变体，探测手写测试用例在结构上无法触及的领域边界。2025 年的一项 OOPSLA 研究发现，平均每个基于属性的测试发现的变异 Bug 数量大约是普通单元测试的 50 倍。另一项研究测量出，PBT 和基于示例的测试（EBT）在不同的 Bug 上会失败——将两者结合后，检测率从 68.75% 提高到了 81.25%。这 12.5 个百分点的差距并非舍入误差，它代表了单一方法无法察觉的整整一类故障。

本文面向那些已经拥有评测集，并希望找出那些评测集在结构上无法发现的 Bug 的工程师。

RAG 系统中存在一种常见的失败模式，数月内都不会被察觉：你的检索器（retriever）返回了错误的文档，但你的生成器（generator）足够擅长即兴发挥，以至于端到端的质量分数依然保持绿色。你不断调整提示词（prompt）。你升级模型。但都无济于事。这个 Bug 存在于上游三层，而你的指标对其视而不见。

这就是检索器评估反模式（retriever eval antipattern）——将整个 RAG 流水线作为一个整体进行评估，这让生成器吸收并隐藏了检索失败。其结果是，你无法区分是“生成器失败”还是“检索器失败”，从而使得系统性的改进几乎变得不可能。

你的红队刚完成了一次越狱扫描。他们发现了三个新型攻击向量，将其整理成文档，并把这些提示词放入共享提示词库，供其他人学习。一周后，安全团队运行基线评估，报告鲁棒性提升了 12%。所有人都在庆祝，却没人问为什么。

实际发生的是：安全团队的基线评估悄悄纳入了红队的攻击提示词。模型并没有变得更健壮——是评估被污染了。你的基准测试现在衡量的是对已知攻击的免疫力，而非对新攻击的泛化能力。

这就是共享评估基础设施污染问题，它比大多数团队意识到的要普遍得多。症状是指标被人为拉高，根本原因是把评估基础设施当生产基础设施来对待——优化了共享和效率，而非隔离性和保真度。

你的团队上线了一个新的 LLM 功能。单元测试全部通过，CI 是绿色的，你部署了。然后用户开始反馈 AI "就是不好用"——回答格式奇怪，智能体选错了工具，在多步骤任务进行到一半时上下文丢失。你查看测试套件，它仍然是绿色的。每个测试都通过了。但这个功能是坏的。

这不是运气不好，而是当你把确定性测试哲学应用于概率性系统时必然发生的结果。经典测试金字塔——宽泛的单元测试底座、较小的集成测试中间层、狭窄的端到端测试顶端——建立在一个如此根本的假设之上，以至于没有人会把它写下来：代码每次都做同样的事情。LLM 在每个层面都违反了这个假设。建立在其上的测试策略需要从头重建。

一个团队发布了一项由 LLM 驱动的功能。它通过了安全过滤器，通过了准确性评估。但用户开始投诉。六个月后，一名研究人员运行了一项包含 300 万次对比的研究，发现该系统在输入完全相同的情况下，有 85% 的时间选择了与白人相关的名字，而选择与黑人相关的名字仅占 9%。

这不是安全问题。这是一个公平性问题，两者需要完全不同的工程应对方案。安全过滤器防范伤害。公平性检查衡量你的系统是否能为每个人产生同样优质的输出。一个模型可以满足你所有的内容策略，但仍可能诊断出黑人患者的死亡风险高于同样患病的白人患者，或者为女性生成的简历比男性更单薄。这些差异对于拦截脏话的护栏来说是不可见的。

大多数团队从未构建过第二种检查。这篇文章将探讨你为什么要构建它，以及具体如何去做。

我去年合作过的一个团队拥有一套包含 847 个测试用例的评估套件，仪表盘一片绿色，发布节奏从外部看非常有纪律。然而，他们的旗舰摘要功能开始为大约二十分之一的客户支持线程生成言之凿凿的错误摘要。该能力的评估得分在连续六个月里一直保持在 94%。当我们对这套套件进行审计时，发现问题并不在于评估在撒谎。问题在于这些评估已经悄然腐化，测量了错误的东西，惩罚了正确的模型行为，并与它们正在评估的模型共享盲点。这套套件并不是像传统测试那样以一种响亮的方式崩溃，而是像温度计一样坏掉了——无论你把它放在哪里，它都显示室温。

测试异味（Test smells）在传统软件领域已经被研究了二十年。Van Deursen 的目录、xUnit 模式分类以及更近期的工作都记录了那些看起来正常的测试如何能积极地损害代码库——通过编码错误的规范、使重构变得昂贵、以及制造让真正的 bug 隐藏得更深的虚假信心。LLM 评估是一个非常新的领域，以至于同类的文献几乎不存在，但同样的动态已经发生在我交流过的每个 AI 团队中。不同之处在于，LLM 评估异味具有传统测试所不具备的机制：训练数据重叠、随机输出、评委模型反馈循环、能力漂移。你不能只是简单地移植旧的分类体系，你需要一个新的。