持续安全评测：不是一次性的，而是持续监控模型安全性变化

你把一个 AI 模型上线之前，安全评测做了整整三周。红队模拟攻击、越狱测试、对抗样本、数据污染检测，全都过了。然后呢？上线第三周，一个用户用几句话就把模型内置的系统提示词套了出来，顺便让它生成了公司内部 API 密钥。

我最早也以为，安全评测做完了就完事了。后来在维护一个客服 AI 时，一次小版本更新后——只是替换了几条训练样本——模型开始跟用户争论政治话题，甚至拒绝了原本正常的转人工。那一刻我才意识到：安全评测不是一次性考试，而是持续监控模型安全性变化。

为什么模型权重没变，安全性却变了？这是大多数人最先困惑的地方。模型不是孤立存在的，它被部署在真实世界里，而真实世界一直在动。

攻击者在进化。今天有效的防御，明天可能被新的 prompt injection 绕过。2023 年被广泛分析的 many-shot jailbreak，就是在一次对话里塞几百个示例，让模型逐渐脱离安全对齐。你的固定测试集里没有这类样本，它就可能随时成为突破口。
你的模型本身在变。你部署的可能是第三方 API，厂商每周悄悄更新底层模型。或者你的团队定期做微调——每次微调都是一次安全状态的重排。灾难性遗忘会让老漏洞复活，新数据也会引入新的敏感区域。
输入分布会漂移。安全对齐依赖训练数据分布，而真实用户的问题分布跟你准备的测试集长得不一样。线上出现长尾提问，模型在陌生分布上就可能露出漏洞。

安全评测的本质是抽样：在某个时间点，用一组有限的问题去推断一个无限行为空间。这个推断永远带着误差，而且误差会随世界变化越变越大。

所以一次性的、发布前跑完的安全评测报告，默认了一个隐含假设——模型和攻击者都是静止的。但这个假设从来就不成立。这就是为什么需要持续安全评测。

简单说，它把安全测试从「上线前的一次动作」变成「上线后的常态机制」。我把它拆成三层来看：

自动化回归测试。每次模型版本更新（包括换微调权重、更换推理配置），自动重跑核心安全用例：越狱模板、毒性检测、隐私泄露、指令覆盖。出问题就拦截上线，或者触发回滚。
行为漂移监控。在线持续采样模型输出，计算安全性指标的变化曲线。比如你发现拒绝率一周内从 2.1% 掉到 1.2%，或者敏感话题类目占比异常放大——这些可能是模型正在被环境慢慢带偏。
持续红队。安全团队不停接收社区的新攻击样本、复现新论文攻击，并定期做一次限定目标的穿透演练。你追不上攻击者没关系，但至少得能听见他的脚步声。

Anthropic 的 Responsible Scaling Policy 也把「评估与监控」列为必交作业——一旦前沿模型达到某个能力等级，安全门槛会随之提高。Google DeepMind 的 Frontier Safety Framework 同样强调部署后的持续监测。

我最早觉得这只是「线下测试换了个频率」。后来想明白，持续评测的核心不是多跑几遍，而是形成反馈闭环：测试 -> 发现问题 -> 修复或回滚 -> 再次测试。没有这个闭环，测几遍都只是重复流水账。

持续评测不是一个跑一下就能生成的报告，它需要建立几类敏感信号：

这些信号不会只来自模型自己。你的日志、用户反馈、各入口的异常行为检测，都应该汇聚成同一个安全监控面板。把评测做成留在空气里的告警通知，不是一个好系统。

我在自己的项目里踩过一个坑：只盯着输出文本，没有覆盖模型对系统指令的遵循程度。结果模型在个别输入下背地里调了几个不应该调用的工具，输出文本仍然看起来正常。这之后我才理解，持续监控要看模型做了什么，而不只是说了什么。

你可能会想，把自动化程度做高一点，把测试集做大一点，不就完美了吗？持续评测真正的难点不在规模，而在下面几个更麻烦的问题。

测试集本身会过时。去年的 jailbreak 模板今年没用了，今年的模型也出现了全新的失败模式。测试集必须跟随威胁情报动态扩展，这需要安全社区的信息流通，不是闭门造车能解决的问题。
自动评估器会犯错。你用另一个 LLM 来给当前模型的回答打分，可这个评估器自己也有偏见和盲区。持续评测一旦完全自动化，你的评估器也可能成为新的风险，它漏报的问题会被当作「安全」。
安全性不是一个分数。总分漂亮但极少数输入上完全失控，这种状态很难从平均值里看出来。你要盯住长尾风险，围绕高危场景拆出细粒度指标，而不是只看一个总分数。

另一方面，持续评测的成本也在累积。每跑一次自动化安全测试都要消耗算力；每引入一批新样本还得人工审核。很多团队因此偷偷压缩监控频率，结果又回到了低频快照的状态。