RAG 与微调如何取舍
第 1 章提到 RAG 与微调互补，本章给出可落地的决策框架，帮你判断该上哪一个、还是两个都要。
1. 先问四个问题
| 维度 | 倾向 RAG | 倾向微调 |
|---|---|---|
| 知识是否频繁更新 | 是，改库即生效 | 否，知识相对稳定 |
| 答案需引用原文溯源 | 是，必须可追溯 | 否，重在表达 |
| 目标是改「知识」还是改「行为/风格」 | 知识 → RAG | 风格/格式 → 微调 |
| 标注数据是否充足 | 不需要，有文档即可 | 需大量高质量样本 |
ℹ️一句话判据
要「接上最新、可溯源的事实」用 RAG；要「让模型学会一种说话/做事方式」用微调。
2. 典型决策树
问题需要引用最新内部文档吗？ ─是→ RAG
│否
要改变输出格式/语气/任务行为吗？ ─是→ 微调
│否
数据会每周变吗？ ─是→ RAG
│否
两者都不强烈 → 先用 RAG（更快更稳）3. 组合使用更常见
很多成熟系统RAG + 轻量微调双管齐下：
# RAG 负责「事实」，微调负责「格式」
answer = rag_generate(question) # 基于检索原文作答（事实准）
# 模型已微调为固定输出结构：先给结论，再列引用4. 成本与风险对比
| 项 | RAG | 微调 |
|---|---|---|
| 上线速度 | 快，接知识库即可 | 慢，需准备数据 + 训练 |
| 迭代成本 | 低，改文档 | 高，重新训练 |
| 幻觉风险 | 低（有原文） | 中（知识固化权重） |
| 数据门槛 | 极低 | 需标注样本 |
⚠️别用微调解决知识更新
若你的真实诉求是「让模型知道最新政策」，微调是错误解法——训练完政策又变了，且无法给出处。这种情况 RAG 才是正解。
💡默认从 RAG 起步
不确定时先上 RAG：它成本低、可溯源、易迭代。当评测发现「风格/格式总不对」且数据充足时，再补一道微调。
🎯练习
列出你业务里 3 个待解决的需求，按上面决策树分别标出 RAG / 微调 / 两者。重点检查有没有把「知识更新」误判成「需要微调」的情况。
小结
- 判据：知识时效与溯源 → RAG；风格行为 → 微调
- 决策树：先问是否需引用最新文档、是否改行为、数据变不变
- 常见组合 RAG + 轻量微调，各管事实与格式
- 不确定时默认 RAG 起步，再按需补微调
- 下一章面对「百万 token 上下文」模型，RAG 还有必要吗 →