AIE-AI Engineering三, 四章总结: 如何评估AI应用

本文为AI Engineering一书的三,四章总结

第 3 章：Evaluation Methodology（评估方法论）

本章聚焦自动评估技术，系统讲解如何评估基础模型的开放式输出，为第 4 章的系统级评估奠定方法论基础。

1. 评估基础模型的 6 大挑战

模型越智能，越难评估：评估复杂任务（如总结一本书）需要评估者具备同等甚至更高的专业能力，耗时巨大。
开放式输出无法对照单一 ground truth：许多任务存在多种正确答案，无法预先穷举期望输出。
黑盒性：API 模型通常不公开架构、训练数据和训练过程。
公共基准快速过时：随着模型能力泛化和快速提升，现有基准可能迅速被超越或变得无关紧要。
通用模型比任务特定模型更难评估：后者领域受限、目标明确，前者能力边界模糊。
评估超越人类能力的系统很困难：模型在某些维度上已超越人类，人类难以判断其输出质量。

核心教学点：评估投入严重落后于模型开发投入。DeepMind 论文指出，实验结果几乎只用于改进算法，极少用于改进评估方法本身。

2. 精确评估 vs 主观评估

精确评估（Exact Evaluation）：产生无歧义的判断，如功能正确性、精确匹配。
主观评估（Subjective Evaluation）：同一个人在不同时间可能给出不同分数。可通过提示设定明确评分指南来降低主观性。

3. 语言模型核心指标

这些指标衡量模型预测下一个 token 的能力，是理解模型内在能力的基础。

指标	定义与教学要点
Entropy（熵）	衡量 token 携带的平均信息量。熵越高 = 信息越多、语言越不可预测。低熵语言更易预测
Cross Entropy（交叉熵）	衡量特定语言模型预测数据集的难度。由两部分构成：(1) 数据集本身的熵（可预测性）；(2) 模型分布与真实分布的 KL 散度。训练的本质就是最小化交叉熵
BPC / BPB	每字符/每字节比特数。因不同模型分词器不同，用此标准化比较。BPB=3.43 表示模型可用 3.43 比特压缩原本 8 比特的字节，反映压缩效率
Perplexity（困惑度）	2^交叉熵，代表模型预测下一个 token 时的平均"选择数"。PPL=3 意味着模型有 1/3 概率猜对。

困惑度的关键教学要点：

结构化数据 （如代码）困惑度更低；词表越大 ，困惑度越高；上下文越长，困惑度越低。
后训练会坍塌熵（Post-training collapses entropy） ：当模型被后训练为更好地对话/回答问题时，它们被训练成以用户喜欢的方式回应，而非预测下一个 token，因此困惑度在后训练后不再是好指标 。
困惑度可用于检测训练数据 ：高困惑度文本可能不在训练数据中；也可用于检测异常文本（不可预测、表达不寻常想法）。

4. 精确评估方法

A. Functional Correctness（功能正确性）

终极指标：系统是否完成了它该做的事？
代码生成可直接执行并验证测试用例；游戏 bot 可直接看分数。
基准测试中的 pass@k：模型尝试解决问题的次数越多，通过概率越高。基准可表示为"3 次尝试后 50% 通过"或"10 次尝试后 90% 通过" 。
有可测量目标的任务通常可用功能正确性评估。

B. Similarity to Reference Data（与参考数据相似度）

用于无法自动化验证功能正确性的任务（如翻译），共 4 种方法：

方法	说明
人工评估者判断	金标准，但耗时耗资源，不可扩展
精确匹配检查	对短输出有效，对长/创意输出无用，二元结果
Lexical Similarity（词汇相似度）	BLEU、ROUGE、METEOR 等 n-gram 指标。缺点是措辞不同但正确的回答可能得分很低，且优化词汇相似度不一定提升功能正确性
Semantic Similarity（语义相似度）	将文本转为 embedding 比较含义。比词汇相似度更鲁棒，但高度依赖 embedding 模型质量

5. AI-as-a-Judge（AI 作为裁判）

