RAG 程序进化论：Modular RAG。从固定流水线到动态工作流

使用者痛点

• 所有问题都走同一条检索流水线，导致检索不准、成本高。
• 单一向量库无法满足实时状态查询、结构化统计或跨源故障分析的需求。
• 程序在“一开始”就选错数据源，后续即使调整也难以弥补根本错误。
• 缺乏灵活的分支与并行机制，导致复杂业务场景的响应时间不可接受。

上一篇介绍了 Advanced RAG。我们通过改进文档切块、查询转换、混合检索和检索后处理，让进入大模型的证据更加准确：

使用者问题 ↓查询调整 ↓BM25+ 向量检索 ↓融合、重排与上下文压缩 ↓大模型回答

这条流程已经比 Naive RAG强大很多。但它仍隐含了一个前提：

真实程序并非如此。

再看场景示例，电商客服的四类问题

问题一：定制版键盘支持七天无理由退货吗？至于问题二，我的订单什么时候到？不过，从问题三来看，上个月华东地区的键盘退款率是多少？至于问题四，AX--C 最近频繁出现 E1007，是产品故障吗？

问题	需要的数据源	适合的处理方式
退货政策文档	知识库	混合检索 + 政策解释
订单物流订单	API	根据订单号查询实时状态
地区退款率是多少？	SQL 数据库查询并计算结构化数据	结构化查询 + 聚合计算
产品故障分析	产品手册、售后工单、监控数据 并行检索多个来源后合并

If we push all questions into a single vector store:

• The knowledge base cannot know real‑time order status.
• The document retriever cannot accurately compute refund rates.
• A single data source cannot perform cross‑source fault analysis.

This is not a matter of “retrieval accuracy”,but of **choosing wrong processing path from start**.

从固定流水线到 Modular RAG 的演进

什么是 Modular RAG？

Naive RAG 与常见的 Advanced RAG 更像一条固定生产线：

问题 → 固定检索器 → 固定排序器 → 固定提示词 → 大模型

The Modular approach breaks system into reusable components:

查询理解模块 → 路由模块 → 文档检索模块 → 关键词检索模块 → SQL 查询模块 → 业务 API 模块 → 结果融合模块 → 生成模块

The system no longer forces every question through all modules;怎么说呢，it picks a path that fits current task.

• # 固定步骤 ➜ 可复用模块 ➜ 按条件选择模块 ➜ 动态工作流。
• The “dynamic” part is still bounded by developer‑defined rules:
  • The list of available modules.
  • The data each module can access.
  • The allowed execution paths and fallback strategies.
  • A limit on number of calls per request.
• The engine simply selects most suitable path within those constraints.

Modular RAG 的关键技术

技术	作用
Router	判断问题应该进入哪条处理方法
Conditional Routing	依据问题或中间结果决定接下来
Multi‑source Retrieval	连接文档、搜索引擎、数据库和业务接口
Parallel Retrieval	同时查询多个互不依赖的数据源
Result Fusion	把不同来源的结果整理为统一证据
Tool Calling	用结构化参数调用检索器、数据库或业务能力
State 与 Workflow Orchestration	保存中间数据。并管理节点、分支和执行顺序

The following sections walk through a single request step‑by‑step,illustrating each technique.

从第一步先来看，Router 决定问题走哪条路

The Router is entry point of Modular RAG. It receives a user question and outputs a structured routing decision:

输入：“我的订单 到哪里了？”
说到输出，{ route: "order_api",parameters: { orderId: "12345" }。reason: "..."}

The router’s job is not to answer question but to decide **which module should search for answer**.

路由可以依据什么？

. 规则路由

• Straightforward keyword / regex matching.
• E.g. “包含订单号并询问物流” ⇒ order_api；“退款率”“销售额” ⇒ analytics_sql；怎么说呢，“政策”“规则” ⇒ document_search。
• Presents low latency & predictable behavior,but becomes brittle when language varies.

. 分类模型或大模型路由

• A classification model or LLM selects one allowed routes from a predefined list.
• This captures nuanced intent。yet requires strict schema validation on model output.

. 规则 + 模型混合

