怎么考「给你一个新场景，怎么决定用 Naive / Advanced / Agentic / Graph 哪种架构？」
谁在问：二三面·综合判断题；技术负责人面尤其爱问
开场怎么问
假设我们要做一个 XX 领域的知识问答，你会怎么设计？
换个问法
- 你怎么判断一个场景该用什么样的 RAG 架构？
- 如果让你重新做一遍上一个项目，架构上会怎么调整？
五层追问链
左边照着问，右边对着听。最后一层是压力面，不必每个候选人都问到。
为什么 Advanced RAG 是默认基线而不是 Naive？
- 期望
- 混合检索和 rerank 的投入产出比极高——前者解决专有名词漏召回（几乎每个真实业务都有），后者是单项收益最大的优化。而它们的成本增量很小（BM25 几乎免费，rerank 几十到几百毫秒）。Naive 只在文档量极小或纯原型阶段合适。
- 信号
- 能用「投入产出比」而非「更先进」来论证的，是工程思维。
客户预算只有原来的一半，你砍什么？
- 期望
- 按收益成本比倒序砍——先砍 Agentic 循环（成本最高、收益最不确定）、再砍多路查询扩展、HyDE；保留混合检索（几乎免费）和 rerank（可换轻量模型或减候选数）；把 embedding 从 API 换成自托管开源模型；降维压存储。要能给出每一刀损失多少精度的量化说法。
- 信号
- 按「先砍贵的」而不是按「先砍收益低的」排序的，缺乏权衡意识。
如果只能选一个指标向老板汇报，你选哪个？
- 期望
- 不选纯技术指标——选业务代理指标（如客服转人工率下降、平均处理时长缩短、用户点踩率）。技术指标是给团队看的，老板看的是业务影响。加分：说明技术指标和业务指标之间的传导链路。
- 信号
- 脱口而出「recall@5」的，缺少向上沟通的视角。
系统日活从 100 涨到 10 万，架构要变什么？
- 期望
- 分层回答——检索层（单机向量库扛不住 → 量化/分片/分布式）、生成层（并发限流、模型路由让简单问题走小模型、语义缓存）、成本层（token 预算监控告警）、可观测（trace 采样而非全量）。同时要说清哪些不变：分块策略、评测体系、引用机制不随流量变。
- 信号
- 只答「加机器」的，没有分层视角。
你给的方案我们试过了，效果不行，怎么办？
- 期望
- 不辩解，先要信息——「效果不行」具体是哪类 query、失败形态是什么、有没有分桶数据。然后走归因流程（Q2-17）：先切开检索和生成，再定位到具体环节。关键是把模糊的否定转化为可排查的问题，而不是急着换方案。如果对方给不出细节，就提议先花两天建评测集把问题量化出来。
- 信号
- 立刻推翻自己的方案换一套的，缺乏定力；能坚持「先量化再决策」的，是成熟工程师的反应。
危险信号
听到这些话，基本可以判定是背题而不是做过。
评分卡
- 先澄清需求再给方案（最重要的单项）
- 给出明确的基线方案并说明为什么
- 按需加挂时同时说出代价
- 主动谈评测方法和评测集建设
- 给出演进路径而非一次性堆满
- 加分：能针对具体场景说出「不用什么、为什么不用」
- 加分：有成本预算意识和砍需求的优先级
- 加分：能把技术指标翻译成业务指标
参考答案与考察意图面试中途别看这一段
考察意图
这是第 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。