Lecture 17 · 评估提示系统与课程项目 · Evaluating Prompt-Based Systems & Projects

对应 Maps to：CMU 17-630 Prompt Engineering（Prof. Travis Breaux），第 13–14 周 · Project Presentations，以及原课 syllabus 里关于提示工程的 benchmark、评估指标和指标设计新做法的内容。 依据说明：原课第 13–14 周是项目展示，syllabus 说明课程项目在学期中提出、每两周汇报一次进度、期末提交报告并展示，项目要组合多种提示策略构建一个更大的系统；syllabus 的学习目标里有”设计实验来评估提示设计、优化提示的表现”。这一讲把”怎样评估一个基于提示的系统”系统地讲一遍（§1–§5），再讲课程项目怎样选题、写提案、汇报、写报告和展示（§6），最后回顾全课（§7）。材料来自 Liang et al.（2022，HELM）、Chiang et al.（2024，Chatbot Arena）、Zhang et al.（2024，GSM1k）、Sclar et al.（2024，FormatSpread）、Liu et al.（2023，G-Eval）、Miller（2024，Adding Error Bars to Evals）、Kapoor et al.（2024，AI Agents That Matter）等；引用的数字都核对过原文。项目部分的模板和建议是讲义自己写的，不代表原课的具体要求——以课程实际发布的要求为准。 配套代码 Code：code/lecture17/（只用 Python 标准库；1 个模块 + 6 个脚本；不需要 API key；每个脚本 2 秒以内） 预计阅读时间：3 小时（含运行代码）

0. 本讲导航 · How to read this lecture

0.1 学习目标 Learning goals

学完这一讲，你应该能够：

1. 说出 benchmark 的几种类型和三个常见隐患：污染、饱和、对格式的依赖；知道怎样检查和缓解。
2. 为一个任务选择和设计指标：答案抽取、精确匹配 / 包含 / F1、基于执行的指标、基于模型的指标（裁判、评分细则），以及成本和延迟；知道每种指标在什么情况下会骗人。
3. 设计并执行一个完整的提示实验：写下假设、按题组划分开发 / 测试集、用功效分析定样本量、多次采样、配对比较、聚类的区间、多重比较校正、按成本比较，并写出报告。
4. 理解成对比较的排名（Bradley–Terry）和它的不确定性。
5. 为课程项目写出提案、进度报告和期末报告，避免最常见的评估错误。

0.2 先修与本讲范围 Prerequisites & scope

这一讲是全课的收尾，会用到前面几乎所有的内容；最直接的是：

0.3 本讲地图 Map

§1  benchmark：类型与隐患（污染、饱和、格式）                      ← 代码 03
§2  指标设计：抽取、匹配、执行、裁判、评分细则；成本与延迟           ← 代码 02、05
§3  一个完整的提示实验流程                                        ← 代码 01、04
§4  成对比较与排名                                               ← 代码 05
§5  在真实模型上                                                 ← 代码 06（可选）
§6  课程项目：选题、提案、进度、报告、展示
§7  全课回顾
§8  小结   §9 常见误区   §10 练习   §11 延伸阅读   §12 结语

0.4 本讲的实验装置 · The setup

promptexp.py   一个可以复用的提示实验框架：数据（按题组）、提示变体、运行（任何 LLM）、答案抽取与指标、
               按题组聚类的区间、配对比较 + Holm、成本、Markdown 报告；
               SimTaskLLM：按提示文字决定行为的模拟模型（能力、思维链加成、把答案包进句子、啰嗦、记忆、格式敏感）

模拟模型的每种行为都是显式的旋钮；代码演示的是评估方法会在哪里骗人。做课程项目时，把 SimTaskLLM 换成真实的模型，框架的其余部分可以直接用（代码 06）。

1. Benchmark：类型与隐患 · Benchmarks

1.1 几种 benchmark

Chatbot Arena 的论文用两个维度给 LLM 的 benchmark 分类：题目来自固定的数据集还是不断更新的来源；评判依据标准答案还是（近似的）人类偏好。

对一个基于提示的系统来说，最有用的往往不是公开 benchmark，而是你自己任务上的评估集：从真实的使用场景里收集输入、写好参考答案或评判标准。公开 benchmark 的作用是做对照、检查你的方法是否在别的地方也成立。

