RAG 演进 03-ModularRAG

发表于 2025-01-23 更新于 2025-02-02 分类于 2-深度学习， LLM开发工程师指南， RAG 阅读次数：本文字数： 4.2k 阅读时长 ≈ 4 分钟

随着 RAG 领域发展和更多工程上的应用，RAG 框架需要更多加多样化和灵活，因此需要抽象为 ModularRAG

Modular RAG 是具有⾼度扩展的范式，它将 RAG 系统拆分为 Molule Type (Indexing) - Module (Chunk/Structrural)-Operator (…) 的三层结构

![[认识 ModularRAG-20250123114804.png]]

有了以上这些 Operator，既可以组合出不同的 RAG 应用，常用的有以下：

1. Sequential

线性的结构的 RAG Flow，模块线性的组织成流⽔线，如果拥有 Pre-Retrieval 和 Post-Retrieval 两个 Module Type，则是典型的 Advanced RAG 范式，如果去掉则是典型的 Naive RAG 范式。

![[NextRAG-20250115222238.png]]

Sequential 是⽬前使⽤最多的 RAG Pipeline，其中在最常使⽤的搭配如下，在检索前增加 Query Rewrite，在检索后增加 Rerank 的算⼦。例如 QAnything。

![[NextRAG-20250115222238-1.png]]

Rewrite-Retrieve-Read (RRR) 也是典型的序列结构。其中 jQuery Rewrite 模块是⼀个⼩型的可训练的语⾔模型，并通过最终 LLM 的输出结果作为奖励。在强化学习的背景下，重写器优化被形式化为⼀个⻢尔科夫决策过程。检索器选⽤了稀疏编码器 BM25。

![[NextRAG-20250115222239.png]]

2. Conditional

条件结构的 RAG Flow，根据不同的条件选择不同的 RAG 路线。通常由⼀个 Routing 模块进⾏路由，判断依据包括通常包括 Query 的关键词或语义。路由到不同的路线，通常根据问题的类型，适⽤的场景路由到不同的 Flow 中。例如当⽤户提问到严肃的问题，政治问题或是娱乐问题，对⼤模型幻觉的容忍度是不同的。不同路由分⽀通常在检索源、检索流程、配置信息、模型选择和 Prompt 上进⾏差异化。

![[NextRAG-20250115222240.png]]

⼀个 Conditional RAG 的经典 Implementation 是 semantic Router。

3. Branching

分⽀结构的 RAG Flow。不同于 Conditional 中是要在多条分⽀中选择⼀条，Branching 则是有多个分⽀并⾏。从结构上可以分成两类：

检索前分⽀ (Multi-Query, Parallel Retrieval)。对原始 Query 进⾏扩展，得到多个⼦ Query，然后对每⼀个⼦ Query 分别进⾏检索，检索后就可以选择⽴即根据⼦问题和对应检索来的内容⽣成答案，也可以只使⽤拓展检索出来的内容最后合并到统⼀上下⽂中进⾏⽣成。
检索后分⽀ (Single Query, Parallel Generation)。保持原来的 Query，检索到多个⽂档块后，并⾏使⽤原始 Query 和每⼀个⽂档块进⾏⽣成，最后将⽣成的结果合并到⼀起。

![[NextRAG-20250115222240-1.png]]

REPLUG 就是⼀个典型的检索后分⽀的分结构，根据每⼀个分⽀预测 token 的概率，通过 Weighted possibilityEnsemble 将不同的分⽀聚合，并通过最后⽣成结果作作为反馈微调检索器 Contriever。

![[NextRAG-20250115222241.png]]

4. Loop

具有环状结构的 RAG Flow，这也是的 Modular RAG 的⼀个重要特点，检索和推理步骤相互影响的。通常包括⼀个 Judge 模块，⽤于控制流程。具体⼜可以分成迭代、递归和主动检索三种。

![[NextRAG-20250115222242.png]]

5. Iterative Retrieval

有时候单次检索和⽣成的并不能很好的解决⼀些需要⼤量知识的复杂的问题。因此可以使⽤迭代的⽅式进⾏ RAG, 通常来说迭代检索都有⼀个固定的迭代次数。迭代检索⼀个典型的案例是是 ITER-RETGEN。

在每次迭代中，ITER-RETGEN 利⽤前⼀次迭代的模型输出作为特定上下⽂，帮助检索更相关的知识，这可能有助于改进模型⽣成。循序的终⽌通过预设的迭代次数来判断。

![[NextRAG-20250115222243.png]]

6. Recursive Retrieval

不同于迭代检索，递归检索的特点是有明显依赖上⼀步并不断深⼊的检索。通常有判断机制作为递归检索的出口。在 RAG 系统中，递归检索的通常要搭配 Query Transformation，每次检索时依赖于新改写后的 Query。

⼀个典型的递归检索实现例如 ToC。从初始问题 (Ambiguous Question,AQ) , 通过递归执⾏ RAC（递归澄清⽅法，Retrieval-Augmented Clarification）逐步插⼊⼦节点到澄清树中，在每个扩展步骤中，根据当前查询重新对段落进⾏重新排名并⽣成⼀个 (Disambiguous Question,DQ)。树的探索在达到了最⼤数量的有效节点或最⼤深度时结束。构建了澄清树后，TOC 收集所有有效节点并⽣成⼀个全⾯的⻓⽂本答案来回答 AQ。

