LLM 评测体系

前言

作者 杨艺韬 · 5,015 字 · 发布于 · 更新于

写给准备翻开这个专栏的你

如果你是一位写过 LLM 应用的工程师，请先回想一下你最近一次"觉得效果变差了"的瞬间。

可能是把模型换成了同一家的新一代型号，发现某些客户的反馈突然变得敷衍；可能是把 prompt 里的"请用礼貌的语气"删掉了，看似无关紧要，但客服满意度的某个角落里似乎少了点什么；也可能是把 retriever 的 chunk size 从 512 改到了 1024，自测了几条 query 看起来都更"完整"了，于是上线，然后两周后产品经理问你："最近用户为什么开始抱怨答案太啰嗦？"

你想反驳，但你拿不出数字。你只能说："我感觉应该是更好的。"

这种"凭感觉"的工程模式，在传统软件领域早已被淘汰。任何一个 Java 后端工程师都会本能地写单测、跑 CI、看监控曲线。但到了 LLM 这一层，这些工具突然不够用了——因为模型每次输出都不一样，"对"也不止一种说法，传统的 assertEquals 写不出来。整个行业被迫重新发明一套针对"非确定性输出"的工程范式，这套范式有一个统一的名字——Evals（评测）。

本专栏要做的事情很简单：让你写 LLM 应用时，能像写 Java 后端一样有底气。每一次 prompt 改动、每一次模型升级、每一次 retriever 调参，你都能在 5 分钟内拿出一组数字，告诉团队"这次改动让 Faithfulness 涨了 3.2 个百分点、Hallucination Rate 降了 18%、平均响应延迟基本持平"。

这个专栏不是什么

在讨论"是什么"之前，先把"不是什么"说清楚，避免你带着错误的期待读了三章才发现选错了东西。

这个专栏不是 LLM 入门教程。 我假设你写过 prompt、调过 OpenAI / Anthropic API、至少跑通过一个 RAG demo 或一个 Agent 工作流。如果你还在"什么是 token"这个层面，请先去读《LangChain 设计与实现》或开源教程。

这个专栏不是 benchmark 排行榜。 我不会用 50 页的篇幅告诉你哪家旗舰模型在 MMLU 上比另一家高几个点，或者哪个开源模型在 MATH 上是不是真的超过了某个推理模型。这些数字一周一变，明天就过时。本专栏关心的是你自己业务上的评测，而不是模型厂商之间的牌桌排名。学术 benchmark 会作为方法论案例出现（第 4、10、15 章），但它们不是目的地。

这个专栏不是工具评测综述。 我不会给你一张"ragas vs promptfoo vs langsmith vs langfuse vs phoenix"的功能矩阵让你勾选。这些工具的功能是流动的——昨天 promptfoo 不支持 trace、今天就支持了。本专栏的做法是直接读源码：剖析每个工具的核心抽象（Test Case、Assertion、Grader、Run）是怎么设计的，理解了底层模型，你就能在任何工具之间无缝迁移，而不是绑死在一个工具上。

这个专栏不是"评测最佳实践"清单。 我不会写"五大原则、十条军规"这种东西。每个团队的业务、用户、监控基础设施都不同，照搬清单只会让你掉进新的坑。本专栏提供的是判断框架：什么场景应该用规则判分、什么时候必须升级到 LLM-as-Judge、什么时候只能上人工标注、人工标注怎么控成本——你看完每一章会知道为什么这样选，而不是"专家说要这样"。

这个专栏是什么

这个专栏讲的是评测工程师的手艺。它有六个部分，从认知建立到工程落地一路打通：

graph LR
  A[第一部分<br/>为什么需要评测] --> B[第二部分<br/>评测理论基础]
  B --> C[第三部分<br/>判分方法学]
  C --> D[第四部分<br/>开源框架源码剖析]
  D --> E[第五部分<br/>场景化评测实战]
  E --> F[第六部分<br/>生产化与持续评测]
  style A fill:#fef3c7
  style B fill:#dbeafe
  style C fill:#dcfce7
  style D fill:#fce7f3
  style E fill:#e0e7ff
  style F fill:#fed7aa

第一部分（第 1 章） 用 5 个有据可查的真实事故切入——Air Canada 因 chatbot 幻觉被不列颠哥伦比亚省民事纠纷裁决庭（Civil Resolution Tribunal）判定赔偿；Google Bard 在一段公开演示动图里说"James Webb 拍下了第一张系外行星照片"，Alphabet 市值单日蒸发约千亿美元；ChatGPT 的"GPT-4 是不是变笨了"争议，斯坦福 / UC 伯克利研究者的 arXiv:2307.09009 用数据证实同名模型的行为在数月间确有明显漂移（有的任务变差、有的变好）——让你直观感受到没有评测体系的代价。

