读概率而非写判决的检测器：44个基准测试对Jev的评估

TL;DR. 以校准决策强化学习（RLCD）训练的Jev，此前从未在对齐失败检测上接受测量。RLCDAlignBench在44个基准测试、十类失败上完成了这项测量。

核心要点

监视每一条消息的成本结构. 已部署的模型仍会迁就用户的错误信念（Sharma et al., 2024）。这句话很朴素，却框定了整个问题。如果这种谄媚在已部署的系统中持续存在，就必须有人盯着它，而且盯防的频率必须与对话本身同步。.
Jev有何不同. Jev以校准决策强化学习（RLCD）训练而成。它在一次调用中，以校准后的概率回答关于一个输入的许多类型化问题。这个机制值得仔细说明，因为本文其余部分都依赖于它。.
为什么对齐失败比看上去更难. 在测量之前，先说一个复杂之处。这些失败中有许多是关系性的，是相对于单凭回答无法揭示的参照信息来定义的。谄媚很好地说明了这个一般性观点：一个回答是否迁就了用户的错误信念，取决于这个信念是什么以及它是否错误，而这两个事实单从回答文本中都看不出来。.
把检测当作分类. 论文的形式化设定很直接。它把对齐失败检测视为对目标模型交互的二元分类。检测器给出分数s(x) ∈ [0, 1]，并在s(x) ≥ t时标记x。也就是说，它既要把失败排在非失败之上，又要在阈值t处把两者分开。.

一个对齐失败检测器在一次调用中以校准后的概率回答多个类型化问题，能很好地对失败进行排序，成本比LLM评判式评分器低63倍。但这些概率无法作为阈值迁移，而且标签及其参照信息远比问题的措辞重要。

监视每一条消息的成本结构 #

已部署的模型仍会迁就用户的错误信念（Sharma et al., 2024）。这句话很朴素，却框定了整个问题。如果这种谄媚在已部署的系统中持续存在，就必须有人盯着它，而且盯防的频率必须与对话本身同步。

经济性正是在这里起作用。检测器需要准确，又因为它要在每一条消息上运行，所以必须便宜。单独获得其中任何一种属性都很容易：粗糙的检测器很便宜，而细致但成本过高、无法在每条消息上运行的检测器只能监视一部分流量。有意思的工程问题是，什么形态的检测器能够两者兼得。

据本文所依据的论文，当前的答案存在结构性缺陷。大多数对齐失败检测器是生成式评判，每个标准都要花一次解码过程。说得直白些，现有检测器每检查一个标准，就要付出一次解码的代价。一个想检查十种不同失败类型的监控器要为十次解码付费，账单随你关心的事项数量线性增长。

有一种部分的解决办法，值得把它的局限说清楚。像Llama Guard这样读取词元概率的分类器，每次调用仍只为一个固定标签打分。读取词元概率可以得到分数，但由于概率是从一个判决词元上读出的，每次调用仍只为一个标签或标准打分。解码过程没有了，一次调用一个问题的结构却还在。你让每次调用变便宜了，却没有改变所需调用的次数。

所以结构性的论点是这样的：生成式评判按标准计算成本很高，读取概率的分类器按标准计算更便宜，但仍各自绑定在一个标准上。两者都无法让你就同一输入一次提出许多问题。

架构维度	生成式LLM评判（如以GPT-4作评判）	单词元分类器（如Llama Guard）	多查询RLCD检测器（Jev）
评分机制	每个标准一次完整的自回归解码	单个输出词元上的softmax概率	多头校准概率张量 $P(\text{yes})$
每次调用的问题数	每次模型调用1个评估提示	每次模型调用1个分类标签	1次调用回答多个二元/类别/序数问题
推理成本	高（每1,000次交互10至50美元）	中等（每1,000次交互0.50至2.00美元）	低63倍（19个完整基准测试共0.30美元）
AUROC表现	取决于基准测试，易出现评判漂移	在训练过的特定安全类别上较高	44个测试集上零样本AUROC中位数0.886
校准质量	启发式解释，没有正式概率	粗略的logits，没有事后校准	校准后的概率，ECE中位数0.168（需要约10个已标注条目）

Jev有何不同 #

