模块 07 — 架构师问答题（含 1 道场景决策题）

先自己答，再对照要点。术语保持英文。

Q1. 「知识库大就上向量库」这个第一反应错在哪？请给出完整的检索选型决策树。

要点：

• 第一层：能不能整个塞进去。库 < ~窗口的可观比例（官方原文阈值 200k token ≈ 500 页；1M 窗口时代可等比放大）且更新慢 → 全量进 prompt + prompt caching——架构最简、无检索失败模式、缓存后成本可控。这是官方明确认可的方案，跳过它直接上 RAG 是 Common Mistake #1。
• 第二层：库塞不下 / 每查询只需小切片 → RAG，且默认 Hybrid（Embeddings + BM25 + rank fusion）：语义路管「意思像不像」，词法路管「字面有没有」（错误码/SKU/法条编号等精确 token 是向量盲区，官方 TS-999 例子）。官方结论：Embeddings+BM25 好于单独 embeddings。
• 第三层：多轮探索、来源异构、查询不可预知 → Agentic search（just-in-time 检索、渐进式披露），代价是运行期慢、可能乱逛；官方推荐常常是混合（Claude Code 样板：固定资料预先入上下文 + grep/glob 按需拉取）。
• 贯穿约束：权限/租户隔离是硬要求时必须在检索层 pre-filter，由应用强制；context rot 永不消失——大窗口降低 RAG 的必要性但不取消「策展上下文」的要求。

Q2. 给定一批异构文档（Markdown 手册、PDF 合同、代码仓库、FAQ 工单），你怎么做 chunking 决策？

要点：

• 原则先行：块大小不是超参数玄学，由「一个答案需要多少上下文才能自解释」决定；官方流程「每块通常不超过几百 token」，cookbook 用 800 token 块估算成本。
• 按类型分策略：Markdown/API 文档 → 结构化分块（按标题/章节切，保留标题链元数据）；代码 → 按函数/类切（模块 09 联动）；合同/法务 → 按条款切；FAQ → 每问答一块（天然语义单元）；均质长文 → 固定 + 重叠做基线。
• 两个病都要治：边界丢失（重叠 10–20% 缓解，代价索引膨胀）与主语丢失（"The company's revenue grew by 3%" 缺公司/季度——结构化带标题链或上 Contextual Retrieval 情境前缀）。
• chunk size / boundary / overlap 都影响检索性能（官方实现注意事项），每次调整都要有金标集数字背书（见 Q4）。
• 成本视角：上下文前缀用廉价模型生成 + prompt caching 摊薄，官方 $1.02/百万文档 token——一次性索引期计算换运行期检索精度。

Q3. 什么时候该引入 Reranker？引入前必须确认什么？

要点：

• 前提：检索层已有评估集与基线指标（recall/precision/MRR）。没有基线就没有「排序差」这个诊断。
• 信号：recall@N 高（宽召回里有答案）但 top-K 精排质量差（答案常在 20 名开外）、噪音块挤占上下文预算、模型被无关块干扰——这是 cross-encoder 精排的靶区。
• 架构：宽进严出——Hybrid 召回 Top-N（官方 150）→ reranker 精排 Top-K（官方 20）进 prompt。bi-encoder 快而粗（可预计算）负责全库，cross-encoder 准而慢只对 Top-N。
• 收益与代价：官方数据 reranking 使检索失败率累计降 67%（5.7%→1.9%），且更好回答 + 更低成本与延迟（模型处理的无关信息更少）；代价是运行期多一跳延迟与 reranker 费用——延迟敏感场景必须实测平衡，块数越多延迟成本越高。
• 反模式：检索 recall 本身就低（该召回的没召回）时先修召回侧（hybrid、chunking、前缀），reranker 救不了没进 Top-N 的块。

Q4. 从零为一个企业 RAG 系统设计评估体系，你会怎么分层落地？

要点：

• 金标先行：构建 golden dataset（问题 → 金标块/答案对）。官方上下文检索 cookbook 用 248 条带 golden chunk 的评测查询；无金标 = 盲调。
• 检索层指标：Recall@k（查全——RAG 优先，块没检索到生成再强也没用）、Precision@k（查准——上下文预算紧时关键）、MRR（单正确答案问答）、nDCG（分级相关度排序）、Pass@k（单金标块，实现最简）。警惕指标作弊：recall 靠加大 K 就能涨（全库塞入 recall=100%），必须与 precision/nDCG 同看。
• 生成层指标：Groundedness（回答主张被证据支撑比例，防幻觉）与 accuracy 分开评——有据≠正确（原文可能过时）、正确≠有据。
• 端到端层：官方 RAG cookbook 用 Claude 当评分员（grading）评最终回答；两层顺序按管线因果链：先检索后端到端，检索层崩了调 prompt 无用。
• 流程化：每次「调 chunk 大小 / 换嵌入模型 / 加 reranker / 改 K」都跑金标集回归，数字背书后再上线；线上配 groundedness 抽检与引用率监控（citations 使主张可回溯）。
• 参照值：官方 RAG cookbook 基线 Precision 0.44 / Recall 0.69 / MRR 0.865 / 端到端 0.81——特定数据集演示值，不是通用基准。

Q5. 多租户企业知识库的权限模型在 RAG 架构里怎么落？为什么提示词方案不可接受？

要点：

