LLM 评测体系：从离线判分到在线回归

系统覆盖 LLM 应用评测工程的全链路。

每一个上线了 LLM 功能的团队，都会在某个深夜遇到同一个问题——"昨天还好好的，今天怎么效果就变了？" 模型升级了一个版本，prompt 多加了一句话，retriever 改了 chunk 大小，向量库换了索引参数。每一处改动都"看起来更好"，但真实质量到底是涨了还是跌了？没人说得清。

这种"凭感觉调 LLM"的工程模式，在 2023 年是普遍现象，到 2026 年已是许多生产事故的根源。Air Canada 的退款 chatbot 因为一句幻觉赔了真金白银；Google Bard 在宣传演示里一句事实错误，Alphabet 市值单日蒸发约千亿美元；OpenAI、Anthropic 因模型版本静默退化被开发者反复声讨——所有这些事故，本质都是同一件事：LLM 应用上线后，再也没有人知道它到底好不好。

测试软件工程师靠的是断言——assert result == expected。LLM 工程师不能这么干，因为模型输出每次都不一样，"对"也不止一种说法。这就是为什么传统的 CI / 单测体系到了 LLM 这一层不够用，必须补上一整套从数据集设计、判分方法、统计推断到在线监控的工程范式。这套范式有一个统一的名字——Evals。

本专栏拆解的就是这套范式。从最基础的"如何写一条规则判分"，到 LLM-as-Judge 的偏差校准，再到 ragas、promptfoo、lm-evaluation-harness 这些开源框架的源码工程学；从离线评测的数据集冷启动，到 CI 里把 Evals 变成质量门禁；从 RAG 的 Faithfulness 度量，到 Agent 的 Trajectory 评估，再到多轮对话与安全对齐的专项评测。

读完本专栏，你会知道：你的 LLM 应用每一次改动的真实效果——而不是猜的。

flowchart TB
  subgraph OFF [离线评测]
    direction LR
    DS[数据集工程<br/>冷启动 · 分层 · 防污染] --> GR
    subgraph GR [判分]
      direction TB
      R[规则判分] --- J[LLM-as-Judge<br/>偏差校准] --- H[人工评测]
    end
    GR --> MT[Meta-Eval<br/>判分器本身准不准]
  end
  MT --> CI[CI 质量门禁<br/>每次改动都过一遍]
  CI --> ON[在线监控<br/>回归 · 漂移 · 告警]
  ON -.真实样本回流.-> DS
  GR -.专项.-> SP[RAG · Agent · 多轮 · 安全]

这条链路里最容易被跳过的是 Meta-Eval。 大多数团队搭完 LLM-as-Judge 就以为有评测了——但如果没人评过这个 judge 本身，你只是把"凭感觉"换成了"凭另一个模型的感觉"。第 8 章专门讲怎么给判分器打分。

读完你能做到什么

1. 从零建一个能用的评测集。 冷启动策略、分层设计、难例挖掘、防污染，以及数据集怎么随业务演进（第3章 数据集工程）。
2. 选对指标。 哪些指标在什么场景下有意义、哪些是自欺欺人，以及统计显著性——两次跑分差 2% 到底算不算改进（第4章 指标）。
3. 写出三类判分器并知道各自的边界。 规则判分、LLM-as-Judge 的偏差与校准、人工评测的组织方式（第5章 规则判分、第6章 LLM-as-Judge、第7章 人工评测）。
4. 评估你的评估。 Meta-Eval：判分器与人类判断的一致性怎么量、偏了怎么修（第8章 Meta-Eval）。
5. 读懂主流开源框架的设计取舍。 OpenAI Evals、lm-evaluation-harness、ragas、promptfoo 各自的抽象与适用面（第9章、第10章、第11章、第12章）。
6. 做专项评测。 RAG 的 Faithfulness、Agent 的 Trajectory、多轮对话、安全对齐（第13章 RAG 评测、第14章 Agent 评测、第15章 多轮、第16章 安全）。
7. 把评测接进 CI，变成门禁。 什么该拦、什么只该告警、跑多久算可接受，以及在线平台怎么选（第17章 在线平台、第18章 CI 质量门禁）。

适合谁读

• LLM 应用工程师：已经把 LangChain / LangGraph / RAG 跑通，但下一步的"质量怎么衡量"卡住了
• AI Infra / 平台工程师：要为团队搭建评测平台，需要理解 langsmith / langfuse / phoenix 等系统的设计差异
• 算法 / 模型评测同学：想从学术 benchmark（MMLU、MT-Bench、Arena Hard）跨到工业级线上评测体系
• 技术负责人 / Tech Lead：负责 LLM 项目交付质量，需要建立可量化的验收标准

前置阅读：本专栏假设读者已经写过 LLM 应用代码（至少调过 OpenAI / Anthropic API），理解 prompt、retriever、tool calling 的基本概念。如果你还在 LLM 入门阶段，建议先读本系列的《LangChain 设计与实现》《RAG 工程与检索系统设计》。

目录

第一部分：为什么需要评测

• 前言
• 第 1 章 评测缺位的代价：从 5 个真实事故谈起

第二部分：评测理论基础

