2BAB's Blog

《AI Engineering》笔记 CH03 Evaluation Methodology

2026/02/03

Cross Entropy 和 Perplexity

这两个概念是机器学习（特别是 NLP）中最基础、最核心的**“跑分指标”**。

作为 Android 工程师，你可以把它们理解为**“衡量模型预测准不准的 Unit Test 报错信息”**。

它们俩其实说的是同一件事，只是单位不同。我们一个一个来看：

1. Cross Entropy (交叉熵) —— “错误惩罚分”

一句话解释：模型预测的概率分布，跟真实答案的概率分布，差距有多大？

  • 场景模拟： 假设你在写一个智能代码补全插件。 你输入了 System.out.，真实答案（Ground Truth）应该是 println。

    • 模型 A (学霸)：

      • 预测 println 的概率：0.9
      • 预测 print 的概率：0.09
      • 预测 error 的概率：0.01
      • Cross Entropy：很低（因为它很自信且猜对了）。

    • 模型 B (学渣)：

      • 预测 println 的概率：0.3 (它觉得也可能是别的)
      • 预测 print 的概率：0.3
      • 预测 error 的概率：0.4
      • Cross Entropy：较高（虽然猜对了，但它犹豫不决）。

    • 模型 C (爆渣)：

      • 预测 error 的概率：0.9 (它非常自信地猜错了)
      • 预测 println 的概率：0.01
      • Cross Entropy：爆炸高（交叉熵会严厉惩罚“自信地胡说八道”）。

  • Android 类比： 你可以把它看作是 DiffUtil 计算出的差异值。

    • 真实列表（Reality）和预测列表（Prediction）之间的差异越大，这个值就越大。
    • 在训练模型时，我们的目标就是通过“梯度下降”算法，把这个 Loss (损失值) 降到最低。

2. Perplexity (困惑度 / PPL) —— “候选数量”

一句话解释：模型在预测下一个词时，平均有多少个“候选”让它感到纠结？

Perplexity 是 Cross Entropy 的指数形式（$e^{\text{Cross Entropy}}$），它更直观，更像人话。

  • 场景模拟： 还是代码补全 System.out.。

    • Perplexity = 1：

      • 模型心里想：“这题我会！下一个词绝对是 println，没有其他可能！”
      • 这是完美状态，完全不困惑。

    • Perplexity = 10：

      • 模型心里想：“额……下一个词可能是 println，也可能是 print，或者是 printf……大概有 10 个 词我觉得都有可能，我得像掷骰子（10面骰）一样选一个。”
      • 这就比较困惑了。

    • Perplexity = 10000：

      • 模型心里想：“我完全看不懂你在写啥，字典里这 10000 个词我觉得都有可能。”
      • 这就是人工智障。

  • Android 类比： 想象 Android Studio 的 代码提示弹窗 (Code Completion Popup)。

    • 当你打代码时，弹窗里列出了 5 个 候选词，说明 IDE 的 Perplexity $\approx$ 5。
    • 如果弹窗里列出了 100 个 候选词，说明 IDE 很困惑，Perplexity $\approx$ 100。
    • 指标越低越好，说明模型越确定，弹窗越精准。

总结

指标 Cross Entropy (交叉熵) Perplexity (困惑度)
本质 Loss Function (损失函数) Branching Factor (分支系数)
数学关系 对数刻度 (Log scale) 线性刻度 (Linear scale)
直观含义 预测概率与真实答案的距离 模型做选择时的纠结程度 (备选数量)
Android 类比 DiffUtil 的差异分数 代码补全弹窗里的候选词数量
目标 越低越好 (接近 0) 越低越好 (接近 1)

为什么书里说它们很重要？ 因为在训练大模型（Pre-training）时，我们没法让人类去盯着每一个字看对不对。我们只能用这两个数学指标来监控训练进度：

  • 如果 Loss (Cross Entropy) 一直在降，说明模型正在“开窍”。
  • 如果 PPL (Perplexity) 降到了 10 以下，说明它已经能写出非常通顺的人话了。

详细拆解：衡量大模型“基本功”的数学指标。

作为 Android 工程师，你可以把这部分理解为：“在没有 QA 测试介入之前，如何通过 Log 和 单元测试 来判断底层的代码逻辑是否健壮。”

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

1. 信息论基础：Entropy (熵) —— "压缩率与信息量"