![[NextRAG-20250115222244.png]]

7. Adaptive (Active) Retrieval

随着 RAG 的发展，逐步超越被动的检索的⽅式，出现了⾃适应的检索（也被称作主动检索），这⼀⽅⾯也是受益于 LLM 的强⼤能⼒。在核⼼思想上与 LLM Agent 相似。

RAG 系统可以主动判断的检索时机，以及判断时候结束整个流程，输出最终的结果。根据判断的依据，⼜可以分成和 Prompt-base 和 Tuning-base。

**Prompt-base.** 通过 Prompt Engineering 的⽅式让 LLM 对流程进⾏控制。⼀个典型的实现案例是 FLARE。它的核⼼思想是 LM 应该仅在缺乏所需知识时进⾏检索，以避免被动检索增强的 LM 中出现不必要或不适当的检索。FLARE 迭代地⽣成下⼀个临时句⼦，并检查是否包含低概率标记。如果是这样，系统将检索相关⽂档并重新⽣成句⼦。

![[NextRAG-20250115222244-1.png]]

Tuning-base. 对 LLM 进⾏微调使其⽣成特殊的 token，以此来触发检索或⽣成。这种思想可以追溯到 Toolformer 中，通过⽣成特俗的内容，来辅助调⽤⼯具。在 RAG 系统中则是⽤于控制检索和⽣成两个步骤。⼀个典型的案例是 Self-RAG。具体⽽⾔，

（1）给定⼀个输⼊提示，和前⾯的⽣成结果，⾸先预测特殊 token “Retrieve" 判断是否通过检索段落对继续的⽣成进⾏增强是有帮助。
（2）如果有帮助，调⽤检索模型。模型会⽣成⼀个 critique token 来评估检索段的相关性，下⼀个响应⽚段，和⼀个批判令牌来评估响应⽚段中的信息是否得到了检索段的⽀持。
（3）最后，⼀个新的批判令牌评估响应的整体效⽤。模型会并⾏处理这些内容，并选择最佳结果作为最终的输出。

![[NextRAG-20250115222245.png]]

最佳行业案例

OpenAI

从 OpenAI Demo day 的演讲整理所得，并不能完全代表 OpenAI 的实际操作。在提升 RAG 的成功案例中，OpenAI 团队从 45% 的准确率开始，尝试了多种⽅法并标记哪些⽅法最终被采⽤到⽣产中。他们尝试了假设性⽂档嵌⼊（HyDE）和精调嵌⼊等⽅法，但效果并不理想。通过尝试不同⼤⼩块的信息和嵌⼊不同的内容部分，他们将准确率提升到 65%。通过 Reranking 和对不同类别问题特别处理的⽅法，他们进⼀步提升到 85% 的准确率。最终，通过提示⼯程、查询扩展和其他⽅法的结合，他们达到了 98% 的准确率。团队强调了模型精调和 RAG 结合使⽤时的强⼤潜⼒，尤其是在没有使⽤复杂技术的情况下，仅通过简单的模型精调和提示⼯程就接近了⾏业领先⽔平。

![[NextRAG-20250115222248.png]]

Baichuan

基于百川的宣传资料整理（查看原⽂)。针对⽤户⽇益复杂的问题，百川借鉴了 Meta 的 CoVe 技术，将复杂 Prompt 拆分为多个独⽴且可并⾏检索的搜索友好型查询。利⽤⾃研的 TS（Think-Step Further) 技术来推断和挖掘⽤户输⼊背后更深层的问题，以更精准、全⾯地理解⽤户意图。在检索步骤中，百川智能⾃研了 Baichuan-TextEmbedding 向量模型。同时引⼊稀疏检索和 rerank 模型（未披露），形成向量检索与稀疏检索并⾏的混合检索⽅式，⼤幅提升了⽬标⽂档的召回率。此外还引⼊了 self-Critique 让⼤模型基于 Prompt、从相关性和可⽤性等⻆度对检索回来的内容⾃省，进⾏⼆次查看，从中筛选出与 Prompt 最匹配、最优质的候选内容。

![[NextRAG-20250115222249.png]]

DatDatabricks

作为⼤数据领域中领先的服务商，在 RAG 设计上依然保持了⾃⼰特点和优势（查看原⽂）。⽤户输⼊问题，通过从事先处理好的⽂本向量索引⾥⾯获取问题相关信息，加上提示词⼯程，⽣成回答。上半部分 Unstructured Data pipeline 就输主流的 RAG ⽅法，并没有特殊之处。

![[NextRAG-20250115222249-1.png]]

下半部分为 Structured Data Pipeline，是 Databricks 特征⼯程处理流程，也是 Databricks RAG 最⼤的特点。Databricks 从⾃身专业的⼤数据⻆度出发，从原来的准确度较⾼的数据存储中进⾏额外的检索，充分发挥⾃身在 Real Time Data Serving 上的优势。可以看到 Databricks 在 GenAI 时代的策略是助具有⼴泛市场需求的 RAG 应⽤，将⾃身强⼤的 Lakehouse 数据处理能与⽣成式 AI 技术深度融合，构建出⼀体化解决⽅案。abricks

参考：