第二部分（第 2-4 章） 建立评测的概念框架：离线评测、在线评测、回归评测的三层模型；黄金集 / 对抗集 / 分布漂移的数据集工程；以及从 Accuracy 一路演化到 Faithfulness、Context Recall 这些 LLM 时代特有指标的脉络。

第三部分（第 5-8 章） 是判分方法学的全谱系：规则判分（Exact Match、Regex、JSON Schema 校验）何时够用、何时不够；LLM-as-Judge 为什么会有偏差（位置偏差、长度偏差、自我偏好），怎么用 G-Eval、JudgeBench 的方法校准；人工评测的标注流程、Inter-rater Agreement（Cohen's Kappa、Krippendorff's Alpha）怎么算；以及最容易被忽略的"元评测"——你怎么知道你的评测器本身是可靠的？

第四部分（第 9-12 章） 拉来四个最有代表性的开源框架，逐行读源码：

读完这四章你会理解：所有评测框架都在解同一个问题，但用了完全不同的抽象。

第五部分（第 13-16 章） 是场景化评测实战：RAG 系统怎么测（第 13 章）、Agent 系统怎么测（第 14 章）、多轮对话怎么测（第 15 章）、安全与对齐怎么测（第 16 章）。每一章都会给出可直接拿走改用的评测代码，不依赖你做任何实验——数据集、判分实现、统计推断都基于公开论文和开源框架。

第六部分（第 17-18 章） 把视野从"如何写评测"拉到"如何运维评测"：在线评测平台 langsmith / langfuse / phoenix 的架构对比（它们解决的是不同的问题，不是替代关系）；以及怎么把 Evals 变成 CI 里的 Quality Gate——和单元测试一样，每次 commit 自动跑一组评测、不达标就阻止合并。

怎么读这个专栏

第一遍顺序读。前四章是基础，跳过任何一章都会让后面的源码分析失去坐标。

第二遍按需读。如果你做的是 RAG，重点啃第 11 章（ragas 源码）+ 第 13 章（RAG 评测实战）；如果你做的是 Agent，重点啃第 14 章 + 第 8 章（元评测）；如果你在搭团队的评测平台，重点啃第 17、18 章。

每章末尾会有"延伸阅读"——指向论文、源码 commit 或本站其他专栏的具体章节。这些链接不是装饰，是评测体系学习路径的真实节点。

关于"不需要你做实验"

这个专栏有一条特殊承诺：不要求读者动手做任何评测实验来理解正文的结论。

普通技术书的写法是："读者请按以下步骤搭建测试环境，跑通后即可观察现象。"——但这条路对评测来说几乎走不通：搭一个 RAG 系统要先备数据、跑一组 Agent 评测要付一笔不小的 API 费、做一次 Inter-rater Agreement 要找三个标注员各标 200 条。一个专栏要求读者复现这些，等于把绝大多数人挡在门外。

本专栏走的是另一条路：所有实验数据来自三个有据可查的来源（正文中以「具体例子」「举例」引出、或标注「示意数据」的数字是为说明口径而构造的示意值，不在此列，见专栏首页说明）——

  1. 公开论文：ragas 论文里的对比表、G-Eval 论文里的偏差实验、JudgeBench 论文里的 Judge 排名，引用时都附 arXiv 编号
  2. 开源框架的官方 benchmark 结果：lm-evaluation-harness 的 task 文档、OpenAI evals 仓库的 registry 规格与示例 notebook、HELM 官网的 leaderboard
  3. 行业公开事故与运营数据：Air Canada 案裁决书、Google Bard 事件的 Reuters 报道、ChatGPT 退化争议的 GitHub Issue 时间线

你只需要读、思考、判断；每一个结论都能在各章的延伸阅读与引用出处里追溯到原始来源。

怎么用本专栏搭建团队的评测体系

如果你不只是想读完、还想真的在团队里把评测体系跑起来，这里给一份分阶段的执行路径。它对应本专栏章节顺序，但每一步都是可独立交付的工程小步：

gantt
    title 团队评测体系的 12 周路线
    dateFormat  YYYY-MM-DD
    section 月 1：起步
    搭 50 题黄金集（手工）       :a1, 2026-05-01, 7d
    跑通规则判分                  :a2, after a1, 5d
    跑通 LLM-as-Judge 一种         :a3, after a2, 5d
    section 月 2：扩量
    扩到 200 题 + 加入对抗集       :b1, 2026-05-21, 7d
    搭 trace 系统(langsmith等)    :b2, 2026-05-28, 5d
    Hard Case Mining 例会         :b3, after b2, 14d
    section 月 3：自动化
    回归集 + CI 集成               :c1, 2026-06-15, 7d
    时序告警 + Grafana 看板        :c2, after c1, 5d
    元评测季度仪式                 :c3, after c2, 5d

