给你一个新场景，怎么决定用 Naive / Advanced / Agentic / Graph 哪种架构？
谁在问：二三面·综合判断题；技术负责人面尤其爱问
口语化问法
- 假设我们要做一个 XX 领域的知识问答，你会怎么设计？
- 你怎么判断一个场景该用什么样的 RAG 架构？
- 如果让你重新做一遍上一个项目，架构上会怎么调整？
考察意图
这是第 2 章的收口题，也是第 8 章所有场景设计题的通用骨架。 面试官不期待标准答案，他在看回答的结构：① 你会不会先澄清需求再报方案——上来就说架构的是最大扣分项；② 你的方案有没有基线和演进路径，还是一次性堆满；③ 你会不会主动谈评测和成本。
参考答案
标准回答结构（五步，务必按顺序）
第一步：先澄清（30 秒，最容易被跳过也最重要）
反问面试官：
- 数据规模和形态？多少文档、什么格式、有没有表格图纸、更新频率如何？
- 问题类型？主要是单跳事实问答，还是需要多跳推理、跨文档对比、全局归纳？
- 约束？延迟要求、成本预算、数据能否出内网、要不要权限隔离和引用溯源？
- 团队？有没有人能长期运维分布式组件？
真实工作中没人会不问就动手，这一步本身就是评分项。
第二步：给基线方案
几乎总是 Advanced RAG，并说明为什么它是默认起点：结构/语义分块 + 混合检索（BM25 + 向量 + RRF）+ Rerank + 元数据过滤。这套是 2026 年生产环境的性价比最优基线。
第三步：按需加挂，并明确说出代价
| 触发条件 | 加什么 | 代价 |
|---|---|---|
| 多跳推理、多源对比 | Agentic 调度层 | 成本数倍、延迟秒级、稳定性下降 |
| 跨文档实体关联、全局洞察 | GraphRAG（预算紧用 LightRAG） | 索引成本 5–10 倍、更新困难 |
| 图表图纸为主 | Multimodal RAG | 存储数十倍、生成成本高 |
| 结构化数据查询 | NL2SQL 支路 + 路由 | 需执行校验，错数字比不答更危险 |
| 数据不出内网 | 全开源自托管 | 运维负担 |
第四步：谈评测
怎么验证方案有效：建 100–200 条分桶评测集（含「知识库无答案」一类）→ 检索侧看 recall@k、生成侧看 faithfulness 与 answer relevancy → 上线后 badcase 归因回流。没有这一步，前面的架构全是纸上谈兵。
第五步：谈演进
先上什么、后上什么：
第 1 周 Naive RAG 跑通链路，拿第一批真实 badcase
第 2–3 周 建评测集（分水岭，很多团队卡在这）
第 4 周+ 按 badcase 归因逐项升级，一次只加一个组件，跑回归确认收益再留下
核心纪律：一次性堆满全家桶的系统，出问题时你根本不知道该拆哪个。
一个完整示范（以「制造业设备手册问答」为例）
先问：手册多少份、有没有大量表格和图纸、用户是现场工程师还是客服、要不要区分产品线权限、延迟能接受多久。
假设：500 份 PDF 手册、表格图纸多、用户是现场工程师（要快、要准、要能核）。
基线：结构感知分块（按章节标题）+ 混合检索（BM25 权重要高，因为型号错误码是主要 query）+ Rerank + 产品线元数据过滤。表格整表存 Markdown 并生成摘要向量；图纸密集页走多模态索引做分流。
不上 Agentic：现场工程师要秒级响应，多轮循环延迟不可接受；也不上 GraphRAG：设备手册的实体关系简单，没有跨文档推理需求。
强制项：引用必须给到文件名 + 页码（工程师要照着操作，必须能核）；检索分数低于阈值直接说不知道——在设备维修场景，错误答案可能导致安全事故。
评测：按 query 类型分桶（型号类 / 故障现象类 / 参数查询类 / 无答案类），型号类单独盯 recall。
追问链
为什么 Advanced RAG 是默认基线而不是 Naive？
期望混合检索与 rerank 的投入产出比极高：前者解决专有名词漏召回（几乎每个真实业务都有），后者是单项收益最大的一步；成本增量却很小（BM25几乎免费、rerank 几十到几百毫秒）。Naive只在文档量极小或纯原型时合适信号用「投入产出比」而不是「更先进」来论证 → 工程思维客户预算只有原来的一半，你砍什么？
期望按收益成本比倒序砍：Agentic循环（最贵、收益最不确定）→ 多路查询扩展 →HyDE；保住混合检索（几乎免费）与 rerank（换轻量模型或减候选数）；embedding从API换自托管开源；降维压存储。每一刀都要说损失多少精度信号按「先砍贵的」而不是「先砍收益低的」排 → 缺权衡意识只能选一个指标向老板汇报，你选哪个？
期望不选纯技术指标，选业务代理指标：客服转人工率下降、平均处理时长缩短、用户点踩率 —— 技术指标是给团队看的，老板看的是业务影响。加分项是把技术指标到业务指标的传导链路说出来信号脱口而出「recall@5」→ 缺少向上沟通的视角日活从 100 涨到 10 万，架构要变什么？
期望分四层：检索层（单机向量库扛不住 → 量化 / 分片 / 分布式）、生成层（并发限流、模型路由让简单问题走小模型、语义缓存）、成本层（token预算监控告警）、可观测（trace采样而非全量）。还要说清哪些不变：分块策略、评测体系、引用机制信号只答「加机器」→ 没有分层视角你给的方案我们试过了，效果不行，怎么办？
期望不辩解，先要信息 → 问清「效果不行」是哪类query、失败形态是什么、有没有分桶数据 → 再走归因流程（Q2-17）：先切开检索与生成，再定位到具体环节 → 对方给不出细节，就提议先花两天建评测集把问题量化出来。要点是把模糊的否定转成可排查的问题信号立刻推翻自己的方案换一套 → 缺定力；坚持「先量化再决策」→ 成熟工程师的反应
评分要点
- 先澄清需求再给方案（最重要的单项）
- 给出明确的基线方案并说明为什么
- 按需加挂时同时说出代价
- 主动谈评测方法和评测集建设
- 给出演进路径而非一次性堆满
- 加分：能针对具体场景说出「不用什么、为什么不用」
- 加分：有成本预算意识和砍需求的优先级
- 加分：能把技术指标翻译成业务指标