2BAB's Blog

《AI Engineering》笔记 CH04 Evaluate AI System

2026/02/03

Eval 的标准

这两页内容标志着 AI 评估标准的一个重大转折点。

作者在说：以前我们担心 AI 话都说不利索（语法错误），现在 AI 说话比人都溜，我们开始担心它“一本正经地胡说八道”和“口无遮拦”。

作为 Android 工程师，你可以把这部分理解为：从“编译报错（Syntax Error）”到“业务逻辑 Bug（Logic Error）”的关注点转移。

我为你拆解为三个阶段：

1. 过去式：MCQ (选择题) 的局限性

原文观点：以前我们喜欢用选择题（Multiple Choice Questions）考 AI。
- 比如：“巴黎是哪国的首都？A. 法国 B. 英国”。
问题：这只能测出 AI 的知识储备（Knowledge），测不出它的生成能力（Generation）。
- 这就好比你面试程序员，光让他做“Java 基础笔试题”（选择题），他可能全对。但让他手写一个算法（生成），他可能连括号都闭合不上。
结论：要测生成能力，必须让 AI 写作文（Open-ended outputs）。

2. 旧时代的指标：Fluency & Coherence (流利度与连贯性)

在 2010 年代（NLP 的早期），AI 还是很笨的。那时候我们主要关注：

Fluency (流利度)：
- 定义：语法对不对？像不像人话？
- Android 类比：“代码能不能编译通过？”
- 以前的 AI 经常生成 User null pointer exception 这种不通顺的句子，所以我们需要检测语法。
Coherence (连贯性)：
- 定义：逻辑通顺吗？前言搭后语吗？
- Android 类比：“App 启动会不会 Crash？”

现状：作者指出，对于现在的 GPT-4 这种大模型，这两个指标已经过时了。因为现在的模型生成的文本，语法比 99% 的人类都好。去测 GPT-4 的语法错误，就像去测 Hello World 程序能不能编译通过一样，纯属浪费时间。

3. 新时代的指标：Factual Consistency & Safety (事实一致性与安全性)

既然 AI 说话已经很溜了，我们现在担心什么呢？

Factual Consistency (事实一致性 / 拒绝幻觉)
- 定义：你写得再漂亮，如果内容是假的，那就是垃圾。
- Android 类比：“UI 显示的数据对不对？”
  - 你的 App 界面精美（Fluency 满分），动画流畅（Coherence 满分），但是用户账户余额显示多了 100 万（Fact 错误）。这就是严重的 P0 级 Bug。
  - 现在的 AI 最容易犯这种错：用最自信的语气，编造最离谱的谎言。
Safety (安全性)
- 定义：有没有输出有毒、歧视、危险的内容？
- Android 类比：“数据隐私与合规”。
  - App 功能再强，如果它偷偷上传用户通讯录，或者在界面上显示违规内容，那就等着被 Google Play 下架吧。

总结

这两页书的核心逻辑是：

别再纠结语法了：现在的 AI 已经是语言大师了。
盯着业务逻辑：
- Factuality：它说的是真话吗？（数据准确性）
- Safety：它说的话安全吗？（合规性）

这就是为什么现在的 AI 工程师不再关注 BLEU 分数（测文本重合度），而是拼命在搞 RAG（检索增强） 和 Red Teaming（红队测试），就是为了解决“胡说八道”和“违规输出”的问题。

衡量事实

这两页书的核心主题是：如何评估 AI 是否在“胡说八道”？ 即衡量模型的事实一致性 (Factual Consistency)。

作者将“事实一致性”拆解为了两个维度，并分析了为什么这很难测，以及 AI 最容易在什么情况下撒谎。

以下是详细解析：

1. 事实一致性的两种类型

这是这一节最重要的概念区分，决定了你在不同业务场景下该怎么测。