1.2 三个隐患

污染（contamination）：模型在训练中见过考题，分数混合了”会做”和”见过”。GSM1k（Zhang et al. 2024）请人重新写了 1000 道和 GSM8K 在风格、难度、步数、答案大小上都对齐的题：一些模型掉了多达 8 个百分点，有几个模型家族几乎在所有规模上都系统性地过拟合；模型生成 GSM8K 原题的概率和它在两套题上的分数差正相关（Spearman r² = 0.36）。同时，很多模型（尤其是最前沿的）几乎没有过拟合的迹象，所有模型都能推广到新题。

代码 03 演示 1：五个模型分别见过 0%–45% 的公开题，公开基准和新写的同风格题的分数差从 −1.2 到 +9.2 个点；“能逐字补全题目”的比例和这个差距高度相关。对策：自己写一小批新题（哪怕几十道）和公开集对照；检查模型能不能逐字补全题目；优先使用发布时间晚于模型训练截止日期的题（不断更新的 benchmark）。

饱和（saturation）：所有模型都接近满分时，benchmark 什么也区分不了。代码 06 的提醒：强模型在简单的两步应用题上可能三个提示变体都接近满分——这时要换更难的题，否则”没有差别”只是天花板效应。

对格式的依赖：FormatSpread（Sclar et al. 2024）发现几个常用的开源模型在少样本设定下对意思不变的格式变化（分隔符、大小写、空格）极其敏感，LLaMA-2-13B 上相差可达 76 个百分点；加大模型、增加示例、做指令微调之后敏感性依然存在；而且不同模型的格式表现只弱相关——用一个任意选定的格式比较模型，结论的有效性值得怀疑。他们建议报告一组合理格式上的分数范围。

代码 03 演示 2：12 种排版（“Question:” / “Q:” / “QUESTION:“，换行或空格，“Answer:” 或 “A:“）下，model-X 的分数在 45.0%–74.2% 之间，model-Y 在 42.9%–85.4% 之间；X 在 12 种格式里赢了 6 种，两个模型各格式分数的相关系数只有 0.17。选哪种格式，可能决定”谁更好”。（第 2 讲的标签偏差和示例顺序、第 16 讲道德评估的选项顺序，都是同一类问题。）

1.3 不只测准确率：HELM

HELM（Liang et al. 2022）的出发点是：只看准确率，会让其他重要的性质被忽略。他们在 16 个核心场景上，尽可能地同时测 7 种指标——准确率、校准、鲁棒性、公平性、偏见、毒性、效率——评估了 30 个模型；在此之前，这些模型平均只在 17.9% 的核心场景上被评估过（有些知名模型之间连一个共同的场景都没有），HELM 把它提高到 96.0%。HELM 的价值不在于给出一个总排名，而在于把权衡摆出来。

2. 指标设计 · Metric design

2.1 先想清楚：你在乎的到底是什么

同一批输出，换一个指标，“谁更好”就可能变。代码 02 演示 1（240 道题 × 4 个提示变体）：

五种指标给出了五种不同的排名。差别来自格式：plain 常把答案包进一句话（“The answer is X.”），expert 常加一句开场白，思维链的答案在最后一行。精确匹配惩罚格式，包含匹配只看内容。

选择指标的问题是：下游怎样使用这个输出？ 如果一个程序要直接读答案，格式就是正确性的一部分，精确匹配是对的；如果关心的是模型知不知道，就应该先抽取答案、再用对格式宽容的指标。两种情况都要做的一件事：随机看 20–50 个输出，确认指标的判断和人的判断一致。

2.2 答案抽取

思维链输出的原始精确匹配是 0.000，抽取 “Answer:” 之后是 0.821（代码 02 演示 3）。很多”换了提示之后模型变差了”，其实是”答案抽取的规则没跟上新的输出格式”。实践：

• 在提示里规定输出格式（最后一行 Answer: ...，或者 JSON——第 8 讲的结构化输出）；
• 评估代码里写一个宽容但明确的抽取函数，并单独统计”抽取失败”的比例——抽取失败本身就是一种失败，不应该悄悄算成答错，也不应该悄悄跳过；
• 精确匹配之前先规范化（小写、去标点、去冠词、合并空白——SQuAD 的做法），数值答案按数值比较。

