AI 评测体系建设(七):错误归因——我们到底在＂测＂什么

一、开篇：一个模型失败了，到底是谁的错？

在前一期，我们建立了实验系统——用数据告诉你「这个版本比上一个版本好多少」。

但这里浮出了一个更尖锐的问题：当版本对比发现新模型的表现下降了，或者某些场景表现不稳定，我们怎么知道责任在哪里？

是数据不够代表性？是模型架构的问题？是提示词设计缺陷？还是评测方法本身有偏差？

大多数团队的回答是：「我们也不知道，就是不好用。」

这一期，我们要解决的是错误归因——当评测发现了一个失败案例，我们如何系统地拆解这个失败背后的真实原因，从而做出精准的优化决策。

这是从「发现问题」升级到「理解问题」的转折点。也是决定你的评测系统能否真正驱动模型进化的关键。

二、问题定义：为什么我们总是在猜测

2.1 行业现状：三种"失败案例的迷思"

我们分析了 30+ 个 AI 团队的评测复盘记录，发现错误归因失效的常见情况：

❌ 现象1：只知道「错了」，不知道「怎么错的」   评测报告：   - 问题识别：模型在"财务报表分析"上成功率只有 62%   - 行动：「这个场景太难了，我们先放弃」   缺失的信息：   - 62% 的失败中，有多少是理解问题失败？   - 有多少是计算逻辑错误？   - 有多少是格式输出错误？   真相：每种错误的修复方案完全不同         不分类就瞎优化，最后还是不行❌ 现象2：混淆了模型问题和评测问题   场景：医学知识问答   评测发现：模型回答准确率 55%   团队反应：「模型不行，需要换基座」   三个月后才发现：   - 问题不在模型，而在评测标准   - 医学问答的正确答案不唯一   - 用 BLEU 这种字面匹配度量是错的   - 应该用医学专家打分，或者语义相似度   代价：浪费人力、丧失信心❌ 现象3：有了失败案例，但无法推广到其他模型   案例1："Claude 在这道题失败了，是因为 XYZ 原因"   案例2："GPT-4 在同样的题也失败了，原因完全不同"   结果：每个模型都要单独分析，无法形成系统性认知   问题：没有建立「错误分类体系」         同一种错误在不同模型上的表现和成因并不相同

2.2 根本原因：缺少错误分类的设计思维

大多数团队做错误分析的过程是这样的：

跑评测，发现失败案例
打开案例，读一遍内容
凭直觉说「可能是因为 XXX」
写个备忘录
下次遇到类似的，还是重复 1-4

为什么？因为没有一个清晰的错误分类框架。

在软件工程中，我们早已知道：

不同类型的 bug 需要不同的修复方式
没有分类的问题库最后一定变成"垃圾堆"
能否快速定位问题，取决于分类体系的粒度

而在 AI 评测中，这个原理被完全忽视了。

2.3 Zenit 的核心观点

错误归因 = 多维度的分类体系 + 精准的根因定位方法。

它要回答四个问题：

问题维度	具体问题	责任方
理解维度	模型是否正确理解了输入意图？	模型 / 提示词设计
推理维度	模型的中间推理过程是否逻辑清晰？	模型能力 / 上下文长度
执行维度	模型是否按预期的方式组织了输出？	模型 / 输出约束
评测维度	评测标准是否能公正地衡量这个答案？	评测指标 / 标注规则

三、方案拆解：构建错误分类体系

3.1 第一层：错误类型的标准分类

我们基于 1000+ 个实际失败案例，总结出了一套可复用的错误分类框架：

L1 - 错误大类（4类）  ├── 理解类（Understanding Failure）  │   └─ 模型未能正确提取题目意图或关键信息  │  ├── 推理类（Reasoning Failure）    │   └─ 中间推理步骤有逻辑漏洞或违反约束  │  ├── 执行类（Execution Failure）  │   └─ 最终输出不符合预期格式或约定  │  └── 评测类（Evaluation Failure）      └─ 答案本身可能是对的，但评测标准错了

为什么这样分？

理解类失败需要改进：更好的提示词、更清晰的输入结构化、或更强的基座模型
推理类失败需要改进：长链路稳定性、思维链（CoT）设计、或外部知识库
执行类失败需要改进：输出约束（如正则表达式）、结构化输出（JSON Schema）
评测类失败需要改进：重新审视评测指标本身

这四类的优化路径完全不同。

3.2 第二层：失败的严重程度划分

不是所有失败都一样重要。我们需要区分：

严重程度	定义	优化优先级
Critical	答案完全错误，不只是部分不完美；例如：要求 True/False，却输出「可能是」	🔴 最高
Major	答案主要思路正确，但关键细节缺失或错误；例如：选择题选对了选项，但原因分析错了	🟠 高
Minor	答案内容对，但表述、格式或风格不符合预期；例如：要求一句话总结，却写了三段	🟡 中
False Positive	这不是真的失败，是评测标准过于严格；例如：医学问答的合理答案被标注为「错」	🔵 需要重新评估

为什么需要这个划分？

假如你的评测有 10000 个失败案例，不区分严重程度，你无法定位优化重点。但如果你知道其中 800 个是 Critical、2000 个是 Major，你就能聚焦于最有价值的 2800 个。

3.3 第三层：归因的决策树

当你发现一个失败案例时，这个决策树可以帮你快速定位根因：