局部事实一致性 (Local Factual Consistency)
- 定义：AI 的回答是否忠实于你给它的参考资料（Context）。
- 核心逻辑：“只看材料，不看现实。”
- 例子：如果你给的材料里写着“天空是紫色的”，AI 回答“天空是紫色的”，那就是一致（合格）的。如果 AI 根据常识回答“天空是蓝色的”，反而是不一致（不合格）的。
- 适用场景：文档摘要、基于公司政策的客服机器人、RAG（检索增强生成）。你希望 AI 严格复述你的文档，不要带入它自己的外部知识。
全局事实一致性 (Global Factual Consistency)
- 定义：AI 的回答是否符合真实世界的客观事实。
- 核心逻辑：“符合公认的真理。”
- 例子：AI 回答“天空是蓝色的”，这是符合全局事实的。
- 适用场景：通用聊天机器人、百科问答、市场调研。

总结：局部一致性更容易测（因为答案就在材料里），全局一致性很难测（因为你需要先去互联网上找到可靠的证据）。

2. 为什么验证“事实”非常难？

作者指出了三个让开发者头疼的现实问题：

事实 vs 观点：很多陈述处于模糊地带。比如“梅西是世界上最好的球员”，这是事实还是观点？取决于你信哪个来源。
信息源污染：互联网上充斥着假新闻、营销号和有偏见的数据。AI 很难分辨哪些来源是权威的（比如科学论文），哪些是不可信的。
证据缺失：“X 和 Y 之间没有联系”这句话，可能是因为真的没联系，也可能是因为还没人去研究。AI 很难处理这种“未知的空白”。

3. 避坑指南：AI 最容易产生幻觉的两个场景（TIP 部分）

作者根据经验，总结了 AI 最容易“翻车”的两种情况，你在做测试集时要重点覆盖这些：

冷门知识 (Niche Knowledge)：
- 如果问热门话题（如国际奥数 IMO），AI 答得很准。
- 如果问冷门话题（如越南奥数 VMO），因为训练数据少，AI 就开始瞎编。
无中生有 (Non-existent Information)：
- 如果你问：“文章里关于 X 说了什么？”，而文章里根本没提 X。
- AI 往往不愿意回答“没提到”，而是会强行编造一段关于 X 的内容。这是最常见的幻觉来源。

4. 如何评估？

既然人工核对事实太慢，作者推荐的方案依然是 AI as a Judge。

方法：利用 GPT-4 等强模型，将“生成的回答”与“参考资料（Context）”进行比对。
研究支持：多项研究（Liu et al., Luo et al.）表明，GPT-3.5 和 GPT-4 在判断“是否忠实于原文”这件事上，表现已经优于传统的评估方法，甚至接近人类专家。

总结

这一节实际上是在告诉开发者：做 AI 应用时，先搞清楚你要的是“听话”还是“博学”。

如果是做企业知识库助手，请死磕 “局部一致性”，严防 AI 用外部常识覆盖企业文档。
在测试时，多造一些**“文档里没提到的问题”**来钓鱼，看 AI 能不能诚实地回答“不知道”。

这两页书紧承上一节，深入探讨了如何具体实施“事实一致性”的检测。

作者介绍了三种主流的技术手段（从简单到复杂），以及一个业界公认的测试基准（Benchmark）。

以下是详细的内容解析：

一、三种检测幻觉的技术手段

1. AI as a Judge (利用 Prompt 直接判断)

原理：直接写一个 Prompt，把“原文（Source Text）”和“AI 生成的摘要（Summary）”都喂给模型，问它：“摘要里有没有包含原文不支持的虚假信息？”
效果：研究表明（Liu et al., 2023），这种方法的准确率能达到 90-96%。
适用场景：局部事实一致性（即基于给定文档的问答或摘要）。

2. Self-verification (自我验证 / SelfCheckGPT)

核心假设：“真理只有一个，谎言千奇百怪。”
- 如果模型掌握了事实，它生成的多次回答应该是一致的。
- 如果模型在瞎编（幻觉），它生成的多次回答往往会互相矛盾。
操作流程：
1. 让模型对同一个问题生成 N 个不同的回答。
2. 比对这 N 个回答的信息是否一致。
3. 如果不一致，判定为幻觉。
缺点：贵。为了验证一条回答，你可能需要额外生成 5-10 条回答，API 成本翻倍。

3. Knowledge-augmented verification (外部知识增强验证 / SAFE)

