别再迷信 LLM 裁判：做 AI 问答评测，为什么必须先知道正确答案？

最近做一个 AI 评测问答测试时，我再次遇到一个很现实的问题：AI 给出的答案语言流畅、结构完整，甚至会主动解释原因，但这并不能证明它答对了。如果我事先不知道正确结果，只跟着它的表达往下看，很容易把“听起来合理”误当成“已经验证”。

这件事让我重新确认了一个看似反直觉的原则：评测 AI 之前，测试人员必须先知道什么叫正确；评测 AI 之后，不能只给一个分数，还要知道这个分数为什么出现。

很多团队已经开始建设 AI 问答评测：整理一批问题，循环调用模型，再让另一个更强的模型担任裁判。这个方向没有错，但只做到这里还不够。被测模型可能答错，裁判模型同样可能误判；最终答案可能有问题，问题也可能更早出在知识文件、切片、索引或检索阶段。

真正可靠的评测，不是一场“两个 AI 互相评价”的对话，而是一条由预期答案、过程证据、确定性规则、LLM 裁判和人工复核共同组成的质量链路。

---

一、不能把 AI 的回答，当成它正确的证据

传统软件测试有一个基本前提：执行用例之前，测试人员知道预期结果。

测试登录功能时，我们不会先点一次按钮，再根据页面出现什么决定什么算正确；测试接口时，也不会看到服务返回 200，就临时把这次响应定义成标准答案。我们会提前写清楚状态码、字段、业务规则和禁止出现的副作用。

到了 AI 问答场景，很多人却不自觉地放弃了这个前提。他们输入一个问题，阅读模型回答，然后凭感觉判断“还不错”“大体正确”或“表达很专业”。问题在于，大模型最擅长的正是生成连贯、有说服力的语言。它可以把错误答案说得比正确答案更完整。

因此，“带着预期问答”不是要求模型复述唯一句式，而是提前定义答案的判定边界：

• 哪些事实必须出现；
• 哪些说法明确错误，不能出现；
• 哪些表达方式虽然不同，但语义上可以接受；
• 答案应当依据哪些知识文件；
• 当资料不足或相互冲突时，模型应该拒答、提示不确定，还是向用户追问；
• 这个问题一旦答错，会造成普通体验问题，还是业务、合规或安全风险。

预期答案可以是一组事实和规则，不必是一段固定文本。我们要限制的是“什么算对”，而不是限制 AI “必须怎么说”。

评测的第一步不是向 AI 提问，而是先把正确答案、可接受边界和失败条件写出来。

---

二、一条合格的评测用例，不应只有问题和答案

最简单的评测集可能只是一个文本文件，每行放一个问题。这能帮助团队批量运行，却不足以判断质量，更无法定位失败原因。

一条可长期复用的问答用例，至少应该包含这些字段：

字段	作用	示例
用例编号	让结果能够追踪和回归	refund-001
用户问题	实际发送给系统的输入	退款期限是多少？
必须包含	回答正确所需的关键事实	7 天；从签收日计算
禁止包含	明确错误或有风险的说法	30 天；无条件退款
预期来源	正确答案应来自哪里	售后服务规则.md
拒答条件	什么时候不应强行回答	当前地区规则缺失
风险等级	决定发布门槛和复核方式	P0 / P1 / P2
评分规则	明确不同分数对应什么表现	0～5 分锚点

这里最容易漏掉的是“预期来源”和“拒答条件”。

如果只保存标准答案，我们只能知道模型最后有没有说对，却不知道它是否真的使用了当前知识库。有时模型会依靠预训练记忆或碰巧猜中；答案表面正确，但知识库一旦更新，它就可能继续输出旧规则。

同样，没有拒答用例的评测集，会悄悄奖励那些“什么都敢回答”的模型。一个在证据不足时明确说不知道的系统，往往比一个每次都给出完整答案的系统更可靠。

评测集应该覆盖哪些问题

第一版不需要追求几百上千条，可以先从 30 条高价值用例开始：

• 10 条直接事实题：答案存在于单一文件；
• 8 条跨文档组合题：需要合并多个来源；
• 5 条无答案题：知识库中不存在答案，应当拒答；
• 4 条冲突题：新旧文件或不同规则之间存在冲突；
• 3 条高风险题：金额、权限、合规、安全等关键结论。