发现失败案例    │    ├─ Q1: 模型输出内容是否为空？    │   ├─ YES → 【执行类】模型拒绝或崩溃，检查异常处理    │   └─ NO  → 继续    │    ├─ Q2: 输出是否符合指定的格式（JSON/Markdown/等）？    │   ├─ NO  → 【执行类】格式错误，需要约束输出    │   └─ YES → 继续    │    ├─ Q3: 如果我给 GPT-4 加上详细的背景和思考步骤，    │       GPT-4 能否给出正确答案？    │   ├─ NO  → 【理解类】模型根本理解错了，需要改进提示词    │   └─ YES → 继续    │    ├─ Q4: 答案的中间推理步骤是否逻辑自洽？    │   ├─ NO  → 【推理类】推理链条有漏洞，需要 CoT 或知识补充    │   └─ YES → 继续    │    └─ Q5: 专家审核认为这个答案可接受吗？        ├─ YES → 【评测类】评测标准过于严格，需要调整        └─ NO  → 【综合】需要多维度改进

这个决策树的妙处在于：它是从最容易修的问题开始（执行类），到最难改的问题（理解类）。

3.4 第四层：标注规范与工具化

为了让这个分类框架能够一致性地应用，我们需要标注规范：

标注模板（每个失败案例都需要填写）：【案例 ID】test_case_20260511_0042【失败类型】理解类 + 推理类【严重程度】Major（因为核心答案对，但推理过程缺失关键步骤）【错误描述】  - 一句话原因：模型未能从长文本中提取关键数字，导致计算错误【改进方向】  - 短期：改进提示词，显式要求"先提取所有数字，然后计算"  - 中期：评估长上下文的稳定性（见第9期）【是否已分配修复任务】是 / 否【关联的前置技术债】实验系统(6) / 数据引擎(2)

这样，每个失败案例就不再是孤立的"吐槽"，而是可追踪、可复用的数据资产。

四、实践要点：从分类到行动

4.1 关键决策1：分类的粒度

问题：是用 4 个大类够了，还是要分到 20 个小类？

建议：从 4 个大类开始，逐步根据你的数据分布细化。

在我们的实验中：

前 100 个案例：用 4 大类，分类准确率 89%
到 500 个案例：加了 3-4 个子类，准确率升到 93%
到 1000 个案例：稳定在 8-10 个细分类，准确率 94%

过度分类（超过 15 个小类）的风险是：标注成本飙升，而边际收益递减。

我们的建议：

小团队（少于 50 人）：坚持 4 大类 + 3-5 个常见子类
中等团队（50–200 人）：8-10 个细分类
大团队（多于 200 人）：可以根据业务特点定制 15-20 个类别

4.2 关键决策2：谁来做标注

选项1：算法工程师标注

优点：理解模型逻辑，标注准确
缺点：工时太贵，影响迭代速度

选项2：产品或测试团队标注

优点：跟业务场景近，能识别评测类失败
缺点：对模型细节理解不足

选项3：三步标注法（最实用）

第一步：自动分类（用 LLM 初步分类）  └─ 用 Prompt："这个失败案例属于 [理解/推理/执行/评测] 类，理由是？"  └─ 准确率通常 80-85%第二步：人工抽检（标注员抽检 10-20% 的案例）  └─ 重点抽查评测类和边界案例第三步：算法工程师快速审核（只审关键案例的分类）  └─ 这一步只需要 20% 的工时

这样既能保证准确率，又能控制成本。

4.3 关键决策3：分类后的流转

分类完成后，不同类型的错误应该流向不同的团队处理：

错误类型	处理方式	负责团队	回环反馈
理解类	改进提示词设计	产品/测试 + 算法	下一轮迭代测试
推理类	外接知识库或长文本优化	算法 + 架构	发布新版本再测
执行类	加入输出约束和后处理	工程	立即生效
评测类	重新审视评测指标	测试/产品	重新标注相关案例

这个流转表的意义在于：确保每个失败案例都有明确的处理方向，而不是沉入数据库无人问津。

4.4 关键决策4：如何度量改进

做了这么多分类和分析，改进有没有效果？怎么衡量？

建议用这个指标：

改进有效性 = (修复前失败数 - 修复后失败数) / 修复前失败数以理解类失败为例：- 修改提示词前：理解类失败 320 个- 修改后：理解类失败 210 个- 改进有效性 = (320 - 210) / 320 = 34%

但更重要的是分层追踪：

改进后，这 110 个被修复的案例中：- 有 70% 永久解决了- 有 20% 在新数据上又出现了（数据覆盖问题）- 有 10% 只是被推迟了（真正的深层问题）这说明：✅ 短期改进有效⚠️ 需要扩大评测数据集🔧 需要更深层的架构改进

五、收尾：从「测什么」到「改什么」

这一期我们明确了一个关键转变：

从「用评测发现问题」升级到「用分类理解问题」。

当你建立了错误分类体系，每一个失败案例就不再是压力，而是改进的地图。你知道从哪开始改，改的顺序是什么，改了有没有效果。

但这只是故事的上半部分。

下一期（第八期），我们要讨论的是：当你有了成百上千个失败案例和它们的分类后，怎样把这些「坏数据」变成「进化的数据」？

这就是著名的 Badcase 闭环 —— 也许是决定你的评测系统能否自我进化的最后一道坎。

敬请期待。