第 15 讲（拓展）：评估方法与期末项目

对应：这一讲不对应原课的某一次讲座，而是把散落在整个学期里的评估方法系统地整理一遍，并为期末项目做准备。材料来源：阅读清单第 10 部分”Evaluation of LLMs”（HELM，Liang 等，2022；Gehrmann 等关于生成文本评估实践的综述，2022；MT-Bench 与 Chatbot Arena，Zheng 等，2023；G-Eval，Liu 等，2023）；课程的项目说明页；Fall 2026 的 12/2 项目展示；以及第 1~14 讲里的评估。 配套代码：code/lecture15/（只用 Python 标准库；02 号文件的统计工具可以直接用在你的项目数据上） 预计阅读时间：2.5 小时左右（含运行代码）

0. 本讲导航

0.1 学完本讲，你应该能够

1. 回顾这门课里用过的评估方法和踩过的坑，说出评估的六条原则。
2. 比较几种评估方式：有参考答案的自动指标、整体评估（HELM）、LLM 当评委、模拟用户、真实用户研究、错误分析；知道各自适合什么、有什么陷阱。
3. 测出并减轻 LLM 评委的偏差：位置偏差、长度偏差、自我偏好；用”和人的一致率 vs 人和人的一致率”、负对照来验证评委。
4. 用统计方法支撑结论：自助法置信区间、配对比较、统计功效、多重比较、Bradley-Terry 排名、标注一致性（Cohen’s kappa）。
5. 为期末项目写一份评估方案；了解项目的交付物（提案、展示、海报、论文、代码）。

0.2 先修知识

这一讲是整门课的回顾，前面每一讲的评估部分都会被引用。特别是：第 5 讲（WikiChat 的评估框架、模拟用户、真实用户）、第 8 讲（自助法置信区间、数据集的规模）、第 11 讲（LLM 评委总给 7 分、标注错误）、第 12 讲（古德哈特定律、在搜索集上过拟合）。项目的选题与提案见第 3 讲第 8 节。

0.3 本讲地图

第1节  回顾：这门课里的评估与六条原则
第2节  评估的几种方式；LLM 当评委                       ← 代码 01
第3节  评估里的统计                                     ← 代码 02
第4节  期末项目：交付物与评估方案模板
第5–8节 小结、练习、延伸阅读、结语

关于本讲的数字：论文里的真实数字会注明出处；代码演示的数字来自 01、02 号文件的实际输出（评委、人、系统都是模拟的，演示的是方法）。

1. 回顾：这门课里的评估

1.1 每一讲是怎样评估的

1.2 六条原则

从这张表里可以归纳出这门课反复强调的六条原则：

1. 指标要对应用途。准确率、F1、相似度、任务完成率……选哪个、怎样统计（按页还是拼在一起、按类别分开），取决于系统要用来做什么（第 13 讲练习 2：给人读看 CER，按人名检索看 WER）。
2. 先检查标准答案。标注错误比你以为的多（第 6、8、10、11、13 讲）。得分低的样例要一条条看，区分”系统错了”和”答案错了”。
3. 不要让被评估的系统给自己打分。智能体自称的成功率（第 12 讲：自称 85%，真实 29%）、模型自己的信心（第 1 讲）都不可信。
4. 留一个独立的测试集。所有的调整只看开发集（搜索集），最后在测试集上报告一次（第 12、14 讲）。
5. 人要在回路里。自动指标和 LLM 评委要用人的判断去验证；最终的指标是真实用户（第 5、10、11 讲）。
6. 用统计说话。小样本的演示没有说服力（第 1 讲）；报告置信区间，比较时用配对的方法（第 8 讲，本讲第 3 节）。

2. 评估的几种方式

2.1 有参考答案的自动指标

EM（完全匹配）、F1、BLEU / ROUGE（词重叠）、CER（字符错误率）、执行准确率……它们便宜、可复现，适合答案明确的任务。问题在于：答案可以有很多种正确的写法（第 7 讲：HybridQA 里很多 EM 为 0 的答案其实是对的）；词重叠和”好不好”的相关性很弱，尤其是开放式的生成任务（第 5 讲：BlenderBot-3、Atlas 的教训）。Gehrmann 等（2022）的综述整理了生成文本评估实践中的常见问题：依赖和人的判断相关性很弱的自动指标、人工评估的设置五花八门无法比较、报告的信息不足以复现，并给出了改进的建议。

