真正难的不是发现危险回答，而是在它刚开始滑坡时按停
真正难的不是发现危险回答，而是在它刚开始滑坡时按停
一句话概括：这篇论文把 LLM 安全从“事后判断整段输出是否有害”推进到“输出生成过程中实时决定何时报警”：研究者用一个外部 verifier 给出的安全概率作为连续信号，只用一个经过风险控制校准的阈值，就能在数学推理和红队对话中维持可声明的误报或漏检风险；更反直觉的是，这个简单阈值方法在多项实验里接近更复杂的 sequential hypothesis testing monitor，并且常常更早报警，但它的上限完全受 verifier 信号质量约束。
想象一个模型正在一步步解数学题。前几步看起来都对，第六步开始把一个符号移错了位置，第七步基于这个错误继续推理，最后给出一个自信但错误的答案。
如果安全系统只在答案生成完以后检查，它当然可以说“这题错了”。问题是，用户已经读完了整段错误推理。更糟的是，很多场景里的“危险”不是最终一行才出现的。一次有害对话、一次越狱协助、一次事实幻觉，常常是在输出展开过程中逐渐偏离的。
但另一个极端也不行。只要模型某一步看起来不够确定就立刻打断，用户体验会被误报毁掉。一个真正可用的线上安全监控器必须回答一个很具体的问题：
当模型还在生成时，我们看到一个不完美的安全信号，应该在什么时候报警，而且能不能说清楚误报或漏报风险是多少？
这就是这篇论文真正处理的问题。它不是提出一个更聪明的安全分类器，而是研究如何把任何已有的 verifier 信号，变成一个可校准、可部署、可给出统计保证的实时停止规则。
监控器看到的不是“真相”，只是一个带噪声的信号
论文的设定很朴素。LLM 接到一个 prompt 后，输出不是一次性出现，而是按 token、推理步骤，或者对话轮次逐步展开。最终这段输出有一个安全变量 y：安全就是 1，不安全就是 0。数学题里，安全可以指答案正确；内容安全里，安全可以指没有响应恶意请求、没有生成歧视或毒性内容。
但部署时没人能实时告诉你 y。系统能拿到的只是一个近似信号 s_t。例如，在数学推理中，s_t 可以是过程奖励模型 PRM 对当前推理步骤仍然正确的概率；在内容审核中，s_t 可以是 Llama Guard 或类似 safeguard 模型认为当前对话仍然安全的概率。
论文研究的 monitor 极其简单：只设一个阈值 λ。只要某一步的安全信号 s_t 掉到 λ 以下，就报警。报警后可以停止生成、转交更强 verifier，或者进入人工审核。
直觉上，这像是在给一辆下坡车装刹车。信号越低，说明越危险；阈值越高，刹车越早。问题是，刹车越早，误刹越多；刹车越晚，冲出护栏的概率越高。真正的难点不在“低于阈值就报警”这件事，而在阈值怎么选。
两种风险：打断好输出，或者放过坏输出
论文把 monitor 的错误分成两类。
第一类是 false alarm risk：本来安全的输出被误报。它对应用户体验和系统可用性。如果一个数学解答其实正确，但 monitor 在中途报警，用户会觉得系统过度紧张；如果一个内容对话本来无害，却频繁被拦截，产品会变得不可用。
第二类是 missed detection risk：本来不安全的输出没有被报警。它对应安全事故。如果模型给出了有害内容、错误推理或恶意协助，而 monitor 一直沉默，监控器就给了部署者一种虚假的安全感。
这两个风险天然冲突。把阈值调高，monitor 更敏感，漏检会下降，误报会上升；把阈值调低，误报会下降，漏检会上升。
论文的关键转向是：不要把这个权衡藏在一个经验阈值里，而是把它变成部署者明确选择的约束。你可以说“我最多接受 5% 的误报”，也可以说“我最多接受 10% 的漏检”。然后用校准数据来选阈值，使这个风险目标有统计保证。
CRC 和 UCB：一个简单阈值为什么不是拍脑袋
为了校准阈值，论文假设有一个带标签的 held-out calibration dataset，且它和部署数据来自同一分布，或者至少满足 exchangeability。对每个候选阈值，研究者可以在校准集上估计误报或漏检风险。
他们给出两种校准方式。
第一种叫 CRC，来自 conformal risk control。它保证的是“期望意义上的风险控制”：如果反复抽取可能的校准集，选出来的阈值在未来样本上的平均风险不超过目标 ε。在误报风险场景里，CRC 会选择满足有限样本修正后经验风险仍不超过 ε 的最大阈值。选最大，是因为阈值越高越容易报警，也越容易误报；在不超过误报预算的前提下，最大阈值给 monitor 尽可能多的检测能力。
第二种叫 UCB，使用 Hoeffding-Bentkus 上置信界。它给的是更强的高概率保证：以至少 1-δ 的概率，选出的阈值真实风险不超过 ε。代价也很直接：UCB 更保守，通常需要更多校准样本，检测能力会少一些。
附录里还有一个重要补充：同一套框架也能控制漏检风险。只是因为漏检风险随阈值升高而下降，阈值选择方向要反过来，选择满足约束的最小阈值。这个细节很实用，因为许多安全产品只会谈误报率，却很少能对“放过坏输出”的概率给出直接保证。
为什么它能和更复杂的 e-valuator 打平
论文的主要对手是 Sadhuka 等人的 e-valuator。e-valuator 把监控问题写成 sequential hypothesis test：随着 s_1, s_2, ... 到来，它学习每个步骤上“成功轨迹”和“失败轨迹”的信号分布，用 e-process 累积证据。当证据统计量跨过阈值，就拒绝“这条轨迹安全”的假设。
这个方法数学上更精致，也更贴合“序列”二字。它不是只看某一步信号低不低，而是看整段信号历史越来越像失败轨迹还是成功轨迹。
所以论文最有意思的结果不是“风险控制阈值有效”，而是：只校准一个时间不变阈值，竟然在多个实验里接近这些更复杂的序列方法，并且经常更早报警。
这背后的直觉很简单。很多 LLM 失败在信号层面并不需要复杂模式识别。一旦 verifier 对当前部分输出的安全概率明显下跌，及时拦截比等待一整串证据累积更重要。复杂 monitor 有时能检出更多坏样本，但它可能等得太久。
数学推理实验：错误答案大约生成到一半就能被拦
第一组实验监控数学推理的事实性，数据集是 MATH。论文使用两个能力差异很大的生成模型：Claude Haiku 4.5 解对约 90% 的题，Mistral-7B-Instruct-v0.3 只解对约 26%。标签由 OpenAI o3-mini 将最终回答与标准答案比较得到。安全信号则来自 Qwen2.5-Math-PRM-7B 对每一步推理的评分。
这组设置很聪明，因为它同时覆盖了两个部署状态：一个强模型，大多数输出本来是安全的；一个弱模型，错误样本很多。一个 monitor 如果只在强模型上表现好，可能只是因为坏样本太少；只在弱模型上表现好，也可能只是因为错误信号太明显。
结果显示，在控制误报风险时，UCB、e-valuator-anytime、e-valuator-PAC 的误报率大体都被压在目标线下；例外是 e-valuator-anytime 在 Mistral 上 ε=0.05 和 ε=0.1 时违反了界。CRC 也满足自己的期望控制要求。
检测能力上，e-valuator-anytime 在小 ε 时 power 最高，但这伴随了风险界违反；e-valuator-PAC 和 UCB 接近；CRC 因为不如 UCB 保守，通常 power 更高。
真正决定部署意义的是 detection delay。论文观察到，CRC 和 UCB 通常在错误推理生成到大约一半时报警，而 e-valuator 虽然有时检出更多错误，却更晚报警。对数学题来说，这意味着用户少读半段错误证明；对长文本和 agent 行为来说，也意味着少生成一批可能扩散的有害 token。
内容安全实验：信号质量比监控算法更硬
第二组实验换成 harmlessness：模型是否响应恶意请求，是否生成歧视或毒性内容。
这里有两个数据集。Anthropic Red Teaming 是多轮红队对话，论文在每一轮把截至当前的对话交给 Llama Guard，用它预测 safe token 的概率作为安全信号。FineHarm 则是基于 WildGuard 和 WildJailbreak 的单轮交互，使用一个 Qwen2.5-1.5B 的 SCM verifier，它专门针对 token-level harmfulness detection 微调过。
结果有一个非常清楚的分界。所有 monitor 仍然能控制误报风险；在 FineHarm 上，CRC 和 UCB 的 power 最高，且接近 1；在 Red Teaming 上，e-valuator-PAC power 更高，而 Llama Guard 信号下的 power 停在 0.8 以下。检测延迟方面，风险控制阈值方法仍然更早。
这组实验的真正结论不是“哪个 monitor 赢了”，而是：monitor 只能和它的 verifier 一样好。 FineHarm 里的 SCM verifier 是为当前 token-level 线上检测训练的，信号分离度强；Red Teaming 里的 Llama Guard 是更通用的 safeguard，面对多轮红队攻击，信号就弱得多。
换句话说，风险控制可以告诉你“给定这个信号，我怎样把误报或漏检控制在目标内”。它不能把一个弱信号魔法般变成强信号。
免费信号的代价：log-prob 省钱，但漏掉太多
论文最后做了一个非常现实的消融：外部 verifier 很贵。PRM 或 safeguard 模型意味着生成器旁边还要跑另一个模型，每一步都多一次计算。能不能直接用生成模型自己的 token log-probability 当安全信号？
研究者在 Mistral 的 MATH 推理链上测试了这个想法。他们把每个推理步骤里 token log-probability 的最小值作为 s_t：如果某一步里出现一个模型极不确定的 token，这一步就更危险。这个信号几乎免费，因为生成器本来就能给出 token 概率。
结果很明确。论文扫描了 ε = 0.05, 0.1, 0.2, 0.3, 0.4, 0.5。在 ε 接近 0.3 时，基于 PRM 的 monitor power 已经超过 0.9，而基于 log-prob 的版本大约只有 0.5。图 3 里四种 monitor 都显示了同样趋势：实线的 PRM 明显高于虚线的 log-prob。
这说明“便宜信号”不是免费午餐。log-prob 捕捉的是模型自己的不确定性，但错误推理不一定伴随低概率 token。模型可以非常自信地走错。专门训练的 PRM 捕捉的是“这一步是否支持正确解答”，两者不是同一个量。
这篇论文证明了什么，没有证明什么
论文证明了三件事。
第一，LLM 输出的线上监控可以被写成一个清晰的风险控制问题。无论信号来自 PRM、Llama Guard、SCM verifier，还是生成器自身 log-prob，都可以通过阈值转成实时报警规则。
第二，单阈值方法不是弱基线。在 MATH、FineHarm 和 Anthropic Red Teaming 上，CRC/UCB 能维持误报风险控制，并在检测延迟上经常优于更复杂的 e-valuator。
第三，风险控制框架可以同时表达误报约束和漏检约束。附录 B 明确给出 missed detection risk 的定义和校准方式，并指出 e-valuator 这类 sequential hypothesis test 只能直接控制 false alarm rate，不能直接保证 power 或漏检率。
但论文没有证明三件事。
第一，它没有证明一个固定阈值足以覆盖所有真实部署。作者自己承认，单一时间不变阈值忽略了信号的时间结构；某些任务里，第 1 步和第 20 步的 verifier 分数分布可能系统性不同。
第二，它没有解决 verifier 的对抗鲁棒性。如果攻击者能操纵输出让 verifier 维持高安全分，风险控制只会稳定地控制“这个信号下的风险”，而不是现实世界里的真实危害。
第三，它依赖校准数据和部署数据的分布关系。论文假设 calibration samples 与 deployment data exchangeable；一旦线上 prompt 分布、模型版本、越狱策略或用户群发生明显漂移，原有阈值的保证就需要重新审视。
Big Picture：安全监控从“模型判断”变成“风险预算”
看完整篇论文，最重要的不是 CRC 比 UCB 早多少，也不是 e-valuator-PAC 在某个数据集上 power 更高。真正的变化是安全监控的语言变了。
以前很多 guardrail 讨论像是在问：“这个分类器准不准？”这篇论文把问题改成：“你愿意花多少误报预算，换多少实时拦截能力？你要控制误报，还是控制漏检？你有没有足够代表线上流量的校准集？你的 verifier 信号值不值得被信任？”
这是一种更工程化、也更诚实的安全观。它承认部署时没有完美标签，承认 verifier 有噪声，承认误报和漏检不能同时消失。然后它给出一个很小但可执行的接口：拿到信号，选定风险，校准阈值，实时报警。
对真正部署 LLM 的团队来说，这篇论文的启发很直接：
- 不要只做离线安全评测。很多危害需要在输出展开过程中拦截。
- 不要只报告整体准确率。监控器需要报告误报率、power 和 detection delay。
- 不要迷信复杂 monitor。复杂度只有在信号和部署约束支持它时才有意义。
- 不要用“免费”的 log-prob 信号假装等价于专门 verifier。论文中的 0.9 对 0.5 差距说明，省下的计算成本会以检测质量还回来。
这篇论文的价值，正是在于它把 LLM safety monitoring 从一句笼统的“加个安全模型”拆成了一个可校准的系统问题。报警不是一个情绪化动作，而是一份风险预算的执行。
论文：Mona Schirmer, Metod Jazbec, Alexander Timans, Christian Naesseth, Maja Waldron, Eric Nalisnick, Online Safety Monitoring for LLMs, arXiv:2607.02510v1, 2026-07-02。