2. 评估的 5W1H：何时、何地、给谁、为什么评估

2.1 本章目标与读者

读完后你能：

• 画出评估在 LLM 全生命周期中的 8 个调用点，说出每个点的频率、规模与决策影响
• 区分模型层评估与应用层评估，并解释为什么同一个模型两层分数可能相反
• 用 5W1H 框架拆解一个评估需求，并识别每个维度最常见的翻车方式
• 判断自己的团队该从哪个评估调用点起步

前置知识：读完第 1 章。本章系统解构大模型全生命周期各阶段的评估切入点，从时间、空间、利益方与战略目的四个维度建立 5W1H 框架。

2.2 评估在 LLM 全生命周期中的位置

第 1 章的基准史讲的是"评估什么"；本节系统拆解"评估发生在哪"。大模型从无结构预训练语料到生产级应用，必须穿越一条高度严密的工程流水线，评估在其中至少挂载 8 处关键门禁。首先明确 4 个核心训练阶段与度量锚点：

• 预训练（pre-training）：用海量互联网文本让模型反复做"预测下一个词"的练习。练完模型会"说话"，但还不会"听话"（不擅长按指令回答）。
• loss / 困惑度（perplexity）：交叉熵损失衡量模型在自回归预测时预测分布与真实数据分布的散度；困惑度（$PPL = 2^{loss}$）反映模型在每个预测步的有效候选分支因子（Branching Factor）。度量专家洞察：损失下降是预训练收敛的必要条件，但与复杂推理、指令遵循等下游任务性能呈现显著的非线性关系。
• SFT（监督微调）：在高质量「指令-响应」专家演示集上微调基座，引导模型收敛至预期的交互范式。度量专家洞察：评估需兼顾特定格式的依从率（Compliance Rate）以及基座广泛知识的灾难性遗忘（Catastrophic Forgetting）。
• RLHF（基于人类反馈的强化学习）：利用人类或高阶裁判对成对响应进行偏好标注，拟合奖励模型（Reward Model）作为效用函数，进而通过强化学习优化策略模型。度量专家洞察：奖励模型本身是一个具有测量误差的评分仪器，其对长文本、表面客套的虚高偏好会直接引发策略网络的奖励黑客行为（Reward Hacking）。

flowchart TB
    PT["① 预训练<br/>评 val loss / 困惑度<br/>每个 checkpoint 一次"] --> MT["② 中期训练<br/>小规模能力探针<br/>每 1-2% 训练进度抽测"]
    MT --> SFT["③ SFT 微调<br/>通用能力回归测试<br/>每个 checkpoint 一次"]
    SFT --> RLHF["④ RLHF 训练<br/>监控 RM 分数分布<br/>训练中持续"]
    RLHF --> RM["⑤ RM 评估<br/>偏好判断准确率<br/>RM 训完后专项评"]
    RM --> SEC["⑥ 发布前安全评估<br/>红队攻防 + 拒绝率<br/>每个候选版本全量"]
    SEC --> SEL["⑦ 模型选型<br/>自建小评估集横向对比<br/>选型期一次性"]
    SEL --> APP["⑧ 应用层 CI 评估<br/>业务 eval 集 + LLM-as-Judge<br/>每次改 prompt / 模型 / RAG"]
    APP --> PROD["⑨ 生产监控<br/>用户反馈 + A/B + 人工抽检<br/>持续"]

图里的 checkpoint 指训练过程的存档点——训练每隔一段时间把模型参数存一份，评估就跟着存档点跑。每个调用点的频率、规模与决策影响：

（量级口径综合自：RewardBench、Anthropic 工程博客、本仓调研笔记 调研笔记。）

度量体系全局架构：这是一套多阶段递进的质量门禁体系（Multi-stage Quality Gates）——①②③ 为模型研发期的内在统计量与收敛性诊断，⑥ 为合规对齐与红队攻防的不可逆发布门禁，⑧ 为业务应用侧的 Prompt、RAG 与工具链回归流水线，⑨ 则是生产环境在线流量的连续观测与因果推断。同一评估理论在模型生命周期的不同拓扑节点具有针对性的操作化形式。

2.2.1 ④⑤ 的递归：评估器变成训练信号

④⑤ 两步值得单独讲，因为它们暴露了评估的一个深层身份变化：

