生产级 LLM 系统的评估工程

大多数构建 LLM 系统的团队都从错误的问题开始。他们在了解系统到底哪里会出错之前，就先问“我该如何评测这个系统？”。然后，他们花几周时间构建评测基础设施，却测量了错误的东西，迅速达到了 90% 以上的通过率，最后发布了用户讨厌的产品。评测本身并没有错——它们只是没有在测量失败。

有效的评测工程（Eval Engineering）主要并不在于基础设施，而在于对你的特定系统而言，“好”究竟意味着什么，并建立精确且共识的理解。基础设施几乎是次要的。在成熟的 LLM 团队中，60–80% 的开发时间都花在错误分析和评测上，而不是功能开发。这个比例会让大多数工程师感到惊讶，直到他们将一个有缺陷的模型推向生产环境，并花了一周时间去调试到底是哪里出了问题。

错误分析循环优先

在编写任何评测器之前，你需要观察你的系统是如何失败的。顺序至关重要：错误分析始终优于自动化。

行之有效的四步流程如下：首先，收集 100 个以上来自生产环境的代表性 Trace——即真实的用户交互，而不是你为了测试“正常路径”（Happy Path）而构建的合成示例。其次，让领域专家审查这些 Trace，并记录关于出错原因的非结构化笔记。先不要分类，仅仅是观察。第三，将观察结果归纳为失败分类体系（Failure Taxonomy）并统计发生次数。这会告诉你该优先处理什么——如果 40% 的失败是幻觉，而 5% 是语气问题，那么你的评测基础设施就应该反映出这个比例。第四，持续这个过程，直到你不再看到新的失败模式，这时你就可以开始自动化了。

每 2–4 周运行一次此循环进行重大分析，每周进行一次较轻量（10–20 个 Trace）的审查，重点关注离群值。这种节奏能让你的评测器与系统在现实世界中的实际失败方式保持一致，而不是你在设计时想象的失败方式。

团队结构也同样重要。任命一位拥有最终质量判断权的领域专家。多个标注员会导致“标注瘫痪”——即针对某个回答在李克特量表上该打 3 分还是 4 分展开无休止的争论。一个拥有明确权限的人可以消除这种摩擦。并且，不要将错误分析外包给外部团队。他们缺乏那些只有在你的特定领域中才能区分 3 分和 4 分的隐含产品背景。

评测栈：成本层级

一旦你理解了失败模式，就按照从最便宜到最昂贵的顺序构建你的评测栈。在成本允许范围内，尽可能多地使用每一层。

简单的断言（Assertions）和正则表达式（Regex） 是你最便宜且最可靠的工具。回答中是否包含不该出现的电话号码？它是否以问候语开头？JSON 是否可解析？毫不犹豫地在 CI/CD 的每次请求中运行这些检查。它们是确定性的、快速的，并且绝不会因为提示词敏感性而产生误报。

Schema 验证器和格式检查 位于上一层——依然是确定性的，依然便宜，用于验证结构化输出是否确实符合预期结构。这些工具能捕捉到惊人比例的生产环境问题。

基于参考的检查（Reference-based checks） 需要一个已知的正确回答进行对比。它们适用于存在基准真值（Ground Truth）的窄领域，但无法扩展到开放式生成任务。

微调后的评委模型（Fine-tuned judge models） 能以极低的成本提供 LLM-as-judge 的大部分价值。一个根据你标注的示例进行微调的 7B 分类器可以在每次提交的 CI/CD 流水中运行，而在这种场景下，使用 GPT-4 级别的推理成本将高得令人望而却步。

使用前沿模型（Frontier Models）的 LLM-as-judge 是最昂贵的评测方案。它能提供最细致的评估（如准确性、完整性和语气），但应留给生产监控、重大版本评估和 LLM 评委训练使用，而不是针对每次代码提交。

二元标签永远胜出

评测工程中被最一致验证的发现是：在几乎所有的评测场景中，二元“通过/失败”（Pass/Fail）标签的表现都优于李克特量表（1–5 分）。

原因在你亲自尝试两者之前可能并不显而易见。数字量表会在标注员之间引入主观理解差异。3 分和 4 分之间的区别本质上是模糊的——一个标注员认为的“基本没问题，有小瑕疵”，在另一个标注员眼中可能是“尚可接受但不够好”。人类在 5 分制量表上的评分者间信度（Inter-rater reliability）通常在 Cohen's Kappa 0.2–0.3 之间，这几乎不比随机概率好多少。而同一任务的二元标签通常能达到 0.6–0.8。

二元标签还强制要求概念清晰。为了标注通过或失败，你必须决定：到底什么才是重要的？对这个问题的具体回答，将成为你的系统真正需要满足的技术规范（Specification）。跳过这一步的团队往往在优化错误的东西。