2.2 整体评估：HELM

HELM（Liang 等，2022）的出发点是：只看一个基准上的准确率，会漏掉很多重要的东西。它在很多场景（问答、摘要、信息检索、毒性检测……）上，用很多指标同时评估模型：准确率之外，还有校准（信心和正确率是否一致）、鲁棒性（输入稍有变化时是否稳定）、公平性、偏见、毒性、效率。并且所有模型用同样的设置、公开所有的提示和输出。这和第 4 讲 VERDICT 的观点一致：一个可问责的系统，不能只看准确率。

2.3 LLM 当评委

开放式的输出（对话、报告、长文章）很难用参考答案评估，于是用一个强的 LLM 当评委。这门课几乎每一讲都用到了它。MT-Bench 论文（Zheng 等，2023）系统地研究了它的可靠性，提出了三种用法：

• 两两比较：给评委一个问题和两个回答，问哪个更好；
• 单独打分：给一个回答打 1~10 分；
• 参考答案引导：先给评委一个参考答案，再让它评判（数学、推理题特别需要）。

结论一：强的评委和人的一致率超过 80%，和人与人之间的一致率相当（在 MT-Bench 的 3,000 条专家投票和 Chatbot Arena 的众包投票上）。所以 LLM 评委是一个可以扩展、可以解释（它会写出理由）的近似人类偏好的方法。

结论二：它有系统性的偏差。

代码 01 用一个模拟的评委（偏差大小是设定的）演示怎样测出这些偏差。两个评委：甲的偏差小、乙的偏差大。

演示 1：交换顺序后结论还一样吗？（400 对质量相近的回答）

评委                    前后一致   两次都选第一个   两次都选第二个
评委甲（偏差小）             54%            30%             16%
评委乙（偏差大）             36%            60%              4%

偏差大的评委有 60% 的时候”选的是位置，而不是回答”。

演示 2：交换顺序、两次一致才算赢（400 对质量差别正常的回答）

评委                    做法               判出胜负的比例   其中和"真正更好的"一致
评委甲（偏差小）        只问一次（A 在前）          100%               80%
评委甲（偏差小）        交换顺序，两次一致才算       71%               92%
评委乙（偏差大）        只问一次（A 在前）          100%               59%
评委乙（偏差大）        交换顺序，两次一致才算       44%               85%

只问一次时，偏差大的评委的结论和真相只有 59% 一致（几乎是抛硬币）；交换顺序、只保留一致的结论之后，剩下的胜负 85% 是对的——代价是两倍的调用、更多的平局。

演示 3：“重复列表”攻击（内容不变、长度翻倍，呈现顺序随机）

评委甲（偏差小）：认为加长的版本更好 51%（没有长度偏差时应为 50%）
评委乙（偏差大）：认为加长的版本更好 69%（没有长度偏差时应为 50%）

一个设计上的细节：最初的实验要求”两种顺序都选加长的版本”才算被骗，结果偏差大的评委反而”被骗得更少”——它强烈的位置偏差在两种顺序里互相抵消了。测量一种偏差时，要控制住其他的偏差（这里是随机决定呈现顺序）。

演示 4：和人的一致率（600 对回答，排除平局）

人 1 和 人 2：72%
评委甲（偏差小） 和 人 1：74%
评委乙（偏差大） 和 人 1：62%

人和人之间本来就不完全一致。评委和人的一致率不应该和 100% 比，而应该和”人和人的一致率”比：评委甲达到了人的水平，评委乙明显不如。

2.4 打分的细节：G-Eval

G-Eval（Liu 等，2023）给出了用 LLM 打分的一套做法：(1) 让评委先根据评价标准自动生成评估步骤（思维链）；(2) 用”填表”的方式输出分数；(3) 不只取评委输出的那个整数，而是用每个分数的概率加权：$\text{score} = \sum_s s \cdot P(s)$。整数分数的问题是大量并列、细微的差别丢掉了；加权之后分数是连续的。用 GPT-4，G-Eval 在摘要评估上和人的斯皮尔曼相关达到 0.514，超过了之前所有的方法。论文也提醒：LLM 评委可能偏爱 LLM 写的文本。

代码 01 演示 5（300 个回答，1~5 分）：

