模型微调

模型微调是用领域数据调整模型行为，使模型更贴近特定任务、术语或输出格式。

企业常把微调理解成“把资料喂给模型，让模型学会公司知识”，但这并不准确。微调更适合改变模型的行为模式、输出格式、语气风格、分类边界或特定任务能力。对于经常变化的企业知识，通常应优先使用 企业 RAG 知识库。

什么时候考虑微调

• 需要稳定输出特定格式
• 需要掌握行业术语或内部表达
• 提示词和 RAG 已无法满足一致性要求
• 有足够高质量样本可以形成训练集和评估集
• 任务边界稳定，不会频繁变化

什么时候不优先微调

• 数据量不足或质量不稳定
• 只是需要引用企业知识
• 业务流程还没有跑通
• 还没有清晰的评估指标
• 只是想降低一次对话中的提示词长度

决策路径

flowchart TD
  A["模型效果不稳定"] --> B{"问题来自哪里"}
  B -- "缺少企业知识" --> C["优先 RAG"]
  B -- "工具执行不稳定" --> D["优化 Agent 与工具协议"]
  B -- "输出格式不稳定" --> E["提示词和样例约束"]
  E --> F{"仍不稳定且样本充足"}
  F -- "是" --> G["进入微调评估"]
  F -- "否" --> H["继续优化流程和数据"]
  B -- "术语和分类边界稳定" --> G

微调和其他方案对比

方案	主要解决	优点	局限
提示词工程	指令、格式、角色、约束	快速、成本低、适合验证	复杂任务稳定性有限
RAG	最新企业知识、引用来源	可更新、可控、可追溯	对检索质量依赖高
工具调用	查询、写入、执行动作	能连接真实系统	需要接口和权限设计
微调	行为模式、输出稳定性、领域任务	一致性更高，推理提示更短	需要高质量数据和评估

数据准备

微调质量主要取决于数据，而不是训练按钮。

数据类型	用途
正样本	告诉模型什么是理想输出
反例样本	帮助模型识别错误边界
复杂样本	覆盖长文本、多条件、多轮上下文
评估集	训练后判断是否真的提升
安全样本	覆盖拒答、脱敏、权限和高风险场景

flowchart LR
  A["业务样本收集"] --> B["清洗与脱敏"]
  B --> C["标注与格式统一"]
  C --> D["训练集/验证集/评估集"]
  D --> E["小规模微调"]
  E --> F["离线评估"]
  F --> G["灰度上线"]
  G --> H["持续监控"]

决策建议

企业落地阶段通常先做提示词、RAG 和工具调用。只有当任务边界稳定、样本质量足够、评估指标明确时，才进入微调。

FDE 在微调项目中会先判断业务问题是否真的需要微调。如果 RAG、提示词或工具调用已经能解决问题，就不建议过早训练模型。真正进入微调时，会同时设计数据规范、评估集、上线灰度、版本回退和成本监控，避免训练出一个无法验证、无法维护的模型。

常见误区

• 微调不能自动记住企业全部文档。
• 微调不能替代权限控制和审计。
• 样本越多不一定越好，低质量样本会放大错误。
• 微调效果必须用独立评估集验证，不能只看几个演示问题。