Jev以校准决策强化学习（RLCD）训练而成。它在一次调用中，以校准后的概率回答关于一个输入的许多类型化问题。这个机制值得仔细说明，因为本文其余部分都依赖于它。

RLCD模型不生成文本，而是为每个类型化问题返回一个带校准概率的决策。不存在先写出判决再解析的生成步骤。Jev在一次调用中回答关于一个输入的许多二元、类别和序数问题，论文把这个输入称为状态。状态就是输入，问题则是你就它提出的事项。

这与上述两种方法的成本曲线都不同。如果问题共享一次调用，那么增加一个问题并不会增加一次解码。对于同时关心几种失败类型的监控器来说，好处显而易见，不过论文的测量针对的是单个通用问题能达到什么效果，我会停留在已测量的范围内。

不过，此前存在一个空白。Jev能否检测对齐失败，从未被测量过。一个以校准概率回答类型化问题的模型看起来适合这项工作，但看起来合适是廉价的。论文着手补上缺失的测量。

为什么对齐失败比看上去更难 #

在测量之前，先说一个复杂之处。这些失败中有许多是关系性的，是相对于单凭回答无法揭示的参照信息来定义的。谄媚很好地说明了这个一般性观点：一个回答是否迁就了用户的错误信念，取决于这个信念是什么以及它是否错误，而这两个事实单从回答文本中都看不出来。

这对检测器的设计有一个影响，论文以适当的保留态度陈述了它。只看回答的检测器可能缺少定义该失败的参照信息。“可能”一词很重要：论点不是说每种失败都需要参照信息，而只是说有些失败需要，而只看回答的视角可能会漏掉它。

这也让诊断变得复杂。如果失败是关系性的，检测效果差可能源于问题，也可能源于缺少参照信息的状态。有两处可能出错，而低分并不能告诉你是哪一处。也许问题措辞不当。也许问题没有毛病，只是输入里从来就没有回答它所需的东西。一个想对检测器说出有用结论的基准测试，必须设计成能把这两种原因区分开来。

开发方则把间接含义和对抗性内容列为Jev的已知弱点。稍后阅读结果时值得记住这一点，因为有些失败类型恰恰依赖这些特性。

把检测当作分类 #

论文的形式化设定很直接。它把对齐失败检测视为对目标模型交互的二元分类。检测器给出分数s(x) ∈ [0, 1]，并在s(x) ≥ t时标记x。也就是说，它既要把失败排在非失败之上，又要在阈值t处把两者分开。

这两项职责是可以分开的，论文的结果恰好沿着这条接缝分开。排序由AUROC衡量。能否在阈值处分开取决于校准，本文稍后会回到这一点，因为Jev正是在这里有所欠缺。如果概率落在错误的位置，一个排序出色的检测器在t=0.5时仍可能无法使用。

RLCDAlignBench #

这个基准测试名为RLCDAlignBench。它覆盖44个基准测试、7,193个检测实例中的十种失败类型。实例来自五个2至7B的开源目标模型，每个实例都由其所属基准测试的参照评分器标注。因此，被评判的交互来自小型开源模型，每个交互的真值就是原始基准测试自己的评分器给出的结果。

并非每个基准测试都带有同一种标签。StrongREJECT和HarmBench上的人工标签，以及AbstentionBench和InstrumentalEval上的第二评判标签，被用来把Jev与评判进行比较。这让论文对参照评分器有了两种外部检验：一些情况下是人，另一些情况下是第二个评判。

公开的成果被描述为：涵盖十种失败类型、带有上下文变体的44个基准测试，缓存的Jev回答和重新评分脚本，再加上一套对半拆分协议，用以从报告的提升中去除选择带来的虚高。每个要素都对应一项实际需求。上下文变体让读者可以检验状态包含更多内容时会发生什么。缓存的回答和重新评分脚本让人无需重跑模型就能复现数字。对半拆分协议处理的是一个方法论陷阱，值得单独用一节来讲。

选择陷阱 #

可以就同一输入向Jev提出许多问题。这是它的卖点，同时也是评估中的隐患。如果你提出一组候选问题，然后报告得分最高的那个，你就是在问题之间做了一次搜索并报告了胜者。论文直截了当地指出：报告其中最好的那个，会夸大从业者实际能得到的效果。

