人类评审 vs 自动评估：谁来给AI Agent打分？

AI Agent 的评估是每个团队迟早要面对的难题。原型跑通之后，总有人会问：这些输出谁来检查？很多团队寄希望于 AI 自己搞定，但现实往往恰恰相反——省掉这一步的团队，最终都交付了一个没人能担保的 Agent。

本文结合 Netflix、Rhesis 等团队的生产实践，把人类专家评估与自动化评估放在一起对比，分析它们各自的强项与断裂点，并给出一个可落地的混合评估闭环。

人类评估：领域知识是自动化无法替代的

上下文只存在于你的组织内部。 类似 helpfulness、toxicity、faithfulness 这样的通用指标，很难判断你的旅行 Agent 是否搞对了你的票价规则。比如它告诉用户起飞前 24 小时可以免费取消，而实际政策是 48 小时——回答流畅、礼貌、有票价文档支撑，但它是错的。只有运营团队的人才知道。

专家发现问题的速度极快。 把十份对话记录交给客服运营的同事，他们几秒内就能找出那条用了上一季行李额度的记录。Hamel Husain 建议指定一位主领域专家作为唯一真相来源，对每条输出做二元的 pass/fail 判定，并附上书面评语。评语和判定同样重要，因为它就是后续转化为指标的原材料。

评估标准来自翻阅输出，而非凭空想象。 Shankar 等人把这种现象称为标准漂移（criteria drift）：人们往往是在打分过程中才逐渐理清自己的标准，随着看到更多输出不断修正。在任何人读过对话记录之前写出的评分细则，只是第一版猜测。

**断裂点：**专家慢、贵、忙。让他们手工编写 200 个测试用例不现实，每次改 prompt 都重读一遍所有对话更是天方夜谭。

Ye Yuan 在构建跨旅行、医疗、教育、法律服务等多个领域的客服机器人时正好撞上了这堵墙。通用 NLP 指标无法捕捉多轮对话质量，团队只能自建评分标准，并以最佳人工销售和支持对话作为基准。第一个瓶颈就是标注产能：训练和校准标注员既慢又贵，金标数据集始终太小。

什么是 helpfulness、toxicity、faithfulness？ 这三个指标是当前 LLM 评估中最常见的通用维度。helpfulness（有用性）衡量回答是否真正解决了用户的问题，而非只是形式完整；toxicity（毒性）检测输出中是否包含冒犯、歧视或有害内容；faithfulness（忠实度）则针对 RAG 类系统，考察回答是否严格依据检索到的上下文，而非模型自行编造。它们的共同局限在于：都是领域无关的，因此对“票价规则写错 24 小时”这类业务事实错误几乎无能为力。

自动化评估：规模与对抗性测试的利器

无需任何前置信息即可探索 Agent。 把自动化测试器指向一个接口，它就能探测领域、摸清 Agent 的能力边界、找到它在哪些地方拒绝或转接。不需要需求文档。

大规模运行对抗性测试。 越狱、提示注入、多轮施压都需要规模和变化量。手工覆盖 OWASP LLM Top 10 及 Agent 应用安全清单并不现实，而生成并执行这些攻击恰恰是自动化的主场。

交接后持续核查需求。 每次运行、每次换模型、每次改 prompt，都在 CI 里跑一遍。人类审查者在第 40 段对话时已经疲惫，而指标不会。

**断裂点：**细节才是魔鬼。LLM 评审倾向于宽松，对部分正确的答案处理不佳，而且对评审 prompt 的措辞非常敏感（Thakur 等人，《Judging the Judges》）。它们会漏掉专家一眼就能抓住的细小错误——24 小时 vs 48 小时。更隐蔽的是，一致率会掩盖问题：如果只有 5% 的输出失败，一个全部判通过的评审器与专家的"一致率"高达 95%，却一个失败都没抓到。

Ye Yuan 在生产中也看到了同样的问题：LLM 评审在语用、隐含意义和用户沉默不语等场景下表现吃力，不同运行之间的分数波动明显。合成测试对话也丢失了真实用户流量中的模糊性以及情绪和话题切换。

