RAG 是不是已经被长上下文淘汰了这个问题我最近一个月至少被问了十几次。问的人里有刚接触大模型的开发新人有正在评估企业知识库的负责人也有正在带 RAG 项目的团队领导。大家的疑问其实很一致上下文窗口都做到几十万甚至上百万 token 了把资料全塞进提示词里不行吗为什么还要搞一套“检索增强生成”这么麻烦的流程先说我的结论也给整篇文章定个调长上下文确实改变了局面也确实“吃掉”了 RAG 的一部分使用场景比如临时分析一份完整文档、一次性读入一本书籍这类需求。但它远没到淘汰 RAG 的程度。恰恰相反真正稳定运行的企业级知识库现在几乎都是“长上下文 RAG”混合着来。这篇文章我会把两组技术放在同一张桌上对比从成本、效果、可维护性三个维度讲清楚再给出一套可以直接照着做的本地 RAG 知识库落地流程最后把我踩过的坑和排查经验全部摊开。内容适合正在做 RAG 实战项目、或者在纠结要不要上知识库的工程师参考。1. 长上下文来势汹汹确实吃掉了一部分 RAG 的活儿1.1 长上下文强在哪能把一本手册完整塞进提示词先给不熟悉概念的朋友补个基础长上下文指的是大模型在单次对话里最多能“看到”的文本量。三年前主流模型只有 4k token换算成中文大概就是几千字稍长一点的文档都放不下。如今主流模型动辄 128k、200k甚至到了 1M token 级别。什么概念一本几十万字的书能整本放进去几十份 PDF 也能连续贴进同一个对话框。这带来的体验是颠覆性的过去要拆文档、做索引、配检索、调召回现在好像只要把文件“拖进对话框”就行了。很多做 RAG 的团队也开始怀疑自己之前那一套是不是白做了。这种怀疑有道理因为确实有一批场景被长上下文“接管”了。比如一份合同的合规审查、一篇论文的精读、一段长代码的逐行解释这些任务资料就是一份文档内容不会中途变也不需要权限隔离把完整上下文给模型就是最简单可靠的方案。1.2 把上下文塞满之后我实际遇到的四个问题但接下来是我在真实项目里反复踩到的一面。第一是成本。按目前商用 API 的大致价格线读入百万 token 并不是“免费午餐”一次包含百万 token 输入的请求单轮成本就可能达到几十元甚至更高。RAG 方案通常只要十分之一甚至百分之一的成本关于这笔账下一章我专门算给大家看。如果是自建模型服务器那就不是钱的问题而是显存和响应时间的问题。上下文越长每轮请求需要处理的输入就越多首字延迟肉眼可见地拉高。第二是“迷失在中间”。当输入文本很长时模型对中间位置内容的注意力会被稀释这是我实测很多次都稳定复现的现象。相关资料放在提示词开头或结尾效果往往不错放在中间答案质量明显下降。你没法保证用户想问的内容恰好出现在文档的头部或尾部这是长上下文方案绕不开的注意力短板。第三是没有真实来源约束。模型读完全文之后可能把文中互相矛盾的片段混在一起或者基于“读过的内容”进行推理编造。它给出的回答无法指出“具体出自第几页第几节”出了问题你很难追责。对聊天玩具来说无所谓但企业场景里“答案可审计”往往是刚需。第四是内容更新问题。今天上午的文档版本和下午的新版本一起塞进上下文模型并不知道该以哪个为准。长上下文本质上是“一次性快照”它不维护索引也没有版本概念。这些问题恰好都是 RAG 的强项。长上下文不是不好而是它擅长的事和很多人以为的不太一样。2. RAG 的核心价值不是省窗口而是让答案可以被验证2.1 从“背字典”到“查字典”检索解决的是知识供给我经常用一个比喻解释 RAG 和长上下文的关系长上下文是逼着人把字典背下来再答题RAG 是遇到不认得的字去查字典。人的工作记忆是有限的把整本字典背下来既累又不稳但查字典很快、很准而且查到哪一页清清楚楚。RAG 全称是检索增强生成流程说起来也不复杂先把知识文档切块、向量化存进向量库用户提问时把问题同样向量化检索出最相关的几个片段最后把这些片段和问题一起交给大模型生成答案。这套范式在 GPT-4 时代之前就是各大知识库产品的主流实现到现在依然是“rag 知识库”“rag 框架”这些搜索热词背后的核心逻辑。检索解决的不只是“省提示词空间”的问题而是“知识供给”的问题。当知识量超过上下文窗口、当知识在持续更新、当不同用户只能看不同范围的资料时就需要一个机制来决定“到底把哪些知识放到模型面前”。这个机制在 RAG 里叫检索在长上下文方案里其实是不存在的或者说只能靠人工去挑选而这在规模上去之后根本没法做。2.2 成本账一次问答差几百倍我按具体数字把这笔账算清楚。假设有一套企业技术手册总共 1 万页平均每页 700 token全库大约是 700 万 token。先用长上下文方案每轮提问都把这 700 万 token 塞给模型。按当前商用 API 每百万 token 输入大约几十元的价格区间粗算仅输入费用一次对话就要几十元。如果企业常驻几十个用户同时问光是模型输入开销就是一笔不小的数字。RAG 这边的做法是提前把这 1 万页做好切分和向量化用户提问时先从向量库里检索取回最相关的 5 到 20 个片段每个片段几百到一千 token再加上问题本身一次输入通常在 1 万 token 上下。按同样的价格算下来一次对话的材料成本只有几厘钱。差距按百倍计不夸张而且 RAG 的答案是“按需取数”响应延迟更容易控住。延迟差异同样值得说。输入 1M token 的模型在生成第一个字之前要先处理完整个输入这个“预填充”阶段在很多模型上要花几十秒。RAG 检索通常在几百毫秒内完成给模型的输入只有一点点首字延迟自然低得多。当然这些数字会随着硬件和模型迭代变化但数量级的差异不会消失。换句话说长上下文解决“能不能读”RAG 解决“读多少划算且高效”。2.3 权限隔离、实时更新、来源可查这三件事长上下文做不了除了钱和速度还有三件事是 RAG 做得到、但长上下文很难做到的。第一是权限隔离。一个企业里销售看销售资料研发看研发资料财务文档只对财务开放。RAG 可以在检索层按用户身份过滤索引范围比如给每个文档打上标签查询时自动加过滤条件。长上下文方案就得在调用模型之前先把文档按人切好人一变就要重切完全没有动态控制能力。第二是实时更新。文档发布、修改、废除在 RAG 体系里只需要修改对应文档的向量记录几秒钟就能让整个知识库用上最新内容索引不用动模型也不用动。长上下文每次都要把最新文档重新组装进提示词组装逻辑一旦复杂运维就成了灾难。第三是来源可查。RAG 生成答案时可以把命中的原文档标题、页码、段落一起带出来用户点开就能核对原句。这也是为什么 wiki 类知识库特别喜欢用 RAGwiki 文章彼此独立、更新频繁天然适合段落化索引而不适合一遍遍全量贴进上下文。可以说只要项目里出现了“知识库”三个字大概率还是离不开 RAG。2.4 一张对比表长上下文、RAG、混合方案到底该选谁为了不让讨论停在抽象层面我自己做方案选型时常用下面这张表今天一并放出来。对比维度纯长上下文纯 RAG混合上下文 检索临时分析单份长文档很适合直接贴没必要多此一举可以但复杂度高大规模长期知识库不现实成本爆炸适合检索生成适合再加缓存策略答案来源可审计弱模型不返回出处强可带回原文块强可控性更好权限与私有数据难以动态隔离适合按标签过滤适合过滤后进上下文实时更新时效性靠重新组装很累适合增量写索引适合索引即最新对检索结果漂移的容忍度无检索问题但会迷失上下文依赖检索质量差就飘通过重排和路由兜底响应成本高尤其是长输入低输入短中看路由策略你的项目落在哪一行直接决定选择。不过我更推荐最后一行之后该有的思路混合。聊到落地时大家真正该关心的是怎么把两者组合出最优解而不是站队。3. 落地时我不选边站上下文做理解RAG 做供给3.1 先用一张决策清单判断你的项目到底该用哪套在动手之前我会先问自己四个问题。第一知识总量有多大如果总量不超过模型上下文窗口的合适比例而且只是几份零散模板纯长上下文最省事。比如单份合同审查直接贴不要为了造轮子而造 RAG。第二知识更新频率高不高资料每周都在变或者来自多个业务系统那快照式的长上下文就很难受RAG 的增量索引机制更合适。第三用户之间有没有权限差异不同角色看到不同数据首选 RAG 并在检索层做过滤。第四答案是否需要附来源法务合规、医疗技术答复、企业汇报都要求“这句话有据可查”RAG 能给出来源块长上下文给不出。这四个问题走下来大方向基本定了。然后我会进一步把资料按“适合全文直读”和“适合检索”分桶官方白皮书放直读桶内部 SOP 和 FAQ 放检索桶。这样在系统里可以同时存在“直接喂上下文”和“查询检索”两条通路后续维护也清楚。3.2 混合架构的两种实用姿势路由分流和检索增强混合方案里我实际用得最多的有两种姿势。第一种叫路由分流。系统先判断用户问题属于哪一类如果只是闲聊、常识、或者模型自己就知道的内容直接把问题交给模型答不触发检索一旦识别出问题涉及内部资料、专业知识或用户明确指定要查知识库就走 RAG 流程。判断方式可以很简单关键词规则、分类模型甚至让模型自己决定调不调工具。在智能体项目里这就是把 RAG 封装成一个工具让 Agent 自主决定何时检索。这个做法最大好处是省成本因为大量日常咨询其实不需要检索。第二种叫检索增强直读。不管问题类型统一先做一次检索把命中的片段作为补充材料拼进提示词再让模型回答。好处是稳代价是多花一点检索资源和流量。如果系统对准确率要求高、对成本不太敏感我建议直接用这种。真正做项目时我往往两者结合问题进来先过一道路由高风险、高专业度的问题走“检索增强直读”普通问题轻量处理。这样既兜底了准确率也控制了总体成本。3.3 零基础也能复刻的本地 RAG 知识库搭建过程网上一堆人在搜“rag 教程”“rag 实战”我理解背后的真实需求想自己搭一套能跑的本地知识库但又不想碰云服务。下面这套路径是完整可复制的工具都可以本地跑而且不需要太高的前置知识。第一步是准备模型环境。用 Ollama 这类本地模型运行工具下载一个生成模型和一个 embedding 模型。生成模型负责最后答题embedding 模型负责把文本转成向量。命令很简单类似ollama pull一个生成模型、再ollama pull一个专用 embedding 模型。这里别贪大机器显存不够就选小一点的量化版本先把流程跑通再考虑换更聪明的模型。第二步是文档解析。用 PyMuPDF、pandas、Unstructured 这些工具把 PDF、Word、Excel 里的文字提取出来然后做清洗去掉页眉页脚、目录页、重复空白。这一步很多人觉得无所谓实际影响极大。我最开始直接拿原始 PDF 切分结果向量库里全是页眉“XX公司内部资料”的重复向量检索结果差到没法用。洗过之后整个知识库质量立刻不一样。第三步是文本切分。切分策略直接决定检索质量。我通常用“按段落 滑动窗口”的方式每个块 800 到 1000 token块之间重叠 120 token 左右切分时优先在句号和换行处断。给一段能直接用的简化版代码def chunk_text(text, chunk_size900, overlap120): chunks [] start 0 while start len(text): end min(start chunk_size, len(text)) if end len(text): for sep in [\n, 。, , ]: idx text.rfind(sep, start, end) if idx ! -1: end idx 1 break chunk text[start:end] if chunk.strip(): chunks.append(chunk) if end len(text): break start end - overlap return chunks切完块之后逐块调用 embedding 模型生成向量写入本地向量库比如 Chroma、QDrant 或 Milvus。这个过程可以写在脚本里循环执行把切出来的块和原始文档编号一起存起来方便溯源。第四步是检索。用户提问时用同一个 embedding 模型把问题转成向量在向量库里做最近邻查询取回 top-k 块。这里有两个经验k 不要太大默认 5 到 10 即可取太多会把无关内容带进来检索结果最好再做一次重排用一个 rerank 模型把召回结果按相关性重新排序再截取前几个。重排是本地 RAG 提升效果最立竿见影的一招强烈建议加上。第五步是拼接生成。把检索到的片段按顺序拼成一个“资料区”加上系统提示词跟用户问题一起交给生成模型。到这里一个能用的本地 RAG 知识库就落地了。用 LangChain、LlamaIndex 这类 rag 框架可以少写很多代码但核心流程理解了换框架就是改配置的事。Java 项目里还可以用 LangChain4j 的 easy rag它把分块、索引、检索都封装好了几行代码就能跑通一套最小流程。3.4 如果知识库要存图片和表格应该怎么处理很多人会问“rag 知识库能存储图片嘛”。答案是能但别把图像本身直接塞给文本模型。比较实用的做法是双路索引一路用多模态 embedding 模型比如 CLIP把图片生成图像向量这样用户用草图或图片特征也能检索另一路为每张图片生成一段文字描述比如用多模态模型识别后写一句“图 3 是电源模块接线示意图包含红黑绿三根线”再把这句描述也存入文本向量库。回答时优先召回文字描述对视觉细节要求高的场景再额外调用多模态模型看图。表格的处理类似。直接把表格内容转成文本或结构化 JSON再按行切块向量化能保留表格的检索能力。在我的项目里这类多模态扩展经常会带来意外惊喜。比如产品手册里用户搜“接线图”纯文本检索找不到但有了“图 3 是接线示意图”这句描述直接命中目标。知识库能不能存图片、存表格关键不在向量库类型而在你有没有为它们建立“可检索的文字化入口”。4. RAG 真正的瓶颈在哪预处理和索引质量才是最值得花时间的4.1 召回不准八成是切分和 embedding 的问题很多人总说“rag 瓶颈”是检索不准然后开始怪向量库。我实际排查过的 RAG 项目里问题最多的是两个地方切分和 embedding 模型。切分太碎一句话被切开向量语义不完整切分太大一个块里揉进好几个主题召回相关性被稀释。最典型的错误是直接按固定字符数切分把一段对话、一个条款、一个配方拦腰截断。我之前处理过一个设备说明书里面用表格对比了新旧两代产品参数固定切分直接把对比表拆成两半检索“新款重量”时召回的全是老款数字。后来改成按段落和语义边界切分问题立刻消失。解决切分问题的思路是优先在章节、段落边界断长段落内部再按句号压断同时配置重叠窗口保证边界附近的信息不丢失。更进一步可以试“父子分块”的思路小粒度块负责检索命中后回溯父段落作为回答上下文这样既保准召回又保住了上下文完整性。embedding 模型的选择同样重要甚至更容易被忽视。通用 embedding 对法律、医疗、代码领域的语义理解有限如果你的资料领域性很强建议用领域 embedding 或微调过的模型。对预算有限的本地项目至少要准备两个不同来源的 embedding用一组真实问答集分别测试对比召回率高低再定模型。这一环节就是 rag 实战里最值得花时间的部分。4.2 重复、相似和过期文档会把答案带偏第二个瓶颈是数据质量问题。大文档经常有重复段落一份协议的前言摘要反复出现在多个章节向量检索按相似度取 top-k很可能取回来的五个块来自三份内容雷同的文档模型被重复信息带跑。做知识库的同学形容得很形象检索出来的结果像复读机每个段落都在说同一件事答案自然不够全面。应对方法不复杂。入库前先做去重可以算一下每个文本块的 embedding 相似度相似度太高的只保留一份或打上“重复提示”标记查询时对召回结果做一次聚合如果多个块的来源文档相同或内容重叠度高只保留相关性最高的一个并把重复块降权。很多框架内置的 MMR也就是最大边际相关性就是干这个的。它能让检索结果在“相关”和“多样”之间平衡强烈建议在查询入口开启。过期文档的问题在于版本管理。资料库里同时存在 2024 版和 2025 版规范检索时不知道该给哪个版本。我的做法是给文档维护版本号和生效日期在索引和检索时都作为过滤字段如果条件允许入库前用文档摘要给整篇文档打上“时效标签”检索时优先返回最新的有效版本。这类问题看起来琐碎但恰恰是 RAG 项目从 demo 走向生产必须跨过的一关。4.3 从 ontology RAG 到混合评估进阶方向怎么选当基础检索调稳之后想让准确率再上一个台阶可以试试 ontology RAG也就是用知识图谱和本体约束来辅助检索。普通 RAG 靠向量相似度对同义词、上下位概念不敏感ontology RAG 先把领域知识构建成实体和关系的图谱查询时先从图谱定位实体再通过关系扩展候选文档最后进入向量检索。对法律、医疗这类术语极严的场景效果提升明显。代价是前期知识建模工作量不小不是专业领域的话不用一上来就碰。不管用哪种增强一个 RAG 系统好不好必须用数据说话。我强烈建议每个项目维护一份评估集几十到几百条真实问题每条问题注明期望召回哪些文档、标准答案是什么。每次调整切分、索引、检索参数后就跑一遍评估集看召回率和答案准确率的变化而不是凭空调参。没有评估集的 RAG 优化基本等于闭眼改 bug。前面提到的那么多热词看起来眼花缭乱其实都服务于同一个目标让检索供给更准、让答案更可信。5. 常见问题排查手册与实操心得5.1 直接对着查的症状表检索不到、答案漂移、越答越慢RAG 系统出问题时症状通常集中在几类。我把常见现象、可能原因和解决建议整理成了一张表排查时可以照着一步步来。症状可能原因排查顺序与解决建议检索不到相关内容切分太碎、embedding 模型不适配、向量索引没建好先看切分块是否语义完整换领域 embedding 重测检查向量库维度与距离度量是否一致答非所问答案漂移检索结果混入无关块、top-k 过大、重复文档过多调低 top-k开启 MMR 去重加重排并查看召回块原文是否真的相关回答很慢拼接上下文过长、向量库全表扫描、模型太重截断拼接上下文的长度给向量库建 HNSW 等索引换小模型或量化版文档更新后答案还是旧的索引没同步、缓存未失效检查增量更新任务是否执行给文档加版本号并在检索时过滤同一问题答案不稳定相似内容多、模型随机性大调低 temperature归一化检索片段给重复块降权回答不引用出处提示词没要求、来源字段没拼进上下文在生成提示词里明确要求“按资料回答并引用编号”把来源 ID 拼进上下文这张表是我每次排查问题的起点。整张表背后有一个原则先看检索结果对不对再看模型回答好不好。检索不对后端模型再强也没用检索对了至少能保证答案的素材是可靠的。5.2 三个踩过坑之后才明白的忠告第一个忠告不要迷信“把上下文拉满”。我见过一个团队为了发挥长上下文优势把检索到的所有块全部塞进提示词结果上下文超过 10 万 token模型反而开始忽略最应该关注的那一段。后来我们给自己定了一条硬规则拼接给模型的资料区控制在 2 万 token 以内命中数量再多也只保留高相关的内容。上下文是工具不是仓库。仓库的功能交给向量库提示词只负责让模型“在最有用的材料上发力”。第二个忠告原始文档一定要做清洗再做切分。从 PPT 转出的 PDF、扫描件 OCR、表格型 Excel里面大量的页眉、导航、空行都会变成“语义噪声”。我处理过一批扫描版协议OCR 结果里全是错字和分行符embedding 之后检索质量惨不忍睹。后来换了质量更好的 OCR 工具再加规则清洗步骤整个知识库准确率几乎翻了一倍。也就是说文本拆解工具不是锦上添花而是生产环境里最被低估的一环。第三个忠告本地部署时embedding 模型和生成模型要分开管理。很多人为了省事只拉一个生成模型文本向量也用这个模型生成结果向量维度不稳定检索效果极差。embedding 和生成各司其职宁可 embedding 用一个小模型也必须用专门的向量模型。内存不够时把向量库和模型放在不同进程限制 batch 大小防止检索时模型加载把内存顶爆。另外建议定期重建索引尤其当文档结构大调整时增量更新往往越改越乱全量重建一次反而是最高效的清理。6. 我个人现在处理这类项目的习惯最后分享一个自己沉淀下来的默认做法供你参考。接到知识库类需求时我不会先纠结“用 RAG 还是长上下文”而是花半天时间把资料按使用场景分桶哪些是全文直读型哪些是检索型哪些需要权限过滤。然后设计一个很轻的路由层简单问题直接对话专业问题走 RAG遇到重大文档或用户主动要求时再启用长上下文直读。这个结构跑下来大多数问答成本都很低准确率也比单走一条路稳定。实际使用中还有一个小细节值得说我几乎每周都会跑一遍评估集把新增的真实问题塞进去看看召回率和答案质量有没有回退。哪怕只是切分函数改了一个参数也要用评估集确认效果再上线。RAG 系统的价值不在某一个模型或某一个算法有多炫而在于你形成了一套可维护、可度量、可迭代的资料供给机制。所以最后想说的体会很简单别纠结“RAG 是不是被淘汰了”先想清楚你的知识库到底需要“背”还是需要“查”。真正常态化使用的知识库一定是在“查”这件事上做透了长上下文只是在这套基础上让“理解”更从容而已。这套思路我建议你下个项目直接试一试。