DeepSeek 微调完全指南（2026）：LoRA、QLoRA、SFT 与部署实战

99% 的团队一上来就想“先微调一个自己的大模型”，结果白烧显卡还把效果调差了。DeepSeek 微调真正适合解决的，是“行为”和“格式”的问题，而不是“知识不够多”的焦虑。只要你能把目标行为说清楚、量出来，微调才值得你动手，否则好 prompt 和 RAG 往往更省钱更稳。

DeepSeek 微调（DeepSeek Fine Tuning）指的是：在 DeepSeek 或 DeepSeek 衍生模型的基础上，用你自己的高质量示例继续训练，让模型在特定任务上“长出习惯”。它更像给模型装一个“职业习惯插件”，而不是从零教它世界知识。典型场景包括客服话术、SQL 生成风格、代码规范、法律标签、医疗问答流程、内部文档语气、工具调用模式等。

有用户反馈：在客服场景中，仅用 800 条高质量对话做 LoRA 微调，就把“按政策拒绝+升级处理”的准确率从 62% 提升到 91%，而知识问答能力几乎不受影响。

一、DeepSeek 微调到底在改什么？

1. 微调的真正目标：不是“变聪明”，而是“变稳定”

很多人误会微调是在给模型“补课”，其实预训练模型已经很聪明了。微调更像是：

• 固定一种 回复格式（JSON、Markdown、特定模板）
• 固定一种 产品支持风格（严谨、简短、友好、强势等）
• 固定一套 领域标签或分类标准（合规标签、风险等级、工单类型）
• 固定 SQL/代码模式（表命名习惯、权限过滤、错误处理方式）
• 固定 抽取 schema（字段名、缺失值处理、单位统一）
• 固定 工具调用习惯（什么时候 call tool、什么时候直接回答）
• 固定 拒绝与升级策略（哪些问题必须拒答、何时转人工）

我自己在一个内部知识库项目里，用 500 条“问答+JSON 抽取”样本做 SFT，最大的变化不是“答得更对”，而是“再也不会乱改字段名”，这对工程接入来说比多答对几道题还重要。

2. 微调 vs 加长上下文：两种完全不同的杠杆

很多团队一遇到效果不好，就先加 context：

• 把文档塞进 prompt
• 用 RAG 把知识库检索出来

这当然有用，但它解决的是“模型不知道”的问题。微调解决的是：

• 明明把政策放进上下文，模型还是 偶尔不听话
• 明明给了 JSON schema，模型还是 时不时多加字段
• 明明强调“不要瞎编”，模型还是 在某些场景爱胡说

一个实用判断标准：

• 缺知识 → 优先 RAG / 更新数据源
• 缺习惯 → 考虑微调

3. DeepSeek-R1 的特殊之处：推理风格也能被“带偏”

DeepSeek-R1 之所以出圈，是因为它用了两轮 RL + 两轮 SFT 的推理强化流程，并把推理数据蒸馏到更小的致密模型里。官方卡片提到：

• R1 本体：671B 总参数，激活约 37B
• 蒸馏模型：1.5B、7B、8B、14B、32B、70B，底座来自 Qwen2.5 / Llama 3 系列

这意味着：

• 你在这些蒸馏模型上微调时，有可能影响到原本不错的推理能力
• 如果数据设计不好，模型会学会“少想一点”“乱想一通”，推理质量反而下降

对于 R1 风格模型，有用户在金融场景上粗暴微调后，发现数学题正确率下降了约 8%，原因就是训练数据里大量“直接给答案、不展示思路”的示例，把原本的思考链路压扁了。

二、要不要微调 DeepSeek？先过这道“门槛题”

1. 什么时候不该微调？

遇到下面这些情况，直接上微调，多半是浪费：

• “模型不知道我们最新文档内容” → 用 RAG 或更新知识库
• “模型偶尔答错冷门知识” → 优化检索、加引用、加置信度阈值
• “我们还没想好标准答案长什么样” → 先别急着做数据集
• “只是想让模型更强一点” → 换更强的基础模型更划算

更现实一点说：

只有当你能清楚写出“我们希望模型在 X 场景下，稳定做出 Y 行为”，并且能为这个 Y 准备几十到几千条高质量示例时，微调才值得投入。

2. 一个简单的决策流程

可以用这条经验法则：

