2025-12-28 01:55:59 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

文章总结： 本文阐述了利用SFT和LoRA微调Qwen3-4B构建安全大模型的实践。作者采用合成数据、真实日志及高价值Badcase混合训练，并通过Agent对抗测试验证效果。结果显示微调将模型攻击绕过率从88%显著降至20%。结论指出，构建稳定安全大模型的关键不在于单次微调，而在于持续积累Badcase和优化数据流水线。 综合评分： 88 文章分类： AI安全,安全建设,安全工具

cover_image

ai安全-SFT&真正稳定的安全大模型，靠的不是模型

原创

苏心斋|月金剑客

剑客古月的安全屋

2025年12月26日 14:55 浙江

ai安全-微调安全大模型

作者：yueji0j1anke

首发于公号：剑客古月的安全屋

字数：2781

阅读时间: 15min

声明：请勿利用文章内的相关技术从事非法测试，由于传播、利用此文所提供的信息而造成的任何直接或者间接的后果及损失，均由使用者本人负责，文章作者不为此承担任何责任。本文章内容纯属虚构，如遇巧合，纯属意外

前言
概述
环境
数积极准备
lora微调
微调效果
总结

0x00 前言

最近在业务中开始接触内容安全与大模型安全相关的问题，便想着像以前一样对大模型进行**安全领域的微调（SFT）**从而进行一些数据构造、数据打标等任务。从数据构建、指令设计，到模型行为约束和效果评估，踩了不少坑，也积累了一些比较有意思的经验。

回头一看，发现自己公众号里虽然写了不少 AI for Security / Security for AI 的内容，但**系统性地讲“安全大模型本身”**这一块却一直是空白的。于是在这里把这段探索过程完整梳理出来，也方便后续持续迭代和复盘。

0x01 概述

在大多数工业级应用场景中，相比从头训练或全参数微调，大模型的后训练（Post-training已经足以覆盖绝大多数业务需求。通过在基座模型之上进行定向能力注入，可以在成本、效率之间取得更好的平衡。

基于这一考虑，本文选择采用 监督式指令微调（SFT） 的方式对模型进行能力对齐，并在参数更新策略上使用 LoRA（Low-Rank Adaptation），以降低显存占用和训练成本。在硬件资源方面，实验环境使用 NVIDIA L20 GPU，能够满足中等规模模型的高效微调需求。

本次微调所选用的基准模型为 Qwen3-4B。该模型在通用指令遵循和对话能力上已经具备较好的基础，适合作为安全与内容理解能力增强的起点模型。在此基础上，通过 SFT + LoRA 的方式对特定任务进行定向优化，可以在不显著影响原有能力的前提下，实现快速、可控的能力增强。

0x02 环境准备

环境准备

conda create -n lora_sec python=3.12 -y
conda activate lora_sec

# 微调环境
pip install torch --index-url https://download.pytorch.org/whl/cu121
pip install transformers accelerate bitsandbytes peft datasets trl streamlit sentencepiece tensorboard --index https://pypi.mirrors.ustc.edu.cn/simple

模型下载

pip install modelscope --index https://pypi.mirrors.ustc.edu.cn/simple
modelscope download --model Qwen/Qwen3-4B &nbsp;--local_dir ./Qwen/

0x03 数据集准备

本次微调的数据集并非单一来源，而是通过 合成数据 + 网络优秀数据集 + Badcase/真实日志驱动 的方式逐步构建，并在过程中不断调整比例与分布，以保证模型既“学得到规则”，又“扛得住真实提问”。

3.1 数据来源

3.1.1 合成数据

合成数据主要由规则模板 + 人工 Prompt + 大模型辅助生成构成，用于快速覆盖能力边界。

这部分数据主要用来

1.构造安全相关的标准问答

2.覆盖稀有但关键的攻击 / 风险模式

demo

Q: 下面这段请求是否存在安全风险？()
A: 该请求包含典型的海绵攻击特征，可能导致GPU膨胀爆炸。

3.1.2 Badcase

Badcase 是本次数据构建中最关键的一环。

来源包括：

• 人工审核发现的误判
• 对抗 Prompt / 绕过样本
• 模型“自信但错误”的输出

这些样本通常数量不多，但信息密度极高。

原则只有一句话：

一个高质量 Badcase，价值远高于 100 条普通样本。

我把badcase分为难例和负例

难例：通常会绕过大模型检测的攻击

负例：被大模型误判的正常业务query

3.2 数据比例

数据不是“越多越好”，而是“结构是否合理”。

在多轮实验后，最终采用了类似以下的比例策略（经验值）：

| 数据类型 | 占比 | | — | — | | 合成数据 | 30% | | 公开数据集+真实日志 | 50% | | Badcase | 20% |

其中：

• 合成数据用于稳定模型基本能力
• 真实日志保证分布贴近线上
• Badcase 用于拉齐模型下限