2.3 几类指标

基于模型的指标：G-Eval（Liu et al. 2023）让 GPT-4 按评价维度的定义，先生成评价步骤（思维链）、再以填表的方式打分；在 SummEval 摘要评测上，它和人的 Spearman 相关是 0.514，高于 ROUGE 等基于参考答案的指标。但裁判的偏差仍在：代码 02 演示 2，同样是答对的回答，裁判给 terse（平均 5 个字符）4.20 分、expert（45 个字符）4.41 分、思维链（104 个字符）4.57 分——裁判偏爱更长的回答。

写一份好的评分细则（rubric）：

1. 把”好”拆成几个可以独立判断的维度（正确性、完整性、是否引用了来源、格式、语气），每个维度单独打分；
2. 每个分数档写出可观察的标准（“给出了正确的最终数字，并且没有引入错误的中间步骤” 而不是 “回答得很好”）；
3. 每个档给一两个例子（第 2 讲：示例比描述更能约束模型）；
4. 有标准答案就给裁判看标准答案；
5. 要求裁判先写理由再打分；交换顺序、控制长度（第 10 讲）；
6. 用一小批人工标注（几十个）检验裁判和人的一致性，报告一致率或相关系数。

2.4 成本和延迟也是指标

一个准确率高 2 个点、但贵 5 倍的提示，是不是”更好”，取决于你的用途。代码 05 演示 1 比较了七种做法：

“大模型 · 思维链”不在帕累托前沿上：级联比它更准、也更便宜。报告结果时，把准确率和成本画在同一张图上，标出前沿。

Kapoor et al.（2024，“AI Agents That Matter”）对智能体 benchmark 的批评值得每个项目记住：在 HumanEval 上，几个简单的基线（失败就重试、逐渐升高温度重试、先用便宜的模型再升级）和当时最好的智能体架构在准确率上没有显著差别；准确率相近的做法，成本可以差将近两个数量级；但成本几乎从来不是论文报告的主要指标。他们还指出很多智能体 benchmark 没有足够的留出集，导致智能体走捷径、过拟合到 benchmark。

3. 一个完整的提示实验流程 · An end-to-end experiment

3.1 流程

1. 写下问题和假设（预注册）：比较什么、主要指标是什么、用什么检验、什么结果算支持假设
2. 准备数据：按题组划分开发集 / 测试集；用功效分析定测试集的大小；必要时准备一份新写的题
3. 在开发集上迭代：随便看、随便改，记录试过的每个变体
4. 冻结：选定要比较的变体、指标、抽取规则
5. 在测试集上只跑一次：多次采样（或说明为什么只采一次），缓存和日志都保留
6. 分析：配对比较、聚类的区间、多重比较校正、按子集拆开、成本
7. 报告：设定、数字、区间、成本、试过多少个变体、失败的例子、局限

代码 01 把这个流程完整地走了一遍（240 道题、60 个题组、4 个提示变体、3 个种子），测试集上的报告：

（三个比较在 Holm 校正后都显著。）脚本把这份报告写成 Markdown，就是项目报告”结果”一节的骨架。

3.2 几个关键的细节

按题组划分，按题组算区间。同一篇文章的几个问题、同一个模板生成的几道题、同一个用户的几轮对话，结果是相关的。把一组拆到开发集和测试集两边，开发集上调出来的东西会通过”近亲”泄露到测试集；把它们当独立的题算标准误，区间会过窄。代码 01 演示 4：聚类的标准误是朴素标准误的 1.13–1.39 倍。

配对比较。两个提示在同一组题上测，结果高度相关（难题大家都错）。在题目层面做配对的推断（McNemar、配对 bootstrap），比各算各的区间再看重不重叠要灵敏得多（前置讲 P3）。

按子集拆开。代码 01 演示 3：用主要指标看，思维链在事实题上也”提升”了 32 个点；换成不受格式影响的包含匹配，事实题上的差是 −0.010，应用题上是 +0.257——事实题上的”提升”全是格式。只报告一个总分、只看一个指标，都会掩盖这一点。

