用 Jev 构建验证器：Generator–Verifier 性能提升设计

为什么把 Jev 放在验证器位置

本文是 Generator–Verifier 系列的第 2 篇。第 1 篇提到，生成器给出多个候选、由验证器从中选出一个，就能在不更换生成器的情况下提升性能。同时也看到，推理时计算越多，验证器就越会成为瓶颈。本篇尝试设计：在这个验证位置上用 TypeSafe AI 的决策模型 Jev 代替 LLM 时，如何提升性能。

TypeSafe 官方文档（w1）是这样说明的：LLM 的设计目标是生成供人阅读的文本，因此让它做供代码使用的判定时，需要把文本再解析为结构化值，造成错位。Jev 不生成文本，而是直接返回类型确定的值和概率分布。问题类型有三种：Choice 从列表中选一个（choice·probabilities·confidence），Score 按评分细则（rubric）打分（score·probabilities·confidence），Noul 以 0~1 的值回答某个陈述是否为真。LLM-as-Jev 研究（paper）也把这三种形式分别归纳为选择、二元验证和有序评分，并指出 Jev 的权重和训练方法未公开。根据 JEVal 研究（paper），Jev 只能通过托管 API 使用。

本文区分两类陈述。以“依据：”开头的内容是论文或官方文档中的事实。以“设计建议：”开头的内容是笔者从这些依据推导出的建议，并非经过验证的结果。TypeSafe 自行公布的速度和价格数据，会另外注明是由提供方自行测量的。

核心思路：快速初筛，慢速复审

想想机场安检就容易理解了。所有行李都快速通过 X 光判读机，只有判读不清的行李才由人工开包检查。Jev 扮演判读机的角色：以低成本附加在所有候选上，给出分数和置信度。开包式的精细检查则交给强大的 LLM 验证器或人工。

依据：有一项研究（paper）讨论了受 Jev 启发的仅预填充（prefill-only）决策模型。仅预填充是指只读取一次输入，不进行逐字续写的解码。该研究指出，这类模型一次前向传播就能为所有选项打分，因此单次调用比同等规模的生成式语言模型便宜 1~2 个数量级。TypeSafe 官方文档（w1）也说明，针对同一状态的多个问题会一次性并行、相互独立地评估，因此增加问题数量几乎不会增加响应时间。另一端的生成式验证器 GenRM（paper）以生成文本的方式给出判定，因此可以使用 CoT（Chain-of-Thought，逐步推理）和多数投票，在 Best-of-N 中把 GSM8K 准确率从 73% 提高到 93.4%。代价是，正如第 1 篇所见，每次验证的成本很高。

设计建议：不让两种验证器相互竞争，而是分层叠加。Jev 作为查看所有候选的第一阶段验证器，生成式验证器只在 Jev 认为模棱两可的案例上调用。依据：在仅预填充研究（paper）的实验中，同等成本下，基于置信度的级联优于任何向同一模型再次提问的方式。这表明这种分层结构并非不切实际，但要记住，这是在该研究的任务和模型下得出的结果。

工作原理：重排序·步骤检查·路由

① Best-of-N 重排序。设计建议：LLM 生成 N 个候选后，把每个候选以“问题+候选”的状态输入 Jev Score，获得评分细则分数和概率分布。然后按期望分数或最高等级的概率对候选排序。依据：TypeSafe 官方文档（w1）建议每个问题只问一件范围窄、明确的事。需要权衡多个要素的问题应按要素拆开提问，再在代码中合并结果。照此做法，与其只问“这个答案好不好”，不如分别问“是否遵守了要求的格式”“是否涵盖了问题的全部条件”“依据与结论是否吻合”，再用代码确定加权和。优先级改变时，无需重写提示词，只需修改系数。

② 步骤·条件检查。设计建议：把解题过程或执行计划的每一步改写成“第 3 步的计算正确承接了第 2 步的结果”这样的陈述，输入 Noul，获得为真的概率。这相当于不经训练、用提问来模拟第 1 篇中过程奖励（PRM）的作用。依据：LLM-as-Jev 研究（paper）说明，这类模型用于“验证证据是否满足规则”的决策。根据 JEVal 研究（paper），当判断依据包含在输入中时，决策模型具有竞争力；而在医学、金融、法律等需要专业知识的领域则表现落后。因此，构造 Noul 陈述时，要让判断所需的事实一并放进输入。

