AI 审查同一 PR 给出不同结论：确定性判定器来解决

上周我写过，AI 审阅者只报准确率而不报召回率，结果只能算一半；五个 AI 审阅者漏掉了同一个 bug，本质上只是一个模型被测了五次。这两篇文章的核心线索是一样的：评判者（judge）是最薄弱的环节，而且它是随机的（stochastic）。

这个问题的修复方案一直在逐步浮现，本周的一个发布让它变得切实可行。让我来拆解一下：为什么一个在不同运行中给出不同答案的评判者，比一个只是答错的评判者更糟糕，以及 decision-model 方案到底改变了什么。

随机评判者的问题

把同一个 PR 过一遍 LLM 审阅者两次，可能得到两个完全不同的结论。这不是理论推演，而是实测数据。LangChain 拿了一条固定的天气 agent 执行轨迹，在多个评判者上各重放一百次，然后把每个评判者的分数与人工标注进行对比。以人工标注为基准的二值通过/不通过准确率，测试的 decision model 是 100%，但其中一个 chat-model 评判者在 500 次重复判定中只有 80%。

对代码审查质量而言，最关键的数字是精确率（precision）：当 agent 行为没有变化时，评判者给出的分数是否一致。LangChain 在同一条轨迹上测量了逐案例方差，发现 chat-model 评判者的分数方差分别是 decision model 的 433 倍、913 倍和 92 倍。

为什么这比答错更伤？一个始终答错的评判者至少是可预测的。你摸清了它的偏差，加以校准，不再信任那个数字就好了。但一个在相同输入下在"阻塞"和"通过"之间反复横跳的评判者更糟糕，因为噪声淹没了信号。当审阅者这周标记了一个 PR，上周一个完全相同的 PR 却一声不吭，你无法判断是代码真的退化了，还是评判者只是飘移了。每一个下游决策——保留哪个 PR、拦截哪个 agent 运行——都继承了那份随机性。一个不稳定的 oracle 不是审阅者，而是一枚带 token 预算的硬币。

改变成本故事的产物

让这件事变得可操作的项目是 jevals，一个基于 TypeSafe AI 的 Jev 构建的评估与护栏库。Jev 是一个"System One"模型，不生成文本。它不是写一段推理再加一个 JSON 字段，而是你把状态加上类型化问题发过去——一个选择、一个评分量规（rubric score）、一个是/否密度——然后它在一次并行前向传播中返回校准后的概率。问四十个问题和问一个问题的延迟几乎相同。

他们的 quickstart 展示了具体的成本差异。针对一条轨迹跑八项评估，一次 HTTP 请求，1,388 个 token，$0.00006，0.33 秒。对比 LLM 评判者，光是一个"答案相关性"指标就已经需要多个往返。在那个价格下，你不再采样 1% 的轨迹，而是开始跑整条管道。

更大的变革是结构性的。因为评估定义一次编写、只依赖轨迹，同一个类可以作为离线指标、生产监控、以及 agent 循环内部的一个 gate 来运行。在生产中拦截有害 agent 行为的 gate，与你在离线测量的东西完全一致。这就堵上了一个我反复遇到的缺口：团队每晚对一小部分流量做评估，但结果从未进入请求路径。jevals 让评判者足够便宜、足够确定性，足以嵌入到行内运行。

还有一条开放权重的路径。在发布后一周内，使用相同有线格式的模型就出现了——Kev 可以跑在 32GB 的 Mac 上，Laya 是一个 ModernBERT 变体，能在 Apple Silicon 上进程内运行。同样的评估定义，改一个后端标志加一次重新校准，就能切换过去。所以这个模式并不锁死在某一个托管服务商上。

保持你的怀疑精神

我喜欢这个方向，但我不是来给你们推销的。有三件事让我不会把它当成已经解决。

第一，样本量太小了。LangChain 的测试只是五个玩具级的天气 agent 轨迹。一个在几条trivial请求上表现良好的评判者，对它在真实代码库或混乱的 agent 会话中的表现说明不了什么。方差数字方向上有参考价值，但不是定论。

第二，来源有倾向性。LangChain 在自己的博客上发布了对比结果，而且几天后他们还计划和 TypeSafe AI 做一场直播合作。自己发布的、倾向自己的供应商数字，是你最应该带着最大怀疑去读的那类结果。发现是合理的，方法也是合理的，但这不是独立复现。

第三，核实我一直强调的核心主张：低方差不等于准确。确定性的评判者可以始终、一致地答错。LangChain 确实检查了与人工标注的一致性，这是对的直觉。但 decision model 消除的是评判者的随机性，不是评判者的偏差。如果 Jev 有盲点——一个它从来不拦截的授权 bug，一个它总是放行的 prompt 注入类型——那它现在就会在每条轨迹上以同样的方式持续失败。这比一个不稳定的评判者更利于调试，但这也意味着一个有偏差的模型可以悄无声息地在规模上为坏代码背书，每次都是。解决这个问题的办法仍然是独立验证：跨模型检查，以及对你关心的特定失败类型加上基于规则的重点关注。

还有一个实际注意点藏在 README 里，团队容易错过。不同后端的概率刻度是不对齐的，所以如果你从 Jev 切换到本地开放权重的 Kev 或基于 ModernBERT 的 Laya，就要重新跑校准。同样的评估定义，不同的概率量程。这件事很容易被忘掉，直到你在基础设施变更后 gate 开始误触发。

结论

如果你在审阅 AI 生成的代码，而你的工具只报一个准确率数字，问它要精确率——相同运行之间的分数方差。一个你无法复现的审阅者，是每一个下游决策里的噪声。如果你自己在做评估，decision-model 模式值得一看，因为 LLM 在不同运行中改变主意时，就是一个糟糕的测试套件。

如果你在为不断增长的 AI 代码量挑选审阅工具，把"哪个评判者来承担重任"作为一等选择标准，而不是脚注。每一个我见过的团队，在尝试依据审阅输出做决策时，确定性的、随处可运行的评分者都胜过随机性的评分者。值得你花时间的工具，是那些能让你复现判决结果的工具。当你无法重跑同一条轨迹并得到完全相同的答案时，你不是在审阅，你是在赌博。

Kodus 的审阅者拆成了多个独立的、角色限定的 agent，而不是一个模型给自己的输出打分——这样就把运动员和裁判分开了。在你选择任何审阅框架时，这种分离同样重要。但原则本身站得住：评判者的确定性和评判者的独立性，共同构成了一个可信的 AI 审阅者，而这两者都不会从一个单一的随机模型中免费获得。

---