事先选定一种主要的检验。小样本时，不同的检验可能给出不同的结论（代码 06 的 --toy 模式里，一个差值的配对 bootstrap 区间不含 0，但 McNemar p = 0.065）。事先写下用哪一种，事后不要挑。

Miller（2024，“Adding Error Bars to Evals”）把评估当作实验来分析，建议：用中心极限定理算均值的标准误；题目成组出现时算聚类的标准误；通过对答案多次采样（或分析下一个 token 的概率）减少方差；比较两个模型时在题目层面的配对差值上做推断；用功效分析判断一个评估能不能检验你关心的假设。

3.3 分岔小径

在同一个测试集上试很多个提示、挑最好的报告，几乎总能得到一个”显著”的提升（第 10 讲的赢家诅咒）。代码 04 演示 1：40 个措辞不同、但没有任何真实差别的提示，在同一份 240 道题上的准确率从 62.5% 到 71.7%；如果基线恰好是最差的那个，挑出来的”最好提示”看起来高 9.2 个点。这次挑出来的提示比基线高 2.9 个点，到一份新的题上是 −0.8 个点——回到了噪声里。

对策：开发集上随便试，测试集上只跑事先选定的变体；报告试过多少个变体；多个比较做校正；重要的结论在新数据上复现。

3.4 要多少道题：功效分析

需要的题数大致和 $\psi/\Delta^2$ 成正比（$\Delta$ 是真实的准确率差，$\psi$ 是两个提示结果不一致的题的比例）。代码 04 演示 2（配对 McNemar，α = 0.05，功效 80%）：

差别减半，题数要翻四倍。想检验 3–5 个点的提升，几百道题常常不够；只有几十道题的评估，只能发现很大的差别——没发现差别，不等于没有差别。做法：先跑一个小规模的预实验估计 ψ，再用公式算正式实验需要多少道题（前置讲 P3 的 n_paired_mcnemar）。

3.5 报告清单

一份可以被别人复现和信任的评估报告，至少包括：

• 模型：名称、版本（或快照日期）、调用日期、关键参数（温度、最大 token、思考 / effort 设置）；
• 提示：完整的提示文字（放附录）、试过多少个变体、怎样选出来的；
• 数据：来源、规模、怎样划分、是否可能被训练数据见过；
• 指标：定义、答案抽取规则、抽取失败率；裁判的话，给出评分细则和与人工的一致性；
• 结果：均值、置信区间（说明怎样算的）、配对比较、多重比较校正；按重要子集拆开；
• 成本：每题的 token、美元、延迟；
• 错误分析：分类统计失败的类型，附代表性的例子（不只挑好看的）；
• 局限：样本量、模拟 / 真实、可能的污染、格式敏感、可能不成立的场景。

4. 成对比较与排名 · Pairwise comparison and rankings

开放式任务（写作、对话、建议）没有标准答案，常用成对比较：把两个系统对同一个输入的回答放在一起（隐去来源、随机顺序），让人或模型选更好的那个。

Chatbot Arena（Chiang et al. 2024）把这件事做成了一个开放平台：用户提出问题，两个匿名模型作答，用户投票（论文写作时已经有超过 24 万张票）；用 Bradley–Terry 模型从投票中估计每个模型的强度——$P(i \text{ 胜 } j) = \frac{e^{s_i}}{e^{s_i} + e^{s_j}}$——并给出置信区间（他们从在线更新的 Elo 改成了 Bradley–Terry 系数）。

代码 05 演示 2：6 个模型，真实强度已知，模拟成对投票后拟合 Bradley–Terry，并用 bootstrap 估计区间和名次范围。300 张票时，强度接近的几个模型在 bootstrap 里名次从第 1 到第 4 来回翻；3000 张票时区间窄了很多。排行榜上名次相邻、区间重叠的模型，不应该被解读为”一个比另一个好”。

成对比较也有它的偏差：投票的人和问题不一定代表你的用户和任务；回答的长度和格式会影响偏好（§2.3 的裁判偏差在人身上也有）。在自己的项目里做人工成对评估时：盲评、随机化左右顺序、每对至少两个人评、报告标注者之间的一致性（例如 Cohen’s κ）。