在构建 LLM 评委时，目标是与你的领域专家达成 90% 以上的一致性。分别测量精确率（Precision）和召回率（Recall），而不是单纯看准确率，尤其是在数据集不平衡时。一个能正确识别 95% 的通过、却漏掉了 40% 的失败的评委是毫无用处的。

构建真正有效的 LLM 裁判

LLM 作为裁判 (LLM-as-judge) 在大规模评估主观特质方面确实非常有用——例如正确性、完整性、语气得体性——这些是确定性检查无法捕捉到的。但要构建一个能与专家判断保持一致的裁判，需要一套特定的方法论。

影子评论 (Critique shadowing) 法的工作流程如下。你的领域专家审查 50–100 个案例，并写下详细的书面评论，解释每个案例通过或失败的原因。简短的笔记（如“这是错的”）是不够的——评论需要捕捉推理过程。这些将成为你裁判的 few-shot 示例。

迭代地构建裁判，从 5–10 个评论示例开始。在你的标记数据集上运行它。检查每一个不一致的地方，更新示例，然后重复。通常在三次迭代内，你就能与领域专家达到 >90% 的一致性。

为每个标准构建独立的裁判，而不是一个一次性对所有内容进行评分的“全能评估器”。细粒度的裁判更容易调试，当某个标准发生变化时更容易更新，并且在失败时能产生更具操作性的信号。

LLM 裁判存在一些已知的偏差，你需要考虑到这些。位置偏差 (Position bias)：裁判倾向于根据回复在提示词中的位置来偏向它。冗长偏差 (Verbosity bias)：较长的回复无论质量如何都会获得更高的评分。从众偏差 (Bandwagon bias)：裁判会同意已陈述的共识。通过交换位置运行两次评估来缓解位置偏差。通过在评分标准中加入关于长度适当性的明确语言来减少冗长偏差。让你的裁判解释其评分——这一改变通过强制模型进行推理而非模式匹配，显著提高了对齐度。

即使是前沿模型裁判也有天花板。与人类判断相比，顶级模型的“两者皆准”准确率 (both-correct accuracy) 通常低于 0.7。这并不是回避 LLM 裁判的理由——人类标注者由于疲劳会漏掉约 50% 的缺陷——但这确实是一个理由，要将自动评估分数视为信号而非绝对真理 (ground truth)。

防护栏不等同于评估器

一个经常被混淆的关键架构区别是：防护栏 (Guardrails) 同步运行并拦截回复；评估器 (Evaluators) 异步运行并为仪表板提供数据。

防护栏是内联检查——PII 检测、亵渎过滤器、JSON Schema 验证、提示词注入检测。它们必须在毫秒内运行，因为它们处于面向用户的回复的关键路径上。误报就是生产环境的 Bug。在这里，应优先选择廉价的、确定性的规则，而不是 LLM 推理。

评估器是事后的。它们从不拦截回复。它们对生产流量进行采样，运行昂贵的质量检查，并向监控仪表板提供数据。一个运行需要 5 秒的评估器不是问题。一个将 20% 的优质回复标记为失败的评估器不是生产事故——而是一个调查信号。

混淆这两个抽象会导致最坏的结果：要么在关键路径中进行 LLM 推理（增加 2 秒以上的延迟），要么用简单的防护栏取代异步评估器，从而漏掉你真正关心的失败案例。

CI/CD 集成与生产监控

在实践中有效的两层评估架构，将开发阶段的回归测试与生产监控分开。

CI/CD 流水线在每次提交时运行。它使用一个精心挑选的数据集，包含 100–200 个示例，涵盖核心功能、已知的回归案例以及过去失败中的边缘案例。确定性断言和较小的微调模型裁判在这里承担重任。流水线是部署的门控——失败会拦截发布。只有在夜间扫描或发布候选版本 (Release Candidates) 时，才使用前沿模型运行 LLM 裁判，此时延迟不是限制因素。

生产监控异步采样实时流量。你不需要评估每一个请求——10–20% 的采样足以检测聚合指标中的回归。需要持续跟踪的关键指标：忠实度 (Faithfulness)（针对 RAG 系统）、任务完成率（针对智能体）、以及面向用户的质量信号。跟踪置信区间而不是点估计值；只有当置信下限跨越阈值时才进行调查。

你的评估成熟度决定了你拥有其中的哪些环节。大多数交付 LLM 功能的团队处于 Level 1：一些离线评估，人工审查。Level 2 增加了带有回归测试套件的 CI/CD 集成。Level 3 增加了持续的生产采样。Level 4——最可靠的团队所在的级别——在生产流量上运行持续评估，并配备自动红队测试，以便在用户发现之前发现新的失败模式。

智能体评估需要不同的思维方式

