LLM 评估：什么才真正有效，什么是在浪费时间

Wait, I should double-check the truncate tag and headers.

大多数构建 LLM 应用的团队都会陷入两种失败模式之一。第一种是完全不建立评估（Evals），凭感觉发布功能。第二种是在还没搞清楚到底要衡量什么之前，就构建了复杂的评估基础设施。这两种都是代价高昂的错误。

表现优秀的团队有一个共同点：他们从观察数据开始，而不是从构建系统开始。错误分析优先于自动化评估。在信任任何自动评判器之前，先用人工判断为指标奠定基础。他们不把评估看作是一个需要跨越的里程碑，而是一个随着产品共同演进的持续准则。

这就是 Evals 在实践中的真实样貌——那些至关重要的决策、浪费精力的模式，以及在你被“坑”过之前都不明显的权衡。

错误分析优先于评估基础设施

LLM 开发中最常见的不匹配是在你还不知道失败长什么样之前就构建评估器。早期编写 Evals 听起来很符合方法论——就像 AI 系统的测试驱动开发（TDD）。但在实践中，LLM 具有近乎无限的失败面。你无法提前列举出提示词-响应系统中可能出现的所有问题。

正确的顺序是：

1. 从预发布环境收集 100 多个真实用户交互或追踪记录（Traces）
2. 让领域专家阅读这些记录，并就失败情况编写开放式笔记（开放式编码）
3. 将类似的失败归类（轴心编码）
4. 迭代直到分类体系稳定
5. 然后针对你发现的失败类别编写评估器

这种方法产生的评估器能衡量应用中的真实问题。抽象的质量框架产生的数字看起来很健康，却掩盖了用户遇到的具体失败模式。

错误分析中的一个重要规则：关注每个追踪记录中的 第一个 上游失败。多步系统中的下游错误往往是由单一根因级联引发的。解决根因，几个下游问题就会自动消失，而无需专门的评估器。

一个实际的影响是：将 60-80% 的 AI 开发时间预算花在错误分析和评估上，而不是模型选择或基础设施上。大多数团队在这方面投入不足，导致他们无法解释为什么尽管指标看起来不错，但产品感觉就是不对劲。

基准测试分数陷阱

顶尖模型现在在 HumanEval 和 GSM8K 上的得分已经超过 90%。这些基准测试已经饱和，在很大程度上已不再对模型选择决策有参考价值。一个在任何公开排行榜上名列前茅的模型，在你的应用生成的特定输入上仍可能出现系统性失败。

原因在于数据污染。在海量网络语料库上训练的模型在训练期间通常见过测试题。静态问题集显著放大了泄露风险——分数反映的是记忆力而非能力。一些组织现在每月更新基准测试数据点，专门为了应对这一问题。

更深层的问题是基准测试的表现无法迁移。生产环境的输入比精心策划的评估集更混乱、更具上下文且更多样化。一个在烹饪知识基准测试中获得高分的食谱助手，在成分解析、热量估算或处理成分替代时仍可能失败——而这些组成部分没有一个是被基准测试直接针对的。

解决方法是基于真实追踪记录构建特定领域的评估。像 BLEU、ROUGE 或 BERTScore 这样的通用指标衡量的是抽象属性，对特定应用没有诊断价值。它们作为探索信号，为人工审查提取有趣的追踪记录是有用的，但作为生产决策的质量指标则毫无用处。

二元通过/失败优于李克特量表

评估研究中的一个一致发现是：1-5 分的评分量表产生的评估效果不如二元通过/失败判断。

失败模式是可以预见的。评估者为了避免做出艰难决策，会默认选择中间值（3/5）。这压缩了方差，掩盖了真实的质量差异，并且需要更大的样本量才能提取出信号。二元判断迫使评估者表态：这个输出是否达到标准？

二元评估速度更快，评估者之间的一致性更高，并且达到统计学显著性所需的样本量更小。它们还使质量标准更加具体。1-5 分量表需要定义五个可区分的质量等级。而通过/失败判断只需要定义一个阈值——这是一个更难但更有价值的练习。

