现代 RAG 架构怎么变?

这道题其实问的是[[RAG]]从早期简单拼接到现在深度融合的演进，本质是看我们怎么理解检索和生成之间的关系。早期做法就是典型的流水线，检索器用[[BM25]]或者[[TF-IDF]]这种[[稀疏检索]]，把文档拿回来，直接拼到prompt里扔给LLM。生成器是固定的，完全不参与检索过程。但现代RAG系统，比如Facebook 2020年那篇RAG论文，已经开始把检索器和生成器一起训练了。

具体区别我分几个点讲。先说架构。传统的是两个独立系统串联，检索器是稀疏检索，生成器是LLM，中间就是个字符串拼接。现代的做法，检索器换成了[[稠密检索]]，比如DPR、Contriever这种[[双塔]]模型，生成器也会做适配。更关键的是连接方式变了，不再是简单的文本拼接，而是向量层面的交互。比如Fusion-in-Decoder，它把检索回来的文档分别编码，然后在decoder的每一层通过cross-attention把信息融合进去，不是只在开头拼一下。

再一个就是信息融合的位置。早期只在输入层融合，受限于上下文长度，文档一多关键信息就被淹没了。现代RASG系统把融合点挪到了中间层，甚至输出层。像[[Self-RAG]]，它让模型自己判断什么时候需要检索、用多少检索结果，相当于把检索决策内化到生成过程里。

端到端训练这块是个难点。传统RAG没有梯度流动，检索器和生成器各自固定。现代系统要联合优化，但检索是离散操作，不可微。解法有好几种，比如用Gumbel-Softmax做近似，或者用强化学习里的REINFORCE，再或者像REALM那样预训练整个系统。

我举个实际业务场景吧。比如电商客服的退款问题。用户问“为什么我的退款还没到账”，传统RAG的做法是检索退款相关的FAQ，拼到prompt里，让LLM回答。但实际落地会发现，如果检索出来的文档里有“7-15个工作日”这种通用规则，而用户的订单其实已经触发异常需要人工介入，传统方法就回答不准。现代RAG系统会怎么做？它可能先用一个检索器召回订单详情和退款状态，然后生成器通过cross-attention把这些结构化信息融合进去，甚至主动判断需要再查一下物流状态，做一次多跳推理。

但这里有个前提，就是检索质量要够高。如果底库里的文档质量参差不齐，或者召回率不够，那融合得再好也没用。我上线时特别关注的是检索的召回率和精确率的平衡，一旦检索结果里混进太多噪声，生成器会跟着跑偏。

所以我的判断是，传统RAG适合知识库稳定、查询简单的场景，比如企业内部SOP问答；现代RAG更适合那些需要动态推理、信息源多的场景，比如客服、金融分析。真正落地时，我倾向把两者结合起来，比如用[[混合检索]]，关键词召回保底，向量召回提高精度，再用一个[[重排]]模型把结果精排一下。

不过说到联合训练，我其实更关心一个细节：检索器更新的频率。如果知识库每天都在变，检索器的编码器要不要跟着微调？如果不调，新文档的向量和旧文档的向量可能不在一个空间里；如果调，又可能破坏已有文档的表示。这块目前还没有特别成熟的方案，我觉得是个值得深挖的方向。