Fine-tuning vs RAG

概述

当通用大模型不够用时，有两种主流方案让它适应特定场景：

• Fine-tuning — 用领域数据重新训练模型，调整内部权重
• RAG — 不动模型，检索外部知识作为上下文

90% 的场景应该用 RAG。但什么时候该用 Fine-tuning？本文帮你判断。

对比

Fine-tuning 的几种姿势

业内说"做 fine-tuning"时通常指三种不同的事，混着用容易踩坑：

中小团队 90% 的「fine-tune」需求其实是 SFT。配合 LoRA / QLoRA，单张 4090 就能跑动 7B-13B 模型的 SFT。

什么时候用 Fine-tuning

1. 调整输出风格

模型需要特定的写作风格、语气、格式，而这些很难用 prompt 描述清楚。

例子：让模型模仿某个品牌的文案风格、生成特定格式的法律文书。

2. 特定领域术语

模型对某个领域的专业术语理解不准确，需要大量领域数据训练。

例子：医学影像报告生成、法律条文引用。

3. 降低推理成本

把 prompt 中的大量指令"固化"到模型权重中，减少每次推理的 token 用量。

例子：固定格式的客服分类、情感分析。

4. 任务专精

模型需要在某个窄任务上达到极致表现，牺牲通用能力换取专业能力。

例子：代码补全专用模型、SQL 生成专用模型。

什么时候用 RAG

1. 知识库问答

企业内部文档、产品手册、FAQ 问答。这是 RAG 的主场。

2. 实时信息

需要查最新数据（股价、天气、新闻）。Fine-tuning 无法解决知识时效性。

3. 多源知识

需要综合多个文档来源回答问题。Fine-tuning 会把知识"混"在一起，RAG 能精确标注来源。

4. 数据安全敏感

数据不能进入模型权重（合规、隐私）。RAG 把数据放在外部知识库，可控制访问权限。

主流 Fine-tuning 服务对比

如果决定做 SFT，三条路线：

经验法则：先试 prompt + RAG，搞不定再试 SFT，SFT 搞不定再试 DPO。直接上 RLHF 是大厂才该做的事。

成本量化（粗略数量级）

按 100 万条对话场景估算：

先算账再决定——很多团队 fine-tune 完一年的推理增量成本就超过了节省的 prompt token 钱。

可以组合使用

Fine-tuning 和 RAG 不是互斥的。最佳实践：

1. Fine-tune 调整模型风格和格式
2. RAG 提供事实性知识
3. Prompt 控制行为规范

用户提问
  ↓
RAG 检索相关文档
  ↓
Fine-tuned 模型（已有正确风格）
  + 检索到的文档上下文
  + System Prompt（行为规范）
  → 生成回答

真实案例：客服场景——用 SFT 教模型"用什么语气说话"和"什么不能承诺"，用 RAG 提供商品/订单实时数据。两者分工明确，单独用任何一个都做不好。

2026 年改变这个选择题的三个变量

上表的对比在 2023–2024 年是完整的，但到 2026 年有三个变量把边界推走了，直接照旧表选型会选错。

变量一：长上下文不再是稀缺品，"塞进 prompt"成为一种 RAG 的替代品

主流模型普遍提供 1M 级别的上下文窗口（如 Claude Haiku 5.5 的 1M 输入与 Gemini 4 系列的 1M 口径），于是出现了一条新路径：不建检索系统，直接把整批文档塞进上下文。

它确实解决了一类问题——一次性的、文档集固定的分析任务（一本合同、一个季度的财报、一份代码库的某个子系统）。但它没有解决另外两类：

关键判据是"要不要出处"，不是"文档多不多"。 需要出处的场景，全量塞上下文是拿可审计性换工程省事。

变量二：RAG 从"检索一次"变成"agent 反复检索"

早期 RAG 是固定的三段式：切分 → 向量召回 top-k → 拼 prompt。现在的做法更接近 agentic retrieval——让模型自己决定查什么、查几次、用什么关键词，甚至用 grep / SQL / 代码执行而不是纯向量相似度。

