13.14 RAG vs 微调 vs 长上下文

RAG 不是唯一的选择。面对”让 LLM 知道更多信息”这个问题，你有三种方案：RAG、微调、长上下文。2026 年，这三种方案各有各的位置。

13.14.1 三种方案对比

RAG：检索 + 生成。知识存在外部数据库里，查询时动态检索。知识更新：实时（改数据库就行）。成本：每次查询有检索成本（Embedding + 向量搜索 + 重排序），但不改模型。知识边界：明确（不检索就不知道）。

微调：用新数据训练模型。知识”固化”进模型参数里。知识更新：重训（需要 GPU 和时间）。成本：训练成本高（数千到数万美元），但推理成本低（没有检索开销）。知识边界：模糊（模型可能”记住”了训练数据，也可能没记住）。

长上下文：把大量信息直接放进 Prompt。知识”临时”注入。知识更新：即时（每次 Prompt 不同）。成本：按 token 计费，长 Prompt 每次查询都要花钱。知识边界：明确（Prompt 里有什么，模型就知道什么）。

13.14.2 决策框架

场景判断流程：

1. 知识是否需要频繁更新（每周/每天）？
   是 → RAG 或 长上下文（微调不适合）
   否 → 继续看

2. 知识量有多大？
   少量（< 10 页）→ 长上下文（最简单）
   中量（10-100 页）→ RAG 或 长上下文
   大量（> 100 页）→ RAG（长上下文成本太高）

3. 查询量有多大？
   高频（每天数千次）→ 微调（训练一次，推理便宜）
   中频 → RAG（训练成本太高，但检索成本可控）
   低频 → 长上下文（最简单，不需要维护基础设施）

4. 需要精确引用来源吗？
   需要 → RAG（天然支持引用）
   不需要 → 微调或长上下文

5. 任务类型是什么？
   知识密集型（问答、客服）→ RAG
   风格/格式转换（改写、翻译）→ 微调
   长文档分析（总结合同、分析论文）→ 长上下文

13.14.3 2026 趋势：长上下文窗口会不会取代 RAG？

2026 年，Gemini 2.5 Pro 支持 1M token 上下文，Claude 4 支持 200K，GPT-5 支持 256K。一个直觉性的问题是：如果上下文窗口这么大了，为什么不直接把所有文档塞进去，还要费劲做 RAG？

答案是：长上下文和 RAG 解决的是不同问题，它们互补而非替代。

长上下文替代不了 RAG 的原因：

成本：1M token 的 Prompt 每次查询都要付费。GPT-4o 的价格是 $2.50/1 M in p u tt o k e n 。如果每次查询都塞 100 K t o k e n 的文档， 1000 次查询就要$ 250 的文档成本。而 RAG 的检索成本远低于此。
Lost in the Middle：LLM 对 Prompt 中间部分的信息关注度显著低于开头和结尾。文档越多，这个效应越严重。RAG 通过检索只保留最相关的文档，信息密度更高。
延迟：处理 100K token 的 Prompt 比处理 1K token 慢得多。用户不想等。
幻觉：长上下文并不能消除幻觉。LLM 面对大量信息时，反而可能”混淆”不同来源的信息。

长上下文的优势场景：

分析单篇长文档（100 页合同、50 页论文）
翻译整本书
对比多个文档的细微差异

13.14.4 混合方案

2026 年的最佳实践是组合使用，而非三选一：

RAG + 微调：用微调让模型学会”如何更好地使用检索结果”（比如学会标注引用、学会说”根据资料我无法回答”），用 RAG 注入实时知识。微调优化的是”行为”，RAG 优化的是”知识”。
RAG + 长上下文：用 RAG 检索出 Top-10 文档，再把这些文档完整地放进长上下文窗口（而不是只用片段）。这样既降低了检索遗漏的风险，又利用了长上下文的理解能力。
微调 + 长上下文：微调让模型学会特定领域的语言风格，长上下文用来注入具体案例。适合法律、医疗等专业领域。

一句话总结：RAG 是 2026 年的默认方案（适合 80% 的知识密集型场景），长上下文是”瑞士军刀”（适合单文档分析），微调是”专业工具”（适合高频、固定风格的场景）。三者不是竞争关系，而是工具箱里的不同工具。

← 上一节：13.13 RAG 评估｜下一节：13.15 RAG 生产部署 →