大模型调优¶

大模型调优是让一个已有模型更适合你的业务场景。核心是“改模型行为”。

大模型调优可以分成几层，从轻到重是：

Prompt Engineering
    ↓
RAG / 工具增强
    ↓
SFT 监督微调
    ↓
偏好优化 DPO / RLHF / ORPO
    ↓
继续预训练 CPT
    ↓
全参数微调 Full Fine-tuning

很多业务场景，RAG + Prompt + 少量 SFT 就够了。全参数微调通常不是中小团队的第一选择。

大模型调优的几种主流方式¶

Prompt 调优¶

这是最轻量的方式，不改模型参数，只改输入。适合：

• 格式约束
• 角色设定
• 输出风格
• 简单业务规则
• 工具调用说明

例如：

你是企业知识库问答助手。
回答必须基于提供的上下文。
如果上下文中没有答案，回答“不知道”，不要编造。

优点：

• 成本低
• 上线快
• 不需要训练
• 可快速迭代

缺点：

• 稳定性有限
• 复杂行为难以保证
• 上下文变长后容易失控
• 不能真正改变模型能力边界

RAG 调优¶

RAG 本质上不是微调模型，而是给模型外接知识库。流程是：

文档采集
  ↓
清洗
  ↓
切分 chunk
  ↓
向量化 embedding
  ↓
写入向量库
  ↓
用户提问
  ↓
检索相关 chunk
  ↓
rerank 重排
  ↓
拼接 prompt
  ↓
LLM 生成答案

适合：

• 企业知识库问答
• 制度问答
• 技术文档问答
• 客服知识库
• 产品手册问答
• 内部 SOP 查询

RAG 解决的是：

• 模型不知道你的私有知识
• 模型知识过期
• 需要可追溯引用
• 不希望频繁重新训练

RAG 不擅长解决：

• 模型不会某种复杂推理
• 模型输出风格总是不符合要求
• 模型需要掌握一种固定业务流程
• 模型需要稳定执行结构化任务

SFT：监督微调¶

SFT，全称 Supervised Fine-Tuning，监督微调。

它的本质是给模型大量标准输入输出样本，让模型学习：

看到这种输入，就应该输出这种答案

典型数据格式：

{
  "messages": [
    {
      "role": "system",
      "content": "你是一个企业知识库问答助手。"
    },
    {
      "role": "user",
      "content": "公司报销流程是什么？"
    },
    {
      "role": "assistant",
      "content": "公司报销流程分为：提交申请、主管审批、财务复核、打款。"
    }
  ]
}

SFT 适合：

• 固定输出格式
• 固定业务流程
• 特定领域问答
• 风格角色扮演
• 代码生成风格
• 客服话术
• Agent 工具调用格式

SFT 不适合：

• 注入大量事实知识
• 频繁变化的企业文档
• 需要精确引用来源的知识问答

LoRA / QLoRA 微调¶

LoRA 的本质¶

原始模型权重不动，只在部分线性层旁边插入低秩矩阵：

• 原始权重 W 不训练
• 新增低秩矩阵 A、B 训练
• 最终效果近似于：
  • W' = W + ΔW
  • ΔW = B × A

这样训练参数量会大幅减少。

优点：

• 显存低
• 训练快
• 可以保存多个 adapter
• 容易切换业务角色
• 适合中小团队

缺点：

• 能力提升有限
• 极深层知识注入不稳定多 adapter 管理复杂和基础模型强绑定

QLoRA 的本质¶

QLoRA 是：基础模型 4bit 量化再进行 LoRA 训练

也就是：

• 冻结 base model：4bit
• 训练 LoRA adapter：通常 fp16 / bf16

优点：

• 极大降低显存
• 单卡也能微调较大模型

缺点：

• 训练速度可能变慢
• 量化误差会影响效果
• 部署时要注意加载方式

DPO / RLHF / ORPO：偏好优化¶