第二页 (Figure 3-4) 用一个正方形的例子解释了什么是熵。

  • 概念：熵衡量的是**“不确定性”或者“信息量”**。
    • 如果一个语言只有 2 个词（图 a），你只需要 1 bit ($2^1=2$) 就能区分它们。
    • 如果一个语言有 4 个词（图 b），你需要 2 bits ($2^2=4$) 就能区分它们。
  • 结论：可能性越多，熵越高，预测下一个词就越难。
  • Android 类比：APK 压缩。
    • 如果你的代码全是重复的 00000（低熵），Zip 压缩率极高，体积很小。
    • 如果你的代码全是随机乱码（高熵），Zip 根本压不动，体积很大。
    • 模型训练的目标，就是试图找到数据背后的规律，把“高熵”的乱码变成“低熵”的可预测数据。

2. 核心指标：Cross Entropy (交叉熵) & BPC/BPB

第三页 介绍了训练模型时最常用的 Loss Function。

  • Cross Entropy (交叉熵)：

    • 定义：衡量“模型预测的概率分布”与“真实数据的概率分布”之间的距离。
    • 公式：$H(P, Q)$。$P$ 是真理，$Q$ 是模型的猜测。
    • Android 类比：assertEquals(expected, actual)。
      • 训练过程就是不断运行这个 Assert，如果 actual 和 expected 差得远，就狠狠惩罚模型（反向传播），逼它改参数。

  • BPC (Bits-per-Character) / BPB (Bits-per-Byte)：

    • 痛点：不同的模型切词（Tokenization）方式不一样。有的模型一个 Token 是一个单词，有的是一个字母。直接比 Loss 不公平。
    • 解决：大家统一换算成“每个字符/每个字节”包含多少 bit 信息。
    • Android 类比：dp (Density-independent Pixels)。
      • 不同手机屏幕密度（Tokenization）不一样，不能直接用 px (Loss) 对比。
      • 必须换算成 dp (BPC/BPB)，才能在不同设备间公平比较 UI 大小。

3. 直观指标：Perplexity (困惑度 / PPL)

第四、五页 讲了这个最著名的指标。

  • 定义：熵的指数形式 ($e^{\text{entropy}}$)。

  • 直观理解：“加权后的备胎数量”。

    • PPL = 1：模型极其自信，它觉得下一个词只有 1种 可能。
    • PPL = 100：模型很困惑，它觉得下一个词有 100种 可能，它得从中瞎蒙一个。

  • 规律：

    • 上下文越长，PPL 越低：读了上半句，猜下半句就容易了。
    • 模型越大，PPL 越低（Table 3-1）：脑容量大的模型（1.5B）比小的（117M）猜得更准。

  • Android 类比：代码补全的候选列表。

    • 你在 Android Studio 里打 Re。
    • 如果 IDE 极其聪明，直接补全 RecyclerView，此时 PPL $\approx$ 1。
    • 如果 IDE 很笨，弹出一个列表列了 50 个以 Re 开头的类让你选，此时 PPL $\approx$ 50。

4. 工程师的陷阱：PPL 的局限性（第五页 Warning）

这一段非常关键，解释了为什么我们不能只看 PPL。

  • 陷阱：PPL 低 $\neq$ 聊天能力强。
  • 现象：
    • 经过 SFT (指令微调) 和 RLHF (人类反馈) 的模型（如 ChatGPT），其 PPL 通常比原始基座模型（Base Model）更高（更差）。
  • 原因：
    • 原始模型读的是互联网上的“自然语言”，它预测得很准。
    • ChatGPT 被强行教导要“说话像个客服”，这种说话方式在互联网原始数据里并不常见（分布偏移）。
    • 所以从统计学角度看，ChatGPT 对“下一个词”的预测能力反而下降了，但它对“人类指令”的理解能力上升了。
  • Android 类比：
    • Base Model 就像一个追求极致性能的 C++ 算法工程师，代码写得极快（PPL 低），但界面丑陋，用户没法用。
    • ChatGPT 就像一个注重体验的产品经理，虽然写代码慢一点（PPL 高），但他做出来的 App 界面友好，用户爱用。
    • 结论：PPL 适合用来评估**预训练（Pre-training）阶段的质量，但不适合评估最终产品（Chatbot）**的好坏。

总结

这几页书是在教你如何看懂模型的“体检报告”：

  1. Entropy 是基础理论。
  2. Cross Entropy 是训练时的“鞭子”（Loss）。
  3. Perplexity 是预训练时的“分数”（越低越好）。
  4. 但是，到了应用层（SFT/RLHF），别太迷信 PPL，要看实际疗效。

常用的 Evaluation 方法

它们从**“代码能不能跑”讲到了“意思对不对”**，涵盖了评估 AI 模型的几种硬核方法。

