1. 从“1M上下文”说起这场争论到底在吵什么最近在各个技术社区里RAG检索增强生成和长上下文的关系几乎成了日经话题。一有大模型宣布支持百万级 token评论区必然出现“RAG 可以退休了”的论调。我做了几年大模型应用落地也踩过不少检索增强的坑想用自己的实际经验把这件事彻底讲明白。先说结论长上下文确实抢走了一部分本该属于 RAG 的工作但距离“淘汰 RAG”还差得远。它们更像是一对互补的工具各自解决不同层面的问题。如果你正在做知识库问答、私有化部署、Agent 应用或者刚入门 RAG 准备在 Mac 上搭一个实验环境这篇文章会给你一个比较完整的视角。为什么这个问题会被反复讨论因为从表面看给模型塞更多上下文确实比“先检索再生成”简单直接。长上下文模型不需要额外维护索引、不需要配置向量库、不需要操心分块策略——把文档全量丢进去模型自己找答案效果在短文本、单文档场景下也确实更省事。但一旦深入到真实业务场景你会发现事情没那么简单。2. 长上下文真正解决的是什么问题2.1 长上下文终结了哪些“伪需求”坦白说RAG 的一部分历史包袱确实被长上下文卸掉了。两年前做 RAG 系统很多时候折腾半天是在对付模型的硬伤——上下文窗口只有 4K、8K一段几千字的合同都装不下不得不拆得稀碎再检索拼装。现在主流模型的窗口动辄 128K 起步旗舰级别直接卷到 1M处理整本书、整个代码仓库已经不是新鲜事。这种变化最直接的受益者是几类场景单文档深度分析比如读一份几百页的 PDF 财报或者分析一个大型开源项目的全部源码。全量塞进去模型有完整上下文理解连贯不需要检索。跨章节逻辑推理一份文档里的信息分布在前后三十页RAG 检索出来的碎片往往难以维持完整推理链条长上下文反而有优势。代码仓库理解函数的定义在 A 文件调用在 B 文件注释在 C 文件。全量输入时模型能看到全局依赖关系而 RAG 高频检索可能丢三落四。我之前做过一个合同审查项目早期用 RAG 方案分块检索出来的条款经常上下文不全模型判断不够稳。后来换成长上下文直接整本输入合同条款的前后引用、定义与例外条款的依赖关系都能被完整覆盖。在这种“一篇文章一个主题”的场景里长上下文就是把路修到了家门口RAG 反而像是在小区里绕路。2.2 长上下文的天花板在哪里但长上下文并不是银弹。最早让我产生怀疑的是一个常规的财务问答项目文档库里存储了近几年的发票、合同、报销单总量十万多页全量塞给长上下文模型根本不可能——1M token 窗口在百万页面前渺小得可笑。这直接暴露了长上下文的一个硬性限制窗口再长物理世界里的知识总量总是远远超出单次输入上限。更麻烦的是注意力机制本身的“偏科”问题。学术界有个著名发现叫“迷失在中间”Lost in the Middle当输入文本变长时模型对开头和结尾内容的注意力明显优于中段。我实测过用长上下文模型读一份 200 页的混合文档让它回答埋藏在第 80 页细节处的具体问题时准确率明显下降。这不是厂商参数吹牛能解决的而是 Transformer 架构的内在问题。还有个被很多人忽视的工程现实token 都是要钱的而且越长越贵。以国内某主流模型为例假设输入 1M token 的成本算下来单次调用就不是个小数目如果业务每天有上千次提问这笔账根本算不过来。如果检索后只把相关片段传进去成本能减少 90% 以上。延迟也是同样的道理——输入越长首字延迟越长。在客服、搜索这类对实时性敏感的场景里用户可等不了每次请求都读十几万 token。3. RAG 不可替代的四张底牌3.1 动态知识长上下文装不进“正在发生的事”长上下文有一个致命短板它的知识在训练/输入那一刻就冻结了。但现实业务里知识是每小时都在变的。举个例子我曾经负责过一个企业内部规章制度问答系统。公司的报销政策每年调整产品文档随版本迭代人员架构表三个月一大变。如果用长上下文方案每次知识更新都要重新构建整个输入——如果知识库里是上千篇文档这既慢又不现实。RAG 方案里知识入库时做向量化新增一条政策只需要处理这一篇文档检索时天然拿到的就是最新内容。这种“持续更新的活知识”长上下文永远替不了。3.2 私有知识可控性企业不敢把家底全交给模型做内部落地的人最清楚企业知识库里有大量敏感数据薪酬结构、未公开的财报、客户个人信息、核心源码。全量塞给模型意味着这些数据全部暴露在模型服务商的 API 调用链路里——本地部署能缓解一部分但没法彻底消除隐患。RAG 体系里数据默认不离开企业自己的存储和检索层只有命中的片段拼接后才会进入生成模型而拼接过程完全受你自己控制。你甚至可以再加一层脱敏中间件在检索结果进入 Prompt 之前做字段级别的过滤。长上下文是“把整个保险柜搬出去让外人翻”RAG 是“只递一两张你审核过的卡片”。对于合规要求严格的行业这不是效率问题而是根本没有选择的问题。3.3 可解释性出了问题你得能说出“为什么”我接触过不少甲方他们的验收标准里明确要求AI 给出的每一个结论必须能定位到知识库中某篇原文的某个段落。RAG 天生自带这种属性——检索返回的文档就是证据链你可以把引用来源直接展示给用户也可以在系统日志里完整追溯“哪个问题→检索了哪些文档→哪个段落参与了答案生成”。长上下文则是一个“黑盒爆炸”答案可能基于第 3 页的内容也可能基于第 157 页的某句话生成过程你无从审计出了错也很难定位。在医疗、法律、金融这类高风险场景这种差距直接决定能否落地。3.4 计算成本与性能弹性说到底工程决策的本质是算账。RAG 最被人低估的优势其实是成本结构。假设你的知识库有 100 万 token 的内容做 10 次提问方案每次输入 token 数10 次总输入 token相对成本量级长上下文全量输入100 万 问题约 1000 万10 个“满份”长上下文缓存命中缓存有效时较低略低但仍有维护成本8~9 个“满份”RAG检索 Top-K约 1~2 万 问题约 15 万1 个“满份”最理想的情况下RAG 能做到两个数量级的成本差距。再加上长上下文模型对显存和计算资源的需求呈指数级增长单机部署长上下文模型通常必须在吞吐量和延迟之间二选一。而 RAG 因为输入精炼可以同时保住高并发和低延迟这是业务上线时每天都在面对的硬指标。4. 你真正需要的是一个增强体系而不是二选一4.1 第一层进补别用坏了向量检索的“天灵盖”逛 RAG 相关讨论时最常见的抱怨就是“检索出来一堆不相关的东西”。这其实不是 RAG 的错而是很多团队只用了最朴素的向量相似度检索把 RAG 做成了“裸奔版”。传统向量检索的问题在于语义相似度和“能不能回答这个问题”是两回事。我举一个亲身经历知识库里有很多关于“苹果价格”的内容用户问“苹果公司今年的营收怎么样”向量检索会返回大量水果价格数据——因为语义上都在聊“苹果”。单纯靠 embeddings 排序模型很可能会拿着一堆炒股资料回答水果行情。这就是为什么现在主流方案都在做混合检索Hybrid Search向量检索负责语义模糊匹配BM25 这类稀疏检索负责精确匹配再用 RRFReciprocal Rank Fusion把两种排序结果合并。加上一个Reranker 重排模型在检索出 Top 50 的低成本结果上再做精密排序只把 Top 5 喂给大模型准确率的提升是肉眼可见的。4.2 第二层进补从 RAG 到 GraphRAG 与 Ontology RAG今年“RAG 瓶颈”已经变成一个高频搜索词。瓶颈出在哪里出在向量检索的碎片化上。一个主题分散在多个文档、多个段落里检索回来的碎片很难拼出完整逻辑尤其是“A 和 B 是什么关系”这类关系型问题传统 RAG 基本处于半放弃状态。GraphRAG 的做法是把抽取出的实体公司、人物、产品和关系持股、合作、竞争构建成知识图谱回答问题时不只做文本检索还在图结构上做多跳推理。比如问“B 公司为什么在跟 C 公司合作”它能沿着“B→上游供应商→A→共同投资→C”这条路径给出答案。这类问题是纯向量 RAG 答不出来的。再进一步是 Ontology RAG。它不是简单地抽实体建图而是先定义一套本体层Ontology明确这个领域有哪些概念、属性和关系规则。比如做金融知识库Ontology 里规定“公司有 CEO”、“财报包含营收、净利润”系统解析问题时严格按这套框架去组织答案。它的优势是精度高、可控性强适合业务边界清晰的企业代价是需要领域专家参与建模前期成本偏高不太适合随手搭一个 Demo。下面是不同 RAG 方案的选型参考方案优势劣势典型场景基础向量 RAG快速上线维护简单关系推理弱、碎片化通用问答、客服知识库混合检索 Rerank准确率高适配大多数业务需要额外排序模型企业搜索、专业问答GraphRAG强关系推理、全局理解构建复杂、更新维护成本高多实体关系分析、研报解读Ontology RAG极高精度、业务规则内嵌建模门槛高、领域强依赖金融、医疗、法律等高合规场景4.3 第三层进补多模态与工程化热词里有人问“RAG 知识库能存图片吗”。答案是可以但记住一点图片类知识库十有八九是先给图片写一段准确的描述文字再对描述做向量化。这样用户搜“红色法拉利”时能命中一张跑车照片。基座模型支持多模态 embedding 时也可以直接用图文联合向量但通常描述方案更稳、成本更低。截图、合同扫描件、产品照片这类素材入库时多一步“视觉语言模型生成说明”的预处理效果远比裸存图片好。Mac 上搭 RAG 知识库的流程我也简单说下本地跑一个 Ollama 拿到 LLM比如 qwen2.5 系列或 llama 3.1 8Bembedding 模型用 bge-m3 或 nomic-embed-text向量库用 Chroma 或 FAISS框架选 LangChain 或 LlamaIndex。配置齐了之后几行 Python 就能跑通“文档导入→分块→向量化→建索引→检索问答”的完整链路。Apple Silicon 上跑 7B~8B 模型体验已经很流畅日常练习完全够用。5. 工程实战一套判断标准与避坑清单5.1 场景选型判断矩阵每次有人问我“我这个项目到底该用 RAG 还是长上下文”我都建议按下面这套标准逐条打分判断维度更倾向 RAG更倾向长上下文知识总量超过窗口上限几十倍单文档可控更新频率文档每周/每天更新知识长期不变隐私合规数据不能出域可接受上云全量处理可解释性必须溯源到原文有答案就行成本敏感高频问答预算有限低频分析单价不敏感跨文档关系推理关系复杂要推理单文档线性阅读绝大多数现实项目打分结果都是“RAG 为主长上下文为辅”。例如还会有一个不错的混合实践先用 RAG 从百万级知识库里召回到几十个候选片段再利用长上下文模型把所有片段整体读一遍做总结——这个组合能同时拿到召回的广度和推理的深度我在实际项目里就是这么用的。5.2 常见问题速查表症状常见原因解决思路检索结果不相关纯向量检索无混合检索加 BM25 与 RRF 融合FAQ 类问题答非所问分块后信息缺失严重调小 chunk size增加重叠数字或名称张冠李戴两块相近文本语义混淆引入 RerankerTop 5 压缩为 Top 3多跳关系问题答不出向量检索碎片化升级 GraphRAG/Ontology数据更新但答案没变索引未重建或缓存失效增量更新向量索引检查缓存策略响应太慢输入 token 过长或重排链路重复计算精简 Prompt、缓存命中、异步索引Mac 本地跑不动模型太大或量化不足换 4bit/8bit 量化或降级到 7B 模型5.3 避坑经验三则第一分块策略永远值得投入时间。我见过太多人默认“每 512 token 切一块”然后就不管了。真实的文档有标题、章节、表格、代码块应该优先按语义结构切——Markdown 标题层级、文档内嵌标题等都能作为天然边界。合适的分块策略能让检索准确率显著提升这几乎是投入产出比最高的调优项。第二评估不可能靠肉眼。手工看几十条问答会觉得“还行”但这是严重幻觉。我现在的做法是搭一套评测集——至少一百条覆盖不同难度的问答配上标准答案跑批量对比算召回率和答案正确率。要判断检索段是否有效简单做法是模型作答时强制它引用原文片段然后人工检查引用是否命中核心信息。没有评测集的 RAG 调优基本等于闭着眼睛走路。第三RAG 流程没有银弹调试时先分段定位。问题到底是“没检索到”还是“检索到了但模型没用上”在系统的中间日志里把检索结果打印出来肉眼扫一眼就知道方向。检索差就去优化分块和检索方式生成差就去调 Prompt 和生成参数。我踩过不少弯路后来养成“先看检索命中率再看最终答案”的习惯调试效率高很多。6. 再聊两句实在的做技术选型最容易犯的毛病是把新概念当万能药。看到长上下文参数涨了就觉得 RAG 过时了看到 GraphRAG 火了又觉得向量检索该扔了。我自己的体会是工程上的正解通常是组合拳。长上下文是和“全面阅读”匹配的能力RAG 是和“海量知识里的精准定位”匹配的能力。真实业务里知识规模、更新频率、合规要求、成本预算这些约束条件放在一起反而会把大多数场景推向“RAG 为主、长上下文为辅”的组合架构——先靠检索从海量库里捞精华再靠长窗口把精华读透。最后分享一个可以立刻用上的小技巧如果你已经搭了 RAG别急着上复杂方案。先在现有流程里加一个“重排”把 Top 20 候选用 Reranker 压到 Top 3 喂给模型。很多“RAG 效果差”的问题这一步就解决了七八成。别怕试错把这些方法都放到评测集上跑一轮你会非常直观地看到差距在哪里。这套方法才是比“RAG 跟长上下文谁淘汰谁”更值得关注的命题。