只取一个整数：只有 5 种不同的分数；和人的评分的斯皮尔曼相关 0.786
按概率加权：  299 种不同的分数；和人的评分的斯皮尔曼相关 0.826

2.5 怎样验证你的评委

把评委当作一个需要评估的系统（“元评估”）：

1. 负对照：拿明显错误的输出给它评，分数应该很低；拿两个完全相同的输出，应该判平局。第 11 讲里那个总给 7 分的评委，第一步就会暴露；
2. 和人比：抽几十到几百个样例请人判断，计算一致率（以及人和人之间的一致率）；看评委在哪类样例上和人分歧；
3. 测偏差：交换顺序、加长内容、换成评委自己写的回答，看结论是否改变（演示 1~3）；
4. 换评委：用两个不同家族的评委，结论应该一致（第 11 讲 DataSTORM 在 GPT-4o 和 Qwen3 两个评委下都领先）；
5. 读理由：评委写出的理由是否合理？它有没有在评判它不会做的题（数学、专业知识）？

2.6 模拟用户

对话系统要多轮评估，又不能每次都找真人。模拟用户（第 5、10 讲）是一个 LLM 扮演的用户，按设定的目标和性格和系统对话。它的价值在于可以大规模、可重复地测试；陷阱在于：模拟用户往往太”配合”、太有礼貌，只走”愉快的路径”（第 10 讲：WOZ 风格的愉快用户让所有系统都接近 100%）；它和被测系统用的是同一类模型，可能共享同样的盲点。模拟用户适合开发阶段的回归测试，最终的结论要靠真实用户。

2.7 真实用户研究

这门课最有说服力的结果都来自真实用户：WikiChat 的用户研究、Genie Worksheet 的 62 位真实用户、DataSTORM 的 10 位新闻工作者。设计一个用户研究要考虑：

• 伦理：涉及人的研究需要伦理审查（例如美国大学的 IRB）、知情同意，不保存可识别个人身份的信息（DataSTORM 论文附录 C 有完整的说明）；
• 任务：用户做什么？给他们什么背景？（DataSTORM 先给评估者看中性的主题和专家文章，再看两份报告）；
• 抵消顺序效应：一半的人先看系统 A，另一半先看系统 B；两份报告匿名、统一格式；
• 多个维度：评分表的每一项都要有明确的定义（DataSTORM 用新闻价值的 7 个维度）；
• 标注一致性：多位评估者时报告一致性（第 3.6 节的 kappa）；分歧本身也是信息；
• 定性反馈：自由评论的编码常常比分数更能说明问题（DataSTORM：40% 的评论批评基线论点弱）。

2.8 错误分析

分数告诉你”好不好”，错误分析告诉你”为什么”和”接下来改什么”。做法：

1. 随机抽样失败的例子（不要只看你记得的那几个）；
2. 逐个检查，给每个失败归类：系统的哪个部件错了？还是标准答案错了？
3. 统计每一类的比例，按比例决定优先改什么。

这门课里的错误分析：第 1 讲 RAG 的错误归因、第 8 讲 SPINACH 的错误分类、第 11 讲 InsightBench（45% 是标注错误、55% 是真正的失败，其中 45% 涉及时间序列）、第 13 讲 CHURRO（阅读顺序 42% → 16%，幻觉 36% → 0%）。第 12 讲的”读轨迹的优化器”就是把错误分析自动化了。

3. 评估里的统计

“我的系统 74%，基线 70%，我赢了。“——真的吗？代码 02 的六个演示回答这个问题。它们用的方法都可以直接用在你的项目数据上（README 里有用法）。

3.1 一个准确率有多准

代码 02 演示 1：真实准确率 70% 的系统，在不同数量的题目上评估：

题目数   测得的准确率   自助法 95% 区间      区间宽度   正态近似的宽度
   100        70.0%      [61.0%, 78.0%]        17.0%         18.0%
   400        66.5%      [62.0%, 71.2%]         9.3%          9.3%
  1600        71.8%      [69.6%, 73.9%]         4.3%          4.4%

自助法（bootstrap）：从你的测试集里有放回地抽同样多的题，算一次准确率；重复一千次，取第 2.5 和第 97.5 百分位，就是 95% 置信区间。它不需要任何公式，任何统计量都能用。对准确率这种比例，也可以用正态近似：

