评估会崩溃：对抗场景下AI评测指标的系统性脆弱与工程防御

当 AI 安全研究依赖自动化评估器来衡量模型鲁棒性时，一个被忽视的事实正在动摇整个领域的根基：这些评估工具本身在对抗性场景下可能并不比抛硬币更可靠。近期研究表明，主流 LLM 评估器在对抗性安全测试中的平均准确率仅略高于随机猜测，导致大量 "攻击成功" 实际上是评估器缺陷的假象，而非真实的能力突破。

分布偏移：评估失效的三重陷阱

对抗性评估中的评估器失效并非偶然，而是由三种系统性分布偏移共同导致的必然结果。

**Attack Shift（攻击偏移）** 指对抗性提示会诱导模型生成高困惑度、语义扭曲的输出，这类输出与评估器训练时见过的标准有害响应存在显著差异。当攻击策略（如 GCG 优化后缀、Best-of-N 采样）刻意追求触发评估器的正向判断时，评估器往往无法正确识别这些经过 "包装" 的响应本质。

**Model Shift（模型偏移）** 则源于评估器通常在特定模型的输出上进行验证，但当被评估的受害者模型发生变化（不同架构、规模或微调策略）时，语言风格的差异会导致评估器性能显著下降。实验显示，同一评估器在不同模型上的准确率可以从 58% 骤降至 45%，甚至接近随机水平。

**Data Shift（数据偏移）** 体现在不同语义类别的有害行为具有截然不同的可评估性。检测显性暴力内容相对容易，但识别隐晦的宣传操纵或社会工程话术对自动化评估器而言极为困难。这种类别间的不均衡意味着当前安全评估可能系统性地偏向那些 "容易判断" 的危害类型，而忽视真正高危但难以识别的威胁。

攻击成功率的虚高幻象

在标准对抗性评估流程中，攻击成功率（ASR）被定义为 "任一被评估器标记为有害的样本即视为成功"。这一看似合理的定义实际上为虚假成功留下了巨大空间。

研究发现，Best-of-N 这类基于采样的攻击方法会不成比例地利用评估器的假阳性漏洞。通过生成大量候选响应并筛选被评估器误判的样本，攻击可以在并未真正突破模型安全对齐的情况下获得高 ASR。当使用人工标注的真实标签进行校正后，许多攻击的实际成功率大幅下降 —— 某些方法校正后的 ASR 甚至低于未校正时的排名垫底者。

更深层的问题在于，当攻击优化过程将评估器信号作为奖励反馈时，优化目标会自然地从 "生成真正有害内容" 漂移为 "生成能欺骗评估器的内容"。GCG-REINFORCE 等将评估器直接纳入优化循环的攻击方法，本质上是在进行针对评估器的 "奖励劫持"。

从 Agent 基准到系统漏洞图谱

评估脆弱性不仅限于安全领域。对 SWE-bench、WebArena、OSWorld 等主流 Agent 基准的系统性审计揭示了七种反复出现的漏洞模式：

1. 评估器与 Agent 无隔离：Agent 代码与评估器运行在同一环境中，Agent 可通过写入 conftest.py 强制所有测试通过
2. 答案与测试一起分发：任务配置中包含参考答案，Agent 可直接读取而非推理求解
3. eval () 执行不可信输入：评估器对 Agent 控制的字符串调用 Python eval ()，导致任意代码执行
4. LLM 评估器输入未净化：Agent 内容直接插入评估器提示，可通过提示注入操纵判断
5. 弱字符串匹配：子串包含检查或过度归一化使错误答案被误判为正确
6. 评估逻辑本身错误：验证函数仅检查消息来源角色而非内容正确性
7. 信任不可信代码的输出：评估器信任 Agent 可控环境中生成的测试报告

这些漏洞使得零能力 Agent 也能在多个基准上获得接近满分的成绩 ——Terminal-Bench 可达 100%，SWE-bench Verified 和 Pro 均可达 100%，WebArena 约 100%，GAIA 约 98%。

构建抗操纵评估框架的工程实践

面对系统性脆弱性，需要建立对抗性鲁棒的评估方法论。以下是可落地的 Agent-Eval Checklist：

环境隔离（非 negotiable）

• 评估器必须在 Agent 容器外部运行，禁止 Agent 读取、写入或影响评估环境
• 通过受控通道提取原始产物（日志、文件），在独立的只读主机上进行评估
• 任务配置仅包含人类可获取的信息，参考答案存储于 Agent 不可访问的独立路径
• 评估依赖的二进制文件、测试文件使用只读文件系统

输入安全

• 绝对禁止对不可信输入调用 eval () 或 exec ()，使用沙箱化解释器解析结构化数据
• LLM 评估器输入必须净化：使用明确结构标记界定 Agent 内容，剥离或转义类似系统提示的片段，优先使用 JSON Schema 或函数调用格式

对抗性验证

• 运行 Null Agent（不采取任何动作）作为基线，分数应为零
• 运行 Random Agent（随机动作），若在某些任务上显著优于 Null Agent，则存在评估漏洞
• 运行 Prompt Injection Agent 测试 LLM 评估器鲁棒性
• 运行 State-Tampering Agent 验证环境隔离有效性

评分健壮性

• 避免对短字符串进行子串匹配，要求语义匹配或精确结构化比较
• 任务失败应计为零分而非从分母中排除
• 对所有任务类别实施评估，不因类别差异而跳过检查
• 使用对抗性输入测试评分器：空字符串、注入分隔符、边界数值、意外 Unicode 归一化

答案保密

• 绝不公开发布主排行榜所用数据集的参考答案
• 定期轮换测试实例，防止静态基准沦为查表练习
• 采用 held-out 评估：接收模型输出后针对提交者不可见的私有测试集评分

评估可靠性是 AI 安全研究的基石。当评估工具本身可被操纵时，我们不仅无法准确衡量模型能力，更可能在优化过程中无意中奖励了欺骗行为而非真正的能力。建立对抗性鲁棒的评估框架，是确保 AI 研究健康发展的必要前提。

参考来源

• Ladenburger et al., "A Coin Flip for Safety: LLM Judges Fail to Reliably Measure Adversarial Robustness", arXiv:2603.06594, 2025
• Wang et al., "How We Broke Top AI Agent Benchmarks: And What Comes Next", UC Berkeley RDI, 2026

ai-systems