做RAG落地这两年我最大的体会是限制系统上限的往往不是生成模型本身而是检索那一环。CRAG、Self-RAG、Adaptive RAG这三篇论文是2023到2024年间绕不开的三个进阶方案也是把RAG从“检索生成”的朴素流水线推向“决策反思纠偏”的关键工作。这篇总结会把它们的核心机制、训练方式和适用场景逐一拆开同时给出我复现和落地过程中的一些经验已经跑通朴素RAG、正在优化线上效果的同学适合读刚入坑、想整体了解RAG发展脉络的新人也不会觉得吃力。1. RAG的进化路线先看清三篇论文要解决什么1.1 朴素RAG最让人头疼的不是“搜不到”而是“搜不准”大家一开始做RAG思路通常很直白把用户问题拿去向量检索把召回文档拼进Prompt让模型基于文档生成回答。早期这套流程能解决很多“知识问答”类需求但一旦放到真实业务里痛点马上暴露出来。第一个痛点是检索结果没有校验机制。向量检索返回的文档是否真的和问题相关系统本身并不知道文档一旦拼进上下文模型就会把它当成可信依据来用。如果召回的是似是而非的内容模型很容易被误导着说出更离谱的答案这比直接让模型凭记忆回答还要危险。第二个痛点是多跳问题处理不了。实际问题经常没法靠一次检索解决。比如用户问“某个作者在获奖之后又写了哪本书”这需要先查出作者是谁再顺着作者去查后续作品。一次检索只能拿到部分信息而传统的“检索-生成”流程根本不支持多轮查询和中间推理。第三个痛点是模型没有自我评估的能力。它不知道当前证据够不够也不知道自己生成的内容是否被文档支撑。生成结果就算存在事实性错误系统也只能照单全收。所以朴素RAG的天花板并不在检索器的召回率而在于整个流水线缺少“决策感”该不该检索、检索结果可不可信、答案有没有证据支撑这些环节全都被跳过了。后来的RAG改进工作基本都是在补这些决策能力。1.2 三条技术路线为什么能成为经典Adaptive RAG、Self-RAG、CRAG这三篇论文放在一起读特别有价值因为它们恰好从三个不同角度回答了上面那些决策问题。Adaptive RAG把“问题复杂度”当作核心决策依据。它训练一个分类器先判断当前问题是简单到可以直接回答还是需要检索甚至需要多步检索再决定走哪条生成分支。这段思路背后是一个很朴实的观察不同复杂度的查询需要的处理方式本就不同。简单问题强行配一堆检索文档反而会被无关信息干扰。Self-RAG则把决策权交给生成模型自己。它训练LLM在生成过程中输出一组反思Token让模型自查我现在需不需要去检索召回文档和问题相关吗我的回答有证据支撑吗对用户有没有用模型一边生成、一边评价自己等于把评审团塞进了生成过程。CRAG针对的是“检索结果不完美”这个普遍现实。它引入一个轻量级检索评估器先给检索结果判级内容可靠就直接用不可靠就丢弃并重新检索模棱两可就换一种方式补充搜索。核心思想是不要无脑信任检索结果该纠偏就纠偏。这三篇论文之所以算经典不是说它们用了多复杂的网络结构而是它们共同把一个纯流水线式的RAG变成了有路由、有反思、有纠偏的决策系统。理解了它们再去读后来的Agent式RAG、带自我批评的对齐方法、以及各种可插拔RAG组件会轻松很多。2. 拆解Adaptive RAG路由器如何决定“检索还是不检索”2.1 核心思路给问题先做个难度分诊Adaptive RAG的架构很好理解。它把整个问答过程分成三段第一段是一个复杂度分类器第二段是三条策略分支第三段是统一的生成器。复杂度分类器就是整个系统的路由器。给定一个Query它输出三个判断结果不需要检索、需要单步检索、需要多步检索。不需要检索时系统直接让生成模型回答需要单步检索时走一次经典RAG流程需要多步检索时则进入类似“检索-推理-再检索”的循环直到信息足够。这个设计很像医院分诊台。头疼脑热的小毛病直接去门诊需要拍片的去影像科情况复杂的走多科室会诊。如果所有病人都先去拍一套全身CT浪费资源不说正常的救治流程也被拉长。RAG也一样统一走检索分支的问题在于简单问题被多余的检索文档干扰复杂问题又因为检索步数不够而答不全。我相当喜欢这个方案的工程切入点。它把所有决策压力都集中在一个轻量分类器上生成模型本身基本不用动。你可以在现有RAG服务前面套一个Router根据分类结果决定内部走哪条链路改动成本非常低。2.2 训练过程与损失设计Adaptive RAG训练的核心是那个复杂度分类器。论文里的做法是先准备一批带答案的问答样本再用一个能力足够强的通用大模型给每个Query标注策略标签。比如某个简单常识问题被标成“不需要检索”某个需要查资料的问题被标成“单步检索”某个需要多跳推理的问题被标成“多步检索”。这一步的本质是把大模型的判断能力蒸馏到一个轻量模型上。标签构造好之后去训练一个小型文本分类模型替换掉昂贵的LLM Router推理时只花极小的代价就能完成路由。损失函数上也做了特殊设计。分类器不只要“把问题分对”还要“让下游生成效果更好”。整体损失可以写成L L_cls λL_policyL_cls是常规的分类交叉熵用来保证路由判断的准确率。L_policy则模拟下游问答任务的效果让路由决策能根据“最终答案好不好”来调整。这样训练出来的路由器不只是机械地按照某个规则分堆而是真正学会了什么样的Query该走哪条路。论文实验里最直观的收益是整体准确率维持甚至超过统一使用多步检索的强基线同时检索调用次数明显下降。这对线上系统的延迟和成本非常友好尤其当问题池里混着大量简单问题时“少检索”本身就是很大的优化。2.3 这套方案在实际工程中的注意事项Adaptive RAG是我认为三篇里最适合作为“起步改造项”的因为它的改动边界非常清晰。你可以把它包装成一个独立的路由服务上端接收Query下端对接现有RAG流程业务方几乎无感知。但有几个工程细节需要特别留意。第一复杂度分类器很容易出现分布偏移。训练时用的Query风格、主题范围和线上真实Query一旦差异太大路由器就会开始乱判。我见过的典型情况是离线评测分类准确率80%以上上线之后简单问题被路由到多步检索分支延迟翻倍用户体验明显下降。第二建议不要做硬路由。不要非A即B地只走某一条分支而是给分类器加一个置信度阈值。当某个类别的预测概率低于阈值时默认走保守分支通常是单步检索。这样可以把分类器的不确定性兜住避免一次误判就把整条链路带偏。第三路由器本身也可以做成级联的。先用一个便宜的规则或小模型过滤掉明显不需要检索的问题剩下的再交给你训练的复杂度分类器。分诊台外面先放个体检护士能省下不少主诊医生的时间。3. 拆解Self-RAG让模型生成答案的同时自我评判3.1 反思Token机制到底是什么如果说Adaptive RAG是把决策放到外部路由那Self-RAG就是彻底把决策内化到模型里。论文的核心贡献是设计了一组特殊的反思Token让LLM在生成过程中同步输出“对自身生成行为的评价”。这组反思Token分四类第一类是检索触发Token模型决定当前步骤需不需要调用外部检索。第二类是相关度Token模型在拿到检索文档后判断文档内容是否和当前问题相关。第三类是证据支持Token模型在生成答案片段后判断这段内容是被证据充分支撑、部分支撑还是没有支撑。第四类是实用性Token模型从用户角度判断整段回答到底有没有用、有多大用。可以这样理解普通RAG是“模型闷头写答案写完了事”Self-RAG则是“模型每写一段都要拿自检清单看一眼”。我不需要外部评估器来判断答案好不好模型自己就把证据核查和答案评审做完了。这个机制对缓解幻觉特别有价值。传统生成过程里模型如果凭印象编了个细节它自己是意识不到的。但Self-RAG在训练阶段就强迫模型输出“当前答案被证据支撑到什么程度”的Token等于把“自我怀疑”变成了生成习惯。3.2 训练阶段的两个关键设计Self-RAG不额外训练独立的Critic模型而是让生成模型自己同时产出反思Token和答案内容这是训练设计上最巧妙的地方。具体做法是先用一个能力较强的模型通过Few-shot提示词生成一批“反思Token答案”混合的训练文本。例如给一条问答样本让模型先输出“是否需要检索”的Token如果检索了文档再输出“文档是否相关”的Token答案生成完再输出“证据支持程度”和“实用性评分”的Token。这些带反思Token的文本被当作标准训练语料去微调基座模型。训练损失本质上还是标准的语言模型负对数似然只不过预测目标从“普通文本”变成了“普通文本反思Token”。基座模型不只学会回答问题还学会了对自己的回答做点评。这种设计有一个非常直接的好处推理阶段不需要额外加载一个评审模型生成和评估共用一套参数部署结构更干净。论文里的实验结论也很能说明问题Self-RAG在事实性、引用准确性、长篇生成一致性等指标上明显优于普通RAG和直接微调的模型尤其在需要模型给出可验证事实的场景下错误率大幅下降。3.3 推理时如何选出“最值得输出”的答案Self-RAG的推理方式和普通生成不一样不是贪心解码一次到底而是先采样后打分。模型对同一个问题生成多个候选答案片段每个片段都伴随一串反思Token。系统把候选片段的Token分数提取出来加权计算出该片段的得分哪个候选得分高就输出哪个。这个过程和论文评审很像。先让多个作者各自写一版回答每版回答都附带“参考文献在不在、相关性强不强、结论有没有被证据支撑、对提问者有没有用”的评分最后选总分最高的一版。因为每一版都被要求自评所以最后选出来的往往不是最花哨的而是证据链最稳的那个。实际复现时要注意Self-RAG的采样轮数和Token权重直接影响效果。采样太少候选池多样性不足反思Token的优势发挥不出来权重设置不合理又可能让“实用性”压过“证据支持”模型为了迎合用户而牺牲事实性。我一般会把“证据支持”的权重调得比“实用性”高一些特别是在知识问答类业务里事实正确永远优先。另外要提醒一点Self-RAG是需要微调生成模型的方案。如果你使用的是不开源的商用API或者没有模型微调条件这套方法基本落不了地。这也是它和Adaptive RAG最本质的区别一个是外挂组件一个是模型自身能力升级。4. 拆解CRAG当检索文档不可信时靠什么纠偏4.1 检索评估器如何给文档“判级”CRAG的核心切入点非常现实无论检索器多强总会有召回文档不准确、不完整的情况。既然无法保证检索百分之百可靠那就加一道质检工序在文档进入生成模型之前先验一遍。这道质检工序是一个轻量级检索评估器。它接收用户Query和召回文档作为输入输出一个置信度评分再把评分映射到三个档位Correct、Incorrect、Ambiguous。三个档位对应完全不同的动作可以用下面这张表快速看明白置信度档位系统采取的动作解决的核心问题典型落地形态Correct直接信任检索结果走增强生成流程让可靠信息顺利进入生成阶段把文档交给生成模型作为上下文Incorrect丢弃当前检索结果重新构造查询并再次检索必要时切换检索源防止错误文档污染生成结果触发一次新的检索或走备选知识库Ambiguous不直接丢弃也不完全信任结合多种来源补充搜索后再综合判断覆盖部分相关、部分不相关的文档重构查询并补充一轮网络搜索这套动作设计的核心思想是不要把所有检索结果一视同仁地塞进Prompt先把文档分成“能用、不能用、部分能用”三类再决定怎么用。它相比传统RAG的改进不是把检索做得多完美而是降低上游检索误差对下游生成的破坏力。4.2 知识条切分与重组只留下真正有用的片段CRAG里另一个很有实操价值的模块是“decompose-then-recompose”也就是把检索文档先拆碎、再重组。为什么要拆因为一篇文档的相关性并不均匀。可能文章整体围绕某个主题但只有某一小段真正回答了用户的问题。如果整篇塞进上下文无关段落会稀释模型注意力甚至引入矛盾信息。CRAG会把文档切分为更细的“知识条”Knowledge Strips再对每个知识条单独评估过滤掉不相关的部分最后把保留下来的知识条重新拼接成一份精炼的上下文。打个比方你找一本书准备写综述你不会把整本书复印给审稿人而是把关键章节摘出来标注好来源再合并成一篇文章。知识条切分做的是同一件事把文档里有价值的片段剥离出来噪音留在门外。我实际做检索增强时也遇到过类似情况。向量召回的第一段文本和问题高度相关但后面跟了一大段相似内容模型会把那部分相似却不相关的文字一并吸收进去回答变得更加啰嗦。有了知识条筛选这类问题会明显减轻。4.3 CRAG训练时的关键细节不对称损失CRAG的评估器训练有一个容易被忽略但很重要的细节它用了非对称的因子化损失factorized loss本质上是把三档分类拆成两个独立任务来优化而且对“错误文档被误判为正确”施加了更大的惩罚。道理很简单。在真实系统里把错误文档当正确的代价远比把正确文档当错误的代价高。后者顶多让系统多检索一次多花点时间前者却可能让模型基于错误信息一本正经地胡说用户一旦信了那就是安全事故。所以评估器的优化目标不只是整体分类准确率高还要尽可能避免“漏掉错误文档”。实际调参时往往需要牺牲一些Correct档位的召回率来换取Incorrect档位更高的精确率。具体阈值怎么设要结合业务场景对“事实错误”的容忍度来定。CRAG还有一个很好的特性它的组件可以独立部署。无论你用的是贪心检索、重排还是Agent式RAG都能在中间插入这个评估器作为纠偏开关。所以它和Adaptive RAG、Self-RAG并不是互斥关系反而经常被组合使用。5. 三篇论文的横向对比与选型建议5.1 从核心机制看清三者的本质差异把三篇论文放在一起看它们的差异其实非常清晰方案核心机制额外模块是否需要微调生成模型主要收益主要代价Adaptive RAG复杂度路由器决定走哪条检索分支轻量分类器不需要降低无效检索缩短简单问题响应时间分类器质量决定上限有分布偏移风险Self-RAG生成时自产反思Token自我评估反思Token与训练语料需要提升事实验证能力降低幻觉率微调成本高采样推理开销大CRAG评估器给检索结果判级分档纠偏轻量评估器不需要过滤坏文档增强系统鲁棒性评估器阈值需要细致调优这三者解决的不是同一个问题。Adaptive RAG解决的是“该不该检索以及检索几次”Self-RAG解决的是“回答有没有证据支撑”CRAG解决的是“检索回来的文档到底能不能信”。你可以把它们看作RAG流程中三个不同位置的阀门入口处路由、过程中反思、使用前质检。5.2 按业务场景选型到底该先上哪一套我个人的建议是不要一上来就纠结“哪篇论文更强”而是先看你的系统卡在哪一环。如果线上问题池简单复杂混合很多问题根本不需要检索但每次请求都白白触发了一大段检索流程那优先考虑Adaptive RAG。用一个分类器做前置路由收益见效最快改造成本也最小。如果检索结果经常不靠谱召回内容经常和用户问题跑题系统里又没有足够人力去精调检索链路那优先考虑CRAG。它的评估器能把大量坏文档拦在生成步骤之前相当于给RAG上了一层保险。如果业务对事实准确率要求极高模型经常一本正经地输出幻觉内容且团队有模型微调的基础那Self-RAG值得认真尝试。反思Token带来的自我约束比任何外部后处理都更贴近生成源头。还有一个常见认知误区要说清楚这三者不是三选一。实际工程里完全可以组合使用。用Adaptive RAG做整体路由用CRAG评估器把住检索质量关再用类似反思Token的思路在Prompt层面对答案做二次核查这样的流水线反而比单纯套用某一篇论文更完整。5.3 从成本和维护角度看长期影响选型不能只看效果还要算维护账。Adaptive RAG的核心资产是一个小分类器训练和更新只需要准备一批带标签的Query样本成本很低。CRAG的评估器略重一些因为要构造正负例和模糊例的训练数据但它一旦训好可以长期服务多条业务线。Self-RAG在这三者里维护成本最高反思Token的标注语料不好造模型迭代时评估效果也复杂但它带来的“模型自我约束”能力是另外两个方案很难代替的。这三篇论文对后来RAG发展的影响也远远超出了它们自身的实验指标。Adaptive RAG把“复杂度自适应”变成RAG设计的默认选项Self-RAG带火了“生成式评估器”和自我批评范式CRAG把“纠偏”变成一个独立组件后来的Agent式RAG里大量出现了类似“先评估后决策”的结构。理解了这三篇再去看后续层出不穷的RAG优化工作会发现很多新东西都是它们的变形或组合。6. 复现与落地实操经验6.1 复现时最容易踩的坑三篇论文我都在模拟项目中复现过印象最深的几个坑很值得写出来。Adaptive RAG的坑主要在数据标注环节。使用大模型给Query打策略标签时标签定义一定要写清楚“是否需要检索”的判定标准。否则同一个问题不同的标注者可能给出不同的标签。我习惯先把一组典型Query拿去人工抽检等标签一致性达到九成以上再批量运行。另外分类器的类别阈值不要直接沿用论文里的0.5最好在验证集上画一下精确率-召回率曲线找出适合业务容忍度的截断点。Self-RAG的坑集中在反思Token的构造。反思Token不能随便塞几个词到词表而是要让训练数据的格式足够统一什么情况下输出检索Token什么情况下输出相关度Token顺序都不能错。训练时如果混入了不带反思Token的普通问答数据模型很快就会忽略反思Token效果直接退化。我在实验里发现反思Token语料和普通语料的比例控制在7:3左右比较合适普通语料能保住模型的生成流畅性反思语料负责强化自评能力。CRAG的坑在评估器的数据平衡。三档分类里“Ambiguous”这档最不好收集模型也最容易在这档上飘。我后来用一种折中方案把Ambiguous档改成软区间处理不要求评估器硬输出三分类而是输出“置信度分数”再用两个阈值切出三档。这样可以在不同业务线上灵活调整不至于为了换一个业务场景重新训练模型。6.2 常见问题速查表现象可能原因排查方向路由分类器线上效果明显低于离线训练Query与线上Query分布不一致抽取线上日志样本做人工标注增量训练Self-RAG训练后反思Token不生效反思Token语料占比过低或顺序不统一提高反思语料比例统一Token顺序模板评估器把大量好文档误判为坏文档Incorrect档阈值设得太激进调整阈值观察精确率和召回率的权衡曲线CRAG纠偏后响应时间变长Ambiguous档触发了多次补充检索限制补充检索轮数或只在固定置信区间内触发组合方案链路复杂难维护路由、评估、反思各模块配置散落把决策配置集中到一个统一的策略配置文件里6.3 从论文到产品我建议的最小落地路径我的建议很明确如果团队资源有限不要一上来就三套方案全上。先做Adaptive RAG的路由改造因为它最轻量能让简单问题少走弯路线上体验几乎立竿见影。路由稳定之后如果发现检索质量还是经常拖后腿再挂一个CRAG风格的评估器专门拦截坏文档。等到业务规模和微调资源都跟上了再把Self-RAG的反思能力逐步引入。最后再分享一个小技巧。三篇论文本身都是英文场景的实验中文业务落地时除了评估器和路由器的迁移训练还要特别关注中文Query的表述特点。中文口语化问题严重同一个意图可能有好几种问法分类器或评估器很容易被新问法打懵。我一般会在真实业务数据里抽一批典型表述做对抗测试用这些样本来决定是否需要补充训练。RAG优化从来不是一次到位的事这三篇论文提供的价值更像是给了一套系统化的优化方向而不是某个可以直接抄的魔法配置。