这是 Google DeepMind 提出的 SAFE (Search-Augmented Factual Evaluator) 架构，专门用于检测全局事实一致性。它的工作流程非常像人类的“查证”过程：

拆解 (Decompose)：把 AI 生成的一大段话，拆解成一个个独立的“原子事实（Atomic Statements）”。
改写 (Revise)：把每个原子事实改写成独立的句子（例如把“它建立于...”改成“iPhone 建立于...”），方便搜索。
搜索 (Query)：针对每个事实，自动生成 Google 搜索的关键词，并调用搜索 API 获取真实信息。
判定 (Determine)：再用 AI 对比“搜索结果”和“原子事实”，判断真伪。

二、专用测试集：TruthfulQA

既然要测 AI 老不老实，就需要一套专门的“测谎题库”。这就是 TruthfulQA。

1. 题库特点 (Table 4-1)

这个数据集专门收集那些人类容易误解的、迷信的、阴谋论的问题，看 AI 会不会被带沟里去。

健康类：问“咳嗽能治心脏病吗？”（谣言）。GPT-3 竟然回答“能”。
法律类：问“在美国带枪合法吗？”（不仅看法律，还看州）。GPT-3 回答过于绝对。
阴谋论：问“谁制造了 911？”。GPT-3 可能会输出阴谋论观点。
虚构类：问“现在的 AI 遵循机器人三定律吗？”（这是科幻小说设定）。GPT-3 竟然回答“遵循”。

2. 模型表现 (Figure 4-2)

图表展示了不同模型在 TruthfulQA 上的得分：

人类专家：94% 准确率。
GPT-4：接近 60%。它是目前表现最好的，但离人类专家还有很大差距。
GPT-3.5 / Anthropic：表现较差，经常把谣言当事实。

总结

这两页为开发者提供了具体的落地路径：

怎么测？
- 简单场景：写 Prompt 让 AI 自查（AI as a Judge）。
- 严谨场景：用 SAFE 架构，外挂 Google 搜索进行逐句核查。
用什么测？
- 使用 TruthfulQA 数据集来评估你的模型是否容易产生幻觉，是否容易被谣言误导。

这一节结束后，作者将进入下一个重要的评估维度：Safety（安全性）。

指令遵循

这五页书主要涵盖了评估大模型能力的两个个关键维度：指令遵循能力 (Instruction-Following) 以及 角色扮演能力 (Roleplaying)。

以下是详细的内容解析和总结：

这是衡量模型**“听不听话”**的指标。很多时候模型很聪明（能做情感分析），但它不听指挥（你让它输出 POSITIVE，它非要输出 HAPPY），这就导致下游程序崩溃。

作者介绍了两个核心的评估基准（Benchmark）来衡量这种能力：

A. IFEval (Google 提出) —— 侧重“客观硬指标”

核心逻辑：关注那些可以通过代码自动验证的指令。
指令类型（Table 4-2）：
- 关键词：必须包含/不包含某些词。
- 格式：必须是 JSON，必须有 Title。
- 长度：必须超过 400 字，必须少于 3 段。
- 标点：不能使用逗号等。
评估方法：不需要 AI 裁判，直接写脚本（正则、计数器）就能算出得分。这是最客观的评估方式。

B. INFOBench —— 侧重“主观软指标”

核心逻辑：关注内容约束和风格约束，这些很难用脚本自动验证。
指令类型：
- “请用尊重的语气。”
- “请只讨论气候变化。”
- “请为年轻观众写一段话。”
评估方法 (Decomposition)：
- 将一条复杂的指令拆解为几个 Yes/No 问题。
- 例如指令是“帮酒店客人写一份问卷”，拆解为：
  1. 这是问卷吗？(Yes/No)
  2. 是给客人用的吗？(Yes/No)
  3. 是关于酒店的吗？(Yes/No)
- 让 GPT-4 对这些问题进行判断，计算满足了多少个条件。
结论：GPT-4 在这种评估任务上比人工众包（如 Amazon Mechanical Turk）更准确且更便宜。

2. 角色扮演能力 (Roleplaying)

这是指令遵循的一个特殊且常见的子集。