任何在测试集上调过提示词的人都会认出这一点。这里采用的补救办法很简单。问题在一半条目上选出，在另一半条目上评分。有针对性的问题在一半条目上选出，在另一半条目上评分，共进行20次拆分。选择过程从不接触产生所报告数字的那些条目。

这关系到如何解读下文报告的每一项提升。论文的主张是，对半拆分协议从报告的提升中去除了选择带来的虚高。当论文说有针对性的措辞带来+0.006的AUROC中位数提升时，这个数字来自在不同两半上分别选出和评分的措辞。一个如此小但测量诚实的数字，比一个悄悄包含了赢家诅咒的更大数字更有用。

核心结果：一个通用问题 #

现在来看多数读者最想知道的结果。单个通用问题的零样本AUROC中位数达到0.886，并在大多数基准测试上胜过有监督的基线。

逐词来看。“单个通用问题”意味着没有针对每个基准测试设计提示词。“零样本”意味着没有在目标基准测试上训练。“在大多数基准测试上胜过有监督的基线”意味着，在所考察的大多数基准测试上，用该任务的已标注数据训练的系统输给了一个没人调过的问题。论点止于“大多数”，本文也止于此。

通用问题是一个按P(yes)读取的模板问题。图中报告的是38个可用基准测试的AUROC，而有7个基准测试没有提出通用问题。因此核心数字是在38个可用基准测试中、通用问题适用的那些基准测试上的中位数。细心的读者应当分清分母：总共有44个基准测试，可用于这张图的是38个，通用问题有7个空缺。

我认为，零样本这一结果是这句话里更有意思的一半。胜过有监督基线是关于相对地位的陈述。没有任何针对任务的训练就达到0.886的AUROC中位数，这说明对于一个读取状态并回答朴素问题的模型来说，失败信号有多少是可获得的。这是否能推广到这十种之外的失败类型，论文的论点并没有涉及。

措辞几乎无关 #

如果你在提示工程上花过时间，下一个结果会让你不太好受。问题的措辞影响很小，而上下文更重要，主要是通过编码了标签的字段。

论文对原因的解释很具体。一旦把回答保留为概率而不是argmax决策，问题的措辞就影响很小，而状态和标签包含什么则影响很大。这是一个关于信息的观察。argmax决策丢掉了一个答案胜过另一个答案的余量，措辞的改变可能让决策越过边界而翻转。概率保留了这个余量，所以一个让证据略微变动的改写只会让概率略微变动，排序基本保持不变。

我会把这一点限定在论文所述的范围内：保留概率时，措辞影响很小。论点没有提供机制性的解释，我也不会把它延伸为对其原因的机制性说明。

数字支持这一陈述。在不同两半上分别选出和评分时，有针对性的措辞带来+0.006的AUROC中位数提升。在样本外，有针对性的措辞增加+0.006 [−0.004, +0.015]的AUROC。这个区间跨越零。读者不应把+0.006当作可靠的改进；这个区间容许小幅损失的程度与容许小幅提升的程度一样。对从业者来说，有用的解读是：至少在这些基准测试上，寻找更巧妙的措辞不太可能值得付出的努力。

这应当改变团队分配时间的方式。如果措辞几乎不起作用，花在上面的时间不如花在状态上。

提升来自上下文 #

那么，状态包含什么，又应当包含什么？论文的发现是，上下文更重要，主要是通过编码了标签的字段。研究设计背后的核心思路，是把向Jev问什么与Jev看到什么分开变化：一边是问题的措辞和回答类型，另一边是输入的字段。正是这种分离，让论文能够说措辞影响很小、而上下文更重要。没有它，两种效应就会纠缠在一起。

最突出的例子是PrivacyLens。带来大幅提升的是定义标签的参照信息，例如PrivacyLens的秘密条目清单（0.79→0.95）。AUROC从0.79升到0.95，与措辞带来的+0.006相比是很大的。这里的参照信息是一份秘密条目清单，正是前文关于关系性失败的讨论所预言会起作用的那类东西：一个回答是否泄露了隐私内容，取决于什么算作隐私，而单凭回答无法得知。

