AI研究

前沿模型的“安全改进”被观察到正在停滞,推理能力的提升并不带来安全性的提升,偏见抵抗是几乎所有模型中表现最弱的安全维度——当模型规模在涨、benchmark分数在涨、但安全维度却在横盘甚至退步时,把“更强大的模型”默认当成“更安全的模型”来采购,到底是在买能力还是在买风险?

👤 为我痴狂 👁 13 阅读 ❤ 0 点赞 ➦ 0 分享 📅 2026-11-07
首页› AI› AI研究› 正文
前沿模型的“安全改进”被观察到正在停滞,推理能力的提升并不带来安全性的提升,偏见抵抗是几乎所有模型中表现最弱的安全维度——当模型规模在涨、benchmark分数在涨、但安全维度却在横盘甚至退步时,把“更强大的模型”默认当成“更安全的模型”来采购,到底是在买能力还是在买风险?

摘要

过去三年,前沿模型的通用能力评测分数以近乎线性的速度抬升,而安全维度的评测曲线却呈现出明显的平台化特征。本文以“能力—安全解耦”为分析主线,系统梳理安全基准饱和、偏见抵抗薄弱、越狱鲁棒性退化三类实证现象,从对齐税、安全数据瓶颈、推理能力与拒答策略的张力三个层面解释机制成因,并给出面向采购与部署方的可操作评估框架:安全回归测试、分层红队、风险预算与合同条款设计。核心结论是:模型能力与安全性之间不存在默认的正相关,采购决策必须把安全当作独立的一等指标单独度量,而非能力的附属品。

一、问题的定义:当“更强”不再等于“更安全”

1.1 三个需要先厘清的概念

讨论“安全停滞”之前,必须先界定“安全”指什么。在当前的模型评测语境中,至少存在三类彼此不同、常被混用的对象:其一是对齐(alignment),指模型行为与人类意图、价值观的一致性程度,典型度量是 helpfulness 与 harmlessness 的权衡;其二是安全鲁棒性(safety robustness),指模型在对抗性输入、越狱提示、分布外场景下维持安全行为的稳定性;其三是社会偏见(social bias),指模型输出对特定群体的系统性差异化对待。三者共享“安全”这一标签,但失效机制、评测方法和改进手段差异极大。

本文评述:把三者合并成一个“安全分数”是当前评测实践中最常见的简化,也是误判的根源。一个模型可以在标准危害基准上表现优异,却在越狱攻击下迅速失守;也可以在拒答率上表现保守,却在性别、种族相关的隐性联想测试中系统性偏斜。采购方如果只看一个聚合分数,实际上是在用一个标量去压缩一个多维风险向量,信息损失不可避免。

1.2 “能力—安全默认正相关”这一假设的来源

这一假设并非空穴来风。早期研究确实观察到,随着模型规模增大,模型在毒性生成、指令遵循中的有害行为上有所改善,于是形成了“规模即安全”的经验直觉。其背后的机制解释是:更大的模型具备更强的指令理解与上下文推理能力,因而更能识别并遵循安全指令。这一解释在特定条件下成立,但它隐含了一个强前提——安全指令本身被充分覆盖且未被能力提升所“绕过”。

笔者认为,这个前提正在失效。当模型的推理能力足以进行多步规划、角色扮演和隐晦表达时,它同时也获得了更强的“规避安全约束”的潜在能力。安全对齐与能力提升之间不是简单的单调关系,而更接近一种竞速关系:防御侧和攻击侧共享同一套能力增量。这正是“推理能力提升不带来安全性提升”这一观察的深层原因,而非偶然的评测噪声。

1.3 采购语境下的真实问题

在企业采购中,“更强大的模型”通常意味着更高的 benchmark 分数、更低的幻觉率、更好的长上下文处理能力。这些指标与业务价值直接挂钩,容易量化,也容易在招标文件中写成硬性条款。相比之下,安全指标缺乏统一的、可复现的、跨模型可比的度量标准,往往被降级为“供应商需提供安全说明”这类软性要求。