作为 Android 工程师，你可以把这部分理解为：“从 Unit Test（单元测试）到 UI Screenshot Test（截图对比），再到 AI 辅助的语义断言。”

我为你拆解为三个核心层级：

1. 功能正确性 (Functional Correctness) —— "能跑通 Unit Test 吗？"

第二、三页 讲的是最客观、最硬核的评估标准，主要用于代码生成 (Code Generation) 任务。

  • 核心逻辑：
    • 别管 AI 生成的代码长得漂不漂亮，缩进对不对。
    • 直接跑一下！ (Execution Accuracy)
    • 如果 AI 写了一个 gcd(a, b) 函数，我们就输入 (15, 20)，看它返不返回 5。
  • Pass@k 指标：
    • 背景：AI 是有随机性的。有时候第一次写错了，第二次就写对了。
    • 定义：让 AI 对同一个问题生成 $k$ 个不同的代码版本（比如 10 个）。只要这 10 个里有 1 个能通过单元测试，就算它通过。
    • Android 类比：Flaky Test 的重试机制。
      • CI 上跑测试挂了？不要紧，Retry 3 次，只要有一次绿了，就当它过了。
      • pass@1 = 一次过。
      • pass@10 = 允许试错 10 次。

2. 机械匹配：Exact Match & Lexical Similarity —— "String.equals() 与 Diff"

第四、五、六页 开始讨论非代码类的文本评估（比如翻译、摘要）。

A. Exact Match (精确匹配)

  • 定义：AI 输出的字符串必须和标准答案（Reference）一模一样。
  • 场景：数学题（答案是 "5"）、多选题（答案是 "C"）。
  • Android 类比：Assert.assertEquals(expected, actual)。
    • 差一个标点符号，或者多一个空格，测试直接 Fail。
    • 这对于开放式对话（Open-ended text）来说太严苛了。

B. Lexical Similarity (词法相似度)

  • 定义：计算 AI 输出的句子和标准答案有多少重叠的单词。
  • 指标：
    • BLEU / ROUGE：这些是 NLP 界的经典指标。它们计算 n-gram（连续的 n 个词）的重合率。
    • Edit Distance (编辑距离)：把 AI 的句子改成标准答案需要几步（增删改）。
  • Android 类比：git diff 或者 Lint 检查。
    • 它只在乎“字”一不一样，不在乎“意思”对不对。
  • 致命缺陷（图 3-5 Big Ben 案例）：
    • 标准答案：“繁忙街道上的车流，背景是钟楼。”
    • AI 回答：“大本钟和议会大厦的夜景。”
    • 结果：虽然 AI 说得很对（语义正确），但因为用的词跟标准答案完全不一样（Lexical 不同），BLEU 分数会非常低。
    • 反例："Let's eat, grandma"（吃饭）和 "Let's eat grandma"（吃人）。词法相似度 99%，但意思完全相反。

3. 语义匹配：Semantic Similarity —— "向量化对比"

第七页 提出了终极解决方案。

  • 定义：不看字面，看意思（Semantics）。
  • 技术实现：Embedding (嵌入)。
    • 把 AI 的回答转成一个向量（Vector A）。
    • 把标准答案转成一个向量（Vector B）。
    • 计算这两个向量的 Cosine Similarity (余弦相似度)。
  • 优势：
    • "The cat sits on the mat" 和 "A feline is resting on the rug"。
    • 这两个句子单词完全不同（Lexical Similarity $\approx$ 0），但向量距离非常近（Semantic Similarity $\approx$ 1）。
  • Android 类比：图片相似度对比。
    • 你不能逐个像素对比（Exact Match），因为压缩算法会导致像素值微变。
    • 你需要提取图片的特征指纹（Embedding），然后对比指纹的相似度。

总结

这几页书展示了 AI 评估方法的进化史：

  1. Functional Correctness：Unit Test。最准，但只能测代码。
  2. Exact Match：String.equals()。太死板，只能测选择题。
  3. Lexical Similarity (BLEU/ROUGE)：Diff。只看字面，容易误判（吃奶奶 vs 吃饭）。
  4. Semantic Similarity (Embedding)：AI 裁判。看懂意思，是目前最主流的评估非结构化文本的方法。

AI as a Judge

这 10 页书是目前 AI 工程化中最热门、最实用的领域：AI as a Judge（用 AI 当裁判）。