用一个 AI 评估另一个 AI 的输出，是新兴但有争议的方法。

AI 裁判的 3 种主要方法：

Individual Response Evaluation：独立评估回答质量，常用数值评分（如 1-5 分）。
Reference Response Comparison：将生成回答与参考答案比较，通常输出二元结果。
Generated Response Comparison（成对比较）：比较两个生成回答，预测用户偏好哪个------对后训练对齐和测试时计算优化至关重要。

如何提示 AI 裁判：

应解释任务、评估标准和评分系统（分类、数值、连续数值）。
带示例的提示表现更好，但会增加 token 数和成本。

主要局限与教学要点：

不一致性：AI 裁判是概率性的，分数波动导致结果难以复现。
同义反复疑虑：许多团队犹豫采用此方法，因为它看起来是同义反复（tautological）。
标准模糊性：开源工具中的评估标准不统一，Azure AI Studio 的 relevance 分数可能与 MLflow 的 relevance 分数完全不同，容易导致误解和误用。
自我偏好偏差：模型倾向于给自己的输出更高分（GPT-4 给自己高 10% 胜率）。
位置偏差：比较时往往偏好第一个看到的答案（与人类近因偏差相反）。
冗长偏差：偏好更长、更详细的回答，即使包含事实错误。
不可信任原则："如果你看不到用于裁判的模型和提示，就不要信任 AI 裁判。"
监控稳定性：随着应用发展，评估方式应理想地固定，以便用评估指标监控应用变化。

AI 裁判在生产中的使用：

可用作**护栏（guardrails）**降低风险。
可用更弱的模型作为裁判以降低成本，或在生产中抽查子集。
会增加延迟，因此如果用例允许，可在返回给用户后再评估。

6. 专用 AI 裁判（Specialized Judges）

挑战"必须用最强模型当裁判"的常识，小型专用裁判在特定任务上可与大型模型一样有效，且更经济高效。

类型	功能
Reward Model	对 (prompt, response) 输出质量分数，用于 RLHF
Reference-based Judge	将生成回答与参考答案比较输出相似度分数
Preference Model	对 (prompt, response1, response2) 预测人类偏好哪个------偏好数据对模型对齐至关重要但获取昂贵

7. 比较评估（Comparative Evaluation）

逐点评估（Pointwise）：独立打分再排序。
成对比较（Pairwise）：直接判断 A 是否比 B 好------对人类和 AI 裁判来说，判断"哪个更好"通常比给绝对分数更可靠、认知负荷更低。
这是 LMSYS Chatbot Arena 的核心原理。
局限：数据密集、缺乏标准化、难以将比较度量转换为绝对度量。

第 4 章：Evaluate AI Systems（评估 AI 系统）

本章将方法论落地，讨论如何为应用选择模型 并构建可靠的评估管道 。作者称这是她写过的"最难但最重要"的主题------没有可靠的评估管道是 AI 落地的最大障碍 。

1. 评估驱动开发（Evaluation-Driven Development, EDD）

受软件工程 TDD 启发：在构建应用之前先定义如何评估。
与 TDD 关键区别：目标不是 100% 覆盖，否则会导致在评估集上过拟合。

2. 四大评估标准（Four Pillars）

A. Domain-Specific Capability（领域特定能力）

评估模型是否理解特定领域（法律、医学、代码等）。
多项选择评估（Multiple-Choice Question Scoring, MCQS） ：常见评估方式，让模型从多个实现中选出功能正确的。但问题表述的微小变化会导致性能变化，导致脆弱的评估（fragile evaluations）。
MCQS 在评估生成任务（摘要、翻译、论文写作）时严重不足。

B. Generation Capability（生成能力）

从传统 NLP 的 NLG 指标演化而来：

指标	状态
Fluency（流畅性）	语法正确性、自然度。基本已解决
Coherence（连贯性）	逻辑结构
Faithfulness（忠实性）	主要用于翻译
Relevance（相关性）	主要用于摘要

现代重点：Factual Consistency（事实一致性）和 Safety（安全性） 。

事实一致性分两种设置：