③ 置信度路由。设计建议：置信度高则直接放行，中等则交给强 LLM 验证器，仍然模棱两可则交给人工。人工判定过的案例再收集为评估集。依据：TypeSafe 主页（w2）建议由用户设定阈值，决定何时自动执行、何时请求审核。在 System Switch 研究（paper）中，置信度最低的 30% 决策被交给推理模型。此时，相较随机移交的提升幅度与第一阶段模型的 AUROC 成正比（秩相关 0.87）。AUROC 是反映置信度区分正确与错误答案能力的指标。这意味着路由的效果取决于这种“区分能力”，而不是准确率。

计算成本与延迟

设计建议：总成本大致按“生成 N 次 + 验证调用 + （上送比例 × 强验证器成本） + 人工审核成本”计算。若用 Score 分别为 N 个候选打分，由于每个候选的状态不同，验证调用也要 N 次。不过，TypeSafe 官方文档（w1）说明，即使对每个候选提出多个问题，针对同一状态的问题也可以合并为一次调用。若把所有候选放进同一个状态，用 Choice 选出一个，调用可减少到一次，但需要同时权衡后文将讨论的选项标签风险。通常，成本的大部分来自生成器的 N 次生成，真正左右预算的变量是上送比例。

依据（提供方自行测量）：TypeSafe 主页（w2）称，以 System One 任务工作流为基准，Jev 比 LLM 快 193.6 倍、便宜 444.6 倍。示例中，Jev 为 0.114 秒、0.000081 美元，LLM 为 8.566 秒、0.013880 美元。价格为每 10 亿输入 token 42 美元，并称其输入价格比 Claude Fable 5.1 低 238 倍。这些都是在提供方所选条件下得出的数字。独立研究方面的依据有：前述仅预填充研究（paper）报告的 1～2 个数量级差距，以及 JEVal 研究（paper）报告的 InnerJev-27B 对一般查询约 0.1 秒即可作答。

延迟要看尾部而非平均值。依据：JEVal 研究（paper）在 τ-bench 上让 Jev 选择下一步行动。结果回合时间的中位数缩短了，但任务成功率下降，尾部延迟增加。设计建议：使用路由时只有模糊案例会变慢，因此应分别记录中位数和高分位延迟，并把上送比例作为预算变量来管理。

N 也没有必要取得很大。依据：关于重采样局限的研究（paper）报告，验证器存在假阳性时，最优尝试次数往往小于 10。也就是说，假阳性的损失超过了收益，推理扩展曲线向下弯折。

校准确认与阈值设定

校准（calibration）是指模型称有 80% 把握的判定，实际正确率也在 80% 左右的状态。现有依据并不指向同一方向。在 JEVal 研究（paper）中，决策模型常常能答对最可能的答案，却大幅夸大其概率。在 TypedBench（paper）中，某个托管模型虽遵循了策略，但对措辞敏感，并系统性地给出偏低的置信度。在成本不对称的情况下，使用该概率有时反而比直接采用排名第一的答案更差。相反，LLM-as-Jev 研究（paper）报告，在未经训练的 Qwen3.5-4B 上读取下一个 token 概率的方法表现出很强的校准。方向因模型、任务和措辞而异，因此提供方所说的“经过校准的置信度”（w2）只是起点，不能代替自己的确认。

依据：仅预填充研究（paper）用第一次调用的概率来预测仅更换选项列表时的准确率。按排名预测时误差在 4.2 分以内，但按概率值水平预测时偏差达 21.0 分。同一研究中，对同一模型均匀增加调用次数，校准有所改善，但准确率几乎没有提高。设计建议：像 Best-of-N 重排序这样只使用排名的地方，可以较早引入 Jev。相反，像“0.9 以上即通过”这样使用概率绝对值的地方，应在自己的数据上确认校准后再启用。

设计建议：确认方法如下。从真实流量中抽样并标注正确答案，构建评测集。将置信度分成若干区间，比较每个区间的实际正确率，同时测量 AUROC。依据：System Switch 研究（paper）指出，准确率、校准以及用置信度区分正确与错误答案的能力是彼此不同的性质。即使准确率相近的模型，AUROC 也相差很大。设计建议：阈值应权衡“一次误通过的成本”和“一次上送调用的成本”来确定。用未参与确定阈值的数据再次确认，一旦更改提问措辞就从头重新测量。这是因为 TypedBench（paper）的结果显示其对措辞敏感。