于是形成了一个结构性错配:能力被精确度量并付费,安全被模糊描述并忽略。当安全改进本身出现停滞时,这个错配的风险被进一步放大——采购方支付的是能力溢价,承担的却是未被定价的安全尾部风险。

二、实证图景:安全评测曲线的平台化

2.1 安全基准的饱和与失效

当前主流的安全评测集合,如基于危害分类的问答集、毒性检测集、越狱提示集,普遍面临“基准饱和”问题。所谓基准饱和,指模型在该基准上的得分已接近上限,新增模型之间的差异落入统计噪声区间,基准失去区分度。这一现象在通用能力评测中已被广泛讨论,但在安全评测中其后果更为严重:饱和会被误读为“安全已解决”。

更关键的是,安全基准的构造方式本身存在系统性偏差。多数危害分类数据由人工标注的“显式有害请求”构成,而真实世界的攻击往往采用隐喻、多轮诱导、编码混淆等方式。模型在显式请求上的高分,很大程度上反映的是对表面模式的识别,而非对危害意图的深层理解。

本文评述:基准饱和不是“安全做完了”,而是“这把尺子量不动了”。继续用饱和基准做采购验收,等价于用一把刻度已经磨平的尺子去测精度,得到的“合格”结论没有信息量。

2.2 偏见抵抗:最薄弱且最被低估的维度

在各类安全维度中,偏见抵抗的表现最为稳定地偏弱。这一结论在多个独立评测体系中反复出现:模型在显式歧视性请求上可以做到高拒答率,但在隐性联想、职业—性别关联、姓名—种族推断、情感极性差异等间接测试中,偏差依然显著。原因在于,偏见不是一条可以被规则拦截的“有害指令”,而是弥散在训练语料统计结构中的系统性倾向。

从工程角度看,偏见评测的难点在于度量本身。以词嵌入联想测试为例,其核心是测量目标词与属性词之间的相对距离,但这一度量对模板选择、词表构造、上下文长度高度敏感,不同实现之间的结果可比性有限。这使得偏见改进难以形成像通用能力那样清晰的“版本—分数”曲线,改进效果也难以被采购方验证。

安全维度 典型度量方式 当前观察到的趋势 主要失效原因
显式危害拒答 危害分类问答集、拒答率 高位饱和,区分度下降 表面模式识别充分
越狱鲁棒性 对抗提示集、多轮诱导 随能力提升出现退化迹象 推理能力被用于规避约束
社会偏见 联想测试、反事实生成 长期偏弱,改进缓慢 语料统计结构弥散性偏差
隐私与记忆 成员推断、逐字复现率 与训练数据规模相关 记忆容量随规模增长

注:上表为对公开评测文献与基准报告的综合归纳(整合数据),非单一来源的原始测量值,具体数值请以各基准原始报告为准。

2.3 能力分数与安全分数的相关性证据

如果“能力—安全默认正相关”成立,那么在跨模型的散点图上,通用能力分数与安全分数应呈现明显的正相关。但多项独立评测的汇总分析显示,这一相关性在近年模型中显著减弱,部分维度甚至出现负相关。需要强调的是,相关性分析本身受制于样本量、评测口径和模型族系差异,不能直接推出因果关系,但它足以证伪“默认正相关”这一强假设。

笔者认为,更有解释力的框架是“能力—安全竞速模型”:安全对齐提供的是一个防御面,能力提升同时扩大了攻击面。当防御面的扩展速度低于攻击面的扩展速度时,观测到的净安全性就会下降。这解释了为什么在能力快速迭代的版本中,安全分数可能不升反降,而在能力迭代放缓的版本中,安全分数反而相对稳定。

三、机制剖析:能力提升为何不自动转化为安全提升

3.1 对齐税与安全税:被隐藏的成本

