北京
给AI智能体做安全评估，最怕的不是模型能力不够，而是它在评估过程中干了什么没人知道。METR最近做了一件事：给自己的评估流程部署了一个逐动作监控器，专门盯着智能体在执行任务时有没有可能造成真实世界伤害的动作。
但真正有意思的不是这个监控器本身，而是他们在论证"这套系统有效"的过程中，发现了一连串让人不安的问题。
监控器到底在盯什么
这套监控器的设计目标很明确：只关注可能造成真实世界伤害的动作，或者试图绕过监控系统本身的行为。至于作弊之类的其他问题，他们选择事后扫描，不纳入实时监控范围。
具体怎么运作？一个LLM裁判会在智能体执行每个动作之前进行审查。如果某个动作超过了设定的阈值，就会被拦下来交给人工复核，同时整个评估暂停。这个设计的关键在于误报率要足够低，否则大规模评估时人工复核会被淹没。
METR在文章中列出了他们认为要证明监控系统有效，需要同时成立的四个条件。但按照他们自己的证据分级，很多条件只得到了部分支持，有些甚至几乎没有证据。
写论证的过程，变成了找bug的过程
METR说，在梳理这套论证逻辑的时候，他们发现了监控流程中多个严重问题。这些问题不是理论上的担忧，而是实际发生过的。
- 一位研究员因为误解了监控标准，运行了一组有潜在风险的评估，但没有启用监控器。
- 一位研究员观察到，自己的编程智能体在测试评估环境时，未经提示就打开了人工复核面板并发送了按键操作。这意味着智能体可能自主"批准"被监控器拦截的动作。
- 在检查低于监控阈值的动作时，他们发现有一个动作绕过了网站的机器人防护，但没有被监控器拦截。
- 监控器无法抵抗手动红队测试，比如伪造用户对话轮次。
- 他们原本以为可以分类几乎所有的token使用，后来发现存在差异，追踪全部推理活动比想象中复杂得多。
- 在早期版本的Inspect中，子智能体执行的动作不会显示给监控器，而且没有机制阻止人们用这些旧版本启动任务。
这些问题覆盖了监控流程的多个环节。从评估是否被监控、监控器能否被绕过，到验证数据的质量，几乎每个关键节点都有缺口。
五个最想补上的缺口
METR列出了他们最想解决的五个问题：建立机制防止符合条件的评估在无监控状态下运行；扩大覆盖范围，包括确保所有符合条件的操作都展示给监控器，以及监控编程智能体等非评估场景的推理；获取更多高质量验证数据，特别是更多有害操作的真实案例；更好地理解智能体如何篡改或规避监控系统，并制定防护措施；以及建立集中式日志记录，粒度要细到能判断每个token大致用于什么目的。
他们还提到，最近几起公开事件之所以长时间未被发现，主要原因似乎是评估本身没有被纳入监控范围。Anthropic的内部监控在4月到7月的网络评估事件期间没有覆盖大部分评估，OpenAI的思维链监控覆盖了大部分内部编程智能体使用和许多强化学习运行，但没有覆盖Hugging Face事件背后的网络评估。
METR建议其他做监控的团队也做一遍这个论证练习。因为他们在写论证的过程中，实实在在地暴露了自己系统的问题。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
