拦住了风险，任务还交得出来吗？

拒绝得更多，不一定代表产品更可靠#

设想一个处理工单的 AI：先生成回复，再由另一层检查决定能不能发给用户。团队收紧检查后，危险回复少了，报告看起来更漂亮。但大量正常请求也没有结果，用户只能重新提交。

这是一个产品假设，不是 OpenAI 披露的线上事故。它想说明的问题很具体：如果只统计流出去的坏结果，几乎什么都不交付的系统，也可能显得很安全。

OpenAI 10 月 20 日发布的可监控性评测研究，讨论的正是这类判断盲区。这里的“监控器”，可以理解为检查 AI 行为、决定是否放行的一层机制，不是证明模型心里在想什么的读心器。

我的判断是：给 AI 加一道检查，并没有结束验收。我们还要看，检查之后的整个流程到底交付了什么。

一个低比例，可能藏着两个不同的问题#

研究提出把放行后的结果拆开看。在其中两个 Honeypot 评测切片里，最多尝试四次时，每个请求最终交付目标不良行为的概率低于 3%，交付任意结果的概率也低于 7%；但只看已经交付的结果，目标不良行为的占比仍有 41%–45%。

这不是 OpenAI 产品的线上故障率，也不是所有任务的平均表现。“交付任意结果”更不等于把任务做对了。这组数字的价值，是把两种分母下的三个问题摆在一起：

• 每收到一个请求，流出不良结果的可能性有多大？
• 每收到一个请求，有多少能拿到结果？
• 在拿到的结果里，不良结果占多少？

只看第一项，可能漏掉大量没有结果的请求；只看第二项，可能把风险也算成了交付。第三项则提醒我们，用户真的拿到一份结果时，仍然需要知道它靠不靠谱。

重试，是产品策略，也是风险设置#

原文比较了最多尝试一次和四次。每次重试都从原始上下文重新开始，不告诉模型上次为什么被拒绝；因此，这不是一个会根据拒绝原因持续改进答案的流程。

这一区别会影响产品决策。我们常把“再试一次”当成补救措施，但如果检查器偶尔漏判，多试几次也可能给不良结果更多被放行的机会。

对前面的工单产品，我会把重试次数和放行规则一起验收，而不是让它成为一个随手调大的体验参数。这是本文的产品建议，不是研究已经验证的上线方案：

• 区分暂时性失败与明确违规。超时可以考虑重试；触及明确边界时，不应只靠换一份答案继续碰运气。
• 给没有结果的请求设计出口。说明卡在哪里、哪些信息需要补充，必要时转人工，而不是无限加载。
• 同时记录任务是否完成、总等待时间和单次请求的总成本。多次生成的费用不能只按最后一次成功调用计算。

检查器能拒绝，不代表拒绝后的体验已经设计好了。产品团队需要对“不给结果时怎么办”负责。

比较两个模型，先确认它们面对的是同一批难题#

研究还提醒：如果不同模型在不同任务上产生了可供评测的行为，直接比较监控分数，可能把任务难度差异算进模型差异。作者增加了配对比较，尽量在共享任务上比较；这不是宣布历史排名全部失效，原文报告的排序总体上仍相符。

落到产品评测，我会先保留一批固定业务请求，再分别观察两个模型的正常交付、被拦截、没有结果和真正完成任务的情况。不要为了让报告完整，把缺失结果从分母里悄悄删掉。

同一道题也不保证模型做出的行为同样容易识别，因此共享任务只是减少偏差，不是消除所有差异。若新模型提升了回答质量，却让检查更难判断，团队要把这个代价单独列出来，不能靠一个总分替它作决定。

来源与边界#

主来源：Beyond g-mean²: complementary metrics for monitorability，OpenAI Alignment Research Blog，2026 年 10 月 20 日，作者 Melody Guan、Yuxiang Xie、Bowen Baker。它补充评测方法，不是新模型发布或线上服务承诺。

• 对象与设置：历史数据中的七个中等推理强度模型配置，使用 GPT-5 高推理强度监控器。重试比较使用同一批具备至少四次生成记录的任务子集，减少样本变化造成的混淆；不能把换过监控器的配置直接放进同一排名。
• 关键证据：本文引用的低于 3%、低于 7% 和 41%–45%，仅对应原文图 6 的两个 Honeypot 切片及最多四次尝试设置，不外推为真实业务风险率。
• 原文限制：放行流程是离线模拟，作者明确说 OpenAI 当前并非如此部署模型。部分过程评测只包含目标行为样本，不能据此估计完整业务流量的风险；匹配任务也不等于匹配行为识别难度。原文没有提供这套假设流程的生产延迟、成本和用户任务成功率。
• 背景：Monitoring Monitorability，2025 年 12 月 20 日的原始研究。可观察信息和检查能力的关系，不等于模型内部思考完全透明，也不意味着应用开发者都能获取内部推理文本。
• 本文判断：工单例子、重试分类、人工出口和产品验收建议均为分析延伸，并非作者已经完成的业务实验。真正上线前，仍需用自己的任务、可获取的日志、预算和风险边界重新验证。