《LLM-as-Judge 救不了产品，真正重要的是改进流程》
LLM-as-Judge 救不了产品，真正重要的是改进流程
Eugene Yan 文章中文整理版
原文标题：An LLM-as-Judge Won’t Save The Product—Fixing Your Process Will
作者：Eugene Yan（Ziyou Yan）
发布时间：2025 年 4 月
说明：本文是对原文的中文结构化整理与关键观点转述，不是对整篇章的逐字全文翻译。原文中的图片 URL 均按原始地址保留。
核心观点
很多团队误以为，只要再添一个工具、一个指标，或者一个 LLM-as-Judge，就能解决 AI 产品的质量问题。
但这通常绕开了真正的核心问题：团队是否认真观察了数据，是否定义了清晰的成功标准，是否持续分析失败，是否用实验验证改动，以及是否建立了稳定的反馈循环。
评测不是静态文件，也不是快速补丁。它是一套持续实践，结合了：
科学方法；
评测驱动开发；
AI 输出监控；
人工抽样和反馈分析。
一句话概括：LLM-as-Judge 只能放大已有流程，不能替代流程本身。
一、产品评测本质上是科学方法
构建产品评测，本质上是在应用科学方法。它是一个不断循环的过程：观察、提出假设、设计实验、分析结果，再根据结果继续迭代。
1. 先观察数据
第一步是认真查看数据，而不是凭感觉判断产品好不好。
需要观察的内容包括：
用户输入；
AI 的输出；
用户如何与系统交互；
系统在哪些场景表现良好；
系统在哪些场景失败；
失败是否集中在某些输入、用户群或工作流中。
只有先看见真实的失败模式，团队才知道应该改进什么。
2. 标注数据，并优先处理问题样本
接下来要对一部分数据进行标注，尤其要关注有问题的输出。
标注不应只收集“成功案例”，也不能只收集最严重的失败。更合理的做法是构造平衡且具有代表性的数据集，尽量覆盖真实输入分布，并同时包含成功和失败样本。
理想情况下，可以从大致 50:50 的通过与失败样本开始。这个数据集会成为针对性评测的基础，用来持续跟踪已经发现的问题。
3. 针对失败提出假设
观察到失败后，要进一步追问：为什么会失败？
例如：
RAG 的检索模块没有返回相关上下文；
模型没有遵循复杂指令；
多条指令之间存在冲突；
Prompt 没有清楚表达边界条件；
工具调用或外部系统返回了错误信息；
模型输出看似流畅，但没有真正完成用户目标。
分析时不能只看最终答案，还要查看检索文档、推理轨迹、工具调用和错误输出。这样才能确定哪些失败最值得修复，哪些假设最值得验证。
4. 设计实验并验证假设
接下来针对假设设计实验。实验可能包括：
重写 Prompt；
更新检索组件；
更换模型；
调整工具接口；
改变上下文组织方式；
修改系统的错误处理策略。
一个好的实验应当提前定义什么结果可以支持假设，什么结果可以推翻假设。最好还要设置基线或对照条件，避免把自然波动误认为改进。
5. 测量结果并分析错误
这是整个流程里最难的一步。
不能只做“凭感觉看起来更好”的 vibe check，而要量化实验是否真的改善了结果。例如：
准确率是否提高？
生成的缺陷是否减少？
新旧版本的成对比较结果是否更好？
关键失败类型是否减少？
用户是否更容易完成任务？
如果无法测量结果，就无法确定改动是否有效，也就无法持续改进。
6. 进入下一轮循环
如果实验成功，就应用更新；如果实验失败，就进行错误分析，修正假设，再设计下一轮实验。
经过不断循环，产品评测会成为一个数据飞轮：它帮助产品变得更好，减少缺陷，并逐渐赢得用户信任。
二、评测驱动开发：先定义成功，再构建系统
评测驱动开发（Eval-Driven Development，简称 EDD）与测试驱动开发（Test-Driven Development，简称 TDD）非常相似。
在 TDD 中，开发者先写测试，再实现能够通过测试的软件。EDD 遵循相同的理念：在开发 AI 功能之前，先通过产品评测定义成功标准，从第一天开始确保目标一致、结果可测量。
EDD 的基本流程
为目标功能定义成功标准。
先评测当前基线，例如一个简单 Prompt 或现有系统。
记录初始结果，形成可比较的基准。
修改 Prompt、系统或模型。
重新运行评测。
比较新旧版本的结果。
保留有效改进，撤回或修正无效改动。
之后，每一个 Prompt 调整、系统更新和模型迭代都应该进入同一套评测流程。
例如：
简化 Prompt 后，回答是否更忠实？
更新检索组件后，相关文档召回率是否提高？
换模型后，任务完成率是否提高？
新版本是否在改善一个指标的同时损害了另一个指标？
EDD 的价值在于提供即时且相对客观的反馈。团队不再依赖模糊的直觉，而是通过“写评测、做改动、跑评测、整合改进”的循环推动可测量的进步。
EDD 并不是全新的思想
机器学习团队其实已经实践这种方法很多年：训练模型时使用验证集和测试集，在模型迭代过程中持续比较结果。
EDD 的变化之处在于，它把这一思想更明确地带入 AI 产品开发：评测不只是研究阶段的指标，而是产品需求、工程迭代和线上质量管理的共同基础。
三、LLM-as-Judge 不能替代人类监督
即使使用自动化评估器，也仍然需要人工监督。
自动化评测可以扩大监控规模，但它无法弥补团队对 AI 输出和用户反馈的忽视。如果团队从来不主动查看系统输出，不分析客户反馈，单独购买或构建一个 LLM-as-Judge 并不能拯救产品。
1. 抽样检查 AI 输出
在评估和监控 AI 产品时，团队通常需要定期抽样输出，并为样本标注质量和缺陷。
这些标注的用途包括：
了解模型真实表现；
发现自动化规则尚未覆盖的失败；
形成高质量的评测数据；
校准自动化评估器；
了解用户反馈与模型表现之间的关系。
2. 用人工判断校准自动评估器
当拥有足够多、足够高质量的人工标注后，可以用它们来校准 LLM-as-Judge，使自动评估结果尽量贴近人类判断。
具体可以测量：
对二元标签的精确率；
对二元标签的召回率；
模型评分与人工评分之间的相关性；
成对比较中自动评估器是否与人工选择一致。
校准完成后，自动评估器可以负责更大规模的持续监控，但这并不意味着人工监督可以永久退出。
3. 反馈循环仍需要持续运行
团队仍然需要定期：
抽样数据；
标注 AI 输出；
分析用户反馈；
检查自动评估器是否发生偏移；
用新的人工判断更新评估器。
理想情况下，产品还应该通过用户行为捕获隐式反馈。例如用户是否接受了建议、是否重复提问、是否撤销了操作、是否继续完成任务。
显式反馈虽然更加稀少，也可能存在偏差，但仍然很有价值，尤其是用户明确报告错误的场景。
四、自动评估器的边界
自动评估器并不完美，但人工标注者也不完美。
关键不在于寻找一个永远正确的评估器，而在于通过更多、更高质量的数据，不断让自动评估结果与可靠的人类判断对齐。
自动化工具的价值是扩大规模、提高频率、降低重复劳动，而不是替代理解问题的人。
真正重要的是组织纪律：团队是否愿意长期坚持抽样、标注、分析、校准和更新。如果没有这套纪律，评测工具越多，可能只是产生更多看似精确但缺乏实际价值的数字。
五、对 AI 产品团队的实践建议
1. 先观察真实数据
不要先选工具、设计指标或购买平台。先查看用户输入、AI 输出和真实交互，找出影响最大的失败模式。
2. 用失败案例建立评测集
把线上出现的问题转化为可重复运行的测试样本，同时保留成功案例，构造平衡且能代表真实分布的数据集。
3. 把成功标准写清楚
一个评测任务应该能够回答“什么算通过”。如果不同评审者会得到完全不同的判断，说明标准还不够清晰。
4. 先做基线，再做实验
任何 Prompt、模型、检索或工具改动都应与基线比较。没有基线，就很难判断改动带来的影响。
5. 让评测进入开发循环
评测应当在开发过程中持续运行，而不是只在上线前执行一次。每次改动都应当能回答：哪些问题变好了，哪些问题变坏了。
6. 保留人工抽样
即使自动评估器已经稳定，也要定期抽样和复核。真实用户反馈和人工阅读仍然是发现评估器盲区的重要方式。
7. 把评测视为长期能力
评测不是某个工程师临时写的脚本，也不是一次性项目。它需要明确负责人、持续维护、数据更新和跨团队协作。
六、结论
使用 AI 构建产品有时看起来像魔法，但构建可靠的 AI 产品仍然需要大量细致、重复而扎实的工程工作。
如果团队不应用科学方法，不实践评测驱动开发，也不持续监控系统输出，那么再购买或构建一个评测工具，也无法拯救产品。
真正有效的顺序是：
看数据。
找失败。
做标注。
提出假设。
设计实验。
测量结果。
分析错误。
更新系统和评测。
持续循环。
LLM-as-Judge 有用，但它应该是流程中的一个组件，而不是流程本身。
引用
Yan, Ziyou. (Apr 2025). An LLM-as-Judge Won’t Save The Product—Fixing Your Process Will. eugeneyan.com. https://eugeneyan.com/writing/eval-process/