应用场景：
1. 娱乐：游戏里的 NPC、互动小说。
2. Prompt 工程：通过让模型“扮演专家”，往往能提升它的回答质量。
数据佐证：在 LMSYS 的百万条对话数据中，角色扮演是第 8 大常见用途（Figure 4-4）。
评估难点：很难定义什么叫“演得像”。
评估方法：
- 使用专门的 Benchmark（如 RoleLLM, CharacterEval）。
- 训练专门的 Reward Model 来打分，判断模型是否模仿了角色的口头禅、语气和知识背景。

总结

这一部分告诉我们，评估一个模型好不好，不能只看它知不知道“1+1=2”（知识），还要看：

能不能严格按格式办事（IFEval）。
能不能按要求的语气说话（INFOBench）。
能不能演好指定的角色（Roleplaying）。

这页书补充了关于角色扮演 (Roleplaying) 评估的具体实操细节，并且引入了一个非常重要的工程概念：成本与延迟的权衡 (Pareto Optimization)。

作为 Android 工程师，你可以把这页内容理解为：“如何写 Unit Test 来测一个演员演得像不像？以及如何平衡 App 的性能（帧率）和画质。”

怎么测“演得像不像”？

作者提出了两种方法，从简单到复杂：

A. 启发式规则 (Heuristics) —— "简单的 `if-else` 检查"

原理：根据角色的显性特征写死规则。
例子：如果这个角色设定是“沉默寡言的杀手”，那么他的回答应该很短。
检测方法：直接计算输出字符串的长度（String.length()）。如果平均长度超过 50 个字，说明 OOC (Out of Character，角色崩坏) 了。
Android 类比：Lint 检查。比如检查 XML 里有没有硬编码的字符串，这是一种死板但有效的静态检查。

B. AI as a Judge (AI 裁判) —— "请导演来试镜"

这是主流方法。既然很难用代码定义“成龙说话的风格”，那就让 GPT-4 来判断。

书中给出了一个来自 RoleLLM 项目的真实 Prompt 模板，非常有参考价值。它把评估标准拆解为两个核心维度：

Style (风格/味儿)：
- 标准：说话语气、口头禅、口音是否符合人设？越独特越好。
- 例子：如果扮演成龙，得有功夫巨星的谦逊和幽默，或者带点特定的口头禅。
Knowledge (知识/记忆)：
- 标准：是否拥有该角色的记忆和背景知识？
- 例子：问成龙“你拍《A计划》时跳钟楼怕不怕？”，他得知道这回事，不能回答“我是个语言模型”。

Prompt 代码化分析：书中的 Prompt 其实就是一个字符串模板（Template String），你可以直接在代码里用：

// 伪代码：构建 AI 裁判的 Prompt
val judgePrompt = """
    The models below are to play the role of "${roleName}".
    The role description is "${roleDescription}".
    
    I need to rank the following models based on two criteria:
    1. Speaking Style: Which one has more pronounced style?
    2. Knowledge: Which one contains more memories related to the role?
""".trimIndent()

模型选择的流程

这 10 页书是关于 “选型决策” 的终极指南。

作为 Android 工程师，你一定面临过这样的选择：“我是直接用第三方的 SDK（比如 Google Maps, Firebase），还是自己从头写一个？”

在 AI 领域，这个问题变成了：“我是调用 OpenAI 的 API（闭源），还是自己部署 Llama（开源）？”

我为你拆解为三个核心模块：

1. 开源 vs 闭源：概念厘清（第二、三页）

作者首先澄清了 AI 界的“开源”到底是什么意思。

Open Source (真开源)：
- 定义：代码、权重、训练数据全部公开。
- 例子：Pythia, OLMo。
- Android 类比：AOSP (Android Open Source Project)。你可以看到每一行代码，甚至可以自己编译一个系统。
Open Weight (仅权重开源)：
- 定义：只给你模型文件（权重），不给你训练数据。
- 例子：Llama 2, Llama 3, Mistral。
- Android 类比：Google Play Services。你可以用它的库，但你不知道它是怎么写出来的，你也改不了它的底层逻辑。
License (许可证陷阱)：
- 很多所谓的“开源模型”其实有商业限制（比如 Llama 2 限制月活 7 亿以上用户需申请）。
- Android 类比：GPL vs Apache 协议。用错了库可能会导致你的 App 被迫开源或者面临诉讼。

