最近几个月我只要在技术群里冒个泡就一定会看到有人问“RAG 是不是已经被长上下文淘汰了”。问的人不光是刚入门的新手连某些做架构的老同事也在犹豫。原因也能理解Claude 把窗口干到了 200KGemini 一度堆上 1MGPT 系列也在不断拉长上下文看起来“把资料直接塞进对话”确实比“先检索再生成”更省事。我正好花了三个月重构一个企业知识库问答系统原方案就是RAG团队里为要不要直接砍掉检索层吵了好几轮。最后我们把纯长上下文、纯RAG、混合方案都推到测试环境里跑了一遍结论没这么非黑即白。这篇文章不站队我把成本、延迟、准确率、维护性这些实测数据摊开讲再给一套可以直接拿到生产环境做选型的判断方法。1. 长上下文凭什么让人觉得RAG要凉1.1 上下文窗口这半年来的“军备竞赛”先看数字。两年前主流模型的上下文窗口普遍是4K到8K token大概只能装几页纸超过这个量就得靠截断或分段处理。到了现在8K基本是入门级32K、128K、200K都成了常规配置面向特定场景的模型甚至宣称支持1M token。1M token是什么概念按英文一个token约四分之三个单词估算差不多是75万到80万个英文单词相当于好几本厚书。中文按词级切分的话大约就是几十万字的一份长篇合集。这个量级放在三年前根本不敢想。所以技术圈里出现了一个很自然的乐观推断既然上下文窗口能装下这么多内容那我为什么还要写一堆检索逻辑、维护向量数据库、调embedding模型、处理chunk切分直接把整本手册、整个文档库、甚至整个代码仓库丢进对话里然后让模型读一遍再回答不就行了吗这种思路在演示Demo里确实成立。你把某产品PDF全文丢进一个200K窗口的模型问它“许可证条款第7条第2款怎么写的”模型确实能给你一个基本靠谱的答案。1.2 长上下文在哪些场景里表现得确实好必须承认有一类场景长上下文是碾压级的好用那就是“一次性、小规模、高度综合性的信息消费”。举个例子一个实习生入职需要快速了解公司某个内部系统的整体架构。他把十几份核心设计文档合成一个几十万字的上下文让模型总结系统模块划分和数据流这种任务不需要精确到单一条款的检索模型读过一遍之后能给出非常流畅的综合概述。这个场景里RAG反而吃亏因为检索出来的片段是碎片化的模型看到的只是局部拼不出全局图景。同类场景还包括对单本长篇文档的多轮深层问答、代码仓库的总体理解、跨章节的对比归纳。长上下文在这里的核心优势是“上下文信息连续性”模型从头读到位前后关联不容易断。相比之下RAG会把内容切成几百到上千token的小块如果切片边界恰好落在关键信息中间那召回效果就跳水。这个坑我踩过太多次了后面会细说。1.3 为什么“窗口变长”不等于“问题解决”但Demo好看和生产可用之间的距离往往比人们想象的宽得多。窗口变长只解决了一个问题模型“理论上看得到”多少内容。而实际效果还取决于另外三个变量模型能不能在长内容里准确找到关键信息、推理时资源成本能不能扛得住、以及内容更新的时效性。这三个变量里任何一个失控长上下文的优势就直接被抵消。我见过不少团队做完POC之后很兴奋说“我现在可以不用RAG了”结果一压真实流量就傻眼。为什么因为真实的企业知识库根本不是“几份文档”而是几万个文件、持续更新的业务数据、不同部门的权限边界、反复修订的制度流程。这种情况下的长上下文不是灵丹妙药反而是另一堆麻烦的开端。接下来我把这几个硬伤逐个摊开。2. 长上下文在生产环境里的几个硬伤2.1 成本token不是免费的数据量一大钱包先扛不住很多兴奋于大窗口的人在算成本前都冷静得特别快。主流模型的输入定价在每百万token几美元到十几美元之间输出更贵。拿一个200K窗口的模型举例你每次调用如果足足塞满200K token一次输入成本大约是几美元。只调用一次问题不大但问答系统是一次对话要调用好多次的用户追问一次就得重新携带这份上下文除非做了缓存一个日活几千的内部工具一个月烧掉几万块很轻松。RAG在这边的账完全不一样。你只把检索出来的几个相关片段拼进上下文可能每次调用只有3K到8K token。同样日活几千的系统token开销可能只有长上下文方案的百分之五到百分之十。哪怕你为了准确率在RAG基础上多召几个片段开销依然小一个数量级。所以我跟团队说别管概念多性感先按真实流量把账单拉出来绝大多数团队当场就会重新考虑。这里贴个我常用的粗算口径方便你做快速评估方案每次调用平均输入token假设日活1000、每次对话3轮月成本量级粗略纯RAG3K - 5K约120万 - 150万token几美元到几十美元纯长上下文塞满窗口150K - 200K约4500万 - 6000万token几百到上千美元混合方案RAG召回长窗精读15K - 30K约450万 - 900万token几十到一百多美元上面是量级估算具体数字取决于你选的模型和是否命中上下文缓存。重点不是精确值而是比例关系RAG和混合方案在输入成本上低一到两个数量级这是架构选型里很难绕开的现实。2.2 延迟首token等待时间在长输入下藏不住成本还只是其一延迟是另一个更让人头疼的问题。长上下文模型在真正输出内容之前需要先把这几十万token的输入预填充进注意力机制里这个过程叫prefill。输入越长prefill耗时越长。我实测过往一个200K窗口的模型里塞入接近满窗口的内容首token返回时间经常超过10秒极端情况下能到30秒以上。在内部工具里30秒的等待体验已经接近“卡死”了放到面向客户的服务里基本不可接受。RAG为什么快因为输入短。检索本身虽然也有耗时但现代向量检索在百万级规模下返回结果通常是几十到几百毫秒是搜索领域里的老本行。算上召回、重排、拼装上下文RAG的首token延迟通常能压在2到5秒内体感要好得多。如果再用缓存、流式输出等手段优化甚至可以做到1秒左右出字。当然你可以给长上下文方案上推理缓存来降低成本、提升速度但缓存命中率取决于用户问题是否集中在静态知识上真实场景里很多人问的是不断变化的内容缓存就失效了成本优势也跟着消失。2.3 “中间迷失”不是传说我自己复现过长上下文最容易被POC阶段忽略的问题是精度。业界常说的Lost in the middle现象指的是模型对长输入中间部分的信息利用率明显低于开头和结尾。我一开始也以为这是实验室里的说法直到我自己做了一个简单实验拿一份35万字的混合文档集把某条关键政策条款放在整份文档中间偏后位置然后问模型“关于报销额度上限的最新规定是什么”。纯长上下文方案给出的答案引用了开头章节里已经被后续政策覆盖的旧数值。我又换了一种问法明确提示“请检查文档中部的内容”结果依然不够稳定。后来我跟用1M窗口模型的同行聊他们也遇到过类似问题——窗口大了模型“看”是都看到了但推理时注意力分配并不均匀。RAG这边反而是另一套逻辑它是检索系统帮你把最可能包含答案的几个片段找出来然后喂给模型做精读。虽然模型看到的上下文更短但关键信息被显眼地放在它面前。同样是查政策条款RAG方案在我的测试里准确率明显更稳。注意我这里不是说RAG一定更准因为检索召回质量太差时一样翻车。但在“已知答案存在于知识库某处、位置不确定”的场景下RAG把问题转化为“在小范围内找”长上下文则要求模型在巨大范围内自己搜索——后者目前依然更不可控。2.4 知识更新和审计全量塞进去之后的维护噩梦第三个硬伤是更新成本。RAG模式下新知识进来之后你要做的事是给新文档切片、生成向量、写入向量库整个链路是增量的。旧文档修订也只替换受影响的部分。长上下文模型不是这样你把知识库增量更新进去要么重新组装一份完整的上下文后再灌一遍要么维护一套复杂的增量拼接逻辑。前者每次更新都是一次新的全量成本后者实施起来远比看起来复杂。还有一个容易被忽略的问题审计。很多企业内部知识库涉及合规审计要求追踪“模型回答的依据是来自哪一份文档、哪个版本、哪个段落”。RAG天然能提供这种溯源因为检索结果就是明确的一组片段列表我可以把文档ID、版本号、来源路径都记录下来。长上下文方案在这个问题上非常难办模型读了整包内容之后答对了你也不知道它依据的是哪一页答错了你更没法回溯是哪份文档误导了它。这一点在金融、医疗、法律这些强监管行业里几乎是不可接受的硬伤。3. RAG真正不可替代的地方动态数据、权限与溯源3.1 数据一变RAG立刻知道长上下文得重新灌聊完长上下文的短板再看看RAG让人舍不得放弃的能力。最大优势是动态数据。拿电商客服场景举例库存、价格、促销规则这些都是按小时变化的。RAG模式下数据库更新后向量库跟着同步用户问到新品或最新活动时检索到的就是最新状态。长上下文方案就尴尬了你总不能每次库存变动都重新把整个知识库灌进窗口吧就算技术上可以做经济上也扛不住。我做过一个更细的实测把一份知识库放在RAG架构里在中午更新了退换货政策下午就有用户问相关问题RAG方案正确引用了新政策。而纯长上下文方案因为上下文还是早上组装的那份回答的还是旧政策。这在生产环境里是致命的用户的信任感会瞬间崩塌。3.2 权限隔离RAG能做行级控制长上下文做不到另一个深水区是权限。企业知识库不是所有人都能看所有内容。销售不该看到法务内部评审意见兼职员工不该接触核心经营数据。RAG架构里权限控制可以通过两层实现检索前在元数据层过滤哪些部门、哪些岗位能访问哪些文档检索后在结果层二次过滤兑现所有命中结果的可见性。这两层过滤可以在向量库查询阶段就完成也可以在做重排的时候顺手过滤。总而言之控制面非常清晰。长上下文方案呢理论上也可以在拼装上下文之前做权限过滤但实际场景里你要把“每个用户都有权看的子集”实时拼装成上下文这等于把RAG的过滤逻辑做进了上下文构建层而且还要承担巨大token开销。我见过一些团队试图用“给不同角色准备不同上下文包”的方式解决最终因为组合爆炸和更新同步问题放弃了。企业知识库的权限维度通常是多维的部门和岗位交叉不是简单分几个包就能覆盖。3.3 事实核查与引用这笔账必须算清楚再就是溯源问题。RAG能返回来源引用这是它帮我挡住过很多业务方追问的设计。比如一个金融风控团队问“哪条监管规则要求保留交易记录五年”RAG方案可以明确回答“依据的是《某某规定》第X条”并附上原文片段。在合规场景这种“答完还能指给你看”的能力是业务上线的前提。长上下文不是完全不能引用但它的引用往往是模型“记得”自己读过某段话位置和版本准确性无法保证。我测试过让长上下文方案输出引用页码它在不同轮次数次给出了不同的页码。3.4 企业知识库的真实形态不是几个文档是几万个文件退一步看企业知识库的真实体型和长上下文窗口之间的差距可能比很多人以为的更大。我跟几个朋友聊过他们的实际数据量一个有几百名员工的中型公司光内部SOP、产品手册、项目文档、制度文件加一起就能到两三万个文件折算成文字量动辄上千万token。这是什么概念哪怕你用的是市面上窗口最大的模型也只能装下其中一小部分而且这个数据量还在持续膨胀。RAG从设计上就是为解决“海量内容中选择性获取”而存在的它不要求你把所有东西都塞进窗口而是先把候选范围缩小到几十个片段再交给模型。这不只是工程妥协更本质的问题是模型推理时根本不需要看那么多不相干的内容多余上下文只是负担。4. 我实际采用的混合架构长上下文和RAG是这样协作的4.1 分层路由先判断问题该走哪条路在经历了上面那堆对比测试之后我最后的决策不是二选一而是做了一套分层路由。核心理念是让用户的问题先经过一个分类器判断它是“需要全局综合理解”还是“需要精确命中某段知识”。前者走长上下文路径后者走RAG路径。分类本身可以用一个轻量模型做意图识别也可以用规则和关键词辅助。我在生产里用的是一个小型分类模型输入是用户query和几个业务标签返回的是路径选择准确率在九成以上成本很低。这个分层的收益很明显。全局综合问题比如“分析一下我们产品目前主打卖点和用户痛点的关系”这类问题把几十份分析报告塞进上下文让模型综合效果确实比RAG好。而精确命中问题比如“第三方支付接口的鉴权失败错误码有哪些”这类问题用RAG召回对应开发文档片段再回答又快又准。我以前试图用一种方案通吃所有问题后来发现本质上是在要求单一方案同时拥有“全局视野”和“精确定位”两种互斥的能力这不符合模型当前的特性不如把问题拆开处理。4.2 小块召回 长窗精读把两个方案的长处拼起来第二步是在RAG路径内部也引入长窗口思路而不是用传统的一锤子式“检索并返回三个片段”。我把检索流程设计成两段式第一段是快速召回。用embedding向量检索取回候选片段数量稍微放宽top-k从传统的5到10扩大到20到30。这个阶段的核心目标不是找到标准答案而是“别漏掉可能相关的内容”。因为召回阶段漏了信息后面再怎么精读都补不回来。第二段是长窗精读。把检索回来的20到30个片段可能总共8000到15000token拼成一个精读上下文交给模型做最终回答。这个上下文体量已经远小于动辄几十万token的全量方案但比传统RAG塞三五个片段要充裕得多足以让模型在多个相关片段之间做交叉比较。实测下来这套“小块召回 长窗精读”方案的准确率比传统RAG提升了至少10个百分点同时成本只比传统RAG高一点点远低于纯长上下文方案。它相当于把RAG的“定位能力”和长上下文的“综合阅读能力”做了一个折中模型读的内容变多了但仍控制在合理成本区间内。4.3 调参记录chunk、top-k、窗口大小怎么配参数配置直接决定这套混合架构的天花板我把几个关键参数的调参过程记录下来供参考。先看chunk size。切块太小比如小于200 token上下文碎片化严重召回时经常只抓到半句话精读模型也缺上下文回答容易出现张冠李戴。切块太大比如超过1500 token单块包含太多冗余信息向量召回时相似度被无关内容稀释该命中的块反而排到后面。我在当前项目里最终用的是800到1200 token的块中文场景下偏向1000 token左右英文场景可以放到1200。这不是绝对标准取决于你文档的语义密度但我建议起步时先按这个区间试再根据召回命中率做微调。再是top-k。传统RAG里top-k往往取3到5混合架构里我建议放宽到20到30。为什么因为后续有长窗精读兜底多召回来的噪声片段可以由模型在精读阶段重新评估但少召回一个真正相关的片段则完全没有补救机会。召回率优先是这一步的指导原则。代价是要多付一些token费但相比准确率提升这个成本是划算的。最后是精读窗口大小。我用的是8K到16K token的窗口这已经足以装下20到30个片段加一部分提示词。如果你的文档之间有大量交叉引用可以适度放宽到24K但超过这个值收益递减因为噪声也开始混进来了。这个参数不需要像chunk那样频繁调定下来之后基本可以稳定运行。4.4 实测数据混合方案 vs 纯RAG vs 纯长上下文为了说服团队里坚持纯长上下文方案的同事我把三个方案压在同一批测试集上做了对比。测试集是从真实客服记录中抽取的300个问题涵盖政策查询、故障排查、跨文档对比三类答案由业务专家手工标注。评测指标用了准确率、首token延迟和单次调用成本三个维度。结果如下数字做了脱敏处理量级关系不变方案准确率首token延迟P95单次调用成本相对值纯RAGtop-k582%2.1秒1x纯长上下文塞满全部文档78%14.6秒约80x混合方案召回top-25 长窗精读93%3.4秒约6x表格里的成本是相对值重点看两件事第一纯长上下文在准确率上并没有赢反而因为Lost in the middle的问题略低于纯RAG第二混合方案把准确率拉到了三个方案里的最高同时成本和延迟都控制在可接受范围。这个结果基本终结了团队内部的争论。5. 选型决策框架你的项目到底该用哪种5.1 五张场景速查卡文章写到这里很多人会问那我做新项目的时候第一版到底用哪种我给一个简化判断逻辑按场景对号入座。第一类场景一次性分析、数据量可控、不需要持续更新、允许较长的响应时间。典型代表是离线文档总结、架构梳理、代码库理解。这种情况直接用长上下文省掉RAG整套基础设施效果还能更好。第二类场景面向用户的高频问答、需要低延迟、数据有一定更新频率。典型代表是客服机器人、内部帮助台。这种情况必须以RAG为主混合长窗口精读做增强不要碰全量塞上下文方案。第三类场景数据量大且持续增长、需要权限控制、要求答案带引用。典型代表是金融和医疗合规系统、大型企业知识库。这种情况不但要用RAG还要在设计之初就把权限过滤、版本管理、溯源记录做进检索层长上下文只能作为辅助手段用于特定全局问题。第四类场景混合型知识库既有重量级的综合报告也有大量碎片化FAQ。典型代表是绝大多数中大型企业的内部知识平台。这种情况用我上一节说的分层路由不同类型的问题走不同路径组合方案是最优解。第五类场景早期验证型Demo连正式数据都还没接到。这种情况别折腾用纯长上下文先跑通再说因为RAG的复杂度在这个阶段纯属负担。5.2 成本估算表三种规模下的开销为了让决策更直观我把同一套知识库推理负载放在三种不同规模下按月度token消耗量做了张估算表。假设模型每百万输入token定价10到15美元输出2到4美元取中间值计算实际价格随市场波动看的是量级关系数据规模日对话量纯RAG月token消耗纯长上下文月token消耗混合方案月token消耗小500份文档约20万token总量100次对话约200万约6000万约800万中5000份文档约200万token总量1000次对话约1500万约1.2亿受窗口限制需分片处理约6000万大5万份文档约2000万token总量5000次对话约6000万无法直接全量需额外分片方案成本失控约2.5亿纯长上下文方案在数据量超过窗口容量以后不是“贵”的问题而是“没法直接做”的问题必须引入额外的分片、路由逻辑本质上就是变相RAG。这一点在架构选型时特别容易被忽略很多团队只算了窗口之内舒服的账没算窗口装不下的账。5.3 几个常见的“我以为”和实际情况的落差在实际指导过数支团队之后我发现几个反复出现的认知偏差这里把最典型的讲一下。第一个偏见是“大窗口零延迟”。有同事觉得模型支持200K那处理200K输入就应该和处理2K输入差不多快。实际上是完全不同的体验曲线我在前面的延迟数据里已经展示过。输入长度接近窗口上限时首token延迟会显著上升这是模型架构决定的不是哪家厂商偷懒。第二个偏见是“RAG性能差”。很多被Demo阶段伤过的人说RAG不靠谱但仔细复盘会发现问题通常出在chunk切太随意、embedding模型选错、top-k设得太小这些工程细节上。RAG的准确率高度依赖检索质量可一套调好的RAG链路准确率完全可以与长上下文持平甚至更好我的测试数据证明了这一点。第三个偏见是“既然长上下文那么强RAG迟早消失”。技术选型不是概念辩论而是约束条件下的取舍。你带着成本约束、延迟约束、数据更新频率、权限矩阵、审计需求这些真实约束再看会发现RAG解决的是工程系统问题长上下文解决的是模型能力问题二者在时间轴上会有交集但不存在简单的替代关系。6. 我现在的判断与个人经验最后讲一点个人体会。这三个月的重构做完我最大的感慨是讨论RAG和长上下文哪个淘汰哪个本质上是在拿问题找锤子。真实世界的问题形态是多样的有的问题需要全局视野有的问题需要精确定位有的问题需要低延迟高并发有的问题需要严格溯源。指望单一方案覆盖全部要么在成本上被打爆要么在准确率上被质量评审打回。我现在的默认做法是新项目上来先用纯长上下文快速跑通业务逻辑确认价值一旦数据量增长、并发上升、或者出现权限与溯源要求就引入RAG做检索层再按我前面说的“小块召回 长窗精读”方式把两条路线结合起来。这套组合目前在我们的生产环境里稳定运行了两个月准确率、成本、延迟都在可接受范围内。如果你也在做类似选型我的建议是别急着站队先把你自己的测量数据跑出来。准备一套带正确答案的测试集分别跑三个方案记录准确率、延迟、成本这三个数字让数据替你做决定。这比在群里讨论“RAG是不是凉了”有用得多。
