# 如何让 LLM-as-Judge 更可信？先别让它什么都判 > 作者：晨旭｜发布：2026-09-21｜系列：入门系列文章 > 来源：https://chenxu.xin/writing/llm-as-judge-limited-authority > 首发：首发于公众号，原文 https://mp.weixin.qq.com/s/To7qw4U_hSEZsghVgjxLdg；此页为作者本人维护的存档 把所有评测维度塞进一个 prompt、让最强的模型打一个总分，这条路走不通。按可验证程度把评测拆成四层，给每层的模型授予不同权限：先收权，再校准。 --- ## 开篇 [上一篇文章](/writing/eval-driven-deep-research)，我记录了第一次完整实践评测驱动时踩过的一些坑。 其中让我印象最深的一件事是：评测器本身也会犯错。 最近，我开始从头思考评测这个问题。在最开始做 AI 产品时，我会想，人能做的事情，为什么模型不能做？是不是只要我在提示词里考虑到所有评测维度、用最好的模型来判，然后通过 bad case，不断丰富维度、约束词，就可以驱动产品越来越好了呢？ 但在不断实践之后，我逐渐发现这样是不行的。🙂‍↔️ 还是拿金融 Deep Research 生成报告为例，它至少会包含四种完全不同的问题： - 系统有没有找到需要的材料？ - 报告里的数字、日期和单位是否正确？ - 报告标注的引用是否真的支持前面的论断？ - 报告的结构、分析深度和风险讨论是否合理？ 这四类问题的可验证程度完全不同。 「营收是多少」存在相对明确的标准答案；「某条引用是否包含这个数字」也可以回查证据；但「分析是否有深度」则很难用规则直接判断。 如果把这些问题全部交给 LLM 来输出一个分数，会产生几个问题。 - 一个事实错误可能被看起来良好的结构和语言掩盖。 - 分数的变化无法指导优化。总分下降了一分，到底应该修检索、证据筛选、数字处理，还是写作模型的 prompt？ - Judge 可能本身就会受到报告长度、选项顺序、语言风格甚至模型家族的影响。 所以这样看，单纯用 LLM 判断，最大的问题是它把不同可信度、不同可验证程度的判断混在了一起。 👉 让 LLM 参与评测，但这不等于把最终裁决权交给 LLM。需要先收权，再校准。 「收权」解决：哪些问题不应该由 Judge 判断。 「校准」解决：对于剩下确实需要 Judge 的问题，如何验证它是否值得信任。 可以根据每类问题的可验证程度，把评测拆成不同层级，并给每层的模型授予不同权限。👇 ## 第一层：过程指标完全不需要 LLM 最底层是过程指标。 这一层不判断报告最终写得好不好，只记录系统在研究过程中究竟做了什么，例如：👇 - 搜索和抓取到了多少条证据 - 抓取成功率是多少 - 权威来源占比是多少 - 最终证据来自多少个不同域名 - 总耗时和 Token 消耗是多少 - 某条目标事实是否曾经进入证据池 这些指标都可以从工作流状态中确定性计算，不需要调用模型。 这层最重要的价值不是评分，而是归因。 比如，一份报告漏掉了某个重要数字，这时就可以按照层级顺序一一排查： - 这个数字有没有进入证据池？ - 它进入了证据池，那在筛选阶段模型有筛选到对应的文章吗？ - 它已经交给写作模型，但最终模型有正确写进报告吗？ - 写作模型写进去了，那是在报告期或者单位上出错了吗？ 同一个「报告漏事实」，背后的根因可能完全不同。如果没有这些过程指标，所有问题最后可能都会被归结成是模型效果不好。 所以这一层做到了： **系统到底做了什么，信息从哪一步开始丢失的？** ## 第二层：让 LLM 负责抽取，让程序负责判决 这一层是事实评测，会比过程指标更复杂，因为研究报告是自然语言文本。 例如，源文章的标准事实可能是： > 某公司 2025 年营业收入为 3375.32 亿元。 报告里的表达却可能是： > 公司全年实现营收约 3375 亿元，较上一年度基本持平。 要判断它是否正确，只靠代码规则就很困难，这时就需要利用 LLM 的自然语言能力从这些文字表述中来识别： - 指标是什么 - 报告期是什么 - 数值是多少 - 单位是什么 但之后的「这个数字算不算正确」这些最终判决还是要交回给程序： ```text 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 实验比较模型策略与基准策略带来的相对增量，再把结果组织成偏好对： ```text chosen = 线上业务效果更好的策略 rejected = 线上业务效果更差的策略 ``` 接下来，就是让 LLM 从偏好对中反推「为什么它会赢」： - **供给**：结合偏好对差异和客观数据模式，生成候选 Rubric - **筛选**：检查规则方向、位置交换一致性，并通过稳定性选择和交叉验证排除只在当前样本上有效的规则 - **验证**：用筛选后的 Rubric 重新判断偏好对，只保留高置信、与业务反馈方向一致的结果 这样，线上反馈提供的就是 Rubric 产生和验证的外部锚点，离线 Judge 可以以此尝试学习哪些可解释规则与真实业务效果存在稳定关系。 我想，这对于我的金融 Deep Research 体系的分工启发是： - 事实、数字和引用质量继续由前面的确定性评测与证据核证负责 - 用户行为和专家偏好为主观质量提供线上偏好信号 - 线上反馈经过实验与归因后，用来筛选、修正和淘汰离线 Rubric - 离线 Judge 负责低成本回归，线上实验保留最终业务解释权 所以，从离线手写 Rubric 走向线上产品，需要建立这样一个闭环： 离线 Bad Case 产生候选标准，线上反馈提供偏好锚点，验证后的 Rubric 再回到离线评测和版本准入。 ## 最后 总结下来，可信评测的第一步是给 LLM 收权： - 能由程序确定的，交给程序 - 需要理解自然语言的，让模型抽取、让程序裁决 - 需要核验证据的，把模型限制在给定论断和证据中，并允许它弃权 - 只有真正无法客观验证的部分，才交给 Judge （但收权也不等于可信。👇 位置随机化、长度监控、多模型投票和参照锚，都只能降低偏见风险。所以，Judge 本身也需要自己的验证集和版本回归，同时测量准确率、一致性与高置信结论的覆盖率；没有把握时允许弃权。） 现在，我会把 LLM-as-Judge 理解为： 一个被严格限制权限、持续接受验证与回归的系统组件，而不是替代人工判断的最终裁判。 它只判断自己有资格判断的部分；并且每一个判断都能够被复核、被归因，也能够被推翻。 ## 核心结论 - 让 LLM 参与评测，不等于把最终裁决权交给 LLM。可信评测的第一步是收权：能由程序确定的交给程序，需要理解自然语言的让模型抽取、让程序裁决，只有真正无法客观验证的部分才交给 Judge。（判断 · 把握较大） 永久链接：https://chenxu.xin/writing/llm-as-judge-limited-authority#judge-needs-scoped-authority - 把可验证程度完全不同的问题混成一个总分，一个事实错误会被良好的结构和语言掩盖，而且分数的变化无法指导优化——总分掉一分，不知道该修检索、证据筛选、数字处理还是写作 prompt。（判断 · 把握较大） 永久链接：https://chenxu.xin/writing/llm-as-judge-limited-authority#single-score-hides-errors - 事实评测的正确分工是：模型把自然语言抽成结构化信息，程序比对数值、单位、报告期和容差后做出判决。模型有理解语言的权限，没有决定答案是否正确的权限。（判断 · 把握较大） 永久链接：https://chenxu.xin/writing/llm-as-judge-limited-authority#extract-with-llm-judge-with-code - 过程指标最重要的价值不是评分而是归因。没有它，「报告漏了一个事实」这类问题最后都会被笼统归结成模型效果不好，而根因可能在检索、筛选或写作的任意一环。（判断 · 把握较大） 永久链接：https://chenxu.xin/writing/llm-as-judge-limited-authority#process-metrics-are-for-attribution - 离线 Judge 只能评价投资建议的论证质量，判断不了买入或卖出的方向最终是否正确——方向需要未来收益或真实业务反馈才能验证。（把握较大） 永久链接：https://chenxu.xin/writing/llm-as-judge-limited-authority#offline-judge-cannot-judge-direction --- 本文出自晨光里的AI（https://chenxu.xin），作者晨旭。 引用时请保留来源链接。文中标注「判断」「假设」的部分是作者的个人看法，不是事实。