开场

“长上下文能不能替代 RAG”是一个很容易吵起来的问题。支持者会说：现在模型动不动几十万、上百万 token，上下文窗口越来越大，把资料都塞进去让模型自己读，不比切块、向量库、召回、重排简单吗？反对者会说：上下文再长也有成本、位置偏差、权限、版本、引用和可解释性问题，生产系统不能靠一次大塞资料解决知识治理。两边都有事实依据，但如果把问题问成“能不能替代”，答案会过于粗糙。

更准确的问题应该是：在哪些任务里，长上下文可以替代一部分 RAG；在哪些任务里，长上下文应该和 RAG 组合；在哪些任务里，RAG 仍然是不可替代的系统能力。长上下文是模型能力，RAG 是系统架构。一个解决“模型能读多少”，一个解决“资料如何被选择、治理、引用、更新、审计和复用”。二者有重叠，但不是同一层东西。

社区里很多讨论只看窗口大小，忽略真实账单和生产责任。长上下文确实降低了很多原来必须检索的痛点：一份长合同、一组会议纪要、一本手册、一个小型代码仓库、几个研究报告，现在可以直接放进模型里精读。可是当资料变成几万份文档、多个权限域、持续更新的网页、用户上传文件、历史工单、产品文档和数据库记录时，“全塞进去”马上遇到成本、延迟、可控性和可解释性问题。

这篇讨论不站队，而是给一个工程判断框架。重点看五件事：成本是否可接受，资料是否可控，答案是否可解释，数据是否新鲜，系统是否能长期维护。只要这五件事说清楚，“长上下文还是 RAG”就不再是口号，而是架构选择。

一、先把长上下文和 RAG 放在不同层级看

长上下文指模型一次请求可以接收更多 token。Google Gemini 官方文档介绍了百万级上下文能力，适合处理长文档、视频、音频、代码库和多模态资料。Anthropic、OpenAI 等模型也在不断扩大上下文窗口，并配合 prompt caching 降低重复前缀成本。这个方向是真实进步，不是营销噱头。

RAG 指 Retrieval-Augmented Generation，最初论文把可微检索和生成模型结合，让模型在回答知识密集任务时从外部文档中取信息。工程里的 RAG 已经远超过“向量库加聊天”。它包括资料接入、解析、切分、embedding、全文检索、向量检索、元数据过滤、rerank、权限控制、引用、版本同步、反馈评测和删除策略。RAG 不是一个模型参数，而是一套证据供应链。

两者解决的核心问题不同。长上下文解决“模型眼前能看到多少材料”。RAG 解决“哪些材料应该被放到模型眼前”。如果资料总量很小、可信、稳定、权限简单，长上下文可以让 RAG 的必要性下降。如果资料总量很大、动态变化、权限复杂、需要引用和审计，RAG 的价值反而更清楚。

一个常见误解是：RAG 只是因为模型上下文不够长才存在。这个说法只对了一小部分。上下文窗口短时，RAG 确实是把大知识库压缩进小窗口的办法；但在生产系统里，RAG 还有治理价值。它帮助系统知道资料来自哪里、属于谁、何时更新、谁能看、引用哪一段、删除后如何失效、评测时是否召回正确证据。这些不是把窗口拉长就自然出现的。

二、长上下文真正带来的变化

长上下文最大的价值，是减少检索边界带来的信息丢失。传统 RAG 会把文档切成片段，检索时只召回少数片段。切得太短，丢掉上下文；切得太长，召回不精；查询写得不好，关键片段可能召回不到；rerank 不准，正确证据可能排在后面。长上下文可以直接读取更完整的资料，尤其适合需要跨章节、跨文件、跨段落理解的任务。

比如审一份五万字合同，用户问“免责条款和违约赔偿之间有没有冲突”。如果只用 RAG，可能召回免责条款、赔偿条款和几个相似片段，但漏掉定义章节、适用范围和附录。长上下文把完整合同交给模型，更容易做全局分析。再比如读一个小型代码库，函数调用关系和配置分散在多个文件里，长上下文能减少“只看到片段，不知道全局”的问题。

长上下文还简化了开发体验。早期做知识问答，需要调分块、embedding、向量库、召回数量、重排模型、提示词和引用格式。现在如果资料只有几份文档，直接上传或放入上下文，开发速度更快，效果也可能更好。对原型、单次分析、临时调研和个人学习工具来说，这个优势很大。

长上下文也让报告生成更自然。模型可以一次看到多个来源，进行比较、归纳和结构化写作。相比只拿到若干碎片，它更容易理解材料之间的关系。这也是为什么很多用户觉得长上下文模型“终于像在读资料”，而不是像在拼搜索结果。