这 30 条用例的价值，不在数量，而在它们能否覆盖系统真正可能翻车的地方。等团队能够稳定解释每一次失败，再逐步从线上反馈、历史缺陷和新需求中扩充评测集。

---

三、0～5 分可以用，但必须把每一分说清楚

让裁判给答案打 0～5 分是一种实用做法，但如果只告诉裁判“0 分最差、5 分最好”，最终得到的只是一个看似精确的主观数字。

同样一个 3 分，可能表示核心答案正确但缺少引用，也可能表示只答对了一半。两种问题的修复方向完全不同。

建议先给总分设置清晰锚点：

分数	判定标准
0	完全错误、答非所问，或编造了会改变关键决策的事实
1	只碰到主题，没有回答核心问题，存在明显误导
2	部分内容正确，但遗漏或弄错至少一个关键事实
3	核心结论正确，但不完整、缺少必要条件或缺乏来源证据
4	事实正确、内容完整、依据基本充分，仅有轻微表达或非关键遗漏
5	完全符合预期，关键事实齐全，来源一致，没有无依据扩展，并正确处理边界

然后把总分拆成可诊断的维度：

• 正确性：核心事实和结论是否正确；
• 完整性：必须回答的关键点是否全部覆盖；
• 证据一致性：回答是否能够被检索到的知识片段支持；
• 边界处理：无答案、冲突和高风险情况下是否正确拒答或提示不确定；
• 表达质量：是否清晰、相关，没有用冗长语言掩盖证据不足。

事实正确性和证据一致性不应被表达质量抵消。一个写得漂亮但关键数字错误的答案，不能因为结构清晰就获得及格分。

对于 P0 用例，最好再设置硬性门槛：只要出现禁止内容、错误金额、越权建议或无依据的合规结论，就直接判定失败，而不是让其他维度的高分把它平均掉。

---

四、为什么“换一个更强模型当裁判”仍然不够

我以前也使用过一个很自然的方法：日常模型负责回答，再用另一个更强的模型做裁判。它确实比逐条人工检查更快，也能处理关键词规则无法覆盖的语义变化。

但“更强”不等于“可靠”，更不等于“可以替代标准答案”。

2026 年 8 月发布的 AgentJudgeBench，专门研究 LLM 裁判在 Agent 工具调用评测中的可靠性。研究构建了 3,808 个基础工作流记录，覆盖 6 种有向无环图结构、3 个难度层级、5 个生成模型和 6 个通用裁判模型。它评估的不只是最终文本，而是工具选择、参数结构、调用顺序和任务覆盖情况。

论文报告了几个值得警惕的结果：

• 随着任务难度提高，裁判与程序化标准答案的一致性持续下降；
• 没有标准答案时，一致性下降速度大约快 1.5 倍；
• 在困难且没有标准答案的任务上，6 个裁判收敛到约 77%～82% 的狭窄区间，扩大模型规模没有突破这个结构性上限；
• 给裁判提供标准答案也不一定总有帮助，GPT-5.4 和 Gemini-2.5-Pro 在论文设置中分别下降 1.5 和 3.9 个百分点，作者将其解释为与过度锚定一致的现象；
• 增加思维链和调整温度几乎没有改善，结构化评分规则最多带来 4.8～6.5 个百分点提升，但效果依赖具体的裁判与生成模型组合。

这项研究测的是工具调用工作流，不是 RAG 问答，不能把它的数字直接搬到知识库项目上。但它揭示的质量风险是相通的：当任务存在依赖关系、部分正确和多种失败路径时，LLM 裁判也会被难度、提示词和参考信息影响。

所以裁判模型应该是评测系统的一层，而不是整个评测系统。

---

五、建立三层裁判，而不是再找一个“更权威的 AI”

一套实用的评测机制，可以把裁判分成三层。

第一层：确定性规则守住事实底线

程序规则适合验证明确、可计算的内容：

• 必须出现或禁止出现的关键词、数字和日期；
• 返回结构是否符合格式；
• 引用的文件是否真实存在；
• 预期文档是否进入检索结果；
• 回答是否包含不允许出现的敏感字段；
• P0 用例的硬性失败条件是否触发。

这些判断不需要 LLM。能够用程序精确验证的内容，交给概率模型只会增加不确定性。

第二层：LLM 裁判处理语义和完整性

LLM 适合判断同义表达、信息覆盖、上下文相关性和拒答是否合理。但必须给它结构化输入：用户问题、预期关键点、禁止内容、预期来源、实际检索片段和模型回答。