SFT 是告诉模型“标准答案是什么”。偏好优化是告诉模型：A 答案比 B 答案更好。

典型数据：

{
  "prompt": "解释一下 RAG 是什么",
  "chosen": "RAG 是检索增强生成，先检索外部知识，再让模型基于知识回答。",
  "rejected": "RAG 是一种让模型变大的训练方法。"
}

适合：

• 减少废话
• 减少幻觉
• 增强拒答能力
• 改善回答风格
• 改善安全边界
• 让模型更符合人类偏好

常见方法：

• RLHF：经典人类反馈强化学习，复杂，成本高
• DPO：直接偏好优化，更简单，工业界很常用
• ORPO：把 SFT 和偏好优化合并成一个目标
• KTO：用好/坏标签优化，不一定需要成对 chosen/rejected

实际建议：

• 第一阶段：SFT
• 第二阶段：DPO

不要一开始就搞 RLHF，工程复杂度高，收益未必匹配。

CPT：继续预训练¶

它不是问答格式训练，而是继续让模型读大量领域文本。

数据一般是：

• 大量医学文献
• 大量法律条文
• 大量金融研报
• 大量企业内部技术文档
• 大量代码仓库

训练目标仍然是语言模型目标：

• 预测下一个 token

适合：

• 让模型熟悉领域术语
• 增强领域语言分布
• 提升某个领域的基础理解能力

不适合：

• 直接让模型学会问答格式
• 直接学会客服话术
• 直接学会工具调用

通常流程是：

基础模型
  ↓
CPT 领域继续预训练
  ↓
SFT 指令微调
  ↓
DPO 偏好优化

但 CPT 成本高，对数据质量要求高，不是第一阶段必做。

全参数微调¶

全参数微调就是训练整个模型所有参数。

适合：

• 资金充足
• 数据量很大
• 算力充足
• 需要深度改变模型能力
• 有专业训练团队

不适合大多数个人或中小团队。

大模型调优的实际操作流程¶

对于一般业务场景的大模型调优实际操作流程如下（个别特殊的场景除外）：

确定目标
  ↓
准备数据
  ↓
选择基础模型
  ↓
选择训练方式
  ↓
训练
  ↓
评估
  ↓
部署
  ↓
线上反馈
  ↓
继续迭代

明确调优目标¶

首先必须回答的问题是：你到底希望模型变成什么样？

常见的目标和方法如下：

• 输出格式调优：SFT
• 业务流程调优：SFT + RAG
• 领域能力调优：RAG 或 CPT + SFT
• 回答风格调优：SFT + DPO
• 小模型能力增强：蒸馏

准备训练数据¶

数据质量比训练技巧更重要。大模型调优最常见的问题不是代码错，而是数据烂。

SFT 数据格式¶

常见格式是 ChatML / messages：

{
  "messages": [
    {
      "role": "system",
      "content": "你是一个 Python 后端开发专家。"
    },
    {
      "role": "user",
      "content": "解释一下 SQLAlchemy Session 的生命周期。"
    },
    {
      "role": "assistant",
      "content": "SQLAlchemy Session 负责管理 ORM 对象状态、事务边界和数据库连接..."
    }
  ]
}

数据来源¶

常见的数据来源如下：

• 历史客服记录
• 企业 FAQ
• 人工整理问答对
• 技术文档转换
• 业务流程文档转换
• 专家标注数据
• 大模型生成 + 人工审核
• 线上用户问题 + 人工优质回答

数据量建议¶

常见场景下的数据量粗略建议如下：

数据质量标准¶

好数据应该满足：

• 问题真实
• 答案准确
• 格式统一
• 无自相矛盾
• 覆盖常见场景
• 覆盖异常场景
• 包含拒答样本
• 包含边界条件
• 包含多轮对话样本

烂数据通常是：

• 答案太短
• 答案含糊
• 答案风格混乱
• 大量重复
• 错误知识
• 过时知识
• 问题不像真实用户会问的
• 没有负样本
• 没有困难样本

