1. 先回答标题RAG 没被长上下文淘汰反而更值钱了最近在技术社区和微信群被问得最多的问题就是这句“RAG 是不是已经被长上下文淘汰了”问的人多了我干脆把这件事掰开揉碎写清楚免得每次都要从头解释一遍。先说结论长上下文不仅没淘汰 RAG反而让 RAG 越来越重要。为什么会这样因为这是两条完全不同的技术路线一条是用更大的“内存”硬扛另一条是用更聪明的“检索”去精准拿资料。前者对应的是超长上下文后者对应的是 RAG。它们的瓶颈不一样适用的场景也不一样根本不是替代关系更像是“一个做大锅饭一个做点菜”。从实际项目来看我见过不少团队把上下文窗口从 8K 升到 128K、甚至 200K然后就以为万事大吉了。结果一上线就发现推理速度变慢、成本暴涨而且模型在中部位置的“记忆”其实没有想象中那么准确——这就是典型的长上下文幻觉。反过来那些老老实实做 RAG 的项目把知识库拆好、索引做好、检索融合做好反而是越用越稳。这篇文章我尽量用“干过活的人”的口吻把 RAG 的核心原理、和长上下文的真实差异、以及我自己踩坑总结出来的实操经验都写清楚。适合谁看呢正在纠结选型的技术负责人、刚接触 RAG 的开发者以及想给本地知识库上点靠谱方案的人。看完你能知道两者到底怎么选、怎么搭、怎么避坑。2. RAG 的核心逻辑与真正优势2.1 RAG 到底在解决什么问题RAG 全称是 Retrieval-Augmented Generation检索增强生成。核心思路其实非常朴素模型不是从参数里硬记一切而是先从你的知识库中检索出相关的片段再把这些片段拼进 Prompt 里让模型基于这些材料来回答。可以拿它当做一个“开卷考试”机制。传统 LLM 是闭卷考试所有知识都写在参数里遇到不熟悉的就编RAG 是开卷考试先翻资料再答题。这样一来答案的准确性、时效性、可解释性都明显更好而且知识更新不需要重新训练模型换个库就行。很多人会问“RAG 知识库能存储图片吗”。我的回答是能但不建议直接把“图片内容”扔进向量库。更靠谱的做法是分两类处理一类是能用文字描述的图片比如图片里的图表、单据扫描件你可以先走 OCR 抽取文字再把文字向量化另一类是产品图、设计稿这类需要视觉理解的图片RAG 管不了应该走多模态模型。本地工具里一般也是这么做的文本抽取、切块、向量化图片先转文本再进库这样检索时不会丢。2.2 RAG 的常见瓶颈在哪里说句公道话RAG 不是银弹瓶颈也非常明显。我归纳下来主要有三个。第一个瓶颈是“检索质量决定天花板”。如果检索出来的 Top-K 内容里面没有正确答案模型再聪明也答不对。常见情况是 Query 表述不清楚、Embedding 模型不分领域、切块大小不合理、元数据过滤做得少。这些问题都会导致召回率低最终答案看起来牛头不对马嘴。第二个瓶颈是“上下文堆叠后的信息冲突”。做一个 RAG 问答系统你可能会检索出 5 个片段其中 3 个相关、2 个只是沾边。把这些全塞给模型它反而容易被噪声带偏。有过实测减少不相关片段之后同样一个 LLM 的回答质量直接提升了一个档次。第三个瓶颈是“长文档的召回不准”。如果一份 PDF 有 300 页RAG 的召回策略不够精细时中后部内容很难被正确检索到。这时候很多人会误以为是“长上下文模型能解决”但从本质上讲 RAG 的问题出在“找得不准”而不是“读得不够长”。2.3 RAG 真正厉害的地方那 RAG 凭什么被大厂还在持续投入呢因为它在真实工程环境中解决了几个致命痛点。第一是可解释性。RAG 能明确告诉你“这个答案来自文档第几段的哪句话”。在医疗、金融、法律这些需要证据链的领域这一点能把系统可靠性和业务合规性拉高一大截。第二是知识更新成本极低。传统方案需要微调模型才能更新知识费 GPU 不说周期长、风险大RAG 只需要把新文档做解析和写入索引几分钟就能生效这就是《ollama 简易本地 RAG 知识库【零基础可复制教程】》这类内容这么火的底层原因。第三是隐私与本地化。很多企业数据不能出域但大模型服务是云端的。RAG 完全可以做到本地用向量数据库存企业文档模型部署在内网或私有环境查询的时候只在本地做检索和推理。这种模式下模型参数不更新敏感文档也不外传安全性远高于用长上下文硬塞。3. 长上下文的真实能力与硬性限制3.1 长上下文模型到底能做什么近两年大模型厂商在上下文长度上确实很拼8K、32K、128K、200K 甚至 1M 的窗口都出来了。长上下文的直接好处是一目了然的你可以一次性把一本手册、一份几十页合同、一整个代码仓库塞进去省略检索环节模型能直接“全局阅读”。这非常适合哪些场景呢典型的是单文档深读比如审阅一份 80 页的招股书你要问“第三季度毛利率为什么下降”传统 RAG 需要精确切块和召回而长上下文直接把全文读一遍理论上只要关键信息不落在“遗忘区”就能回答。另一个是代码库补全和分析。把半个项目的源码塞进上下文模型能跨文件理解调用关系这对代码生成和重构很有帮助。我实际用下来短代码片段里这样做很爽但是仓库一大了Prompt 长度和推理时延就立刻难以接受。第三个场景是多文件对比。政策对比、版本对比、合同 diff长上下文可以在一个上下文窗口里对比多份文档输出跨文件一致性判断。这在 RAG 里做会麻烦一些因为跨文档的检索和拼接策略需要反复调。3.2 长上下文的三个致命限制长上下文最大的问题是它不是免费的午餐。首先是“中等位置偏差”。模型在读一段很长的上下文时对开头和结尾的部分注意力更集中对中间部分反而容易忽略。不止一家机构做过实验在长文档中部埋入关键信息提问时模型经常答错。这意味着长上下文看似“全读”实际并不会“全部记住”更类似“读是读了但扫得太快记不全”。其次是成本与速度。Token 一长KV Cache 占用内存直线上升推理时间也随之拉长。一个实际案例128K 上下文下单次推理的耗时和数据传输量远超 8K 上下文的十几倍流量费和卡时费都不便宜。对普通团队来说没必要为 99% 的短问答场景专门支付“长头”的代价。最后是幻觉放大。上下文越长模型被“淹没”在噪声中的概率越大。如果有 50 页文档但真正相关的只有 100 个词模型很容易被干扰。用术语讲叫“Lost in the Middle”但这不仅仅是“丢中间”还包括“过度服从上下文里的错误线索”。所以你会发现长上下文并不天然带来正确率提升反而对 Prompt 结构、文档片段编排要求更高了。3.3 长上下文处理不了什么除了上述限制长上下文在几个场景下是彻底“失灵”的。企业内部知识库动辄几万份文档你不可能在上下文中塞下这么多内容。这不是 128K 和 200K 的问题就算给你 1M 窗口也不够。你仍然需要一个索引先定位候选文档再做精读这个索引可以说本质上就是 RAG 的检索层。复杂多跳问答也处理不好。比如“找出所有在华东地区有项目并且客户投诉率低于 5% 的合作方”这样的逻辑通常需要查文档、过滤、再查长上下文只能一次性读完全量但对这种精细的筛选逻辑并不一定有理有据。RAG 则可以拆成多轮检索和过滤用结构化元数据辅助筛选。还有权限控制。长上下文一旦把大量文档混合进 Prompt你很难保证模型“只用”某人有权看到的文档。RAG 可以在检索阶段就做文档级 ACL 过滤这一点是长上下文想都不用想的。4. 长上下文会取代 RAG这些场景已经给了答案4.1 大模型厂商为什么都在强调长上下文厂商拼命宣传长上下文原因其实有两个一是参数竞赛的需要二是确实解决了某些用户痛点比如单文档分析。但你要知道厂商希望你“少做工程、多买 Token”而你的诉求是“稳定、便宜、高质量”这中间的博弈语境决定了各家新闻稿里的测试数字比你自己的真实项目好看得多。实际中长上下文更多作为 RAG 的“后道能力”出现而不是替代品。不少平台的做法是先通过 RAG 召回几十个相关片段再把这些片段合并加上系统提示词一次性丢给长上下文模型做最终生成。这就是混合架构你把长上下文当成 RAG 的一个优化组件而不是整体前提。4.2 真实项目中的选型依据我整理过一个简表能直接辅助选型需求维度优先用 RAG优先用长上下文资料规模数千到数十万文档单篇长文档或多份小文档实时性文档更新后可立即生效随 Prompt 更新可解释性强能追溯来源片段弱答案通常无法定位到具体段落成本瓶颈Embedding 向量库成本较低Token 消耗大KV Cache 占显存权限控制可在检索层控制 ACL只能靠提示词约束落地方案适合长期积累的知识库适合短期速读与分析注意这个表格并不是“二选一”更多是“谁先谁后”。如果我只做一份季度财报分析我会用长上下文如果是持续给一个业务团队搭建问答系统我必然用 RAG。至于“RAG 是不是被长上下文淘汰”站在真实工程角度看答案已经很清晰了淘汰不了。4.3 混合架构RAG 长上下文的正确姿势我目前最推荐的方案其实是混合架构而不是死站一边。基本做法是第一章先解析文档做切块和 Embedding存入向量库第二层在做问答时先走检索召回 Top-K 候选块再做一次粗排筛掉明显不相关的片段第三层把过滤后的片段拼接进上下文交给长上下文能力强的模型来做推理和生成。这个流程既利用 RAG 的定位与过滤能力又利用长上下文的全局理解能力。我在一个企业合同审核项目里这样搭总计 3500 份合同单份合同平均 25 页 PDF。如果全文塞进上下文模型撑不住如果用纯向量召回很多条款细节又查不准。后来把文档切分成“合同结构化字段 关键段落块”建立双索引再配合长上下文模型处理准确率和速度都明显提升。这里面嵌着一个很关键的小技巧给每个文本块增加元数据比如合同编号、所属章节、日期、当事人。检索时不光做语义相似度还要用元数据做过滤。比如用户搜索“2023 年签署的保密协议”你可以在索引层面先把合同类型过滤为保密协议再做向量检索效果比单纯语义向量检索好得多。5. 零基础也能上手的本地 RAG 搭建教程5.1 本地 RAG 需要准备哪些工具如果你想在本地零基础跑一个 RAG 知识库当前主流且最省心的组合是Ollama 本地模型 一个向量数据库如 Chroma 一个文档加载器如 LangChain 或 LlamaIndex。这样的好处是全程离线不需要调用外部 API数据留在你自己的电脑上隐私性极佳。具体工具选择我有一个小建议模型用qwen2.5:7b或llama3.1:8b都可以这类模型在 16G 内存的机器上就能流畅跑Embedding 模型推荐用bge-m3中文效果比很多国外模型好客户端 UI 可以用Dify或AnythingLLM图形化界面适合新手快速体验。想自己动手写代码LangChain是入门首选但它的抽象层次多调试起来有些绕嫌麻烦可以用LlamaIndex对文档问答场景更友好。5.2 三个关键步骤文档切块、向量化、检索问答第一步文档加载与切块很多人直接跳过切块直接喂整份文档这是 RAG 新手最容易犯的错误。文本切块大小直接影响检索精度切得太大一个块内包含多个主题检索结果噪声多切得太小语义完整性不够容易把完整概念切断。常见的经验值是“按 300-500 字切块、重叠 50-100 字”。重叠的目的就是为了避免切断句子导致语义断层。实际项目里要结合文档类型调整合同按条款切代码按函数切新闻按段落切。现在有 LangChain 的RecursiveCharacterTextSplitter可以按分隔符层级切也有更进阶的基于语义相似度的切分器但基础版在 80% 场景下已经够用。第二步向量化与索引构建切好的块必须转成向量向量检索才会快。这个环节主要注意两点一是用专门的 Embedding 模型而不是用 LLM 自己二是 Embedding 模型要与你的领域数据匹配。通用模型在中文合同、金融术语上表现一般条件允许的话建议用领域微调过的模型或者至少用bge-m3这类多语言模型。索引构建时别忘记把元数据一起存进去。元数据可以理解为文本块的“标签”来源文件名、页号、章节标题、日期等。检索的时候可以先用元数据粗筛一遍再用向量相似度精排体验会完全不一样。第三步检索问答问答阶段的关键是“检索 重排 生成”。检索阶段根据用户问题从向量库中取回 Top-K 个块K 值视情况取 5-10 比较合适重排阶段我是强烈建议加一个rerank模型哪怕用简单的交叉编码器也行能把相关性差的片段滤掉最终生成阶段把过滤后的片段拼接进 Prompt然后让 LLM 生成回答。很多零基础教程里没有重排这一步结果就是模型经常“被带偏”。加上重排后我的项目准确率大约能提升 10-15%代价只是多调一次模型接口性价比极高。5.3 Ollama 本地知识库实操记录我用一套最简单的流程演示一次方便你照着复现。系统为 macOS内存 32G模型全部本地运行。步骤一安装 Ollama并拉取模型。brew install ollama ollama pull qwen2.5:7b ollama pull bge-m3步骤二检查模型是否正常启动。ollama list ollama run qwen2.5:7b 你好步骤三用 Python 写一个小流程文档解析用PyPDF2或langchain的PyPDFLoader切分用RecursiveCharacterTextSplitter向量库用Chroma实现一个最简问答链路。from langchain_community.document_loaders import PyPDFLoader from langchain_text_splitters import RecursiveCharacterTextSplitter from langchain_community.embeddings import OllamaEmbeddings from langchain_community.vectorstores import Chroma loader PyPDFLoader(your_file.pdf) docs loader.load() splitter RecursiveCharacterTextSplitter(chunk_size400, chunk_overlap80) chunks splitter.split_documents(docs) embeddings OllamaEmbeddings(modelbge-m3) vectordb Chroma.from_documents(chunks, embeddings) retriever vectordb.as_retriever(search_kwargs{k: 5})步骤四自定义一个简答函数把检索结果拼接进 Prompt再用 Ollama 的 chat 接口生成答案。from langchain_community.chat_models import ChatOllama llm ChatOllama(modelqwen2.5:7b) def rag_answer(question): candidates retriever.get_relevant_documents(question) context \n\n.join([doc.page_content for doc in candidates]) prompt f请基于以下资料回答问题资料中找不到的信息不要猜测\n\n{context}\n\n问题{question} result llm.invoke(prompt) return result.content print(rag_answer(这份合同中最长付款周期是多久))上面这套代码十行左右就能把最简 RAG 链路跑通。别小看它在本地测试场景里已经足够支撑几百页文档的问答。后续要提升体验再把重排、对话历史、多路召回加进去就行。6. RAG 实战经验总结与常见问题排查6.1 我踩过的几个大坑第一个坑是“切块后再也不管上下文”。切块不是切完就完事有些语义只有在整篇文档里才成立。比如一句话“如上表所示”单独拿出来谁也看不懂。我现在的做法是切块时保留“前文摘要”字段把所在章节的标题、上一段的关键句作为辅助上下文一并存入元数据。当检索命中这个块时把辅助上下文也拼进最终 Prompt效果很明显。第二个坑是“只查一次不追问”。RAG 系统在面对复杂问题时会吃不消比如“比较 A 方案和 B 方案的成本差异”单次检索往往只拿到 A 或只拿到 B。正确做法是做多轮检索先拆解用户问题分解成多个子查询分别召回候选块最后再合并。你也可以用小模型先做意图识别再决定是单路、多路还是追问这是 LangChain4j easy RAG 之类框架里一直在优化的点。第三个坑是“没有评估体系就开始调参”。很多人调 RAG 全凭感觉问几个测试问题就上线结果一到真实业务就崩。正确做法是准备至少 50-100 条高质量问答对覆盖正常问题、边界问题、否定问题、多跳问题每次改动后跑一轮脚本记录召回率、命中率和答案可接受率用数据来决定调不调。RAG 没有评估就等于闭着眼睛开车。6.2 常见问题速查表现象根本原因解决方案答案经常张冠李戴检索召回片段噪声多增加 rerank 模型减少 Top-K 的 K 值查不到近期更新的文档Embedding 索引未更新建立增量更新机制按文件修改时间重跑索引长文档中部内容查不到切块策略不合理按章节或语义段落切块并加标题元数据中文问题效果差Embedding 模型选择不当切换bge-m3等中英双语模型相似文档太多导致答案混缺少元数据过滤检索前按时间、类型、来源等字段粗筛回答格式经常乱缺少输出约束在 Prompt 中明确要求“分点回答并标注来源片段编号”系统响应太慢向量检索后拼接内容过长限制单次检索片段数控制 Prompt 长度必要时做摘要替换隐私要求高的本地场景外网调用模型或向量库在云端全部切换为 Ollama 本地推理 本地向量库每个问题都对应的是我在真实系统里修过的 BUG不是拍脑袋写出来的。你可以把这些当成上线前的检查清单逐项过一遍。6.3 “本地 RAG 文本拆解工具”怎么选如果你现在最急需的是一个本地工具把 PDF、Word、Markdown 拆成干净文本再进向量库我的筛选标准很简单能否处理扫描版 PDF这点非常重要很多合同都是扫描件不做 OCR 拆出来全是图片空文本。能否保留文档结构至少能识别标题、表格、页眉页脚并标注到块元数据。能否批量处理一个一个文件拖进工具会累死人支持目录遍历和增量更新才合格。是否开源或本地可部署数据不出本机才叫“本地工具”。我常用的组合是Apache Tika做通用格式解析PaddleOCR处理扫描件再配合 LangChain 的文本分割器做切块。三者全是本地运行检索端可以配 Chroma 或 Milvus。如果你的文档比较规整其实用一个MinerU或TextIn的本地版也能达到不错效果。关键是先把“文本拆解”这个基础打牢后面向量化和问答才会省心。6.4 什么时候你必须放弃纯 RAG说句得罪人的话RAG 也不是万能的有些场景下你死磕 RAG 是浪费时间。如果只是单篇文档的深度阅读比如读三五篇论文做总结RAG 反而多余。直接用长上下文模型把 PDF 转成 Markdown 喂进去效果简洁又直接。如果任务不需要实时更新知识库比如固定的历史数据统计那么微调一个模型或做一个规则引擎可能更合适。如果文档之间的推理关系特别复杂比如多步骤因果链“A 导致 BB 导致 C而 C 影响 D”RAG 的检索式上下文会很难覆盖全链路。这时候你可以考虑图谱 RAGGraphRAG 或 Ontology RAG先构建实体关系图谱再沿图结构检索相关子图。这类方案是“RAG 的进化”不是被长上下文淘汰的反向证明。所以RAG 应该在“大规模知识库、需要可解释、需要权限控制”的场景中全力以赴在“单文档浅读、快速摘要”的场景中让位给长上下文。这两个共存不打架。7. 关于 RAG 的几个看热闹与看门道的问题有一类问题属于“看热闹的人问的问题”比如 Oriole 的“RAG 是不是已经被长上下文淘汰了”其实每几个月就会以相似的面目出现一次。最早 GPT-4 等模型刚发布时也有人问“RAG 是不是没有必要了直接微调不就行了吗”后来 Claude 2.1 等模型出现大家又开始问“100K 上下文是不是让 RAG 废了”再到 1M 上下文问世这类问题简直成了技术复读机。答案呢当年没有消失现在没有消失未来也不会消失。因为决定技术选型的是“成本、数据规模、私域知识、可解释性”四个真实约束而不是上下文数字的游戏。RAG 每次被看衰随后就会吸收长上下文技术的力量进化出新的形态这就是 RAG 的韧性。再比如“RAG 知识库能存储图片吗”我上面说了要区分“图片里的文字信息”和“图片本身的视觉信息”前者可以走 OCR 提取后向量化后者需要多模态模型支持。如果你做的是票证识别、表格提取RAG 完全可以胜任如果是“帮我看看这张建筑效果图里有哪些问题”那你就别折腾 RAG 了直接把图片喂给多模态模型更靠谱。“RAG 瓶颈”这个问题我也做个总结性回答。最大的瓶颈始终在“检索质量”。模型侧已经越来越强Embedding 模型卷完一波又一波但真正拖后腿的是文档切块、元数据设计、召回排序、评估机制这些都是工程活儿。许多项目声称自己是 RAG其实只是往 Prompt 里硬塞了几段文档文字没做重排没做元数据没做增量更新效果当然差但是这不怪 RAG怪工程没做到位。RAG 最大的意义在于“用低成本把知识库接入 LLM”这正好解释了为什么全网关于 rag 教程、rag 框架、rag 知识库的热度一直不减。大家需要的不是争论谁取代谁而是能看到一个真正跑通的方案知道每一步怎么选、怎么测、怎么上线。这套方法论不管未来上下文窗口到 1M 还是 1B都会一直管用因为我做过的所有效果还不错的 RAG 项目通常都不是“用了最强的大模型”而是“用对了检索方法”。8. 我的结论与真实体会最后再分享一个我在真实项目里观察到的现象那些真正把长上下文用得飞起的团队恰恰也是把 RAG 用得最细的团队。他们不是二选一而是在长上下文和 RAG 之间做了分层底层用 RAG 召回到文档级中层用重排过滤垃圾片段顶层用长上下文模型做最终答案综合。这种组合兼顾了知识覆盖面、答案溯源和推理深度比单走一条路明显稳得多。所以如果有人再问我“RAG 是不是被长上下文淘汰了”我会反问他你想解决什么问题如果你的问题只是一份 100 页的 PDF 深度问答那用长上下文就够了别折腾 RAG如果你的问题是一个持续增长的企业知识库、需要权限隔离、需要答案可追溯、需要低成本快速更新那 RAG 不仅不会被淘汰还会是未来知识应用的基础设施。RAG 和长上下文本质上是一个问题的两个解法就像查资料和背书查资料永远慢一点、但可靠背书开头很爽越背越多就容易出错。你把一本书背下来不等于你就能在法庭上精准引用你有一条好检索通道哪怕模型窗口只有 8K也能答出高质量的问题。我的建议是不要被参数竞赛的数字蛊惑把长上下文当做一个增强手段把 RAG 当做一个系统底座。任何一个季度里我都建议你搭一个最简单的 RAG 系统跑跑内部问答不为别的就为了储备这套“低成本接入知识”的能力。等到哪天真来了大文档模型你才会感受到“先检索再生成”的思路有多顺畅。