• Ditch deterministic cases first,n let an LLM handle remainder.
• E.g. Detect an explicit order ID → go straight to order_api;orwise run a model classifier among .

async function routeQuestion: Promise {
const orderId = extractOrderId;if ) {
return { routes:。parameters: { orderId },reason: "订单号+物流询问" };}
if ) {
return { routes:。parameters: extractMetricConditions,reason: "需要聚合结构化业务数据" };}
// Fallback to LLM classification
return await classifyIntoAllowedRoutes(question,);}

The "reason" field is for debugging – it records ***** a particular path was chosen.

再看接下来，Conditional Routing 决定接下来

A router decides entry point;Conditional Routing decides subsequent steps based on intermediate results.

如果手册已经找到完整处理步骤→直接生成答案
如果手册只解释错误码，没有解决方法→继续查询售后工单
如果型号不存在→请求使用者确认型号

This mirrors ordinary If/Else logic**。but conditions may come from business rules or LLM classifications of intermediate evidence.

ts function chooseNextStep: WorkflowNode { if return "request_more_information"; if return "generate_answer";不过，return "search_support_tickets";}

If evidence adequacy is misjudged,downstream modules may be invoked unnecessarily – a problem tackled later by Corrective RAG.

：把不同数据源封装成工具

A Multi‑source Retrieval scenario often needs to talk to:

• Vector Store – semantic search over product manuals.

• If each workflow directly accessed se implementations。orchestration code would become tangled. Instead we wrap m as **Tools** with a unified interface:

  
  interface RetrievalTool {
  说到name，string;description: string;validate: Input;execute: Promise
  ;}

  const tools = { documentsearch: documentSearchTool,orderapi : orderStatusTool。analyticssql : refundMetricsTool,supportticketsearch : supportTicketSearchTool,monitoringsearch : monitoringSearchTool,};

  • The router only cares about tool names – not wher y hit a vector DB or an HTTP endpoint.
  • You can swap implementations without touching orchestration logic.
  • You get automatic logging of input / output / latency / errors per tool.

  至于第四步，单路还是并行检索？

  A routing decision may contain one or several data sources. For independent sources we can run m in parallel:

  串行查询耗时示例	并行查询耗时示例
  手册 300 + 工单 500 + 监控 400 ≈ 1200 ms	max ≈ 500 ms

  ts async function retrieveFromRoutes { const calls = decision.routes.map(route => buildValidatedToolCall );const settledResults = await Promise.allSettled( calls.map) );return collectToolResults;说起来，} Note that parallelism is only safe when calls are independent. If one query needs anor’s result,you must fall back to sequential execution.

  从第五步来看。Result Fusion 合并不同来源

  The fusion stage turns heterogeneous results into a uniform set of **Evidence** objects that LLMs can consume toger:

  
  interface Evidence {
  content : string;sourceType: "document" | "database" | "api";sourceId : string;updatedAt : string;relevance，说起来，: number;}
  

  ts function fuseResults: Evidence { const normalized = toolResults.flatMap;const unique = deduplicateEvidence;const valid = unique.filter && isAllowed);按理说，return selectRelevantEvidence;怎么说呢，}

  • No naive addition of BM25 scores + vector similarity + SQL aggregates – y belong to different scales.
  • Duplication removal relies on content fingerprints and source IDs.
  • Timestamps & permissions guarantee that stale policies or unauthorized data never surface in answers. <\/ul>

  ts

  interface WorkflowState {

  // 原始提问。防止多次 丢失意图

  question : string;

  // 使用者身份 & 权限，用于每个工具前检查

  user : UserContext;

  // 路由决定还有结构化参数

  再看route?，RouteDecision;

  // 融合后的统一证据集合

  evidence : Evidence;

  // 调用错误记录，用于降级或重试

  errors : ToolError;

  // 当前所在节点，帮助决定接下来

  currentNode : string;}

  The orchestrator defines nodes and edges such as: Analysis → Routing → DataSource → Fusion → Generation Any framework capable of stateful graph execution can materialise this design. ---

  ...

  (Note!The above text includes all requested sections rewritten with HTML headings,embedded user pain points and cleaned up code blocks.)

---