5. 在真实模型上 · On a real model

06_real_llm.py 用同一个框架评估真实的 Claude：40 道程序生成、答案确定的两步应用题（框架里的虚构国家事实题对真实模型没有意义），3 个提示变体（plain / terse / cot），生成和代码 01 一样格式的报告（results/06_report.md）。120 次调用，预算上限 1.00 美元。编写讲义时环境里没有安装 anthropic SDK，所以这里不报告真实模型的数字。两个提醒：40 道题只能发现很大的差别——先用它估计 ψ，再决定正式实验要多少道题；强模型可能三个变体都接近满分，那就换更难的题。

6. 课程项目 · Course project

原课的 syllabus 对项目的描述（意译）：学期中提出项目，之后每两周汇报一次进度，期末提交报告并做展示；项目要把课上学到的多种提示策略组合起来，构建一个更大的系统。下面是讲义给出的建议和模板——具体要求以课程实际发布的为准。

6.1 选题

好的项目题目通常满足四个条件：

1. 任务真实：有一个具体的用户和场景（“帮助研究生在课程论坛上找到已经回答过的问题”），而不是”让模型更聪明”；
2. 输出可以检查：有标准答案、可以运行的测试、可以核对的来源，或者至少能写出清楚的评分细则；
3. 有一个简单的基线：单次调用、零样本，或者一个非 LLM 的方法（关键词搜索、规则）；
4. 需要组合多种策略：只靠一个提示做不好，需要检索、工具、分解、验证、多次采样或多个智能体中的几种。

一些可以从课上内容出发的方向：

6.2 提案（一到两页）

1. 问题：谁、在什么场景下、需要什么；为什么现有做法不够
2. 数据：从哪里来、多少条、怎样标注；按什么分组；有没有被模型见过的风险
3. 基线：最简单的做法是什么
4. 提出的系统：组合哪些策略（画一张流程图），每一步的输入输出
5. 指标：主要指标（一个）和次要指标；答案怎样抽取；成本怎样记
6. 假设：例如 "加入检索和自我验证后，忠实性比基线高至少 10 个点，成本不超过 3 倍"
7. 规模和预算：预实验估计的 ψ、需要多少条测试数据、预计多少次调用、多少钱
8. 风险和备选：数据拿不到怎么办、模型已经接近满分怎么办

6.3 双周进度汇报

每次汇报回答四个问题：做了什么（附带区间的数字）、失败的例子是什么样的（分类统计）、下一步做什么、有什么需要帮助的。不要只报告开发集上最好的数字；说明试过多少个变体。

6.4 期末报告的结构

摘要        一段话：问题、方法、主要结果（带区间和成本）
1 引言      问题和动机；贡献
2 相关工作   课上的哪些方法、相关论文
3 系统      流程图；每个组件的提示（完整文字放附录）
4 实验设定   数据（来源、划分、规模）、基线、变体、指标、统计方法、模型版本和日期
5 结果      主表（均值、区间、配对比较、成本）；按子集拆开；准确率—成本图
6 错误分析   失败的分类统计 + 代表性例子
7 局限与伦理  样本量、模拟 vs 真实、污染风险、隐私、可能的误用
附录         完整的提示、评分细则、额外的结果、复现说明（代码、种子、缓存）

代码 01 生成的 Markdown 报告可以直接作为第 5 节的起点。

6.5 展示

• 用一个具体的例子开场：一个输入，基线怎样失败，你的系统怎样做对；
• 一张主图：准确率—成本（或主要指标的配对差值和区间）；
• 讲清楚一个你学到的、出乎意料的东西（一个没有效果的改进、一个隐藏的偏差）；
• 诚实地讲局限；
• 如果做现场演示，准备好录屏作为后备。

6.6 最常见的问题

1. 没有基线，或者基线太弱（没有试过”把同样的调用次数花在 self-consistency 上”）；
2. 在测试集上调提示；
3. 只跑一次、只报一个数字，没有区间；
4. 只看一个指标，没有人工检查输出；
5. 不报成本；
6. 只展示好看的例子；
7. 测试集太小，“没有显著差别”就下结论说”没有差别”。