作为 Android 工程师，你肯定熟悉 CI/CD（持续集成）。 以前，代码写完了，要靠 QA 人工点点点（Human Evaluation）。 后来，我们写了 Unit Test 和 UI Test，让机器自动跑测试（Code-based Evaluation）。 现在，对于“写诗”、“聊天”这种没有标准答案的功能，我们用 GPT-4 来给 Llama-2 写的诗打分。这就是 AI as a Judge。

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

1. 核心模式：三种裁判打分法（图 3）

书中列举了三种让 AI 裁判干活的方式，这跟 Android 测试非常像：

  • 模式 A：单点评分 (Single-point Grading)
    • Prompt：“请给这段回复打分（1-5分），标准是是否有礼貌。”
    • Android 类比：Lint 检查 / SonarQube。代码提交上去，系统自动扫描代码质量，给出一个“健康度分数”。
  • 模式 B：参考对比 (Reference-based)
    • Prompt：“标准答案是 A，AI 生成的是 B，请问 B 的意思和 A 一样吗？（True/False）”
    • Android 类比：Snapshot Testing (截图对比测试)。UI 跑出来的截图（B）和设计稿/基准图（A）对比，看像素差异大不大。
  • 模式 C：成对比较 (Pairwise Comparison)
    • Prompt：“针对这个问题，回答 A 和回答 B，哪个更好？”
    • Android 类比：A/B Testing。你不知道哪个 UI 更好，所以你把两个版本都发出去，看哪个转化率高。这里只是把“用户”换成了“GPT-4”。

2. 裁判的偏见 (Biases) —— "机器也有私心"（图 7）

这是这一章最精彩的部分。你以为 AI 是客观的？错，AI 裁判有很多**“人类的臭毛病”**。

  • Verbosity Bias (话痨偏见)：
    • 现象：AI 裁判倾向于给更长的回答打高分，哪怕它是废话连篇。
    • Android 类比：KPI 考核代码行数。有些公司觉得写 1000 行代码的程序员比写 100 行的厉害，实际上可能 100 行的那个重构能力更强。
  • Self-bias (自恋偏见)：
    • 现象：GPT-4 往往觉得 GPT-4 生成的答案最好，Claude 觉得 Claude 最好。
    • Android 类比："Not Invented Here" (非我所创综合症)。程序员总觉得别人的代码写得烂，只有自己写的才是最优雅的。
  • Position Bias (位置偏见)：
    • 现象：在成对比较中，AI 往往倾向于选第一个出现的答案（或者最后一个）。
    • Android 类比：列表的点击率。用户总是习惯性点击 RecyclerView 的第一个 Item。

3. 裁判的资格：谁能当裁判？（图 8 & 9）

  • 强带弱 (Stronger Judge)：
    • 用 GPT-4 去评测 Llama-7B。这是最稳的。
    • 类比：Senior 工程师 Review Junior 的代码。
  • 弱带强 (Weaker Judge)：
    • 用一个小模型去评测 GPT-4。这很难，但在特定领域（比如只看有没有脏话）是可行的。
    • 类比：实习生检查代码格式。虽然实习生不懂架构，但他能检查你有没有写注释。
  • 自我反思 (Self-Critique)：
    • 让模型自己评价自己：“我刚才算的对吗？”
    • 类比：Double Check。写完代码自己再读一遍。

4. 专用裁判模型 (Specialized Judges)

为了省钱（GPT-4 太贵了），业界训练了一些专门用来打分的小模型（图 9 & 10）。

  • PandaLM / JudgeLM：
    • 这些模型不会写诗，也不会写代码，但它们特别擅长挑刺。
    • 它们就像是专业的 QA 团队，虽然不会写代码，但找 Bug 一找一个准。
  • Reward Model (奖励模型)：
    • 比如 Google 的 Cappy。它只输出一个 0-1 的分数。
    • 类比：CI 流水线上的脚本。它只告诉你 Build Success 还是 Fail，不负责帮你改代码。

总结

AI as a Judge 是目前解决“大模型不好测”这个问题的最佳方案。

对于 Android 工程师，这意味着：

  1. 你不需要雇佣 100 个人来测试你的 AI App。
  2. 你可以写一个脚本，调用 GPT-4 API，让它充当“虚拟用户”或“虚拟质检员”。
  3. 警惕：这个虚拟质检员可能喜欢听废话（话痨偏见），而且收费很贵（Token 成本），你需要像优化代码一样优化你的评测流水线。

Comparative Evaluation

这最后 10 页书是本章的压轴大戏，也是目前 AI 圈最火的“打擂台”机制——Comparative Evaluation (比较评估)。

作为 Android 工程师，你可以把这部分理解为：“从单纯的 Unit Test（跑分），进化到了 Multiplayer Ranked Match（多人排位赛/天梯系统）。”

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

