Fine-tuning微调

微调(Fine-tuning)是在一个已经预训练好的模型基础上,用规模小得多的特定数据继续训练,让模型适配某个领域、某种风格或某类任务。相比从零训练,成本低几个数量级,是绝大多数团队能负担的定制方式。

它真正擅长解决什么

这是最容易搞错的一点。微调擅长教模型怎么做,不擅长教模型知道什么:

适合微调	不适合微调(该用 RAG)
固定的输出格式和结构	会变化的事实和数据
特定的语气、文风、话术	需要标注来源的内容
领域术语和表达习惯	频繁更新的知识库
复杂的分类和抽取任务	需要权限隔离的资料

把公司知识"微调进模型"是常见的错误路线:知识一更新就要重训,而且无法溯源。这类需求几乎都该走检索。

主流的几种做法

• SFT(监督微调):给成对的"输入 → 期望输出"示例,让模型学着照做。最常用。
• LoRA / QLoRA:不动原始权重,只训练一小组低秩增量参数。显存需求大幅下降,一张消费级显卡也能跑,而且可以给不同场景各训一个适配器,按需挂载。目前中小团队的默认选择。
• 偏好优化(DPO 等):给"更好的回答 / 更差的回答"成对数据,让模型学会倾向前者。适合调语气和取舍标准,不适合灌事实。

数据比方法重要得多

微调的效果几乎完全由数据质量决定:

• 宁少勿脏。几百条精心校对的样本,常常胜过几万条自动生成的噪音数据。
• 样本要体现你要的判断,包括边界情况和该拒答的情况。只喂正面样本,模型学不会什么时候不该答。
• 格式要绝对一致。样本里格式飘,模型输出就飘。
• 留出一份从没参与训练的评测集。没有这个,你无法判断微调到底是变好了还是过拟合了。

微调的隐藏成本

决定微调前算清这几笔账:

• 推理侧要自己部署(除非用托管的微调服务),GPU 常驻成本比按量调 API 高得多。
• 底座会过时。基础模型半年一代,你微调的是旧底座,新一代通用模型可能直接超过你调过的版本。
• 每次底座升级都要重训一遍,数据管线得能复现。
• 可能变笨。在窄数据上训过头会损失通用能力,这叫灾难性遗忘。

务实的顺序

Prompt 工程 → Few-shot 示例 → RAG → 微调。前三步成本低、迭代快,能解决的问题远比想象中多。到了必须微调那一步,通常是因为对格式稳定性、延迟或成本有硬要求,而不是因为"效果不够好"。