本文作者：meng shao（@shao__meng）。版权归作者所有，未经授权禁止转载。

AI Evals: Everything You Need to Know

作者：Hamel Husain @HamelHusain & Shreya Shankar @sh_reya

本文是基于两位作者开设的 AI Evals 课程，面向 700+ 工程师与产品经理的实战经验沉淀。表面是 FAQ，实际在论证一个反直觉的观点：AI 评估的最大瓶颈不是技术，是“人是否真的在看数据”。

当前行业的主流叙事是：搭评估基础设施、接 LLM-as-a-Judge、看仪表盘分数。两位作者基于大量一线教学与实践，认为这条路径恰恰是错的，或者说是本末倒置的。他们的核心方法论可以压缩成一句话：

先做错误分析，再谈评估体系。 评估指标是从真实失败案例中“生长”出来的，不应该是预先设计出来的。

支撑这个命题的关键论据有三：

  1. LLM 的失败面是无穷的，无法穷举预判。 传统软件的测试驱动开发（TDD）之所以可行，是因为行为规约可以事先写定；而 LLM 应用中你无法想象“会出什么错”。因此“eval-driven development”在多数场景下不成立，评估器应该为已发现的错误而建，而非为想象中的错误而建。
  2. 通用指标制造虚假信心。 helpfulness、coherence 这类现成指标，以及 BERTScore/ROUGE 等相似度度量，测不出“向用户推荐了不存在的场次”或“在多客户间混淆了人设”这类真实业务失败。它们最多可作为探索信号，帮助定位值得人看的 trace。
  3. 研究表明需求必须通过观察行为来外化（引用 arXiv 2404.12272），用户和开发者往往说不清自己要什么，直到亲眼看到模型做错了什么。这正是错误分析的认识论基础。

方法论骨架：错误分析怎么做

FAQ 给出了一个可操作的四步流程，明显借鉴了社会科学的质性研究方法：

  1. 建数据集：收集 ~100 条多样化的 trace（trace = 从单次用户请求到最终响应的完整记录：消息、工具调用、检索过程）。
  2. 开放式编码（Open Coding）：领域专家逐条阅读 trace，针对每条 trace 的第一个上游失败写开放式笔记。关键纪律：前 30 条必须亲自标注，不许外包给 LLM 或 Agent，因为初始编码承载的是无法言传的隐性知识。
  3. 轴心编码（Axial Coding）：把笔记归类为失败模式分类体系（taxonomy）。作者称这是全流程最重要的一步。
  4. 迭代到理论饱和：此后可让 agent 按已识别的模式检索剩余 trace、提议新失败，但人始终保留裁决权。

几个配套的纪律性观点值得注意：

  • 不要提前写评分标准（rubric）。过早成文的 rubric 会蒙蔽审阅者，使其对预料之外的问题视而不见。Rubric 应在错误分析之后写，并随“标准漂移”（criteria drift）定期修订。这一条直接否定了“先定义质量标准再评估”的传统 QA 直觉。
  • 失败标准用二元判断，不用 Likert 量表。1–5 分存在相邻等级主观差异、样本量需求更大、标注者倾向选中间值等缺陷。渐进质量应拆成多个二元子检查（如“5 个要点命中 4 个”），而非单一打分。
  • 100% 通过率是警报而非喜讯。一个总是通过的评估没有信息量；70% 的通过率反而说明评估真正击中了系统的软肋。

样本量与数据策略：分阶段给数

这是全文最“工程实用”的部分，作者按三个目的分别给出量化标准：

| 目的 | 建议规模 |
| --- | --- |
| 发现失败模式 | 起步 ~100 条多样 trace；前 30 条亲标；持续到理论饱和 |
| 验证评估器 | 代码断言：每个条件各需 Pass/Fail 正反例；LLM judge：每个失败模式 100–200 条人工标注，按 10–20% train / 40–45% dev / 40–45% test 切分 |
| 可回归的评估集 | 常增长至 100+ 条，覆盖核心工作流与已确认的失败 |

