Evals 实操手册：从 100 条 trace 到一张失败分类表，把误差分析跑成流水线

这是「吴恩达 AI 工程技能地图深挖」系列的第 ① 篇，对应地图第 4 格「评估驱动开发」。总纲见：照着这张地图学：吴恩达「AI 工程技能地图」的 20 格自测与 12 周落地路线（含 20 格自评表与 12 周计划）。

在 20 格里，吴恩达只对一格给出了"分水岭"级别的评价。他在技能地图 Part 2 中写道：

在我经验里，区分'擅长构建 AI 系统的人'与'不擅长的'，最重要的特质就是能否驱动一个严谨的 evals / 误差分析循环。我发现这是项棘手技能，因为正确做法因项目、甚至因项目阶段而异。

"最重要"和"最棘手"同时落在同一格上，这很不寻常。它意味着：这一格不是靠学一个工具补上的，而是靠练一套流程养出来的。

这篇给的就是那套流程：从 100 条 trace 到一张失败分类表，再到一份能持续运行的评测集。

一、先纠正一个最贵的错误做法

大多数团队做 evals 的路径是这样的：先选平台 → 平台推荐一批通用指标（相关性、忠实度、有害性）→ 跑出一个 0.83 的分数 → 不知道该改什么。

Hamel Husain（AI evals 领域被引用最多的实践者之一）在其 evals FAQ 里给出了相反的起点：

误差分析是 evals 中最重要的活动。误差分析帮你决定首先该写哪些 evals。它让你识别出你的应用与数据独有的失败模式。

不要跳过误差分析。它确保你开发出的评估指标由真实的应用行为支撑，而不是那些适得其反的通用指标（大多数平台都在引导你使用它们）。

两句话的区别是方向性的：

	通用指标驱动（自上而下）	误差分析驱动（自下而上）
起点	平台给的指标清单	你自己系统的真实 trace
产出	一个总分	一张失败分类表
能回答	"系统好还是不好"	"下一步该改什么"
典型结局	分数稳定但用户仍在投诉	每一轮修复都打在占比最高的失败上

先分析数据，再写测试。 顺序反了，你就是在用别人的问题清单评估自己的系统。

二、四步流水线

下面这套流程来自 Hamel Husain 与 Shreya Shankar 的 evals 方法论（在其课程与公开 FAQ 中反复出现），我把散落的步骤整理成一条可执行的流水线。

Step 0｜建数据集：100 条，覆盖三维度

数量：先做 100 条。为什么是 100？Hamel 的说法是：没有理由，就是一个"魔法数字"，让你能启动起来，别在细节上纠结。
怎么造：先定义至少三个维度（facet），常见的选择是——用户使用的功能、用户画像（persona）、查询复杂度或场景。把三个维度做组合，生成约 50 个"不合理就删掉"的组合，再为每个组合手写或用 LLM 生成真实感的查询，凑满 100 条。
没有真实数据怎么办：用合成数据跨过冷启动。有人问过"如果流程里本来就有人工介入怎么办"，两个可行做法是——造一个合成 persona 扮演那个人的角色，或者直接找 5 个真人，每人跑十几遍，先拿到足够数据走出冷启动。

关键不是"完美覆盖"，而是让样本跨越足够宽的使用维度。维度定义得太窄，是这个流程最常见的死因（见第五节坑 1）。

Step 1｜Open coding（开放式编码）：逐条写笔记

把你的 100 条输入灌进系统，拿到完整 trace——不只是最终回答，还包括中间的工具调用、检索结果、元数据。然后逐条读、逐条写笔记。

这是整个流程里最耗时的环节：约占 80% 的时间；熟练后 100 条 trace 大约 1 小时左右。
只记观察，不追根因。这一点常被搞错：Hamel 明确说这一步"不关心为什么会发生"，只关心观察到的行为与模式。根因分析是后面的事。
长 trace 记"第一个失败"。多轮对话或带复杂中间步骤的 trace，上游错误会污染下游，所以优先记录你看到的第一个上游失败，实在可以的话再标记独立的失败。
让类别从数据里浮现，不要带着预设的分类清单进来。
谁来做：应当由领域专家来做。如果要用 Agent 帮忙，先自己标注至少 30 条，再看它的建议。

Step 2｜Axial coding（关联式编码）：聚成失败分类表

把第一步的散装笔记聚成类，得到一张涌现出来的失败分类表（failure taxonomy），并统计每一类出现了多少次。

Hamel 对这一步的评价是："axial coding 是最重要的一步。"

三条实操要点：

LLM 可以帮你聚类，但不能替你拍板。 原话是："永远要自己人工复核、修正并定义这些失败模式。" 最终判断依赖你对应用上下文的理解。
失败模式尽量做成二元判定（可观察的"是/否"），而不是 1–5 分的打分。理由很实际：二元定义更容易写清楚"什么算、什么不算"，分数制太容易含糊。
先数数，再动手。每类的出现次数，就是你接下来修复与写评测的优先级排序。

Step 3｜迭代到"理论饱和"

这一步不是"做完收工"，而是循环：让 Agent 帮你在剩余 trace 里找符合你已描述失败模式的样本，你接受/拒绝它的建议，持续迭代，直到理论饱和——即新的复核不再发现新的失败模式、也不再改变已有定义。

