如何让 LLM-as-Judge 更可信？先别让它什么都判

开篇

上一篇文章，我记录了第一次完整实践评测驱动时踩过的一些坑。

其中让我印象最深的一件事是：评测器本身也会犯错。

最近，我开始从头思考评测这个问题。在最开始做 AI 产品时，我会想，人能做的事情，为什么模型不能做？是不是只要我在提示词里考虑到所有评测维度、用最好的模型来判，然后通过 bad case，不断丰富维度、约束词，就可以驱动产品越来越好了呢？

但在不断实践之后，我逐渐发现这样是不行的。🙂‍↔️

还是拿金融 Deep Research 生成报告为例，它至少会包含四种完全不同的问题：

- 系统有没有找到需要的材料？ - 报告里的数字、日期和单位是否正确？ - 报告标注的引用是否真的支持前面的论断？ - 报告的结构、分析深度和风险讨论是否合理？

这四类问题的可验证程度完全不同。

「营收是多少」存在相对明确的标准答案；「某条引用是否包含这个数字」也可以回查证据；但「分析是否有深度」则很难用规则直接判断。

如果把这些问题全部交给 LLM 来输出一个分数，会产生几个问题。

- 一个事实错误可能被看起来良好的结构和语言掩盖。 - 分数的变化无法指导优化。总分下降了一分，到底应该修检索、证据筛选、数字处理，还是写作模型的 prompt？ - Judge 可能本身就会受到报告长度、选项顺序、语言风格甚至模型家族的影响。

所以这样看，单纯用 LLM 判断，最大的问题是它把不同可信度、不同可验证程度的判断混在了一起。

👉 让 LLM 参与评测，但这不等于把最终裁决权交给 LLM。需要先收权，再校准。

「收权」解决：哪些问题不应该由 Judge 判断。

「校准」解决：对于剩下确实需要 Judge 的问题，如何验证它是否值得信任。

可以根据每类问题的可验证程度，把评测拆成不同层级，并给每层的模型授予不同权限。👇

第一层：过程指标完全不需要 LLM

最底层是过程指标。

这一层不判断报告最终写得好不好，只记录系统在研究过程中究竟做了什么，例如：👇

- 搜索和抓取到了多少条证据 - 抓取成功率是多少 - 权威来源占比是多少 - 最终证据来自多少个不同域名 - 总耗时和 Token 消耗是多少 - 某条目标事实是否曾经进入证据池

这些指标都可以从工作流状态中确定性计算，不需要调用模型。

这层最重要的价值不是评分，而是归因。

比如，一份报告漏掉了某个重要数字，这时就可以按照层级顺序一一排查：

- 这个数字有没有进入证据池？ - 它进入了证据池，那在筛选阶段模型有筛选到对应的文章吗？ - 它已经交给写作模型，但最终模型有正确写进报告吗？ - 写作模型写进去了，那是在报告期或者单位上出错了吗？

同一个「报告漏事实」，背后的根因可能完全不同。如果没有这些过程指标，所有问题最后可能都会被归结成是模型效果不好。

所以这一层做到了：

系统到底做了什么，信息从哪一步开始丢失的？

第二层：让 LLM 负责抽取，让程序负责判决

这一层是事实评测，会比过程指标更复杂，因为研究报告是自然语言文本。

例如，源文章的标准事实可能是：

某公司 2025 年营业收入为 3375.32 亿元。

报告里的表达却可能是：

公司全年实现营收约 3375 亿元，较上一年度基本持平。

要判断它是否正确，只靠代码规则就很困难，这时就需要利用 LLM 的自然语言能力从这些文字表述中来识别：

- 指标是什么 - 报告期是什么 - 数值是多少 - 单位是什么

但之后的「这个数字算不算正确」这些最终判决还是要交回给程序：

LLM 从报告中抽取候选事实 ↓ 代码比较数值、单位、报告期和容差 ↓ 得到 Fact Recall / Numeric Accuracy

👉 模型负责把自然语言转成结构化信息，程序负责决定它是否命中标准答案。

这里就是在收窄 LLM 判别的权限：

- 有理解自然语言的权限； - 但没有决定答案是否正确的权限。

第三层：引用核证不是「有引用就算正确」

这层解决的是报告里的数字正确，并不代表对应的引用就正确。

例如：

公司 2025 年净利润增长 20% [3]

这里就需要检查：

- [3] 对应的证据到底是什么 - 证据里有没有这个指标 - 报告期是否一致 - 数值口径是否一致 - 证据是支持、矛盾，还是信息不足

需要先把带引用的实质性论断逐条抽取出来，再和它引用的证据逐一核对。核证结果会被限制在三类：

- supported - unsupported - unverifiable

每条结果都必须保留：

- 被核证的具体论断 - 引用了哪些证据 - 判定结果 - 判定依据

未引用的论断更危险

如果只检查带 [n] 的句子，还有一个明显的盲区：

模型最可能在没有引用的地方凭参数记忆写作。

所以我还会抽取不带引用的实质性事实，并将它们和整个证据池进行比对，统计：

- 有多少实质性论断没有引用 - 这些未引用论断中有多少能被证据池支持

