Amazon首席应用科学家Eugene Yan提出的三步测评法正在重塑AI产品的质量评估体系。从人工标注到LLM评审对齐，再到自动化测评框架搭建，这套方法不仅解决了传统测评的高成本痛点，更让团队得以实现每周上百次的实验迭代。本文将深入解析如何在二元标签设计、失败样本构造、位置偏差消除等关键环节实现高效可靠的模型测评。

今天分享是 Eugene Yan 在 11 月发布的长文：《Product Evals in Three Simple Steps》（中文：三个步骤即可完成产品测评）。

如果你刚接触测评、正在测评市面上的模型，或准备为团队建立自己的测评体系，这篇文章会是一条极佳的入门路径。

Eugene Yan是 Amazon 的首席应用科学家，曾在阿里巴巴、Lazada、IBM 担任过数据科学家。

他的文章发布后被 LangChain 转发，并专门录制了 YouTube 视频，讲解这三步方法如何在真实团队中落地。

正文。

Eugene 在文章一开始，就把产品测评拆成了三个非常清晰的步骤：

1. First, label some data——先给一小部分数据打标签；
2. Then, align our LLM-evaluator——再校准一个 LLM “测评员”；
3. Finally, run our eval harness with each change——最后，把测评流程做成“跑一次就出结果”的测评框架，并在每次配置变更时运行。

这三个步骤的设计思路是：从少量高质量的人工标注出发，把“好/坏”的判断标准，用一个经过校准的 LLM-evaluator 固定下来，最后再把它封装进自动化的测评流程中。

这样一来，模型、prompt、RAG 配置每优化一次，都可以在同一套标准下快速得到测评结果，而不用每次重新组织人力、一条条人工复核。

下面，我们按原文的顺序，把这三个步骤拆开来看。

First, label some data先给一小部分数据打标签

1.从真实案例中采样，并用简单表格开始

Eugene 把第一步说得很具体：从现有的 LLM 请求中，采样一部分真实的输入与输出，围绕你关心的测评标准（例如：是否忠实、是否相关）打标签。

他建议一开始用最简单的工具即可，比如一张表格，包含下面几类列：

• input：模型收到的输入（例如工单、对话、文档片段）
• output：模型给出的输出
• additional metadata：任何有助于测评的额外信息（例如来源渠道、场景、用户类型等）
• label：标签列，用来记录这条样本是否“合格”

起步阶段不需要复杂标注系统，一个结构清晰的电子表格就足以支撑有效测评。

2.以二元标签为主：pass/fail或win/lose/tie

在标签设计上，Eugene 强烈建议优先使用二元标签，例如 pass/fail（通过/未通过），或win/lose/tie（胜/负/持平）

• 对于相对客观的标准，比如：总结是否忠实于原文、是否包含拒答，可以用 pass/fail（通过/未通过）；
• 对于相对主观的标准，比如：哪个总结更简洁、哪个回答更有帮助，可以用 win/lose/tie（胜/负/持平）这样的对比式标签。

他特别强调了一点：标注者在比较两个输出时，要允许选择 “tie（平局）”。

如果两个结果几乎一样好或一样差，却被强行要求选出一个“赢家”，会在标签里引入噪声，也让我们难以分辨哪些差异本身就微不足道。

3.为什么不推荐一开始用1–5分的打分表？

很多团队一开始会考虑用1–5分、1–7分的量表，Eugene 在文章中解释了他对这类打分方式的实际观察：

• 不同标注者之间，很难对“3分vs4分”达成一致；
• 即便写了很详细的标注 Rubric，人类之间的理解差异依然存在；
• 对 LLM-evaluator 来说，如果人类自己打分都不稳定，让模型“对齐”这套打分体系会更加困难。

他提到自己多次遇到这样的场景：业务方希望有更“细粒度”的打分，理由是以后可以灵活调整阈值——比如从“≥3算通过”调成“≥4算通过“，或者把“轻微错误”和“完全正确”区分开来。

但现实情况是：这些预期中的“灵活调阈值”几乎从来没发生过。

最后业务方真正需要的，仍然是一个可以汇报的“通过率/不通过率”，以及一个可执行的推荐阈值。

在这样的前提下，二元标签有几个明显好处：

• 让标注者做出清晰决策，避免模糊地游走在中间分数；
• 让 LLM-evaluator 的学习目标更明确，有助于提高一致性；
• 在测评阶段更容易计算 precision/recall/Kappa 等指标。

用 Eugene 的话说，二元标签可以带来更快、更一致的人工标注，也使后续的人工测评和 LLM-evaluator 对齐更顺畅。

4.把注意力放在“失败样本”上，并刻意构造失败

接下来，文章谈到一个容易被忽略但十分关键的点：测评集里，fail case（失败样本）的数量要足够多。

