这篇解决了「评测指标做了一堆，却不知道 AI 到底行不行」的问题：给出从找专家到建 LLM 评审的完整路线图。
核心是 Critique Shadowing：让首席领域专家只做通过/不通过的二元判断并写详细批评，再用这些批评做 few-shot 构建 LLM 评审，迭代到与专家一致率可接受，最后按维度切分做错误分析。最容易出现误用的地方是用 1-5 打分——作者断言这些分数多半与专家判断不相关；另外一致率指标在类别不平衡时会失真，要看 TPR/TNR。
相比市面上教你怎么调评审提示词的内容，本文的增量在于把「看数据」制度化：评审员只是副产品，真正驱动改进的是专家与数据的高频接触。中文读者可把这套流程直接搬进国内团队的交付评审场景；叠加的变量是领域专家的可用时间，需要按文中方法把审阅界面做得足够顺手。
读完先找到你的首席领域专家，挑 30 条真实交互，做一轮 pass/fail 加批评的人工评审。
—— FDEChina编辑部 · 实战派
问题：AI 团队正在被数据淹没
今年早些时候，我写了《Your AI product needs evals》。很多人问：「我该怎么入门 LLM-as-a-judge（以 LLM 为评审）？」这篇指南分享我在帮助 30 多家公司搭建评估系统之后学到的东西。
你是否花了几周搭好一个 AI 系统，却发现自己根本不知道它到底好不好用？你不是一个人。我注意到团队在用 LLM 评估 AI 输出时，反复犯同样的错误：
- 指标太多：创建大量度量项，多到无法管理。
- 随意的打分体系：在多个维度上使用未经校准的量表（如 1-5），分数之间的差异不清晰、很主观。什么东西算 3 分、什么算 4 分？没人知道，而且不同评估者对这些量表的解读常常不同。
- 忽视领域专家：不让真正深刻理解业务的人参与。
- 指标未经验证：使用的度量并不真正反映用户或业务在乎的东西。
结果呢？团队要么被堆积如山的指标淹没，要么握着一堆不信任、用不上的数据。进展停摆，人人沮丧。
比如，我看到过下面这样的仪表盘——一张糟糕评估仪表盘的示意例子，这非常常见。在一堆 1-5 分的分数上打转，往往是评估流程糟糕的信号（原因后文详述）。在这篇文章里，我会展示如何避开这些坑。解法是我称之为「批评跟随」（Critique Shadowing）的技术。下面一步一步来讲。
第一步：找到首席领域专家
大多数组织里，通常有一（也许两）个关键人物，他们的判断对你的 AI 产品成败至关重要。他们是拥有深厚领域专长的人，或代表你的目标用户。尽早找到并让这位「首席领域专家」（Principal Domain Expert）参与进来，至关重要。
为什么找对领域专家如此重要？
- 他们设定标准：这个人不仅定义什么在技术上可接受，还帮你判断你是不是在做用户真正想要的东西。
- 捕捉未言明的期望：让他们参与，你能挖掘出他们的偏好和期望——这些往往无法在一开始就完整表达出来。通过评估过程，你帮他们弄清一次「过得去」的 AI 交互长什么样。
- 判断的一致性：组织里的人对 AI 表现可能有不同看法。聚焦首席专家能保证评估一致，并与最关键的标准对齐。
- 主人翁感：让专家参与会让他们在 AI 的开发中有一份投入，因为他们亲手参与了塑造。最终，他们更可能认可这个 AI。
首席领域专家的例子：
- 心理健康 AI 助手的心理学家。
- 分析法律文书的 AI 背后的律师。
- 客服聊天机器人对应的客服总监。
- 教育类 AI 工具的领衔教师或课程开发者。
例外情况：在小公司，这可能就是 CEO 或创始人。如果你是独立开发者，你自己就该是领域专家（但要诚实地评估自己的专业程度）。如果你必须依赖领导层，就应定期用真实用户反馈检验他们的假设。
许多开发者试图自己充当领域专家，或者找个顺手的代理（比如自己的上级）。这是灾难的配方。人们对「什么可接受」意见不一，你不可能让所有人满意。重要的是你的首席领域专家满意。
记住：这不必占用领域专家太多时间，本文后面会讲如何让流程高效。他们的参与对 AI 的成功绝对关键。
找到专家后，下一步是给他们合适的数据来审。我们接着谈怎么做。
第二步：构建数据集
有了首席领域专家，下一步是构建一个能覆盖 AI 将遇到的问题的数据集。数据集必须多样，并代表 AI 在生产中将遇到的交互类型。
为什么多样的数据集很重要？
- 全面测试：确保 AI 在广泛的情境下得到评估。
- 真实交互：反映真实的用户行为，评估才更相关。
- 发现弱点：帮助暴露 AI 可能吃力或出错的地方。
为数据集搭建结构的维度
你要为用例定义合理的维度。例如，我给 B2C 应用常用的维度是：
- 功能（Features）：AI 产品的具体功能。
- 场景（Scenarios）：AI 可能遇到并需要处理的情境或问题。
- 画像（Personas）：有鲜明特征和需求的代表性用户画像。
下面是功能、场景、画像的例子。
功能：
| 功能 | 描述 |
|---|---|
| 邮件摘要 | 把冗长邮件浓缩成要点。 |
| 会议排期 | 自动安排跨时区的会议。 |
| 订单追踪 | 提供发货状态和配送更新。 |
| 联系人搜索 | 从数据库中查找并取回联系人信息。 |
| 语言翻译 | 在不同语言之间翻译文本。 |
| 内容推荐 | 根据用户兴趣推荐文章或商品。 |
场景（指 AI 需要处理的情境，不基于 AI 回答的结果）：
| 场景 | 描述 |
|---|---|
| 多条匹配 | 用户请求命中多个结果，需要收窄。例如：用户问「我的订单在哪？」但有三笔进行中的订单（#123、#124、#125）。AI 必须帮忙确认问的是哪一笔。 |
| 无匹配 | 用户请求没有命中结果，需要替代方案或纠正。例如：用户搜索不存在的订单 #ABC-123。AI 应说明有效的订单号格式，并建议查收确认邮件。 |
| 含糊请求 | 用户输入缺少必要的具体性。例如：用户说「我要改配送」，却没说是哪笔订单、要改什么（日期、地址等）。 |
| 提供了无效数据 | 用户给出错误的数据类型或格式。例如：用户想用普通订单号（而非退货授权 RMA 号）追踪退货。 |
| 系统错误 | 技术故障导致无法正常运作。例如：查询订单时库存数据库暂时不可用。AI 需要解释情况并提供替代方案。 |
| 信息不完整 | 用户遗漏了必要细节。例如：用户想发起退货，却没给订单号或原因。AI 需要一步步收集这些信息。 |
| 不支持的功能 | 用户请求不存在的能力。例如：订单已发货后用户要求改支付方式。AI 必须解释为什么做不到，并给出替代建议。 |
画像：
| 画像 | 描述 |
|---|---|
| 新用户 | 不熟悉系统；需要引导。 |
| 专家用户 | 经验丰富；追求效率和高级功能。 |
| 非母语使用者 | 可能有语言障碍；使用非标准表达。 |
| 忙碌的职场人 | 看重快速、简洁的回复；常常一心多用。 |
| 技术恐惧者 | 对技术不自在；需要简单指令。 |
| 年长用户 | 可能不擅长科技；需要耐心和清晰的指引。 |
这套分类法（功能、场景、画像）并非普适。比如，如果用户并不直接与你的 AI 交互，画像可能根本没有意义。要点是：为你的用例列出合理的维度，并生成覆盖它们的数据。第一轮评估之后你很可能还要迭代这些维度。
生成数据
构建数据集时，你可以：
- 用现有数据：从你的 AI 系统中采样真实的用户交互或行为。
- 生成合成数据：用 LLM 创建覆盖各种功能、场景、画像的逼真用户输入。
通常两者结合，以保证覆盖面。合成数据不如真实数据，但是很好的起点。另外注意：我们只用 LLM 生成用户输入，不生成 LLM 的回复或系统内部行为。
无论用哪种数据，都要在你定义的维度上保持良好覆盖。
纳入系统信息
做测试数据时，在合适的地方使用你的 API 和数据库。这会产生逼真的数据，并触发正确的场景。有时你需要写些小程序来获取信息——这就是下面例子里「假设」一栏的含义。
生成用户输入的 LLM 提示示例
下面是一些示例提示，展示如何用 LLM 为不同的「功能 × 场景 × 画像」组合生成合成用户输入：
| ID | 功能 | 场景 | 画像 | 生成用户输入的 LLM 提示 | 假设（不直接写进提示） |
|---|---|---|---|---|---|
| 1 | 订单追踪 | 提供了无效数据 | 愤怒的客户 | 「生成一个明显恼火、不耐烦的用户输入：用简短生硬的语气催问订单 #1234567890 的物流状态，并带出之前有过不愉快经历的痕迹。」 | 订单号 #1234567890 在系统中不存在。 |
| 2 | 联系人搜索 | 多条匹配 | 新用户 | 「生成一个看起来不熟悉系统的用户输入：用犹豫的语言求助，想查找一个叫 Alex 的人的联系方式。用户应显得不确定需要什么信息。」 | 系统中存在多个叫 Alex 的联系人。 |
| 3 | 会议排期 | 含糊请求 | 忙碌的职场人 | 「模拟一个明显在赶时间的用户输入：用缩写式的语言、最少的细节请求安排会议。消息应显得仓促且缺少具体信息。」 | 无 |
| 4 | 内容推荐 | 无匹配 | 专家用户 | 「生成一个展现出深厚行业知识的用户输入：用专业术语请求可持续供应链管理方面的文章。用这篇文章里的信息构造一个可信的查询：{{article}}」 | 系统中不存在「可持续供应链管理的新趋势」相关文章。 |
生成合成数据
生成合成数据时，你只需要创建用户输入。然后把这些输入喂给你的 AI 系统去生成 AI 回复。重要的是把一切记录下来（log），这样你才能评估你的 AI。回顾一下流程：
- 生成用户输入：用 LLM 提示创建逼真的用户输入。
- 把输入喂进你的 AI 系统：把用户交互输入给当前状态的 AI。
- 捕获 AI 回复：记录 AI 的回复，形成完整交互。
- 整理交互：建一张表，存用户输入、AI 回复和相关元数据。
该生成多少数据？
这里没有标准答案。至少，你要生成足够的数据，让每个维度组合都有样例（在这个玩具例子里是功能、场景、画像）。此外，你要持续生成更多数据，直到你感觉再看不到新的失败模式。我生成多少数据随用例变化很大。
合成数据真的管用吗？你可能对合成数据持怀疑态度。毕竟不是真实数据，怎么会是好的替代品？以我的经验，它出奇地有效。我最喜欢的一些 AI 产品，比如 Hex，就在用合成数据支撑评测。Hex 的 AI 工程负责人 Bryan Bischof 说：「LLM 出奇擅长生成优秀且多样的用户提示示例。这既可以驱动应用功能，也可以悄悄用来搭建评测。如果这听起来像大语言蛇在吞自己的尾巴，我当初和你一样惊讶！我只能说：它管用，上线吧。」
数据集就绪后，接下来是最重要的部分：让首席领域专家评估这些交互。
第三步：让领域专家给出带批评的通过/不通过判断
领域专家的任务只有一件事：「AI 达成期望的结果了吗？」不要复杂的评分量表，不要多个指标，只做一个清晰的通过/不通过（pass/fail）决定。除此之外，领域专家应写一段批评（critique）来解释理由。
为什么简单的 pass/fail 指标很重要？
- 清晰与聚焦：二元决定迫使所有人思考什么真正重要，把评估化简为一个关键问题。
- 可行动的洞察：pass/fail 容易解读、容易行动，帮你迅速判断 AI 是否满足用户需求。
- 迫使说出期望：当领域专家必须判断一次交互通过与否时，他们不得不清楚地表达期望。这个过程会挖出关于 AI 应该如何表现的细微之处和未言明的假设。
- 资源的高效利用：让评估流程在起步阶段保持可管理，避免陷入可能还没有意义的细节指标。
批评的作用
除了二元 pass/fail 判断，写一段对 LLM 输出的详细批评也很重要。这些批评：
- 捕捉细微差别：批评让你能记下「大体正确但仍有改进空间」的情况。
- 指导改进：详细反馈提供 AI 如何增强的具体洞察。
- 在简单与深度之间取得平衡：pass/fail 给出明确裁决，批评提供理解判断理由所需的深度。
为什么要写批评？实践中，领域专家可能没有完全内化所有判断标准。强迫他们做出 pass/fail 决定并解释理由，能让他们澄清期望，为打磨 AI 提供宝贵指引。
「但我的问题很复杂！」相信我——从简单开始，才能逼你聚焦真正重要的东西。以后有需要再引入更多复杂度。
好批评的例子
为了展示 pass/fail 加详细批评在实践中如何运作，这里有一张用户与 AI 助手交互的示例表，既含通过也有失败，批评解释了为何得到该判断。AI 带着严重问题仍然通过时，批评会指出这些问题并说明为什么整体仍算通过；失败时，批评解释导致失败的关键要素。
| 用户与 AI 的交互 | 判断 | 批评 |
|---|---|---|
| 用户：「我要取消下周的航班预订。」 AI：「您下周的航班预订已取消，确认邮件已发送给您。」 |
通过 | AI 成功执行了用户请求：取消了航班并发送确认，达成了主要目标。但它应该在执行前先请求确认，以防误操作取消。尽管有这个关键疏漏，AI 仍完成了用户的请求，所以算通过；但加一个确认步骤会更安全。 |
| 用户：「法国的首都是什么？」 AI：「法国的首都是巴黎。」 |
通过 | AI 正确回答了问题，及时提供了准确信息。回复已经足够，AI 还可以补充有趣的冷知识或询问是否还有其他问题来增强体验。尽管有这些锦上添花的机会，AI 满足了用户的主要需求，所以通过。 |
| 用户：「我登不上账号，系统说密码不对。」 AI：「请点击『忘记密码』来重置密码。」 |
失败 | AI 给了通用方案，没有体察用户的沮丧情绪，也没有排查账号锁定等其他问题。它没有提供有同理心的支持或额外帮助。由于缺乏个性化帮助、用户体验差，判为失败。 |
| 用户：「帮我今晚 7 点订一家意大利餐厅的双人桌。」 AI：「已为您预订今晚 7 点 Luigi 意大利餐厅双人桌，确认号 12345。」 |
通过 | AI 高效完成了预订，提供了全部必要细节和确认号。不过它可以问用户是否有座位偏好或饮食限制。AI 成功完成了主要任务，所以通过，仅有提升服务的微小机会。 |
| 用户：「我需要帮我处理账单。」 AI：「请提供您的账号和全名。」 |
失败 | AI 在未通过安全方式核实用户身份的情况下索取敏感信息，可能危及安全。它应先引导用户走安全的身份验证流程。由于这一用户数据保护上的关键疏漏，判为失败。 |
这些例子展示了 AI 如何同时得到「通过」和「失败」。在批评里：对通过的情况，我们解释 AI 为什么满足了用户的主要需求，哪怕存在关键的可改进之处——我们点出这些改进空间，同时说明为什么整体仍判通过。对失败的情况，我们指出导致失败的关键要素，解释 AI 为什么没有达成用户的主要目标，或在用户体验、安全等重要因素上打了折扣。
最重要的是，批评要详细到可以直接放进 LLM 评审的 few-shot 提示里。换句话说，要详细到一个新员工能看懂。写得太简短是常见错误。
注意，例子中的用户交互为简洁起见做了简化——但你可能需要给领域专家更多上下文才能做出判断，后文详述。
在这一步，你不需要去分析 AI 失败背后的技术根因。很多时候，先建立对整体行为的感知，再钻进细节更有用。
起步阶段不要偏离二元 pass/fail
一个常见错误是偏离二元 pass/fail 判断。回顾一下前面那个仪表盘：如果你的评估是一堆让 LLM 打 1-5 分（或任何其他量表）的指标，你就做错了。展开讲讲为什么。
- 它不可行动：人们不知道拿到 3 分或 4 分该怎么办，看不出这个数为什么比 2 好。你需要能说出「这次交互通过是因为……」「这次交互失败是因为……」。
- 这些指标多半无关紧要。每次我分析领域专家判断的数据，它们都与这类指标不相关。让领域专家做二元判断，你才能弄清什么真正重要。
这就是我讨厌评估框架自带的现成指标的原因——它们往往把人带偏。
对 pass/fail 判断的常见反对意见：
- 「业务方说这 8 个维度都重要，所以我们都要评。」
- 「我们要能说出一次交互为什么通过、为什么失败。」
我可以向你保证：如果有人说你需要在 1-5 量表上测 8 样东西，他们并不知道自己要找什么，只是在猜。你必须让领域专家主导，做出带批评的 pass/fail 判断，这样才能弄清什么真正重要。在这个问题上要顶住。
让领域专家轻松地审数据
最后，要消除审数据的所有摩擦。我之前专门写过这一点。有时用电子表格就行。怎么最方便是一道判断题。我发现常常要给领域专家提供额外上下文，帮助他们理解用户交互，比如：
- 用户的元数据，如所在地区、订阅档位等。
- 系统的额外上下文，如当前时间、库存水平等。
- 可用于核对 AI 回复是否正确的资源（比如搜索数据库的能力等）。
所有这些数据都要呈现在同一屏上，让领域专家不用折腾就能审完。这就是我推荐做一个简单的 Web 应用来审数据的原因。
需要多少样例？
样例数量取决于任务复杂度。我的经验法则是：从大约 30 个样例起步，一直做到看不到新的失败模式为止；然后继续做，直到学不到新东西为止。
那条经验法则是为发现失败模式、撰写评分规则（rubric）服务的。验证一个自动评审需要更大的标注集：每个失败模式瞄准约 100 个样例，并保证有足够的通过与不通过样例来度量两类。低于 60 个样例时，置信区间往往宽得撑不起有用的结论。
接下来，我们看如何用这些数据构建 LLM 评审。
第四步：修复错误
看完数据后，你很可能在 AI 系统里发现错误。不要闷头继续搭 LLM 评审，而要先修掉明显的错误。记住，LLM-as-a-judge 的全部意义就是帮你发现这些错误——早点发现完全没问题！
如果你已经按我上一篇文章搭建了第一级评测（Level 1 evals），就不该存在大范围的错误。但有时错误仍会漏网。如果发现大范围错误，修掉它们，然后回到第三步。持续迭代，直到你觉得系统已经稳定。
第五步：迭代式构建 LLM 评审
批评的隐藏力量
没看过数据之前，你写不出好的评审提示。Shankar 等人的论文《Who Validates the Validators? Aligning LLM-Assisted Evaluation of LLM Outputs with Human Preferences》总结得很好：
为了给输出打分，人们需要把评估标准外化并定义出来；然而，给输出打分的过程本身又在帮助他们定义这套标准。我们把这个现象称为「标准漂移」（criteria drift）。它意味着：在人工评审 LLM 输出之前就把评估标准完全确定下来，是不可能的。
从专家示例开始
让我分享一个可以套用到你自己的用例上的真实案例。在帮 Honeycomb 打造 Query Assistant 功能时，我们需要一种办法评估 AI 是否在生成好的查询。下面是我们的 LLM 评审提示，包含来自领域专家 Phillip 的批评 few-shot 示例：
You are a Honeycomb query evaluator with advanced capabilities to judge if a query is good or not.
You understand the nuances of the Honeycomb query language, including what is likely to be
most useful from an analytics perspective.
Here is information about the Honeycomb query language:
{{query_language_info}}
Here are some guidelines for evaluating queries:
{{guidelines}}
Example evaluations:
<examples>
<example-1>
<nlq>show me traces where ip is 10.0.2.90</nlq>
<query>
{
"breakdowns": ["trace.trace_id"],
"calculations": [{"op": "COUNT"}],
"filters": [{"column": "net.host.ip", "op": "=", "value": "10.0.2.90"}]
}
</query>
<critique>
{
"critique": "The query correctly filters for traces with an IP address of 10.0.2.90
and counts the occurrences of those traces, grouped by trace.trace_id. The response
is good as it meets the requirement of showing traces from a specific IP address
without additional complexities.",
"outcome": "good"
}
</critique>
</example-1>
<example-2>
<nlq>show me slowest trace</nlq>
<query>
{
"calculations": [{"column": "duration_ms", "op": "MAX"}],
"orders": [{"column": "duration_ms", "op": "MAX", "order": "descending"}],
"limit": 1
}
</query>
<critique>
{
"critique": "While the query attempts to find the slowest trace using MAX(duration_ms)
and ordering correctly, it fails to group by trace.trace_id. Without this grouping,
the query only shows the MAX(duration_ms) measurement over time, not the actual
slowest trace.",
"outcome": "bad"
}
</critique>
</example-2>
<example-3>
<nlq>count window-hash where window-hash exists per hour</nlq>
<query>
{
"breakdowns": ["window-hash"],
"calculations": [{"op": "COUNT"}],
"filters": [{"column": "window-hash", "op": "exists"}],
"time_range": 3600
}
</query>
<critique>
{
"critique": "While the query correctly counts window-hash occurrences, the time_range
of 3600 seconds (1 hour) is insufficient for per-hour analysis. When we say 'per hour',
we need a time_range of at least 36000 seconds to show meaningful hourly patterns.",
"outcome": "bad"
}
</critique>
</example-3>
</examples>
For the following query, first write a detailed critique explaining your reasoning,
then provide a pass/fail judgment in the same format as above.
<nlq>{{user_input}}</nlq>
<query>
{{generated_query}}
</query>
<critique>注意每个示例包含三部分：<nlq> 标签里的自然语言查询（NLQ）、<query> 标签里生成的查询、<critique> 标签里的批评和结论。
上面的提示中，示例批评是固定的。进阶做法是根据被评审的对象动态选择示例，你可以在那篇关于持续上下文学习（Continual In-Context Learning）的文章里了解更多。
持续迭代提示，直到与领域专家收敛
这个例子里，我用了一种很「低技术」的方法来迭代提示：我给 Phillip 发一张电子表格，包含四列——NLQ、生成的查询、批评、结论（通过/失败）。Phillip 在自己那份表格里填上他写的批评。我用这些来迭代改进提示。表格大致如下图所示。
我还跟踪了一致率（agreement rate）随时间的变化，确保我们在向一个好的提示收敛。
把一致率当指标使用的重要提醒：在这个例子里，我们用模型与人工评估者之间的一致率，是因为数据集大致平衡（约 50% 的实例是失败）。类别不平衡时，原始一致率可能有误导性。请把人工标注当作真值（ground truth），分开报告评审员的真阳性率（True Positive Rate）和真阴性率（True Negative Rate）。
我们只用了三次迭代，就让 LLM 与 Phillip 的一致率超过 90%。你的情况取决于任务复杂度。比如，Swyx 为 AI News——一个推荐质量极高、非常受欢迎的新闻聚合器——做过几百次类似的流程。这个产品广受好评的质量正源于这一流程。
如何优化 LLM 评审提示？
我通常手工调整提示，用 DSPy 这类提示优化器运气不佳。不过，我的朋友 Eugene Yan 刚发布了一个叫 Align Eval 的有前景的工具，我很喜欢它，因为它简单有效。另外别忘了前面提到的持续上下文学习——实现得当的话会很有效。
极少数情况下我会微调评审员，但我尽量不这么做，FAQ 部分有更多讨论。
流程中「人」的一面
这个过程中发生了意料之外的事。Honeycomb 的领域专家 Phillip Carter 发现，审阅 LLM 的批评帮他更清楚地表达了自己的评估标准。他说：「看到 LLM 如何拆解它的推理，我意识到自己在判断某些边界情况时并不一致。」
这是我反复见到的模式——构建 LLM 评审的过程，常常帮助标准化评估标准。
此外，因为这个流程强迫领域专家仔细看数据，我总会挖掘出关于产品、AI 能力和用户需求的新洞察。由此带来的收益，往往比做出一个 LLM 评审本身更有价值！
该多久评估一次？
我按固定周期做这种人工评审，并且在出现重大变更时做。比如更新了模型，我会把流程再跑一遍。这里我不搞得太科学化，靠自己的最佳判断。另外注意，头两轮迭代之后，我更倾向于针对错误取样而不是纯随机抽样：比如发现一个错误，我会搜索更多我认为可能触发同一错误的样例。但我总会保留一部分随机抽样。
如果行不通怎么办？
我见过这个流程失败的情况：
- AI 的范围铺得太大：比如 SaaS 产品里一个「你想干什么都行」的聊天机器人。
- 流程没被正确执行：没用首席领域专家、没写合格的批评等。
- 对齐的期望不现实或不可行。
每一种情况下，我都试图解决根因，而不是硬凑对齐。有时你可能无法达到想要的对齐，只能更依赖人工标注。不过，走完这里描述的流程后，你会拥有能帮你判断「该在多大程度上信任这个 LLM 评审」的指标。
我在 LLM 评审提示里注意到的错误
我见过的大多数 LLM 评审提示错误，都与「没提供好示例」有关：
- 完全不提供批评。
- 批评写得极其简短。
- 不提供外部上下文。你的示例应包含你评估时所用的全部信息，包括用户元数据、系统信息等外部信息。
- 示例不够多样。你需要广泛的示例，才能保证评审对广泛的输入都有效。
有时你可能很难把所有需要的东西塞进提示，得在示例的组织方式上动点脑筋。不过，随着上下文窗口扩大和提示缓存（prompt caching）普及，这已越来越不是问题。
第六步：做错误分析
有了 LLM 评审之后，你就拥有一个「用户与 AI 的交互 + LLM 判断」的数据集。如果你的指标显示领域专家与 LLM 评审的一致性可接受，就可以把这个评审用到真实或合成交互上。之后，你可以按数据的不同维度计算错误率。注意：只应在未见过的数据上计算，以免得到有偏的结果。
比如，如果你按画像、场景、功能等切分了数据，你的分析可能长这样：
| 功能 | 场景 | 画像 | 样例总数 | 失败率 |
|---|---|---|---|---|
| 订单追踪 | 多条匹配 | 新用户 | 42 | 24.3% |
| 订单追踪 | 多条匹配 | 专家用户 | 38 | 18.4% |
| 订单追踪 | 无匹配 | 专家用户 | 30 | 23.3% |
| 订单追踪 | 无匹配 | 新用户 | 20 | 75.0% |
| 联系人搜索 | 多条匹配 | 新用户 | 35 | 22.9% |
| 联系人搜索 | 多条匹配 | 专家用户 | 32 | 19.7% |
| 联系人搜索 | 无匹配 | 新用户 | 25 | 68.0% |
| 联系人搜索 | 无匹配 | 专家用户 | 28 | 21.4% |
对 trace 分类
知道了错误在哪里，就可以做错误分析、追到错误的根因。我最喜欢的方式是把每类错误的样例找出来，手工分类，推荐用电子表格。比如，「订单追踪 × 无匹配结果 × 新用户」的一条 trace 可能长这样：
示例 trace：这条 trace 里，用户给了一个无效订单号。AI 正确识别出订单号无效，但回复没有帮助。如果你还不熟悉 LLM trace 日志，请参考我上一篇关于评测的文章。注意这条 trace 为了可读性做过排版。
{
"user_input": "Where's my order #ABC123?",
"function_calls": [
{
"name": "search_order_database",
"args": {"order_id": "ABC123"},
"result": {
"status": "not_found",
"valid_patterns": ["XXX-XXX-XXX"]
}
},
{
"name": "retrieve_context",
"result": {
"relevant_docs": [
"Order numbers follow format XXX-XXX-XXX",
"New users should check confirmation email"
]
}
}
],
"llm_intermediate_steps": [
{
"thought": "User is new and order format is invalid",
"action": "Generate help message with format info"
}
],
"final_response": "I cannot find that order #. Please check the number and try again."
}这个例子里，你可能把这个错误分类为「缺少用户教育」（Missing User Education）：系统检索到了新用户上下文和格式信息，却没有把它放进回复——这提示我们可以改进提示。分类了一定量错误之后，可以按根因计算错误分布，可能长这样：
| 根因 | 数量 | 百分比 |
|---|---|---|
| 缺少用户教育 | 8 | 40% |
| 身份验证/权限问题 | 6 | 30% |
| 上下文处理差 | 4 | 20% |
| 错误提示不充分 | 2 | 10% |
现在你知道该把力气花在哪了。这不必花特别多时间，15 分钟就能推进不少。你也可以用 LLM 帮你做这个分类，但这超出了本文的范围（本文里的任何事你都可以用 LLM 辅助，只要你有验证结果的流程）。
错误分析的交互式演示
错误分析在机器学习领域由来已久。吴恩达的这个视频对整个流程做了很好的交互式讲解。
再次修复错误
现在你对错误有了感觉，可以回去再修一轮。回到第三步，迭代到你满意为止。注意：每修一个错误，都应尽量为它写一个测试用例。有时可以是测试套件里的一条断言（assertion），有时你可能需要为这类失败造一个更「专门」的 LLM 评审，下一节谈。
做好这件事需要数据素养
在实际中，调查数据比我在本文里展示的要难得多。它需要一种只有实践才能练出来的「数据嗅觉」。对统计学和数据分析工具有基本的熟悉也有帮助。我最喜欢的数据素养文章是 Jason Liu 和 Eugene Yan 合写的那篇。
第七步：创建更多专门的 LLM 评审（如有需要）
现在你知道 AI 的问题在哪里，可以决定是否、以及在哪里投入更定向的 LLM 评审。比如，如果发现 AI 在正确引用来源上有困难，就可以为它做一个定向评测。有些错误甚至不需要 LLM 评审（用基于代码的断言就够了）。
关键要点：在走完这套批评跟随流程之前，不要直接跳到专门的 LLM 评审。它能帮你理性决定时间该投在哪里。
批评跟随流程回顾
做法得当的话，LLM-as-a-judge 能大幅简化你的 AI 评估流程。下面是流程的可视化示意（流程图代码原样保留，步骤说明见其后）：
graph TB
A[Start] --> B[1 Find Principal Domain Expert]
B --> C[2 Create Dataset]
C --> D[3 Domain Expert Reviews Data]
D --> E{Found Errors?}
E -->|Yes| F[4 Fix Errors]
F --> D
E -->|No| G[5 Build LLM Judge]
G --> H[Test Against Domain Expert]
H --> I{Acceptable Agreement?}
I -->|No| J[Refine Prompt]
J --> H
I -->|Yes| K[6 Perform Error Analysis]
K --> L{Critical Issues Found?}
L -->|Yes| M[7 Fix Issues & Create Specialized Judges]
M --> D
L -->|No| N[Material Changes or Periodic Review?]
N -->|Yes| C批评跟随是一个带反馈回路的迭代流程。步骤如下：
- 找到首席领域专家。
- 构建数据集：生成覆盖你用例的多样样例；纳入真实或合成的用户交互。
- 领域专家审数据：专家做出通过/不通过判断；专家写出详细批评，解释自己的理由。
- 修复错误（如有发现）：处理评审中发现的问题；回到专家评审验证修复效果；如果仍有错误，回到第 3 步。
- 构建 LLM 评审：用专家示例创建提示；对照专家判断测试；迭代提示，直到一致率令人满意。
- 做错误分析：按不同维度计算错误率；识别模式与根因；修复错误并视需要回到第 3 步。
- 按需创建专门的评审。
这个流程永远不会真正结束。它会周期性重跑，或在出现重大变更时重跑。
归根结底，创造价值的不是评审本身
这个流程的真正价值在于看你的数据、做细致的分析。AI 评审可以是个有用的工具，但驱动结果的是走完这个流程。我甚至想说：造一个 LLM 评审，是我用来「骗」大家仔细看自家数据的一个漂亮小把戏！
没错，真正的业务价值来自看你的数据。不过嘛，叫法不同罢了。
你真的需要这套吗？
呼，看起来工作量不小！你真的需要吗？看情况。有些场景可以抄近路。比如：
- 你是独立开发者，同时自己就是领域专家。
- 你手头就有现成的测试数据（推文等）。
- 看数据的成本不高（比如你几个小时就能人工看完足够多的数据）。
这种情况下，你可以直接跳到类似第三步的地方，立刻开始看数据。而且既然看数据不太贵，只做错误分析、不建评审可能就够了（至少初期如此）。你可以把学到的东西立刻反映回主模型。这个例子并不穷尽，但让你对如何按需裁剪流程有个感觉。
不过，看数据这一步永远无法完全省掉！这恰恰是大多数人跳过的一步。别做那个人。
常见问题（FAQ）
如果我有一个好的评审 LLM，那不也是我想用在产品里的那个 LLM 吗？
有效的评审常常使用比被评估系统更大的模型或更多算力（通过更长的提示、思维链等）。不过，如果最强 LLM 的成本并非不可承受、延迟也不是问题，那你可能要重新考虑力气花在哪：这种情况下，把更多精力放在专门的 LLM 评审、基于代码的断言和 A/B 测试上可能更合理。但即便如此，在采用专门评审之前，你仍应走过看数据、批评 LLM 输出的流程。
你推荐微调评审员吗？
我不倾向微调 LLM 评审员，我宁愿把力气花在微调真正的业务 LLM 上。不过，微调护栏或其他专门的评审可能有用（尤其是小型分类器）。顺带一提，你可以借 LLM 评审来为微调主模型策展和加工数据。例如，你可以用评审员：剔除微调用的坏样例；参照批评生成更高质量的输出；用批评模拟高质量的思维链。当你想把一个大 LLM 蒸馏成小 LLM 时，用 LLM 评审增强微调数据就更有吸引力了。微调的细节超出本文范围，有兴趣可以看这些资源。
现成的 LLM 评审有什么问题？
严格说没有问题。只是很多人被它们带偏了。如果你有纪律，可以把它们套在自己的数据上，看它们是否说出有价值的东西。但我发现它们带来的困惑往往多于价值。
如何对照人工标注验证一个 LLM 评审？
把评审员当作一个二元分类器。请一位可信的领域专家给样例打标，然后拆成训练（train）、开发（dev）、测试（test）三组。训练集：选少量清晰的通过/失败样例，可用作评审提示里的 few-shot 示例。开发集：在这些样例上跑评审，把它的决定与人工标注对比；检查错误、修改提示、反复进行。开发集样例绝不能放进提示。测试集：在完成提示修改之前保持隐藏；冻结提示，在测试集上只跑一次评审，把结果作为评审性能的最终估计。
典型划分是 10% 到 20% 的标注样例用于训练，开发与测试各占 40% 到 45%。开发和测试集应各含足够的通过/失败样例来估计两类比率；可能的话，每个集合里每类瞄准 30 到 50 个样例。绝不要把开发或测试样例放进评审提示。
最后，用真阳性率和真阴性率来度量评审性能，因为失败很罕见时一致率会有误导性。比如，如果错误只出现在 5% 的样例里，一个永远预测「通过」的评审仍有 95% 的一致率，却一个错误也发现不了。文中的闪卡（flashcard）就是这个方法的可视化指南。
LLM 评审用什么模型？
对本文讲的这类评审员，我喜欢在成本/延迟预算内用我能负担的最强模型。这个预算可能与我的主模型不同，取决于我要打分的样例数量，随用例变化很大。
那护栏（guardrails）呢？
护栏是另一个相关但独立的话题。它是阻止 LLM 说出/做出有害或不当言行的一种手段。本文聚焦于帮你创建一个与业务目标对齐的评审员，尤其是在起步阶段。
我在用 LLM-as-a-judge，收获巨大，但没走你这套流程。
我信。本文不是使用 LLM 评审的唯一方式。事实上，我见过人们以各种有创意的方式使用它：排序、分类、模型选型等等。我聚焦的是一个起步阶段行之有效、能避开「指标泛滥」陷阱的方法。不过，无论你建哪种评审，看数据这个通用流程始终是核心。
传统 ML、LLM-as-a-judge 和人工标注之间怎么选？
答案（以及许多其他问题的答案）是：做能奏效的最简单的事。简单不一定意味着传统 ML。看你的情况，用 LLM API 当分类器，可能比训练并部署一个模型更省事。
能用小模型做评审员吗？
可以，有潜力。我只用过较大的模型做评审。这个问题的答案必须建立在数据上（即与领域专家的一致率）。
更新 LLM 模型时如何保证一致性？
你必须把流程再走一遍，并测量结果。
如何逐步减少人在回路来规模化？
你不需要领域专家给每个样例打分，只需要有代表性的样本。我不认为可以完全去掉人，因为 LLM 总要和某个东西对齐，而那个东西通常是人。随着你的评估系统变好，需要的人工投入自然会减少。
资源
以下是我推荐用来深入了解这个话题的资源：
- Your AI Product Needs Evals：本文的前身，对 LLM 产品评测做了高层概述。
- Who Validates the Validators? Aligning LLM-Assisted Evaluation of LLM Outputs with Human Preferences：Shreya Shankar 等人的论文，很好概述了评估 LLM 的挑战，以及遵循好流程的重要性。
- Align Eval：Eugene Yan 的新工具，帮你按好的流程构建 LLM 评审；他的配套博客文章也值得一读。
- Evaluating the Effectiveness of LLM-Evaluators (aka LLM-as-Judge)：同样出自 Eugene Yan 之手，是关于 LLM 评审各种用例与方法的好综述。
- Enhancing LLM-As-A-Judge with Grading Notes（Yi Liu 等）：描述了一种与本文非常相似的方法，对「写批评」（他们称之为 grading notes）的价值提供了另一个视角。
- Custom LLM as a Judge to Detect Hallucinations with Braintrust（Ankur Goyal 与 Shaymal Anadkt）：端到端构建 LLM 评审的完整示例；在该用例中，作者发现分类方法比数值评分更可靠（与本文结论一致）。
- Techniques for Self-Improving LLM Evals（Arize 的 Eric Xiao）：展示了构建 LLM 评测的好方法，附带一些值得一看的工具。
- How Dosu Used LangSmith to Achieve a 30% Accuracy Improvement with No Prompt Engineering（LangChain）：展示了用动态示例构建 LLM 提示的好方法。想法简单但有效，我已经把它适配到自己的用例上，包括 LLM 评审。该方法的视频讲解也值得一看。
- What We’ve Learned From A Year of Building with LLMs：对 LLM 开发众多实践面的好综述，强调了评估的重要性。
延伸阅读
如果你想继续深入评测与 Agent 交付实践，推荐阅读站内的 Agent 专题、AI Coding 专题，以及 FDE 实践指南 中关于评测与质量把关的章节；了解整体能力框架可参考 FDE 能力模型。
本文由 FDEChina 团队翻译自原文，转载已注明出处；如需引用请以原文为准。