• 第一层（经典评估）：数据集 → 模型 → 分数。评估是训练的旁观者。
• 第二层（RLHF）：人类投票 → 训练 RM → RM 的分数作为训练信号 → 训练原模型。评估模型（RM）变成了训练信号本身。
• 第三层（RLAIF）：用 LLM 当裁判替代人类投票，评估器直接生成训练信号。评估器 = 训练器。

工程含义：评分仪器的微小偏差会在闭环迭代中呈指数级级联放大。若奖励模型对冗长或空洞辞令赋予系统性偏置，强化学习优化将迅速演变为奖励黑客攻击（Reward Hacking）——即牺牲真实解决问题的能力以获取虚高的奖励得分。因此，⑤ 对奖励模型的评估属于至关重要的元评估（Meta-Evaluation），直接决定整个对齐流水线的可信度。

对你（应用层工程师）的推论只有一条：任何"用另一个模型打分"的方案（LLM-as-Judge），都必须先校准裁判——第 3 章会给出校准的具体数字。

2.3 模型层评估 vs 应用层评估

图里的 ①-⑥ 评的是模型本身：这个基座模型有什么能力。⑦-⑨ 评的是你的系统：模型 + 提示词 + 检索（RAG）+ 工具 + 编排在你的任务上表现如何。这是两个不同的测量对象：

为什么同一个模型，两层分数可能相反？ 四个原因：

1. 分布不同：公开基准覆盖通用分布，你的任务可能集中在长尾。Arena 的大众问题偏简单，测不出专业知识（来源：Judging LLM-as-a-Judge, arXiv:2306.05685）；
2. 调用方式不同：提示协议、few-shot 示例、系统消息都是实验变量，换一个 prompt 分数可以差很多（GPT-3 之后这就是常态，见第 1 章）；
3. 系统组件不同：检索质量、工具 schema、错误重试逻辑都是你的代码，模型层分数对它们一无所知；
4. 判分口径不同：榜单用学术判分，你的业务判分可能更严（或更松）。

这不是理论推演。社区有实践者公开分享过倒挂案例：同一个 agent 在 SWE-bench 与自建内部评估上排名完全反转（一组数字是 73% vs 81%，另一组 89% vs 38%）（来源：Reddit r/ClaudeAI 实践复盘；个人复盘帖属二手口径，当作"现象存在"的证据而非精确数字）。Anthropic 对应用层评估的官方要求也印证了这一点：评估要与生产中 agent 行为一致、环境本身不引入噪声、每次 trial 环境隔离（来源：Anthropic 工程博客）。

一句话总结：模型层评估决定你选哪个引擎，应用层评估决定你的产品是否合格。本书第 2 部分讲模型层基准，第 4、5 部分转入应用层工程——两层你都需要，但最终为业务负责的是后者。

2.4 5W1H 框架：六个问题，六个翻车故事

每个维度配一个真实翻车故事——它们全部来自公开记录。

2.4.1 Why：为了"有个分数"而评估

翻车故事：2023 年 ChatGPT 之后的开源复制潮（Vicuna、Alpaca 时代），各家都在发模型，却没有一家能拿出"谁的对话更好"的可信证据。Vicuna 团队自己用 GPT-4 当裁判评 win rate，Stanford 的 AlpacaEval 用 805 条指令集让 GPT-4 两两对比——都是真空期的应急产物（来源：AlpacaEval、arXiv:2305.14314）。评估动机不清的后果是这些分数互相不可比，谁也没回答"该用哪个"。

正确姿势：Why 必须落到一个具体决策（选 A 还是 B、上不上线、回不回滚）。评估报告里没有待决事项 = 白跑。

2.4.2 What：评估对象选错层

翻车故事：见 2.3 节的倒挂案例——团队把"SWE-bench 高分"当成"能干活"的证据， What 定在了模型层，结果内部任务表现完全另一回事（来源：Reddit r/ClaudeAI 复盘）。另一个方向也成立：把"客服机器人"的 What 定成"MMLU 分数"，测的是闭卷学术知识，与客服场景零交集。

正确姿势：What 写成可测量的能力描述——"回答退款问题的准确率 ≥ 90%，且敏感投诉的拒答率 ≥ 95%"。

2.4.3 Who：评估者被被评估对象欺骗

翻车故事 1（1966，人类版）：ELIZA 只有模板匹配，用户却在问卷里把它当知心人（来源：ELIZA, CACM 1966）。人类评估者会被表演性输出欺骗，这叫 ELIZA 效应。