如果你发现自己正在为评估设计李克特量表，这通常意味着质量标准尚未定义清楚。二元判断能更早地暴露出模糊性。

一个推论：目标通过率应设在 70% 左右，而不是 100%。100% 的通过率表明你的 Evals 测试强度不够。具有清晰失败类别的 70% 通过率意味着你构建的评估器真正具有区分度。

LLM-as-Judge 何时奏效，何时失败

LLM-as-judge 已成为将评估扩展到生产流量的主流方法，因为在这种情况下，人工审核在数学上是不可能的。它非常适合解决特定类别的问题。

将 LLM-as-judge 用于：

• 可以在提示词（Prompt）中精确落地的明确定义标准
• 不存在“正确答案”的无参考生产环境监控（如聊天机器人、支持代理）
• RAG 忠实度（Faithfulness）和答案相关性检查
• 开发过程中用于模型或提示词选择的两两比较 (Pairwise comparison)

研究表明，如果实现得当，LLM 裁判在两两比较中与人类评估者的一致性可以达到 80% 以上。对于开发决策来说，这是一个合理的信号。

避免将 LLM-as-judge 用于：

• 实时防护栏 (Guardrails) —— API 延迟过高；请改用规则或向量嵌入（Embeddings）
• 需要在生成过程中立即进行验证的任务
• 缺乏已标注验证数据的专家领域高风险决策

最大的差距存在于专业领域。在营养学、心理健康和医疗背景下，LLM 裁判与人类领域专家的一致性仅为 60-70%。对于创意写作，一致性会降至 58% 左右。这些任务需要人工审核；在这种情况下，LLM 裁判提供的是噪音而非信号。

如果不加以修正，几种系统性偏见会进一步削弱 LLM 裁判的效果：

• 位置偏见 (Position bias)：在两两比较中倾向于选择先出现的响应。可以通过随机化顺序并对两种顺序的结果取平均值来缓解。
• 冗长偏见 (Verbosity bias)：无论质量如何，都倾向于更长的响应。
• 自我提升偏见 (Self-enhancement bias)：倾向于来自同系列模型的输出，这一点在 NeurIPS 2024 上得到了证实。

一个关键的操作要求：在信任 LLM 裁判进行生产决策之前，请先针对 50-200 个已标注示例对其进行验证。一个未经校准的裁判比没有裁判更糟糕 —— 它会提供自信但不可靠的评分，从而掩盖真实问题。

在构建之前考虑评估成本

LLM-as-judge 并非免费。它需要 100 多个标注示例进行验证，随着模型版本的变化需要定期重新校准，并且需要跨职能协作来维护。为一个你只会看一次的问题构建自动化评估器是浪费的。

实际的过滤标准是：仅针对你会反复迭代的持久性故障类别构建 LLM-as-judge 评估器。一次性检查最好通过直接的人工审核来完成。基于规则的检查（格式验证、关键字存在、长度限制）对于确定性需求更便宜且更可靠 —— 请优先使用它们。

这引出了一个有用的二级分类法：

1. 确定性检查：精确匹配、正则表达式、Schema 验证 —— 这些功能类似于单元测试，应该在每次推理时运行。
2. 统计评估：LLM 裁判、人工审核小组 —— 这些是定期抽样和监控的。

将这些混合在单个评估流水线中会造成混乱。请将它们分开并进行不同的跟踪。

大多数流水线都适用“五项指标上限”原则：在任何单个流水线中超过五项指标都会削弱信号。使用一两个自定义指标来满足特定用例的需求，使用两三个通用指标来关注架构层面的问题。更多的指标并不会增加覆盖范围 —— 它们只会增加噪音。

评估智能体（Agent）有所不同

单轮评估侧重于“提示词-响应”对。而智能体评估需要评估整个轨迹 (Trajectories) —— 工具调用、状态转换、中间决策，以及可能跨越数十个步骤的多步推理。

智能体特有的失败模式不会出现在响应质量评分中：