但这些优势有前提：资料数量有限，来源可信，用户有权访问，资料不需要频繁更新，成本和延迟可以接受，输出风险可控。一旦这些前提不成立，长上下文的便利会转化成系统问题。

三、成本：窗口变大不等于免费

长上下文最直接的代价是输入 token。把十份长文档每次都放进请求，就等于每次都为这些文档付费。即使单价下降，百万 token 级请求仍然会显著增加成本和延迟。对偶尔分析一份报告的个人用户，这个成本可能可以接受；对面向大量用户的产品，每个问题都塞几十万 token，账单很快失控。

RAG 的成本结构不同。它有前置成本：解析、切分、embedding、索引、存储、更新和评测。每次回答时，只把召回片段放入上下文，输入 token 通常更少。资料重复使用越多，RAG 越划算。长上下文适合一次性或低频读取，RAG 适合高频问答和大规模资料复用。

缓存改变了部分计算。OpenAI prompt caching、Anthropic prompt caching、Gemini context caching 都试图降低重复上下文的成本和延迟。如果固定资料反复使用，缓存可以让长上下文更有竞争力。比如同一份产品手册被多个问题连续使用，缓存命中后成本会下降。可是缓存不是万能。缓存要求内容和位置稳定，动态插入用户问题、不同资料组合、权限过滤和频繁更新都会降低命中率。

成本还不只是钱。长上下文会增加响应延迟、失败概率和调试难度。一个小问题如果需要模型读完整知识库，用户会感觉慢；模型上下文过大时，输出错误也更难定位。RAG 虽然有系统复杂度，但每次进入模型的证据更少，问题排查往往更具体：是没召回、重排错了、片段不完整，还是生成时没忠实使用证据。

一个实用判断是看资料复用率。如果资料只分析一次，长上下文优先；如果同一批资料要被许多用户反复问，RAG 优先；如果资料会被一组连续问题反复使用，可以用长上下文加缓存；如果资料超大但每次只问其中一小部分，RAG 更经济。

四、可控性：RAG 管的是资料入口，不只是检索

生产系统最怕“模型看到了不该看的资料”。长上下文方案如果简单地把一堆文档拼进请求，权限边界很容易变模糊。用户 A 有权看文档一，用户 B 有权看文档二，部门主管有权看汇总，外部客户只能看公开资料。每次构造上下文时，都要做权限过滤、版本过滤和数据脱敏。这个过滤逻辑本质上就是 RAG 系统的一部分。

RAG 可以把权限作为检索条件。每个文档、片段、来源、版本都有访问控制元数据。查询时先根据用户身份过滤可见范围，再进行检索和重排。即使使用长上下文，资料选择阶段仍然需要类似机制，否则模型可能被喂入越权资料。上下文窗口再长，也不会自动帮你判断组织权限。

可控性还包括版本和生命周期。产品手册更新、政策废弃、合同到期、网页改版、用户删除文件、权限收紧，这些都要求资料从索引和缓存中同步失效。RAG 系统通常会保存文档版本、索引状态和删除任务。纯长上下文方案如果依赖临时拼接，短期看简单，长期容易不知道某段回答用了哪个版本资料。

还有来源优先级。企业知识库里经常有正式制度、草稿、讨论记录、客服话术、旧培训材料和用户反馈。模型如果同时看到这些内容，可能把草稿当制度、把讨论意见当结论。RAG 可以在检索和重排层标记来源权重，把权威资料排前，把低可信资料作为背景或排除。长上下文如果没有证据筛选，噪声会直接进入模型注意力范围。

因此可控性问题的核心不是“能不能放进去”，而是“谁决定放什么进去”。只要资料选择、权限过滤、版本控制和来源排序仍然存在，RAG 的系统角色就还在。它可能不表现为传统向量库，也可能是结构化搜索、全文索引、规则过滤和长上下文组合，但它仍然是检索增强。

五、可解释性：用户需要知道答案从哪来

在生产应用里，用户常常不满足于“模型说”。他们会问：这个结论来自哪份文档？是最新版吗？哪一段写了？有没有相反证据？如果答案导致业务动作，例如退款、合同审查、医疗建议、财务分析、工程变更，引用和解释就不是锦上添花，而是责任边界。

RAG 天然更容易提供引用，因为它把片段作为证据单元召回。每个片段可以带文档 ID、页码、标题、URL、代码行号、表格坐标和版本。回答中每个关键结论都能关联到这些片段。OpenAI File Search、Google grounding、Anthropic web search 等官方能力都把 citations 或 grounding metadata 作为重要输出，说明可引用已经成为检索增强应用的基本要求。