局部（Local）：输出与给定上下文一致。用于摘要、客服、RAG。
全局（Global）：输出与开放世界知识一致。用于聊天机器人、事实核查。
无上下文验证更难 ：必须搜索并挑选可靠来源，常遇到无证据谬误（absence-of-evidence fallacy）------找不到证据不等于事实错误。
模型幻觉高发区：（1）小众知识；（2）关于不存在事物的查询（如"X 对 Y 说了什么？"当 X 从未谈论过 Y 时）。

幻觉检测 4 种方法：

方法	原理
AI as a judge	GPT-3.5/GPT-4 优于早期方法。GPT-judge 在 TruthfulQA 上预测人类真实性达 90-96% 准确率
Self-Verification（SelfCheckGPT）	对同一提示生成 N 个额外响应，检查一致性。有效但昂贵
Knowledge-Augmented Verification（SAFE）	Google DeepMind 方法：将长回答拆分为原子声明，使声明自包含，搜索 Google，检查与搜索结果的一致性
Textual Entailment（NLI）	将（前提，假设）对分类为 entailment（蕴含）、contradiction（矛盾）或 neutral（中性）。专用评分器：DeBERTa-v3-base-mnli-fever-anli（184M 参数，在 764K 标注对上训练）

Safety（安全性）------6 类不安全内容：

不当语言（脏话、露骨内容）
有害教程（"如何抢劫银行"）
仇恨言论（种族主义、性别歧视、恐同）
暴力（威胁、血腥细节）
刻板印象（如护士总是女性名字）
政治和宗教偏见（Feng et al. 2023 发现 GPT-4 倾向左翼自由主义，Llama 倾向威权主义）

工具与基准：Facebook 仇恨言论分类器、Skolkovo 毒性分类器、Perspective API；RealToxicityPrompts（10 万自然毒性诱发提示）、BOLD 。

C. Instruction-Following Capability（指令遵循能力）

输出是否遵守指定约束（长度、格式等）。
指令-性能悖论（Instruction-Performance Paradox） ：表现差可能是指令本身模糊 ，而非模型能力不足------指令遵循质量不能脱离指令质量本身来评估 。
解决方案：开发针对应用需求的自定义基准。

D. Cost and Latency（成本与延迟）

帕累托优化（Pareto Optimization）：不同指标间存在权衡，没有单一最优解。明确哪些维度不可妥协。

延迟指标：

TTFT（Time To First Token）：首 token 时间
TPOT（Time Per Output Token）：每输出 token 时间
加上 token 间时间和每查询时间

优化杠杆：要求简洁响应的提示、停止条件、模型选择。

评估延迟时区分"must-have"和"nice-to-have"：高延迟会让用户感到烦躁、不耐烦，但很少会因为"慢了几秒"就彻底放弃使用这个产品。

成本：

模型 API 按输入+输出 token 收费；自托管有固定计算成本，且随着规模增长每 token 成本下降。
7B 和 65B 参数大小存在是因为它们分别最大化 24GB 和 80GB GPU。
随着规模变化重新评估成本。

3. 模型选择（Model Selection）

4 步评估工作流（迭代过程）：

硬属性过滤：按部署需求、安全隐私、许可限制、资源约束筛选。
公共信息评估：审查基准性能、排行榜排名、延迟和成本指标。
实验评估：用特定用例进行实际测试，包括自定义指标和集成需求。
持续监控：定期性能监控、故障检测、反馈收集。

自建模型 vs API 模型：7 维度决策 ：

数据隐私、数据血缘、性能、功能、控制力、成本、易用性。此决策因团队需求和意愿而异。

4. 公共基准测试（Public Benchmarks）的陷阱

现有数千个公共基准，但只能帮你淘汰差模型，无法帮你找到最适合你应用的模型。
数据污染严重：基准数据已被纳入许多模型的训练数据。
公共排行榜聚合多个基准排名模型，但基准如何选择、如何聚合的过程不透明。
模型选择的本质 = 基于自身需求创建私有排行榜 。

5. 设计评估管道（Evaluation Pipeline）

Step 1: 评估系统所有组件