• 工具幻觉：调用不存在的工具或使用错误的参数。
• 长轨迹中的上下文丢失。
• 多智能体振荡：责任在智能体之间来回传递而无法解决。
• 记忆投毒：导致长期的行为偏移。
• 级联故障：单个错误的工具调用触发下游的一系列错误。

对于智能体来说，两种类型的指标都是必要的：结果指标（最终结果是否正确且完整？）和过程指标（智能体达成该结果的效率如何 —— 步数、Token 使用量、工具调用准确性、耗时？）。仅有结果指标会忽略系统性的低效率。仅有过程指标会忽略正确性方面的失败。

一种有用的诊断技术是“转换失败矩阵”：对于每个追踪（Trace），记录最后一个成功的状态和第一个失败点。在许多追踪中累积这些数据，以识别系统性的失败热点。早期阶段的失败具有更大的级联影响，值得优先关注。

在生产部署前建立基准智能体指标的团队，检测质量倒退的速度比没有基准的团队快大约三倍。根据亚马逊报告的研究结果，在生产环境的智能体系统中，混合自动化加人工评估产生的系统质量比纯自动化方法高出约 40%。

评估永无止境

一个常见的错误是将评估视为一次性的里程碑：构建评估套件，获得通过分数，然后发布。这会失败，因为你评估的系统并不是一成不变的。

模型提供商会更新基础模型。用户行为会随时间发生变化。随着你的产品覆盖新的用户群体，输入分布也会改变。“标准漂移 (Criteria drift)” —— 即对你的应用而言“好”的定义在逐渐演变 —— 是预期内且正常的。六个月前校准良好的评估套件在今天衡量的可能是过时的质量标准。

在操作层面的启示是，评估是一种持续的实践，而不是一个关卡：

• 随着生产环境中出现新的失败模式，更新评估数据集。
• 当底层模型发生变化时，重新校准 LLM 裁判。
• 定期审查人工标注的示例以捕获标准漂移。
• 将评估标准 (Rubrics) 视为动态文档，在 Git 中与提示词一起进行版本控制。

将提示词和评估标准存储在版本控制中 —— 像对待软件制品一样进行评审、记录历史和部署 —— 是构建在 LLM 之上的团队可以采用的最高杠杆的流程改进之一。它创建了一个可追溯的记录，展示了任何时间点所采用的质量标准，这使得调试功能倒退变得快得多。

组织现实

评估（Evals）本身无法证明其自身的价值。利益相关者希望看到具体的失败模式得到修复，而不是方法论的描述。获得评估认同最有效的路径是结果导向：展示通过错误分析（error analysis）发现的具体 Bug，演示在高频失败类别上的改进，并记录从追踪审查（trace review）中发现的令人惊讶的用户模式。

任命一位领域专家作为最终的质量决策者。由委员会进行标注会导致标签不一致，且难以达成共识。一个人经过校准的判断比五个人的平均意见更有价值。如果一个人的判断不足以确定质量，这通常是一个信号，表明产品范围过大——而不是你需要更多的标注人员。

在投入评估基础设施之前，先构建自定义标注工具。拥有专为特定目的构建的标注界面的团队，其迭代速度大约是使用通用平台的团队的 10 倍。界面决定了标注者如何思考质量；一个设计良好的工具会将评估标准直接嵌入到评审工作流中。

总结

在表现优秀的评估团队中通用的原则：

• 在编写任何评估器（evaluators）之前，先从真实追踪的错误分析开始
• 在几乎所有维度上，二进制的通过/失败（pass/fail）判断都优于评分量表
• 使用带标签的示例验证 LLM 裁判（LLM judges）；不要相信未校准的裁判
• 将确定性检查（deterministic checks）和统计性评估（statistical evals）分层处理
• Agent 需要轨迹级（trajectory-level）评估——仅靠响应质量分数会遗漏 Agent 特有的失败模式
• 将评估视为一项持续的准则，而不是一次性的关卡
• 通用指标会营造一种虚假的健康感；而基于真实失败案例构建的领域特定评估则能提供可落地的信号

那些从评估中获得真正价值的团队，是将评估视为一种将关于质量的隐性知识显性化的方式——而不是将其视为一个勾选框或优化目标。