1. 从“检索增强”到“上下文工程”RAG 到底在演什么如果你最近一年一直在跟大模型应用打交道大概率会有一种感觉RAG 这个词好像每隔几个月就被重新定义一次。去年大家还在聊“向量库选哪个”“chunk 切多大”今年风向就变成了“长上下文是不是要干掉 RAG”“GraphRAG 和 Agentic RAG 到底谁更靠谱”。标题里那个“终”字其实特别有意思——它不是“终结”更像是“终局思维”当我们把 RAG 这条技术线拉长来看它最终会收敛成什么样。先把结论摆前面RAG 的本质从来没变过就是在模型生成之前把对当前任务有用的信息塞进它的上下文里。变的只是“怎么找”“找什么”“找多少”“什么时候找”这四件事。早期大家把它当成一个“检索拼接”的工程活现在越来越多人意识到它其实是一个上下文工程问题——检索只是其中一环真正决定效果的是整个信息流转链路的设计。这篇文章我打算按技术演进的脉络来拆不堆概念而是讲清楚每一代方案为什么会出现、解决了上一代的什么问题、又在什么地方埋了新坑。适合两类人看一类是正在做 RAG 应用、被召回率和幻觉折磨的开发者另一类是想搞清楚这个领域到底走到哪一步了、该不该跟进新方案的技术负责人。读完你至少能判断自己手头的场景到底该用哪一代的思路。2. 第一代 RAG朴素检索拼接为什么“能用但不好用”2.1 最原始的形态一次检索一次生成最早期的 RAG 实现简单到有点可爱用户问一个问题系统拿这个问题去向量库做相似度检索取回 Top-K 个文本块拼成一段 prompt丢给模型生成答案。整个流程就是一条直线没有任何分支和循环。这个方案之所以能快速铺开是因为它门槛极低。你不需要微调模型不需要复杂的编排框架一个向量数据库加一个 embedding 接口就能跑起来。对于“企业知识库问答”这类场景它确实解决了模型不知道内部文档的问题。但用不了多久问题就暴露了。最典型的是检索质量完全取决于用户提问的措辞。用户问“报销流程怎么走”文档里写的是“费用核销操作指引”字面相似度不高向量检索就可能召回一堆不相关的内容。这时候模型要么硬编要么直接说“根据资料无法回答”。2.2 朴素方案的三个硬伤我把第一代 RAG 的痛点归纳成三条这三条基本定义了后面所有演进的方向。第一是查询与文档的语义鸿沟。用户的自然语言提问和文档的书面表述之间存在天然差异单靠一次 embedding 相似度很难跨越。尤其是当问题包含多个意图、或者需要推理才能匹配时单轮检索几乎必然漏召回。第二是上下文窗口的浪费与污染。Top-K 取少了信息不够取多了噪声一大堆。更麻烦的是拼进去的文本块之间可能互相矛盾模型面对冲突信息时表现很不稳定容易挑一个看起来顺眼的编下去。第三是没有反馈闭环。检索完就完事了模型生成得好不好、答案有没有被用上系统完全不知道。这就导致调优只能靠人工看 case效率极低。提示如果你现在的 RAG 系统还停留在这一代先别急着上高级框架。把检索的召回率单独测一遍很多时候问题根本不在生成端而是压根没检到正确内容。3. 第二代 RAG查询改写与多路召回把“找得准”这件事做扎实3.1 查询改写让问题先“说人话”针对语义鸿沟最直接的思路是在检索之前先让模型把用户的问题改写成更适合检索的形式。这就是查询改写Query Rewriting的由来。常见做法包括同义扩展、拆解子问题、生成假设性答案HyDE等。HyDE 这个思路我觉得特别值得说。它的逻辑是与其拿问题去匹配文档不如先让模型“编”一个假答案再拿这个假答案去检索。因为假答案的措辞风格更接近真实文档相似度匹配反而更准。实测下来在专业领域问答里HyDE 对召回率的提升相当明显代价是多了一次模型调用。查询改写不是万能的。如果改写本身引入了错误意图后面的检索会一路错下去。所以我的经验是改写结果要保留原始查询作为兜底两路检索结果合并后再做重排而不是完全替换。3.2 多路召回与混合检索单一向量检索的另一个问题是它对关键词精确匹配不敏感。比如用户问某个具体型号、编号、专有名词向量检索经常召回一堆语义相近但实体不对的内容。这时候就需要把 BM25 这类稀疏检索拉进来和稠密向量做混合。混合检索的关键在于融合策略。最简单的做法是加权求和但两路分数的量纲不一样直接加权很粗糙。更稳的做法是用倒数排名融合RRF只看排名不看分数鲁棒性更好。下面是一个 RRF 的简化实现思路def rrf_fusion(result_lists, k60): scores {} for results in result_lists: for rank, doc_id in enumerate(results): scores[doc_id] scores.get(doc_id, 0) 1.0 / (k rank 1) return sorted(scores.items(), keylambda x: x[1], reverseTrue)这段代码里 k 是个平滑参数一般取 60 左右。它的作用是压低头部排名的绝对优势让多路结果更均衡地融合。我试过在几个不同数据集上调整 k发现 40 到 80 之间效果差异不大不用太纠结。3.3 重排把“差不多”变成“最相关”多路召回解决了“找得全”但召回回来的东西排序往往是乱的。这时候就需要重排Rerank模型介入。重排模型通常是交叉编码器结构把查询和文档拼在一起打分精度比向量相似度高一个档次代价是计算量大只能对少量候选做。工程上的标准做法是召回阶段取 50 到 100 条重排阶段取 Top 5 到 10 条。这个比例不是拍脑袋定的而是精度和延迟的平衡点。召回太少会漏重排太多延迟扛不住。我一般会先看业务能接受的响应时间再倒推重排的候选数量。注意重排模型和 embedding 模型最好来自同一技术路线否则两者的语义空间不一致重排效果会打折扣。这一点很多教程不会提但实际调优时很关键。4. 第三代 RAG从“一次检索”到“迭代检索”让模型自己决定找什么4.1 自适应检索不是所有问题都需要查资料前面两代方案有个隐含假设每个问题都必须走检索。但现实中很多问题模型自己就能答强行检索反而引入噪声。自适应检索Adaptive Retrieval就是让模型先判断“这个问题需不需要查”需要再查。这个判断可以用一个小分类器做也可以直接用 prompt 让模型输出决策。我倾向于后者因为灵活、不用额外训练。判断逻辑大概是涉及事实性、时效性、专有信息的问题走检索纯推理、常识、创意类问题直接生成。4.2 迭代检索与自我反思更进一步的思路是让检索变成多轮。模型先根据问题检索一轮看完结果后判断“信息够不够”不够就生成新的查询再检一轮。这就是迭代检索Iterative Retrieval。配合自我反思Self-Reflection模型还能评估已检索内容的相关性把不相关的丢掉。这套机制听起来很美但工程上要小心循环失控。必须设置最大迭代次数和收敛条件否则模型可能陷入“再查一次”的死循环。我的做法是限制最多三轮并且每轮都要有明确的新增信息否则提前终止。4.3 一个容易忽略的细节检索结果的压缩迭代检索会带来一个新问题上下文里堆的文本块越来越多很快就撑爆窗口。这时候就需要上下文压缩——把检索回来的内容做摘要或抽取只保留和问题相关的部分。压缩可以用模型做也可以用规则做。规则做的好处是快且可控比如按句子和问题的相似度过滤。模型做的好处是能处理语义层面的冗余。实际项目里我通常两者结合先用规则粗筛再用模型精压。5. 第四代 RAG图结构与 Agent 化RAG 开始“长脑子”5.1 GraphRAG当知识之间存在关系传统 RAG 把文档切成孤立的块块与块之间的关系丢失了。但很多问题恰恰需要跨块推理比如“A 公司的创始人和 B 公司的投资方有什么交集”。这种问题靠向量检索几乎无解因为答案分散在多个文档里且需要关系推理。GraphRAG 的思路是先构建知识图谱把实体和关系抽出来检索时沿着图结构走。它能回答全局性、总结性的问题比如“这批文档主要讲了哪几个主题”。代价是构建图谱的成本高而且图谱质量直接决定效果。我的判断是GraphRAG 适合文档集合相对稳定、且问题涉及多跳关系的场景。如果文档天天变、问题又都是单点事实查询上图谱就是杀鸡用牛刀。5.2 Agentic RAG把检索当成一个工具Agent 化的 RAG 是最近讨论最多的方向。核心变化是检索不再是固定流程而是 Agent 可以调用的一个工具。Agent 根据任务需要自己决定什么时候检索、检索什么、要不要换工具。这就把 RAG 从“管道”变成了“决策系统”。好处是灵活性极高能处理复杂任务坏处是可控性下降调试难度上升。我见过不少团队一上来就搞 Agentic RAG结果连基础的召回都没调好最后效果还不如朴素方案。提示Agentic RAG 的前提是单步检索已经足够可靠。如果单步都检不准让 Agent 多调几次只会放大错误。5.3 长上下文与 RAG 的关系经常有人问上下文窗口都上百万 token 了RAG 是不是没必要了我的看法是长上下文和 RAG 不是替代关系而是互补。长上下文解决的是“信息能塞进去”RAG 解决的是“塞进去的是对的信息”。窗口再大塞一堆无关内容模型照样抓不住重点而且成本和延迟都上去了。实际做法是用 RAG 做粗筛把候选范围缩小再用长上下文做精细推理。这样既控制了成本又保证了信息密度。6. 演进背后的不变逻辑四个维度看 RAG 的收敛方向把四代方案拉通看会发现演进其实沿着四个维度在收敛。维度第一代第二代第三代第四代检索时机固定一次固定一次自适应、多轮Agent 决策检索来源单路向量多路混合多路压缩图工具信息组织平铺文本块重排后文本块压缩后文本块结构化知识反馈机制无无自我反思任务级闭环这张表想说明的是RAG 的演进不是简单堆功能而是在“找得准”和“用得好”之间不断找平衡。每一代都在补上一代的短板同时引入新的复杂度。选择哪一代取决于你的场景对准确率、延迟、成本、可维护性的综合要求。7. 实操建议不同场景该选哪一代方案7.1 场景匹配清单我把常见场景和推荐方案整理成下面这张表方便直接对照。场景特征推荐方案理由文档稳定、问题单点事实第二代混合检索重排性价比最高够用问题涉及多跳关系第四代GraphRAG需要关系推理任务复杂、步骤多第四代Agentic RAG需要动态决策文档频繁更新第二代自适应检索图谱维护成本太高对延迟极敏感第一代重排减少模型调用次数7.2 落地时的三个经验第一先把评测集建起来再谈优化。没有评测集所有调优都是盲调。评测集不用大一两百条覆盖核心场景就够但必须包含“应该拒答”的负样本。第二检索和生成分开调。先确保召回率达标再调生成。很多人一上来就换模型、改 prompt其实问题在检索端。第三别迷信最新方案。我见过太多团队追新框架结果基础召回率只有 60%换什么框架都救不回来。把第二代方案做扎实效果往往比半吊子的第四代好。8. 我在实际项目里踩过的几个坑说几个具体的。有一次做内部文档问答召回率一直上不去排查半天发现是 chunk 切分把表格切碎了导致关键信息丢失。后来改成按语义切分表格整体保留召回率直接涨了十几个点。这个坑很典型切分策略对召回的影响比换 embedding 模型还大。还有一次上重排模型延迟从 800ms 涨到 3 秒用户直接投诉。后来把重排候选从 100 降到 30延迟回到 1.5 秒效果只掉了不到两个点。这说明重排的边际收益是递减的没必要追求极致。最后一个坑是关于 Agentic RAG 的。早期让 Agent 自由决定检索次数结果它经常反复检索同样的内容token 消耗翻了好几倍。后来加了“检索结果去重”和“最大轮次限制”才把成本压下来。Agent 的自由度必须用约束框住否则它比固定流程还不可控。9. 关于“终”的一点个人理解标题里那个“终”字我琢磨了很久。它可能不是说 RAG 技术走到头了而是说RAG 这个概念本身正在消融。当检索、推理、生成越来越融为一体当 Agent 能自主调用各种工具RAG 就不再是一个独立的技术模块而是变成大模型应用的基础能力之一。就像当年“前后端分离”是个热门概念现在没人专门提了因为它已经成了默认做法。RAG 大概率也会走这条路——未来大家不会再问“你用不用 RAG”而是默认所有靠谱的应用都在做某种形式的上下文增强。所以与其纠结追哪一代方案不如把基本功打牢检索质量、上下文管理、评测体系。这三样做扎实了无论技术怎么演进你都能快速接上。我自己现在的做法是保持对新一代方案的关注但落地时永远从最稳的那一代起步验证有效再往上加。这样既不会错过趋势也不会被趋势带沟里。