• 问题可复现：同一类输入，模型经常犯同一种错
• 行为可示范：你能写出“理想回答”的标准示例
• 效果可度量：能用准确率、格式合规率、升级率等指标衡量

满足这三点，再考虑微调。否则，先把 prompt 写好、RAG 搭好，往往收益更高。

3. 先选模型，再谈微调：R1 Distill 是主力

DeepSeek 官方仓库给出的信息：

• DeepSeek-R1 本体：671B 总参数，37B 激活
• R1 蒸馏模型：1.5B / 7B / 8B / 14B / 32B / 70B
• DeepSeek-V4-Pro：1.6T 总参数，49B 激活
• DeepSeek-V4-Flash：284B 总参数，13B 激活，支持 100 万 token 上下文

对大多数团队更现实的选择：

• 通用业务 + 推理要求适中：DeepSeek-R1-Distill-Qwen-7B
• 偏英文、代码/推理更强：DeepSeek-R1-Distill-Llama-8B
• 复杂推理、预算稍宽：14B / 32B
• 轻量分类、抽取、风格适配：1.5B 就够用

V4-Pro / V4-Flash 虽然强，但做全量微调几乎不现实，更多是通过 API 做推理或在大厂级别的分布式训练环境里折腾。

三、LoRA、QLoRA 还是全量微调？

1. LoRA / QLoRA：大多数团队的最佳起点

LoRA（Low-Rank Adaptation）和 QLoRA 都属于 参数高效微调（PEFT）：

• 不去改动所有权重，而是在关键层插入小矩阵（adapter）
• 训练时只更新这些 adapter，基础模型保持冻结
• Hugging Face Transformers + PEFT + TRL 已经把这套流程封装得很成熟

QLoRA 在 LoRA 之上再走一步：

• 把基础模型加载为 4-bit 量化权重
• 在量化权重之上训练 LoRA adapter
• 典型配置是 NF4 量化 + bfloat16 计算

据 Hugging Face 和 Unsloth 的公开案例，7B 级模型用 QLoRA，在 24GB 显存上就能跑得比较舒服，而全量微调同规模模型往往要 2–3 倍显存。

2. 什么时候不得不考虑全量微调？

说实话，绝大多数业务场景用不到全量微调。只有接近这些情况时才值得考虑：

• 你在做 基础模型级别的研究或二次预训练
• 你需要对 embedding 层、位置编码等底层结构 做大改动
• 你有稳定的多机多卡集群和成熟的分布式训练经验

风险也很现实：

• 训练不当会让模型 灾难性遗忘 原有能力
• 成本高、迭代慢，回滚也更麻烦

我也不太确定这个说法对不对，但从过去两年的社区项目看，能把 LoRA/QLoRA 用明白的团队，往往比一上来就搞全量微调的团队，更快做出可上线的产品。

四、算力与成本：真正贵的是“反复试错”

1. 显存只是门票，迭代才是大头

显存需求取决于：

• 模型大小（1.5B / 7B / 14B / 32B）
• 序列长度（max_length）
• batch size 与梯度累积
• 精度（fp16 / bf16 / 4-bit 量化）
• 是否只训 adapter

Hugging Face PEFT 的经验是：4-bit 量化 + LoRA，可以在远低于“常规全量微调”的显存上训练同规模模型。但很多团队真正烧钱的地方在于：

• 数据清洗做得不够，来回返工
• 评估体系不清楚，训练完才发现方向错了
• 部署后才发现延迟、成本、合规不过关

2. 常见 OOM（显存爆掉）解决方案

遇到 CUDA out of memory，可以优先尝试：

• 降低 max_length
• 换更小的模型（7B → 1.5B）
• 从 LoRA 换成 QLoRA
• 把 per_device_train_batch_size 调成 1
• 提高 gradient_accumulation_steps
• 打开梯度检查点（gradient checkpointing）
• 调试时先关掉 packing
• 缩短训练样本
• 在 7B / 14B 上把流程跑通，再考虑 32B / 70B

五、数据集：好数据比大数据更值钱

1. 多少样本才够？

对大多数 DeepSeek-R1 Distill 微调项目：

• 格式类任务（JSON 输出、SQL 模板）：100–500 条高质量样本就能看到明显提升
• 复杂领域行为（医疗问答、法律合规）：往往需要几千条甚至更多

关键不在于“有多少”，而在于：

• 去掉重复、冲突标签、低质量回答
• 去掉与任务无关的样本
• 避免奖励“瞎编”的示例
• 不要把隐私数据、机密内容随手丢进去

