1. RAG 概念澄清先别急着谈演进聊RAG检索增强生成之前有必要先对齐一个基础认知——很多人把RAG当成一个具体的技术组件其实它更像一套方法论把外部知识检索和大模型生成组合起来让模型在回答时不再只靠参数里那点记忆而是先查资料、再写答案。我第一次接触这个概念时正好踩过一个典型场景。当时手上有个内部知识库问答项目第一版直接拿通用模型硬跑效果惨不忍睹新上线的产品文档模型完全没见过张口就是幻觉运营同事问了三轮就开始吐槽这AI是不是在胡说八道。后来把所有相关文档全塞进上下文倒是能答了可上下文窗口被撑满稍微多问几句就超限成本也跟着暴涨。这个两难处境其实就是RAG要解决的核心问题怎么在不微调模型、不无限加长上下文的前提下让模型拿到刚好够用的外部知识。所以评估RAG演进时别只盯着某一个环节。按我自己的拆法RAG链路大致分四段索引Indexing、检索Retrieval、增强Augmentation、生成Generation。每一段都有各自的演进逻辑而且演进方向基本围绕三个痛点展开——检索准不准、上下文塞得合不合理、生成结果可不可信。下面我按这条主线梳理。2. 朴素期向量检索 粗暴拼接2.1 第一代RAG的基本形态早期RAG的流程非常朴素可以概括成四步把知识库文档切成固定大小的chunk比如256或512个token。用嵌入模型把每个chunk转成向量存入向量数据库。用户提问时把问题也转成向量在库里做相似度检索取Top-K。把检索到的chunk拼在系统提示词后面一起交给生成模型。这套流程解决了一个大问题模型终于能临时翻书了。在当时它对长尾知识和实时信息的有效性提升是颠覆性的所以很快成了标配。但它的问题也很快暴露。最直观的问题是向量相似度不等于语义相关更不等于能回答用户问题。我做过一个实验问员工请假流程需要几步检索系统按向量距离返回了五段内容两段讲请假审批、三段讲考勤补卡看着都沾边真正对应的步骤说明却被切碎散落在其他chunk里。模型拿到了检索结果依然答不全。这个现象后来被总结为检索漂移越依赖向量距离越容易被表面相似的内容带偏。2.2 固定切片带来的连锁反应固定切片是另一个隐患。按固定token数切分文档完全不关心语义边界导致一个完整概念被拦腰截断或者几段不相干的内容被硬拼成一个chunk。更麻烦的是切片长度本身直接影响检索效果切太长chunk里混合多个主题向量表征被稀释切太短语义不完整检索回来信息支离破碎。我当时调一个合同问答项目时对比过128、256、512三种切片长度结果很典型128 token切片召回内容太碎经常需要拼3段以上才能凑齐一个条款要素而且拼起来逻辑顺序还经常不对。512 token切片单个chunk里混入了多条条款检索时命中噪声明显增多模型容易被无关内容干扰。256 token切片相对均衡但对纯表格型条款仍然不友好。这个阶段我个人的总结是以固定token切片为代表的朴素RAG本质上是拿工程简单性换检索精准度所有问题都源于一个根本性矛盾——通用检索单元和语义完整性之间不可兼得。3. 进阶检索从查相似到查得准3.1 混合检索为什么成为标配第一代RAG的检索通道只有向量相似度一条这带来一个致命盲区向量模型擅长语义泛化却不擅长精确匹配。典型场景是查订单号、身份证号、合同编号这类精确标识或者查VAT-2024-001和VAT 2024 001这种细微差异。由于向量空间里这两个文本的表示可能极近模型会漏掉严格的字符约束。解决方案就是混合检索Hybrid Search把向量检索和关键词检索比如BM25的结果做融合。关键词负责精确命中向量负责语义召回。这是演进中最稳的一步因为它不改变任何底层模型只把召回策略从单通道变成多通道效果提升却立竿见影。3.2 重排序的引入第一次向精准低头混合检索解决了召回广度问题却没有解决排序精度问题。Top-K甚至Top-20里依然混着大量看似相关、实则无用的内容。于是重排序Rerank模块被引入。重排序的典型做法是把候选段落与用户问题同时喂给一个更强的交叉编码器逐对计算相关性分数再重新排序。因为交叉编码器能看到问题和候选的完整交互所以比单纯的双塔向量相似度更准。代价也明显——每对都要单独算推理成本高所以一般只对Top-20或Top-50做重排。我们实际测试下来加重排后检索结果的前三位命中率能提升两成以上。但也要提醒一句重排不是万能药如果候选池本身没有正确答案重排只能让矮子里拔将军的过程更体面。3.3 查询改写与HyDE让问题先被理解早期系统直接拿用户原话去检索问题在于口语化表达和文档行文差异太大经常出现问A库中记B。演进中比较有代表性的思路是查询改写先让大模型把用户问题拆解成多个子查询、提取关键词或补全语义再分别检索、汇总结果。比查询改写更“激进”的是HyDE假设性文档嵌入。思路是先让模型根据问题生成一段假设答案再用这段假设答案的向量去检索。这打破了“拿问题向量去找文档向量”的惯性——假设答案与知识库文档在体裁和详略层次上更接近检索往往更准。但HyDE对模型本身的生成能力有依赖生成太离谱检索结果也会跟着跑偏。现在很多项目依然在用只是通常和查询改写配合使用而不是二选一。4. 索引升级文档不再是整段扔进去4.1 小向量 父文档兼顾精确与上下文检索精度提升之后下一个瓶颈出现在上下文利用上。早期直接把检索到的chunk全部塞给模型经常出现相关但不完整的问题检索到的片段只是某条款第一步后续步骤在另一段里模型看不到。这时候出现了一个非常实用的模式——小到大检索Small-to-Big具体做法是索引时把原文切成小块向量比如句子级别同时记录每块的父文档比如整个段落或章节。检索时用小块做相似度匹配拿到结果后再把父文档整体取出交给模型。这么做的好处是匹配粒度精细上下文完整性由父文档保障。坏处是token消耗变大对上下文窗口要求也更高。但相比拼多个破烂chunk一次把完整段落喂进去生成的逻辑连贯性确实更好。我在多个项目里用它替代固定切片在问答完整度上的提升非常明显。4.2 结构化索引与Metadata过滤另一个重要演进是给chunk打标签在检索前先做条件过滤。早期所有文档一视同仁没有区分适用范围时间生效保密级别导致检索经常把过期文档或别的部门的内部说明捞出来。演进方向是做结构化索引每段chunk附带metadata如文档创建时间、部门、文档类型、版本号、适用范围等。检索时先按metadata做硬性过滤再在候选集内做向量匹配。举个例子一个多租户问答系统里如果不加租户ID过滤A租户的问题就可能检索到B租户的内部文档。这已经不是质量问题而是权限事故。所以在我看索引升级的最大意义不是提分而是“可控”。4.3 图索引与知识图谱增强再往后是图索引。普通文档拆分只保留线性邻接关系而知识图谱显式保存实体、关系、因果链路。把两者结合就有了GraphRAG这类方案先用LLM从文档中抽取实体和关系生成图结构再在检索时沿着图结构扩展相关实体。尤其在多跳问题上比如该供应商参与了哪些与XX合同相关的项目线性chunk检索经常漏掉中间实体而图索引天然把这种关系组织好了。代价是构建图成本高且受实体抽取质量约束。5. 上下文组装从全部塞进去到用得刚刚好5.1 上下文压缩解决信息过载检索链路变强之后新的问题浮出水面系统拿回的上下文越来越多但模型阅读理解能力有限塞太多无关内容反而干扰答案甚至被噪声带着跑。为解决这个问题出现了上下文压缩Context Compression技术。核心做法是先让模型或轻量分类器对检索结果做相关性和信息密度筛选丢弃低价值片段保留高价值段落再拼给生成模型。我当时在一个客服FAQ项目里试过不加压缩时全量塞进Top-10的chunk模型被无关内容干扰严重加了压缩之后有效信息保留率明显上升generation阶段的幻觉明显下降。这背后的逻辑很简单——LLM和人类读者一样资料越杂乱越容易逮着两句貌似相关的话就开始发挥。5.2 重新打包与段落排序另一个常被忽视的细节是检索回来的段落顺序未必适合生成模型阅读。向量检索按相似度排序但相似度高的不一定排在逻辑链条前面。演进中出现了重新打包Reordering思路不是简单删减而是基于段落间的逻辑关系或与问题的依赖顺序重新排列让模型读到的上下文更接近先背景、再过程、后结论的自然阅读顺序。这个环节不引入新检索信号纯粹在组装阶段优化信息排布。看起来不起眼但对生成质量的影响比想象中大。有一次我们做对比实验其他环节完全相同只调整了chunk顺序人工打分的流畅度和信息完整度就产生了明显差距。5.3 迭代检索与多轮引用的处理把上下文组装从单轮扩展到多轮也是演进中的重要节点。早期RAG追求一次性检索、一次性生成遇到复杂问题就崩。后来出现迭代检索Iterative Retrieval模型先看第一轮检索结果发现信息不够再发第二轮查询补充检索循环直到答案完整。在多轮对话场景中还需要解决指代消解问题。用户上一轮说那个流程这一轮问那它需要谁审批如果直接拿原始句子去检索什么都查不到。演进做法是先对当前问题做大模型改写、解析指代再带上下文去检索。这也是当前主流RAG框架都内置Query Rewriting的原因。6. 生成端演进从防幻觉到设计打脸机制6.1 引用溯源成为硬性要求RAG演进早期只关注答得好不好不太在意为什么这么答。但在企业落地阶段给出处很快成了硬性需求。主要原因是RAG系统的幻觉虽然比纯LLM少但并未消失光靠肉眼判断不可靠业务侧更不可能凭感觉信任一段AI生成的回答尤其是涉及合同条款、法规、临床建议等场景。于是引用溯源Citation / Source Traceability成为标配生成结果的每个关键片段都附带对应的检索来源chunk。用户在UI上直接点击引用就能看到原文对应位置。这个能力看似简单真正做起来有不少细节需要考量引用粒度是句子级还是段落级来源定位到文件还是页码多来源信息互相矛盾时如何呈现。我曾经在一个内部运维知识库做实测评估加了强制引用之后用户对回答的信任度评价明显上升原因很简单——引用给了用户“去原文核对”的机会这个动作本身会削弱对幻觉的恐惧。但对引用不能盲目信任因为它的核心机制是指向来源而非保证正确如果前端判断不严谨仍然可能导向错误位置。6.2 反驳机制当检索结果和模型认知冲突演进中非常有意思的一步是引入反驳机制。传统做法是检索结果永远最高优先模型只能顺着检索结果生成答案但检索结果并不总是正确的可能是文档本身有误也可能是检索排名把错误内容放在了前面。此时生成端需要一种能力——如果模型根据自身知识强烈判断这个问题不该这么答它能明确地提出质疑而不是硬着头皮按检索内容编。具体实现可以从两个方向做一种是在系统提示词里显式声明如果检索内容与事实冲突请指出并提供参考依据另一种是在生成结果中加入置信度评估模块让模型在不确定时主动降级输出而不是硬编。我自己的体会是这种方案比单纯加提示词更有效因为它把“承认不知道”变成了生成策略的一个选项而不是一个禁忌。6.3 多模型协作与Agent化萌芽演进后期生成端从单模型变成多模型协作。比如规划模型负责拆解复杂问题生成模型负责最终作答评估模型负责检查答案与引用的对应关系发现不对就回退重生成。这就把RAG从检索 生成的两段式推向检索 规划 写作 审校的多智能体协作流程。Agent化是比多模型协作更进一步的趋势但它走的路线偏工程化不再把检索当成一个固定函数调用而是将是否检索、检索什么、检索多少次、怎样使用检索结果都交给模型动态决策。所以每一步都不是链上写死的步骤而是模型在每一轮自主决定下一步行动。这里的争论点在于模型自主决策会带来不确定性和调试困难是否有必要仍然取决于场景复杂性。7. 演进本质与未来落点梳理RAG的演进我有一个越来越清晰的判断RAG的演进方向不是越来越花哨而是越来越克制。每个关键节点的核心推动力都源于应用落地时被暴露出的问题——检索不准就加混合检索上下文被撑爆就做压缩用户不信任就加引用溯源。演进本质上是被需求推着走而不是被论文推着走。未来一段时间的落点我比较关注三个方向。第一是检索与生成的联合优化检索结果的质量直接影响生成输出而生成输出的品质又反过来决定对检索结果的取舍二者应该做端到端的联合建模而不是各自优化之后再拼接。第二是更可控的自适应检索即系统能在多大程度上自主判断何时该检索、何时该直接回答。第三是检索评估体系的升级。当前很多项目按检索阶段的RecallK和生成阶段的ROUGE/BLEU分别评估这割裂了“检索质量”和“答案质量”的联动关系。未来需要用端到端指标评估整个链路的整体效果甚至把幻觉率、引用正确率、人工满意度这类实际落地指标纳入统一评测框架。做RAG这么长时间我最大的感受是RAG这套技术看似简单真正的问题往往出在那些论文里很少提及的边界情况上——索引怎么切、metadata怎么标、召回结果怎么调、模型误判怎么兜底。每个环节都能折腾掉大把时间也恰恰是每个环节的精细化才让RAG从能跑走到好用。后续有机会我继续写写“RAG 技术演进一览下”把工程落地、评测体系、可观测性和迭代调优等更贴近生产实践的部分展开聊聊欢迎持续关注。 
长河君 · 2026/10/22 10:57:56 · 阅读 1.2k RAG技术演进全解析：从朴素检索到生成增强的工程实践
1. RAG 概念澄清先别急着谈演进聊RAG检索增强生成之前有必要先对齐一个基础认知——很多人把RAG当成一个具体的技术组件其实它更像一套方法论把外部知识检索和大模型生成组合起来让模型在回答时不再只靠参数里那点记忆而是先查资料、再写答案。我第一次接触这个概念时正好踩过一个典型场景。当时手上有个内部知识库问答项目第一版直接拿通用模型硬跑效果惨不忍睹新上线的产品文档模型完全没见过张口就是幻觉运营同事问了三轮就开始吐槽这AI是不是在胡说八道。后来把所有相关文档全塞进上下文倒是能答了可上下文窗口被撑满稍微多问几句就超限成本也跟着暴涨。这个两难处境其实就是RAG要解决的核心问题怎么在不微调模型、不无限加长上下文的前提下让模型拿到刚好够用的外部知识。所以评估RAG演进时别只盯着某一个环节。按我自己的拆法RAG链路大致分四段索引Indexing、检索Retrieval、增强Augmentation、生成Generation。每一段都有各自的演进逻辑而且演进方向基本围绕三个痛点展开——检索准不准、上下文塞得合不合理、生成结果可不可信。下面我按这条主线梳理。2. 朴素期向量检索 粗暴拼接2.1 第一代RAG的基本形态早期RAG的流程非常朴素可以概括成四步把知识库文档切成固定大小的chunk比如256或512个token。用嵌入模型把每个chunk转成向量存入向量数据库。用户提问时把问题也转成向量在库里做相似度检索取Top-K。把检索到的chunk拼在系统提示词后面一起交给生成模型。这套流程解决了一个大问题模型终于能临时翻书了。在当时它对长尾知识和实时信息的有效性提升是颠覆性的所以很快成了标配。但它的问题也很快暴露。最直观的问题是向量相似度不等于语义相关更不等于能回答用户问题。我做过一个实验问员工请假流程需要几步检索系统按向量距离返回了五段内容两段讲请假审批、三段讲考勤补卡看着都沾边真正对应的步骤说明却被切碎散落在其他chunk里。模型拿到了检索结果依然答不全。这个现象后来被总结为检索漂移越依赖向量距离越容易被表面相似的内容带偏。2.2 固定切片带来的连锁反应固定切片是另一个隐患。按固定token数切分文档完全不关心语义边界导致一个完整概念被拦腰截断或者几段不相干的内容被硬拼成一个chunk。更麻烦的是切片长度本身直接影响检索效果切太长chunk里混合多个主题向量表征被稀释切太短语义不完整检索回来信息支离破碎。我当时调一个合同问答项目时对比过128、256、512三种切片长度结果很典型128 token切片召回内容太碎经常需要拼3段以上才能凑齐一个条款要素而且拼起来逻辑顺序还经常不对。512 token切片单个chunk里混入了多条条款检索时命中噪声明显增多模型容易被无关内容干扰。256 token切片相对均衡但对纯表格型条款仍然不友好。这个阶段我个人的总结是以固定token切片为代表的朴素RAG本质上是拿工程简单性换检索精准度所有问题都源于一个根本性矛盾——通用检索单元和语义完整性之间不可兼得。3. 进阶检索从查相似到查得准3.1 混合检索为什么成为标配第一代RAG的检索通道只有向量相似度一条这带来一个致命盲区向量模型擅长语义泛化却不擅长精确匹配。典型场景是查订单号、身份证号、合同编号这类精确标识或者查VAT-2024-001和VAT 2024 001这种细微差异。由于向量空间里这两个文本的表示可能极近模型会漏掉严格的字符约束。解决方案就是混合检索Hybrid Search把向量检索和关键词检索比如BM25的结果做融合。关键词负责精确命中向量负责语义召回。这是演进中最稳的一步因为它不改变任何底层模型只把召回策略从单通道变成多通道效果提升却立竿见影。3.2 重排序的引入第一次向精准低头混合检索解决了召回广度问题却没有解决排序精度问题。Top-K甚至Top-20里依然混着大量看似相关、实则无用的内容。于是重排序Rerank模块被引入。重排序的典型做法是把候选段落与用户问题同时喂给一个更强的交叉编码器逐对计算相关性分数再重新排序。因为交叉编码器能看到问题和候选的完整交互所以比单纯的双塔向量相似度更准。代价也明显——每对都要单独算推理成本高所以一般只对Top-20或Top-50做重排。我们实际测试下来加重排后检索结果的前三位命中率能提升两成以上。但也要提醒一句重排不是万能药如果候选池本身没有正确答案重排只能让矮子里拔将军的过程更体面。3.3 查询改写与HyDE让问题先被理解早期系统直接拿用户原话去检索问题在于口语化表达和文档行文差异太大经常出现问A库中记B。演进中比较有代表性的思路是查询改写先让大模型把用户问题拆解成多个子查询、提取关键词或补全语义再分别检索、汇总结果。比查询改写更“激进”的是HyDE假设性文档嵌入。思路是先让模型根据问题生成一段假设答案再用这段假设答案的向量去检索。这打破了“拿问题向量去找文档向量”的惯性——假设答案与知识库文档在体裁和详略层次上更接近检索往往更准。但HyDE对模型本身的生成能力有依赖生成太离谱检索结果也会跟着跑偏。现在很多项目依然在用只是通常和查询改写配合使用而不是二选一。4. 索引升级文档不再是整段扔进去4.1 小向量 父文档兼顾精确与上下文检索精度提升之后下一个瓶颈出现在上下文利用上。早期直接把检索到的chunk全部塞给模型经常出现相关但不完整的问题检索到的片段只是某条款第一步后续步骤在另一段里模型看不到。这时候出现了一个非常实用的模式——小到大检索Small-to-Big具体做法是索引时把原文切成小块向量比如句子级别同时记录每块的父文档比如整个段落或章节。检索时用小块做相似度匹配拿到结果后再把父文档整体取出交给模型。这么做的好处是匹配粒度精细上下文完整性由父文档保障。坏处是token消耗变大对上下文窗口要求也更高。但相比拼多个破烂chunk一次把完整段落喂进去生成的逻辑连贯性确实更好。我在多个项目里用它替代固定切片在问答完整度上的提升非常明显。4.2 结构化索引与Metadata过滤另一个重要演进是给chunk打标签在检索前先做条件过滤。早期所有文档一视同仁没有区分适用范围时间生效保密级别导致检索经常把过期文档或别的部门的内部说明捞出来。演进方向是做结构化索引每段chunk附带metadata如文档创建时间、部门、文档类型、版本号、适用范围等。检索时先按metadata做硬性过滤再在候选集内做向量匹配。举个例子一个多租户问答系统里如果不加租户ID过滤A租户的问题就可能检索到B租户的内部文档。这已经不是质量问题而是权限事故。所以在我看索引升级的最大意义不是提分而是“可控”。4.3 图索引与知识图谱增强再往后是图索引。普通文档拆分只保留线性邻接关系而知识图谱显式保存实体、关系、因果链路。把两者结合就有了GraphRAG这类方案先用LLM从文档中抽取实体和关系生成图结构再在检索时沿着图结构扩展相关实体。尤其在多跳问题上比如该供应商参与了哪些与XX合同相关的项目线性chunk检索经常漏掉中间实体而图索引天然把这种关系组织好了。代价是构建图成本高且受实体抽取质量约束。5. 上下文组装从全部塞进去到用得刚刚好5.1 上下文压缩解决信息过载检索链路变强之后新的问题浮出水面系统拿回的上下文越来越多但模型阅读理解能力有限塞太多无关内容反而干扰答案甚至被噪声带着跑。为解决这个问题出现了上下文压缩Context Compression技术。核心做法是先让模型或轻量分类器对检索结果做相关性和信息密度筛选丢弃低价值片段保留高价值段落再拼给生成模型。我当时在一个客服FAQ项目里试过不加压缩时全量塞进Top-10的chunk模型被无关内容干扰严重加了压缩之后有效信息保留率明显上升generation阶段的幻觉明显下降。这背后的逻辑很简单——LLM和人类读者一样资料越杂乱越容易逮着两句貌似相关的话就开始发挥。5.2 重新打包与段落排序另一个常被忽视的细节是检索回来的段落顺序未必适合生成模型阅读。向量检索按相似度排序但相似度高的不一定排在逻辑链条前面。演进中出现了重新打包Reordering思路不是简单删减而是基于段落间的逻辑关系或与问题的依赖顺序重新排列让模型读到的上下文更接近先背景、再过程、后结论的自然阅读顺序。这个环节不引入新检索信号纯粹在组装阶段优化信息排布。看起来不起眼但对生成质量的影响比想象中大。有一次我们做对比实验其他环节完全相同只调整了chunk顺序人工打分的流畅度和信息完整度就产生了明显差距。5.3 迭代检索与多轮引用的处理把上下文组装从单轮扩展到多轮也是演进中的重要节点。早期RAG追求一次性检索、一次性生成遇到复杂问题就崩。后来出现迭代检索Iterative Retrieval模型先看第一轮检索结果发现信息不够再发第二轮查询补充检索循环直到答案完整。在多轮对话场景中还需要解决指代消解问题。用户上一轮说那个流程这一轮问那它需要谁审批如果直接拿原始句子去检索什么都查不到。演进做法是先对当前问题做大模型改写、解析指代再带上下文去检索。这也是当前主流RAG框架都内置Query Rewriting的原因。6. 生成端演进从防幻觉到设计打脸机制6.1 引用溯源成为硬性要求RAG演进早期只关注答得好不好不太在意为什么这么答。但在企业落地阶段给出处很快成了硬性需求。主要原因是RAG系统的幻觉虽然比纯LLM少但并未消失光靠肉眼判断不可靠业务侧更不可能凭感觉信任一段AI生成的回答尤其是涉及合同条款、法规、临床建议等场景。于是引用溯源Citation / Source Traceability成为标配生成结果的每个关键片段都附带对应的检索来源chunk。用户在UI上直接点击引用就能看到原文对应位置。这个能力看似简单真正做起来有不少细节需要考量引用粒度是句子级还是段落级来源定位到文件还是页码多来源信息互相矛盾时如何呈现。我曾经在一个内部运维知识库做实测评估加了强制引用之后用户对回答的信任度评价明显上升原因很简单——引用给了用户“去原文核对”的机会这个动作本身会削弱对幻觉的恐惧。但对引用不能盲目信任因为它的核心机制是指向来源而非保证正确如果前端判断不严谨仍然可能导向错误位置。6.2 反驳机制当检索结果和模型认知冲突演进中非常有意思的一步是引入反驳机制。传统做法是检索结果永远最高优先模型只能顺着检索结果生成答案但检索结果并不总是正确的可能是文档本身有误也可能是检索排名把错误内容放在了前面。此时生成端需要一种能力——如果模型根据自身知识强烈判断这个问题不该这么答它能明确地提出质疑而不是硬着头皮按检索内容编。具体实现可以从两个方向做一种是在系统提示词里显式声明如果检索内容与事实冲突请指出并提供参考依据另一种是在生成结果中加入置信度评估模块让模型在不确定时主动降级输出而不是硬编。我自己的体会是这种方案比单纯加提示词更有效因为它把“承认不知道”变成了生成策略的一个选项而不是一个禁忌。6.3 多模型协作与Agent化萌芽演进后期生成端从单模型变成多模型协作。比如规划模型负责拆解复杂问题生成模型负责最终作答评估模型负责检查答案与引用的对应关系发现不对就回退重生成。这就把RAG从检索 生成的两段式推向检索 规划 写作 审校的多智能体协作流程。Agent化是比多模型协作更进一步的趋势但它走的路线偏工程化不再把检索当成一个固定函数调用而是将是否检索、检索什么、检索多少次、怎样使用检索结果都交给模型动态决策。所以每一步都不是链上写死的步骤而是模型在每一轮自主决定下一步行动。这里的争论点在于模型自主决策会带来不确定性和调试困难是否有必要仍然取决于场景复杂性。7. 演进本质与未来落点梳理RAG的演进我有一个越来越清晰的判断RAG的演进方向不是越来越花哨而是越来越克制。每个关键节点的核心推动力都源于应用落地时被暴露出的问题——检索不准就加混合检索上下文被撑爆就做压缩用户不信任就加引用溯源。演进本质上是被需求推着走而不是被论文推着走。未来一段时间的落点我比较关注三个方向。第一是检索与生成的联合优化检索结果的质量直接影响生成输出而生成输出的品质又反过来决定对检索结果的取舍二者应该做端到端的联合建模而不是各自优化之后再拼接。第二是更可控的自适应检索即系统能在多大程度上自主判断何时该检索、何时该直接回答。第三是检索评估体系的升级。当前很多项目按检索阶段的RecallK和生成阶段的ROUGE/BLEU分别评估这割裂了“检索质量”和“答案质量”的联动关系。未来需要用端到端指标评估整个链路的整体效果甚至把幻觉率、引用正确率、人工满意度这类实际落地指标纳入统一评测框架。做RAG这么长时间我最大的感受是RAG这套技术看似简单真正的问题往往出在那些论文里很少提及的边界情况上——索引怎么切、metadata怎么标、召回结果怎么调、模型误判怎么兜底。每个环节都能折腾掉大把时间也恰恰是每个环节的精细化才让RAG从能跑走到好用。后续有机会我继续写写“RAG 技术演进一览下”把工程落地、评测体系、可观测性和迭代调优等更贴近生产实践的部分展开聊聊欢迎持续关注。