两者很接近。区间宽度按 $1/\sqrt{n}$ 缩小：题目数变成 4 倍，区间宽度大约减半。100 道题时，“70%“其实可能是 61% 也可能是 78%。

3.2 配对比较

演示 2：系统 A（真实 70%）和 B（真实 74%）在同样的 400 道题上：

A：69.0%，95% 区间 [64.2%, 73.0%]
B：75.5%，95% 区间 [71.2%, 79.5%]   ← 两个区间重叠
配对：B − A = +6.5%，95% 区间 [+1.0%, +11.8%]
两个系统结论相同的题 292 道（对比较没有信息）；A 对 B 错 41 道，A 错 B 对 67 道；符号检验 p = 0.016

分别看两个区间，它们重叠，似乎”看不出差别”。但两个系统做的是同一批题：难题两个都错、容易题两个都对，这些题（292 道）对”谁更好”没有任何信息。配对地看每道题上的差，区间窄得多，而且不包含 0。

符号检验（McNemar 精确检验）只看结论不同的题：如果两个系统一样好，每道”分歧题”归 A 还是归 B 应该是一半对一半；41 比 67 偏离一半对一半的程度，用二项分布算出 p = 0.016。配对的设计是评估里的”免费午餐”：同样多的题，更灵敏的比较——前提是两个系统在同样的题、同样的顺序上评估，并且保存每道题的结果。

3.3 需要多少道题

演示 3：B 真的比 A 高 4 个点。用 n 道题、配对的符号检验（p < 0.05），有多大的把握检测出来（统计功效）？

题目数   检测出提升的比例（统计功效）
   100            5%
   200           19%
   400           28%
   800           52%
  1600           84%

100 道题时，几乎检测不出来——不是没有提升，是题太少。要有八成把握，需要上千道题。反过来说：在 100 道题的测试集上”提高了 2 个点”，几乎肯定是噪声。练习 2 显示，提升翻倍（8 个点）时，400 道题就有 83% 的把握——检测一半大小的效果，大约需要 4 倍的数据。做项目时，先想清楚你想检测多大的提升，再决定测试集要多大。

3.4 多重比较

演示 4：试了 20 个提示词，它们其实一样好（都是 70%）。在 200 道开发题上各评估一次，挑最好的那个和基线比较（重复 200 次这个”实验”）：

最好的提示词在开发题上比基线平均高 +5.1%；在新的测试题上 -0.1%
符号检验 p < 0.05 的比例：16%；Bonferroni 校正（p < 0.05 / 20）后：1%

挑出来的”最好的”在开发题上平均高 5 个点，在新的测试题上什么也没有——这就是第 12 讲的”赢家的诅咒”。试的东西越多，越容易碰到运气好的那一个。对策：在独立的测试集上确认（最可靠）；或者做多重比较校正，例如 Bonferroni：比较了 $k$ 次，就把显著性阈值除以 $k$。

3.5 从两两比较得到排名

Chatbot Arena（和 MT-Bench 同一篇论文发布）让用户对两个匿名模型的回答投票，用几十万次投票给模型排名。它用的是 Bradley-Terry 模型：每个模型有一个强度 $s_i$，

从所有的对战结果里估计 $s$（代码 02 用 MM 迭代算法），常常换算成类似国际象棋 Elo 的分数（$400 \log_{10} s$）。为什么不直接看胜率？演示 5：6 个系统、3,000 场对战，最强的两个系统大多和彼此对战：

系统     真实强度   场数   胜率   胜率排名   Bradley-Terry 分数   排名
系统 1      2.0    2193    62%       1              198           1
系统 2      1.6    2208    46%       3              134           2
系统 3      1.0     424    51%       2                5           3
系统 4      0.6     397    43%       4              -42           4
系统 5      0.3     402    35%       5             -103           5
系统 6      0.0     376    24%       6             -192           6

第二强的系统按胜率只排第三：它大部分场次都在和最强的系统打。Bradley-Terry 考虑了”和谁打”，恢复了正确的排序。

3.6 标注一致性

演示 6：两位标注员判断 400 个回答”是否有事实错误”，90% 的回答没有错误：

仔细的两位标注员      一致率 98%   碰巧一致的概率 80%   kappa 0.90
随便看看的两位标注员  一致率 85%   碰巧一致的概率 83%   kappa 0.11

随便看看的标注员一致率也有 85%——因为大多数回答都没错，两个人都说”没错”就一致了。Cohen’s kappa 扣除了”碰巧一致”：