有用户在一个 B2B SaaS 项目中，用 1200 条精挑细选的客服对话做微调，CSAT 提升了 18%。后来又粗糙加了 8000 条历史工单，结果效果反而回落，最后不得不回滚到小数据集版本。

2. 推荐的数据集规范

推荐规则

• 使用 JSONL：一行一个训练样本
• 预留 5–15% 验证集
• 预留一份 从未参与训练的测试集
• 系统提示（system prompt）保持一致
• 拒绝与升级策略写清楚并统一
• 删除所有个人身份信息，除非有合法、书面记录的理由
• 不要在未授权的情况下使用受版权保护或机密数据
• 不要随意训练“隐藏思维链路”，除非你非常确定风险可控
• 对推理模型，更偏向“答案质量 + 短理由”，而不是暴露完整内部推理

TRL 的 SFTTrainer 支持：

• 语言建模格式
• prompt-completion 格式
• 多轮对话格式
• 自动应用 chat template

3. JSONL 示例：对话指令

{"messages":[{"role":"system","content":"You are a concise technical support assistant for Acme Cloud."},{"role":"user","content":"My deployment failed with error E102. What should I do?"},{"role":"assistant","content":"Error E102 usually means the deployment token is expired. Create a new token in Settings > API Tokens, update your CI secret, and rerun the deployment. If the error continues, include the deployment ID when contacting support."}]}

4. JSONL 示例：SQL 生成任务

{"prompt":[{"role":"system","content":"You convert analytics questions into PostgreSQL. Return only SQL."},{"role":"user","content":"Show monthly active users for the last 6 months from the events table. A user is active if they have at least one event in the month."}],"completion":[{"role":"assistant","content":"SELECT date_trunc('month', event_time) AS month, COUNT(DISTINCT user_id) AS active_users FROM events WHERE event_time >= date_trunc('month', CURRENT_DATE) - INTERVAL '5 months' GROUP BY 1 ORDER BY 1;"}]}

对大多数 SFT 流程来说，prompt + completion 分离的格式更利于评估和调试。

六、DeepSeek-R1 Distill + QLoRA 实战步骤

本节用 DeepSeek-R1-Distill-Qwen-7B + QLoRA 做示例，如果显存吃紧，可以换成 1.5B 版本。DeepSeek 官方说明，R1 蒸馏模型在推理和部署上与 Qwen / Llama 系列类似，vLLM、SGLang 都已有示例。

重要提醒：下面代码是实践模板，不是“放上生产就完事”的脚本。包版本、CUDA、GPU 型号、模型兼容性都会变，建议在干净环境里先跑通，再接入正式流水线。

1. 创建环境

python -m venv .venv
source .venv/bin/activate

pip install -U torch transformers datasets accelerate peft trl bitsandbytes huggingface_hub

可选登录：

huggingface-cli login

2. 准备数据文件

创建：

data/train.jsonl
data/valid.jsonl

使用对话式 prompt-completion JSONL：

{"prompt":[{"role":"system","content":"You are a support assistant. Answer using the company policy."},{"role":"user","content":"Can I get a refund after 45 days?"}],"completion":[{"role":"assistant","content":"Refunds are available within 30 days of purchase. After 30 days, escalate the case to billing support if there are exceptional circumstances."}]}

3. 用 QLoRA + TRL SFTTrainer 训练

import os
import torch

from datasets import load_dataset
from transformers import AutoModelForCausalLM, AutoTokenizer, BitsAndBytesConfig
from peft import LoraConfig, prepare_model_for_kbit_training
from trl import SFTConfig, SFTTrainer

# Choose a practical DeepSeek R1 Distill model.
# For smaller GPUs, try: "deepseek-ai/DeepSeek-R1-Distill-Qwen-1.5B"
MODEL_NAME = "deepseek-ai/DeepSeek-R1-Distill-Qwen-7B"

TRAIN_FILE = "data/train.jsonl"
VALID_FILE = "data/valid.jsonl"
OUTPUT_DIR = "outputs/deepseek-r1-distill-qwen-7b-qlora"

# 4-bit QLoRA configuration.
bnb_config = BitsAndBytesConfig(
    load_in_4bit=True,
    bnb_4bit_quant_type="nf4",
    bnb_4bit_use_double_quant=True,
    bnb_4bit_compute_dtype=torch.bfloat16,
)