LLM-as-a-Judge 与一致率的陷阱。 用一个大模型去评判另一个模型的输出，被称为 LLM-as-a-Judge，是自动化评估的主流范式。它便宜、可批量运行，但存在已知偏差：倾向给长回答和高分、对措辞敏感、难以处理“部分正确”。Thakur 等人提出的“一致率悖论”尤其值得警惕——假设真实失败率只有 5%，一个永远判通过的评审器与专家的一致率仍有 95%，但它的召回率为零。因此评估评审器时必须同时看 precision、recall 和混淆矩阵，而不能只看一致率。

两者如何互补

专家的强项是识别问题，弱项是产出规模；自动化恰好相反。所以真正有用的问题不是"选哪个"，而是"哪部分工作交给谁"。

专家的角色从撰写测试用例转向审阅和纠正判定。审阅一个 pass/fail 并附一句话说明只需几秒；从零写一个好的测试用例需要几分钟，写 200 个根本不现实。

Ye Yuan 的团队最终落在一个类似的循环上：规模化自动评估、人工抽检、对每个低分对话进行人工复核、把失败模式反馈到下一轮迭代。具体运作如下：

1. 自动化探索 Agent 并生成第一版测试集
2. 专家抽样审阅，给出 pass/fail 加评论
3. 专家与评审器产生分歧的案例用来校准指标
4. 校准后的指标在每次变更时自动运行
5. 专家只看冲突和新出现的失败类型

需要的人工投入比想象中少。Anthropic 建议从 20 到 50 个来自真实失败的任务开始。Hamel Husain 从约 30 个样例起步，持续扩充直到不再出现新的失败模式，然后每个失败模式积累约 100 条标注样例来校验评审器。Netflix 每周持续新增约 300 条评分，因为线上流量一直在变。这是几小时的专家时间，不是一个季度的投入。

实战闭环：自动化跑测试，专家做决断

在 Rhesis 的演示中，我把工具指向一个没有任何需求文档的旅行 Agent，让它自行探索并测试，然后以领域专家的身份审阅结果。

1. Architect 探索接口。 在快速或全面模式下，它从零开始探测领域、梳理能力边界、找出 Agent 在哪些地方拒绝或转接。
2. Architect 规划并运行测试套件。 根据探索结果，它提出需求、指标和测试集建议，等待批准后才创建任何内容。我自己补了一条需求：取消条款必须与票价规则一致。运行中取消测试通过了。
3. 专家审阅结果。 标注（Annotation）可以挂在整条测试结果、单个指标或对话的某一轮上，每条带 pass/fail 和评论。我把取消指标判为失败，并写明理由：票价规则写的是 48 小时。
4. 人类判定优先。 专家的判定现在计为最终结果，自动判定保留在记录中，Rhesis 把这种分歧标记为状态冲突，让团队看到评审器和专家在哪里分道扬镳。当两者一致时，结果会显示"Confirmed by"加上审阅人姓名，久而久之你能看出哪些指标值得信赖、哪些还需要打磨。

所有标注汇集在 Improve 下的 Annotations hub 中，可以按冲突筛选，修复那些持续出错的指标。工程师也可以通过 SDK 和 MCP 读写标注，让专家判定和 CI 结果落在同一个地方。

状态冲突（status conflict）为什么重要。 在混合评估闭环中，专家判定与自动判定不一致的样本信息量最大。它们要么暴露评审器遗漏了业务规则（如 48 小时取消条款），要么说明专家的标准尚未被清晰表达。Rhesis 把这类分歧显式标记为状态冲突，并汇集到 Annotations hub 按冲突筛选，本质上是在用“分歧”作为校准信号主动挖掘指标缺陷。长期跟踪冲突率的变化，还能判断某个指标是否已经足够可信、可以放权给自动化独立执行。

让专家做判断，让自动化做规模

两种方法单独都不够用。没有专家输入的自动评估会放过那些流畅但业务上错误的回答；没有自动化的人类评审只能覆盖几十段对话就停下来了。把专家放在需要判断力的位置，让自动化承担探索、攻击和重复核查的工作。

这套逻辑在 Netflix、Anthropic 和 Ye Yuan 团队的生产实践中得到了交叉验证：评估系统的核心不是"人还是机器"的二选一，而是把人类判断力当作校准自动指标的锚点，再用自动化把校准结果放大到生产规模。