2026年6月，Gemini 2.5 Ultra的百万token上下文窗口正式开放API调用。一个问题立刻浮出水面：我们之前费心搭建的RAG系统，会不会过时？
答案没那么简单。长上下文直投和RAG，是两种不同的信息处理方式，谁更好用取决于具体任务、数据量和你的预算。
知识库问答：长上下文更准，但账单很痛
假设你有一个500份PDF的技术文档库，总计约200万字。传统RAG的流程是：先建好索引，用户提问时，系统检索出最相关的3-5个段落，送给模型回答。
用Gemini 2.5 Ultra，理论上可以把整个文档库一次性塞进去。Google在2026年5月的基准测试显示，在多文档问答上，这种百万token模型的准确率比128k上下文配合RAG的方案高8-12个百分点。因为它不用“回忆”，直接在全量文本里找答案，召回遗漏自然少了。
但成本是道硬门槛。 根据公开定价，Gemini 2.5 Ultra的输入费用是$0.005/千token，输出是$0.015/千token。处理一次200万字（约300万token）的问答，仅输入成本就要$15。假设这是个日均1000次查询的客服系统，一个月下来，光API费用就超过45万美元。
而一个优化得当的RAG系统，单次查询的上下文通常控制在4千token以内，单次成本约$0.02，月成本大概600美元。
所以，对于那些内容不常变、查询量不大的知识库，长上下文直投既准又省事。但对于要服务海量用户的高频应用，RAG在成本上依然不可替代。一个务实的折中方案是“分层检索”：先用RAG做粗筛，把可能相关的文档从500份缩小到5-10份（约5万token），再交给长上下文模型精读。这样成本可控，准确性也比纯RAG好。
文档审阅：RAG的阵地没丢
法律合同、财报分析这类活，核心是深度理解和细节关联。模型需要反复比对不同条款，查找定义。
把一份500页合同（约50万token）直接扔给长上下文模型，看着省事。但实测发现，当文档超长时，模型对远距离细节的注意力会下降。比如，用Gemini 2.5 Ultra和Claude 3.5 Opus审查同一份复杂并购协议，如果关键定义条款和引用它的具体条款相隔超过30万token，模型有时会“忘记”定义内容，导致解释出错。
RAG在这里的优势是结构性的。你可以为文档建立精细索引：按章节、条款类型、关键实体来分块向量化。当需要查“董事会一票否决权”时，系统能精准召回所有相关段落，哪怕它们散落在文档各处。检索本身成了一个显式的、可控的推理步骤。
因此，在文档审阅、合规检查等场景，RAG架构短期内不会被取代。更可行的路径是用长上下文模型来替代RAG里的“重排序”或“精读”环节：先用轻量级检索召回较大的候选集（比如50个段落），再把这些候选集（约5-10万token）送入长上下文模型做最终分析。
代码理解：混合架构的试验田
理解一个代码库是另一个典型场景。一个中等规模项目的代码可能达数百万行（数千万token），远超任何模型的上下文窗口。纯粹靠长上下文直投不现实，RAG仍然是主力，但检索策略需要升级。
传统的基于文本相似度的检索，在代码场景效果不好。更有效的是结合代码图谱与语义检索：
- 语法解析：用Tree-sitter等工具将代码解析成抽象语法树（AST），构建函数调用图、类继承关系图。
- 语义索引：不仅对代码注释、函数名向量化，更对代码片段的“语义功能”进行描述（比如，用一个小模型为每个函数生成功能摘要），然后对这些摘要向量化。
- 混合检索：当问题如“用户登录流程有哪些风险点？”来临时，先通过关键词在AST中定位相关函数（如
login,authenticate），再通过语义检索在摘要库中查找“安全”、“加密”、“会话”相关的功能，最后合并结果送入模型。
长上下文模型在这里扮演深度分析的角色。当检索到的相关代码片段总和达到20万token时，可以全部输入长上下文模型，进行跨文件的漏洞分析或架构解读。
技术选型：一份实用清单
面对2026年下半年的技术环境，选择RAG还是长上下文，可以参考这个清单：
- 任务类型：高频、低成本、静态知识库 → 优先RAG，或考虑“RAG粗筛+长上下文精读”。低频、高精度、深度分析 → 直接使用长上下文模型，或RAG精筛后长上下文分析。超大规模、动态数据（如代码库） → 必须RAG，但需升级检索策略（图谱+语义）。
- 数据敏感性：如果数据完全不能出本地，目前支持超长上下文的商用API都无法使用。只能依赖本地部署的RAG系统，虽然本地模型的上下文窗口较小（通常32K-128K），但通过高效检索仍能解决大多数问题。
- 预算：严格评估API调用成本。长上下文模型单次调用昂贵，务必用批处理、缓存和分层策略控制总量。RAG系统的隐性成本在于索引维护、更新和检索算法优化。
- 开发复杂度：长上下文直投方案开发快，无需构建和维护向量数据库。但一旦需要处理超大规模数据或要求高召回率，RAG系统的复杂度和带来的优势将显现。
没有银弹。RAG和长上下文不是非此即彼，而是工具箱里两把不同规格的扳手。根据螺丝的形状和你手头的预算，挑最合适的那把，或者两把一起用。
