现代RAG架构有哪些改进?

这道题问的是现代[[RAG]]到底比传统流水线强在哪，本质是看检索和生成的关系从单向变成双向互动了。传统做法是检索完把结果拼进prompt，生成器就直接用了，三个模块各自优化，检的只管检，写的只管写。但现代RAG会把检索嵌进生成过程里，让生成器反过来指导检索，比如生成到一半发现缺信息，再主动去查一次。这不是简单拼接，而是有更深层的融合。

具体说一下，传统RAG适合那些问题比较固定、知识库也不太变动的场景，比如内部知识库问答，查什么文档基本一眼就能判断。但真实业务里，问题复杂度差别很大，比如电商客服，用户问“退款流程”可能直接生成就行，但问“用了满减券又用了积分，退款怎么算”就得检索详细规则。所以现代RAG引入了自适应路由，让模型自己判断要不要检、检几次。

这里我重点讲几个机制。第一个是迭代式检索，生成过程中发现知识缺口就触发补充检索，比如Self-Ask，模型会主动说“我需要查一下某某规则”。第二个是自适应路由，根据问题难度选策略：简单的直接生成，中等难度的单轮检索，复杂的甚至多轮迭代。像[[Self-RAG]]会输出反思token，比如“是否需要检索”“结果是否相关”“是否足够支持生成”，模型自己评估要不要再查一次。

拿客服退款举个例子。用户问“我昨天买了东西今天降价了能退差价吗”，传统做法是直接把所有退货政策文档塞进prompt，可能信息很多但没切中要点。现代RAG会先尝试生成，如果模型不确定，就触发检索，找到“价保政策”那条记录，再生成回答；如果检索结果不够置信，比如文档里没明确说，模型可以降级处理，比如建议用户联系人工。这样既快又准。

但落地时有个关键前提：检索质量得稳定。如果检索器召回一堆不相关文档，那迭代反而放大错误。我特别关注的是，上线前要压测检索的Recall和Precision，同时控制迭代轮次，一般两轮就够，多了延迟和成本受不了。常见失败场景是迭代检索陷入死循环，模型反复说“还需要查”，这时候得设最大轮次，超时就用默认策略。

所以我会把现代RAG看成一种动态决策系统，而不是简单的检索+生成。我更倾向的做法是先用[[Corrective RAG]]做置信度评估，低置信时触发工具扩展或生成降级，同时保留传统流程兜底。

另外有个点值得注意，就是这些反思token是怎么训练出来的？像Self-RAG是用了[[SFT]]来教模型输出这些控制信号，但训练数据构造本身就很讲究，比如负样本怎么采样，直接关系到模型会不会过度依赖检索。