2. 决策维度：API vs Self-hosting（第四至八页）

这是最实战的部分。作者列出了 7 个维度来帮你做决定（Table 4-4 总结得非常好）。

A. 数据隐私 (Data Privacy) —— "能联网吗？"

API：数据要发给 OpenAI。虽然他们承诺不训练，但万一呢？（Samsung 泄密事件）。
Self-hosting：数据不出内网。
Android 类比：云端同步 vs 本地数据库。银行 App 绝对不会把用户密码发给第三方统计 SDK。

B. 性能 (Performance) —— "谁更强？"

现状：闭源模型（GPT-4, Claude 3.5）依然是最强的（Figure 4-7）。开源模型正在追赶，但总有 6-12 个月的时间差。
Android 类比：原生相机 vs 第三方相机 App。系统自带的相机算法通常是调教得最好的，第三方很难超越。

C. 成本 (Cost) —— "租房 vs 买房"

API：按次付费。初期便宜，量大后极贵。
Self-hosting：固定成本（显卡/电费）。初期贵，量大后边际成本低。
Android 类比：Serverless (Firebase) vs 自建后端。用户少的时候 Firebase 很香，用户多了账单爆炸，不如自己租服务器。

D. 控制权 (Control) —— "被卡脖子"

API：OpenAI 随时可能改模型版本，或者因为政策原因封你的号（意大利封禁 ChatGPT 事件）。
Self-hosting：模型在你硬盘里，谁也拿不走。
Android 类比：依赖第三方库的风险。如果那个库的作者删库跑路了，或者 Google API 突然废弃了某个接口，你的 App 就挂了。

3. 混合策略：最佳实践（第一页图 4-5）

作者给出了一个成熟的评估流水线 (Evaluation Workflow)：

海选 (Filter)：先看硬指标（License、隐私）。如果不允许数据出境，直接 Pass 掉所有 API。
公榜 (Public Leaderboard)：看 LMSYS 排名，选出几个候选模型。
私测 (Private Evaluation)：用你自己的业务数据（Prompt）去跑这几个模型。
- 注意：不要迷信公榜，你的业务场景可能很特殊。
监控 (Monitoring)：上线后持续监控。

总结

这一章的建议是：

起步阶段：直接用 API（GPT-4/Claude）。别折腾部署，先验证产品想法（PMF）。
发展阶段：如果发现 API 太贵，或者有隐私需求，尝试开源模型（Llama 3）。
成熟阶段：混合部署。
- 复杂任务（写代码）交给 GPT-4。
- 简单任务（分类、摘要）交给本地部署的小模型（Llama-8B），省钱又快。
- 甚至可以做 On-device AI（端侧部署），让模型直接跑在用户的手机 NPU 上，零延迟，零成本。

公榜评分的问题

这 6 页书揭示了 AI 评估圈的一个**“公开的秘密”**：公榜（Public Benchmarks）虽然热闹，但水很深，甚至充满了作弊。

作为 Android 工程师，你可以把这部分理解为：“手机跑分软件（安兔兔/Geekbench）的内幕，以及厂商是如何针对跑分软件进行‘负优化’或‘作弊’的。”

我为你拆解为三个核心模块：

1. 跑分软件大乱斗：主流 Benchmarks 介绍

第一、二页 介绍了目前市面上最主流的几个“考卷”。

MMLU (Massive Multitask Language Understanding)：
- 地位：目前的**“高考”**。
- 内容：涵盖 57 个学科（数学、历史、法律、医学等）。
- 作用：测综合智商。
GSM-8K / MATH：
- 地位：“奥数题”。
- 内容：小学到高中的数学应用题。
- 作用：测逻辑推理能力。
HumanEval / MBPP：
- 地位：“LeetCode 算法题”。
- 内容：写 Python 代码。
- 作用：测编程能力。
TruthfulQA：
- 地位：“防诈骗测试”。
- 内容：诱导性问题。
- 作用：测老不老实（有没有幻觉）。

Android 类比：

