「我们要做个内部知识库问答」「把这两百页手册让 AI 学一下」，需求说得很轻，动手才知道方案有三条路，而且账算下来差很多。RAG、长上下文直喂、微调，这三条路我前后用过不止一次，这篇把什么时候该用哪个说清楚。
先把结论放前面：大部分场景选 RAG，资料少且固定用长上下文，只有让模型「学会说话方式」这种需求才用微调。下面是判断过程。
三条路各自是什么
RAG（检索增强生成）的思路是先查再答。用户提问时，系统先从你的知识库里检索出最相关的几段内容，塞进提示词，模型基于这些内容作答。知识库可以随时更新，跟模型本身完全分开。Anthropic 官方的定义是「从知识库检索相关信息，附加到用户提示词后面」。
长上下文直喂更简单，干脆不检索，把所有资料一次性放进上下文窗口里。Anthropic 官方写过一条明确的界线：知识库小于 20 万 token（大约 500 页材料）时，直接把整个知识库放进提示词是最简单的方案，不需要 RAG。
微调是另一回事。它不是给模型挂资料，而是用你自己的数据去继续训练模型，把某种风格、格式或者领域习惯写进模型参数里。注意方向：微调擅长改变模型「怎么说」，不太擅长给它灌「新事实」。
我的实际判断流程
第一步还是资料量。不到 500 页，直接长上下文，一条 API 就跑通了，别过度设计。Kimi 这类原生 1M 上下文的模型，连百万 token 的文件问答也有官方用法，把文件抽取出来塞进 system prompt 就能跑。成本方面，Anthropic 的 prompt caching 提到过，缓存能让延迟降一半以上、成本最多省 90%，这套数字在你自己家 API 上验证过再当真。
资料量超过这一个窗口，或者需要一个能持续更新的知识库，就上 RAG。RAG 的麻烦不在于跑起来，而在于「检索这一步经常不准」，这是 Anthropic 官方也承认的问题。他们给了一组实测数字：Contextual Embeddings 把 top-20 检索失败率从 5.7% 降到 3.7%；再叠加 Contextual BM25，失败率降到 2.9%，相当于减少 49% 的检索失败；如果再上 reranker，减少 67%。这些数字方向上很有参考价值，具体到你的语料，还是得自己搭个评测才知道。
那什么时候轮到微调？两种情况。一是你需要的输出有固定的格式和口吻，比如客服回复永远一个腔调、财报摘要永远一种版式，微调比反复在提示词里描述省事。二是任务本身对你的领域敏感，通用模型的术语用得别扭。但任何时候，如果你是想解决「模型不知道某个具体事实」，微调都不是正解，这种需求 RAG 才是对的。
几笔账：钱、时效、出错时怎么办
钱：长上下文按塞进去的 token 收费，同一批资料反复用，缓存能省很多。RAG 只在提示词里塞检索出来的几段，单次成本最低，但每次查询多一步检索，知识库本身要维护。微调最贵，而且每次资料更新都要重新训练。
时效：知识库每天在变的场景，比如政策文档、产品目录，只有 RAG 加增量更新能跟上。长上下文适合一个季度更新一次都嫌多的巴，微调在时效上是最差的。
出错时：长上下文错了不好定位；RAG 检索失败率有官方数字可对照，更可控（Anthropic 的失败率数字全是在 top-20 检索、成段评估下测的，你自己的 reviewed set 才是关键）。微调最不透明，做坏了不好回头。
选型速查
资料少、固定、懒得搭：长上下文直喂，先跑起来，遇到上下文 rot 再改。资料多、要更新、要溯源：RAG，重点花力气把检索做准。要固定输出风格或行业习惯：微调。三条都能叠：真实的项目里，RAG 检索 + 长上下文存对话历史 + 轻量微调调风格，是挺常见的组合，先别嫌重。
站内相关的几篇可以搭配看：基础概念看我之前写的那篇（233），Embedding 和向量是什么看（273），Kimi 文件问答的具体用法看（288），上下文缓存的省钱细节看（357），Few-shot 少样本跟这篇的边界也在那篇里画过（391）。