自增强偏差（Self-Enhancement Bias）：Zheng 等人的实验系统揭示了 LLM 裁判的同源亲和性——GPT-4 当裁判时给自家回答的胜率高出约 10%，Claude-v1 给自家的高出约 25%（来源：arXiv:2306.05685）。度量专家洞察：评估存在天然的利益相关性与认知共鸣效应，任何未经跨厂商双盲交叉裁决公布的胜率优势，均必须在证据等级上予以系统性降级。

正确姿势：Who = 被评对象的利益无关方。人评要抽样与自动判分交叉校验；用 LLM 裁判时要避开"运动员兼裁判"（评 GPT 系模型时不用 GPT 当裁判）。

2.4.4 When：评估有时效，过期分数会骗人

翻车故事：GLUE 榜 2019 年就饱和（T5 达 90.3 后失去区分度），但此后仍有团队拿 GLUE 分数做 2021 年之后的选型依据——好模型和 SOTA 的分差不再提供任何信息（来源：基准饱和分析、SuperGLUE）。更近的例子：SWE-bench Verified 的最高分一年内从约 40% 涨到 80% 以上、接近饱和（来源：Anthropic 工程博客）——你去年存的对比表今天已经失效。

正确姿势：When 是一个集合——选型期一次 + 每次变更 CI 一次 + 定期复测（确认旧分数还有区分度）。90% 的团队只做"上线前一次"，这正是上线后翻车的主因。

2.4.5 Where：评估环境与生产不一致

翻车故事 1：Anthropic 记录，内部评估中模型通过读取之前 trial 留下的 git 历史获得不公平优势——评估环境没有做隔离，前一轮的痕迹变成了后一轮的答案（来源：Anthropic 工程博客）。

翻车故事 2：CORE-Bench 上 Opus 4.5 最初只得 42%，排查发现判分脚本把 96.12 与 96.124991… 判成不等（浮点精度）、任务描述歧义、随机性不可复现——评估环境本身的噪声比模型差异还大，换脚手架后跳到 95%（来源：Anthropic 工程博客）。

环境同构准则（Environmental Isomorphism）：Where 要求测试环境与生产部署保持绝对同构——包括量化精度（如 FP16 vs INT4）、系统 Prompt 模板、解码超参数以及上下文切分逻辑，并对每个评估实例施加无状态的沙箱隔离。脱离真实生产拓扑的离线环境测试，其结论不具备外推效度。

2.4.6 How：评估协议不写清楚，数字不可比

翻车故事 1（协议改变分数）：Chain-of-Thought 实验（2022）显示，同一个 PaLM 540B、同一批 GSM8K 题目，只要在提示里加 8 个"先写推理过程"的示例，准确率从 17.9% 跳到 56.9%——约 3 倍（来源：Wei et al., arXiv:2201.11903、Google Research 博客）。报告不写协议，数字就没有意义。

翻车故事 2（指标被钻空子）：AlpacaEval 1.0 的 GPT-4 裁判偏爱长回答，模型学会"写长"来赢，2024 年 4 月的 2.0 版专门加了长度控制修正（来源：arXiv:2404.04475）。

评估协议版本化（Protocol Versioning）：How 必须以声明式配置形式严密锁定并全量归档——包括 Prompt 模板的绝对字符序列、Few-shot 示例顺序、解码温度（Temperature）、随机种子（Seed）、提取正则与裁判模型确切版本号。任何未声明评测协议的分数均不具备统计复现性。

2.5 评估的三种分类法

分类 1：离线 vs 在线

分类 2：有参考答案 vs 无参考答案

分类 3：绝对 vs 相对

三种分类互相正交：一次评估可以同时是"离线 + 无参考 + 相对"。5W1H 里回答清楚 How，往往就顺带回答了这三个分类。

2.6 评估对象不只是模型

2.3 节的分野落到工程上，就是这 5 层——任何一层变化都要重新评估：

[1] 基础模型 (Base Model)
    GPT-4o, Claude, Qwen, DeepSeek ...
    ↓
[2] 提示词 (Prompt / System Message)
    "你是一个耐心的客服……"
    ↓
[3] 上下文 (Context / RAG)
    检索回来的 5 段文档
    ↓
[4] 工具 (Tools)
    函数调用的 schema
    ↓
[5] 编排 (Orchestration)
    多次调用的链路、错误处理