$p_o$ 是实际的一致率，$p_e$ 是两个人各自按自己的比例随机标注时碰巧一致的概率。kappa 0.11 说明他们在真正重要的那 10%（有错误的回答）上几乎不一致。类别不均衡的标注任务，要报告 kappa，而不只是一致率。

4. 期末项目

4.1 项目的要求

项目的选题（从领域出发 vs 从技术出发）、建议的方向、提案的字段，第 3 讲第 8 节已经详细介绍过；时间安排和评分见第 1 讲第 8 节。这里补充几点：

• 两人一组，每周和导师见面；
• 可以使用任何工具，但必须使用最先进的工具和概念，不能只是把问题描述交给一个普通的 LLM。课程提供了 Agentic OS（AOS）作为基础设施：语义文件系统（CHURRO、SUQL、SLIDERS、SatIR）、知识策展（WikiChat、Co-STORM、DataTalk、DataSTORM、GRILL）、应用框架（Genie Worksheets、VERDICT）——这门课的每一讲都对应其中的一个组件；
• 课程的项目产出了很多论文：2023 年的 WikiChat；2024 年的 SUQL、STORM、SPAGHETTI、SPINACH、Co-STORM；2025 年的 Genie Worksheets、LEMONADE、CHURRO、维基百科的不一致检测等；2026 年的 SatIR、DataSTORM、VERDICT。你的项目可能是明年这张清单上的一行。

4.2 交付物

60 秒的展示意味着：你要能用一句话说清关键问题和主要结果。如果做不到，说明问题还没有想清楚。

4.3 评估方案模板

评估方案应该在项目开始时就写好，而不是做完系统再想怎样证明它好。下面是一个模板，把本讲和整门课的原则落到具体的问题上：

## 评估方案

### 1. 要证明的论断
- 主论断：在 ___（任务 / 数据）上，我们的系统比 ___（最强的基线）在 ___（指标）上好。
- 次要论断：___ 部件是必要的（消融）；成本 / 延迟在 ___ 以内。

### 2. 指标（为什么是这个指标？它和用途对应吗？）
- 主指标：___；怎样统计（按样例平均？按类别分开报告？）
- 辅助指标：___（例如成本、延迟、引用的正确率、校准）
- 如果用 LLM 评委：评委是哪个模型？评分标准？怎样验证（负对照、和人的一致率、交换顺序）？

### 3. 数据
- 开发集：___ 条，用来调提示词、调参数
- 测试集：___ 条，**只在最后用一次**；和开发集怎样隔开？
- 来源：真实的 / 合成的？有没有可能出现在模型的训练数据里（污染）？
- 标准答案：谁标的？标注规范？抽查过多少条？标注一致性（kappa）？

### 4. 基线（要强）
- 直接用最强的 LLM（加上合理的提示词）
- 最强的已发表的方法 / 现成的系统
- 简单的规则或检索基线

### 5. 消融
- 去掉 ___ 部件、换成 ___，各自的影响

### 6. 统计
- 想检测的最小提升：___ 个点 → 需要大约 ___ 条测试数据（第 3.3 节）
- 报告：置信区间（自助法）；和基线的配对比较（符号检验 / 配对自助法）
- 试了多少种设置？在独立的测试集上确认

### 7. 人工评估 / 用户研究（如果需要）
- 谁来评估？多少人？什么任务？评分维度和定义？
- 顺序和匿名化；伦理审查和知情同意

### 8. 错误分析
- 抽样多少个失败的例子？分类的类别？区分系统错误和标注错误

### 9. 局限与威胁
- 结论在什么情况下可能不成立？（数据分布、评委偏差、样本量）

4.4 常见的陷阱（自查清单）

• 基线是否足够强？（只和”直接问 GPT”比，说服力有限；也和”认真写了提示词的最强模型”比）
• 测试集有没有在开发过程中被看过、被调过？
• 结论是不是只建立在几个精挑细选的例子上？
• 有没有报告置信区间？差距是否大于噪声？
• LLM 评委验证过吗？交换顺序会改变结论吗？
• 标准答案抽查过吗？低分的样例里有多少是标注的问题？
• 系统有没有”给自己打分”？（例如用同一个模型生成和评判）
• 成本和延迟报告了吗？
• 失败的例子看过吗？论文里有没有诚实地讨论局限？