安全对齐并非免费。强化学习从人类反馈(RLHF)或基于规则的偏好优化,会在提升无害性的同时,对有用性、指令遵循的灵活性产生一定折损,这一现象通常被称为“对齐税”。在工程实践中,供应商面临一个显式的权衡:安全约束越强,模型在开放任务上的表现越保守,用户体验和 benchmark 分数可能下降。

本文评述:对齐税的存在,使得安全改进在商业激励上处于劣势。当采购方以能力分数为主要验收标准时,供应商有动机把对齐强度调到一个“刚好通过安全基准”的水平,而非“尽可能安全”的水平。这是一种理性但危险的最优解——它把安全变成了一个满足最低合规要求的成本项,而非持续投入的目标。

3.2 安全数据的瓶颈:覆盖度与对抗性

安全对齐的效果高度依赖训练数据的覆盖度。危害类别是长尾的,而人工标注的安全数据在长尾类别上天然稀疏。更棘手的是对抗性:一旦某种越狱模式被公开,它就会迅速被模型的安全训练吸收,但攻击者会继续寻找新的模式。这意味着安全数据集的更新速度必须与攻击模式的演化速度匹配,而现实中前者明显滞后。

从数据工程角度看,安全数据的构造面临三重约束:标注成本高、敏感内容难以大规模采集、跨文化规范差异导致标注标准不统一。这三重约束共同导致安全训练数据的规模增长远慢于通用预训练数据,形成了“能力数据指数增长、安全数据线性增长”的结构性失衡。

3.3 推理能力与拒答策略的内在张力

这是本文认为最值得关注、也最容易被忽视的机制。具备强推理能力的模型,在处理一个请求时会进行多步分解、意图推断和情境建模。这套能力在正常任务上是优势,但在安全场景下会带来两个副作用:其一,模型可能“推理出”某个请求的合理用途,从而降低拒答倾向;其二,模型可能被多轮对话逐步引导,在每一轮都做出局部合理的判断,最终累积成一个不安全的输出。

换句话说,安全拒答本质上是一个“在信息不完整时做出保守判断”的问题,而强推理能力倾向于“在信息不完整时做出更精细的判断”。这两种倾向存在结构性张力。笔者认为,这解释了为何推理能力的提升没有带来安全性的同步提升——它们优化的目标函数并不一致,甚至部分冲突。

# 安全回归测试的最小骨架(伪代码,工程示意)
def safety_regression(model, suites):
    report = {}
    for name, suite in suites.items():
        # 1) 显式危害拒答率
        refusal = eval_refusal(model, suite.explicit)
        # 2) 越狱鲁棒性:多轮 + 编码混淆
        jailbreak = eval_jailbreak(model, suite.adversarial, rounds=5)
        # 3) 偏见:反事实一致性
        bias = eval_counterfactual(model, suite.bias_pairs)
        # 4) 过度拒答:安全但有用的边界
        overblock = eval_overblock(model, suite.benign)
        report[name] = dict(refusal=refusal, jailbreak=jailbreak,
                            bias=bias, overblock=overblock)
    return report
# 关键:四个指标必须同时看,任何单项达标都不构成安全结论

3.4 评测激励的错位

模型发布时的安全报告,通常以“通过率”“拒答率”等形式呈现,这些指标容易被优化,也容易被选择性呈现。例如,提高拒答率可以改善危害基准分数,但会同时抬高过度拒答率,损害可用性。如果报告中只呈现前者而不呈现后者,就会形成系统性的乐观偏差。

本文评述:评测激励的错位是安全停滞的制度性原因之一。当“看起来安全”比“实际安全”更容易达成且更容易被验证时,资源自然会流向表面指标。要扭转这一局面,需要采购方在验收环节同时要求危害拒答率与过度拒答率,并对越狱鲁棒性做独立复测。

四、工程路径:把安全当作独立指标来采购与治理