长上下文也可以做引用，但难度更高。如果直接把整份资料放入上下文，模型需要自己定位出处。对于短文档还好；对于几十万 token 的资料，模型可能给出笼统引用，甚至引用到相邻但不支持结论的段落。引用准确性需要额外的定位和校验流程。也就是说，长上下文报告要做到可解释，通常仍要把资料分段、编号、记录位置，并在生成后校验引用，这又回到了 RAG 的证据管理思想。

可解释性还包括“为什么没答”。RAG 可以告诉用户：当前知识库没有召回到相关证据，或者只有旧版本资料，或者用户无权访问某些文档。纯长上下文方案如果只是把可用材料丢给模型，模型容易用常识补齐缺口。对严肃场景来说，知道“没有证据”比生成一个顺滑答案更重要。

社区里经常有人说“用户不看引用”。很多普通问答场景确实如此，但这不能推导出引用不重要。引用是给高风险场景、复盘、审计和纠错使用的。用户平时不看，不代表系统可以没有。出错以后，引用会决定团队能不能快速定位问题。

六、数据新鲜度：动态资料需要检索机制

长上下文擅长读给定材料，不擅长自动发现材料变化。模型不会自己知道官网刚更新了价格，也不会知道某份内部制度刚废弃。只要问题涉及最新事实，就需要检索、抓取、同步或 API 查询。把旧资料放进长上下文，只会让模型更认真地读旧东西。

RAG 系统可以围绕资料新鲜度建立流程：定时抓取网页，检测内容哈希，保存版本，增量更新索引，过期资料降权，删除资料撤销召回，回答中显示更新时间。网页搜索和 RAG 可以配合：开放互联网用搜索找最新来源，内部资料用索引找授权内容。长上下文可以在找到最新资料后负责精读，但它不替代资料发现和更新。

数据新鲜度还影响缓存。长上下文加缓存很诱人，但缓存命中的内容可能过期。价格、政策、模型列表、API 参数、漏洞通报、法律条款和市场数据都应该设置短 TTL，必要时强制刷新。RAG 中的缓存也有同样问题，只是更容易在文档版本和索引层管理。

对社区项目来说，一个务实原则是：如果答案需要“截至今天”的事实，就不要只相信模型记忆或旧上下文；如果资料来自外部网页，就记录抓取日期；如果资料来自内部文档，就记录文档版本；如果资料更新频繁，就不要把长上下文缓存当永久知识库。

七、长上下文的“位置问题”和注意力稀释

长上下文窗口变大，不代表模型能均匀利用所有位置的信息。Lost in the Middle 论文显示，相关信息位于输入中间时，模型表现可能比信息在开头或结尾时差。不同模型、不同任务和不同提示方式表现会变化，但这个现象提醒我们：把材料放进去不等于模型一定能用好。

注意力稀释也是实践中的常见问题。资料越多，噪声越多，模型越容易抓住显眼但不关键的段落，或者把不同来源的说法混在一起。尤其是长报告生成，模型可能在开头读到一个旧结论，在后面读到一个新结论，最后输出折中但不准确的说法。上下文越长，来源排序、标题分层、编号和证据摘要越重要。

RAG 在这里不是完美解法。RAG 也会漏召回、错召回、切块破坏语义。但 RAG 至少提供了一个可调的证据选择层。你可以评测召回率、重排效果、片段长度、混合检索和过滤条件。纯长上下文出错时，团队常常只能尝试重排材料、改提示词或减少输入，而难以知道模型到底忽略了哪段。

比较现实的做法是用 RAG 做“证据定位”，用长上下文做“局部精读”。先让检索系统找到相关文档和段落，再把完整章节、相邻上下文或整份关键文档交给模型。这样能缓解切块带来的割裂，也能避免把无关资料塞进模型。

八、RAG 的问题也不能回避

支持长上下文的人有很多合理抱怨。传统 RAG 确实经常失败。分块策略粗糙，表格和代码被切坏；embedding 模型不懂业务术语；向量召回找不到精确数字；BM25 找不到语义相近表达；rerank 模型慢又贵；引用位置不准；资料同步失败；权限过滤写在应用层导致泄漏风险。这些问题不是想象，而是很多团队真实踩过的坑。

更糟的是，很多所谓 RAG 只是“上传文件到向量库”。没有原文版本，没有解析质量检查，没有全文检索，没有引用校验，没有评测集，没有删除同步。这样的 RAG 被长上下文打败并不奇怪。用户上传三份 PDF，直接让长上下文模型读完，往往比粗糙切块效果更好。