5. 本讲小结

1. 六条原则：指标对应用途；先检查标准答案；不让系统给自己打分；留独立的测试集；人在回路里；用统计说话。
2. 评估方式：有参考答案的自动指标（便宜但和”好不好”的相关性有限）；整体评估（HELM：准确率之外还有校准、鲁棒性、公平性、偏见、毒性、效率）；LLM 当评委（强评委和人的一致率超过 80%，和人与人相当，但有位置、长度、自我偏好的偏差，评判推理的能力有限）；模拟用户（适合开发阶段）；真实用户研究（最有说服力，要注意伦理、顺序效应、标注一致性）；错误分析。
3. 验证评委：负对照、和人比、测偏差、换评委、读理由。减轻位置偏差：交换顺序、两次一致才算赢（模拟：偏差大的评委从 59% 提高到 85% 的正确率）。打分用概率加权（G-Eval）。
4. 统计：自助法置信区间（区间宽度按 $1/\sqrt{n}$ 缩小，100 道题时约 ±9 个点）；配对比较和符号检验（同样的题，更灵敏）；统计功效（检测 4 个点的提升要上千道题）；多重比较（20 个其实一样的提示词，挑最好的看起来高 5 个点）；Bradley-Terry（考虑和谁对战）；Cohen’s kappa（扣除碰巧一致）。
5. 期末项目：评估方案在项目开始时就写好；交付物是提案、60 秒展示 + 海报、ACL 格式的论文、可运行的代码和演示。

6. 练习

练习 1（动手：位置偏差什么时候最严重）。把 01 号文件演示 1 的 gap 从 0.3 改成 1.0、2.0（两个回答的质量差得更多），两个评委前后一致的比例怎样变化？这对设计评估有什么启示？

实测：

质量差别越大，真实的差别越能压过位置偏差，结论越稳定。MT-Bench 论文也指出，它们的位置偏差测试特意用了两个非常相似的回答（同一个模型采样两次），这是最难的情况；在差别明显的情况下位置偏差没那么突出。启示：(1) 你最关心的比较往往恰恰是”两个系统差不多”的时候（例如消融），这时评委最不可靠，一定要交换顺序；(2) 报告”一致率”时要说明是在什么样的样例上测的。

练习 2（动手：效果的大小与样本量）。把 02 号文件演示 3 的真实提升从 4 个点改成 8 个点（70% → 78%），在 100、200、400、800 道题上的统计功效分别是多少？和 4 个点比较，你能总结出什么规律？

实测（300 次模拟）：

8 个点的提升在 400 道题上就有 83% 的把握检测出来，而 4 个点要 1,600 道题才到 84%（演示 3）。规律：要检测的效果减半，需要的样本量大约变成 4 倍——因为标准误差按 $1/\sqrt{n}$ 缩小。所以先估计你的方法大概能带来多大的提升，再决定测试集的规模；如果只能负担 200 道题，就只能可靠地检测出很大的提升。

练习 3（计算：区间宽度）。一个系统的准确率大约 70%。你希望 95% 置信区间是 ±2 个点（宽 4 个点），大约需要多少道测试题？用正态近似的公式算。

半宽 $1.96\sqrt{p(1-p)/n} = 0.02$，解得 $n = 1.96^2 \times 0.7 \times 0.3 / 0.02^2 \approx 2017$。大约需要 2,000 道题。对照演示 1：1,600 道题时区间宽 4.3 个点（±2.15），和这个估算一致。很多论文的测试集只有几百条，报告的”提高 1~2 个点”往往在误差范围之内——这也是为什么这门课的论文（例如 SPINACH）专门讨论数据集的规模和置信区间。

练习 4（思考：为你的项目写评估方案）。用第 4.3 节的模板，为你的项目（或者这门课里任意一个系统）写一份评估方案。特别回答：你的主指标是什么、为什么；最强的基线是什么；测试集多大、够不够检测你预期的提升；LLM 评委（如果用的话）怎样验证。