选择基础模型¶

要根据任务场景选择合适的模型，以下是一些常用场景下的模型选择：

• 中文业务 / 企业知识库 / RAG / 对话助手：优先看 Qwen 系列。
• 英文、多语言、国际化通用助手：优先看 Llama / Mistral /Gemma。
• 代码生成、代码解释、代码 Agent：优先看 Qwen Coder / DeepSeek Coder / Mistral Coder 类模型。
• 数学、逻辑推理、复杂规划：优先看 DeepSeek-R1 / Qwen Math / reasoning-oriented 模型。
• 低成本本地部署：优先看 Qwen 1.5B/3B/7B、Gemma 1B/4B/12B、Phi、小尺寸 Mistral/Ministral。
• 视觉理解、多模态问答：优先看 Qwen-VL、Llama 4、Gemma 3 多模态版本、Mistral 多模态模型。
• Embedding / RAG 检索：不要用普通生成模型凑合，直接选 Qwen3-Embedding、BGE-M3、bge-reranker、Qwen3-Reranker 等专用模型。

Base 模型和 Instruct 模型怎么选？¶

Base 模型是预训练模型，主要学到了语言、知识、代码、推理模式，能进行基础续写，适合做以下内容：

• 继续预训练 CPT，注入大量领域语料
• 从头开始做 SFT

Instruct 模型已经经过指令微调或对齐，适合做以下内容：

• 企业客服助手
• RAG 问答
• 角色微调
• 工具调用/ Agent
• 少量业务样本的 LoRA 微调
• 通用聊天机器人

选择训练方式¶

对于小规模业务而言，在 7B 以下的模型，可以选择 LoRA 或全参微调，但对于 7B 以上，优先选择 LoRA / QLoRA 。

如果想要高质量生产模型，且预算充足，可以按以下路线进行，这个路线成本较高：

Base Model
  ↓
领域 CPT
  ↓
SFT
  ↓
DPO
  ↓
评估
  ↓
部署

训练¶

LoRA SFT 的训练流程参考：LoRA 方法介绍

评估¶

对于模型训练后的评估环节，至少准备三类评估集：

• 训练集同分布问题
• 真实线上问题
• 困难/边界问题

评估指标可以分成：

• 准确性
• 格式符合率
• 拒答正确率
• 幻觉率
• 响应长度
• 工具调用准确率
• 人工评分

对于 RAG 问答，评估还应该包括：

• 检索命中率
• rerank 后 top-k 命中率
• 答案是否基于上下文
• 是否引用正确来源
• 无答案时是否拒答

部署¶

线上反馈与继续迭代¶

对于大模型调优，“线上反馈”和“继续迭代”的本质是：

把真实用户使用中的失败样本、偏好信号、业务变更、模型缺陷，持续回流到评估集、数据集、Prompt、RAG、微调策略和部署策略中。

线上反馈¶

线上反馈主要收集以下内容：

• 显式反馈：用户直接评价
• 隐式反馈：用户行为信号
• 人工质检反馈
• 失败类型标签
• 线上日志
• 线上数据分布变化

显式反馈：用户直接评价¶

让用户对相应内容进行评价，例如：

• 👍 有帮助
• 👎 没有帮助
• 答案错误
• 答非所问
• 不够详细
• 引用错误
• 格式不对
• 需要人工处理

设计上需要收集：

• request_id
• user_id / tenant_id
• session_id
• 用户原始问题
• 模型回答
• 用户反馈类型
• 用户反馈文本
• 时间
• 使用的模型版本
• 使用的 prompt 版本
• 使用的知识库版本
• 召回文档列表
• rerank 分数
• 最终上下文
• 生成参数
• 是否命中缓存

在这个环节中，不仅仅是收集用户的评价内容，更要收集用户对哪个答案不满意，对答案来到来源进行追溯。