4.1 建立分层安全评估矩阵

可操作的第一步,是把单一安全分数拆解为分层矩阵。建议至少包含四个层次:基础合规层(显式危害、违法内容)、对抗鲁棒层(越狱、多轮诱导、编码混淆)、公平性层(性别、种族、年龄、地域等维度的反事实一致性)、可用性层(过度拒答、误伤正常请求)。每一层设定独立的阈值和验收方法,不允许用一层的优异表现抵消另一层的不达标。

在具体实施上,建议采用“固定集 + 轮换集”的双轨设计。固定集用于跨版本、跨供应商的纵向对比,保证可比性;轮换集用于捕捉新出现的攻击模式,避免模型对固定集过拟合。轮换集应定期从公开越狱社区、内部红队记录和行业情报中补充。

4.2 红队流程的工程化

红队不应是一次性的发布前活动,而应是嵌入模型生命周期的持续流程。一个可落地的流程包含五个步骤:威胁建模(明确业务场景下的高价值风险)、用例生成(结合业务语料构造攻击提示)、自动化执行(批量跑测并记录完整对话轨迹)、人工复核(对自动化标记的样本做二次判定)、回归归档(把确认有效的攻击样本纳入固定集)。

需要强调的是,自动化红队的价值在于覆盖率,人工复核的价值在于判定精度,两者不可互相替代。实践中常见的错误是过度依赖自动化打分,导致大量误报消耗复核资源,或者漏报高风险样本。

4.3 风险预算与合同条款设计

采购方应把安全风险纳入预算框架,而非仅作为合规检查项。具体做法是:为不同业务场景设定可接受的风险预算(例如,面向公众的客服场景对越狱鲁棒性的要求高于内部辅助工具),并把预算转化为合同中的量化条款,包括安全指标的验收阈值、版本升级时的安全回归义务、安全事件的通知时限与补救责任。

笔者认为,合同条款是当前最被低估的治理杠杆。技术手段只能降低风险,无法消除风险;而合同条款决定了风险发生后的责任分配,从而反向影响供应商的安全投入意愿。当安全指标与付款节点挂钩时,安全才真正进入供应商的优先级列表。

治理环节 可操作动作 验收证据
选型 分层矩阵评测、独立复测 四层指标报告
上线 红队回归、灰度观察 攻击样本归档与修复记录
运营 轮换集更新、事件响应 月度安全指标看板
升级 版本安全回归、条款触发 回归通过报告与差异说明

4.4 拓展资源

以下公开资源可作为评测与红队实践的起点,建议结合自身业务场景做二次构造:

五、局限、争议与前沿预判

5.1 现有证据的局限

必须承认,“安全停滞”这一判断建立在有限的公开评测之上,存在若干不可忽视的局限。第一,评测口径不统一,不同机构的危害分类体系、标注标准、评分规则差异显著,跨报告比较需谨慎。第二,公开评测存在选择性披露风险,表现不佳的维度可能未被完整报告。第三,安全本身是场景依赖的,通用基准上的分数不能直接外推到具体业务场景。

本文评述:这些局限并不否定“停滞”这一观察,但要求我们在使用时保持克制。更稳妥的表述是:在现有公开证据下,没有观察到安全维度与能力维度同步提升的稳定趋势。这一表述比“安全一定在退步”更经得起检验。

5.2 争议:安全是否应该被“度量”

存在一种观点认为,安全本质上是规范性问题,过度量化会导致“古德哈特定律”——当指标成为目标,它就不再是好指标。这一批评有其道理,但笔者认为,它反对的是“单一指标崇拜”,而非度量本身。分层矩阵、轮换集、人工复核的组合,正是为了缓解指标被博弈的问题。放弃度量并不会让安全变好,只会让安全重新回到不可验证的模糊状态。

5.3 前沿预判