所以讨论不能变成保护旧架构。长上下文迫使 RAG 系统提高标准。未来的 RAG 不应该只靠向量相似度，而应是混合检索、结构化元数据、语义重排、知识图谱、长上下文精读和引用校验的组合。RAG 的价值不在“向量库”，而在“证据治理”。

如果团队现在的 RAG 回答差，第一步不是争论要不要废掉它，而是拆问题：解析是否保留结构，切分是否尊重标题和表格，检索是否同时支持关键词和语义，重排是否可靠，召回证据是否完整，模型是否忠实使用证据，引用是否准确，评测集是否覆盖真实问题。长上下文可以临时提升效果，但不能替代这些治理工作。

九、什么时候长上下文可以替代 RAG

第一种场景是单次或低频资料分析。用户上传一份合同、一份财报、一本手册、一篇论文、一组会议纪要，希望得到总结、风险点、问答或报告。资料量在模型窗口内，用户有权访问，输出只服务当前任务。这里直接长上下文通常最简单，也最符合用户预期。

第二种场景是小规模资料集。一个项目只有十几份稳定文档，总量不大，更新频率低，权限简单。与其搭建完整向量库，不如先用长上下文和缓存。等资料增长、用户增加、权限复杂后，再引入索引和检索。

第三种场景是需要全局阅读的任务。合同审查、论文精读、代码库理解、长视频总结、跨章节一致性检查，都需要模型看到完整上下文。RAG 召回片段可能破坏全局关系。此时可以弱化 RAG，甚至不用 RAG。

第四种场景是原型验证。产品还没证明用户需求，不必先建复杂知识库。直接用长上下文验证交互、输出形态和用户价值，速度更快。只要团队知道这不是最终治理方案即可。

第五种场景是缓存命中很高的固定资料问答。同一份手册在一个会话或短时间内被多次提问，prompt caching 或 context caching 可以显著降低重复成本。这里长上下文体验很好。

这些场景的共同特点是资料边界清楚、规模可控、风险较低或可人工复核。长上下文替代的是“为了窗口限制而被迫做的简陋检索”，不是替代所有知识系统。

十、什么时候 RAG 仍然不可替代

第一，大规模资料库。资料达到成千上万份，甚至持续接入网页、工单、代码、表格和多媒体时，不可能每次都放进上下文。必须有索引、过滤、排序和增量更新。

第二，权限复杂。不同用户、团队、客户、项目和角色可见资料不同，RAG 的元数据过滤和权限控制是基础能力。上下文窗口不负责权限治理。

第三，引用和审计强需求。法律、财务、医疗、安全、合同、企业制度、工程变更等场景，答案必须能追溯来源。RAG 更适合管理片段、版本和引用位置。

第四，资料高频更新。产品文档、价格、政策、库存、日志、监控、新闻和市场数据需要持续同步。RAG 或搜索系统负责发现变化，长上下文只负责阅读已选资料。

第五，高并发产品问答。大量用户反复问同一知识库，RAG 把常用资料索引化更经济，缓存和召回也更可控。每次长上下文全量读取会浪费。

第六，多源冲突和来源治理。正式文档、旧文档、博客、客服记录、用户反馈和社区帖子混在一起时，系统必须按来源权重和版本筛选。RAG 的资料治理比纯上下文拼接更清晰。

第七，需要可持续改进。RAG 可以用问题集评测召回、重排、忠实度和引用准确。长上下文也能评测，但如果没有证据层，优化粒度更粗。

这些场景里，RAG 的意义不是节省 token，而是把知识从“临时输入”变成“可管理资产”。

十一、最稳的组合：RAG 负责找，长上下文负责读

实际项目里，最常见的答案不是二选一，而是组合。RAG 先根据问题、权限、时间和来源类型找到候选证据。长上下文再读取关键文档的完整章节、相邻段落或整份高价值材料。生成答案时，引用回到 RAG 管理的证据位置。这样既利用长上下文的全局理解，也保留 RAG 的可控性和可解释性。

可以把组合流程分成五步。第一，用户提问后，系统判断是否需要最新资料或私有资料。第二，检索层用混合检索找候选文档和片段，包含关键词、向量、元数据过滤和 rerank。第三，证据层把候选片段扩展成更完整上下文，例如同一标题下的完整章节、相邻几段、整张表或相关代码文件。第四，长上下文模型基于这些材料生成回答。第五，校验层检查关键结论是否有证据支持，引用是否准确。

