1.3 RAG、微调与长上下文：三条路线怎么选

1.3 RAG、微调与长上下文：三条路线怎么选

本节摘要：让大模型"更懂你的业务"有三条主流路线——RAG 外挂知识库、微调改造模型本身、长上下文直接塞文档。三条路线解决的是不同性质的问题：知识注入、行为塑造、短期记忆扩容。本节用对比表和决策框架划清边界，并讨论三者组合使用的打法。读完你应当能在立项阶段选对路线，避免半年后推倒重来。

学习目标

阅读完本节，你应当能够：

1. 用"知识 vs 行为 vs 记忆"三个词区分三条路线的本质；
2. 列出每条路线的成本结构、生效周期与失效条件；
3. 按决策流程为一个具体需求选定主路线；
4. 设计"微调 + RAG"或"长上下文 + RAG"的组合方案。

一、一场经常发生的争论

评审会上，产品经理说："让 AI 回答得更像我们资深工程师。"算法工程师说："那得微调。"另一人说："直接把文档全塞进上下文不就行了？"第三人说："还是建 RAG 吧，大家都在建。"

三个人说的其实不是同一件事。"回答得像资深工程师"包含两层：知道工程师知道的资料（知识问题），以及用工程师的口吻和推理方式组织答案（行为问题）。知识问题归 RAG 管，行为问题归微调管，而长上下文是第三种东西——临时的、一次性的记忆扩容。争论之所以吵不出结果，是因为大家没先分清问题的性质。

我们先把三条路线的本质钉死，再谈选择。

二、三条路线的本质差异

RAG：外挂知识。 模型不动，知识放在外部库里，用的时候检索进来。特点：知识可随时增删、答案可溯源、数据可留在本地；代价是每次回答都要过一遍检索，多一环就多一环的出错可能，系统也多一坨工程复杂度。

微调：重塑行为。 用领域数据继续训练模型，改变的是权重。它擅长让模型学会特定的语言风格、输出格式、领域术语习惯，也能强化某类任务的完成方式。但微调不是好的知识注入手段——让模型"背下"具体事实既低效又不可靠，而且知识一更新就得重训。成本上，微调需要标注数据、算力和训练周期，一次投入以周计。

长上下文：临时扩容。 新一代模型支持数十万 token 的上下文窗口，一份几百页的文档可以直接塞进去提问。它的优势是无须任何额外工程——不用建库、不用分块、不用调检索。劣势同样明显：每次调用都要把全部文档重新"读"一遍，token 费用随文档量线性上涨，长文档中间部分的信息容易被模型忽略（所谓"迷失在中间"现象），而且它只解决"这一份文档"的问题，无法管理持续增长的知识集合。

三、一个决策框架

把选型压缩成三个连续的追问：

用三个例子走一遍流程。

例一，律所想让 AI 用所里的公文风格起草合同条款初稿。行为要求明确——主路线微调。但起草时还要引用最新法规，知识需求也在——组合方案：微调后的模型加法规知识库的 RAG。

例二，个人开发者想对一份三百页的年度报告提问。单份文档、不增长、用完即弃——长上下文直接塞，任何额外工程都是浪费。

例三，电商客服，商品手册每周更新，需要回答物流、退换、尺码问题。知识持续增长且频繁更新——主路线 RAG，风格要求不强，暂不微调。

四点补充判断

三个例子之外，还有四个边界情形值得单独交代，它们在真实项目里出现的频率不低。

情形一：知识量很小（比如只有二十页文档），但查询量很大。 建 RAG 的固定成本摊不薄，长上下文每次调用的 token 成本又乘以巨大的查询量。此时最优解可能是第三种——把文档直接写进系统提示词的一部分（提示词缓存在多数接口上能显著降费），连长上下文的"每次重读"都省了。判断公式很简单：文档 token 量乘以预期查询次数，与建库人力成本比大小。

情形二：既要风格又要知识，但预算只够做一件事。 先做 RAG。理由是知识错误比风格平庸更致命——用户能忍受答案不够俏皮，不能忍受答案答错。风格问题还可以用精心设计的提示词弥补大半，知识错误没有任何提示词能救。

情形三：模型已经微调过了，现在想加知识。 直接加 RAG，两者不冲突，微调模型照常当生成器用。反之，已有 RAG 想再微调，评估一下微调目标是否真的涉及"行为"——如果只是想让答案更准，加大检索投入通常比微调便宜且见效快。