7. 全课回顾 · Looking back

课程大纲开头列了五条主线，这里看看每条在哪几讲里出现过：

1. 提示 = 给一个条件分布设定条件。第 1 讲从 n-gram 到迷你 GPT 建立这个直觉；第 2 讲的上下文学习、第 3 讲的指令、第 5 讲的校准、第 14 讲的角色，都是在调节这个条件分布；第 16 讲提醒我们，提示和微调调节的是行为的表现。
2. 模型从哪里来，决定了提示怎样起作用。base 模型续写文档（第 1 讲），指令微调后遵循指令（第 3 讲），RLHF 之后讨好用户（第 6 讲），推理模型把搜索训练进了模型（第 13 讲）。
3. 一次调用不够，就分成多次。思维链（第 4 讲）、检索（第 7 讲）、工具（第 8 讲）、分解（第 9 讲）、自我验证（第 10 讲）、代码执行（第 11 讲）、规划与校验器（第 13 讲）、智能体循环与记忆（第 14 讲）、多智能体（第 15 讲）——每一种都是在阶段之间加入外部信息或检查。贯穿其中的结论是：能从外部得到可靠的反馈时，多阶段才真正有效。
4. “这个提示更好”是一个需要实验证明的论断。前置讲 P3 打了统计基础；第 2 讲的示例顺序、第 10 讲的赢家诅咒、第 14 讲的角色效应、第 15 讲的同等成本比较、第 16 讲的测量偏差，最后在这一讲整理成一个流程。
5. 可靠 ≠ 准确。幻觉（第 5 讲）、偏见和谄媚（第 6 讲）、注入攻击（第 12 讲）、欺骗（第 16 讲）——平均准确率之外的失败，需要专门的评估和纵深的防御。

8. 小结 · Summary

1. Benchmark 有三个隐患：污染（用新写的同风格题对照，GSM1k）、饱和（换更难的题）、对格式的依赖（报告一组格式上的范围，FormatSpread）。HELM 提醒我们同时看多种指标。
2. 指标：先想清楚下游怎样使用输出；先抽取答案、规范化；匹配、执行、裁判、人工各有适用的场合；裁判要有评分细则并用人工校验；成本和延迟也是指标，画准确率—成本的帕累托前沿。
3. 实验流程：写下假设 → 按题组划分 → 功效分析定规模 → 开发集上迭代 → 冻结 → 测试集上只跑一次 → 配对比较、聚类区间、多重比较校正、按子集拆开 → 带成本和局限的报告。
4. 分岔小径会制造虚假的提升；报告试过多少个变体，在新数据上复现。
5. 成对比较用 Bradley–Terry 估计强度和区间；区间重叠的名次不应该被过度解读。
6. 课程项目：真实的任务、可以检查的输出、简单的基线、多种策略的组合；提案、进度、报告、展示都围绕带区间、带成本、诚实的数字。

9. 常见误区 · Common pitfalls

1. “在公开 benchmark 上提高了，就是方法有效。” 可能是污染、可能是格式、可能是在测试集上调出来的。
2. “精确匹配最客观。” 它也惩罚格式；先抽取答案，再决定格式算不算正确性的一部分。
3. “LLM 裁判和人差不多，可以直接用。” 要有评分细则、交换顺序、控制长度，并用人工标注校验。
4. “每道题跑三次，样本量就是三倍。” 同一道题的三次结果是相关的；先对种子平均，再按题（和题组）算区间。
5. “两个区间重叠，所以没有差别。” 不配对的区间重叠不说明什么；在同一组题上做配对比较。
6. “差别不显著，所以两个提示一样好。” 可能只是题太少；先做功效分析。
7. “新的提示准确率高 3 个点，就用它。” 看成本、看延迟、看它在哪类题上提高、看试了多少个才挑出它。
8. “报告一个格式下的结果就够了。” 换一种合理的格式，结论可能反过来。

10. 练习 · Exercises

练习 1（计算）　你预计新提示比基线高 5 个百分点，预实验里两个提示结果不一致的题约占 20%。（a）配对 McNemar 检验（α = 0.05，功效 80%）大约需要多少道题？（b）如果真实的提升只有 2.5 个点呢？（c）你只有 150 道题，怎么办？