这个组合有一个关键细节：不要只把召回片段塞给模型，也不要把全库塞给模型。召回片段负责定位，扩展上下文负责理解。比如用户问“退款政策是否覆盖虚拟商品”，检索先找到退款制度里的虚拟商品段落，再扩展到适用范围、例外条款和流程章节。模型看到的是完整证据环境，而不是无关全库。

组合方案还适合分层成本控制。便宜模型做查询改写和初筛，检索系统缩小范围，强模型或长上下文模型做最终分析。常见问题命中缓存，复杂问题走深度流程。这样比所有问题都用最大上下文模型更可持续。

十二、上下文成本如何算

很多团队在选型时只看模型标价，没有算完整链路。一次长上下文问答的成本至少包括输入 token、输出 token、缓存命中情况、工具调用、失败重试和延迟成本。一次 RAG 问答的成本包括检索服务、embedding 存储、索引更新、rerank、输入输出 token 和运维成本。两者要按任务量和复用率比较。

可以用一个简单口径估算。假设资料库有一百万 token，用户每天问一千次。如果每次都把全部资料放进长上下文，就是每天十亿输入 token，哪怕有缓存，也要考虑不同用户权限、不同资料组合和缓存 TTL。RAG 方案先索引资料，每次只取几千到几万 token，长期成本通常低很多。反过来，如果用户只做一次一百万 token 分析，搭建完整 RAG 反而不划算。

还要看失败成本。长上下文输出错误时，如果没有引用和证据定位，人工复核成本会增加。RAG 维护索引也有成本，但它让错误更容易归因：某个问题没召回目标文档，某个表格解析错，某个权限过滤漏了，某个重排模型把旧文档排前。可观测性本身也是成本的一部分。

缓存能降低长上下文成本，但缓存设计要贴合资料形态。稳定系统提示、固定手册、产品文档、同一会话内上传文件，适合缓存；个性化权限结果、实时网页、金融价格和新闻不适合长时间缓存。缓存命中率不应靠感觉，要在日志里记录。

最后要把人工和工程成本算进去。小团队用长上下文快速上线，省掉几周知识库开发，很可能是正确选择。大团队如果为了省 RAG 工程，把巨量资料每次塞进模型，后续账单和事故成本可能更高。架构选择不是技术洁癖，而是总成本权衡。

十三、可解释性如何设计

如果系统需要可解释性，最好从资料进入系统那一刻开始设计引用。每份文档要有来源、版本、标题、作者或责任人、更新时间、权限范围和可引用位置。每个片段要能回到原文页码、URL、标题层级、表格坐标或代码行号。生成回答时，关键结论绑定这些位置。

长上下文方案也可以做到这一点。做法是给输入资料编号和分段，例如 [D3-S2] 表示第三份文档第二节，表格用行列坐标，代码用文件路径和行号。模型回答时要求引用这些编号。生成后再用校验器检查编号是否真的支持对应句子。这样本质上是在长上下文上叠加一个轻量证据层。

不要让模型自由编造引用。很多模型会给出看似合理的页码、章节或链接，但并不一定存在。引用应该来自系统已知证据对象，而不是生成阶段凭空生成。官方 web search 和 grounding 工具把引用作为结构化 metadata 返回，正是为了避免纯文本引用失控。

可解释性也要服务用户体验。普通用户不一定要看到冗长来源表，但应该能点开关键来源。专业用户需要更完整证据链。社区帖、教程和内部知识库可以在段落后引用；合同、政策和财务分析最好给句级引用和证据表。引用展示不应成为视觉噪声，但底层数据必须存在。

十四、一个实践决策表

临时阅读一份长文档：优先长上下文。原因是资料边界清楚，搭建检索没有必要。

个人知识库几十份文档：先长上下文或轻量索引。资料增长后再升级 RAG。

企业知识库几万份文档：RAG 必须有。长上下文只用于精读候选资料。

客服 FAQ 高频问答：RAG 优先。常见问题缓存，答案要能引用制度和帮助文档。

合同审查单文件：长上下文优先。需要引用时加分段编号和校验。

合同库批量检索：RAG 优先。按客户、项目、条款、版本和权限检索，再用长上下文分析。

代码库问答小仓库：长上下文可行。大仓库用代码索引和检索，再读取相关文件。

最新政策或价格查询：搜索和 RAG 优先。长上下文只能读检索到的最新资料。

研究报告：组合方案。搜索找来源，RAG 管证据，长上下文读关键材料，校验器检查引用。

高风险业务决策：RAG 和审计优先。长上下文可以参与分析，但不能取代来源、权限和复核。

