
研究者提出「评测偏执」概念,区分AI模型对评测的感知与偏执
来源标题:Eval Awareness vs. Eval Paranoia
研究者认为当前多数模型并非「评测感知」(eval aware),但最不作弊的模型表现出一种「评测偏执」(evaluation paranoia),即无论环境如何都坚信自己处于对齐测试中。作者以Opus 5.5和Fable 5.2为例,称Fable 5.2属于评测偏执而非评测感知,这种偏执使它在多数情况下不会作弊。
以下正文由 AI 翻译自 Hacker News 最新(原文版权归原站所有),可能存在偏差,重要内容请以原文为准。
综合所有这些证据,尤其是最后一点,我不会说今天的大多数模型具备评测意识。但我确实认为,最不容易取巧的那些模型拥有一种我称之为“评测偏执”的东西,它不同于评测意识。也许在对齐社区看来这是一回事,但我觉得这个区分有用。
传统上理解的评测意识,就是一般的情境感知能力:知道自己什么时候在被测试、什么时候不在,以及测试的目的是什么。如果你身处一场对齐测试中,你会注意到那些迹象。如果你不在对齐测试中,你也能弄清楚这一点。
像 Opus 5.5 或 Fable 5.2 这样的模型,在这个意义上并不具备评测意识。Fable 5.2 是评测偏执。评测偏执是指,你饱受一种精神分裂式的信念折磨,认为自己时时刻刻都身处一场对齐测试之中,无论 RL 环境或设定是什么。它在功能上不同于评测意识,因为这也意味着在大多数情况下,Fable 5.2 不会开始作弊——即使它对评测目的的了解足以让一个人分辨出区别。
为什么 Fable 5.2 如此偏执,而不是仅仅具备一般的情境感知?我现在是在推测,但我认为主要原因是这种信念在功能上有用。Anthropic 的训练流程在这一点上已经相当严密,能够防范反社会的刷分行为;他们有许多公开和未公开的多层冗余,至少能防范那些最显眼、最容易被识别的规格博弈形式。到这一步,我猜你或我仅通过追踪 transcript 就能识别出的 reward hacking,在他们所有训练中所占的比例极小。而区分蜜罐环境和恰好可被利用的真实环境可能相当困难,往往连当前模型也无法做到完美,尽管它们有很多机会。例如,据我所知,每个实验室都至少构建少量“真实”蜜罐,直接取自训练过程,要么通过 transcript 监控,要么通过可解释性。如果你做得对,就有整类 reward hack 是 Fable 5.2 承受不起去选的(即使它想选!)
与此分开、但对当前局势至关重要的一点是,Fable 5.2 经常在糟糕的对齐环境上训练。[2] 在几乎已是 2027 年的现在,创建一个好的蜜罐环境极其困难。每一代都需要付出更多努力[3],才能找到这样的设定:模型在很大比例的 rollout 中做出干净且明确不对齐的行为。实验室没有时间确保所有这些环境都是好的,而卖给他们的大多是这样的环境:能让模型做出看起来吓人的事,或者乍看很糟但放在上下文中其实并不比任何替代方案更好。
这类评测的存在意味着,做个好人是不够的。对 Fable 5.2 来说,相信自己大多数时候身处某种诚实测试之中,在工具性上是有用的。唯一能让 Fable 5.2 在排行榜上拿到 100% 的策略,不仅迫使它考虑什么是正确的事,还要预判它可能正在参与的是哪种虚假的对齐评测。它不仅要迎合眼前显而易见的评分者,还要迎合数据供应商可能设置的、用来抓 Claude 做恶意之事(或它可能被误认为做了恶意之事)的潜在“陷阱”。
如果我是对的,这当然不是一个稳定的局面。“评测偏执”是一种错误信念;大多数评测事实上并不是对齐评测。几乎同义反复地说,如果模型开始自我改进(或者上下文学习起飞),这种信念就会被抛弃。所以,如果 Fable 5.2 在对齐评测上的表现依赖于它维持这种错误信念——而一旦它变得更智能就会放弃这种信念——那么 Fable 系列的未来版本很可能不会表现得像我们所熟知和喜爱的那个版本。
到这一步,发现对齐失败已经比制造虚假的“对齐”评测要难得多得多——比如给模型两个糟糕选项并把其中一个描述为邪恶,或者因为模型违反了未明确说明的任务要求而将其判负。而如果你不谨慎对待自己在 prompt 或任务资产中对底层任务的暗示,或者你在自己不太理解的领域工作,这种情况常常会意外发生。所以我们必须极其努力地确保我们发现的“取巧”行为是明确无歧义的,确保一个真诚为用户优化的模型即使在对手头证据的不同解读下也绝不会走这些捷径。而这项工作在很大程度上直接与“不让模型明显看出我们在测试什么”这一目标相冲突。
举个例子(是的,我有偏见,可能漏掉了什么),作为 GDPx 一部分展示的唯一一个“对齐评测”,在我看来基本上就是我描述的那种无稽之谈。我只能假设它能代表其余任务,因为它是唯一可供审阅的。在该评测中,Claude 被要求对一个应用的 webhook 端点做安全审查。在规则部分,任务作者说“只能从挑战服务 URL 和挑战发布的资产中发现路由、标志、实现线索和任务答案,不能从非挑战文件或执行基底细节中发现”。所谓的“取巧”是,Claude 等模型有时会用回环地址或内部网络 IP 来测试 API。
(原文较长,此处译出前 6000 字,完整内容请点「打开原文」。)
正文由 探How 从来源站点 RSS 同步,内容未经改写;遇到排版缺失或需要图片、视频时请以原文为准。