AI DAILY / 2026-09-22
AI评估完全FAQ：常见问题与实操建议
AI Evals: Everything You Need to Know
全文中文翻译 · AI 生成，仅供学习交流
这篇文章汇集了 Shreya 和我在为 700 多位工程师与 PM 讲授 AI Evals 时最常被问到的问题。
警告：以下是关于多数情况下有效做法的犀利观点，并非放之四海皆准的真理，请结合实际情况自行判断。
如何使用本 FAQ
浏览你感兴趣的问题，或从下方指南中选择一条精心编排的阅读路径，串联起这些 FAQ 和相关文章。
你处在哪个阶段？
这听起来像我
- 我是评估的新手
我听过这个术语，但不太确定评估具体涉及什么，也不确定自己是否需要它。
- 我不知道该测什么
我正在做一款 AI 产品，但还没想清楚要衡量哪些失败，也不清楚什么才算好的表现。
- 我不信任我的评估分数
我们有评估，但分数与我对输出的判断对不上；测试都通过了，用户却仍然碰到问题。
- 我的产品太难评估
我们的输出主观、冗长，或者涉及很多步骤；即便是懂行的人，也很难判定它们是否正确。
- 评估耗时或成本太高
我们在审阅输出、维护测试或运行评估器上投入了过多精力。
所有问题按章节浏览所有问题。
入门与基础
Q: 什么是 AI 评估（AI Evals）？
Q: 什么是 trace（追踪记录）？
Q: 最小可行的评估（minimum viable evaluation）配置是什么样的？
Q: 我应该把多少开发预算分配给评估？
Q: 考虑到 AI 发展如此之快，当今的评估方法在 5-10 年后还管用吗？
Q: 如何向团队争取对评估的投入？
错误分析与数据收集
Q: 为什么 "错误分析"（error analysis）在 AI 评估中如此重要？具体该怎么做？
Q: 在标注数据之前，我是否需要一份参考答案或评分标准？
Q: 我是否应该记录那些并非模型原因导致的问题？
Q: 一个评估需要多少条样例？
Q: 除了用户反馈之外，如何发现需要审阅的有问题的 trace？
Q: 多久应该对生产系统重做一次错误分析？
Q: 当我的 "金标准" 评估数据集变得陈旧时该怎么办？
Q: 生成合成数据（synthetic data）的最佳方法是什么？
Q: 合成数据在哪些场景下可能不可靠？
Q: 当 trace 包含敏感数据时，如何进行评估？
Q: 当我的系统要处理多样化的用户查询时，该如何做评估？
Q: 如何高效地对生产 trace 进行抽样审阅？
评估设计与方法
Q: 为什么你推荐用二元（pass/fail，通过/不通过）评估，而不是 1-5 分的 Likert 量表？
Q: 如何把多个评估合并成单一指标？
Q: 我应该践行评估驱动开发（eval-driven development）吗？
Q: 是否应该为每一个发现的失败模式都构建自动评估器？
Q: 构建自动评估应该用什么模型或大语言模型？
Q: 我能用 Jev 做评估吗？
Q: 如何判断我能否信任我的自动评估？
Q: 当我的 LLM judge（LLM 评审器）与人工评审无法达成一致时该怎么办？
Q: 我应该使用 "即用型" 的评估指标吗？
Q: 相似度指标（BERTScore、ROUGE 等）对评估 LLM 输出有用吗？
Q: 主任务和评估可以用同一个模型吗？
Q: 应该给 LLM judge 多少上下文？
Q: 我们如何评估模型表达 "不确定性" 或 "自知其不知" 的能力？
人工标注与流程
Q: 标注 LLM 输出需要多少人？
Q: 如何让人类评审者更容易评估 AI 的输出？
Q: 产品经理和工程师是否应该协作做错误分析？怎么做？
Q: 如果我不是领域专家，能参与评估吗？
Q: 我是否应该把标注工作外包给第三方？
Q: 我该如何审阅一条特别长的 trace？
Q: 评估中有哪些部分可以用 LLM 自动化？
Q: 我是否应该停止手写 prompt，转而使用自动化工具？
工具与基础设施
Q: 我应该自建标注工具，还是用现成的？
Q: 一个好的 LLM 输出审阅自定义界面应该具备什么？
Q: 评估工具中的哪些空白需要我自己来填补？
Q: 内部评估平台应该为各团队统一哪些东西？
Q: 你最喜欢的评估厂商是哪家？
Q: 我应该如何对 prompt 做版本管理？
Q: system prompt（系统提示）和 user prompt（用户提示）应该分别放什么？
生产与部署
Q: 评估在 CI/CD（持续集成/持续交付）和生产监控中的用法有什么不同？
Q: guardrails（护栏）和 evaluators（评估器）有何区别？
Q: 我的评估器能否也用来在生产中自动修复或纠正输出？
Q: 我应该在模型选择上花多少时间？
领域特定应用
Q: RAG（检索增强生成）是不是过时了？
Q: 我该如何评估一个编程 agent？
Q: 我该如何评估自己的 RAG 系统？
Q: 在文档处理任务中，如何选择合适的 chunk size（分块大小）？
Q: 如何调试多轮对话的 trace？
Q: 涉及人工交接的会话该如何评估？
Q: 复杂的多步骤工作流该如何评估？
Q: 如何评估 agentic workflow（智能体工作流）？
---
入门与基础
Q: 什么是 AI 评估（AI Evals）？
AI 评估是告诉你一个 AI 系统是否在按你的期望行事的测试。当产品偏离用户需求或业务目标时，它能给你的团队反馈。它捕获的失败，也是你用来改进系统的数据。
更正式地说，评估（evaluation）是对质量的系统性度量。每一条评估在相关样例上检查一种行为，并返回一个分数或结构化的评审结果。大多数 AI 产品需要多条评估，因为它们的失败方式多种多样。
当你说起 "evals" 这个词时，它通常指两件事之一：模型基准（model benchmarks）或产品评估（product evals）。
模型基准
模型基准在共享任务上比较通用模型。模型厂商发布新模型时会公布这些基准结果。常见例子包括：面向研究生级科学推理的 GPQA Diamond，面向在命令行环境中执行复杂任务的 agent 的 Terminal-Bench，以及覆盖广泛主题知识与推理的 MMLU。这些分数可以帮你挑出一个有潜力的模型作为起点。要评估你自己的任务质量，你需要的是产品评估，我们下一节讨论。
产品评估
产品评估衡量的是你这款具体的 AI 产品是否做到了你想让它做的事。它把 "好的产品体验长什么样" 的判断，转化为可以追踪的指标。产品评估涵盖产品的所有组件，包括模型、prompt、检索（retrieval）、工具以及应用代码。这类评估聚焦于捕捉对用户和业务真正重要的失败。
举例来说，考虑一个订单取消 agent。它的产品评估可能会检查：它是否选中了正确的订单，以及在告诉用户订单已取消之前，是否真的等到了取消工具调用成功。即便在 GPQA Diamond 或 Terminal-Bench 上拿了高分，对这条评估也没用，因为那些基准根本无法触达你的系统。
你可以使用多种机制来实现产品评估，包括代码断言（code assertions）、人工评审（human review）、LLM judges（LLM 评审器），以及在线实验（online experiments）。具体用哪种，取决于你要衡量的失败类型，本系列文章会详细讨论。
在 AI Evals FAQ 的剩余部分，我们聚焦于产品评估。它从分析 trace、发现真实的失败模式开始；随后把重要的失败转化为有针对性的评估，再用结果来指导改进；最后，重跑评估就能告诉我们系统是否得到了改善。
从哪里开始评估
如果你对产品级评估完全是新手，可以看下面这几篇：
| 指南 | 涵盖内容 |
|---|---|
| 第一部分：你的 AI 产品需要评估（Your AI Product Needs Evals） | 用限定范围的测试、trace 审阅、人工评估和实验，构建一套领域特定的评估体系。 |
| 第二部分：使用 LLM-as-a-Judge 做评估：完整指南（Using LLM-as-a-Judge For Evaluation: A Complete Guide） | 捕获领域专家的判断，用 LLM judge 将其自动化，并对照人工标注验证 judge。 |
| 第三部分：快速改进 AI 产品的实战手册（A Field Guide to Rapidly Improving AI Products） | 通过错误分析、真实数据和值得信赖的评估，运行可持续的产品改进闭环。 |
Q: 什么是 trace（追踪记录）？
trace 是从一次初始用户查询开始、到最终响应为止，对所有动作、消息、工具调用和数据检索的完整记录。它涵盖了一次会话中跨所有 agent、工具和系统组件的每一步：包括多条用户消息、助手回复、检索到的文档，以及中间的工具交互。
术语备注：不同的可观测性厂商对 trace 和 span 的定义各不相同。
Alex Strick van Linschoten 的分析指出了这些差异（截图如下）：截至 2025-07-02 的各厂商 trace 定义差异。
Q: 最小可行的评估配置是什么样的？
从错误分析开始，而不是基础设施。每次做出重大改动时，花 30 分钟人工审阅 20-50 条 LLM 输出。挑一位了解你用户的领域专家作为质量决策者（即 "benevolent dictator"，译注：原意 "仁慈的独裁者"，指那种虽一人拍板但始终以用户利益为先的角色）。
用 notebook 来审阅 trace 和分析数据，或者借助像 Claude 或 Codex 这样的 AI 编程助手，自建一个自定义标注界面。无论哪种方式，你都可以编写任意代码、可视化数据并快速迭代。下面的视频展示了一个在 notebook 里搭建的简易标注界面。
Q: 我应该把多少开发预算分配给评估？
要认识到，评估是开发流程的一部分，而不是一项独立的预算条目，这跟调试是软件开发的一部分是类似的。
你应该始终在做错误分析。通过错误分析发现的问题中，很多都是显而易见的 bug，你顺手就修了。这些修复不需要单独的评估基础设施，它们本身就是开发的一部分。
是否要构建自动评估器，说到底是个成本收益分析。如果你用一条简单的断言或正则就能捕获一个错误，成本极低，那就值得做。但如果你需要让一个 LLM-as-judge（以 LLM 为评审器）的评估器与你对齐，就要掂量这个失败模式值不值得投入。
在我们做过的项目里，60-80% 的开发时间都花在了错误分析和评估上。期待你大部分精力都用在理解失败上（即看数据），而不是搭建自动检查。
要警惕为了追求高评估通过率而过度优化。如果你 100% 通过评估，大概率说明你对自己的系统还不够狠。70% 的通过率反而可能意味着评估更有意义，真的在给你的应用做压力测试。关注那些能帮你发现真问题的评估，而不是让指标好看的那一类。
Q: 考虑到 AI 发展如此之快，当今的评估方法在 5-10 年后还管用吗？
管用。即便有完美的模型，你仍然需要验证它是否在解决正确的问题。对系统化错误分析、领域特定测试和监控的需求依然重要。
今天的 prompt 工程技巧可能会过时，但你依然需要理解失败模式。此外，LLM 没法读懂你的心思；研究表明，人需要观察 LLM 的行为，才能把自己的需求真正外化出来。
关于这场争论的更深入视角，可以看这两种观点："模型即产品"（"The model is the product"）与"模型不是产品"（"The model is NOT the product"）。
Q: 如何向团队争取对评估的投入？
不要试图向团队 "推销评估"。反过来，把你查看数据时发现的真东西直接拿给他们看。
先自己做错误分析。看 50 到 100 段真实的用户对话，找出产品失败的最常见方式。用这些发现来讲述一个数据驱动的故事。
向团队展示：
- 你发现的最主要的失败模式清单
- 反映高影响力错误出现频率的指标
- 用户与产品交互中那些出乎意料的方式
- 你发现并修复的 bug 报告，包装成"已阻止的生产事故"
把评估定位成开发的一部分，而非可选的测试环节。维护一份运行日志，记录你捕获的错误、你学到的、修复方案，以及你可能避免的影响。每周或每月分享一次。像"我们在用户看到之前拦下了 47 个问题"这样具体的报告，比关于评估的抽象说辞更容易让人看到价值。
这种方式能建立信任。别只是甩仪表盘和指标，要讲你在数据中发现了什么的故事。通过叙述你的发现，你把正在学的东西教给了团队，提供了立等可取的价值。当你修复一个问题时，展示这个具体问题的错误率是如何下降的。不久之后，团队会看到进展，并主动问"你是怎么做到的"。让结果而不是方法去主导对话。
这与经典的机器学习项目类似：结果是投机性的，进步受限于对实验的不断迭代。在这种情况下，重要的是分享每次实验的收获，以展示进展并争取投入。
Q: 为什么 "错误分析"（error analysis）在 AI 评估中如此重要？具体该怎么做？
错误分析是评估中最重要的活动。它帮你决定到底该写哪些评估；它让你识别出专属于你的应用和数据的失败模式。流程如下：
1. 创建数据集
收集用户与 LLM 交互的有代表性的 trace。如果你手上没有数据，可以先生成合成数据（synthetic data）来起步。
2. 开放式编码（Open Coding）
由人类标注员（最好是一位 "仁慈的独裁者"）来审阅 trace，并对观察到的问题写下开放式笔记。这个过程类似 "写日记"，改编自定性研究方法。建议先自己标注至少 30 条 trace，再去看 agent 提出的建议。起步时，建议先聚焦于记下 trace 中观察到的第一个失败，因为上游错误会引发下游问题；不过条件允许的话，也可以把彼此独立的失败都打上标签。这一步应当由领域专家执行。
3. 关联编码（Axial Coding）
把开放式笔记归类成一份"失败分类体系"（failure taxonomy）。也就是说，把相似的失败归入不同的类别。关联编码是最关键的一步。结束时，统计每个类别下的失败数量。这步可以借助 LLM 来辅助。
4. 迭代精炼
让 agent 对数据进行聚类，并挑选一个多样化的初始样本。在你完成最初的 30 条标注之后，让它在剩余的 trace 中搜索你描述的失败的可能实例。接受或拒绝它的建议，持续迭代，直到达到理论饱和（theoretical saturation），也就是说，新的审阅不再揭示新的失败模式，也不再改变既有的模式。
一份大约 100 条多样化 trace 的工作池，是这个 "人 + agent" 循环的有用护栏。agent 可以把你的注意力聚焦在最富含信息的 trace 上，这样你就不用把 100 条都顺序读一遍。每类评估各需要多少样例，请看完整拆解。
你应该经常重做这一过程。还有一些更高级的采样方法，如聚类、按用户反馈排序、按高概率失败模式排序。随着时间推移，你会培养出对数据中哪里更容易出问题的 "嗅觉"。
不要跳过错误分析。它能保证你构建的评估指标是被真实的应用行为所支撑的，而不是被那些反生产力的通用指标（大多数平台都会把你推向的方向）所误导。要看错误分析如何发挥作用的示例，可以看这个视频，或这篇博客。
下面是错误分析过程的一张可视化图，由我们的一位学员 Pawel Huryn 制作，含它如何融入整体评估流程：
Q: 在标注数据之前，我是否需要一份参考答案或评分标准？
不需要。动手审阅样例之前就写评分标准，可能会碍事。
先把几个定义说清楚：
- 参考答案（reference answer）：一个正确响应的样例。
- 评分标准（rubric）：一套用于评判响应的准则，例如它是否遵循退款政策。
两者都有用，但请把你最初的预期视为一个起点，并准备去修订它。
更常见的做法是，先看完一些样例，再制定详细的评分标准。评审员会变得过于专注于逐项核对，反而漏掉评分标准之外的问题。给评审员留出空间，让他们注意到你没预料到的事情。你对"什么算好"的这种调整，就叫"标准漂移"（criteria drift）。
举个例子，假设你有一个处理退款的客服 agent，它按公司政策会把退款升级给人工。你可能要读过几条交互之后才会意识到：现有流程对用户其实很不友好。不要低估审阅样例时会出现多大程度的标准漂移！
我们建议用错误分析来系统地审阅样例，再决定哪些内容可能写进评分标准。具体做法是：写下哪些地方看起来有问题，然后把相似的笔记归类，看哪些问题反复出现。操作演示可以看这个 live demo。
完成错误分析之后，你就能写出更好的、由用户和应用行为所驱动的评分标准。你还应当定期做错误分析，确保评分标准保持更新。
Q: 我是否应该记录那些并非模型原因导致的问题？
要。在审阅交互时，记下任何让产品变得不那么有用的东西。这包括那些与模型无关的、缺失的或有问题的功能。此外，不要纠结于错误产生的原因，那应该在你排好修复优先级之后再说。
举例来说，一个客服 agent 可能告诉客户订单已经发出，却没有提供物流追踪链接。即便你的 AI 没有获取物流链接的能力，也要把这个问题记下来。构建评估的前提，就是通过错误分析识别并排定修复优先级。其中一些最终可能是工程或设计问题，并不需要自动评估器，但它们仍然值得修！
最后，我们发现：推迟做根因分析，先聚焦于问题本身，能让你在标注更多数据的同时，写出更高质量的标注。
Q: 一个评估需要多少条样例？
构建评估是一条流水线，每个阶段需要的数据量各不相同。各阶段如下：
| 阶段 | 该做什么 |
|---|---|
| 1. 审阅应用 | 阅读 trace，把应用失败的方式记下来。这个过程叫"错误发现"（error discovery）。从 100 条多样化的 trace 开始，自己至少标注前 30 条。 |
| 2. 创建并验证评估器 | 在两种评估器类型之间二选一：当某个客观规则就能识别失败时，用基于代码的评估（code-based eval）。对每一条规则，覆盖 Pass 和 Fail 的样例以及重要的边界情况。当失败需要借助人类判断时，用 LLM judge（LLM 评审器）。对每个失败模式标注 100 到 200 条样例。 |
| 3. 构建可复跑的评估集 | 收集能代表重要工作流和已确认失败的样例。每次修改应用时跑这套集合。这类集合通常会增长到 100 条以上。 |
阶段 1：审阅 trace 以发现失败
trace 是用户与应用一次完整会话的完整记录。让一个编程 agent 帮你对初始样本池做抽样，使其覆盖不同的用户和工作流。我们的评估插件（evals plugin）能帮你做抽样，并搭一个用于审阅 trace 的标注界面。
自己先至少审阅 30 条 trace
我们建议：在让 agent 推荐失败之前，自己先用"错误发现"的流程标注至少 30 条 trace。把任何看起来有问题的地方以自由文本的形式记下来
