引言：RAG 为什么没有过时

检索增强生成（Retrieval-Augmented Generation，RAG）在 2023 年随着企业知识库问答的爆发进入主流视野：把私有文档切块、向量化、建索引，用户提问时先检索相关片段，再让大模型基于片段生成答案。这套朴素流程解决了大模型"不知道企业私有数据"与"一本正经地胡说八道"两大痛点，成为企业落地大模型的第一站。

三年过去，长上下文窗口从 128K 一路涨到 1M token，有人开始断言"RAG 已死，全量喂入即可"。但 2026 年的现实是：RAG 不仅没有消失，反而从一条技术路线演进为一个技术家族——向量检索、GraphRAG、Agentic RAG 各司其职。本文试图梳理这条演进路线，并回答一个关键问题：长上下文时代，RAG 的价值到底在哪里。

朴素 RAG 的三大缺陷

先看朴素 RAG（Naive RAG）为什么不够用。它的流程可以概括为"切块—嵌入—检索—拼接—生成"，问题恰好出在每一个环节。

第一，分块暴力破坏语义。固定长度切块是最常见的做法，但语义边界不会恰好落在字符数上：一句话被拦腰截断、一个完整论点被拆进两个块，检索时要么召回半句话，要么召回不完整上下文。更隐蔽的问题是块粒度的错配——答案可能藏在"段落"层面，但索引建立在"句子"层面。

第二，向量相似不等于语义相关。嵌入模型把文本映射到高维向量，相似度计算的是"语义距离"，但企业场景大量存在精确匹配需求：型号、人名、法规条文编号、合同条款。两个向量上距离很近的句子，在事实层面可能毫不相干；而用户问"GLM 5.2 的输入价格"，检索到的可能是"GLM 5 Turbo 的输出价格"。纯向量检索对这类问题天然弱势。

第三，多跳问题无解。当问题需要跨多个文档、多步推理才能回答（例如"某公司去年采购的设备中，哪些超过了预算上限"），朴素 RAG 只取 top-k 相似块，缺失中间推理链路，模型只能靠猜。这三个缺陷共同指向一个本质：朴素 RAG 把"检索"当成了"一次性的查字典"，而不是"持续逼近答案的过程"。

工程优化：分块、嵌入与重排

针对上述缺陷，第一波优化集中在检索管线的三个环节，它们至今仍是性价比最高的单点改进。

分块策略：从固定长度切块升级为语义分块——按段落、标题层级、句边界切分，并引入重叠窗口避免边界截断；更成熟的做法是父子分块（parent-child chunking）：用小粒度块参与检索匹配，命中后把其所属的大粒度父块整体送入生成阶段，兼顾"检索的精准"与"上下文的完整"。

嵌入与混合检索：通用嵌入模型在垂直领域常常表现不佳，领域微调嵌入（用企业语料微调）是常见手段；更关键的认知是"不要只靠向量"——BM25 等稀疏检索擅长精确关键词匹配，稠密向量检索擅长语义近似，两者互补。实践中普遍采用"稀疏 + 稠密"混合检索，用加权或 RRF（倒数排名融合）合并结果，实体名、编号类查询的命中率立刻上一个台阶。

重排（Rerank）：这是被低估最严重的一环。先用廉价的双塔嵌入粗召回 top-100，再用 cross-encoder 精排模型对"查询-候选块"逐对打分取 top-5。交叉编码器同时看到查询与文档全文，精度远高于双塔，只是速度慢，所以只对粗召回结果做精排。一粗一细的两级检索结构，让精度提升的同时把成本控制在可接受范围。加上检索后的上下文压缩与引文溯源，朴素 RAG 的"地基"问题基本得到解决。

混合检索与 GraphRAG：知识图谱增强

工程优化解决的是"检得准"，但解决不了"看得全"——对需要全局理解的提问（"这份财报里收入增长最快的业务线有哪些""这些条款之间是否存在冲突"），任何基于局部片段的检索都先天不足。GraphRAG 的答案是：把文档内容显式结构化为知识图谱。

GraphRAG 由微软于 2024 年提出（公开资料整理）：先用大模型从文档中抽取实体与关系，构建知识图谱，再通过社区检测算法把图谱划分为层次化社区，为每个社区生成摘要。回答全局性问题时，检索的不是原文片段，而是"社区摘要"——相当于先让人工智能通读全书并做好读书笔记，提问时直接查笔记。

GraphRAG 的价值在高互联、强结构的领域（医疗指南、法规、研报、金融尽调）尤为明显，多跳与对比类问题的回答质量显著优于朴素 RAG。但它的代价同样清晰：图谱构建需要逐文档调用大模型抽取实体，成本高；文档更新时图谱需要增量维护，工程复杂。实践中更常见的是"混合检索 + 图谱"的组合架构：简单事实性问题走向量检索，全局性问题走图谱，两者按问题类型路由。

Agentic RAG：从"查一次"到"想清楚再查"

如果说 GraphRAG 解决的是"检索对象"的问题，Agentic RAG 解决的则是"检索策略"的问题——把检索从一次函数调用，升级为 Agent 的一个工具，由规划-执行-评估循环驱动。