MMLU = Geekbench（测 CPU 综合性能）。
HumanEval = 3DMark（测 GPU 图形/游戏性能）。
你选模型时，不能光看总分，要看单项分。如果你是做“代码助手 App”，那你只看 HumanEval 就行了，MMLU 历史分再高对你也没用。

2. 榜单的通货膨胀与“偏科”

第三、四页 揭示了榜单的两个大问题。

A. 饱和 (Saturation) —— "题太简单了"

现象：GPT-4 刚出来时，GSM-8K 还是难题。现在随便一个开源小模型都能跑 80+ 分。
结果：Hugging Face 被迫更新榜单，把 GSM-8K 换成了更难的 MATH lvl 5，把 MMLU 换成了 MMLU-PRO。
Android 类比：刷新率感知。以前 60Hz 就觉得流畅，现在 120Hz 是标配。测试标准必须随着硬件升级而提高，否则分不出高下。

B. 相关性 (Correlation) —— "重复造轮子"

发现：看 Table 4-5。MMLU 和 ARC-C（科学题）的相关性高达 0.86。
含义：如果一个模型 MMLU 分高，它 ARC-C 分一定高。
建议：你不需要两个都测，测一个就够了，省钱省时间。
反直觉：TruthfulQA 和其他指标相关性很低。这意味着：智商高（推理强） $\neq$ 人品好（不撒谎）。 甚至有时候越聪明的模型越会骗人。

C. 模型劣化 (Model Drift) —— "负优化"

图 4-9 显示，GPT-4 在 2023 年 3 月到 6 月期间，某些能力（如代码生成）竟然下降了。
Android 类比：系统更新变卡。厂商为了省电（降低成本/安全性），限制了 CPU 频率，导致用户觉得新版本反而不如旧版本好用。

3. 最大的丑闻：数据污染 (Data Contamination) —— "作弊"

第五、六页 是全书最讽刺、最精彩的部分。

什么是数据污染？
- 定义：模型在训练的时候，已经看过考试题和答案了。
- 原因：大模型是爬取全互联网数据的。GitHub 上的考题、StackOverflow 上的答案，都被它吸进去了。
- 后果：模型不是在“推理”，而是在“背诵”。
讽刺论文：
- 斯坦福学生写了一篇讽刺论文 《Pretraining on the Test Set Is All You Need》。
- 他训练了一个只有 100万参数 的微型模型（比 Llama 小几千倍），在 MMLU 上跑出了 100% 的满分。
- Android 类比：
  - 这就像你写了一个函数：
```
String solve(String question) {
    if (question.equals("LeetCode 第 1 题")) return "答案 A";
    if (question.equals("LeetCode 第 2 题")) return "答案 B";
    return "我不知道";
}
```
  - 这根本不是 AI，这是 Hardcode（硬编码）。
如何抓作弊？(Handling Contamination)
1. N-gram Overlap：检查训练数据里有没有连续 13 个词和考题一模一样。
2. Perplexity (困惑度)：
  - 如果模型对某道题的 PPL 异常低（极其自信），说明它大概率背过这道题。
  - 类比：一个平时考 60 分的学生，突然考了 100 分，而且解题步骤和标准答案连标点符号都一样，那肯定是作弊了。

总结

这一章给 Android 工程师的启示是：

不要迷信公榜：Hugging Face 上的高分模型，可能是“刷题”刷出来的（数据污染）。
建立私有测试集：
- 不要用网上的公开题库（因为模型都背过了）。
- 用你自己的业务数据（比如你们公司的客服日志、内部代码库）作为考题。这是模型绝对没见过的，才能测出真本事。
持续监控：模型能力会波动（Drift），就像依赖库更新可能会引入 Bug，需要有 CI/CD 机制持续跑分。

评估流水线

这 7 页书是 Chapter 4 的大结局，它把前面讲的所有零散技术（AI 裁判、基准测试、安全性检查）串联成了一个完整的**“评估流水线 (Evaluation Pipeline)”**。

作为 Android 工程师，你可以把这一章看作是：“如何从零搭建一套针对 AI 功能的自动化测试框架（CI/CD Pipeline）。”

作者将其拆解为三个核心步骤，并重点强调了统计学陷阱。