典型是编程场景：Claude Code 之类的 agent 并不建索引，而是用 Grep / Glob 反复探查代码库。这在本质上就是一种 RAG，只是检索器是工具调用而不是向量库。

含义：如果你在做代码或结构化数据的知识问答，先考虑"给模型工具让它自己查"，而不是先建向量库——后者的召回准确率在很多场景下反而更差。

变量三：Fine-tuning 的重心从"灌知识"移到了"对齐行为"与"小模型蒸馏"

"用 fine-tuning 让模型记住领域知识"这条路已经基本被证伪（见误区 2）。2026 年还在做 fine-tuning 的，主要集中在这两类：

1. 行为对齐——输出风格、格式稳定性、拒答边界、工具调用的调用倾向。这类目标 RAG 做不到，prompt 不够稳。
2. 小模型蒸馏——用大模型产出的数据去训一个便宜得多的小模型，把某个固定环节的成本压下来。这是成本工程，不是能力工程。

常见误区

误区 1: "我们的数据很特殊，必须 fine-tune"

大多数情况下，你的数据只是"模型没见过"而非"模型理解不了"。RAG 就能让模型看到你的数据。

误区 2: "Fine-tuning 会让模型更聪明"

Fine-tuning 调整的是行为模式，不是知识。模型不会因为 fine-tuning 就变得更擅长推理。

误区 3: "Fine-tuning 后不需要 prompt 了"

Fine-tuning 后仍需要好的 prompt。Fine-tuning 只是让模型在特定模式下更可靠。

误区 4: "Fine-tune 一次就一劳永逸"

模型升级（GPT-4 → GPT-5、Claude 3 → Claude 4），你的 fine-tune 模型还停在旧基座。要么不升级享受不到新能力，要么重新跑训练流程。RAG 没这问题。

误区 5: "上下文窗口够大，就不用做 RAG 了"

见上文「变量一」。长上下文替代的是"检索系统的工程量"，不是"检索系统的必要性"。 三个问题会迅速把它打回原形：知识要更新怎么办？要不要给出处？每次请求都塞全量文档的钱谁来付？三个里面有一个答不上来，就该做 RAG。

误区 6: "RAG 上线了就算做完了"

RAG 的质量几乎全部取决于检索召回，而不是生成。常见翻车方式是：只盯着最终回答挑毛病，却从不单独测"该召回的段落召没召回"。正确做法是分别测两段——先看 top-k 里有没有正确答案（召回率），再看模型有没有用上（生成忠实度）。只看端到端答案，你永远分不清是检索错了还是生成错了。

误区 7: "切分越细召回越准"

细切分会提高单次命中的相似度，但会把一段完整论证拆得七零八落，模型拿到的是残缺上下文，反而更容易胡编。切分粒度要按"语义能不能自洽"来定，而不是按固定字数。 代码按函数/类切、文档按小节切，比按 500 字硬切好得多。

决策树

你的需求是什么？
├─ 让模型知道新知识 → RAG
├─ 让模型改变输出风格 → Fine-tuning（SFT）
├─ 让模型理解领域术语 → 先 RAG（喂术语表），不行再 SFT
├─ 让模型用特定格式输出 → 先 Structured Output / Prompt，不行再 SFT
├─ 让模型基于私有数据回答 → RAG
├─ 减少幻觉 / 对齐偏好 → DPO
└─ 以上多个 → RAG + SFT 组合

更新说明

待核实：本文未转录任何具体基准分数或厂商公布的 RAG 评测数字；长上下文成本随模型与缓存策略差异很大，请以你实际调用模型的定价页与 Prompt Caching 口径自行核算。

延伸阅读

• 高效微调：LoRA（低秩适配）
• 检索架构：RAG（检索增强生成）
• 数据准备：Embedding
• 控制输出：Prompt Engineering