参考答案：（a）用 $n = (z_{0.975}\sqrt{\psi} + z_{0.8}\sqrt{\psi - \Delta^2})^2/\Delta^2$：$(1.96 \times 0.447 + 0.842 \times 0.444)^2 / 0.0025 \approx 1.564 / 0.0025 \approx 626$ 道（n_paired_mcnemar(0.05, 0.2) 给出 626）。（b）差别减半，题数约翻四倍：2510 道。（c）150 道题只能可靠地发现很大的差别（大约 10 个点以上）。可以：扩充测试集（自己写、或者从真实使用中收集）；对每道题多次采样以减少方差（Miller 2024）；把问题改成”新提示是否不差于基线”之类更适合小样本的问题；或者如实报告”在这个规模上检测不到小于约 X 个点的差别”。

练习 2（解释）　你的评估集有 50 篇文章、每篇 4 个问题，共 200 题。同事按 200 道独立的题算了 95% 区间 ±5.6 个点。（a）为什么这个区间可能过窄？（b）怎样修正？（c）划分开发 / 测试集时要注意什么？

参考答案：（a）同一篇文章的 4 个问题结果相关（文章难，几个问题都容易错），有效的独立样本数介于 50 和 200 之间；把它们当独立的题，标准误被低估了。（b）按文章算聚类的标准误（promptexp.cluster_ci 的公式，Miller 2024），或者按文章做 bootstrap（每次重抽文章，带着它的 4 个问题一起）；代码 01 里聚类的标准误是朴素的 1.13–1.39 倍。（c）按文章划分：同一篇文章的问题要么全在开发集、要么全在测试集，否则开发集上针对某篇文章调出来的东西会泄露到测试集。

练习 3（设计）　你在做一个”从邮件里抽取会议信息（时间、地点、参会人、议题）成 JSON”的系统。设计它的指标体系：主要指标、次要指标、成本指标，以及怎样处理”输出不是合法的 JSON”。

参考答案（一种可能）：主要指标：字段级的准确率（每个字段规范化后精确匹配：时间统一成 ISO 格式和时区，参会人按集合比较），再报告”整条记录全对”的比例（下游通常需要整条都对）。次要指标：JSON 合法率（单独报告，第 8 讲）；每个字段的召回 / 精确率（参会人可能漏、可能多）；对”邮件里根本没有会议”的样本，误报会议的比例。处理不合法的 JSON：先尝试一个明确的、有限的修复（例如去掉 Markdown 代码块标记），修复失败就算这条全错，并单独统计失败率——不要悄悄跳过。成本：每封邮件的 token、美元、延迟；如果用了”失败就重试”，报告平均重试次数。数据按发件人或线程分组，按组划分开发 / 测试集。

练习 4（动手）　在 03_contamination_format.py 的演示 2 里，把两个模型的 format_sd 从 0.35 改成 0.15 和 0.0，重新运行。分数范围和”谁更好”的结论怎样变？为什么 format_sd = 0 时仍然有差别？

参考答案：编写讲义时：format_sd = 0.35 / 0.15 / 0.0 时，model-X 的范围是 45.0%–74.2% / 55.0%–70.4% / 63.3%–68.3%，model-Y 是 42.9%–85.4% / 56.7%–79.6% / 64.2%–72.1%；12 种格式里 X 赢 6 / 5 / 3 种。即使没有系统性的格式效应（0.0），每种格式下的分数仍然有约 5–8 个点的范围，较弱的 X 仍然在 3 种格式下”赢”：模拟器里换一个提示文字，边界题的随机结果也会变（真实模型也是这样），240 道题上的抽样误差本身就有几个点。所以即使模型对格式不敏感，用单一格式、单次运行比较两个接近的模型，也可能得出相反的结论——要么报告多个格式的平均和范围，要么增加题数和采样次数。

练习 5（批判）　一份项目报告写道：“我们的多智能体 RAG 系统在我们收集的 60 个问题上准确率 83%，基线（单次调用）70%，提升 13 个点。我们尝试了多种提示设计，最终方案效果最好。“指出至少五个问题，并说明你希望看到什么。