1. 为什么要“打擂台”？(Pointwise vs. Comparative)

第一页 (Figure 3-9) 和 第二页 解释了两种评估哲学的区别。

  • Pointwise Evaluation (单点评估)：

    • 做法：给每个模型打分（1-100分）。
    • 缺点：很难标准化。评委 A 的 80 分可能等于评委 B 的 60 分。
    • Android 类比：Google Play 的星级评分。有的用户觉得 4 星是好评，有的觉得 4 星是差评，标准不统一。

  • Comparative Evaluation (比较评估)：

    • 做法：不打分，只让两个模型 PK。问评委：“A 和 B 谁更好？”
    • 优点：人（或 AI）非常擅长做“二选一”，这比打分容易得多，也准确得多。
    • Android 类比：A/B Testing。你不需要问用户“你给新 UI 打几分”，你只需要看“新 UI 的点击率是不是比旧 UI 高”。

2. 天梯算法：Elo Rating & Win Rate

第四、五页 展示了如何把“PK 结果”变成“排行榜”。

  • Win Rate (胜率矩阵)：
    • 看 Table 3-6。它统计了 Model 1 和 Model 2 打了 1000 场，赢了 900 场，胜率 90%。
  • Elo Rating / Bradley-Terry 模型：
    • 这是从国际象棋和电子竞技里借来的算法。
    • 如果一个弱队（Llama-7B）赢了一个强队（GPT-4），它的积分会暴涨。
    • LMSYS Chatbot Arena：这是目前全球公认最权威的大模型排行榜，用的就是这套逻辑。
    • Android 类比：王者荣耀/LOL 的排位分 (MMR)。你不需要知道每个玩家的具体“战斗力数值”，你只需要通过他们互相 PK 的输赢，就能算出谁是王者，谁是青铜。

3. 比较评估的四大坑 (Challenges)

虽然“打擂台”很爽，但书中（第六至九页）列出了它的致命弱点：

A. 传递性失效 (Non-transitivity) —— "剪刀石头布"

  • 理论：如果 A > B，B > C，那么理应 A > C。
  • 现实：AI 模型可能会出现 A 赢 B，B 赢 C，但 C 赢 A 的情况。
  • 原因：不同的模型擅长不同的领域（有的擅长写代码，有的擅长写小说）。
  • Android 类比：兼容性测试。App 在 Pixel 上跑得比三星好，在三星上比小米好，但这不代表在 Pixel 上一定比小米好（可能小米魔改了某个底层机制恰好兼容了）。

B. 绝对性能盲区 (Absolute Performance)

  • 问题：比较评估只能告诉你 B 比 A 好，但没告诉你 B 到底好不好。
  • 场景：
    • 情况 1：A 是垃圾，B 稍微好一点的垃圾。
    • 情况 2：A 是大神，B 是超级大神。
    • 在排行榜上，B 都在 A 上面，但你不知道它们是垃圾还是大神。
  • Android 类比：矮子里拔将军。你有两个 crash 率很高的版本，V2 比 V1 稍微稳定一点点，但这不代表 V2 就是一个合格的 Release 版本。

C. 提示词污染 (Prompt Quality)

  • 问题：LMSYS 这种公开竞技场，很多用户输入的 Prompt 都是 "Hi", "Hello" 这种没营养的词。
  • 结果：导致排行榜反映的是“谁闲聊能力强”，而不是“谁解决复杂问题能力强”。

4. 全章总结 (Summary) & 彩蛋

最后一页 总结了 Chapter 3 的核心路径，也是你学习 AI 评估的最佳路线图：

  1. 基础指标：看 Perplexity (困惑度)，但这只是参考。
  2. 硬指标：看 Functional Correctness (单元测试)，能不能跑通代码。
  3. 软指标：用 Embedding 算语义相似度，或者用 AI as a Judge（让 GPT-4 当裁判）。
  4. 终极指标：Human Evaluation (人类评估) 还是金标准，但太贵太慢，所以我们用 Comparative Evaluation (打擂台) 来逼近人类的偏好。

彩蛋 (Footnote 4)： 书中提到了 OpenAI o1 (September 2024) 和数学家 Terrence Tao (陶哲轩) 的评价。 这说明这本书极度得新！它甚至覆盖到了 2024 年 9 月发布的最新模型（o1），这在出版物中是非常罕见的。这也印证了书中关于“Test Time Compute”的内容是目前最前沿的工程实践。

评论和交流请发送邮件到 [email protected]
Wechat Donate QACode
通过微信扫描赞赏码赞助此文