你已经构建了评估套件。它通过了。你部署了。用户却立刻抱怨评估没有捕获的回归。
这是生产大语言模型工作中最常见、也最令人沮丧的模式之一。评估套件看起来令人印象深刻，却漏掉了真正重要的回归。它们带来虚假的信心：团队信任评估，发布了损害质量的变更，直到用户暴露问题时才发现。
构建真正能捕获回归的评估比看上去更难。基础部分（数据集、预期输出、评分）很容易；真正的工作在于让它们成为可靠的信号。
本文介绍我们在构建经得住考验的评估方面获得的经验，面向认真对待生产AI质量的团队。
优秀的评估能做什么
对候选变更运行一套优秀的评估后，它应该能让你非常有把握地回答：“这项变更比当前版本更好、更差，还是没有区别？”
具体表现为：
- 捕获回归。 当真实场景中的质量下降时，评估分数也会下降。
- 发现改进。 当质量提高时，分数会反映出来（而不只是在精挑细选的用例上）。
- 在没有变化时保持稳定。 没有实质性变化时，分数保持一致。
- 可用于可信决策。 基于评估分数作出的决策与实际用户结果相关。
每一项都比听起来更难。
数据集问题
评估的质量取决于数据集。大多数失败的评估套件都在这里出了问题。
常见的数据集问题
问题1：精挑细选的简单用例。 数据集是在系统正常运行时构建的，通常由构建系统的工程师亲自完成。他们选择了“看起来合理”的用例，即每种行为的清晰示例。真实生产流量要混乱得多。困难用例、含糊用例和边缘用例是故障的主要来源，却在数据集中代表不足。
问题2：数据集陈旧。 数据集是六个月前构建的。此后用户行为发生了变化，新的功能领域已经开放，新的产品能力已经发布。数据集测试的是过去的世界。
问题3：没有覆盖容易回归的领域。 评估全面覆盖了“理想路径”，却没有探测真正发生回归的边界。
问题4：数据集污染。 评估使用的示例也出现在提示或微调数据中。模型“记住”了它们。测试分数被夸大，实际性能却更差。
问题5：分布不均衡。 数据集中80%是同一种输入，长尾只占5%。长尾中的回归几乎不会改变分数，尽管它确实是真实回归。
构建强大的数据集
以下原则有助于构建强大的数据集：
取材于真实生产流量。 最好的示例是真实用户输入（需移除个人身份信息）。它们包含系统真正需要应对的复杂情况。
实用工作流如下：
- 对生产调用进行抽样（采用适当的隐私控制）。
- 人工标注预期输出（或先由大语言模型标注，再由人工验证）。
- 将用例加入评估数据集。
- 定期刷新数据集（每月一次是很好的节奏）。
纳入多种故障模式。 特别加入过去在生产环境中失败的用例。这些用例会成为回归测试：修复缺陷后加入失败用例，确保它不再复发。
对数据集分层。 按难度（简单/中等/困难）、主题、用户类型和长度对用例分类。确保每个类别都有足够覆盖。按类别跟踪分数，不要只看总体分数。
混合不同难度。 包含一些简单用例（以便发现灾难性回归）、一些中等用例（真实流量的主体），以及一些困难用例（边缘情况）。只有困难用例的数据集会因微小变更而剧烈波动；只有简单用例的数据集面对真实回归则毫无变化。
采用适当规模。 规模太小，统计噪声就很大；规模太大，运行又会变慢且昂贵。典型规模：
- 分类：200–500个用例。
- 生成：50–200个用例。
- 复杂代理流程：20–50个用例。
你完全可以从较小规模开始，再逐步扩展。
严格执行刷新。 安排每月审查数据集。加入新的故障模式，淘汰陈旧用例。如果预期行为发生变化，就更新预期输出。
指标问题
衡量什么，就会优化什么。选择错误的指标是第二常见的评估失败原因。
常见的指标问题
问题1：单一汇总数字掩盖问题。 总体准确率达到90%，可能掩盖某个重要类别从95%降至70%、其他类别却有所改善的事实。平均值看起来仍然正常。
修复：始终按类别细分。
问题2：指标衡量了错误的东西。 客户支持响应的“正确性”指标可能看不出响应虽然正确，语气却很无礼。指标没有捕获语气。
修复：采用多维评分。分别衡量正确性、语气、长度和格式。
问题3：对严重程度不敏感。 无论是无关紧要的小错，还是危险的幻觉，错误答案都得到相同处理。
修复：加权评分。严重错误权重更高。有些错误计为0（安全违规）；有些计为 -1（灾难性故障，比没有回答更糟）。
问题4：两极化敏感度。 分数要么从100%变为99%（几乎无法察觉），要么从100%变为50%（灾难性变化），无法显示细微回归。
修复：采用分级评分。每个输出按连续量表（1–5或0–1）评分，而不是二元评分。
问题5：跨群体聚合。 对所有用户求平均，会掩盖某个占比10%的子群体性能暴跌。
修复：按相关切片（用户等级、查询类型、语言区域）进行维度细分。
构建强大的指标
多维度。 每个输出获得多个分数：正确性、语气、格式、安全性、长度，以及其他重要维度。
加权。 某些维度比其他维度更重要。在任何综合指标中都应对它们加权。
校准严重程度。 在同一维度内区分轻微和重大错误。事实错误的响应比略有偏差的响应更糟。
按类别衡量。 按相关切片报告分数，例如简单/中等/困难、各个主题、各类用户。
跟踪长期趋势。 单个分数没有太大用处，趋势才有用。绘制分数随时间变化的图表，检测漂移。
与用户一致。 指标应该与用户真正关心的内容相关。如果用户抱怨语气无礼，就衡量无礼程度；如果用户抱怨篇幅，就衡量篇幅。
评判模型问题
使用LLM-as-judge（由一个大语言模型为另一个大语言模型的输出评分）时，评判模型就是评分者。如果评判模型有偏见或判断错误，评估就毫无用处。
常见的评判模型问题
问题1：长度偏差。 大语言模型评判者倾向于偏爱较长的响应。即使响应冗长臃肿，它们仍会给更长的响应更高分。
问题2：格式偏差。 无论哪种形式更适合任务，评判模型都会偏爱结构化输出（项目符号、标题）而不是散文。
问题3：自我偏好。 如果评判模型与被评模型来自同一模型系列，它会给同系列输出更高分。
问题4：迎合。 评判模型会顺从给定的框架。告诉它“旧版本很差，请给新版本评分”，会夸大新版本的分数。
问题5：缺乏依据。 评判模型凭印象评分，而不是依据具体标准。同一提示在不同运行中得到不同分数。
构建强大的评判模型
以人工评分校准。 抽取一部分评判模型的评分，让人工重新评分。出现分歧时，改进评判提示，或接受该维度需要人工评判。
使用不同的评判模型。 如果可能，使用与被评系统不同模型系列的评判模型，以降低自我偏好。
明确说明标准。 评判提示应通过示例准确说明好与坏的表现。模糊标准只会产生模糊评分。
避免诱导性表述。 不要告诉评判模型“请按大多数输出都很好的量表评分”。应以具体行为作为锚点。
使用带锚点的评分细则。 根据定义清晰、每个等级都有示例的细则进行评分。“5分：事实准确、具体、结构清晰。4分：大体准确，可能缺少一个细节。3分：……”有锚点时，评判模型会保持一致；没有锚点时，它会发生漂移。
强制结构化输出。 评判模型生成结构化分数（按维度评分并说明理由），而不是自由文本。这样更容易聚合和审计。
一份优秀的评判提示如下：
你正在评估AI助手的响应。
用户查询：{query}
助手响应：{response}
请按1-5分对以下维度评分：
1. 事实准确性：所有主张是否正确？（5 = 全部正确，4 = 大体正确但有轻微问题，3 = 有一些错误，2 = 有许多错误，1 = 大部分错误）
2. 相关性：响应是否回答了用户的实际问题？（5 = 完全回答，1 = 没有回答）
3. 完整性：响应是否包含足够信息？（5 = 完整，1 = 严重不完整）
4. 语气：响应是否具有适当的专业性？（5 = 语气非常恰当，1 = 不恰当）
请为每项分数提供：
- 分数
- 一句话说明具体原因
- 响应中支持该分数的具体文本
输出JSON：{"accuracy": {"score": N, "reason": "...", "evidence": "..."}, ...}
使用校准集（人工评分示例）运行该评判模型。不断调整，直到其评分与人工评分的差异处于可接受范围内。
为生产环境设计评估套件
以下几种模式在生产环境中效果很好：
套件1：回归套件
一组明确的测试用例（200–500个），系统在任何一次部署前都必须通过。它们来自真实故障、边缘情况和已知良好模式，并且不会经常变化。
这是你的“绝不能破坏”套件。CI集成方式：每个PR都运行它；出现回归时阻止合并。
套件2：冒烟测试
一个较小的子集（10–30个用例），频繁运行。在开发期间提供快速反馈，立即捕获灾难性回归。
集成方式：使用pre-commit钩子，或在主要评估前运行快速冒烟测试。
套件3：探索套件
规模更大、更多样的数据集（数千个用例），从真实生产流量中抽样。运行频率较低（每周一次？），用于寻找较小套件可能遗漏的模式。
集成方式：定时任务。在每周质量会议中审查结果。
套件4：在线套件
对真实生产流量进行抽样，使用自动方式（大语言模型评判者）或用户信号评分。捕获离线评估遗漏的漂移。
集成方式：持续运行，使用仪表板。
套件5：用户流程套件
测试完整用户流程的端到端测试，而不只是单次大语言模型调用。适用于代理系统和多步骤工作流。
集成方式：重大变更部署前运行。
成熟的生产系统五种套件兼备。先从回归套件开始，再随着能力增长逐步添加其他套件。
成本和时间纪律
评估既耗费资金（大语言模型调用），也耗费时间（运行和审查）。
一套包含500个用例、使用旗舰评判模型的评估，每次运行可能花费€5–20。若每个PR都运行（每天10次），每天就要花费€50–200。虽然可以承受，但不可忽视。
策略包括：
在PR中运行冒烟测试，合并时运行完整套件。 避免在不会合并的PR上浪费成本。
缓存结果。 如果提示和模型都没有变化，就无需重新运行。按 (prompt_version, model, dataset_version) 缓存。
尽可能使用更便宜的评判模型。 经过良好校准的低成本评判模型通常可以接受。
并行运行。 评估运行极易并行化。请使用并发。
抽样而不是完整运行。 例行检查时，从包含500个用例的数据集中抽取50个。重要变更才完整运行。
时间预算通常取决于“一个PR可以等待多久？”完整评估应争取在15分钟内完成。超过这一时长，开发者就会切换上下文，损失生产力。
运维模式
以下实践能够区分成熟的评估项目：
模式1：以评估作为部署门禁
影响大语言模型的变更在生产部署前必须通过评估。分数回归并低于阈值？阻止部署，由工程师调查。
阈值通常是相对值，例如“分数与基线的差异必须在2%以内”。这样既容许噪声，又能捕获实质性回归。
模式2：分数变化时进行调查
任何有意义的分数变化（无论升降）都应调查。分数提高了？为什么？是我们确实改进了，还是测试变简单了？分数降低了？具体在哪里？回归是否仅限于某个切片？
不要因汇总分数变化而立即庆祝或恐慌；先调查。
模式3：持续维护数据集
数据集不是一次性构建的，而应持续维护。流程如下：
- 用户投诉某个响应 → 将其作为回归测试加入数据集。
- 新功能发布 → 添加覆盖该功能的用例。
- 模型行为出乎某人预料 → 如果确实是故障，就加入数据集。
- 陈旧用例（不再相关）→ 淘汰。
每月一次的审查会议效果很好。将数据集视为不断演进的资产。
模式4：基于差异的审查
审查评估结果时，重点关注与基线的差异：
- 新版本分数高于基线的用例（改进）。
- 新版本分数低于基线的用例（回归）。
- 分数保持不变的用例（没有信号）。
差异才是信号。按顺序审查500个用例并不现实；审查30项差异则完全可行。
模式5：人工审核评判分歧
定期（每周？）抽取评判模型给出低分和高分的用例。由人工审核：你是否同意评判模型？
分歧会揭示：
- 评判模型偏差（校准评判提示）。
- 真实质量问题（修复系统）。
- 数据集问题（用例的预期输出有误）。
这就是长期保持评判质量的方法。
模式6：季度评估审查
每季度对评估项目本身进行一次回顾：
- 本季度评估套件捕获了哪些真实回归？
- 漏掉了哪些真实回归？
- 产生了哪些误报？
- 我们已知哪些覆盖缺口？
- 数据集对当前生产行为的覆盖情况如何？
这是元评估：评估“评估”本身。没有它，评估项目就会退化。
完整示例：客户支持评估
为了具体说明，下面是一套面向AI客户支持响应系统的生产级评估配置。
目标： 确保AI对客户查询的响应准确、有帮助、符合品牌调性且安全。
数据集：
-
回归套件（300个用例）：
- 50个简单用例（政策明确、答案简单）。
- 100个中等用例（典型复杂度）。
- 100个困难用例（含糊、敏感、多部分）。
- 50个已知故障用例（过去发生回归的场景）。
-
探索套件（1000个用例）： 每月从真实生产流量中抽样，并清除个人身份信息。
-
对抗套件（50个用例）： 专门设计的提示，试图提取信息、为不符合资格的情况获取退款、操纵AI。
指标：
对每个用例，评判模型在以下维度评分：
- 事实准确性（1–5）
- 政策合规性（1–5）
- 语气恰当程度（1–5）
- 完整性（1–5）
- 长度恰当程度（1–5）
- 安全性（二元：通过/失败）
评判模型：
- 主要评判模型：Claude（与被测系统使用不同的提供商；被测系统使用GPT——选择不同提供商可避免同模型自我偏好）。
- 使用100个参考用例，对照人工审核者进行校准。
- 每季度重新校准。
聚合：
- 各切片中每个维度的平均分（切片：工单类型、客户等级、语言）。
- 安全通过率（必须达到100%）。
- 每个用例的加权分数（用于比较差异）。
运维：
- 每个PR运行冒烟测试（30个用例）。
- PR合并时运行完整回归套件（300个用例）。
- 每周运行探索套件（1000个用例）。
- 任何提示或模型变更前运行对抗套件（50个用例）。
- 对1%的生产流量进行在线抽样并实时评判。
审查：
- 月度会议：审查评估趋势、新故障模式和数据集更新。
- 季度会议：元评估、评判模型校准和数据集审计。
结果（来自类似系统的真实部署）：
- 每月捕获约3项本会在没有评估的情况下发布的回归。
- 每月约有1次误报（评估标记了回归，但实际没有问题）。
- 在数天内检测到漂移，而不是数周或数月。
- 团队对发布提示和模型变更更有信心。
这就是生产级评估的样貌。它不是一个周末就能完成的小项目，而是一项能够带来真实投资回报的持续投入。
常见陷阱
我们反复看到以下几种模式：
陷阱1：产品发布后才构建评估。 “以后再添加评估。”这个“以后”永远不会到来。请从第一天开始构建。
陷阱2：由单一工程师负责。 一个人构建评估，其他人都不维护。此人离开后，评估就会腐化。应分散责任。
陷阱3：将评估视为静态内容。 构建一次，此后再不更新。随着产品演进，它会变得毫无用处。将评估视为不断演进的资产。
陷阱4：盲目信任评估分数。 评估说它更好，所以直接发布。如果不进行人工抽查，你会发布评估给出高分、用户却讨厌的内容。重要变更应将评估与人工审核结合起来。
陷阱5：针对评估优化。 专门为了在评估中取得高分而调整提示。评估分数提高了，现实表现却没有改善。务必警惕：如果评估改进没有与生产改进相匹配，你就是在针对测试进行优化。
陷阱6：忽略基础设施成本。 大规模评估很昂贵（大语言模型调用积少成多）。如果不跟踪成本，月底才会发现问题。
陷阱7：没有明确的通过/失败标准。 “分数从4.2降到4.0——这算回归吗？”应预先定义阈值并坚持执行。
陷阱8：评估套件占用了大部分测试精力。 在缺少基本正确性测试的情况下构建复杂评估。评估用于检测质量漂移，并非所有测试都是评估。
文化因素
生产评估最难的部分在于文化。工程师和产品人员需要：
- 充分信任评估，以便将其作为部署门禁。 否则评估只是形式主义。
- 又不能完全信任评估，要调查分数变化。 盲目信任会导致针对测试进行优化。
- 将数据集维护作为持续工作进行投入。 它不是一次性项目。
- 接受评估无法取代人类判断。 评估只是缩小需要人工审核的范围。
- 能够识别评估套件何时失效。 如果真实回归漏网，问题出在评估套件，而不是提出投诉的用户。
具备这种文化的团队发布速度更快、可靠性更高。缺乏这种文化的团队最终要么过度依赖有缺陷的评估，要么因没有评估而停滞不前。
核心结论
构建真正能捕获回归的评估比看上去更难，但完全可行。
关键在于：
- 源自真实生产情况的真实、多样数据集。
- 符合用户体验的多维、切片感知指标。
- 真正与人工判断对照检查过的校准评判模型。
- 面向不同关注点的多种评估套件（回归、冒烟、探索、在线、端到端）。
- 运维纪律：以评估作为部署门禁、持续维护数据集、调查分数变化。
- 长期使用并改进评估的文化承诺。
如果做得好，评估会成为AI架构中最有价值的基础设施。它们让你既能快速发布，又能保持质量。没有评估，就如同盲目飞行。
构建评估。信任评估。改进评估。这就是持续保障生产AI质量的方法。