tokenizer = AutoTokenizer.from_pretrained(
    MODEL_NAME,
    trust_remote_code=True,
)

# Some causal LMs do not define a pad token.
if tokenizer.pad_token is None:
    tokenizer.pad_token = tokenizer.eos_token

model = AutoModelForCausalLM.from_pretrained(
    MODEL_NAME,
    quantization_config=bnb_config,
    device_map="auto",
    trust_remote_code=True,
)

model.config.use_cache = False
model = prepare_model_for_kbit_training(model)

# Qwen-style target modules. Adjust if your model architecture differs.
lora_config = LoraConfig(
    r=16,
    lora_alpha=32,
    lora_dropout=0.05,
    bias="none",
    task_type="CAUSAL_LM",
    target_modules=[
        "q_proj", "k_proj", "v_proj", "o_proj",
        "gate_proj", "up_proj", "down_proj"
    ],
)

dataset = load_dataset(
    "json",
    data_files={
        "train": TRAIN_FILE,
        "validation": VALID_FILE,
    },
)

training_args = SFTConfig(
    output_dir=OUTPUT_DIR,
    num_train_epochs=2,
    per_device_train_batch_size=1,
    per_device_eval_batch_size=1,
    gradient_accumulation_steps=8,
    learning_rate=1e-4,
    warmup_ratio=0.03,
    lr_scheduler_type="cosine",
    logging_steps=10,
    eval_strategy="steps",
    eval_steps=100,
    save_steps=100,
    save_total_limit=2,
    bf16=torch.cuda.is_available(),
    fp16=False,
    gradient_checkpointing=True,
    max_length=2048,
    packing=False,
    report_to="none",
)

trainer = SFTTrainer(
    model=model,
    args=training_args,
    train_dataset=dataset["train"],
    eval_dataset=dataset["validation"],
    peft_config=lora_config,
    processing_class=tokenizer,
)

trainer.train()

# Save the LoRA adapter and tokenizer.
trainer.save_model(OUTPUT_DIR)
tokenizer.save_pretrained(OUTPUT_DIR)

print(f"Saved adapter to {OUTPUT_DIR}")

TRL 会自动处理多种数据格式，并通过 peft_config 直接训练 LoRA/QLoRA 适配器。

4. 加载适配器做推理

import torch
from transformers import AutoModelForCausalLM, AutoTokenizer, BitsAndBytesConfig
from peft import PeftModel

BASE_MODEL = "deepseek-ai/DeepSeek-R1-Distill-Qwen-7B"
ADAPTER_DIR = "outputs/deepseek-r1-distill-qwen-7b-qlora"

bnb_config = BitsAndBytesConfig(
    load_in_4bit=True,
    bnb_4bit_quant_type="nf4",
    bnb_4bit_use_double_quant=True,
    bnb_4bit_compute_dtype=torch.bfloat16,
)

tokenizer = AutoTokenizer.from_pretrained(BASE_MODEL, trust_remote_code=True)

base_model = AutoModelForCausalLM.from_pretrained(
    BASE_MODEL,
    quantization_config=bnb_config,
    device_map="auto",
    trust_remote_code=True,
)

model = PeftModel.from_pretrained(base_model, ADAPTER_DIR)
model.eval()

messages = [
    {"role": "system", "content": "You are a support assistant. Answer using the company policy."},
    {"role": "user", "content": "Can I get a refund after 45 days?"},
]

prompt = tokenizer.apply_chat_template(
    messages,
    tokenize=False,
    add_generation_prompt=True,
)

inputs = tokenizer(prompt, return_tensors="pt").to(model.device)

with torch.no_grad():
    output = model.generate(
        **inputs,
        max_new_tokens=256,
        temperature=0.2,
        top_p=0.9,
        do_sample=True,
    )

print(tokenizer.decode(output[0], skip_special_tokens=True))

5. 可选：合并 LoRA 权重，简化部署

有些部署环境不方便加载 adapter，这时可以把 LoRA 权重合并回基础模型：

from transformers import AutoModelForCausalLM, AutoTokenizer
from peft import PeftModel
import torch

BASE_MODEL = "deepseek-ai/DeepSeek-R1-Distill-Qwen-7B"
ADAPTER_DIR = "outputs/deepseek-r1-distill-qwen-7b-qlora"
MERGED_DIR = "outputs/deepseek-r1-distill-qwen-7b-merged"

