面经策

什么是 Modular RAG？ ​

  • 标签：AI、大模型、RAG

🏛 业务架构师 ​

Modular RAG 把 RAG 从固定流水线重构为一组可编排的模块：检索器、生成器、记忆、路由、评估等都是标准组件，按业务需求灵活组合成流水线——可以"检索两次再生成"，可以"先路由到不同知识库"，甚至可以"检索结果不满意自动重写 query 再来一轮"（Self-RAG、CRAG 等模式）。

业务价值在两点：

  • 场景适配：不同业务线的需求差异很大——客服要低延迟，法务要高准确、可溯源，研报场景要多源比对。模块化让同一套基础设施支撑不同"配方"，避免每个场景重复造轮子。
  • 演进能力：RAG 技术迭代极快，2026 年的"最佳实践"半年就过时。模块化架构下，把 Rerank 模型从 A 换成 B、把检索策略从单路改混合，是换插件而不是重构系统。

我的判断：Modular RAG 与其说是技术，不如说是架构态度——当你的 RAG 要服务多个业务场景、团队超过一个 squads 时，模块化的投入才划算；如果只是一个部门的知识库问答，老老实实 Advanced RAG 流水线就够，别为了架构优雅付复杂度税。

🏗 系统架构师 ​

Modular RAG 是把 RAG 拆成可编排、可复用、可替换的组件集合的架构范式：检索模块、记忆模块、路由模块、生成模块、评估模块各自独立，通过类似数据流 DAG 的编排组合，支持循环、分支、递归，而不是固定线性流水线。

和 Naive / Advanced 的递进关系：Naive 是固定三段流水线；Advanced 还是流水线只是每段增强；Modular 则承认"不同 query 需要不同路径"——事实型问题走检索，闲聊不走，复杂研究问题走"检索→生成→再检索"的迭代循环（如 Self-RAG、CRAG 都是典型模块化模式）。

架构师视角的价值：

  • 路由即架构：入口 Router 按意图分发到不同流水线，这是 RAG 版的 API Gateway + 微服务拆分思想；
  • 组件可替换：换 Embedding、换向量库、加 Rerank 都是局部改动，符合开闭原则；
  • 复杂场景的表达力：多跳问答（Q2 依赖 Q1 的答案再检索）、多知识库联邦检索都需要 DAG 编排，线性流水线表达不了。

代价：组件间契约要定义清楚（接口 + 数据 schema），编排层（LangGraph / 自研 DAG）成为新的复杂度来源和故障点。我的建议：超过 3 种 query 形态、或需要迭代检索时才上 Modular，否则 Advanced RAG 更划算。

💻 全栈开发专家 ​

Modular RAG 是把 RAG 从「固定流水线」重构为**可插拔模块的编排系统」：检索、记忆、路由、融合、重排、生成都是独立模块，按需组合成流程，甚至允许循环（检索→生成→发现不够→再检索）和分支（部分 query 不检索直接回答）。

对比着理解三代：

  • Naive RAG：固定管道「索引→检索→生成」；
  • Advanced RAG：还是固定管道，前后加优化点；
  • Modular RAG：管道本身可编程，像搭积木。

工程价值（我真实用过的场景）：

  1. 多数据源路由：query 先过 Router 模块，产品手册走向量库、工单历史走 ES、参数表走 SQL，各走各的 Retriever 再 Fusion 融合；
  2. Self-RAG/CRAG 式自适应：生成模块输出「检索质量不足」信号 → 触发再检索或换源，形成反馈环；
  3. 复用：模块注册为 Spring Bean 或 LangGraph 节点，新业务拼装已有模块一周上线。
java
// 伪代码：模块编排
Flow flow = router(intentClassifier).then(queryRewriter)
    .branch(mapOf("kb" to ragRetriever, "sql" to text2Sql))
    .then(fusion, reranker, generator.withCitation());

一句话：Naive 起步、Advanced 优化、Modular 是业务复杂到多源多链路后的必然形态。