对大多数产品来说，真正影响用户信任的，是那些明显错误、违反预期、产生严重后果的缺陷。

如果整个数据集中几乎都是 pass，只夹杂少量 fail，那么这个测评集就很难支撑有效分析与对齐。

Eugene 给出的经验是：总样本量可以在 200+，其中至少要有 50–100 条失败样本。

如果只有几条失败样本，既不利于理解模型失败类型，也不足以对齐 LLM 评审者。

那如何获得足够多的失败样本？

Eugene 认为“使用更小、更弱的模型来生成输出”效果较好。

这些小模型即使尽力，也会自然暴露各种缺陷，例如：长上下文处理困难、推理链条断裂、边缘情况处理失当等，这些失败非常接近真实生产环境中可能出现的问题。

虽然现在流行用更大的模型来“生成一个带缺陷的答案”，作为bad case，但Eugene 认为，这类bad case很多时候会“脱离真实场景”，要么太夸张，要么过于隐晦，当 eval 只在这类bad case上表现好时，在真实生产环境中的表现往往不理想。

5.用active learning持续“捞”出新的失败样本

在有了初步测评集、并对齐出一个还算可靠的 LLM-evaluator 之后，Eugene 还建议引入一个步骤：主动学习（active learning）。

做法是：

• 先用已经校准好的 LLM-evaluator ，在大量未标注样本上运行；
• 从中筛出潜在bad case；
• 再把这些潜在 bad case 交给人类进行标注。

这样不仅可以降低人工标注成本，还能快速丰富测评集。

Then, align our LLM-evaluator把 LLM 调成一个稳定可靠的“测评员”

第二步的目标，是把前面人工标注的数据，用来训练/对齐一个 LLM-evaluator。

1.把它当作一个标准的机器学习问题来处理

Eugene 建议把对齐 LLM-evaluator 的过程，当成一个常规的机器学习问题来看待：

先定义一个 prompt 模板，输入包括：

• 原始输入（input）；
• 模型输出（output）；
• 测评相关的额外信息（additional metadata）；
• 让LLM-evaluator按照模板输出与测评集一致的标签（如pass/fail 或win/lose/tie）。

接着，需要对标注数据集做开发集和测试集划分：

• 例如用 75% 的数据作为开发集（dev set）——用于迭代 prompt 模板；
• 剩余 25% 作为测试集（test set）——用于衡量 LLM-evaluator 在新样本上的泛化能力；

这样可以避免我们在调 prompt 时，完全“记住”现有样本，而对新数据缺乏鲁棒性。

2.一个Evaluator只评一个维度，避免“God Evaluator”

在测评维度设计上，Eugene 非常明确地提出了一个反模式：不要把所有测评维度塞进一个“大一统测评器（God Evaluator）”里。

原因是，如果一个 evaluator 同时判断：忠实性、相关性、简洁度、语气、格式等 5–10 个维度，很难对它进行调优和错误分析；当测评结果不符合预期时，很难知道是哪一个维度“跑偏”。

更合理的做法是：为每一个维度单独训练/对齐一个 evaluator；然后用简单的规则把这些维度组合起来，例如：

• 所有「必备维度」都通过才算整体通过；
• 有些维度可以视为“北极星指标”（northstar），持续优化；
• 有些维度是“底线指标”（guardrail），任何一次失败都可以视为阻断上线（ship-blocker）。

3.在win/lose测评中，注意位置偏差（position bias）

Position bias 指的是当我们用 win/lose/tie 来比较两个输出时，测评员可能会对“排在前面的”产生偏好，认为它更好。

Eugene 提供了一套非常实操的做法：

• 在 prompt 中，用类似<control>和<treatment>的 XML 标签包住两份输出
• 先运行一次测评，让 baseline 在<control>，对照输出在<treatment>
• 再运行第二次测评，调换两者的位置，把对照输出放到<control>，baseline 放到<treatment>

简单来说：进行win/lose测评时，同一个问题测评两次，每次测评时，两个输出内容的位置调换。

一个校准良好的LLM-evaluator在两次测评中给出一致的结论，若前后结论反复横跳，很可能是两份输出本来就难以区分，可以标记为 tie，而不是强行判定 win/lose。

4.用precision/recall/Cohen’s Kappa来测评“测评者本身”

当测评者本身也是一个模型时，它也需要被测评。

Eugene 建议采用三类指标：

• Precision（精确率）：确保不会错误地标记过多的失败项；
• Recall（召回率）：对于 pass/fail 任务，可以优先考虑“失败”类别的召回率，确保能够识别出所有缺陷；
• Cohen’s Kappa：用来衡量模型评审与人工标注之间的一致性，0.4–0.6 一般被认为是“较强的一致性（substantial agreement）”，0.7 以上可以视为非常优秀。