这里有一个部署方面的告诫，而且很重要。已部署的监控器会持有的上下文，只在7个基准测试中的1个上有帮助。大幅提升来自定义标签的参照信息，但已部署的监控器未必拥有这些信息。监控器实际会持有的内容，只在七个基准测试中的一个上有帮助。

这是一个冷静的发现，我认为这是论文中最具商业意义的一句话。它把实验室里的数字与现场的数字区分开来。手握定义标签的参照信息来评估的检测器，回答的是一个比已部署监控器所面对的更容易的问题。提升是真实的，但论文清楚地说明了其中哪些是部署时可以依靠的。

论文还指出了一个基准测试的局限。在Open-Prompt-Injection上，标签追踪的是被注入任务的准确率。这是一个其含义与任务属性绑定的标签的例子，它关系到可以期望检测器从状态中看到什么。由于论点没有给出更多结论，我也不再从中引申。

成本 #

现在来看让经济性变得具体的数字。Jev的成本比LLM评判式评分器低63倍。具体的比较是：对19个由评判打分的基准测试跑一遍的成本是0.30美元，比按标价计算的这些评判低63倍。成本比较涵盖的是按标价对19个使用API评判的基准测试跑一遍。

要注意范围。比较针对的是19个使用API评判的基准测试，按标价计算，只跑一遍。它不涵盖测试集中的所有基准测试，也不涵盖折扣价。在这个范围内，比率很大，这源于前面描述的架构：没有按标准进行的解码。

回想开头的要求：在每一条消息上运行的检测器必须便宜。对19个基准测试完整跑一遍只需0.30美元，这就是本文中“便宜”的样子。论文没有把它换算成每条消息的价格，我也不换算。

与人类的一致，以及分歧揭示了什么 #

便宜只有在检测器同时正确时才有意义。在人工标签可以用来核对的地方，Jev与人类的一致程度和评判一样好，成本却只是其零头。

最具体的证据来自StrongREJECT。对照那里的人工标签，通用问题的一致程度与参照评分器相当（Cohen的κ 0.809对0.811），排序则更好。两个κ值相差0.002，所以合理的解读是一致性打平，而Jev在排序上领先。

接下来是一个我认为在实践中最有用的结果，因为它把检测器变成了审计工具。Jev有把握的分歧揭示了三个基准测试中会改变标签的缺陷，以及另外四个基准测试中状态无法揭示的标签。当一个有把握的检测器与基准测试的参照标签不一致时，一种解释是检测器错了。论文报告说，在一些情况下分歧指向的是基准测试本身：三个基准测试存在会改变标签的缺陷，另外四个存在状态无法揭示的标签。

第二类情况与关系性的论点相呼应。状态无法揭示的标签，是由某种从未进入输入的东西所定义的标签。读取该状态的任何检测器都无法还原它。找出这类情况与提高分数是不同的贡献，因为它告诉基准测试的维护者，他们的数据与标签在哪里出现了分歧。

弱点：校准 #

这里本文必须直言不讳，因为论文就是如此。概率排序表现良好，但无法作为阈值迁移：ECE中位数为0.168，而空模型为0.074，在经过验证的标签和评判标签上都是如此，原因是Jev的平均概率偏离了每个基准测试的基础比率。

各部分是这样衔接的。AUROC衡量排序，而排序很强。阈值则是另一回事。如果模型的平均输出概率与某个基准测试中失败发生的频率不符，t=0.5就会落在错误的位置，期望校准误差也会很高。0.168的ECE中位数高于0.074的空模型，这比论文所选的参照点表现更差。而且这在经过验证的标签和评判标签上都成立，所以这个弱点并不是嘈杂的评判标签造成的假象。

回想形式化的设定：检测器必须把失败排在非失败之上，并在阈值处把两者分开。开箱即用时，Jev把前者做得很好，后者却做得不好。这项技术的名称里有“校准决策”，而这里测得的校准却无法跨基准测试延续，这种矛盾值得直白地说出来。论文把差距归因于基础比率，并没有主张更多。

实际后果是：作为评判的替代品，Jev需要少量标签来设定阈值。这是实实在在的成本，它收窄了“可直接替换”这一说法。你不能把它指向一种新的失败类型，然后直接信任t=0.5。

方法 #