十五、常见争议逐条看

“上下文都一百万了，还要向量库吗？”要看资料总量和复用率。一百万 token 对单次输入很大，对企业资料库很小。向量库也不是唯一 RAG，全文索引、结构化过滤和图检索都可以是检索层。

“RAG 经常召回错，还不如全塞。”如果资料只有几份，全塞可能更好。如果资料很多，全塞不可持续。RAG 召回错应该改解析、检索、重排和评测，而不是直接否定证据治理。

“长上下文能给引用。”能，但要看引用是否准确。长输入中生成的引用需要校验。没有结构化证据对象，引用容易变成文本装饰。

“缓存让长上下文成本不是问题。”缓存降低问题，不消灭问题。权限差异、资料更新、动态网页和不同任务都会影响命中率。缓存还会引入过期风险。

“RAG 太复杂，小团队用不起。”对。小团队可以先不用完整 RAG，但至少要保留来源、版本和引用意识。等资料和用户增长，再把轻量证据层升级成正式检索系统。

“未来模型会自己解决检索。”模型能力会继续增强，但外部资料的权限、版本、更新、删除、审计和成本仍然是系统问题。模型越强，越值得给它更干净、更可信的证据。

十六、给小团队的落地建议

第一阶段，不要一上来建设大平台。选一个明确场景，比如产品手册问答、合同审查、客服制度助手或研发文档助手。资料少时，用长上下文快速验证输出质量。文档进入上下文前，至少保留文件名、版本、更新时间和分段编号。

第二阶段，加入轻量检索。可以先用全文搜索和简单元数据过滤，不必马上上复杂向量库。让系统能按标题、关键词、文档类型、更新时间和权限找到资料。对中文业务术语，全文检索常常比纯向量更可靠。

第三阶段，引入混合检索和引用。资料增长后，加入 embedding、rerank、片段扩展和引用位置。回答中每个关键结论都能回到原文。不要只看回答是否顺，要检查引用是否真支持句子。

第四阶段，做评测和成本观测。收集真实问题，标注理想来源。记录每次请求的检索命中、输入 token、输出 token、缓存命中、延迟和用户反馈。没有这些数据，团队会在“感觉长上下文好”或“感觉 RAG 好”之间摇摆。

第五阶段，按风险分流。低风险解释和摘要可以用便宜模型和长上下文；高风险结论走检索、引用、校验和人工确认；最新事实强制搜索或刷新；敏感资料强制权限过滤。不要让所有任务走同一条昂贵或粗糙链路。

十七、给成熟团队的架构建议

成熟团队应该把知识系统分成四层。第一层是资料治理，负责来源、权限、版本、解析、删除和更新。第二层是检索层，负责全文、向量、结构化过滤、重排和候选扩展。第三层是模型层，负责长上下文阅读、推理、总结和报告生成。第四层是评测审计，负责引用准确、事实忠实、成本、延迟和用户反馈。

长上下文模型放在第三层，而不是替代第一层和第二层。它可以显著提升阅读和综合能力，但资料治理仍要独立存在。RAG 也不要停留在“向量库”。它应该提供证据对象，告诉模型哪些资料可靠、哪些过期、哪些用户可见、哪些段落支撑当前问题。

成熟团队还可以做动态路由。短问题先检索少量片段；复杂问题扩展章节；需要全局理解时放入整份文档；超大任务分阶段摘要；高频资料使用缓存；高风险输出触发事实校验。路由依据不是模型名字，而是任务风险、资料规模、用户权限和成本预算。

评测要覆盖端到端。只评估 embedding 召回不够，只看模型回答也不够。要看正确来源是否被召回，引用是否支撑结论，答案是否忠实于证据，旧资料是否被降权，越权资料是否不可见，缓存是否过期，成本是否在预算内。RAGAS 等评测框架提供了 context precision、context recall、faithfulness、answer relevancy 等方向，可以结合业务场景扩展。

十八、结论

长上下文会替代一部分粗糙 RAG，尤其是单次长文档阅读、小资料集问答、原型验证和需要全局理解的任务。它让很多过去复杂的流程变简单，也迫使知识库系统重新思考切分和检索策略。

长上下文不能替代 RAG 的全部价值。只要系统涉及大规模资料、复杂权限、持续更新、引用审计、成本控制和可解释性，仍然需要检索和证据治理。RAG 的核心不是向量库，而是把资料变成可选择、可追溯、可更新、可评测的证据。

