三步构建高效的 Product Evals
第一步：为数据打标签
首先需要从 LLM 的请求中采样输入和输出，然后标注输出是否符合我们的评估标准（如忠实度、相关性等）。先用一个简单的电子表格，列包括输入、输出、有助于评估的额外元数据，以及一个新的标签列。
聚焦于二元的通过/失败或胜/负标签。如果标准是客观的——例如摘要是否忠实于原文，或是否包含拒绝回答——就使用通过/失败标签。对于主观标准，例如哪个摘要更简洁，就使用胜/负/平局比较。在后一种情况下，允许标注人员标明“平局”很有帮助。在两个输出几乎相同时强迫选择胜者，会引入噪声，并阻碍我们得出“某些差异可忽略不计”的结论。
那数值标签或李克特量表呢？虽然 1-5 分制提供了细粒度，但我发现很难让人工标注人员和 LLM 评测器保持一致性。“3”分和“4”分之间的差异往往很微妙。即使有详细的标注准则，不同的人工标注人员仍会给出不同的标签。如果人工标注人员很难依据准则一致地打分，LLM 评测器同样会面临挑战。二元标签通过强制清晰的决策边界，缓解了这一问题。
此外，尽管利益相关者有时要求提供细粒度的分数，以便后续灵活调整通过阈值（例如从 3 分提升到 4 分，或从轻微错误调整为无错误），但根据我的经验，完全没有人这样做。他们最终只是要求给出一个推荐阈值，以便他们报告通过率。既然终点都一样，不如从一开始就使用二元标签。这能让标注人员更快、更一致地打标签，也便于对齐我们的 LLM 评测器。
目标是 50-100 个失败用例。这取决于标签的总数，更重要的是取决于我们真正关心的标签数量。对于通过/失败评估，大多数情况下，关键在于“失败”项，因为这些是破坏信任的缺陷。一个拥有数百个标签但只有五个失败样本的数据集，对于对齐和评估我们的评估器来说毫无用处。我们需要一个平衡的数据集。我通常建议至少要有 50-100 个失败样本，总数在 200 个以上。
如何获取失败用例？我发现使用更小、能力较弱的模型来生成输出会很有效。即使这些模型尽力而为，它们也会自然地产生“有机”失败。它们可能在长上下文处理上存在困难，推理能力不足，或在边缘案例上失败——这些都是我们在生产中会遇到的失败类型。
一种流行的方法是提示一个强模型来生成合成缺陷。我发现这些合成缺陷存在问题。它们往往分布外，要么过于夸张，要么过于微妙，无法反映生产中的实际情况。当我们基于这些缺陷对齐评估器时，它们可能无法检测出真正影响用户的混乱、有机的问题。虽然我理解需要从一个起点开始引导评估，但如果我们的评估数据集仅由这些组成，我们就应优先补充来自生产环境的有机样本。
我们还可以应用主动学习。一旦我们拥有足够精确的评估器，就可以在未经标注的数据上运行它，以识别可能的失败案例并优先安排人工标注。这有助于我们在无需盲目标注数千个样本的情况下构建平衡的数据集。
然后，对齐我们的 LLM 评估器
有了标注样本，下一步是创建一个提示模板，输入输入和输出（以及附加元数据），并返回预期的标签。我们应该将这个问题视为常规机器学习问题，并将数据划分为开发集和测试集。例如，使用 75% 的样本进行对齐（即迭代提示模板），保留剩余的 25% 作为测试集。这能确保我们衡量的是评估器在新数据上的泛化能力，而不是对初始 75% 样本的过拟合。
每个维度只建一个评估器。让评估器对齐单一标准、达到高准确率要容易得多。一个典型的反模式是构建一个"上帝评估器"（参见 God Object），试图在同一个 prompt 里评估 5 到 10 个维度——忠实度、相关性、简洁性、语气等等。我从没见过这种做法效果好。而且这种大杂烩评估器校准起来是场噩梦，因为很难隔离出到底是哪个维度出了偏差。
正确的做法是分别构建独立的评估器，再用简单的规则组合起来（比如所有维度都通过才算通过）。这样能得到细粒度的指标，清楚看到是哪个维度拖累了整体表现。还能对不同指标区别对待：有些是护栏指标，不达标就不能上线；有些是北极星指标，我们希望持续提升。
做胜/负评估时，要消除位置偏差。方法是调换顺序跑两遍评估。我通常用 XML 标签，比如 <control> 和 <treatment>，把待评估的输出放里面。第一次评估时，基线放在 <control>，对比输出放在 <treatment>；第二次评估则反过来。这样能确保评估器评判的是内容本身，而不是被顺序或 XML 标签带偏。
校准良好的评估器应该前后一致：如果基线在第一次评估中胜出，第二次也应该胜出。如果结论翻转了，说明两个输出可能过于相似、难以区分，这时可以标记为平局，不必强行给出一个充满噪声的判断。
用精确率、召回率和 Cohen's Kappa 来评估这些评估器。既然用的是二元标签，评估方法很直接。对通过/失败类任务，可以优先关注"失败"类的召回率，因为我们要确保不漏掉缺陷；同时也要有不错的精确率，避免误报太多失败。要衡量与人工标注的一致性，可以看 Cohen's Kappa：0.4 到 0.6 表示相当一致，0.7 以上则是优秀。
评估的基准是人类表现，而非完美无缺。 我们有时会收到 90% 以上准确率的需求。我的做法是委婉地提醒对方：人类标注员很少能达到这个水平。我常见到人类标注员之间的评分者信度（Cohen's Kappa）低至 0.2 - 0.3。此外，标注员在看了几百个样本后，因疲劳可能漏掉多达 50% 的缺陷。因此，如果我们的 LLM 评估器在召回率和一致性上优于人类标注员，我就认为这是成功的。
在我看来，真正的价值不在于比人类标注员获得更高的准确率，而在于可扩展性。一个对齐良好的评估器允许我们在几分钟内、全天候地以一致的（甚至超越人类的）判断力处理数百个样本，而不受人工审核的瓶颈限制。这使得我们能够大规模运行实验，从而更快迭代。
最后，用每次变更运行评估框架
最后，我们可以将各个独立的评估器组合成一个评估框架（eval harness）。该框架应接受输入-输出对的数据集，在满足速率限制的前提下并行运行相关评估器，并聚合结果。我还发现，提供一个将这些指标输出为单行 dataframe 的工具函数很有帮助。这样便于将结果复制粘贴到 Excel 中（产品经理更喜欢用 Excel 进行追踪）。加上一点条件格式，我们就能轻松识别改进或退步。
将评估框架与实验管道集成。 当我们的评估框架能够直接消费实验输出时，大规模运行实验和评估就变得简单了。我们可以调整配置——提示词模板、检索参数、模型选择及参数——生成输出，并立即进行评估。这种紧密的反馈循环使我们能够快速迭代。例如，如果我们想评估从 Claude Haiku 3.5 迁移到 Haiku 4.5 的模型，只需改一行配置，启动管道，然后去吃个午饭，回来查看结果即可。
我们应该评估多少个样本？ 这取决于我们所需的统计置信度。假设我们的产品要求是缺陷率低于 5%。如果我们在 200 个样本上运行实验，观察到 3% 的缺陷率，那么我们的 95% 置信区间大约是 3% ± 2.4%。这给出了 0.6% - 5.4% 的缺陷率范围。由于上限超过了 5%，我们无法有信心地断定当前配置已达到发布要求。
通过增加样本量可以进一步收窄估算区间。若将输出增至 400 个样本，误差范围可缩至 3% ± 1.7%，此时 4.7% 的上限已低于 5% 的要求。注意：由于标准误随样本量的平方根成比例减小，要将误差范围缩小一半，需将样本量增至原来的四倍。因此，单纯增加样本量的边际收益是递减的。（详见 Anthropic 的深度分析） • • • 最后分享一个善用评估的实例。近期我看到一个团队投入约四周时间构建评估框架，包括定义评估标准、收集人工标注、对齐评估者以及搭建实验平台。最初，利益相关者担心这会分散构建产品本身的精力。 但回报几乎立竿见影。接下来的两周里，团队针对不同模型、检索配置和提示模板跑了数十次实验，快速迭代出可用产品。随后几个月又跑了数百次实验，用于打磨产品、添加新功能并优化边界情况。如果每次配置变更后都要依赖人工标注，这根本不可能实现。 这正是产品评估的价值所在：不仅用于衡量和提升产品质量，更在于缩短反馈闭环，助力更快迭代。 **更新：** LangChain/LangSmith 创始人 Harrison Chase 录制了一段视频，演示如何在 LangSmith 中构建产品评估（包括标签数据、对齐评估者、运行评估框架）。延伸阅读
- Your AI Product Needs Evals
- Using LLM-as-a-Judge For Evaluation: A Complete Guide
- LLM Evals: Everything You Need to Know
- In Defense of AI Evals, for Everyone
- Evaluating the Effectiveness of LLM-Evaluators (aka LLM-as-Judge)
如果这篇文章对你有帮助，请按以下格式引用：
Yan, Ziyou. (2025年11月). Product Evals in Three Simple Steps. eugeneyan.com. https://eugeneyan.com/writing/product-evals/.
或
@article{yan2025product-evals,
title = {Product Evals in Three Simple Steps},
author = {Yan, Ziyou},
journal = {eugeneyan.com},
year = {2025},
month = {Nov},
url = {https://eugeneyan.com/writing/product-evals/}
}