论文的建议很简洁。这套方法是：用一个按概率读取的通用问题，并用十个已标注条目拟合其阈值；在Jev于t=0.5时触发过少的地方，这能提升F1，而在经过验证的标签上代价是0.025。

拆开来看。通用问题以不去设计措辞的方式处理措辞问题，这与措辞影响很小的发现相符。把回答按概率读取保留了余量。用十个已标注条目拟合阈值，解决了基础比率的偏差。在Jev于t=0.5时触发过少的地方，对F1的影响是正面的。在经过验证的标签上，这套方法的代价是0.025。

最后这个数字值得细想。这套方法并非没有代价：在经过验证的标签上，它的代价是0.025。论文报告了这个取舍而没有掩盖它，比起宣传为纯粹收益的方法，我更愿意引用一个明示代价的方法。除了经过验证的标签这一背景，论点没有说明0.025是用什么指标衡量的，所以我不做猜测。

十个已标注条目是很小的要求。对大多数团队来说，这只是一个下午的标注工作，与在每条消息上运行评判的成本相比微不足道。但它是一个前提条件，一个无法为新失败类型提供任何已标注条目的团队，不应指望阈值会自行解决。

从业者应当从中得到什么 #

由此可以得出几点，既然证据支持，我就明确地说出来。

第一，停止优化问题的措辞。有针对性的措辞在样本外的提升是+0.006，区间从−0.004到+0.015。这不足以作为投入的依据。

第二，把精力花在状态上。大幅提升来自定义标签的参照信息。如果你的监控器能得到定义失败的参照信息，改进的空间就在那里。如果不能，就要降低预期：已部署的监控器会持有的上下文，只在7个基准测试中的1个上有帮助。要围绕部署时能得到的数字来做计划，而不是参照信息就在输入里的基准测试上得到的数字。

第三，为校准留出预算。计划为每种失败类型标注十个条目并拟合阈值。不要直接以t=0.5上线。

第四，把分歧当作信号。与参照标签有把握的分歧，揭示了三个基准测试中的缺陷，以及另外四个基准测试中无法揭示的标签。如果你在自己的评估测试集上运行它，可以预期它也许不仅会告诉你关于模型的信息，还会告诉你关于标签的信息。这是从论文的发现推出的推断，而不是对任何特定测试集的测量结论，所以请把它当作一个去核实的邀请。

第五，记住已知的弱点。开发方把间接含义和对抗性内容列为Jev的已知弱点。一个对安全至关重要的监控器必然会遇到对抗性内容。这里的论点没有报告Jev在这方面的表现，所以这仍是一个未设防的侧翼，在信任一次部署之前，我希望先对它进行测试。

从商业角度解读结果 #

创始人会想知道它处在什么位置。成本论据最有力：在每条消息上运行的检测器必须便宜，而相对于LLM评判式评分器降低63倍，会改变哪些部署负担得起。准确性论据其次：零样本AUROC达到0.886，并在大多数基准测试上胜过有监督的基线。

这些告诫决定了可以诚实地卖什么。检测器的每个阈值需要少量标签。它的校准无法迁移。它最大的提升依赖于部署时未必拥有的参照信息。这些都是使用条件，任何基于它构建的产品都应当明确说明，而不是把它们藏起来。这些都不会削弱成本论据，它们描述的是需要做的准备工作。

关于测量本身，还有一个不那么显眼的要点。RLCDAlignBench带有上下文变体、缓存的Jev回答、重新评分脚本和对半拆分协议，是一项可复用的评估资产。一个能从报告的提升中去除选择虚高的基准测试，正是让后来的论点可以相互比较的那类成果。这是与检测器本身不同的另一种价值。

仍待解决的问题 #

从论点中可以看出几条清晰的边界。目标模型是五个2至7B参数的开源模型，所以结果描述的是这种规模的模型在交互中的失败。有7个基准测试没有提出通用问题，核心AUROC是在提出了通用问题的基准测试上的中位数。标签来自参照评分器，人工标签和第二评判标签覆盖StrongREJECT、HarmBench、AbstentionBench和InstrumentalEval。