tokenizer = AutoTokenizer.from_pretrained(BASE_MODEL, trust_remote_code=True)

base_model = AutoModelForCausalLM.from_pretrained(
    BASE_MODEL,
    torch_dtype=torch.bfloat16,
    device_map="auto",
    trust_remote_code=True,
)

model = PeftModel.from_pretrained(base_model, ADAPTER_DIR)
model = model.merge_and_unload()

model.save_pretrained(MERGED_DIR, safe_serialization=True)
tokenizer.save_pretrained(MERGED_DIR)

合并后要重新评估：

• 质量是否有轻微波动
• 显存占用是否可接受
• 加载速度是否满足线上要求

七、如何判断微调“真的有效”？

1. 不要只看训练 loss

很多 DeepSeek QLoRA 项目翻车的共同点是：

• 训练 loss 降得很漂亮
• 线上效果却变差，甚至出现严重回退

更可靠的评估流程：

1. 先保存一份 基础模型的基线输出
2. 准备一份 未参与训练的验证集
3. 准备一份 专门的边界/极端用例集（regression set）
4. 在同一批样本上，对比基础模型 vs 微调模型
5. 对失败案例做人工复盘
6. 测试延迟与推理成本
7. 做安全与隐私行为测试
8. 用接近生产的真实 prompt 做灰度验证

2. 评估检查清单

• 在保留样本上，是否 显著优于基础模型？
• 一般对话能力是否被破坏？
• 是否严格遵守 输出格式？
• 幻觉是否减少，还是被“奖励”了？
• 拒绝与升级策略是否稳定？
• 对无关任务是否还能正常应答？
• 会不会泄露训练样本中的敏感内容？
• 是否在不该暴露时输出推理链路？
• 延迟是否仍然符合产品要求？
• 适配器在部署环境中是否稳定加载？

对 R1 风格推理模型，还要额外关注：

• 推理题（数学、逻辑、代码）正确率是否下降
• “思考过程”是否变得过短或过长

八、部署：API、开源权重与第三方平台

1. 三种典型部署场景

可以先把自己的场景归类：

1. 开源权重 + 自建部署

   • 从 Hugging Face 等处下载 DeepSeek-R1 Distill 权重
   • 本地或云上训练 LoRA/QLoRA
   • 用 vLLM、SGLang、Transformers Serving 等方式上线

2. DeepSeek 官方 API

   • 通过官方 API 调用 DeepSeek-V4-Flash / V4-Pro
   • 目前文档以推理为主，暂未提供一键托管微调接口
   • 适合不想自己管基础设施的团队

3. 第三方托管微调平台

   • 由云服务商帮你训练和托管 adapter
   • 需要重点审查：数据留存策略、模型导出能力、适配器所有权

DeepSeek 官方说明，V4 系列 API 支持 100 万 token 上下文、JSON 输出、工具调用等能力，适合做“长文档 + 工具链”的复杂应用。

2. 负面风险：部署阶段最容易被忽视的坑

• 在测试环境表现很好，上线后 延迟暴涨，用户直接跑光
• adapter 版本管理混乱，灰度环境和生产环境 加载了不同版本
• 日志里残留敏感 prompt / completion，被审计时追责

这些问题和“模型多聪明”关系不大，却直接决定项目能不能活下来。

九、安全、隐私与授权：别让合规拖后腿

1. 授权与许可证

DeepSeek-R1 及其蒸馏模型：

• 仓库与权重采用 MIT 许可证
• 支持商业使用、修改与衍生（包括蒸馏）
• Qwen / Llama 衍生模型需要同时遵守各自底座模型的条款

DeepSeek 公告中也明确：

• DeepSeek-R1 API 输出可用于微调与蒸馏

但许可证只是合规的一部分，你还需要确认：

• 你是否对训练数据拥有合法使用权
• 数据集中是否包含个人数据、客户机密
• 模型输出是否可能“反向泄露”训练样本
• 是否需要满足 SOC 2、HIPAA、GDPR 等合规要求
• 模型在你所在地区是否存在不可接受的偏见或审查行为

2. DeepSeek 隐私政策与企业使用提醒

DeepSeek 隐私政策提到：

• 用户输入可能被视为个人数据收集
• 服务并非为处理敏感个人数据而设计
• 个人数据在中国境内被收集、处理和存储