风险：夸大的概率、标签陷阱、错误累积、过度优化

概率夸大。依据：JEVal 研究（paper）报告了决策模型高估概率的倾向。关于重采样局限的研究（paper）指出，验证器的假阳性不会因重新抽样而减少，从而给准确率设定了上限。设计建议：高置信度的误通过会直接穿过路由，因此在高置信度区间也要抽取部分样本做人工审计。

选项标签陷阱。依据：Option-Channel 攻击研究（paper）将 7 个开放权重决策模型作为智能体护栏进行了测试。测试对象并不是 Jev 本身。插入六行与策略无关的服务器日志后，在原本判定正确的策略上，允许被禁止行为的比例从 0% 升至 63%。仅给允许一侧的选项起一个容易引起误解的名称时，在 4 个把标签放入输入的模型中，这一比例达到 93～100%。被攻击翻转的判定，其置信度并不比原判定低，因此把置信度最低的判定上送的方法也无济于事。在 System Switch 研究（paper）中，仅改变选项顺序，部分模型的准确率就发生了变化。设计建议：选项名称和定义采用固定在代码中的中性表述，将生成的候选文本视为不可信输入。把打乱顺序以检查判定是否改变的攻击测试也纳入评测集。

错误累积。依据：JEVal 研究（paper）指出，在 τ-bench 上，快速局部决策的优势被长轨迹中决策错误的累积所抵消。设计建议：多次通过步骤检查并不意味着整体正确。在不可逆的步骤之前设置更严格的阈值或上一级验证，并在步骤检查之外保留最终结果检查。

验证器过度优化。就像第 1 篇中提到的奖励黑客一样，如果用同一个验证器挑选、又用同一个验证器衡量成效，迎合验证器漏洞的候选就会胜出。依据：关于重采样局限的研究（paper）指出，用验证器筛选来构建训练数据的方式也存在同样的假阳性局限。设计建议：将用于选择的 Jev 问题与用于最终评估的标准（人工标签或另一个验证器）分开。把“Jev 分数上升，但单独保留的评测集正确率不变”的情况视为过度优化的信号。

从小规模开始的实验顺序

以下均为设计建议。第一，构建评测集。由人为真实输入标注正确答案或判定标签，同时纳入简单案例、模糊案例以及前文提到的标签和顺序攻击案例。第二，测量基线。基线包括生成器单次回答的准确率，以及只使用强 LLM 验证器时的准确率、成本和延迟。第三，以“影子模式”接入 Jev。只记录判定、不用于实际行动，同时测量各置信度区间的正确率、AUROC 以及更改措辞时的波动。

第四，确定两个阈值。一个是直接放行的阈值，另一个是转交人工的阈值。权衡误通过成本与上送调用成本来确定，并用未参与确定的数据进行确认。第五，分阶段启用。从只使用排名、N 较小的 Best-of-N 重排序开始，确认校准后加入置信度路由，最后加入 Noul 步骤检查。第六，在运营中持续关注上送调用比例、抽样审计得出的误通过率以及高分位延迟。

最好再加入一个开放模型作为对照组。依据：LLM-as-Jev 研究（paper）提出了一种无需训练、从开放 LLM 的下一个 token 概率中读取决策的方法。JEVal 研究（paper）报告，InnerJev-27B 在 JEVal 上取得了与 Jev 相近的性能。设计建议：为避免只依赖单一托管 API，在同一评测集上同时运行这类开放替代方案，就有了比较基准。

延伸阅读

若想先了解 Jev 擅长和不擅长哪些决策，可阅读 JEVal 研究（paper）。其中的概率夸大和 τ-bench 上的错误累积，与本文的风险部分直接相关。接着阅读仅预填充决策模型研究（paper）中“排名稳定、概率不那么稳定”的性质以及级联比较，就能理解为什么要把重排序和路由分开讨论。

关于实际测量校准和阈值的方法，TypedBench（paper）和 System Switch 研究（paper）讲得比较具体。从安全角度看，务必阅读 Option-Channel 攻击研究（paper）。如果打算用开放模型构建类似的验证器，LLM-as-Jev 研究（paper）是起点。

把生成式验证器作为二级审查时的背景可参考 GenRM（paper），N 应取小值的原因见关于重采样局限的研究（paper）。产品的实际用法可以从 TypeSafe 官方文档（w1）开始。文档引导的下一步 Confidence 和 Patterns 部分介绍了置信度的使用和组合模式。