• 第 2 章 LLM 评测体系全景：离线、在线、回归三层模型
• 第 3 章 数据集工程：黄金集、对抗集与分布漂移
• 第 4 章 指标体系：从 Accuracy 到 Faithfulness 的演化

第三部分：判分方法学

• 第 5 章 规则判分：Exact Match / Regex / JSON Schema
• 第 6 章 LLM-as-Judge：原理、偏差与校准方法
• 第 7 章 人工评测：标注流程、一致性度量与众包成本
• 第 8 章 元评测：如何评测评测器本身

第四部分：开源框架源码剖析

• 第 9 章 OpenAI evals 源码：模板系统与 Solver 抽象
• 第 10 章 lm-evaluation-harness：学术评测的事实标准
• 第 11 章 ragas：RAG 评测的工程范式
• 第 12 章 promptfoo：生产化评测最易上手的工具

第五部分：场景化评测实战

• 第 13 章 RAG 评测：Context Recall、Faithfulness、Answer Relevance
• 第 14 章 Agent 评测：Tool Calling 正确性与 Trajectory 评估
• 第 15 章 多轮对话评测：MT-Bench、Arena Hard 与对话级指标
• 第 16 章 安全与对齐评测：HELM、Jailbreak、Bias 与红队测试

第六部分：生产化与持续评测

• 第 17 章 在线评测平台：langsmith、langfuse、phoenix 架构对比
• 第 18 章 把 Evals 变成 Quality Gate：CI 集成与回归告警

源码版本与数据来源

本专栏所有源码引用、实验结论均基于以下版本和公开来源。版本清单于 2026 年 4 月 27 日锁定，锁定的是下表各 pin，不是锁定当日各仓库的最新版；各 pin 自身的提交日期见表：

时效说明（核对日期 2026-09-25）：据 OpenAI 官方弃用页（developers.openai.com/api/docs/deprecations），OpenAI 于 2026-06-03 宣布弃用其托管 Evals 平台（Evals dashboard + Evals API）：2026-10-31 起现有 evals 只读，2026-11-30 计划关停，官方推荐迁移到 Promptfoo（第 12 章）。第 9 章剖析的是开源仓库 openai/evals，与托管平台是两回事，本地运行不受影响，详见第 9 章 §9.7.3。

学术 benchmark 与论文引用：MMLU (Hendrycks et al. 2021, arXiv:2009.03300)、MT-Bench (Zheng et al. 2023, arXiv:2306.05685)、Arena Hard (Li et al. 2024, arXiv:2406.11939)、HELM (Liang et al. 2023, arXiv:2211.09110)、ragas 论文 (Es et al. 2023, arXiv:2309.15217)、G-Eval (Liu et al. 2023, arXiv:2303.16634)、JudgeBench (Tan et al. 2024, arXiv:2410.12784)、TruthfulQA (Lin et al. 2022, arXiv:2109.07958)、HaluEval (Li et al. 2023, arXiv:2305.11747)。

正文中凡以「具体例子」「举例」引出的案例数字，以及标注了「示意数据」的表格，都是为了说明口径与决策方式而构造的示意值，不是任何团队的实测结果——落到自己的系统上必须用自己的数据重新算一遍。

行业事故与公开数据：Moffatt v. Air Canada (2024 BCCRT 149)、Google Bard demo 事件、ChatGPT 退化争议（公开 GitHub Issue / Reddit / arXiv:2307.09009）、Anthropic / OpenAI 官方 model deprecation 公告。

读者可通过仓库 git clone 命令获取与本专栏完全一致的源码：

git clone https://github.com/openai/evals.git
git clone https://github.com/EleutherAI/lm-evaluation-harness.git
git clone https://github.com/vibrantlabsai/ragas.git
git clone https://github.com/promptfoo/promptfoo.git
git clone https://github.com/langchain-ai/langsmith-sdk.git
git clone https://github.com/langfuse/langfuse.git
git clone https://github.com/Arize-ai/phoenix.git

本专栏与其他专栏的关系

本专栏属于杨艺韬讲堂 AI 方向的专栏，与以下专栏形成知识网络：

• 《LangChain 设计与实现》：链式调用与 Agent 框架，是 Evals 的常见被测对象
• 《LangGraph 设计与实现》：第 14 章的多 Agent 协作评测以 LangGraph 这类工作流框架搭出的系统为被测对象
• 《MCP 协议设计与实现》：第 14 章 Tool Calling 评测以 MCP 标准化的 tool schema 为协议基础
• 《RAG 工程与检索系统设计》：第 13 章 RAG 评测与之配套，前者讲怎么搭、本专栏讲怎么测
• 《vLLM 推理内核深度解析》：第 10 章讨论以 vLLM 作 lm-eval 的推理后端
• 《Claude Code 源码深度解析》：Claude Code 本身就是一个 Agent，可作为第 14 章 Agent 评测方法的被测对象

版权声明

本专栏内容为 杨艺韬 版权所有，保留一切权利。未经书面许可，不得全文或大段转载、改编、翻译，或用于任何商业用途（含以本专栏内容训练模型、生成衍生课程或商品）。

欢迎分享本专栏的链接。引用少量内容用于评论、教学或研究时，请署名 杨艺韬 并附上原文链接。