评估智能体 (Agents) 引入了一个在单轮生成中不存在的结构性复杂问题：你需要评估轨迹 (Trajectories)，而不仅仅是最终输出。

有三种评分器类型适用。基于代码的评分器处理客观、可验证的结果：智能体是否编写了有效的 JSON？它是否调用了正确的 API？最终的数据库状态是否符合规范？这些方式快速、廉价，应在求助于基于模型的评分器之前穷尽使用。使用评分标准进行打分的基于模型的评分器处理需要判断的结果——研究摘要是否准确？是否参考了正确的来源？人工审查仍然是金标准，但无法扩展到偶尔的抽检之外。

智能体评估中最常见的错误是针对路径评分，而不是针对结果。如果智能体通过非传统的工具调用序列实现了正确的最终状态，那也应被视为成功。将评估器锁定在特定的执行路径上，意味着每次进行有效的架构更改时，你都会面临评估倒退。

根据你的用例，有两个指标的重要性各不相同。pass@k 衡量在 k 次尝试中至少有一个正确解的概率——当一次成功就足够时，这是正确的指标。pass^k 衡量所有 k 次尝试都成功的概率——当你需要可靠性时，这是正确的指标。在 k=10 时，这两者会发生巨大的分歧：对于能力强的模型，pass@k 通常接近 100%，而 pass^k 可能接近 0%。你优化哪一个指标，将决定你的整个训练和评估策略。

谨慎处理非确定性：对每次尝试使用隔离环境，运行之间不共享状态。一个提取 Bug 曾使一个已发布的基准测试从 50% 提升到 73%——在将变化归因于模型质量之前，先验证你的数据流水线。

导致评估项目失败的陷阱

十二个值得明确指出的失败模式：

评估驱动开发 (Eval-driven development)：在查看真实数据之前，就为想象中的失败构建评估器。LLM 的失败往往是违背直觉的——只为你观察到的失败编写评估器。

通用指标：“有用性”、“连贯性”和“相关性”评分会产生虚假的安全感。在实践中，它们与用户满意度并不相关；它们衡量的是容易衡量的东西，而不是重要的东西。

相似度指标：BERTScore 和 ROUGE 对大多数 LLM 输出并无用处。它们仅适用于拥有精确参考文本的检索评估。

100% 通过率：如果你通过了所有的评估，说明它们不够难。目标应设定在 70% 左右的通过率，以获得有意义的信号。

标准漂移：领域专家无法预先完全确定质量标准。评判输出的过程本身就是定义标准的过程。应建立重新校准周期。

单次运行结论：始终计算置信区间。200 个样本的误差幅度为 ±2.4%；400 个样本为 ±1.7%。永远不要根据单次评估运行就声称有所改进。

单一万能评估器 (One God Evaluator)：用一个评估器对所有内容评分，无法诊断出到底是哪个具体标准退化了。应为每个标准构建专门的评估器。

过早使用提示词优化工具：这些工具会根据你当前的指标进行爬坡优化，而新的失败模式却在不断积累。应同步保持人工参与的误差分析。

不稳定的 CI 测试：LLM 具有非确定性。一个测试可能在一次运行中通过，而在下一次失败。将 LLM 评判留给每日构建 (nightly sweeps)；在阻断提交的测试中使用确定性的断言。

实现生产级评估

从零到可靠评估基础设施的路径分为三个阶段。

在第一阶段（20–50 个样本），手动标注一个包含代表性生产输出的小型数据集。使用二进制的通过/失败判断。开始运行误差分析周期。确定前三个主要的失败模式。为每个模式构建简单的基于断言的测试。

在第二阶段（50–200 个样本），扩大你的标注数据集。训练或配置一个带有批判影子 (critique shadowing) 的 LLM 评判员。衡量其与专家标签的一致性——在信任自动化评分之前，目标应设定在 90% 以上的一致性。针对该数据集构建 CI/CD 评估流水线。

在第三阶段（200+ 个样本），将生产监控与异步采样相结合。建立阻断退化的 CI/CD 门禁。每周运行误差分析周期，在新的失败模式积累之前捕获它们。从生产追踪中持续扩充你的黄金数据集 (golden dataset)，将其视为一份动态文档，而非静态产物。

这项投资具有复利效应。一个团队花了四周时间构建评估基础设施，随后在接下来的两周内进行了数十次实验，并在随后的几个月里进行了数百次实验——而这些工作之前都受阻于人工审核的瓶颈。评估基础设施并没有减慢他们的速度；正是它让他们能够在不破坏系统的情况下快速迭代。

目标不是为了自动化而自动化，而是为了达成一个共同的、精确的质量定义，这个定义要足够廉价以支持持续检查，并足够可靠以在出现退化时值得信赖。