每一步对应的本专栏章节：

走完这 12 周，团队就有了一套覆盖离线评测、CI 门禁与在线 trace 的基础评测体系，之后按业务逐层加深。

本专栏的写作方法论：不依赖私人经验，全靠公开来源

这里要单独交代一件事——为什么我能保证"读者不需要做实验"也能读懂这个专栏。

本专栏不依赖任何"我的团队遇到过"、"我的项目里"这种第一人称体验。所有结论的来源严格限定在三类：

  1. 可被任何读者验证的开源代码：openai/evals、ragas、promptfoo、lm-evaluation-harness、langsmith-sdk、langfuse、phoenix——所有源码引用都以专栏首页锁定的版本为准，并标注文件路径
  2. 可被任何读者下载的论文与文档：MMLU、MT-Bench、Arena Hard、HELM、JudgeBench、ragas、G-Eval、TruthfulQA——所有引用都附 arXiv 编号或官方报告链接
  3. 可被任何读者读到的公开案例：裁决书、调查报道、模型方官方 model card——事故描述都附原始出处

这意味着你读到任何一句话都能反查到原始来源。如果哪一句你不信，自己花 5 分钟就能验证或证伪。这种全可追溯的写法是评测内容的应有之义——评测本身就是讲"可追溯性"的工程，作者再讲一堆没法追溯的"个人经验"那是讽刺。

关于版本与时效性

这是一个变化极快的领域。本专栏的源码版本清单于 2026 年 4 月锁定（详见首页"源码版本与数据来源"表；表中各 pin 并非锁定当日的最新版，各自的提交日期也列在表里），所有 commit 哈希、行号、API 形态都以这些 pin 为准。

但评测体系的方法论部分——为什么需要黄金集、LLM-as-Judge 的偏差从哪来、Faithfulness 怎么定义——这些不会随框架版本而变化。框架会迭代、benchmark 会被新数据集取代，但问题的形状已经稳定。读完这个专栏，你拥有的不是某个 2026 年工具的使用说明，而是一种能长期适用的评测工程心智。

工具链与资源清单：可直接拿走的链接

为方便读者上手，把全专栏涉及的核心工具与资源在这里列一份清单：

评测框架（按本专栏第 9-12 章顺序）

在线评测平台（第 17 章）

红队 / 安全工具（第 16 章）

学术 benchmark / 论文

法规与标准（第 16 章）

事故案例的官方文件

给不同读者的"前 20 页"路径

本专栏篇幅较长。如果时间有限，按你的角色挑前 20 页：

你是 LLM 应用工程师：读 §1 ~ §1.10、§2 ~ §2.7、§4 ~ §4.6、§13 整章——掌握"为什么 + 三层模型 + 指标 + RAG 实战"。后续按需翻第 18 章了解 CI 集成。

你是 ML / 平台工程师：读 §1 ~ §1.7、§9 ~ §10 整两章、§17 整章——掌握"为什么 + 框架架构 + 在线平台"。后续按需翻第 8 章元评测。

你是 PM / 技术负责人：读 §1 整章、§2.8（成本与投资回报）、§16.8（合规）、§18.7（组织角色）——掌握"事故代价 + 阶段化 + 合规 + 团队"。具体技术细节让工程师读。

你是 QA / 测试工程师：读 §1.7（事故）、§5 整章（规则判分）、§7 整章（人工评测）、§12 整章（promptfoo）、§18 整章（CI Gate）——掌握"质量纪律 + 工具链 + 流程"。

你是合规 / 法务：读 §1 整章、§3.8（PII）、§16 整章、§18.5（指标版本化）——掌握"合规风险 + 安全评测 + 审计"。

你是研究员 / 学生：读 §4 整章、§6 整章（LLM-as-Judge）、§10 整章（lm-eval）、§15.2-15.3（MT-Bench / Arena）——掌握"指标 + judge 方法学 + 学术 benchmark"。

每条路径覆盖关键 4-5 章，先拿到与角色最相关的部分，其余在工作中按需翻补。

核心论文与出处一览

全专栏引用的核心论文按主题分类如下（「事故案例」一组列的是 5 起事故的原始出处，不是论文）：

评测方法学（基础）

Bias 校准

事故案例

Benchmark

Agent 评测

安全 / Bias

人工标注

Long context

模型遗忘（Unlearning）

论文均附 arXiv 编号，可在 arxiv.org 直接下载。

术语表

本专栏反复出现的 30 个术语，读各章时可回查：