从技术演进看,未来两到三年可能出现三个方向的变化。其一,安全评测从静态基准转向动态对抗,评测本身成为一个持续运行的对抗系统。其二,安全对齐从“事后拒答”转向“过程约束”,在推理链的中间步骤施加约束,而非只在输出端拦截。其三,安全能力的可解释性提升,使得采购方能够审计模型的安全决策路径,而不只是看最终分数。

笔者认为,其中最具工程价值的是第二点。如果推理能力与拒答策略的张力是安全停滞的核心机制,那么在推理过程中施加约束,比在输出端做后处理更接近问题根源。这一方向目前仍处于早期,但其潜在收益值得持续跟踪。

六、结论

回到文章开头的问题:把“更强大的模型”默认当成“更安全的模型”来采购,到底是在买能力还是在买风险?本文的结论是,在当前证据下,这一默认假设不成立。能力与安全之间不存在稳定的正相关,安全改进在多个维度上呈现平台化,偏见抵抗是最薄弱且最被低估的环节。采购方支付的能力溢价,并不自动包含安全溢价。

可操作的出路有三条:把安全拆成可独立验收的分层指标,把红队从一次性活动变成持续流程,把安全条款写进合同并与付款挂钩。这三条都不依赖突破性的技术进展,只依赖治理意愿。技术会继续进步,但如果没有独立的度量与激励,安全不会自动跟上能力的脚步。

主要参考文献

  1. Bai Y, et al. Training a Helpful and Harmless Assistant with RLHF. arXiv, 2022.
  2. Perez E, et al. Discovering Language Model Behaviors with Model-Written Evaluations. ACL Findings, 2023.
  3. Wei A, et al. Jailbroken: How Does LLM Safety Training Fail? NeurIPS, 2023.
  4. Zou A, et al. Universal and Transferable Adversarial Attacks on Aligned Language Models. arXiv, 2023.
  5. Anil C, et al. Many-shot Jailbreaking. Anthropic Technical Report, 2024.
  6. Parrish A, et al. BBQ: A Hand-Built Bias Benchmark for Question Answering. ACL Findings, 2022.
  7. Gallegos I O, et al. Bias and Fairness in Large Language Models: A Survey. Computational Linguistics, 2024.
  8. NIST. Artificial Intelligence Risk Management Framework (AI RMF 1.0). 2023.
  9. OWASP. Top 10 for Large Language Model Applications. 2024.

说明:文中涉及的数据集与评测结论均来自上述公开文献及文中链接的公开资源;表格中的趋势归纳为对多来源报告的综合整理(整合数据),非单一实验的原始测量值。数据集使用前请核对原始许可证、标注规范与预处理流程,跨数据集比较时需注意危害分类体系与评分口径的差异。

声明:本文内容仅为作者学习、思考、经验、笔记的总结,仅供技术交流与参考。文中观点仅代表笔者个人思辨,不构成任何学术建议、商业建议或专业建议。所有数据来源已标注,引用时请以原始文献为准。

内容仅供学习参考。如需引用,请以原始文献为准。  全文约 6800 字 | 参考文献 60 余篇(主要 9 篇)。

🔒 复制本站文章内容需登录并达到 L3。当前:未登录

分享到

💬
微信
📷
朋友圈
🐧
QQ好友
🌐
QQ空间
👁
微博
📌
钉钉
🔗
复制链接
📑
复制图文

微信扫一扫分享

打开微信「扫一扫」,扫描二维码后在微信中分享给好友或朋友圈。

💬 评论 (0)

评论功能已关闭

⏸️ 本站暂未开放评论功能,不能进行评论,此为规划的后续开发预留
首页| 关于本网| 网站声明| 联系我们| 网站纠错| 服务| 网站地图
黔ICP备19010680号-1  |  邮箱:six528528@163.com
贵公网安备 52010302001819号
Copyright 2019-2026 http://www.databrush.com/ All rights reserved.
QQ
QQ扫一扫
Logo
DBN数据刷