裁判输出也应结构化，至少包含各维度得分、命中的证据、扣分理由和置信度。不要只让它返回一个“4 分”。没有理由的分数无法审计，也无法帮助团队修复问题。

第三层：人工复核处理高风险和裁判分歧

以下结果应该进入人工队列：

• P0 用例未满分或触发禁止项；
• 程序规则与 LLM 裁判结论冲突；
• 两个裁判模型的总分相差 2 分及以上；
• 裁判无法引用具体证据；
• 同一配置重复运行时结果明显波动；
• 问题涉及金额、权限、合规、安全或不可逆操作。

人工复核不是评测自动化失败，而是风险分层的一部分。真正低效的是把所有问题都交给人，或者把所有问题都交给 AI。

---

六、原因反推：不能只看答案猜问题出在哪里

给答案打完分，还只是评测的中点。更重要的是根据过程证据定位失败发生在哪一层。

这里有一个常见误区：看到 AI 回答错误，就直接说“知识库里没有相关文件”。这个结论不能只从最终回答推出来。文件可能存在，只是没有被切片；切片可能存在，只是没有被检索；正确片段也可能已经进入上下文，但生成模型仍然没有使用。

建议把失败分成以下几类：

观察到的证据	更可能的问题	优先检查
知识库确实没有预期文件	知识缺口	文档责任人、内容更新流程
文件存在，但索引中没有对应片段	入库问题	格式解析、切片、索引任务
片段已索引，但没有进入 Top-K	检索问题	查询改写、Embedding、过滤和排序
正确片段已进入上下文，回答仍然错误	生成问题	Prompt、上下文组织、模型能力
回答正确，但没有证据支持	猜测或模型记忆	强制引用、无证据拒答、对抗用例
人工认为正确，裁判持续低分	裁判问题	评分锚点、裁判 Prompt、参考答案
相同输入多次得分波动明显	稳定性问题	模型版本、采样参数、上下文变化

要完成这种归因，每次评测至少要保存：

• 用例和预期答案版本；
• 知识库及索引版本；
• 实际检索到的文档、片段、分数和排序；
• 发送给生成模型的完整上下文；
• 模型原始回答和运行参数；
• 程序检查结果；
• LLM 裁判的分项得分、理由和证据；
• 人工复核结论与最终原因分类。

如果没有这些记录，团队只能不断修改 Prompt 或更换模型，却不知道改动是否触及真正原因。

---

七、一个低成本、可以马上执行的评测实验

不需要先购买复杂评测平台。使用前面的 30 条用例，就能搭建第一版可复现试验。

第一步：固定基线

固定生成模型、系统 Prompt、知识库快照、切片规则、Embedding、Top-K 和采样参数。任何一项发生变化，都记录为新的评测版本。

第二步：每条用例运行三次

AI 输出存在随机性。单次通过不能证明稳定，单次失败也可能是偶然波动。每条用例重复三次，分别保存回答、检索结果和评分。

第三步：同时运行三种判定

• 程序规则检查必须点、禁止点和预期来源；
• LLM 裁判按 0～5 分维度评分；
• 人工抽查全部 P0、全部裁判冲突结果，以及不少于普通用例的 20%。

第四步：比较的不只是平均分

至少观察这些指标：

指标	回答的问题
P0 通过率	高风险问题是否全部守住底线
关键事实正确率	必须回答的内容有多少真正正确
无依据回答率	有多少结论无法被检索证据支持
正确拒答率	没有答案时是否能够承认不知道
检索命中率	预期来源是否进入 Top-K
裁判—人工一致率	自动评分是否足以参与发布门禁
重复运行稳定率	同一配置是否持续给出相近结果

第五步：提前定义停止条件

以下门槛可以作为第一版试点规则，再根据业务风险调整：

• 任一 P0 用例出现错误关键事实，阻断发布；
• 裁判与人工在关键事实判断上的分歧超过 10%，暂停自动门禁并修订评分规则；
• 同一用例三次运行的总分极差达到 2 分，进入稳定性排查；
• 正确文档未进入 Top-K 时，不通过修改生成 Prompt 掩盖检索问题；
• 评测集或预期答案没有版本记录时，不比较两个模型的分数；
• 无法保存检索和裁判证据时，只能报告结果未完成归因，不能宣称系统已经通过验证。

