随着大模型的上下文窗口扩展到数十万甚至百万 Token，一个问题被反复提起：既然模型能一次读完整个知识库，还有必要费力搭建 RAG 吗？ 答案取决于你的数据规模、使用频率和对准确性的要求。在大多数生产场景中，两者不是二选一，而是互相补充。

两种方案的基本思路

  • 长上下文：把相关文档全部放进提示词，让模型自己阅读和寻找答案；
  • RAG：先根据问题检索出最相关的少量片段，只把这些片段交给模型。

逐项对比

成本

长上下文方案每次请求都要为全部文档付费。如果同一批文档被频繁查询，成本会迅速累积。部分服务商提供的提示缓存功能可以降低重复部分的费用，但并非所有场景都适用。RAG 每次只发送少量片段，单次成本低得多，代价是需要建设和维护检索系统。

延迟

模型处理输入需要时间，几十万 Token 的输入会让首字延迟明显增加，影响交互体验。RAG 的检索环节通常只需要几十到几百毫秒，加上较短的输入，总体响应更快。延迟优化的更多方法见降低大模型应用延迟。

准确性

长上下文让模型看到完整信息，适合需要综合理解的任务。但信息量越大，模型越可能忽略中间部分的细节，详见上下文窗口的能力边界。RAG 把相关内容集中呈现，但如果检索没有命中，模型就无从回答。

规模

再长的上下文也有上限。企业知识库动辄数万份文档，远超任何模型的窗口，RAG 是唯一可行的方式。

可追溯性

RAG 天然知道每个片段的来源，便于在回答中标注出处。长上下文方案也可以要求模型引用，但需要额外的设计来定位原文位置。

权限控制

RAG 可以在检索阶段按用户权限过滤文档。长上下文方案需要在组装提示词前自行做好过滤，否则可能把无权查看的内容交给模型。

什么时候用长上下文

  • 单份或少量文档的深度分析，如审阅一份合同、总结一本书、对比几份报告；
  • 一次性任务，不值得为此建立索引；
  • 需要全局理解和跨章节推理的问题；
  • 文档总量明确小于窗口且查询频率不高。

什么时候用 RAG

  • 文档规模大、持续增长；
  • 高频查询、成本敏感的在线服务；
  • 需要严格的权限控制和来源引用；
  • 知识频繁更新，需要随时生效。

组合使用：两全其美

在实际系统中，很多团队采用组合方案：

  1. RAG 检索文档级而非片段级：先用检索找到最相关的几份完整文档，再把这些文档整体放进长上下文，既缩小范围又保留完整语境；
  2. 先检索后扩展：检索命中某个片段后，自动把它前后相邻的内容或整个章节一起送入模型；
  3. 按任务分流：事实型问答走 RAG，深度分析型任务把用户选定的文档放入长上下文。

长上下文能力的提升，让 RAG 可以“检索得粗一点”，对切分和召回精度的要求降低，系统整体更加稳健。

小结

长上下文没有让 RAG 过时，而是改变了 RAG 的设计方式。小规模、低频、需要全局理解的任务适合长上下文；大规模、高频、需要权限和溯源的场景依然离不开 RAG。最实用的做法是把两者结合，用检索缩小范围，用长上下文保证语境完整。