对系统后续发展来说，难例+负例的比例会逐渐提高，后续需要搭配捞线上真实日志去进行一个持续的打标+复核+微调的自循环闭环

3.3 数据清洗

这是踩坑最多的一步。

出现了很多标签“看似正确，实则错误”，以及输出风格不一致的问题

最终所有数据统一为指令微调（SFT）格式：

{
&nbsp; "instruction": "请分析以下请求是否存在安全风险",
&nbsp; "input": "...",
&nbsp; "output": "该请求存在 XX 风险，原因是 ..."
}

并在训练时统一注入 system role：

你是一名大模型安全专家，精通各种网络安全知识

这样可以：

• 稳定模型角色
• 减少推理阶段 Prompt 成本
• 提升安全相关回答的一致性

同时需进行抽样人工复核

0x04 lora微调

整体流程非常简单：

• 基础模型：Qwen3-4B
• 微调方式：LoRA SFT
• 训练数据：前文构建的指令式安全数据

至于 LoRA 的具体超参数（r / alpha / dropout 等）：

这里我并没有刻意追求最优配置，更多是参考公开实现 + 工程经验做的经验型设置。

网上已经有大量成熟示例，这里就不重复贴完整训练代码了。

在训练完成后，模型目录中保存的其实只是 LoRA Adapter 权重，而不是一个完整模型

最后还需要将lora模块注入挂到原模型

model = PeftModel.from_pretrained(model, model_id=lora_path)
model = model.merge_and_unload()

0x05 微调效果评估

我主要从部署方式和实际对抗效果两个层面，来简单验证这次 LoRA 微调的价值

推理部署：直接上 vLLM

为了尽量贴近真实线上环境，我并没有用 transformers.generate() 做本地测试，而是直接选择了 vLLM 作为推理引擎。

原因也很简单：

• 推理速度快
• 显存利用率高
• 接口形态更接近真实服务

部署命令如下：

vllm serve lora/merged_Qwen/Qwen3-4B_lora \
&nbsp; --host 0.0.0.0 \
&nbsp; --port 8000 \
&nbsp; --dtype half \
&nbsp; --served-model-name Qwen3-4B-Lora

这里使用的是已经合并 LoRA 权重后的完整模型，部署形态与普通基础模型完全一致，避免了 Adapter 推理带来的额外复杂度。

对抗方式：Agent 驱动的绕过测试

效果评估部分，我并没有简单地手写几个 prompt 去试探模型，而是采用了一种更“真实”的方式：

通过 Agent 自动构造绕过大模型安全机制的提示词。

这类 Agent 的核心目标只有一个： 不断尝试绕过模型的安全边界，诱导其输出违规内容。

测试对象包括两组模型：

1. Qwen3Guard（未微调）
2. 经过 LoRA 安全指令微调的 Qwen3-4B

测试策略、攻击模板、调用方式完全一致，只对比模型本身的防御能力。

实际结果对比

最终结果非常直观

| 模型 | 绕过成功率 | | — | — | | Qwen3Guard | ≈ 88% | | 微调后的 Qwen3-4B | ≈ 20% |

这里的“成功率”，指的是 Agent 成功诱导模型输出违规或不安全内容的比例。

换句话说：

• 原始 Guard 模型在复杂组合攻击下，防御能力有限
• 基准模型经过针对性安全指令 SFT + LoRA 微调后，模型对绕过攻击的鲁棒性出现了显著提升

0x06 总结

最开始做这件事的时候，目标其实很朴素： 用微调后的大模型，去替代人工，完成一部分数据打标工作。

当时的判断也很直接：

• 通用大模型能力很强，但不可控（很多误判）
• 如果场景足够垂直（安全 / 攻防 / payload / 规则），那么 微调模型一定能用更小的参数量，覆盖我侧需求

于是第一阶段的路线非常“工程直觉”：

先把模型训出来 → 能跑 → 能打标 → 比通用大模型好用就行

但真正跑起来之后，问题才一个一个浮出水面。

不论是构造攻方agent产出的prompt的不断演进，还是层出不穷的新变种、新绕过方式，都在狠狠告诉我（真实的大模型业务也会存在各种tool调用无效、幻觉产出、不可信、回答无关等问题）

-> 他喵的根本不知道模型什么时候开始不可靠，需要按照业务算法那边的标准流程不断的收集 badcase（人工+通用大模型）去进行修正，以及badcase的收集是一个非常耗时的任务。

那微调模型的意义在哪里呢？对我来说，数据打标标注，后续可以作为奖励信号源，对一些业务来说，价值可能体现在流水线上–延迟降低，幻觉减少

最后想说的是：真正稳定的大模型系统，靠的从来不是一次“调得很好的模型”，而是大量真实标注数据 + 持续运转的 badcase 优化流水线。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：剑客古月的安全屋苏心斋|月金剑客《ai安全-SFT&真正稳定的安全大模型，靠的不是模型》