Eugene 还提到现实中的一个观察：很多时候，人类标注者之间的 Kappa 只有 0.2–0.3，原因是在连续标注数百条样本后，人类的疲劳会非常明显，有时甚至会错过一半的缺陷。

因此，他认为LLM-evaluator的基准不应设想为“完美无误”，而是和人类相比是否更稳定、更高召回率、更一致。

LLM-evaluator真正的优势是：可以在几分钟内，对几百条样本做出稳定、可重复的评判，全天候工作，不会疲劳。这种能力可以极大提升实验迭代的频率和规模。

Finally,run our eval harness with each change把测评做成“可以反复运行的框架”

当标注数据和评审者都准备好之后，第三步是把这一切固化成一个evaluation harness（测评框架）。

1.测评框架的核心功能

Eugene 对 eval harness 的功能描述很清楚：

• 接收一批 input–output 样本（即实验产出的结果）；
• 并行调用多个 evaluator（受模型限流约束）；
• 汇总各维度的测评结果；
• 输出一份结构化的指标汇总表。

他个人喜欢让这个汇总表呈现为一行的dataframe，便于复制到 Excel 里；产品经理通常更习惯用 Excel 来追踪各次实验的测评记录，再配合条件格式（比如红绿色块）直观查看哪个维度有提升、哪个维度出现回退。

2.把 eval harness 接到实验流水线上

接下来，是把这个测评框架和实验流水线连接起来，这样，团队在调整配置时（优化），就可以形成一个非常简洁的循环：改一行配置（例如更换模型/修改 prompt）->运行流水线，生成一批新的输出->启动 eval harness，得到这批输出在各维度上的表现。

他举了一个非常具体的例子：如果团队想测评从 Claude Haiku 3.5 迁移到 Haiku 4.5 的效果，只需要：改动一行配置->启动实验室流水线->去吃个午饭->回来就能直接看到本次迁移在各个测评维度上的表现。

3.样本数量与“能不能上线”的统计置信度

文章中还专门用了一段，讨论需要多少样本，才能有足够置信度判断当前配置是否满足质量要求。

假设产品团队提出的质量目标是：缺陷率（defect rate）要低于 5%。

Eugene 给出了一组示例计算：如果在 200 条样本上观察到约 3% 的缺陷率，那么 95% 置信区间大约是 3% ± 2.4%，也就是区间在 0.6% 到 5.4% 之间，由于上界 5.4% 高于目标 5%，因此还不能有足够信心认为当前配置已经达标。

如果把样本量翻倍到 400 条：在同样 3% 观测缺陷率下，95% 置信区间会收窄到 3% ± 1.7%，区间约为 1.3% 到 4.7%，此时上界 4.7% 已经低于 5% 的要求，就可以更有把握地认为当前配置满足上线标准。

他也提醒了一个常常被忽略的事实：标准误差随样本量的增加，是按平方根缩减的——想要把误差减半，需要把样本量增加到原来的四倍，因此在增加样本量上会遇到明显的边际收益递减，这一点在 Anthropic 的一篇长文里也有更深入的推导与讨论。

4.一个真实团队的落地案例

文章的最后，Eugene 用了一个真实团队的案例，来说明这整套 product eval 流程的价值。有个团队花了大约四周时间梳理测评标准、收集并人工标注数据、对齐 LLM-evaluator、搭建实验与测评框架。

起初，部分人担心这会“拖慢产品进度”，但在测评体系搭起来之后，效果非常明显：接下来两周内，团队就跑了几十组实验：覆盖不同模型、不同检索配置、不同 prompt 模板、用于迭代出一个可上线的版本。在接下来的几个月里，又运行了几百次实验，打磨产品质量、处理长尾边界情况、逐步添加新功能与场景支持。

如果每次配置变更之后，都要依赖人类评审一条条看、慢慢标，这样的迭代节奏几乎不可能实现。

Eugene 在文末总结：良好的 product eval，不只是为了量化当前产品的质量，更是为了缩短反馈闭环、提高实验频率，让团队在可控风险下持续改进产品。

最后

读 Eugene Yan 这篇文章的时候，我反复有一种微妙的熟悉感——文中的每一条“坑”，我几乎都踩过。

1–5 分量表的混乱、God Evaluator 的不可控、样本里没有足够的失败案例……文章中很多问题看上去只是“测评方法的选择”，但背后往往对应着一个团队在真实项目中走过的弯路、试错的代价。

这篇文章值得反复阅读，Eugene 写的这些原则，看似简单，却都是经历过足够多失败之后，才沉淀下来的“精华经验”。

相关链接：

文章地址：https://eugeneyan.com/writing/product-evals/#first-label-some-data

LangChain视频地址：https://www.youtube.com/watch?v=mz7mAo4zIC8

Eugene Yan 个人Blog：https://eugeneyan.com/

Eugene Yan 的X账号：@Eugene Yan