改一个 prompt 词，可能比换模型影响更大。 因为 prompt 离模型输出最近，而它通常没有版本控制和测试就上线了——这正是 ⑧（应用层 CI 评估）存在的理由。

2.7 评估的"最小必要"决策树

不知道从哪个调用点起步时，按这个顺序问：

问：你有真实用户吗？
├─ 是 → 在线评估为主（⑨），离线回归为辅（⑧）
└─ 否
   │
   问：你的任务有标准答案吗？
   ├─ 是 → 有参考答案的固定题集（⑧ 起步，100 题以内）
   └─ 否
      │
      问：你能请到领域专家吗？
      ├─ 是 → 人类评估为主，LLM-as-Judge 辅助（先校准裁判）
      └─ 否 → LLM-as-Judge + 多模型投票

2.7.1 工程落地：用 TypeScript 固化 5W1H 配置

在真实前端工程中，你可以像配置 playwright.config.ts 一样，用一个 eval.config.ts 将 5W1H 转化为 CI 可执行的类型定义：

// eval.config.ts — 5W1H 的工程化类型契约
export interface EvalPipelineConfig {
  why: "model_selection" | "regression_test" | "prompt_iteration";
  what: {
    dataset: string;           // 题目集路径，如 "./evals/refund-qa-200.jsonl"
    metrics: ("exact_match" | "llm_judge_score" | "latency_p95")[];
    thresholds: { passRate: number; maxLatencyMs: number }; // 门禁线：如通过率 ≥ 85%
  };
  who: {
    evaluator: "rule" | "llm_as_judge" | "human_expert";
    judgeModel?: string;       // 如 "gpt-4o"
  };
  when: "pre_commit" | "nightly_ci" | "release_gate";
  where: {
    isolation: "docker_sandbox" | "memory_clean";
    mockExternalTools: boolean;
  };
}

// 模拟 CI 门禁消费配置
export function runGateCheck(actualScore: number, config: EvalPipelineConfig): boolean {
  const isPass = actualScore >= config.what.thresholds.passRate;
  console.log(`[Eval CI] 目标: ${config.why} | 当前得分: ${(actualScore * 100).toFixed(1)}% | 门禁: ${isPass ? "通过 ✓" : "阻断 ✗"}`);
  return isPass;
}

2.8 实战与陷阱

陷阱 1：评估"了"但没"用"。 跑 10 个基准 → 写报告 → 归档 → 模型还是凭感觉选。对策：每份评估报告必须含 1 个明确决策（"基于 X 集 Y 分，选模型 A"）。

陷阱 2：评估数据集太小。 100 道题的"准确率 90%"误差可能 ±5%；最少样本量经验法则：准确率类 ≥ 500 题，偏好类 ≥ 5000 票，开放式 ≥ 200 条 + 多个评分员。

陷阱 3：评估集和实际分布不一致。 评估集是英文维基风格、真实场景是中文客服对话，准确率差距可能超过 20%。对策：真实用户样本至少留 20% 作 hold-out（留出集，不参与任何调优）。

陷阱 4：裁判没校准就上岗。 "用 GPT-4 给输出打分"是 2023 年以来最流行的捷径，但 2.4.3 与 2.2.1 已经说明：裁判有偏差谱系，且偏差会被下游消费放大。对策：先抽 100-300 条人工标注算一致性（第 3 章给具体指标），通过再让裁判上岗。

2.10 本章 Cheat Sheet

2.11 五个常见错误

1. Why 没问清就跑——没有待决事项的评估是表演，100% 浪费时间。
2. 只评模型不评系统——业务受 prompt/RAG/工具/编排影响，只评模型是片面的。
3. 只在上线前评一次——评估有时效，饱和与污染会让旧分数失效。
4. 数据集 < 500 题——100 题的"90%"误差可能 ±5%，小样本不可靠。
5. 裁判不校准就上岗——LLM 裁判有位置/冗长/亲缘偏差，先算与人类的一致性。

2.12 延伸阅读

⭐⭐⭐

• Anthropic: Demystifying evals for AI agents — 应用层评估的官方工程口径
• RewardBench — "评估 reward model"的元评估基准

⭐⭐

• Judging LLM-as-a-Judge — 裁判偏差的定量实验
• OpenAI Evals 最佳实践 — 评估设计方法论

⭐

• Chain-of-Thought 论文 — "协议改变分数"的原始证据