这一层仍然调用了 LLM，但它的权限同样会被限制：

- 只能在给定证据范围内判断 - 只能输出有限的结构化结论 - 每个结论都能回到具体论断和具体证据 - 信息不足时允许输出 unverifiable，而不是强行判断

👉 LLM 不能被允许脱离证据去自由裁决。

第四层：真正主观的部分才交给 Judge

完成事实和引用核证之后，剩下的才是难以程序化的部分，例如：

- 报告结构是否合理 - 分析是否足够深入 - 是否只是复述事实 - 金融分析是否严谨 - 风险和不确定性是否被充分讨论

这些问题很难找到唯一标准答案。在涉及投资建议的问题里，Judge 还会判断：

- 结论是否有报告中的事实支撑 - 是否使用了合理的估值锚 - 是否同时讨论多头和空头因素 - 是否包含必要的风险提示和免责声明

但这里有一个非常重要的边界：

Judge 只评价投资建议的论证质量，不判断买入或者卖出的方向最终是否正确。

方向是否正确，需要未来收益或真实业务反馈，这是离线 Judge 永远做不到的。

对于我现在的离线做法是用手写 Rubric 把主观要求显式化，把抽象要求拆成二值项。例如分析一家银行时，可以检查这些 Rubric：

- 是否解释了营收接近零增长、净利润仍增长的结构性原因 - 是否使用 PB 和股息率作为估值锚，而不是机械套用 PE - 是否讨论净息差下行、资产质量与 ROAE 变化

Judge 对每一项只能回答 pass 或 fail。

仅仅提到关键词、没有实质分析，不算通过；如果 Judge 漏回某项，默认记为失败。最后汇总成 rubric_pass_rate。这样 Bad Case 就可以直接定位到缺失的分析点。

目前每个 case 使用的专属 Rubric 主要来自：

- pairwise 对比中失败报告的裁判理由 - ChatGPT / Gemini Deep Research 覆盖、而当前系统遗漏的分析 - 沿工作流回放得到的 Bad Case - 卖方研究中常见的行业分析框架

当然，手写 Rubric 同样会引入我的主观偏差，但目前它至少是显式、可审计、可以修改和回放的，只适合我目前的实验条件。

从离线 Rubric 到线上反馈

前几天看到淘天技术团队在《让 Agent 可评、可控、可迭代：业务效果导向的评测体系与场景实践》中讨论他们一个真实线上产品的评测问题：营销策略 Agent 的输出没有唯一标准答案，一条离线看起来合理的策略，只有进入真实业务后，才能观察它是否带来了 ROI、GMV 等指标的增量。

文章中提到，线上反馈也不是一个可以直接写进评测集的标准答案。线上会有三个特点：

- 反馈稀缺且延迟 - 多个业务指标之间需要权衡 - 结果还会受到货盘、周期和流量环境影响

所以他们通过 A/B 实验比较模型策略与基准策略带来的相对增量，再把结果组织成偏好对：

chosen = 线上业务效果更好的策略 rejected = 线上业务效果更差的策略

接下来，就是让 LLM 从偏好对中反推「为什么它会赢」：

- 供给：结合偏好对差异和客观数据模式，生成候选 Rubric - 筛选：检查规则方向、位置交换一致性，并通过稳定性选择和交叉验证排除只在当前样本上有效的规则 - 验证：用筛选后的 Rubric 重新判断偏好对，只保留高置信、与业务反馈方向一致的结果

这样，线上反馈提供的就是 Rubric 产生和验证的外部锚点，离线 Judge 可以以此尝试学习哪些可解释规则与真实业务效果存在稳定关系。

我想，这对于我的金融 Deep Research 体系的分工启发是：

- 事实、数字和引用质量继续由前面的确定性评测与证据核证负责 - 用户行为和专家偏好为主观质量提供线上偏好信号 - 线上反馈经过实验与归因后，用来筛选、修正和淘汰离线 Rubric - 离线 Judge 负责低成本回归，线上实验保留最终业务解释权

所以，从离线手写 Rubric 走向线上产品，需要建立这样一个闭环：

离线 Bad Case 产生候选标准，线上反馈提供偏好锚点，验证后的 Rubric 再回到离线评测和版本准入。

最后

总结下来，可信评测的第一步是给 LLM 收权：

- 能由程序确定的，交给程序 - 需要理解自然语言的，让模型抽取、让程序裁决 - 需要核验证据的，把模型限制在给定论断和证据中，并允许它弃权 - 只有真正无法客观验证的部分，才交给 Judge

（但收权也不等于可信。👇

位置随机化、长度监控、多模型投票和参照锚，都只能降低偏见风险。所以，Judge 本身也需要自己的验证集和版本回归，同时测量准确率、一致性与高置信结论的覆盖率；没有把握时允许弃权。）

现在，我会把 LLM-as-Judge 理解为：

一个被严格限制权限、持续接受验证与回归的系统组件，而不是替代人工判断的最终裁判。

它只判断自己有资格判断的部分；并且每一个判断都能够被复核、被归因，也能够被推翻。