参考答案：（1）没有区间：60 道题上 83% 的 95% 区间大约是 ±10 个点；（2）没有配对比较：应该在同一组题上报告配对差值和 McNemar / 配对 bootstrap；（3）“尝试了多种提示设计，最终方案最好”——在哪个集合上选的？如果在这 60 道题上选，就是分岔小径；应该说明试了多少个、在开发集上选、在独立的测试集上报告；（4）没有成本：多智能体 RAG 每题多少次调用、多少钱、多长延迟？基线如果用同样的预算做 self-consistency 呢？（5）准确率怎样判定？精确匹配、裁判，还是人工？答案抽取规则？裁判的话和人工一致性如何？（6）没有错误分析：剩下 17% 错在检索、阅读还是推理？（7）没有消融：多智能体和 RAG 各贡献了多少？希望看到：开发 / 测试划分、主表（均值 + 区间 + 配对差值 + 成本）、消融、错误分类、试过的变体数、完整提示在附录。

练习 6（设计）　按 §6.2 的模板，为”一个帮助学生在课程论坛发帖前找到已有答案的助手”写一份项目提案的要点（每一项一两句话）。

参考答案（一种可能）：（1）问题：课程论坛里很多新帖和旧帖重复，助教重复回答；学生发帖前很难搜到。（2）数据：往届论坛的 N 个帖子（征得同意、去掉个人信息），人工标注 200 对”新帖—已有答案”的匹配；按学期分组，用较早的学期开发、最近一个学期测试（也降低被模型见过的风险）。（3）基线：论坛自带的关键词搜索（BM25）。（4）系统：查询改写 → 混合检索（第 7 讲）→ LLM 判断”已有答案是否真的回答了这个问题”并给出引用 → 不确定时说”没有找到，建议发帖”（拒答，第 5 讲）。（5）指标：主要是 top-3 中包含正确旧帖的比例；次要是给出的答案是否忠实于引用（人工 + 评分细则）、错误地声称”已有答案”的比例；成本和延迟。（6）假设：系统的 top-3 命中率比 BM25 高至少 10 个点，误报率不超过 5%，每次查询不超过 0.01 美元。（7）规模：预实验 50 对估计 ψ，用功效分析确定测试集（大约几百对）；预算上限若干美元。（8）风险：标注不够 → 用往届的”重复帖”标记作为弱标签；隐私 → 只用公开帖、去标识化。

11. 延伸阅读 · Further reading

Benchmark 与评估框架

• Liang et al. (2022). Holistic Evaluation of Language Models（HELM）. TMLR 2023.
• Chiang et al. (2024). Chatbot Arena: An Open Platform for Evaluating LLMs by Human Preference. ICML.
• Zhang et al. (2024). A Careful Examination of Large Language Model Performance on Grade School Arithmetic（GSM1k）.
• Sclar et al. (2024). Quantifying Language Models’ Sensitivity to Spurious Features in Prompt Design（FormatSpread）. ICLR.

指标与统计

• Liu et al. (2023). G-Eval: NLG Evaluation using GPT-4 with Better Human Alignment. EMNLP.
• Miller (2024). Adding Error Bars to Evals: A Statistical Approach to Language Model Evaluations.
• Kapoor et al. (2024). AI Agents That Matter.

回顾前面几讲的评估相关内容：前置讲 P3（统计）、第 2 讲（示例与格式）、第 10 讲（LLM 当裁判）、第 11 讲（基于执行的评估）、第 16 讲（评估设计的陷阱）。

12. 结语 · Closing

这门课从”语言模型是一个条件分布”开始，经过上下文学习、指令、推理、对齐、检索、工具、分解、自动提示、代码、安全、规划、智能体、多智能体和超级对齐，最后回到一个朴素的问题：你怎么知道它真的更好？

提示工程的技巧会随着模型更新而过时——今天必须写的思维链，明天的推理模型可能自己就会；今天有效的措辞，换一个模型可能没用。不会过时的是这门课反复练习的几种能力：理解模型从哪里来、为什么这样表现；把一个任务拆成可以检查的步骤，在步骤之间引入可靠的外部反馈；以及用诚实的实验——带区间、带成本、在没见过的数据上——证明一个改进是真的。