典型的 Agentic RAG 流程是：模型先理解问题，决定检索策略（拆分子问题、改写查询、选择数据源），执行检索，评估结果是否足以作答；不足则发起新一轮检索，或切换工具（调用计算器、查询数据库、运行代码），最后综合多轮结果生成答案。三个关键能力值得展开：

查询改写与子问题分解：模糊问题被改写为多个精确子查询，多跳问题被分解为逐跳检索，每一步检索结果成为下一步检索的上下文——这是对"多跳无解"缺陷的根本性回应。

工具协同：检索不再是唯一的信息来源。Agent 可以在"查文档"和"查数据库"之间自由切换，甚至调用专门的推理模型处理检索到的数据。信息获取从单一管道变成编排式协作。

自反思（self-reflection）：模型被要求"检索结果不够时，承认不够并继续检索"，而不是硬答。这一条对幻觉的抑制效果，比任何提示词技巧都更本质——因为它把"不知道"变成了合法的中间状态。

代价同样真实：多轮检索意味着更高的延迟与 token 消耗，且 Agent 的决策过程需要完整的可观测性（检索了什么、为什么再检索），否则一旦出错难以排查。评估也从"单轮答案正确率"扩展到"检索命中率、检索轮次、最终答案正确率"的多维指标。

长上下文时代：1M 窗口会杀死 RAG 吗

这是 RAG 面对的最大质疑：既然模型能装下 1M token，为什么不把整个知识库一次性喂进去？答案藏在成本与质量两个维度。

先看成本。据昆仑镜 AI 中心模型库（2026-08 验证，USD/1M tokens）：支持 1M 级窗口的模型，输入价格从 Kimi K3 的 $20、GPT-5.6 Sol 的 $5、Qwen3.7 Max 的 $1.48、GLM 5.2 的 $0.72、DeepSeek V4 Pro 的 $0.435 到 MiniMax M3 的 $0.3 不等。假设知识库恰好 1M token，全量喂入意味着每次对话光输入成本就要 $0.3-$20；而 RAG 路线只把命中块（约 5-10 块、数千 token）送入模型，按同样的价格线性换算，输入成本在毫分到美分级——数量级上是百倍之差。考虑到真实知识库动辄数十 M token、且多轮对话每次都需重传上下文，差距还会继续放大。

再看质量。长上下文的两个已知软肋（均为公开资料整理）在 1M 尺度上更突出：一是注意力计算量随序列长度增长，延迟显著上升；二是"迷失在中间"现象——模型对长文本中部信息的利用能力明显弱于开头与结尾，全量喂入并不等于全量理解。多文档场景下，这个问题更加严重：模型难以定位"哪一段才是依据"。

所以更准确的结论是：长上下文解决"能不能装下"，RAG 解决"值不值得装下"。1M 窗口适合单文档深读、代码库全量审计这类"必须全局看"的场景；RAG 适合大规模、频繁更新、成本敏感的知识库。而 2026 年的主流做法是融合：用 RAG 把长文档压缩为相关片段，再送入长窗口模型——检索负责降本与聚焦，长窗口负责深度理解，两者各取所长。

企业落地最佳实践

技术路线梳理完毕，回到落地层面。基于行业实践，企业 RAG 项目最值得遵循的五条原则：

一是数据治理先于算法。文档去重、版本管理、权限隔离是检索系统的一等公民——检索必须尊重 ACL，否则"检索增强"会变成"权限绕过"。这一条在金融、医疗行业是合规红线。

二是评测闭环先行。建立领域评测集（含简单事实、多跳、全局对比、数字精确匹配四类问题），用召回率、答案正确率、引文准确率三个指标做回归，每一次管线改动都要过评测——没有评测的 RAG 优化都是玄学。

三是按问题类型分档路由。简单问答走向量检索，精确匹配走混合检索，全局性问题走图谱或长窗口，复杂任务交给 Agentic RAG。用最便宜的路径解决大多数问题，是控制总成本的关键。

四是索引与图谱的增量维护。文档更新 → 增量嵌入；图谱更新是 GraphRAG 落地最大的隐性成本，务必在选型前评估更新频率与构建预算。

五是可观测性。记录每次检索的查询改写、命中块、重排得分与最终引文，让"答错了"可以追溯是检索问题还是生成问题。

结语

RAG 没有过时，它只是完成了进化：从一条流水线，变成一个由向量检索、知识图谱与 Agent 决策共同构成的检索体系。长上下文没有杀死 RAG，反而让它更专注——在 1M 窗口面前，RAG 的价值不再是"塞不下"，而是"不必塞"：用最小的成本拿到最相关的信息，再把深度理解交给大模型。对企业而言，RAG 的演进路线本质上是一条"成本与精度持续再平衡"的路线：数据治理、评测闭环、分档路由，这三件事做扎实，比追逐任何一种新架构都更重要。选型与预算评估时，对照真实模型的价格与能力数据做测算会更有把握——昆仑镜（aigc.fushtn.com）作为 AI 数字员工办公平台，其 AI 中心提供的全球模型性价比数据，可以作为这类决策的参考。