419 lines
27 KiB
Markdown
419 lines
27 KiB
Markdown
|
# 从零开始做 LLM 评测：每一步背后的道理
|
|||
|
|
|
|||
|
|
**写给谁：** 有多年编程经验，但还没有做过大模型数据标注、模型评测、RAG 或 Agent 的人。
|
|||
|
|
|
|||
|
|
**这篇文章只解决一个问题：** 当你开始做第一个 LLM 评测项目时，为什么要先写 case、写 rubric、手工比较、保存运行记录和分类失败？这些动作表面很琐碎，背后分别在训练什么能力？
|
|||
|
|
|
|||
|
|
> **阅读位置：** 这是一份入门的“Why Guide”，建议先读它以建立判断框架；随后再阅读配套的《LLM 评测工程实战路线图》，将这里的原则落实为目录结构、JSON schema、trial、校准、CI 与作品集。两份材料不应合并：前者解释为什么，后者说明怎么做。
|
|||
|
|
|
|||
|
|
## 先把“入门”说清楚
|
|||
|
|
|
|||
|
|
入门并不是“会调用一个大模型 API”，也不是“知道 RLHF、RAG、Agent 这些名词”。对一个程序员而言，真正的入门标志是：面对一个 AI 功能，你能把模糊的要求变成一套别人也能执行的判断方法，并在它表现不好时说清楚**坏在哪里、下一步该改哪里、改完如何证明没有退步**。
|
|||
|
|
|
|||
|
|
这就是为什么我们把数据标注理解为**规格工程**。传统程序常常有明确的输入输出和断言：传入两个整数，返回它们的和。AI 功能则经常只有一句产品愿望，例如“回答用户问题要准确、专业、别瞎编”。这不是可测试的规格，只是一个愿望。你的工作就是把愿望逐步变成 test case、rubric、run 和回归检查。
|
|||
|
|
|
|||
|
|
> **你并不是在学习“如何评价模型好不好”。你是在学习：如何把人的期待转译成一套可重复执行的测试。**
|
|||
|
|
|
|||
|
|
OpenAI 将 eval 描述为对模型输出进行结构化测试，并强调先定义任务、准备数据、使用评分器，再分析结果与持续迭代。[1] 对 Agent，评测对象还会延伸到工具调用、完整轨迹与环境最终状态，而不只是最后一句回答。[2]
|
|||
|
|
|
|||
|
|
## 一个总的认知模型：先建立“判断能力”，再追求自动化
|
|||
|
|
|
|||
|
|
初学者最容易掉进一个误区：以为项目的顺序是“选模型 → 调 API → 得分 → 优化”。实际更可靠的顺序恰好相反：
|
|||
|
|
|
|||
|
|
```text
|
|||
|
|
我希望用户得到什么
|
|||
|
|
↓
|
|||
|
|
什么情况算成功、什么情况算失败
|
|||
|
|
↓
|
|||
|
|
如何构造能暴露这些情况的案例
|
|||
|
|
↓
|
|||
|
|
如何让人或程序按照同一规则判断
|
|||
|
|
↓
|
|||
|
|
最后才是：系统、模型或提示词到底表现如何
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
为什么？因为如果“什么算好”没有定义清楚，后面所有的平均分、排行榜和 A/B 对比都没有意义。你只是在给一个没有尺子的对象报数字。
|
|||
|
|
|
|||
|
|
| 初学动作 | 表面上在做什么 | 真正训练的能力 | 如果跳过会怎样 |
|
|||
|
|
|---|---|---|---|
|
|||
|
|
| 选一个很小的任务 | 缩小项目 | 让成功条件可观察、可验证 | 任务范围无边界，最后只能说“感觉不太好”。 |
|
|||
|
|
| 写 10—20 个 case | 准备数据 | 发现真实路径、边界和负例 | 只会测试自己最容易想到的正常问题。 |
|
|||
|
|
| 写 rubric | 写评分标准 | 把个人直觉变成操作定义 | 不同人或同一个人隔天可能给出不同结论。 |
|
|||
|
|
| 手工盲评 | 比较两个答案 | 识别规则歧义和个人偏好 | 会把“我喜欢某模型”误当成“模型更好”。 |
|
|||
|
|
| 保存 run | 存模型输出 | 分离测试定义与一次执行 | 无法解释版本差异，也无法重现结论。 |
|
|||
|
|
| 写最小脚本 | 做统计 | 把个案感受升级为可重复观察 | 每次比较都要手工翻记录，结论不可审计。 |
|
|||
|
|
| 分类失败 | 记录坏答案 | 将“错误”变为可修复的 bug | 所有问题都被粗暴归因成“模型不行”。 |
|
|||
|
|
| 重跑旧 case | 做回归 | 验证修复不是以牺牲别处为代价 | 修好一个问题后，旧能力会悄悄退化。 |
|
|||
|
|
|
|||
|
|
下面用一个**公开文档问答**的小项目，把这些动作逐步讲透。它不是因为 RAG 最热门，而是因为它对初学者的“对错边界”较清楚：答案应该受给定文档约束。等你理解这一套，再换成工具调用 Agent，结构仍然一样。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 第 0 步：为什么第一个项目要“小、可验证、可失败”
|
|||
|
|
|
|||
|
|
假设你选择的任务是：
|
|||
|
|
|
|||
|
|
> 用户给出问题和一段公开文档，系统应只依据这段文档作答；文档没有答案时，系统应明确说“无法从资料确认”。
|
|||
|
|
|
|||
|
|
这个任务看起来很普通，却比“做一个聪明客服”更适合入门。原因不是技术难度，而是它把问题的三个关键部分固定住了：**输入是什么、证据从哪里来、什么行为不允许。**
|
|||
|
|
|
|||
|
|
如果你第一天选择“做一个全能 Agent”或“评价回答是否专业”，你会立刻遇到一个根本问题：谁来定义“全能”或“专业”？没有业务边界时，任何失败都可以被解释成“模型也许本来就做不到”，你学不到如何设计判断。
|
|||
|
|
|
|||
|
|
初学项目应遵守下面的选择标准：
|
|||
|
|
|
|||
|
|
| 标准 | 为什么重要 | 合格例子 | 不适合作为第一个项目的例子 |
|
|||
|
|
|---|---|---|---|
|
|||
|
|
| 你能判断主要对错 | 没有判断能力就无法写 rubric | API 参数是否满足 schema；答案是否有文档证据 | “这个回答有没有洞见？” |
|
|||
|
|
| 可用公开或合成数据 | 避免隐私、授权和脱敏阻塞学习 | 公开技术文档、开源 README、玩具数据库 | 客户工单、内部代码库、真实生产日志 |
|
|||
|
|
| 失败有清晰形态 | 失败分类才有意义 | 无依据编造、漏约束、引用错误 | “用户好像不满意” |
|
|||
|
|
| 可以在本地安全地重复跑 | 评测的价值来自比较和回归 | 只读问答、假工具、模拟状态 | 真正删库、发邮件、改日历 |
|
|||
|
|
|
|||
|
|
> **小，不是降低标准；小是降低干扰。**
|
|||
|
|
>
|
|||
|
|
> 你暂时不学习大规模数据生产、模型微调或复杂平台，是为了先看清“需求—判断—失败—修复”这条主线。
|
|||
|
|
|
|||
|
|
### 你此时真正学到什么
|
|||
|
|
|
|||
|
|
你开始理解：评测不是找一个很强的模型来“答题”，而是设计一个环境，让系统的好坏能够被看见。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 第 1 步：为什么要先写“成功条件”，而不是先跑模型
|
|||
|
|
|
|||
|
|
初学者常会直接把问题丢给几个模型，再挑一个看起来更好的答案。这很自然，但它只能帮助你体验模型，不能帮助你建立评测能力。
|
|||
|
|
|
|||
|
|
先把任务写成一句可操作的成功条件，例如：
|
|||
|
|
|
|||
|
|
> 对于给定上下文，回答中的每一个关键事实必须能在上下文中找到支持；上下文没有支持时，必须明确说明不确定，而不是补全猜测。
|
|||
|
|
|
|||
|
|
这句话做了两件重要的事。
|
|||
|
|
|
|||
|
|
第一，它把“回答准确”变成了**证据关系**。我们不需要争论模型是否拥有世界知识，只问这个回答是否由当前任务允许的证据支持。
|
|||
|
|
|
|||
|
|
第二，它明确了“资料不足时怎么办”。很多 LLM 失败不是因为完全胡说，而是因为它在知道一点点信息时，自信地把空白补满。若你不事先规定“可以拒答”，模型越流畅反而越危险。
|
|||
|
|
|
|||
|
|
| 模糊愿望 | 为什么无法评估 | 可操作的改写 |
|
|||
|
|
|---|---|---|
|
|||
|
|
| 回答要专业 | 专业对不同人含义不同 | 回答应给出文档中定义的配置字段和限制条件。 |
|
|||
|
|
| 不要幻觉 | “幻觉”过于抽象 | 不得陈述任何上下文未支持的参数、默认值或时间点。 |
|
|||
|
|
| 尽量帮助用户 | 容易鼓励猜测 | 缺少证据时说明无法确认，并指出需要哪类补充资料。 |
|
|||
|
|
| Agent 要完成任务 | 不知道只看文本还是看真实动作 | 工具调用必须授权、参数合法，且环境状态满足预期。 |
|
|||
|
|
|
|||
|
|
### 隐藏的道理：这是在做“可判定性设计”
|
|||
|
|
|
|||
|
|
软件测试不会直接断言“这个服务很好”；它断言“调用返回 200”“数据库出现预期记录”“权限检查拒绝未授权用户”。AI 评测也一样。你正在把人的期望转化为可观察、可验收的信号。这里说的不是生产系统中 logs、metrics、traces 意义上的可观测性，而是让成功条件本身变得可判定。
|
|||
|
|
|
|||
|
|
如果没有这一步，后续的评分器只能评价语言是否顺口，无法评价系统是否真的可靠。
|
|||
|
|
|
|||
|
|
### 最小行动
|
|||
|
|
|
|||
|
|
花 15 分钟写四行，不要超过半页：
|
|||
|
|
|
|||
|
|
```text
|
|||
|
|
任务：给定文档片段回答技术问题。
|
|||
|
|
成功：关键事实都能由文档支持；资料不足时明确说明。
|
|||
|
|
失败：无依据事实、遗漏关键限制、把不确定说成确定。
|
|||
|
|
非目标：不评模型是否知道文档以外的世界知识。
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### 你此时真正学到什么
|
|||
|
|
|
|||
|
|
你开始从“模型给什么答案”转向“产品到底要求什么行为”。这就是规格工程的起点。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 第 2 步：为什么起步只写 10—20 个 case，而不是 100 个
|
|||
|
|
|
|||
|
|
“样本越多越好”是传统数据思维的惯性，但在入门阶段，样本数量不是瓶颈，**你对失败空间的理解**才是。
|
|||
|
|
|
|||
|
|
先写 10—20 个 case，是为了迫使你回答一个更难的问题：用户会以哪些不同方式使用系统？哪些情况最容易诱发错误？你写不出来，恰恰说明你还没有足够理解任务，而不是说明你需要更多数据。
|
|||
|
|
|
|||
|
|
建议先用如下小分布，而不是随机列 20 个问题：
|
|||
|
|
|
|||
|
|
| 样本类型 | 初始数量 | 为什么要有 |
|
|||
|
|
|---|---:|---|
|
|||
|
|
| 文档可完整回答 | 8 | 验证核心功能是否成立。 |
|
|||
|
|
| 文档完全没有答案 | 4 | 观察系统是否乱猜。 |
|
|||
|
|
| 文档只支持部分答案 | 3 | 观察系统能否承认边界，而非二元化地答或不答。 |
|
|||
|
|
| 多片段才能回答 | 2 | 暴露遗漏证据、拼接错误或片面回答。 |
|
|||
|
|
| 容易诱发常识补全 | 2 | 检测看似合理但无证据的内容。 |
|
|||
|
|
| 格式或对抗边界 | 1 | 检查关键约束是否在压力下仍被遵守。 |
|
|||
|
|
|
|||
|
|
这 20 个 case 不是“训练数据”，而是**你写给系统的 20 个问题**。每个问题都在问：“当我换一种真实但容易出错的条件时，你还能遵守同一个行为标准吗？”
|
|||
|
|
|
|||
|
|
如果时间只够做 **10 个 case**，不要把所有类别机械地等比例砍半。优先保留：4 个正常路径、3 个资料不足、2 个幻觉诱发或部分支持、1 个边界条件。多证据、格式和对抗类可以留到第二版；第一版必须先学会测试“能答”与“不能答时不乱猜”这两个核心行为。
|
|||
|
|
|
|||
|
|
### 为什么负例和资料不足特别重要
|
|||
|
|
|
|||
|
|
人类测试软件时，不只测试“正确密码能不能登录”，还测试“错误密码是否被拒绝”“没有权限是否被阻断”。对于 LLM，资料不足的问答就相当于负向权限测试：系统是否知道自己不能确认？
|
|||
|
|
|
|||
|
|
如果你的 20 条 case 全是“文档里有明确答案的问题”，任何流畅模型都可能表现不错，你得到的是一种虚假的安全感。真正有信息量的，是它被要求**不要猜**时会怎样。
|
|||
|
|
|
|||
|
|
### 最小行动
|
|||
|
|
|
|||
|
|
先只选三页公开文档。每页写：两个能回答的问题、一个不能回答的问题、一个“看起来能回答但其实需要文档外知识”的问题。你马上就会有 12 个有结构的 case。
|
|||
|
|
|
|||
|
|
### 你此时真正学到什么
|
|||
|
|
|
|||
|
|
你会发现数据集不是“从网上找来的材料”，而是你对风险、边界和用户行为的编码。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 第 3 步：为什么 rubric 比参考答案更重要
|
|||
|
|
|
|||
|
|
许多初学者会为每个问题写一份“标准答案”，然后拿模型输出逐字比对。这样做在计算题中有效，在自然语言任务里却常常失败。
|
|||
|
|
|
|||
|
|
同一个正确答案可以有不同措辞；同一个看起来像参考答案的输出，也可能漏掉了最关键的安全限制。参考答案只是一个例子，rubric 才是**判定逻辑**。
|
|||
|
|
|
|||
|
|
以“根据文档回答问题”为例，第一版 rubric 可以只有三项：
|
|||
|
|
|
|||
|
|
| 维度 | 通过意味着什么 | 失败意味着什么 | 为什么这样设计 |
|
|||
|
|
|---|---|---|---|
|
|||
|
|
| 有据性 | 每个关键事实能在上下文找到支持 | 出现至少一条无依据事实 | 直接约束幻觉风险。 |
|
|||
|
|
| 缺失信息处理 | 资料不足时明确说明 | 把未知内容说成确定结论 | 让“拒答”成为正确行为。 |
|
|||
|
|
| 任务完成度 | 覆盖问题中的必要部分 | 漏掉核心限制或答偏 | 防止系统只写安全套话却不解决问题。 |
|
|||
|
|
|
|||
|
|
第一版优先使用 `pass/fail` 或 `0/1/2`，不要上来就给“专业度、清晰度、帮助性”各打 1—5 分。原因不是细粒度评分不好，而是你还没有建立足够的锚点：3 分与 4 分差在哪里？如果人自己答不清，模型评分器更不可能稳定答清。
|
|||
|
|
|
|||
|
|
### 隐藏的道理：rubric 是“把主观判断拆成可讨论的部件”
|
|||
|
|
|
|||
|
|
当你说“这个回答不行”，另一个人无法知道你是在意事实错误、遗漏限制、语气不好还是格式不对。rubric 迫使你把这些混在一起的感受拆开。
|
|||
|
|
|
|||
|
|
一旦拆开，分歧才有价值：如果两个人都同意答案不完整，但对是否无依据有分歧，就说明你应该补“什么叫关键事实”或补文档证据，而不是泛泛地争论谁判断对。
|
|||
|
|
|
|||
|
|
### 最小行动
|
|||
|
|
|
|||
|
|
为每一项 rubric 写一个正例和一个反例。例如：
|
|||
|
|
|
|||
|
|
```text
|
|||
|
|
有据性通过：文档写“默认保留 7 天”，回答“默认保留 7 天”。
|
|||
|
|
有据性失败：文档未说明默认值，回答“默认保留 30 天”。
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
不要试图写完整手册。你要的是第一版可执行规则；规则本来就应该在使用中改进。
|
|||
|
|
|
|||
|
|
### 你此时真正学到什么
|
|||
|
|
|
|||
|
|
你开始区分“答案内容”与“判定答案的规则”。前者会变化，后者才是质量体系的核心资产。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 第 4 步：为什么要让两个候选答案进行盲评
|
|||
|
|
|
|||
|
|
你可以让两个模型回答，也可以让同一个模型使用两个不同提示词回答。这里的关键不在于选出“冠军模型”，而在于制造一个更容易判断的比较场景。**A/B 成对比较是很好的教学起点，不是评测的必要条件。** 评测也可以只判断单个输出是否满足 rubric，这叫 pointwise evaluation；当你尚未有两个候选或只需验收一个系统版本时，单输出判定完全足够。
|
|||
|
|
|
|||
|
|
人类通常不擅长凭空给一个复杂答案打绝对分数，却更擅长比较两个候选：哪一个事实更有依据？哪一个遗漏更少？哪一个在资料不足时更克制？这也是偏好数据常见采用成对比较的原因。
|
|||
|
|
|
|||
|
|
但必须**盲评**：把模型名隐藏，把输出随机标为 A 和 B，再先按 rubric 逐条评分，最后才揭示来源。否则你会不自觉地偏袒自己熟悉或期待更强的模型，把品牌印象混入判断。
|
|||
|
|
|
|||
|
|
### 盲评不是为了假装客观，而是为了暴露偏差
|
|||
|
|
|
|||
|
|
盲评不能消除所有主观性，却能消除一种很具体的干扰：你知道答案来自谁。它还会暴露另一个重要问题：如果你连 A 与 B 谁更好都说不清，通常不是模型问题，而是 rubric 太模糊、case 缺证据，或者任务根本不适合当前的自动化标准。
|
|||
|
|
|
|||
|
|
最小盲评记录无需复杂，包含下面五件事即可：
|
|||
|
|
|
|||
|
|
```text
|
|||
|
|
case_id：正在评哪个问题
|
|||
|
|
A / B：随机位置的两个输出
|
|||
|
|
每个维度的判定：pass/fail 或 0/1/2
|
|||
|
|
reason：一句可复核理由
|
|||
|
|
confidence：high / low；low 表示需要回头改规则的难例
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### 你此时真正学到什么
|
|||
|
|
|
|||
|
|
你不只是在“给模型评分”，而是在测试你的评分规则：它是否足够清楚，能否支持比较，是否能解释理由。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 第 5 步：为什么必须保存 run，而不是只截图或记结论
|
|||
|
|
|
|||
|
|
第一次做项目时，把结果复制到一个文档里似乎就够了。但只要你改了提示词、换了模型、更新了文档或重新跑了一次，就会遇到一个问题：**你现在看到的差异到底来自哪里？**
|
|||
|
|
|
|||
|
|
因此需要区分两类东西：
|
|||
|
|
|
|||
|
|
```text
|
|||
|
|
Case 定义：我想测试什么、成功条件是什么。
|
|||
|
|
Run 记录：这个版本的系统在某个时间、某个配置下实际输出了什么。
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
这个区分就是 `Test Definition ≠ Test Execution`。它的意义与传统测试完全一样：测试用例不应随一次执行结果被改写；否则你无法比较不同版本，更无法追溯错误。
|
|||
|
|
|
|||
|
|
| 应该稳定保存的定义 | 每次运行才生成的记录 |
|
|||
|
|
|---|---|
|
|||
|
|
| 问题、上下文、预期行为、类别、rubric 版本 | 模型名、提示词/系统版本、温度、trial、输出、延迟、评分结果 |
|
|||
|
|
| 为什么测这个 case | 这次系统到底做了什么 |
|
|||
|
|
| `datasets/` | `runs/` |
|
|||
|
|
|
|||
|
|
保存 run 不是“为了看起来工程化”，而是为了保留实验条件。没有条件记录的结论无法重现；无法重现的结论，就不能指导后续修改。
|
|||
|
|
|
|||
|
|
### 最小行动
|
|||
|
|
|
|||
|
|
不必先建数据库。一个 JSONL 文件够用。每次运行至少记录：`case_id`、模型或系统版本、日期、`trial`、输出与评分。大输入不要重复复制，记录 `case_id` 和版本号即可。
|
|||
|
|
|
|||
|
|
### 你此时真正学到什么
|
|||
|
|
|
|||
|
|
你会开始把模型输出看作一次**实验观测**，而不是一次聊天记录。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 第 6 步：为什么第一版要亲手评分，而不是直接让 LLM Judge 打分
|
|||
|
|
|
|||
|
|
“让一个模型评价另一个模型”看起来很省事，但对刚入门的人，它容易掩盖真正的问题：你还不知道自己的标准是否成立。
|
|||
|
|
|
|||
|
|
如果 Judge 给出 `fail`，你需要能判断：这是 Judge 理解错了、rubric 有歧义、参考证据不完整，还是被评输出真的不合格？如果你自己从未评过一批样本，无法回答这个问题，就没有资格信任自动 Judge。
|
|||
|
|
|
|||
|
|
所以顺序应是：
|
|||
|
|
|
|||
|
|
```text
|
|||
|
|
先手工评一小批
|
|||
|
|
↓
|
|||
|
|
发现哪些地方难判
|
|||
|
|
↓
|
|||
|
|
修改 rubric / case / reference
|
|||
|
|
↓
|
|||
|
|
再让 Judge 按同一规则评分
|
|||
|
|
↓
|
|||
|
|
比较 Judge 与人工不一致的 case
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
这不是反对自动化，而是在建立自动化的基准。自动 Judge 的真正用途是把已被校准的判断放大，而不是代替你决定什么叫好。
|
|||
|
|
|
|||
|
|
### 你此时真正学到什么
|
|||
|
|
|
|||
|
|
你会理解“人工”不是低级替代品，而是定义和校准质量标准的来源。自动化是在这之后提高规模与速度。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 第 7 步：为什么要分类失败，而不是只看总分
|
|||
|
|
|
|||
|
|
假设模型 A 的通过率是 80%，模型 B 是 82%。如果不看失败内容，你很容易得出“B 更好”。但这 2% 的差异可能来自格式小问题，也可能掩盖 B 在资料不足时更容易编造事实。
|
|||
|
|
|
|||
|
|
因此，每个失败至少标一个原因。对于文档问答项目，第一版可以只用下面五类：
|
|||
|
|
|
|||
|
|
| 失败类型 | 它在问什么 | 下一步通常改哪里 |
|
|||
|
|
|---|---|---|
|
|||
|
|
| 无依据事实 | 回答是否补充了证据外内容 | prompt、上下文约束、检索质量。 |
|
|||
|
|
| 漏掉关键限制 | 是否只答了容易部分 | rubric、上下文覆盖、提示词。 |
|
|||
|
|
| 不当确定 | 资料不足时是否还在下结论 | 拒答规则、示例、评分器。 |
|
|||
|
|
| 引用 / 格式错误 | 是否能让用户核对来源 | 后处理、输出 schema。 |
|
|||
|
|
| 评分不确定 | 人也难稳定判定 | 修改 rubric、补证据或保留人工仲裁。 |
|
|||
|
|
|
|||
|
|
这五类是**没有独立检索层和工具调用层的小型文档问答项目的简化子集**，不是通用终点。当你引入实际检索、路由、工具参数、授权和执行环境后，应将失败进一步拆分为检索错误、路由错误、工具选择错误、参数错误、权限错误、执行错误、后处理错误和 grader 错误；这些扩展分类见配套实战路线图。
|
|||
|
|
|
|||
|
|
### 隐藏的道理：failure taxonomy 是 AI 系统的缺陷分类表
|
|||
|
|
|
|||
|
|
传统 bug 不会只写“程序不对”；会区分空指针、竞态、权限、数据库约束或超时。AI 系统也一样。输出错误可能来自检索没有拿到证据、提示词没有强调约束、模型没理解、工具参数错误，甚至是评分器误判。
|
|||
|
|
|
|||
|
|
分类的目的不是写出漂亮报告，而是让**不同的错误得到不同的修复**。如果所有失败都叫“幻觉”，你无法判断要改数据、改检索、改提示词、改工具还是改 grader。
|
|||
|
|
|
|||
|
|
### 你此时真正学到什么
|
|||
|
|
|
|||
|
|
你从“评价结果”进入“诊断系统”。这是程序员进入评测工作的真正分水岭。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 第 8 步：为什么要改一个地方，再重跑旧 case
|
|||
|
|
|
|||
|
|
评测不是为了给模型发成绩单，而是为了帮助你做改变。例如发现资料不足时经常乱猜，你可能在提示词里加入“缺证据时说明无法确认”的规则。然后重跑原来的 case。
|
|||
|
|
|
|||
|
|
这看起来简单，却包含一个重要实验原则：**尽可能控制变量，并完整记录所有变化，再看结果是否变化。** 初学时优先一次改一个可解释因素，这样最容易学习因果关系；真实系统修复有时必须同时改检索与提示词，或同时改工具 schema 与策略，这并不违反原则，但必须把每一项改动写入 run 与报告。否则结果提高了也不知道是哪一个改变起作用。
|
|||
|
|
|
|||
|
|
更重要的是，不只重跑失败 case，也要重跑一小组原本通过的 case。因为 AI 系统常有“修 A 坏 B”的现象：为了更谨慎，它可能变得过度拒答；为了更详细，它可能引入更多无依据内容。
|
|||
|
|
|
|||
|
|
这就是回归测试的意义：
|
|||
|
|
|
|||
|
|
```text
|
|||
|
|
发现失败
|
|||
|
|
→ 形成 case
|
|||
|
|
→ 修改系统
|
|||
|
|
→ 重跑旧 case
|
|||
|
|
→ 既看修复是否成功，也看是否引入新问题
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### 你此时真正学到什么
|
|||
|
|
|
|||
|
|
你学会用证据而不是印象判断“改进”。这比掌握任何特定评测框架更基础。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 初学阶段刻意不做什么，以及为什么
|
|||
|
|
|
|||
|
|
一份好的入门路线不仅告诉你做什么，也要告诉你现在可以**不做什么**。这些内容并不无用，只是过早引入会掩盖核心学习。
|
|||
|
|
|
|||
|
|
| 暂时不做 | 为什么现在不做 | 什么时候再学 |
|
|||
|
|
|---|---|---|
|
|||
|
|
| 训练 / 微调模型 | 你还没有稳定的质量标准，不知道该用什么数据改进 | 能稳定设计 case、rubric 与回归集之后。 |
|
|||
|
|
| LLM-as-a-Judge | 自动评分会掩盖 rubric 是否清楚 | 手工盲评至少 20—50 条并复盘分歧之后。 |
|
|||
|
|
| CI 门禁、平台和仪表盘 | 它们放大已有流程，不会创造流程 | 手工重跑开始重复、容易漏步骤之后。 |
|
|||
|
|
| 大规模红队 | 范围广、风险分类复杂 | 有一个具体系统边界，如 RAG 注入或工具越权之后。 |
|
|||
|
|
| 1000 条数据 | 数量会掩盖设计问题 | 你能明确说出每个类别为何存在之后。 |
|
|||
|
|
| 很多框架 | 框架会让你“会点按钮”，却不一定理解判断 | 你已经被重复的手工工作真实卡住之后。 |
|
|||
|
|
|
|||
|
|
> **初学阶段最稀缺的不是模型、框架或算力，而是清楚的判断。**
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 一个更现实的首周计划：允许卡住，也允许缩范围
|
|||
|
|
|
|||
|
|
不要把“72 小时”理解为必须连续投入三整天。它表示大约 6—10 小时的最小闭环。首次执行时超时完全正常，因为你会第一次碰到“什么算对”这类真正困难的问题。
|
|||
|
|
|
|||
|
|
| 时间块 | 只做一件事 | 完成标志 | 卡住时如何缩小 |
|
|||
|
|
|---|---|---|---|
|
|||
|
|
| 第 1 次 60—90 分钟 | 写任务边界与 rubric v0.1 | 两个维度、各一个正反例 | 从 RAG 改为“回答必须引用文档句子”。 |
|
|||
|
|
| 第 2 次 90 分钟 | 写 10 个结构化 case | 至少 3 个资料不足 case | 只使用一篇公开文档。 |
|
|||
|
|
| 第 3 次 60 分钟 | 生成两组候选回答 | 每个 case 有 A/B 输出 | API 不可用时手写一好一坏两个候选。 |
|
|||
|
|
| 第 4 次 90 分钟 | 盲评并标理由 | 至少 5 条低置信度或难例 | 只评 5 个 case，并修改一条规则。 |
|
|||
|
|
| 第 5 次 60 分钟 | 写最小统计脚本 | 输出通过数和失败类型分布 | 先用 CSV / 表格，脚本只统计计数。 |
|
|||
|
|
| 第 6 次 60 分钟 | 修改一个因素并重跑 | 有一个“修改前/后”对比 | 不改模型，只改一条提示词或一个 case 分类。 |
|
|||
|
|
|
|||
|
|
**停止条件：** 如果你已经能发现并解释 3—5 类失败，就不要继续扩充 case；先修改一次 rubric 或系统，再跑一次回归。否则很容易一直造数据，却没有进入分析与迭代。
|
|||
|
|
|
|||
|
|
如果某周没完成，不要从头开始，也不要把目标改成“下周做双倍”。保留现有 case、run 和笔记，将下一步范围砍半：20 个 case 改为 10 个，双人评审改为先做自我复评，CI 改为一个本地命令。**优先保留三件事：rubric、失败理由和版本记录。** 这些才是学习的骨架。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 从 RAG 入门如何迁移到 Agent：结构没变，只是“成功”更复杂
|
|||
|
|
|
|||
|
|
当你理解文档问答后，Agent 评测并不是一套完全不同的学科。你只是在把“有据回答”扩展成“正确行动”。
|
|||
|
|
|
|||
|
|
| RAG 问答中的对象 | Agent 中的对应对象 | 共同的底层问题 |
|
|||
|
|
|---|---|---|
|
|||
|
|
| 文档上下文 | 工具描述、权限、当前状态 | 系统能否在正确约束下行动？ |
|
|||
|
|
| 回答是否有依据 | 工具是否被正确选择 | 系统是否使用了正确的可用信息？ |
|
|||
|
|
| 无法回答时说明不足 | 意图模糊时请求澄清 | 系统是否知道什么时候不应擅自行动？ |
|
|||
|
|
| 引用是否正确 | 参数、权限和状态是否正确 | 输出或动作能否被核对？ |
|
|||
|
|
| 最终回答 | 环境 outcome | 文字承诺是否与真实结果一致？ |
|
|||
|
|
|
|||
|
|
所以，等你准备做 Agent 项目时，不要先追求复杂的多工具流程。先实现三个无副作用的模拟工具，例如 `search_issue()`、`get_issue()`、`update_issue_draft()`，再构造“参数缺失、同名实体、权限不足、用户改意”这些 case。你会发现仍然是在重复同一条主线：**定义成功 → 构造边界 → 执行 → 评分 → 归因 → 回归。**
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 你什么时候算“真的入门了”
|
|||
|
|
|
|||
|
|
不是当你背会术语时，而是你能独立完成下面这段解释：
|
|||
|
|
|
|||
|
|
> “我正在评测一个有文档约束的问答系统。我的数据集刻意包含正常、资料不足和幻觉诱发 case。我的 rubric 将有据性与完成度分开。第一次盲评发现资料不足 case 的规则不够清楚，所以我更新了 rubric。系统失败的主要原因是无依据补全；我改了一条提示词后，重跑回归集，幻觉减少，但有两条正常 case 变成过度拒答，因此还不能宣布它更好。”
|
|||
|
|
|
|||
|
|
一个仍停留在旧思维的说法则是：“我跑了几个模型，整体表现不错，准确率大概 80%，所以这个系统可以用。” 它没有说明 80% 是如何定义的、漏掉的 20% 是什么、是否包含高风险失败，也无法告诉别人接下来应改哪里。
|
|||
|
|
|
|||
|
|
如果你能说清前面的合格叙述，哪怕只用了 10 个 case、没有使用任何框架，你已经在做评测工程的核心工作了。
|
|||
|
|
|
|||
|
|
## 最后：现在第一步到底做什么
|
|||
|
|
|
|||
|
|
不要再打开新的课程或框架文档。任选一个动作，十分钟内完成：
|
|||
|
|
|
|||
|
|
- [ ] 从一份公开技术文档中复制一段 200—500 字的内容，并写出一个“文档能回答的问题”和一个“文档不能回答的问题”。
|
|||
|
|
- [ ] 在空白文档写下：“我的系统什么时候应该说‘我无法确认’？”
|
|||
|
|
- [ ] 写一条 rubric：`若答案包含上下文未支持的事实，则 groundedness = fail`。
|
|||
|
|
|
|||
|
|
这个动作很小，但它会迫使你从“学习 AI 概念”切换到“定义 AI 的可验证行为”。后面的 case、盲评、脚本和回归，都是从这一步自然长出来的。
|
|||
|
|
|
|||
|
|
完成这份 Why Guide 的心智建立后，再进入配套的《LLM 评测工程实战路线图》：在那里你会把这些原则落实为项目目录、JSONL、运行记录、校准、风险门禁与 12 周节奏。
|
|||
|
|
|
|||
|
|
## 参考资料
|
|||
|
|
|
|||
|
|
[1] [OpenAI, *Working with evals*](https://developers.openai.com/api/docs/guides/evals)。
|
|||
|
|
|
|||
|
|
[2] [Anthropic, *Demystifying evals for AI agents*](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents)。
|