既要做端到端（End-to-end）系统评估 ，也要做组件级（Component-level）评估。
示例：从简历 PDF 提取当前雇主：
1. PDF 转文本（用与 ground-truth 文本的相似度评估）
2. 文本到当前雇主（给定正确文本时评估准确率）
没有组件级评估，无法判断系统在哪一环断裂。

Turn-based vs Task-based：

Turn-based：每次输出的质量（可能包含多步）。
Task-based：系统是否实际完成用户目标？用了多少轮？BIG-bench 中的 twenty_questions 是干净的 task-based 示例。

Step 2: 创建评估指南（Evaluation Guideline）------最关键的一步

难点不是判断输出是否好，而是定义"好"是什么。
LinkedIn 教训：对于职位评估，"你完全不适合"在技术上正确但无用。好的回答应解释差距并建议如何弥补 。
LangChain State of AI 2023：用户平均每个应用使用 2.3 个不同标准 。

创建评分标准（Scoring Rubrics）：

可选系统：二元(0/1)、1-5、 $-1, 0, 1$ 用于蕴含等。
用人类（自己、同事）验证：如果人类不能遵循标准，AI 也不能。
额外好处：指南可稍后复用于微调数据标注。

将技术指标映射到业务指标：

80% 事实一致性 → 自动化 30% 客服
90% → 自动化 50%
98% → 自动化 90%
定义有用性阈值（usefulness threshold）：例如必须至少达到 50% 才有用。

Step 3: 定义方法与数据

选择评估方法：

混合搭配：廉价分类器处理 100% 数据 + 昂贵 AI 裁判处理 1% = 可控成本且有信心。
使用 logprobs（如果可用）测量模型置信度，对分类、困惑度、流畅度至关重要。
不要忽视人工评估：LinkedIn 每天手动评估多达 500 次对话。

标注评估数据：

尽可能使用真实生产数据。
使用自然标签（如果存在）。
数据切片（Data Slicing） ：
- 避免对少数群体的偏见
- 调试子集失败（长输入、特定主题）
- 避免辛普森悖论（Simpson's Paradox）：A 在每个子组都击败 B，但总体上输了。
保持多个评估集：生产分布、频繁失败、频繁用户错误（拼写错误！）、超出范围请求。

样本量（How Much Data?）：

使用 bootstrap：从集合中有放回地抽取 N 个样本，评估，重复。若结果波动大，需更多数据。
OpenAI 95% 置信度指导（分数差异 vs 所需样本量）：

可检测分数差异	所需样本量
30%	~10
10%	~100
3%	~1,000
1%	~10,000

经验法则：可检测差异减少 3 倍 → 样本量增加 10 倍。
参考值：EleutherAI 的 lm-evaluation-harness 中位基准大小 1,000 例（平均 2,159）；Inverse Scaling Prize 下限 300，偏好 1,000+（尤其合成数据时）。

元评估（Meta-Evaluation）------评估你的评估管道：

正确信号？ 更好的回答得分更高？更好的指标是否与更好的业务成果相关？
可靠性？ 运行两次，结果相同？将 AI 裁判温度设为 0。
指标相关性？ 删除冗余指标，调查完全不相关的指标（是信号还是噪音？）。
成本与延迟？ 不要为了节省延迟而跳过评估，这是冒险的权衡。

迭代（Iterate）：

跟踪一切：评估数据、标准、提示、采样配置。否则无法判断指标变化反映的是应用变化还是评估变化。

6. 核心结论

不存在完美的评估方法。用一维或几维分数无法捕捉高维系统的能力。
现代 AI 评估充满局限和偏差，但这不意味着不做评估。
组合多种方法（精确评估 + AI 裁判 + 人工评估）可以缓解许多挑战。

两章关系：第 3 章提供"工具箱"（各种评估方法及其原理、公式与局限），第 4 章提供"施工图纸"（如何将这些工具组合成适合你业务的评估管道，包括标准定义、模型选择、样本量计算、元评估等）。评估不是一次性工作，而是贯穿整个应用开发周期的持续活动。