RAG 架构选型决策树
Naive / Advanced / Agentic / Graph 四代形态不是升级关系，是坐标系上的四个位置。决策从数据形态出发：结构化程度、更新频率、问题是否多跳、成本与延迟预算；演进路径不要一步到位 —— 先 Naive 跑通评测集，被 badcase 逼着才升级。
也叫：架构选型 · 决策树 · Naive RAG · Advanced RAG · 演进路径
四代形态的坐标系出自 T2-10
先把 T2-1 提过的坐标系补全，这是所有选型讨论的底图：
| 形态 | 组成 | 索引成本 | 查询成本 | 适用 |
|---|---|---|---|---|
| Naive RAG | 固定切分 + 向量检索 + 生成 | 低 | 低 | 小型 FAQ、原型验证 |
| Advanced RAG | 语义/结构分块 + 混合检索 + Rerank + 查询改写 | 中 | 中 | 生产默认基线 |
| Agentic RAG | Advanced + Agent 决策循环 + 多数据源 | 中 | 高（数倍） | 多步推理、多源对比 |
| GraphRAG | 实体关系抽取 + 图索引（+社区摘要） | 高（5–10 倍） | 中高 | 实体密集、跨文档推理 |
| Multimodal RAG | 图像/版面直接建索引 | 中高 | 中高 | 图表、图纸、扫描件为主 |
一句话记住主线：Advanced RAG 作基座 + Agentic 作调度层 + Graph/SQL/Web 作可选数据源。
一条主线：Advanced RAG 作基座，Agentic 作调度层，Graph/SQL/Web 作数据源
四代形态的坐标系
| 形态 | 组成 | 成本与适用 |
|---|---|---|
| Naive RAG | 固定切分 + 向量检索 + 生成 | 索引低 / 查询低；小型 FAQ、原型验证 |
| Advanced RAG | 语义或结构分块 + 混合检索 + Rerank + 查询改写 | 索引中 / 查询中；生产默认基线 |
| Agentic RAG | Advanced + Agent 决策循环 + 多数据源 | 索引中 / 查询高（数倍）；多步推理、多源对比 |
| GraphRAG | 实体关系抽取 + 图索引（+社区摘要） | 索引高（5–10 倍） / 查询中高；实体密集、跨文档推理 |
| Multimodal RAG | 图像/版面直接建索引 | 索引中高 / 查询中高；图表、图纸、扫描件为主 |
场景速查：先给起点，再讲取舍
- 企业制度问答
- Advanced RAG；结构分块（按标题）+ 权限元数据
- 设备手册问答
- Advanced RAG；BM25 权重要高（型号编号多）、表格特殊处理
- 合同审查
- Advanced + Graph；跨合同实体关联、条款比对
- 客服机器人
- Advanced RAG + 阈值兜底；「不知道就说不知道」是硬指标
- 代码库问答
- Advanced RAG；按 AST 切分、符号名走 BM25
- 数据分析 / 研报竞品
- Agentic + NL2SQL，路由与执行结果校验；研报再加 Graph + Web，要多源和时效
选型讨论几乎都从 Advanced RAG 起步；真正被追问的从来不是它，而是你往上叠了什么、这一叠付出多少索引与查询成本。
以上节选自T2-10 2026 RAG 架构选型决策树，读全文能看到前后语境。
决策树：从数据形态出发出自 T2-10
数据长什么样 → 问题是哪一类 → 有什么约束，第三步最能体现工程判断
第一步 · 数据长什么样
短文本 FAQ < 500 条Naive RAG，一天上线
长文档 > 1000 页Advanced RAG 作基座
多源混合 / 图表扫描件Agentic 路由 / 多模态
第二步 · 问题类型是什么
单跳事实问答选定的基座就够
多跳推理 / 多文档对比叠加 Agentic 调度层
全局归纳 / 要实时社区摘要 / 加 Web 工具
第三步 · 约束条件
延迟要求 < 1s砍改写与多路扩展
成本敏感分类器路由代替循环
要溯源 / 更新频繁元数据前置；选增量方案
长文档那一支还要再分一次：实体关系简单 → Advanced RAG（语义或结构分块 + 混合检索 + Rerank）；实体关系复杂（法务 / 医疗 / 金融 / 供应链）→ Advanced 作基座再加 GraphRAG，预算紧则 LightRAG。
约束里最硬的两条：数据不能出内网就全开源自托管（BGE-M3 + Qdrant/Milvus + bge-reranker）；要引用溯源或权限隔离，元数据设计必须前置，chunk 得带来源与权限标签。
不澄清就报架构是最大的扣分项。这三步同时也是澄清清单 —— 真实工作里没人不问数据规模、问题类型和延迟预算，就直接开出方案。
第一步：你的数据长什么样？
├── 短文本 FAQ（< 500 条）
│ → Naive RAG + 轻量向量库（Chroma/pgvector），一天上线
│
├── 长文档知识库（手册/规范/合同，> 1000 页）
│ ├── 实体关系简单 → Advanced RAG
│ │ 语义或结构分块 + 混合检索(BM25+向量+RRF) + Rerank
│ └── 实体关系复杂（法务/医疗/金融/供应链）
│ → Advanced RAG 基座 + GraphRAG（预算紧则 LightRAG）
│
├── 图表、图纸、扫描件为主 → Multimodal RAG
│
└── 多数据源混合（文档 + 数据库 + 实时 API）
→ Agentic RAG（Router + 多 Retriever）
第二步：你的问题类型是什么？
├── 单跳事实问答 → 上面选定的基座就够
├── 多跳推理 / 多文档对比 → 叠加 Agentic 调度层
├── 全局归纳（"整体趋势如何"） → 需要 GraphRAG 社区摘要或预生成摘要
└── 需要实时信息 → Agentic + Web 搜索工具
第三步：约束条件是什么？（这一步最能体现工程判断）
├── 延迟要求 < 1s → 砍掉查询改写/多路扩展，Rerank 用轻量模型
├── 成本敏感 → 别上 Agentic 循环，用分类器做轻量路由代替
├── 数据不能出内网 → 全开源自托管（BGE-M3 + Qdrant/Milvus + bge-reranker）
├── 需要引用溯源/权限隔离 → 元数据设计前置，chunk 必须带来源与权限标签
└── 知识库更新频繁 → 优先支持增量更新的方案（避开重建代价高的完整 GraphRAG）以上节选自T2-10 2026 RAG 架构选型决策树，读全文能看到前后语境。