术语 英文 一句话定义 出现章节
黄金集 Golden Set 经过专家校对、答案唯一的高质量小规模评测集 Ch3, 7
对抗集 Adversarial Set 故意设计来诱发模型失败的边界样本集 Ch3, 16
漂移 Drift 生产数据分布相对评测集分布发生的偏移 Ch3, 17
评测三层 3-Layer Evals 离线 + 在线 + 回归 三层评测体系 Ch2
元评测 Meta-Eval 评估"评测系统本身"的可靠性 Ch8
Faithfulness Faithfulness 答案是否完全 grounded 在给定上下文 Ch4, 11, 13
Context Recall Context Recall 检索到的上下文是否覆盖标准答案信息 Ch4, 11, 13
Context Precision Context Precision 检索到的上下文里有用的部分占多少、排得靠不靠前（ragas 按排名加权） Ch4, 11, 13
Answer Relevance Answer Relevance 答案是否切题（不脱离 query 意图） Ch4, 11
LLM-as-Judge LLM-as-Judge 用大模型当评分员的范式 Ch6, 11
Position Bias Position Bias 评判时偏好选项位置（A 优先 / B 优先） Ch6
Length Bias Length Bias 评判时偏好更长的回答 Ch6
Self-preference Bias Self-preference Bias 模型评判自己生成的回答时打高分 Ch6
Cohen's Kappa Cohen's Kappa 两位标注员一致性，扣除随机一致 Ch7, 8
Fleiss' Kappa Fleiss' Kappa 多位标注员一致性指标 Ch7, 8
Krippendorff's Alpha Krippendorff's Alpha 兼容缺失值与有序标签的一致性指标 Ch7, 8
Trajectory Trajectory Agent 整个执行路径（tool 调用序列） Ch14
Tool Call Accuracy Tool Call Accuracy Agent 调用对工具且参数正确的比例 Ch14
Goal Reached Goal Reached Agent 是否达到了任务目标 Ch14
Spearman ρ Spearman correlation 度量自动评分与人工评分的排序相关性 Ch4, 8
Discriminative Power Discriminative Power 指标区分两个相似系统的能力 Ch4, 8
Calibration Calibration 自动评分与人工评分的相关程度 Ch8
Self-Consistency Self-Consistency 同一个评测对同一样本多次结果的一致性 Ch8
Quality Gate Quality Gate CI 中阻止低质量代码合入的评测门禁 Ch18
Hard Case Mining Hard Case Mining 从生产 trace 中挖掘失败样本反哺评测 Ch3, 17
Trace Trace 一次完整 LLM 调用链路的可观测记录 Ch17
OpenInference OpenInference Arize 发起、基于 OpenTelemetry 的 LLM trace 语义约定 Ch17
Schema-First Eval Schema-First Eval 用 Pydantic 定义"应用契约 + 评测契约"的范式 Ch5
Constitutional AI Constitutional AI Anthropic 提出的"原则约束模型行为"方法 Ch16
OWASP LLM Top 10 OWASP LLM Top 10 LLM 应用十大安全风险标准 Ch16

延伸阅读

各主题在本专栏之外的延伸入口：

主题 必读论文 / 工具 链接类型
LLM-as-Judge 方法学 Zheng et al. 2023 (MT-Bench) arXiv:2306.05685
RAG 评测框架 ragas 0.2.x docs docs.ragas.io
安全评测 HarmBench (Mazeika 2024) arXiv:2402.04249
Agent 评测 SWE-bench leaderboard swebench.com
在线评测平台 Langfuse / Phoenix / LangSmith 各官方文档
元评测 Klie et al. 2024 "Analyzing Dataset Annotation Quality Management in the Wild" Computational Linguistics 50(3)
数据集治理 Datasheets for Datasets (Gebru et al. 2018) arXiv:1803.09010
标注员保护 Roberts 2019 Behind the Screen Yale University Press
Prompt 版本化 LangChain Hub / LangSmith Prompt 各 SaaS
OWASP LLM Top 10 owasp.org/llm 持续更新
EU AI Act 实施 artificialintelligenceact.eu 官方追踪站
中国合规 网信办深度合成规定 法律法规库

致谢

最后想感谢所有把这些方法学开放分享的团队和个人——OpenAI 的 evals 团队、EleutherAI 的 Harness 维护者们、ragas 的 Shahul / Jithin、promptfoo 的 Ian、LangChain 的 Harrison、LMSYS 的 lm-arena 团队、Anthropic 的 RLHF 与 Constitutional AI 研究者们、HELM 的 Stanford CRFM 团队。没有他们持续把工业级评测方法做成开源工具与公开论文，本专栏的每一章都将是无米之炊。

也感谢中文社区的早期读者——是他们的反馈让我意识到"中文 LLM 评测的系统性内容缺位"是个真问题，也才有了这个专栏的写作动机。

如果你读完本专栏还有疑问、发现错误、或想分享你的评测体系建设经验——欢迎在杨艺韬讲堂的项目仓库提 issue / PR，或者在我的微博 / Twitter 上私信。下一版会基于真实读者的反馈改进。

下一章见。