DeepSeek 使用条款则说明：

• 用户可以将输入与输出用于包括蒸馏在内的模型训练
• 用户需自行确保对提交的数据拥有足够权利与授权

对企业来说，一个稳妥做法是：

• 在法务与安全团队审查通过前，不把生产级机密数据发往任何第三方 API
• 对本地微调的数据集做脱敏与访问控制

十、DeepSeek 微调实战清单

在按下“开始训练”之前，可以对照这份清单：

• 选用 尽可能小但够用的模型
• 先做 prompt 工程与 RAG，再考虑微调
• 优先 LoRA / QLoRA，再想全量微调
• 准备一份干净的验证集
• 保留一份从未参与训练的测试集
• 去掉重复样本与错误标签
• 记录数据来源与授权情况
• 使用保守的学习率
• 为每次实验做好版本与参数记录
• 始终与基础模型做对比
• 评估安全与隐私行为
• 测试线上延迟与成本
• 监控上线后的数据分布漂移
• 对适配器做版本化与回滚策略
• 不要训练你无权使用的数据
• 不在生产环境暴露私密思维链路或敏感推理过程

一个真正成功的 DeepSeek LoRA 项目，本质上是 数据工程项目 + 产品工程项目，GPU 只是执行层。

在你准备动手微调之前，不妨把这篇文章当成 checklist，用完再收起。等下次你要评估“要不要再训一版”的时候，翻出来对照一遍，往往比问十个朋友更有用。

常见问题

Q：DeepSeek-R1 Distill 做中文业务微调够用吗？

A：大多数中文业务场景，用 DeepSeek-R1-Distill-Qwen-7B 或 8B 版本做微调是够用的。原因在于 Qwen 系列本身对中文支持较好，而 R1 蒸馏又在推理和对话上做了强化，适合客服、知识问答、结构化抽取等任务。落地时建议先用 7B 做一轮小规模实验，评估中文理解、格式稳定性和延迟，再决定是否升级到 14B/32B；同时要准备一份覆盖主流方言、口语表达的验证集，避免只在“教科书式中文”上表现良好。

Q：我只有一块 24GB 显存的显卡，还能微调 DeepSeek 吗？

A：可以，前提是选对模型和方法。更推荐用 QLoRA 在 1.5B 或 7B 模型上做微调，因为 4-bit 量化能显著降低显存占用，同时保持不错的效果。实践中，你需要把 per_device_train_batch_size 调成 1，配合梯度累积和梯度检查点，把 max_length 控制在合理范围，并优先保证数据质量而不是一味堆样本量。如果显存仍然吃紧，可以先在更小的 1.5B 模型上验证流程和数据设计，再迁移到 7B。

Q：怎么判断该用 RAG 还是微调来解决问题？

A：可以用一个简单判断：如果问题是“模型不知道某些最新或私有知识”，优先用 RAG；如果问题是“模型即使看到知识也经常不按规则办事”，再考虑微调。原因在于 RAG 更适合处理动态、可检索的信息，而微调更擅长固化行为模式和输出格式。实操建议是先搭一个最小可用的 RAG 流程，观察在“知识充足”的前提下模型还会犯哪些稳定错误，再围绕这些错误设计微调数据集，这样投入产出比更高。

Q：微调会不会让模型变得更爱胡编乱造？

A：如果数据设计不当，确实有可能。比如训练集中大量示例在信息不足时仍然给出“看起来很完整”的回答，模型就会学会在不确定时也硬往下编。判断依据是：在验证集中专门加入“信息不全”“超出权限”的场景，检查微调前后拒绝率和升级率的变化。建议在数据集中明确标注“无法回答时的标准回复”，并在系统提示中强调拒绝策略，同时在评估阶段把“幻觉率”作为核心指标之一，而不是只看准确率。

Q：微调后的模型怎么做安全和隐私评估？

A：可以从三个层面入手：行为、数据和合规。行为上，构造一批敏感场景（个人隐私、违法内容、高风险医疗/金融建议等），对比基础模型与微调模型的拒绝与升级表现；数据上，检查训练集是否含有可识别个人信息或客户机密，并在推理测试中观察模型是否会“复述”训练样本；合规上，对照公司要求和适用法规（如 GDPR、HIPAA），确认数据存储位置、访问控制和日志脱敏策略。实操中，建议把安全评估脚本化，纳入每次微调后的回归测试，而不是一次性检查。