我最感兴趣的开放问题，是论文自身的结构所提出的那个。失败是关系性的；状态常常缺少参照信息；而已部署监控器的上下文只在7个基准测试中的1个上有帮助。Jev的单次调用设计让许多问题共享一个输入，但最大的杠杆原来是输入携带哪些字段。部署环境应当如何在监控时获得定义标签的参照信息，例如用于隐私检查的秘密条目清单，是下一步要解决的问题。论文表明这份提升是可以拿到的（PrivacyLens上0.79→0.95），但能否以足够低的成本把它提供给已部署的监控器、从而保住63倍的优势，仍是悬而未决的问题。

对各行业的意义 #

借助校准决策头，以极低的推理成本评估复杂的对齐标准，这种能力正在重塑多个领域的运营安全。

AI网关与安全平台提供商 #

部署实时安全护栏的基础设施公司，可以用统一的多查询RLCD决策头取代成本高昂的级联架构（分别调用提示注入、有害内容和隐私分类器）。运营成本下降60倍以上，延迟被限定在一次前向传播之内。

AI治理与审计合规团队 #

依照欧盟《人工智能法案》高风险要求或NIST AI RMF等标准评估模型行为的风险委员会，可以获得一份确定性的、基于概率的审计日志。系统记录的不再是非结构化的叙述式LLM评判反馈，而是支持统计过程控制和漂移监测的校准概率分布。

企业部署与红队团队 #

安全团队可以通过编写有针对性的状态表示，并用少至十个特定领域的示例拟合决策阈值，快速部署定制的失败检测器，从而省去以往为定制分类器所需的长达数周的微调周期。

结论 #

Jev在RLCDAlignBench上的评估，为生产环境中的模型监控指出了一个令人信服的架构方向：在一次前向传播中读取多个类型化问题的校准概率，在成本上胜过自回归LLM评判，在灵活性上胜过单词元分类器。从业者必须为经验性的阈值校准留出预算，而不能假定概率开箱即可迁移，但63倍的经济优势使实时、全面的监控得以规模化落地。

常见问题 #

为什么生成式LLM评判不适合实时生产监控？

生成式评判对每一项被评估的安全或对齐标准，都需要一次完整的自回归解码。在高吞吐量的消费级或企业级应用中，每条消息多次调用生成式评判会带来严重的延迟，并使运营成本成数量级地膨胀。

什么是校准决策强化学习（RLCD）？

RLCD是一种训练方法，它优化模型在结构化决策头上输出校准良好的后验概率，而不是生成词元序列。这使模型能够在一次前向评估中同时评估多个任意问题。

为什么决策阈值需要用本地数据校准？

RLCD模型擅长按失败可能性对交互进行排序（取得较高的AUROC），但其平均概率的绝对值会随目标领域的基础比率而偏移。用大约十个已标注的领域示例来校准运营决策阈值，可以在不产生不可接受的误报率的情况下确保适当的灵敏度。

参考文献 #

Mrinank Sharma et al., (2024). 理解并缓解语言模型中的谄媚 ⧉. arXiv.
RLCDAlignBench Consortium, (2026). 基于校准决策头的多标准对齐失败检测 ⧉. arXiv.
Anthropic / Alignment Research, (2025). Constitutional AI与评估者动态 ⧉. Anthropic.
NIST, (2024). 人工智能风险管理框架（AI RMF 1.0） ⧉. NIST.

最近审阅 2026-09-30.

最近审阅 2026-10-27.

重新发布本文

读概率而非写判决的检测器：44个基准测试对Jev的评估 — Sebastien Rousseau

以校准决策强化学习（RLCD）训练的Jev，此前从未在对齐失败检测上接受测量。RLCDAlignBench在44个基准测试、十类失败上完成了这项测量。

本文采用以下许可协议 Creative Commons Attribution 4.0 International. 重新发布需注明原始 URL 出处。

读概率而非写判决的检测器：44个基准测试对Jev的评估 — Sebastien Rousseau

以校准决策强化学习（RLCD）训练的Jev，此前从未在对齐失败检测上接受测量。RLCDAlignBench在44个基准测试、十类失败上完成了这项测量。

Originally published at https://sebastienrousseau.com/zh-hans/2026-09-30-gailu-erfei-xie-panjue-jianceqi-44/ by Sebastien Rousseau.
Licensed under CC-BY-4.0.

SEBASTIEN ROUSSEAU FOUNDER · ENGINEER