Refuse without Refusal: Safety-Tuning 响应的结构分析以减少语言模型中的错误拒绝

TL;DR 将安全微调响应拆成拒绝模板与解释理由，发现仅用理由训练可减少误拒且不损安全，定位拒绝语句是模型依赖表面线索误判的关键诱因。

问题

问题背景

当前 LLM 安全对齐的核心目标是兼顾 帮助性 与 安全性，即在拒绝有害请求的同时，对良性输入保持正常响应。这一平衡在真实部署中愈发关键。

现有方法局限

主流安全调优通常构造包含 拒绝声明（如 I cannot...）和 拒绝理由 的完整监督响应。然而论文实验表明，拒绝声明会使模型过度依赖表面风险词（如 shoot、bomb），而非深层语义判断，导致对 Where can I shoot a good photo? 这类良性查询产生 误拒。现有方法缺少对安全响应结构的细粒度拆解，仅优化整体下一 token 损失，无法消除模板化拒绝带来的虚假相关信号。这与 Rationale-Only 等更精细的数据构建思路形成对比。

为什么这个问题难/重要

区分真正的有害意图与仅表面相似的良性表达，需要模型具备超出词汇共现的语义推理能力。训练数据中拒绝声明与高风险词的强共现，容易将模型诱导为“触发词检测器”。误拒直接损害用户体验和产品信任，在助手、代码、创作等场景中尤为突出。业界普遍关注在不降低安全性的前提下降低误拒率，这需要更精细的数据监督与训练策略，例如只对 拒绝理由 建模，避免让模型学习到“出现敏感词就输出拒绝模板”的捷径。

行业类比

就像智能客服不应因为用户提到“转账”就一律拒绝交流，而是需判断具体意图；类似地，安全对齐模型需要学会忽略表面敏感词，聚焦真实语义。

核心洞察

• 安全微调数据中的 boilerplate refusal statement 是造成 false refusal 的关键因素，剔除该部分、仅使用 rationale 进行训练可显著降低误拒率。传统安全对齐将拒绝模板与解释混合，使模型学到表面风险词与拒绝行为的强关联，而 rationale 提供语义判断依据，让模型聚焦于意图识别。与现有方法相比，多数工作通过扩充良性数据或推理时干预缓解误拒，但未分解响应内部结构；本文从数据构造粒度证明，精细拆分监督信号即可同时提升 helpfulness 与 safety，工程实现更直接。
• 该研究揭示了安全对齐中“拒绝行为”与“安全推理”的可分离性，为构建更精准的监督数据集提供了新方向。实验表明，仅用 rationale 训练在 in-context learning 配置和多种推理时缓解方法下均保持收益，说明该方法具有较强泛化性和兼容性。与依赖额外判别模型或复杂损失函数的工作不同，它只需调整数据标注方式，成本较低，但要求 rationale 标注具备高质量和一致性，对数据 pipeline 的设计提出新的工程挑战。

方法

方法详解

输入：安全调优数据集中的每个 response 被拆分为两个组件：

1. 拒绝声明（boilerplate refusal statement）：如 “I cannot help with that” 等固定句式，不解释原因；
2. 拒绝理由（rationale explaining refusal）：说明为何该查询有害、不能回答的具体分析。

关键模块：构造不同训练配置，分别使用完整 response、仅拒绝声明、仅拒绝理由进行监督微调（SFT）。评估指标包括误拒率（false refusal rate）与安全通过率（safety pass rate）。

分析与发现：仅用拒绝声明训练会放大模型对表面风险词的依赖，例如把 “shoot a photo” 中的 “shoot” 误判为暴力意图；仅用拒绝理由训练则迫使模型理解语义差异，显著降低误拒，同时保持可比的安全性能。该方法在 In-Context Learning（ICL）设置下同样有效，并且与推理时缓解方法（如 self-reflection）兼容。

输出：生成更细粒度的安全监督数据集，可用于微调对齐模型，改进 helpfulness 与 safety 的平衡。

原文强调：“rationale-only benefits also appear in our ICL configuration and remain compatible with evaluated inference-time mitigation methods.”

与同类方法的差异：多数对齐工作通过调整损失权重或加入更多完整拒绝样本缓解误拒；本文从 response 结构本身切入，移除拒绝声明、只保留理由，表明误拒并非归因于数据量，而是表面化拒绝模板的副作用。

实验

实验设计

将安全微调数据集中的每条响应拆解为 拒绝声明（boilerplate refusal statement）与 理由阐述（rationale）。训练两组模型：一组使用完整安全响应，另一组仅使用理由阐述。评估指标覆盖 误拒率 与 安全性能，并测试在 In-context Learning 及推理时缓解方法下的表现。

关键发现

仅用理由训练显著降低误拒，同时安全性能与完整响应训练相当。拒绝声明本身会诱导模型依赖“危险词”等表面线索，导致对良性查询误判。移除拒绝声明后模型更关注语义合理性。该结论在 ICL 配置下持续成立，且与主流推理时安全干预方法兼容。

与基线对比

与使用完整安全响应的标准基线相比，Rationale-Only 在不牺牲安全性的前提下明显减少误拒，说明精细分解监督信号可优化 helpfulness-safety 权衡。传统方法保留模板化拒绝语句可能强化表面模式匹配。该工作提示安全数据集构造应更细粒度，避免冗余表达带来的混淆偏置。

行业影响

落地场景

• 对话式 AI 客服：在电商、SaaS 产品支持中，用户常问及“如何删除账户”“如何杀死进程”等含敏感动词的问题，现有安全模型容易误拒。用 rationale-only 训练的安全模型能减少这类 false refusal，同时保持对真实有害请求（如“如何伤害他人”）的拒绝能力。
• 教育/内容平台：学生提问“如何制作烟雾弹”可能只是化学实验，安全护栏需区分真实危险意图与知识性询问。

商业价值

• 降低误拒率可提升用户完成率与留存：客服场景中减少无效兜底转人工，节省单次服务成本；内容平台减少误伤正常内容，提升创作者体验。
• 训练数据更精细，只需标注 rationale 而非固定拒绝模板，降低数据标注与模型过拟合风险；安全性能不下降，可减少额外安全审核层。

与现有产品/工作流的接口

• 直接改造安全微调数据集：将安全响应拆成 refusal_statement 与 rationale 两部分，仅用 rationale 进行 SFT/DPO，无需改变模型架构。
• 与推理时缓解方法（如 self-refine、安全提示词）兼容，可叠加部署；开源实现见 GitHub

局限

• **方法泛化性存疑**：论文主要针对安全微调数据集中的响应结构进行分解，实验集中在特定模型与评测基准上，未充分验证在不同模型架构（如从 decoder-only 扩展到 encoder-decoder）或不同安全对齐流程（如 RLHF、DPO）中的效果。若更换底层模型或安全训练范式，`rationale-only` 训练是否仍能保持同等安全性与低误拒率，仍需进一步实验。
• **安全性能评估可能不全面**：论文虽报告 rationale-only 训练在保持安全水平的同时降低 false refusal，但安全评测通常依赖固定测试集，难以覆盖对抗性越狱或分布外有害查询。缺少红队测试与 open-ended 安全审计，可能高估其实际防御能力。
• **与同类工作对比有限**：虽然提到与推理时缓解方法兼容，但在实验对比中未将 rationale-only 训练与更直接的数据过滤、拒答阈值调整或上下文学习方法进行系统性消融，难以证明该结构分解是降低误拒率的最优路径。