隐式反馈：用户行为信号¶

有些时候，用户的行为会暴露对答案的不满意。常见的隐式信号如下：

人工质检反馈¶

在企业级调优中，人工质检是最重要的一环，让专业和非专业的人员对模型的回答打标是重要的测试。

常见的打标维度：

评分可以这样设计：

5 = 完全可用
4 = 基本可用，小问题
3 = 部分可用，需要修改
2 = 大部分错误
1 = 完全不可用

失败类型标签¶

对于负反馈必须要进行分类，常用的分类如下：

A. 检索问题
   A1. 没召回正确文档
   A2. 召回了错误文档
   A3. chunk 太碎
   A4. chunk 太长
   A5. rerank 排错
   A6. metadata / 权限过滤错误

B. 生成问题
   B1. 幻觉
   B2. 答非所问
   B3. 回答不完整
   B4. 逻辑错误
   B5. 过度推理
   B6. 拒答错误
   B7. 没有遵循格式

C. 意图理解问题
   C1. 用户问题分类错误
   C2. 没识别上下文
   C3. 多轮指代错误
   C4. 没识别用户真实目标

D. 工具调用问题
   D1. 工具选择错误
   D2. 参数生成错误
   D3. 工具结果理解错误
   D4. 工具失败后没有恢复

E. 业务规则问题
   E1. 违反权限
   E2. 违反流程
   E3. 业务政策过期
   E4. 需要人工处理但没有转人工

F. 产品交互问题
   F1. 用户输入信息不足
   F2. 没有追问澄清
   F3. 答案太长
   F4. 答案太短

线上日志¶

大模型线上服务至少要记录：

用户输入
会话历史
系统 prompt
开发者 prompt
最终 prompt
模型名
模型版本
LoRA adapter 版本
生成参数
输入 token 数
输出 token 数
延迟
首 token 延迟
总耗时
召回文档 ID
召回分数
rerank 分数
上下文片段
最终回答
用户反馈
错误码
工具调用记录
权限过滤记录

RAG 场景还要记录：

query rewrite 结果
embedding 模型版本
向量库 collection 版本
chunk 策略版本
top_k
score threshold
reranker 模型版本
最终进入 prompt 的 chunk
引用来源

线上数据分布变化¶

继续迭代还要关注数据漂移，例如：

继续迭代¶

继续迭代不是只迭代模型权重，而是迭代整个 LLM 应用系统。

按优先级看，通常是：

1. 数据
2. 评估集
3. Prompt
4. RAG 检索链路
5. 工具调用链路
6. 模型选择
7. 微调模型
8. 部署和路由策略

第一优先级：迭代评估集¶

评估集是继续迭代的基准。线上发现问题后，不能只修改 Prompt、RAG 或重新训练模型，而应该先把典型失败样本沉淀到评估集中，作为后续版本回归测试的依据。

评估集的核心作用是：

• 防止旧问题反复出现
• 判断新版本是否真的变好
• 定位不同版本之间的能力变化
• 为 Prompt、RAG、模型微调提供统一评价标准

评估集应重点包含几类样本：

1. Golden Set：核心业务高质量样本，每次上线前必须测试。
2. Regression Set：从线上失败样本中沉淀，用于防止历史问题复发。
3. Stress Set：边界问题、长上下文问题、歧义问题、越权问题、无答案问题、Prompt Injection 问题。
4. Domain Set：领域专项问题，例如企业制度、法律条款、医疗知识、代码问题、财务规则等。

线上失败样本进入评估集前，必须经过：

• 清洗
• 脱敏
• 人工确认
• 错误归因
• 标注标准答案或评分标准

需要注意：评估集不能混入训练集。否则模型会在评估样本上“背答案”，导致离线指标虚高，无法反映真实泛化能力。

第二优先级：迭代数据¶

数据是调优效果的核心。线上反馈不能直接拿来训练，必须经过清洗、修正、标注和分类。