一个实用的护栏：维护一个约 100 条多样化 trace 的工作池，不必顺序读完 100 条，让 Agent 把注意力引到信息量最大的那条上。
定义会漂移，这是好事。标注过程中失败模式的定义与命名会演化，这反映你对数据的理解在加深，应该欢迎它，而不是为了"一致性"把它冻住。

三、三个现实难题与对应打法

3.1 系统太复杂，trace 读不动怎么办

Hamel 给的两个答案，核心都是简化：

自建一个数据查看器 / 标注界面。现成工具再强，也不可能对所有人都是最优解；自己搭一个能把"你在意的那些部分"前置展示的界面，往往效率更高。
只看最终输出，不要陷进中间细节。因为这是个迭代过程，"在输出里观察到错误"就已经足够作为编码和聚类的依据，你不需要在这一步做根因分析。
一句很实用的原则："找到那个淹没了其他错误的错误"——先修最刺眼的那个。

3.2 心态：像侦探一样工作

Hamel 给的类比是："我要去把失败节点找出来。" 这个过程本身相当开放，Hamel 和 Shreya 都承认它有点"信念之跃"的味道——像夜里开雾中行车，只能看清前方十米，但车依然在向前走。

3.3 什么时候用大模型辅助

可以用 LLM 来压缩那些机械但耗时的环节：帮你聚类、帮你在剩余数据里检索候选样本。但有两件事不能外包：定义失败模式、以及最终接受/拒绝。

四、从失败分类表到真正的评测集

失败分类表是原料，评测集是成品。转换时你需要选评测手段——三种，按确定性从高到低：

手段	适用	代价与注意
确定性代码评测	能用规则判定的（格式、字段、是否包含引用、工具是否被调用）	最便宜、最稳定，应优先榨干
LLM-as-a-judge	定性/主观输出（语气、是否有帮助、是否答非所问）	必须校准；judge 的 prompt 本身要有评测
人在环	高风险、低置信、需要专业判断的样本	最贵，用在刀刃上

两个容易被忽略的动作：

校准你的评测本身。定期"故意让评测集红一次"——确认它真的能抓到问题，而不是稳定地给高分。吴恩达在 Part 2 也把这条写进了要求："评估你的评测，以持续迭代它。"
让评测集持续生长。吴恩达提到，设计评测要"查看系统的 trace 与输出，做探索性数据分析，并结合产品与商业洞察来决定测什么"——这意味着评测集不是一次性产物，而应随生产流量更新。

五、五个坑（每一个都能让整件事白做）

来自实操者的复盘清单：

维度定义太窄：一开始的 facet 组合不够宽，导致数据集压根没覆盖真实的使用模式。
偷工：只标注了几条，或者标注时没有认真想"这条 trace 到底代表了什么"。
过早自动化：把专家判断交给了机器——尤其在早期，模型无法代表你的利益。
跳过迭代：做完 axial coding 就停手，不回灌到 open coding 继续细化定义。
缺领域专家：复杂领域里，标注环节没有真正懂业务的人参与。

吴恩达把第 4 格的难点归结为"方法因项目与阶段而异"。这五个坑某种意义上都是同一件事：想跳过"人读数据"这个不可省略的核心步骤。

六、可直接抄的工作表

一张能立刻用起来的失败分类表，建议包含这些列：

字段	示例
失败模式 ID	F-03
失败模式名称	检索到了过期版本的政策文档
定义（二元判定）	回答引用的条款版本早于当前生效版本 → 是/否
出现次数	17 / 100
典型 trace 链接	（填你的追踪系统链接）
首次观察到的轮次	Step1 / Step2
优先级	P0（占比最高）
建议评测手段	代码判定（比对引用版本号）
状态	待修 / 已修 / 已加评测

跑完一轮，你会得到两个直接可用的产物：一张按占比排序的修复清单，以及一组有真实来源的评测项。这正是吴恩达所说的"让进展系统化而不是随机"。

七、小结

起点不是平台，是你的 trace。 先误差分析，再写评测；跳过这一步，你会得到一套"适得其反的通用指标"。
四步：建数据集 → open coding → axial coding → 迭代到饱和。 其中 axial coding 是关键、open coding 最耗时（80%）。
两条铁律：只观察不追根因；定义必须由人拍板，LLM 只能辅助。
二元优于打分，计数优于感觉。
最后一步永远留给校准：一个从不失败的评测集，等于没有评测集。

把这一格练到位，你就拿到了地图里最难也最值钱的那张门票。下一篇我们会走到它的上游：当 Agent 替你写代码时，规划、执行、监控这三段流程具体该怎么组织。

参考来源

Andrew Ng, The AI Engineering Skills Map Part 2 — AI Applications，2026-08-21（第 4 格定义与"分水岭"论断）
Hamel Husain, AI Evals FAQ — Why is "error analysis" so important in AI evals, and how is it performed?（四步流程、100 条池、理论饱和、二元失败模式）
Alex Strick van Linschoten, Error analysis to find failure modes（五步 analyse loop、80% 时间口径、pitfalls 清单、数据查看器与"只看最终输出"）
Hamel Husain & Shreya Shankar, AI Evals 课程公开材料（求值手段选择与迭代循环）
「吴恩达 AI 工程技能地图深挖」总纲：20 格自测与 12 周落地路线

说明：本文的"四步流水线"是对 Hamel Husain 公开方法的整理与再组织；工作表模板与优先级建议为本站整合补充，非原作者原文。