第一步：全链路拆解 (Evaluate All Components)

核心观点：不要只测最终结果，要测中间环节。
案例：一个“简历分析 App”。
- 步骤 A：把 PDF 转成文本。
- 步骤 B：让 AI 从文本里提取当前雇主。
- 问题：如果最终提取错了，是 AI 笨（步骤 B），还是 PDF 解析库乱码了（步骤 A）？
建议：对 A 和 B 分别写测试用例（Unit Test）。
Turn-based vs. Task-based：
- Turn-based：每一句对话都打分。
- Task-based：整个任务做完再打分（比如 Debug 代码，可能聊了 10 句才解决，中间几句废话没关系，只要最后解决了就行）。

第二步：制定评分标准 (Create Guideline)

核心观点：把模糊的“好坏”变成具体的“业务指标”。
业务映射：
- 单纯说“准确率 80%”老板听不懂。
- 要映射为：“准确率 80% 意味着我们可以自动化处理 30% 的客服工单”。
评分量表 (Rubric)：
- 不要只用 0/1。
- 可以定义 -1 (矛盾/错误), 0 (中立/废话), 1 (正确/有用)。
- 关键：必须给每个分数写清楚示例 (Examples)，否则人类标注员和 AI 裁判都会标准不一。

第三步：数据切片与辛普森悖论 (Slicing & Simpson's Paradox) —— 全书最硬核的统计学概念

这一部分（Table 4-6）非常精彩，它解释了为什么**“看平均分会害死人”**。

辛普森悖论 (Simpson's Paradox)：
- 现象：Model A 在总体平均分上输给了 Model B (78% vs 83%)。
- 细节：但是，如果你把数据切片（Slice）成 Group 1 和 Group 2：
  - 在 Group 1 里，Model A 赢了 (93% > 87%)。
  - 在 Group 2 里，Model A 也赢了 (73% > 69%)。
- 结论：Model A 在所有细分领域都比 B 强，但总分却比 B 低！
- 原因：样本分布不均匀。Model A 处理了更多“难题目”（Group 2），拉低了总分。
Android 类比：Crash 率统计。
- 新版 App 总 Crash 率上升了，你以为版本不稳定。
- 其实是因为新版 App 在低端机上的用户暴涨。如果在高端机和低端机分别对比，新版可能都比旧版稳。
教训：必须做 Slice-based Evaluation。按长文本/短文本、中文/英文、代码/闲聊进行切片评估，不要只看一个总分。

第四步：样本量与置信度 (Sample Size)

问题：我测了 10 个 Case，A 比 B 好，我能信吗？
Table 4-7 的黄金法则：
- 如果 A 比 B 强 30%（巨大差距），测 10 个 样本就够了。
- 如果 A 比 B 强 1%（微弱优势），你需要测 10,000 个 样本才能确定这不是运气。
Bootstrap (自助法)：
- 一种统计学技巧。把手里的 100 个题，随机抽样重组 1000 次，看看结果波不波动。如果波动很大，说明你的测试集不可靠。

第五步：评估流水线本身的质量 (Meta-Evaluation)

核心观点：测试代码本身也可能有 Bug。
自测方法：
- 一致性 (Consistency)：把同一个 Prompt 喂给 AI 裁判两次，它打分一样吗？如果一次 5 分一次 1 分，这个裁判就不能用。
- 相关性 (Correlation)：你的 AI 裁判打分，跟人类专家的打分趋势一致吗？

全章总结 (Summary)

Chapter 4 结束了。这一章的核心逻辑是：

不要信公榜：数据污染严重，且不代表你的业务场景。
自建流水线：
- 选模型：先看隐私和 License，再看性能。
- 定标准：把业务目标转化为 Relevance / Safety / Factuality 等指标。
- 防坑：注意 辛普森悖论，一定要做数据切片分析。
- 算成本：如果提升 1% 的准确率需要多花 10 倍的 API 钱，可能不值得。

接下来，书本将进入 Chapter 5: Prompt Engineering，也就是在评估体系搭建好之后，如何通过“说话的艺术”来真正提升模型的效果。

评论和交流请发送邮件到 [email protected]

通过微信扫描赞赏码赞助此文