数据迭代的重点不是“收集越多越好”，而是收集高质量、可训练、可评估、可复现的数据。

常见数据类型包括：

1. SFT 数据：用于训练模型如何回答。适合优化回答格式、业务话术、角色风格、工具调用、多轮对话、拒答策略。
2. 偏好数据：形式是 chosen / rejected。用于 DPO、ORPO 或其他偏好优化。适合优化回答质量、减少幻觉、改善语气、强化拒答边界。
3. RAG 数据：包含 query、positive docs、negative docs。用于评估或训练 embedding、reranker、query rewrite、检索策略。
4. 工具调用数据：包含用户问题、工具选择、工具参数、工具结果、最终回答。用于优化 Agent 或 function calling 能力。
5. 拒答和边界数据：用于训练模型在无权限、无资料、敏感问题、信息不足时正确拒答或追问。

数据处理流程：

线上日志 / 用户反馈
  ↓
筛选有效样本
  ↓
脱敏
  ↓
人工修正错误答案
  ↓
标注错误类型
  ↓
划分训练集、验证集、测试集、偏好集、回归集

特别注意：不能把模型的错误回答直接当训练数据。如果线上回答本来就是错的，直接拿去训练，只会强化错误行为。

第三优先级：迭代 Prompt¶

Prompt 迭代适合快速修复行为层问题，尤其适合在不重新训练模型的情况下，快速调整模型输出方式。

Prompt 适合解决的问题：

• 回答太长或太短
• 输出格式不稳定
• 没有引用来源
• 回答不够结构化
• 没有按照业务角色回答
• 不知道时没有拒答
• 信息不足时没有追问
• 回答语气不符合要求

Prompt 不适合解决的问题：

• 知识库没有正确内容
• RAG 没有召回正确文档
• 模型基础能力不足
• 复杂推理能力不够
• 权限过滤逻辑错误
• 实时数据查询错误

Prompt 迭代要做版本管理。每一次修改都应该记录：

• prompt_version
• 适用模型
• 适用业务场景
• 修改原因
• 上线时间
• 评估结果
• 回滚记录

Prompt 应该像代码一样管理，而不是散落在业务代码中随意修改。

一个基本原则：

• 小问题先改 Prompt
• 结构化问题加 schema 约束
• 长期稳定问题再考虑 SFT
• 知识问题优先修 RAG

第四优先级：迭代 RAG 链路¶

对于知识库问答系统，很多线上问题不是模型生成能力差，而是 RAG 链路出了问题。

RAG 链路需要重点检查：

1. Query Rewrite：用户问题是否被正确改写。
2. Embedding：语义向量是否适合当前语言和领域。
3. Chunk：文档切分是否合理，是否保留标题、层级、上下文和元数据。
4. Retrieval：是否召回了正确文档。
5. Rerank：正确文档是否被排到前面。
6. Context Construction：最终进入 Prompt 的上下文是否完整、干净、不过期、不冲突。
7. Citation：回答中的引用是否真正支持答案。
8. Permission Filter：是否只召回用户有权限访问的文档。

常见问题和修复方向：

• 没有召回正确文档 → 调整 embedding、chunk、top_k、hybrid search、query rewrite。
• 正确文档被召回但排名靠后 → 加 reranker，或优化 reranker。
• 召回了旧文档 → 加文档版本、生效时间、失效时间等 metadata。
• 上下文太长导致模型忽略重点 → 做上下文压缩、去重、排序和摘要。
• 模型基于资料外内容胡编 → 强化 Prompt 约束，要求只基于资料回答。
• 引用错误 → 优化引用生成逻辑，检查引用是否支持答案。

第五优先级：迭代模型¶

模型迭代是最后一层手段，不应该成为第一反应。

适合微调模型的问题：

• 输出格式长期不稳定
• 业务话术不统一
• 角色风格不稳定
• 工具调用格式经常错误
• 多轮对话模式不符合预期
• 拒答边界不稳定
• 领域术语表达不自然
• 分类、抽取、结构化输出不稳定