关于合成数据，作者的立场是方法对了才可用：先手工定义变异维度（如 饮食限制 × 菜系 × 复杂度），手写 ~20 个元组，再用“两步生成”（先让 LLM 生成结构化元组，再用另一个 prompt 把元组转写成自然语言）扩展。直接一句“给我生成一批测试问题”是最差做法。高风险领域、低资源语言、无法验证的场景，合成数据不可靠。敏感数据则按优先级递降：真实可查数据 → 领域专家在正常工作流内代查 → 脱敏（并验证脱敏效果）→ 合成数据兜底。

人的组织：由一位领域专家做最终裁决

文章在标注团队组织上观点极其鲜明：一位领域专家担任质量的最终裁决者，好过委员会。 心理健康聊天机器人就该由心理学家定标准，法律文档就该由律师定标准。如果每个交互都需要五位 SME 参与，更可能说明产品范围定义过宽而非标注资源不足。

同理，外包标注在多数情况下是重大错误；外包方只能做表层标注，丢失产品上下文与隐性知识。例外仅限纯机械任务（如无产品上下文的翻译）或直接雇佣外部专家本人（如 AnkiHub 雇医学生评估医学 RAG）。

一个容易被忽略的深刻观点：“难以评估”往往是产品设计问题，不是评估问题（It's Hard to Eval Is a Product Smell）。如果输出难以审阅，应该重构产品让验证变容易；例如让医生先看到带原文链接的抽取事实，再生成报告。这是把评估压力反向传导到产品设计。

LLM-as-a-Judge：可用，但必须校准

作者不反对用 judge，反对的是未经验证地用。标准流程：错误分析 → 迭代 prompt → 建标注集 → 对照人工标签测 judge 的 True Positive / True Negative Rate。知道 TPR/TNR 后，还能据此反推系统真实失败率（对 judge 的估计做校正）。跳过校准，judge 的分数可能与你的质量标准毫无关系。

其余要点：任务模型和 judge 模型可以相同（judge 做的是另一个范围收窄的二元任务，对齐度才是唯一标准）；给 judge 的上下文越少越好（只给所需片段，多余上下文导致 "context rot"，需做消融验证）；trace 过大时可给 judge 搜索工具，但仅在必要时引入这份复杂度。

基础设施：自建标注工具是“回报最高的单项投资”

这是全文最出人意料的结论之一：在 AI Coding Agent 加持下，自建标注界面几小时即可完成，而拥有定制工具的团队迭代速度约 10 倍于用通用工具的团队。好界面的标准：按领域原生形态渲染 trace（邮件像邮件、代码有高亮、长输出可折叠）、键盘导航与进度指示、聚类/过滤/语义搜索、优先展示疑似问题 trace 并支持一键“加入数据集 / 提 bug”。原则是保持极简，功能收益须高于维护成本。

其他基建结论：prompt 用 Git 管理（prompt 是软件工件，应与代码一起原子化部署；供应商的 prompt 管理工具难以执行你应用里的工具/RAG/agent 代码，引入不必要的间接层）；选评估平台（LangSmith、Arize、Braintrust 等）功能差异不大且每周都在变，支持质量（人的因素）权重最大，作者通常在其之上再自建工具。

生产与部署：三条边界线

  • CI vs 线上监控：CI 数据集小而精（100+ 条），覆盖核心功能与历史回归，优先用廉价的确定性断言（因为高频运行）；线上监控对采样 trace 异步跑更贵的无参考评估器（LLM judge），追踪置信区间，下界越过阈值才调查。两者闭环：线上发现的新失败回灌进 CI 数据集。
  • Guardrail vs Evaluator：Guardrail 在请求关键路径上同步执行，快、确定性、可解释（正则、黑名单、schema 校验），针对客观高危失败（PII 泄漏、SQL 注入、畸形 JSON），误报即生产 bug；Evaluator 在响应产生后异步运行，度量规则测不出的主观质量（正确性、完整性），喂给仪表盘和改进循环，不阻断输出。几乎不应把慢且非确定性的 LLM judge 用作同步 guardrail；若确需，只在级联中对少数边界案例启用，并权衡误报/漏报的业务代价（医疗场景漏报更贵，创意场景误报更伤）。
  • 模型选择：不要把换模型当作默认改进手段。“在没有证据表明模型是瓶颈之前，不要把它当作改进系统的主轴。”先做错误分析。