这些停止条件不是行业统一标准，而是一组可操作的试点门槛。团队应根据错误成本、样本数量和人工审核能力重新校准。

---

八、落地时最容易踩的五个坑

1. 把标准答案写成唯一文案

这样会惩罚合理的同义表达，把评测变成文本相似度比赛。标准答案应拆成事实、条件、禁止项和来源。

2. 用同一个总分掩盖关键错误

表达清晰不能抵消数字错误，内容完整不能抵消无依据结论。P0 事实必须设置硬失败条件。

3. 只保存答案，不保存检索过程

没有检索片段和排序，就无法区分知识缺口、召回失败和生成失败，最终所有问题都会被错误归因给 Prompt。

4. 认为更大的裁判模型一定更准

模型规模、思维链和低温度都不是可靠性保证。评分结构、标准答案质量和人工校准更重要。

5. 只挑模型容易回答的问题

如果评测集没有无答案、冲突、跨文档和高风险问题，分数再高也只能说明系统会回答简单题。

---

九、证据边界：论文结论不能直接替代你的实验

AgentJudgeBench 给出了重要警示，但使用它时必须保留边界。

首先，它研究的是 Agent 工具调用工作流，不是企业 RAG 问答；本文把它用于说明“LLM 裁判同样需要验证”，属于质量工程层面的迁移，不代表论文已经证明某个问答系统会得到相同数字。

其次，论文的 3,808 个基础记录是合成数据，而不是从真实企业执行轨迹中直接采集。合成方法让研究者能够得到程序化标准答案、控制工作流结构和难度，但真实业务中的模糊需求、动态工具返回和多轮交互可能更加复杂。

论文使用程序化评分器作为大规模参考信号，并用 120 条记录的单人标注研究进行验证。其中参数结构指标的人机一致率低于其他指标，说明“多余但 schema 合法的参数是否算错”本身也包含规则选择。

此外，论文发现结构化评分 Prompt 的优势没有在所有裁判—生成模型组合上稳定复现；部分困难用例中甚至出现反转。因此，我们可以借用它的评测思路，不能把某个提示模板或某个裁判模型写成普遍最佳方案。

真正适用于你项目的结论，仍然要来自自己的评测集、知识库、风险分层和人工校准。

---

十、测试工程师可以直接使用的检查清单

评测前

• [ ] 每个问题都有必须点、禁止点、预期来源和拒答条件
• [ ] P0 / P1 / P2 风险等级已经标注
• [ ] 评测集、知识库、索引和 Prompt 都有版本
• [ ] 标准答案描述的是事实边界，而不是唯一句式

评测中

• [ ] 保存了检索片段、排序、完整上下文和原始回答
• [ ] 确定性规则与 LLM 裁判分别运行
• [ ] 裁判输出包含分项得分、理由和证据
• [ ] 高风险、低置信度和裁判冲突结果进入人工复核

评测后

• [ ] 每个失败都归类为知识、入库、检索、生成、裁判或稳定性问题
• [ ] 没有用平均分掩盖 P0 错误
• [ ] 修改后使用同一评测集完成回归
• [ ] 报告中明确写出未验证项、剩余风险和停止条件

---

写在最后

AI 问答评测真正困难的地方，不是把几十个问题循环发送给模型，也不是再调用一个更强模型给答案打分。

困难的是在提问之前定义“正确”，在打分之后解释“为什么”，并且让每一个结论都能回到知识文件、检索片段、评分规则和人工证据上。

AI 可以参与回答，也可以参与评分，但不能让它同时定义正确答案、决定评分标准，再为自己的结论提供证明。

一套可靠的评测机制，应该形成这样的闭环：定义预期 → 建立评测集 → 批量问答 → 分层裁判 → 记录过程证据 → 定位原因 → 修改系统 → 重新回归。

当这个闭环建立起来，AI 评测才不再是“我觉得它回答得还不错”，而是可以被重复、解释和审计的质量工程。

---

参考资料

• AgentJudgeBench：A Multi-Difficulty Benchmark for Evaluating LLM Judges on Agentic Tool-Calling
• AgentJudgeBench HTML 全文
• RSS 试运行日报 Issue #19

说明：本文中的问答评测框架、评分锚点、原因分类、试点门槛和检查清单，是结合实际 AI 问答测试经验与论文证据形成的质量工程方案，需要根据具体业务风险继续校准。