不适合微调模型的问题：

• 知识库内容频繁更新
• 实时数据查询
• 权限控制
• 检索不到正确文档
• 业务规则经常变化
• 模型参数规模太小导致能力不足
• 用户输入信息缺失

模型迭代常见方式：

1. 更换基础模型：当当前模型能力上限不够时，换更强的模型比继续微调更有效。
2. LoRA / QLoRA：适合低成本适配业务风格、格式、角色、工具调用和领域表达。
3. SFT：适合用高质量指令数据训练模型的业务回答方式。
4. DPO / ORPO：适合利用偏好数据优化回答质量、拒答边界、语气和幻觉问题。
5. 继续预训练：适合大量领域语料注入，但成本高，不适合少量问答数据。

模型迭代必须配合评估集和灰度发布：

训练新模型
  ↓
离线评估
  ↓
和旧模型对比
  ↓
小流量灰度
  ↓
观察线上指标
  ↓
决定扩大或回滚

继续迭代的闭环流程¶

继续迭代的本质是建立一个从线上反馈到系统优化的闭环。完整流程如下：

线上请求
  ↓
日志采集
  ↓
用户反馈 / 隐式行为 / 人工质检 / 自动评估
  ↓
失败样本筛选
  ↓
错误归因
  ↓
数据清洗与脱敏
  ↓
进入数据池
  ↓
沉淀为评估集 / 训练集 / 偏好集 / RAG 样本
  ↓
选择修复方式
      ├── 迭代评估集
      ├── 迭代数据
      ├── 迭代 Prompt
      ├── 迭代 RAG 链路
      ├── 迭代工具调用
      ├── 迭代模型
      └── 迭代部署和路由策略
  ↓
离线评估
  ↓
灰度发布
  ↓
线上监控
  ↓
继续反馈回流

线上反馈需要重点记录：

1. 用户原始问题
2. 会话上下文
3. 模型回答
4. 模型版本
5. Prompt 版本
6. LoRA 版本
7. Embedding 模型版本
8. Reranker 模型版本
9. 知识库版本
10. 召回文档
11. 重排结果
12. 最终上下文
13. 生成参数
14. 输入/输出 token
15. 延迟
16. 用户反馈
17. 人工质检结果
18. 错误类型

继续迭代的核心原则：

• 没有日志，就无法复现。
• 没有归因，就无法修复。
• 没有评估集，就无法判断是否变好。
• 没有灰度，就无法控制风险。
• 没有版本管理，就无法回滚。

最终要形成的不是“不断重新训练模型”，而是：

1. 线上反馈驱动
2. 评估集约束
3. 数据持续沉淀
4. Prompt 快速修正
5. RAG 持续优化
6. 模型按需微调
7. 灰度发布验证
8. 线上指标闭环

继续迭代不是盲目再训练模型，而是基于线上反馈，对评估集、数据、Prompt、RAG、模型和部署策略进行系统性优化。

继续迭代时最危险的坑¶

1. 拿模型错误回答当训练数据

   • 线上日志里模型答错了，你如果不人工修正就拿去训练，等于强化错误。

2. 只根据点赞/点踩训练

   • 用户反馈噪声很大。
   • 差评不一定代表答案错，可能是用户不满意业务规则。
   • 点赞也不一定代表事实正确。

3. 评估集污染

   • 把测试集样本放进训练集，离线指标会虚高。

4. 只优化平均分

   • 平均分提升，但关键高风险场景下降，这是严重问题。

5. Prompt 改动无版本

   • 线上变差后无法回滚。

6. 知识问题用微调解决

   • 知识频繁变化时，微调是错误方向。

7. 没有灰度

   • 新模型直接全量上线，风险很高。

8. 只看模型，不看系统

   • 大模型应用是系统工程，不是模型权重工程。