RAG 与 Agent：具体领域的落地

RAG 未死：“RAG is dead”那篇热文反对的是给自主编码 agent 用朴素向量库检索，而非检索增强本身。Claude Code 等工具仍在用检索，只是换成了 agentic search。正确的问题是“如何有效检索”，而非“要不要检索”。

RAG 评估分两层：检索层用经典 IR 指标（Recall@k、Precision@k、MRR），可通过“从文档抽事实→反推问题”合成 query-doc 对；生成层用 Jason Liu 的框架（上下文相关性（C|Q）、答案忠实性（A|C）、答案切题性（A|Q））但 judge 同样必须走完整校准流程。领域特有失败（如医疗 RAG 混淆成人/儿童剂量）只能从错误分析中发现。

Chunk 大小按输出类型分治：固定输出型任务（提取一个数字、回答一个具体问题）用大块；减少查询次数、避免上下文碎片化，但警惕长输入中部注意力衰减与无关信息干扰；扩展输出型任务（摘要、穷举提取）用小块 + map-reduce 聚合，尊重段落/章节边界。核心是把 chunk size 当超参数实验调优，无万能经验值。

Agent 评估两阶段：先端到端（黑盒判定任务是否达成，记录首个上游失败），再步级诊断（工具选择、参数提取、错误处理、上下文保持、效率、里程碑检查点）。工具调用测试拆为名称、参数、结果、状态变更四个独立断言；合法的调用仍可能是错的，若用户未授权或系统跳过了前置检查。测试用例遵循“最简复现”原则：四轮对话里报错，先简化成单轮问句验证是否与对话上下文有关。

转移失败矩阵（Transition Failure Matrix）是全文给出的一个高价值分析工具：行记“最后一个成功状态”，列记“第一个失败位置”，矩阵单元的计数直接暴露失败热点（文中的 text-to-SQL 例子：GenSQL→ExecSQL 转移贡献 12 次失败，而另一路径仅 2 次），指导调试投入的优先级。多步工作流中早期失败的修复价值最高，因为 LLM 链上错误会级联放大；流程性失败（步数、耗时）比结果性失败更确定性、更易调试，应先攻。

人工接管（handoff）本身即失败模式：trace 必须延续到用户需求真正解决为止，而非 AI 交给人就算结束。要记录交接时机、传递的上下文、人工动作与最终结果；很多失败恰恰发生在交接边界（太早、太晚、上下文不足）。有时最优改进不是优化交接质量，是减少交接本身。

贯穿全文的立场与评注

把所有 FAQ 抽象之后，作者的世界观可以归纳为几组一致的取舍：

  • 观察先于设计：失败模式从数据中来，不从预设分类体系中来；
  • 具体先于通用：自建的、应用相关的评估器优于现成指标；Git 优于 prompt 管理平台；
  • 独裁先于民主：一位被授权的领域专家优于标注委员会与外包；
  • 人力守住的环节不可外包：初始开放式编码、taxonomy 验证、judge 的金标准标注、根因分析；这些是认知发生的地方；LLM 可以加速其余一切（轴心编码初稿、按模式检索、prompt 改进建议）；
  • 手写 prompt 优于自动优化：“好的写作就是好的思考”；写 prompt 的过程逼你澄清假设；自动优化器只能爬山一个预定义的指标，发现不了新失败。优化只适合评估体系成熟后的“最后一公里”。

在评估工具营销话语泛滥的当下，这篇文章最有价值的贡献是把讨论拉回到一个朴素的事实：评估的本质是理解你的系统在哪里影响了用户，而这件事没有自动化捷径；工具与 LLM 能让这个循环转得更快，但“看数据、形成判断”这一步，始终属于人。