• 论断：在 30 个罕见病主题上，我们的系统写的报告比 OpenAI Deep Research 覆盖更多专家认可的关键事实，引用的正确率更高。
• 主指标：参考综述里提取的关键事实的召回率（参照第 11 讲”参考文章的标准匹配”）；辅助指标：引用支撑率（每句话是否被引用的文献支持）、成本、时间。
• 基线：OpenAI Deep Research；最强的 LLM + 网页搜索；作业 1 的 RAG 基线。
• 数据：30 个主题，每个有一篇专家写的综述；开发集 10 个、测试集 20 个；综述的发表日期晚于系统检索的截止日期，防止泄漏（第 2、11 讲）。
• LLM 评委：抽 50 条”关键事实是否被报告覆盖”的判断请两位医学生标注，计算评委和人、人和人的一致率与 kappa；交换顺序测试；负对照（拿另一个疾病的报告去评）。
• 统计：20 个主题太少，主题级别的比较只能检测很大的差别；所以在关键事实级别（几百条）做配对比较，用自助法（按主题重抽样，因为同一主题内的事实是相关的）。
• 错误分析：抽 30 个漏掉的事实，归类为”没检索到""检索到了没读出来""读出来了没写进报告""标准答案有误”。

练习 5（思考：什么时候可以只用 LLM 评委）。列出两种你认为”只用 LLM 评委就够了”的情况，和两种”必须有人工评估”的情况，说明理由。

只用 LLM 评委可能就够了：(1) 开发阶段的快速迭代：比较两个提示词版本，评委已经用人工标注验证过、交换顺序后结论一致，而且最终结论还会用人工确认；(2) 评委有可靠参考的判断：例如”这个回答是否包含参考答案里的这个事实""这句话是否被这段证据支持”——任务窄、有依据，评委的准确率可以单独测出来（第 5 讲的声明核查）。

必须有人工评估：(1) 最终的主要结论，尤其是对外发表的结论；以及涉及高风险领域（医疗、法律）的判断——评委的系统性错误会直接变成你的结论；(2) 评委本身可能有偏差的情况：被评估的系统和评委是同一家族的模型（自我偏好）、比较的两个系统长度差别很大（长度偏差）、任务需要评委不具备的专业知识或推理能力（数学、罕见病）、以及”新闻价值""原创性”这类主观的、和目标用户紧密相关的维度（DataSTORM 请了新闻工作者）。

7. 延伸阅读

课程阅读清单（Evaluation of LLMs）

• Liang 等. Holistic Evaluation of Language Models（HELM）. 2022.
• Gehrmann、Clark、Sellam. Repairing the Cracked Foundation: A Survey of Obstacles in Evaluation Practices for Generated Text. 2022.
• Zheng 等. Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena. NeurIPS 2023. arXiv 2306.05685.
• Liu 等. G-Eval: NLG Evaluation using GPT-4 with Better Human Alignment. EMNLP 2023. arXiv 2303.16634.

统计与评估实践

• Efron & Tibshirani. An Introduction to the Bootstrap. 1993.
• Dror 等. The Hitchhiker’s Guide to Testing Statistical Significance in Natural Language Processing. ACL 2018.
• Card 等. With Little Power Comes Great Responsibility. EMNLP 2020（NLP 实验的统计功效）。
• Bradley & Terry. Rank Analysis of Incomplete Block Designs. 1952；Chiang 等. Chatbot Arena. 2024.
• 课程的项目说明页：项目的方向、提案模板、期末论文的结构、往年项目发表的论文。

8. 结语

回到第 1 讲的问题：LLM 会幻觉，怎样把它变成可靠的智能体？ 十五讲下来，这门课的答案可以概括成几句话：

• 分解：把问题拆成 LLM 能可靠完成的小任务（阅读、比较、改写、翻译、写查询），把它不擅长的交给程序、检索、数据库、求解器、运行时（第 1、3、4、6~10 讲）；
• 结构化：把文本变成数据库（SLIDERS），把对话变成形式化的状态（Genie），把规则变成逻辑公式（VERDICT），把开放的研究变成论点驱动的分析（DataSTORM）；
• 核查：用证据、执行、测试、定理证明器去验证 LLM 的输出，而不是相信它（第 4、5、12 讲）；
• 数据与训练：在系统做对之后，用专门的数据和蒸馏让它更快、更便宜、可以部署（第 13、14 讲）；
• 评估：系统地、诚实地评估，人在回路里，用统计说话（第 15 讲）。

每一讲的代码都用一个”会犯错的模拟 LLM”演示了这些想法——真实的 LLM 犯错的方式更多样、更难预测，这正是这些方法存在的理由。祝你的项目顺利。