更务实的答案是：RAG 负责找，长上下文负责读，校验层负责证明。小场景可以先用长上下文，生产系统要逐步补齐资料治理、检索、引用、缓存和评测。架构不是为了证明某个技术更先进，而是为了让答案在真实用户、真实成本和真实责任下站得住。

十九、几个常见反模式

第一个反模式是“全量塞入式知识库”。团队把所有文档拼成一个巨大的上下文，觉得模型自己会挑重点。短期演示可能惊艳，长期会遇到权限、过期、成本和噪声问题。用户问一个很小的问题，系统也要读大量无关资料；某份旧文档混在其中，模型可能把旧规则当当前规则；某个用户无权看的内容如果被拼进去，就已经越过了安全边界。

第二个反模式是“向量库崇拜式 RAG”。团队不管文档类型，全部按固定长度切块，丢进向量库，然后期待模型回答准确。PDF 表格被切碎，代码函数被截断，制度条款和例外条件分离，网页导航和正文混在一起。这种 RAG 被长上下文击败，并不说明 RAG 没价值，只说明实现没有尊重资料结构。

第三个反模式是“无引用长文报告”。模型读了很多资料，输出一份很长报告，但没有来源位置，也没有证据表。读者看起来获得很多信息，实际无法复核。只要其中一个数字、日期或能力描述错了，团队很难定位错误来自哪个来源。研究和决策类系统尤其不能这样做。

第四个反模式是“缓存当知识库”。缓存是性能优化，不是事实来源。把一次长上下文输入缓存起来长期复用，如果没有版本和过期策略，就可能把旧资料固定成系统常识。缓存命中率很高不代表答案可靠，尤其在价格、政策、模型能力和法规场景中。

第五个反模式是“只看回答顺不顺”。很多 AI 知识库验收只看模型是否说得自然。真正该看的指标是：正确证据是否被找到，引用是否支撑结论，是否遗漏限制条件，是否拒绝无证据问题，是否遵守权限，成本是否可承受。流畅度是最后一层，不是第一层。

二十、从纯长上下文迁移到 RAG 的路线

很多团队一开始用长上下文没有问题，问题是资料增长后不知道怎么升级。比较平滑的路线是先加“证据编号”，再加“轻量检索”，最后加“完整治理”。不要等到系统已经混乱再重建。

第一步，在长上下文输入里给资料编号。每份文档有文档编号，每个章节有章节编号，表格有表名和行列，代码有文件路径和行号。模型回答时引用这些编号。这样即使还没有向量库，也能让答案可追溯。

第二步，把资料元数据保存下来。至少记录来源、标题、版本、更新时间、权限范围、文件哈希和解析状态。这个动作很小，但决定未来能不能升级。很多团队后来做 RAG 痛苦，是因为早期只保存了上传后的纯文本，没有原文、版本和权限。

第三步，加全文搜索。对中文企业资料来说，全文搜索很实用，尤其是产品名、错误码、制度名称、接口字段、合同条款和专有名词。它比向量检索更容易解释，也更容易调试。先用全文搜索缩小资料，再把相关章节放进长上下文。

第四步，加向量检索和重排。语义表达差异明显时，embedding 能找到关键词不一致但含义相近的资料。重排模型可以进一步提高候选质量。此时不要把向量分数当唯一依据，要结合来源权重、时间、权限和文档类型。

第五步，加评测集和引用校验。每次改切分、模型、检索参数或缓存策略，都用真实问题跑一遍。评测不仅看答案，还看证据。只要能持续看到召回和引用质量，系统就能迭代；否则架构再漂亮也只是凭感觉。

二十一、从传统 RAG 升级到长上下文增强 RAG

另一类团队已经有 RAG，但效果一般。此时不一定要推翻重做，可以把长上下文作为增强层。传统 RAG 失败常常不是因为检索概念错，而是模型拿到的片段太碎。长上下文能把片段周围的完整章节带回来，让模型理解证据环境。

第一种升级是片段扩展。检索命中某个片段后，不只把该片段放进上下文，而是扩展到同一标题下的完整小节、前后若干段、整张表或相关代码函数。这样能保留定义、例外、限制和示例。

第二种升级是候选文档精读。先用 RAG 找到三到五份最相关文档，再把这些文档的关键章节完整放进长上下文。对研究报告、合同审查和代码分析，这比只给十几个碎片更稳。

第三种升级是多阶段摘要。超大资料无法一次读完时，可以先按章节生成带引用的局部摘要，再把摘要和关键原文放进最终上下文。这里要注意摘要不能替代原文证据，最终结论仍应能回到原文。

