这篇学完你能回答什么
- 「给你一个新场景，你怎么决定用 Naive / Advanced / Agentic / Graph 哪种架构？」
- 「你们的 RAG 是怎么一步步演进的？」——简历深挖必问。
- 这是模块 2 的收官篇，把前九篇的技术点收拢成一套可当场画出来的决策框架。
为什么这题重要
前面九篇讲的是「每个零件怎么用」，这一篇讲「怎么组装」。面试到了二三面，考的不再是单点知识，而是：给你一个陌生场景，你能不能在十分钟内给出一个合理且分得清取舍的方案。
这类题没有标准答案，但有标准的回答结构。掌握结构比记住结论重要。
四代形态的坐标系
先把 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 起步；真正被追问的从来不是它，而是你往上叠了什么、这一叠付出多少索引与查询成本。
决策树：从数据形态出发
数据长什么样 → 问题是哪一类 → 有什么约束，第三步最能体现工程判断
第一步 · 数据长什么样
短文本 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）演进路径：不要一步到位
真实项目几乎都是长出来的，不是设计出来的。这条路径本身就是很好的面试叙事：
第 1 周 Naive RAG 跑通链路，拿到第一批真实 badcase
第 2–3 周 建评测集（100–200 条，分桶）← 分水岭，很多团队卡在这
第 4 周+ 按 badcase 归因逐项升级：
召回漏 → 混合检索
排序偏 → Rerank
分块碎 → 语义/结构/父子分块
多轮变差 → 查询改写
跨文档答不了 → GraphRAG
需要多步 → Agentic 循环核心纪律：每次只加一个组件，跑一次全量回归，确认收益再留下。一次性堆满全家桶的系统，出问题时你根本不知道该拆哪个。
真实项目几乎都是长出来的：先跑通拿 badcase，再建评测集，然后逐项升级
第 1 周
Naive RAG 跑通链路，拿到第一批 badcase
第 2–3 周断点
建 100–200 条分桶评测集，很多团队卡在这
第 4 周起
按 badcase 归因逐项升级：召回漏 → 混合检索
每次只加一个
跑一次全量回归，确认收益再留下
逐项加组件一次只加一个收益归得清，坏了知道拆哪个
一次性堆满全家桶看起来很完整出问题根本不知道该拆哪个
重型管线首字延迟改写 + 三路扩展 + rerank + Agentic 两轮很容易到 3–5 秒
两笔最大的开销Agentic 循环 / GraphRAG 索引成本数倍 / 索引 5–10 倍
混合检索几乎免费，Rerank 几十~几百毫秒，改写与 HyDE 各一次 LLM 调用 —— 单项都不贵，叠满才贵。对话式产品必须分级：高频简单 query 走轻管线。
成本与延迟预算（容易被追问）
各组件的大致代价，心里要有本账：
| 组件 | 延迟增量 | 成本增量 |
|---|---|---|
| 混合检索（BM25 + 向量） | 几十 ms | 几乎为零 |
| Rerank（top 50） | 几十~几百 ms | 小（自托管）/ 中（API） |
| 查询改写 | 一次 LLM 调用 | 小模型可控 |
| 多路扩展（3 路） | 检索 ×3 | 检索成本 ×3 |
| HyDE | 一次 LLM 调用 | 中 |
| Agentic 循环 | 秒级，随轮次线性增长 | 数倍 |
| GraphRAG 索引 | 离线 | 5–10 倍索引成本 |
一个「改写 + 三路扩展 + rerank + Agentic 两轮」的重型管线，首字延迟很容易到 3–5 秒。对话式产品必须做分级：高频简单 query 走轻管线，复杂 query 才走重管线。
场景速查表
面试常见场景的推荐起点（答题时先给起点，再讲取舍）：
| 场景 | 推荐架构 | 关键点 |
|---|---|---|
| 企业制度问答 | Advanced RAG | 结构分块（按标题）+ 权限元数据 |
| 设备手册问答 | Advanced RAG | BM25 权重要高（型号编号多）、表格特殊处理 |
| 合同审查 | Advanced + Graph | 跨合同实体关联、条款比对 |
| 客服机器人 | Advanced RAG + 阈值兜底 | 「不知道就说不知道」是硬指标 |
| 代码库问答 | Advanced RAG | 按 AST 切分、符号名走 BM25 |
| 数据分析问答 | Agentic + NL2SQL | 路由 + 执行结果校验 |
| 研报/竞品分析 | Agentic + Graph + Web | 多源、多跳、需要时效 |
面试视角
澄清需求 → 给基线 → 按需加挂 → 谈评测 → 谈演进，第八章场景题同样适用
- 先澄清需求（30 秒）数据规模形态？单跳还是多跳？延迟成本？能不能出内网？
- 给基线方案几乎总是 Advanced RAG，并说明它为什么是默认起点
- 按需加挂要不要 Agentic / Graph / 多模态，并明确说出代价
- 谈评测怎么验证方案有效、评测集怎么建、上线后怎么迭代
- 谈演进先上什么、后上什么，而不是一次性堆满
读过教程：这些回答会暴露你
- 一听场景就报架构，不问数据规模、延迟和内网要求
- 开口推 GraphRAG 或 Agentic，说不清为什么不是 Advanced
- 只讲要加哪些组件，不讲各自的延迟增量和成本增量
- 整套方案讲完，没提怎么验证它到底有没有效
- 把方案说成一次到位，跳过先上什么、后上什么
设计过系统：这些细节骗不了人
- 先花 30 秒澄清四件事，再开口给方案
- 把 Advanced RAG 当默认基线，加挂的每一项都报代价
- 报得出 Agentic 查询成本数倍、GraphRAG 索引 5–10 倍
- 主动讲评测集怎么建、上线后怎么按 badcase 迭代
- 给出演进顺序，并说每次只加一个组件、跑一次全量回归
第 1 步和第 5 步是大多数候选人会跳过的，也正是面试官区分「设计过系统」和「读过教程」的地方。配套题目：
Q2-25（架构选型）、Q2-22（多模态）。Q2-25 这类开放选型题的标准回答结构（也适用于第 8 章所有场景设计题）：
- 先澄清需求（30 秒）：数据规模和形态？问题类型是单跳还是多跳？延迟和成本约束？数据能不能出内网？——不澄清就报架构是最大的扣分项，真实工作里没人这么干。
- 给基线方案：几乎总是 Advanced RAG，并说明为什么它是默认起点。
- 按需加挂：结合场景说明要不要 Agentic / Graph / 多模态，并明确说出代价。
- 谈评测：怎么验证方案有效、评测集怎么建、上线后怎么迭代。
- 谈演进：先上什么、后上什么，而不是一次性堆满。
第 1 步和第 5 步是大多数候选人会跳过的，也正是面试官区分「设计过系统」和「读过教程」的地方。
模块 2 小结
继续深入
本篇归属第 2 章「RAG 工程化」，去做这一章的题。