情形四：多条路线的团队话语权之争。 现实中路线选择常变成部门博弈——数据团队倾向微调（体现数据价值），平台团队倾向 RAG（体现架构能力）。本节的决策框架给了一个超越立场的公共语言：把需求的性质、知识更新频率、用量三要素摆上桌，结论往往不言自明。技术选型的去政治化，靠的是共享的判断标准。

最后给一个自检口诀收束本节：知识常新用检索，风格定制靠微调，单份文档长窗口，三者组合效益高。朗朗上口不严谨，但立项讨论时足够把方向钉住，细节再回到决策图里逐项核对。

四、成本与风险的细账

选型光看"能不能做到"不够，还要算三笔账。

第一笔：钱。 RAG 的成本结构是"一次性建库加持续的低单价调用"——建库是人力密集活，调用时只为检索到的片段付 token 钱。长上下文是"零建设加持续的高单价调用"——什么都不用建，但每次提问都为整份文档的 token 买单，使用越频繁差距越悬殊。微调是"高一次性投入加低边际成本"——训练一次花掉大几万到几十万元不等，之后每次调用便宜。用量是决定性变量：低频使用，长上下文最省；高频使用，RAG 的摊薄优势碾压；预算充足且行为需求明确，微调的钱花得其所。

第二笔：时间。 RAG 建库以天计，微调从数据准备到训练验证以周到月计，长上下文当天见效。急着出结果的试点项目，先上长上下文或朴素 RAG 验证价值，再决定要不要做重投入——这本身就是一种降低选型风险的策略。

第三笔：风险。 RAG 的主要风险是检索错误导致的答案错误，可控可排查（有出处可对）；微调的主要风险是训练数据把偏见或错误固化进权重，出了问题难以定位和修复；长上下文的主要风险是成本失控与长文档中部信息的漏读。三条风险曲线里，RAG 的风险最"透明"，微调的风险最"黑箱"。

把三笔账折算成一张总表：

注意最后一行"失败后的退路"，它常被忽略却极重要。RAG 走错了路，知识库、评估集这些资产还能复用；微调失败了，标注费用与训练算力基本沉没。不确定性高的项目，优先选退路宽的路线。

五、组合拳：1 加 1 何时大于 2

三条路线并非互斥，实践中最常见的组合有两种。

微调加 RAG。 先用领域语料微调一个"懂行话"的底座模型，再接 RAG 供给事实。微调负责让模型理解领域术语的微妙差异（比如医学场景里"禁忌"和"慎用"的区别），RAG 负责供给具体病例、指南条文。顺序很重要：先微调后检索的收益大于反过来，因为一个懂领域语言的模型，把检索回来的资料用对的概率也更高。

长上下文加 RAG。 用 RAG 先筛出最相关的几十个文本块，再连同问题的完整上下文一起交给长上下文模型。检索负责"从一万个块里挑出五十个"，长上下文负责"把五十个块读全读透"。这种分工既控制了 token 成本，又缓解了检索环节"只给模型看零碎片段"的割裂感。当前多数生产系统的实际形态，就是这一种。

💡 我们的建议：预算有限时，投入顺序是"提示词优化 → RAG → 长上下文 → 微调"。前两项的性价比通常最高；微调放在最后，等你明确感知到"模型语言能力配不上你的领域"时再做不迟。

⚠️ 最贵的错误是路线错位：把事实知识硬灌进微调（知识更新即重训，成本失控），或者把行为需求甩给 RAG（检索再准也改不了口吻）。返工的代价是整个项目周期，而避免它只需要本节的一张决策图。

本节要点回顾

• 本质三分：RAG 注入知识、微调塑造行为、长上下文扩容单次记忆——先判断需求性质，再谈路线。
• 更新频率是分水岭：知识持续增长选 RAG，单份静态文档用长上下文，几乎不更新且重在风格选微调。
• 成本结构不同：RAG 付工程复杂度，微调付训练周期，长上下文付持续的 token 账单。
• 组合常见且有效：微调加 RAG 解决"懂行话加查资料"，RAG 加长上下文是当前生产系统的主流形态。
• 投入顺序建议：提示词 → RAG → 长上下文 → 微调，按性价比递进。

路线定了，接下来进入施工环节。第 2 章把 RAG 系统拆成知识库、检索器、生成器三大零件，逐一讲清每个零件的内部结构与工程取舍。