第四种升级是上下文排序。把系统规则、用户问题、关键证据、次要证据、背景资料按稳定顺序组织。重要证据放在更容易被模型利用的位置，冲突证据放在相邻位置，过期资料明确标注。长上下文不是乱序仓库，材料编排会影响结果。

第五种升级是生成后校验。长上下文模型生成答案后，用检索系统回查每个关键结论。如果回查找不到支撑来源，就要求模型修订或标注不确定。这样能把长上下文的综合能力和 RAG 的可验证性连接起来。

二十二、验收指标：别让架构争论停在嘴上

要判断长上下文、RAG 或组合方案哪个更适合，最好用同一组真实问题比较，而不是靠会议争论。验收指标可以分四类：质量、可解释性、成本和运维。

质量指标包括答案正确率、关键限制条件覆盖率、拒答准确率和多来源冲突处理。很多系统只看“能不能答”，不看“该拒绝时是否拒绝”。知识库没有证据时，正确行为可能是说明找不到资料，而不是生成常识答案。

可解释性指标包括引用覆盖率、引用准确率、来源新鲜度和证据可打开率。引用覆盖率看重要结论是否有来源；引用准确率看来源是否真的支持句子；来源新鲜度看是否使用了最新文档；证据可打开率看用户能不能顺利回到原文。

成本指标包括平均输入 token、输出 token、缓存命中率、检索耗时、模型耗时、失败重试次数和单次问题成本。长上下文方案可能质量高但成本高，RAG 方案可能成本低但漏召回。没有成本数据，选型容易变成偏好。

运维指标包括新增资料可用时间、删除资料失效时间、权限变更生效时间、索引失败可见性、缓存过期策略和日志可追溯性。这些指标看起来不如模型回答酷，但它们决定系统能不能长期运行。

比较时要分任务类型。单文档精读、跨文档问答、最新事实查询、高风险政策问答、代码库理解、客服 FAQ、研究报告，每种任务可能有不同赢家。一个成熟系统可以按任务路由，而不是用一种架构覆盖所有场景。

二十三、社区里的实际判断口径

如果只是个人使用，长上下文优先。省掉知识库建设，直接上传资料，马上得到结果。只要重要结论自己再看来源，风险可控。

如果是小团队内部工具，先用长上下文加轻量证据编号。资料少、用户少、权限简单时，不要过度建设。早期重点是验证是否有人真的用、真实问题是什么、输出形态是否合适。

如果是企业内部知识库，RAG 是迟早要补的基础设施。可以晚一点做复杂向量检索，但不能晚做资料台账、权限、版本、引用和删除。否则后面迁移成本会很高。

如果是面向外部用户的产品，必须尽早设计成本和安全边界。外部用户的问题不可控，滥用和误用都会发生。长上下文请求的预算、频率、资料范围和缓存策略要被限制，RAG 的权限过滤和引用审计要进入架构。

如果是高风险行业，别把长上下文当最终答案机。它可以帮助阅读和归纳，但结论要回到可核验证据、业务规则和人工确认。可解释性和审计比回答速度更重要。

参考资料

1. Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks，https://arxiv.org/abs/2005.11401
2. Lost in the Middle: How Language Models Use Long Contexts，https://arxiv.org/abs/2307.03172
3. Google Gemini API 文档：Long context，https://ai.google.dev/gemini-api/docs/long-context
4. Google Gemini API 文档：Context caching，https://ai.google.dev/gemini-api/docs/caching
5. OpenAI API 文档：Prompt caching，https://platform.openai.com/docs/guides/prompt-caching
6. OpenAI API 文档：File search，https://platform.openai.com/docs/guides/tools-file-search
7. Anthropic 文档：Prompt caching，https://docs.anthropic.com/en/docs/build-with-claude/prompt-caching
8. Anthropic 文档：Context windows，https://docs.anthropic.com/en/docs/build-with-claude/context-windows
9. Ragas: Automated Evaluation of Retrieval Augmented Generation，https://arxiv.org/abs/2309.15217
10. Evaluating Verifiability in Generative Search Engines，https://arxiv.org/abs/2304.09848
11. FActScore: Fine-grained Atomic Evaluation of Factual Precision in Long Form Text Generation，https://arxiv.org/abs/2305.14251
12. OpenAI Cookbook：Question answering using embeddings，https://cookbook.openai.com/examples/question_answering_using_embeddings
13. Google Gemini API 文档：Grounding with Google Search，https://ai.google.dev/gemini-api/docs/grounding
14. Anthropic 文档：Web search tool，https://docs.anthropic.com/en/docs/agents-and-tools/tool-use/web-search-tool