• 块入库时打结构化元数据：{tenant, source, doc_type, updated_at, acl, product_line}；查询时 pre-filter（检索前过滤候选集）优于 post-filter（检索后过滤——可能把 Top-K 全滤光导致空结果或被迫回填噪音）。
• 同时解决三问题：安全（用户看不到的文档根本不进候选集——应用层强制）、新鲜度（updated_at > 政策下线日，防作废政策被引用）、精度（候选空间更小，检索更准）。
• 提示词方案（「请不要引用其他租户的文档」）不是授权机制：LLM instruction ≠ application enforcement（模块 11 联动）——指令可被忽略、可被注入攻击绕过，泄露已经发生才可能被发现。安全边界必须在确定性代码层。

Q6. 上下文窗口已到 1M token，「RAG 还有没有必要」——你怎么回答 CEO 的这个问题？

要点：

• 官方物理约束：context rot——token 越多准确率与召回率越退化（transformer n² 注意力、attention budget 有限）；官方判断「可预见的未来里，任何尺寸的窗口都受上下文污染与相关性问题困扰」。
• 经济约束：全量拼接的成本与延迟随库大小线性涨；prompt caching 摊薄的前提是前缀稳定（更新频繁的库缓存失效快）。RAG 成本随块数线性而非随库大小。
• 决策表：库 < 窗口的 ~20–30% 且更新慢 → 塞 + caching；库 > 窗口或每查询只要小切片 → RAG；查询不可预知/探索型 → agentic search；三者常组合。
• 一句话：窗口是工作内存不是硬盘；大窗口改变了「塞得下」的边界，没有取消「策展」的必要。

Q7. 「索引一建永不更新」会造成什么？预检索索引与 just-in-time 检索怎么选？

要点：

• 陈旧索引症状：作废政策仍被引用（新鲜度事故）、新文档查不到、块内容与源文档漂移（引用对不上原文）。
• ingest 管线要求：增量更新、失效机制（源文档删除/更新时块级失效）、updated_at 元数据支撑查询期过滤。
• Just-in-time 检索（agentic 派）的优势恰在于此：运行期直接查源头，没有陈旧索引问题；代价是慢、不可预测、查询成本高。
• 官方混合样板（Claude Code）：固定资料（CLAUDE.md）预先进上下文，动态资料靠 grep/glob 按需拉取——预检索与即时检索不是二选一。
• 决策变量：数据变更频率、延迟预算、查询可预测性。

Q8.（场景决策题）玩具 RAG 升级为生产级：从哪里下手？

Scenario

团队现有一个「玩具级」内部问答机器人：文档按 512 token 硬切、只用向量检索 top-5、无元数据、无引用、无评估集。现在要把它升级为面向客户支持团队的生产系统，语料含产品文档、故障排查手册（大量错误码）、历史工单，多个产品线，文档每周更新。

Constraints

• 精确 token 查询（错误码如 TS-999）是高频场景
• 多产品线，权限按团队划分
• 文档每周更新，旧版本政策必须立即失效
• 无额外预算引入昂贵组件，团队可运维向量库 + 全文索引

Options

A. 只把 top-5 调成 top-20，其余不动 B. 结构化/上下文感知分块 + Hybrid（Embeddings+BM25+RRF）+ metadata pre-filter + Citations + 金标评估集，reranker 二期再加 C. 直接全部推倒换成 agentic search（给模型搜索引擎工具） D. 全量语料塞 1M 窗口 + prompt caching

Best choice

B。

Why

• 症状逐条对症：错误码盲区 → BM25 路；主语丢失/表格被切断 → 结构化分块 + 上下文前缀；跨产品线与权限 → metadata pre-filter（应用层强制）；不可审计 → Citations；「调什么都靠感觉」→ 金标评估集先行。
• 官方路线图顺序即如此：先 Hybrid（Embeddings+BM25 失败率已显著降），上下文化后 +49%，reranking 再 +67% 但可二期——先把召回与块质量做对，精排收益才立得住。
• 每周更新 → ingest 增量 + updated_at 过滤解决失效。

Why others are weaker

• A：K 调大只涨 recall 假象，context rot 与噪音同步上升（Common Mistake #6）；单路向量检索的精确匹配盲区、权限缺失、无评估的根病一个没治。
• C：客服问答查询模式可预测，agentic search 的运行期延迟与不可预测性是纯代价；且把权限交给模型自行检索反而扩大安全面。
• D：语料（产品文档+手册+工单）远超可塞规模且每周更新，缓存前缀频繁失效，成本与 context rot 都不可接受。

Tradeoffs

• B 的工程面最大：两套索引（向量+全文）运维、上下文前缀的索引期 LLM 成本（prompt caching 摊薄后 ~$1.02/M doc tokens）、金标集的前期标注投入。
• reranker 延迟二期引入时需在延迟敏感链路实测（宽进 Top-150 → 严出 Top-20 的额外一跳）。

What would change the answer

• 若语料其实很小（<200k token）且更新慢 → D 变为合理（官方「最简单方案」原则）。
• 若查询是探索型/跨源调查（支持工程师排查复杂案例）→ C（agentic search）或 B+C 混合（预取固定手册 + 按需搜工单）。
• 若延迟预算极紧（实时对话）→ reranker 与 agentic 都慎入，靠更准的召回与更小的 K。

覆盖对照