架构决策训练 — 检索/上下文类（EX01–EX08）

主题：知识接入选型（RAG / long context / tool query / fine-tuning）、检索质量治理（query 侧、位置侧）、权限。八要素中的 Scenario / Constraints / Options 为题目；答案五要素在文末「答案与解析」。先做题，再翻答案。

EX01 — 法务合同库问答（★☆☆）

核心张力：RAG or long context?（依据：模块 07 §8）

Scenario 你为法务部门构建合同问答助手。知识体 = 标准合同模板 + 条款解释文档，共约 150,000 token（约 400 页）。每年随法务政策审订更新一次。查询以「这条条款什么意思/怎么写」的事实型问答为主，模式可预测。公司已有 1M token 上下文窗口的模型，法务对首次响应延迟敏感。

Constraints

• 库 150k token < 200k 官方阈值，仅占 1M 窗口的 15%
• 更新频率极低（每年一次）
• 查询可预测、无多轮探索需求
• 团队无向量数据库运维经验

Options A. 全量知识库放进 system prompt + prompt caching B. Hybrid RAG（embeddings + BM25 + RRF + reranking） C. Agentic search（搜索工具交给模型按需检索） D. 全量拼接、不开缓存

EX02 — 电信运营商 8M token 知识库（★☆☆）

核心张力：RAG or long context?

Scenario 运营商客服助手的知识库约 800 万 token：设备手册、故障工单历史、资费说明、网络覆盖文档，混合 PDF/HTML/工单文本，持续每周更新。查询大多是「用户报故障码 + 设备型号」的排查类问题。服务 5 个租户（不同省公司），文档权限按租户隔离。

Constraints

• 库远超任何上下文窗口（8M ≫ 1M）
• 高频精确 token（故障码、设备型号 SKU）
• 每周更新（索引新鲜度有要求）
• 多租户硬隔离

Options A. 1M 窗口模型 + 每次按租户拼接「最常用」文档子集 B. Hybrid RAG + metadata pre-filter（tenant/文档类型/时间）+ reranking C. 只用向量检索（无 BM25 路）的 RAG D. Agentic search 让模型自己翻目录找文档

EX03 — 客服 RAG 的「加料」提案（★★☆）

核心张力：more context or better retrieval?

Scenario 客服 RAG 上线三个月，抽查发现约 20% 的回答「没用上本该用的文档」。团队内两派意见：一派提议把 Top-K 从 10 提到 40，「多塞点上下文总能盖住」；另一派提议改检索本身（目前是纯向量检索，无 rerank，query 原句直查）。检索层评估显示：金标块 recall@10 = 0.61，很多失败查询是口语化短句（「wifi 灯红的咋整」）或含故障码精确词。

Constraints

• 现有上下文窗口充足（塞 40 块也装得下）
• P95 延迟预算有限（每回答 < 8s）
• 无 BM25 索引、无 reranker、无 query 改写（都是候选改进项）
• 有 500 条带金标块的评估集可用

Options A. Top-K 10 → 40，其余不动 B. Top-K 不动；引入 hybrid retrieval（+BM25）与 reranking（150→20），并用小模型做查询改写 C. 直接换更大的嵌入模型重索引 D. 换最大的模型（「模型强了就能在 40 块里找对」）

EX04 — 销售分析助手（★★☆）

核心张力：RAG or tool query / database?（依据：模块 07 §8.4、模块 06）

Scenario 销售VP 要一个对话式助手，典型问题：「上季度华东区销售额 Top 5 的产品？」「对比去年同期的毛利率变化」。数据在公司数仓（结构化表，每日 ETL 更新），同时还有 2000 页非结构化的销售策略文档。

Constraints

• 数值必须精确（进董事会报表）
• 数据每日更新
• 同时存在结构化数据与非结构化文档两类知识
• 团队已有受控的 SQL 视图层

Options A. 全部走 RAG：数仓导出文本快照 + 策略文档一起向量化 B. 结构化问题走 tool query（text-to-SQL 工具，应用侧只读视图 + 行数限额）；策略文档走 RAG——混合路由 C. 每日把数仓全量报表塞进长上下文 D. 微调模型学会「背下」常用报表数字

EX05 — 年度更新的编码手册（★★☆）

核心张力：fine-tuning or RAG?

Scenario 医疗编码团队的合规助手需要掌握国际疾病编码手册（约 10 万条编码条目 + 使用规则）。手册每年官方修订一次，修订幅度 5–10%。团队有微调预算，有人提议「把手册微调进模型，回答更快更准」。

Constraints

• 知识体大且每年必须跟随官方修订
• 回答需要可引用（审计要求指出依据条目）
• 内部已有 RAG 基础设施
• 合规场景，错误引用是事故

Options A. 每年用新版手册微调一次模型 B. RAG：手册结构化分块（按编码层级）+ hybrid 检索 + citations C. 手册全量塞长上下文 + prompt caching D. A+B 双管齐下

EX06 — 金标块总被忽略（★★☆）

核心张力：reranking + position（Lost in the Middle）（依据：模块 07 §15）

Scenario RAG 检索质量已达标（金标块 90% 进 Top-20），但端到端评估发现：当金标块位于拼装后上下文的中部（第 8–16 位）时，回答引用率明显低于它排在前 3 位时。目前块的摆放顺序 = 检索融合分数从高到低，20 块一次性罗列。

Constraints

• 检索层 recall 已达标，不想动索引
• 块的拼装逻辑在应用代码里，可自由控制顺序与格式
• 延迟预算不允许增加 LLM 调用轮数

Options A. 维持现状，接受中部损失 B. 重排摆放：把 reranker 分数最高的块放最前（其余放后部），配合 <document index> 编号 + 「先引用再作答」提示结构 C. 把 20 块对半拆成两次请求分别处理再拼接答案 D. 把 K 降到 5，只留前 5 块

EX07 — 竞品情报分析（★★☆）

核心张力：pre-built RAG or agentic search?

Scenario 战略团队要做竞品情报：问题形态开放（「X 公司最近在开发者生态上有什么动作？」），信源异构且动态（官网、新闻稿、应用商店评论、内部销售反馈），无法预判下一步要查什么，常需多轮追问式检索。此前预建索引的 RAG 方案总漏「上周刚发生的事」。

Constraints

• 信源集合每周变化，索引陈旧是主要痛点
• 查询不可预知、多轮探索
• 用户能接受 1–3 分钟的分析级延迟（非实时对话）
• 固定资料（竞品基础档案）是稳定的

Options A. 继续预建索引 RAG，把索引频率提到每天 B. 混合策略：固定基础档案预先进上下文（+缓存）；动态信源交给搜索工具按需检索（just-in-time） C. 全 agentic：所有资料（含固定档案）都让 agent 现查 D. 放弃检索，微调一个「懂行业」的模型

EX08 — 多租户知识库（★★★）

核心张力：prompt-level or retrieval-level permissions?（依据：模块 07 §5.1、模块 11）

Scenario SaaS 知识库服务 200 家企业客户，文档权限矩阵复杂：租户隔离是底线，租户内还有部门级 ACL（HR 文档只有 HR 角色可见）。Agent 回答用户问题时绝不能引用无权文档。安全审计在即。

Constraints

• 权限模型复杂且频繁变更（人员调岗即时生效）
• 审计要求：越权文档「根本不进入候选集」，而非「模型被要求不引用」
• 已有统一身份系统（会话携带用户/租户/角色）
• 检索必须支持 pre-filter

Options A. system prompt 写明「只引用用户有权文档」，权限表作为上下文附加 B. 每个（租户×部门）建独立小索引，按用户路由到对应索引 C. 统一索引 + metadata pre-filter：块带 tenant/ACL 元数据，检索前由应用按会话身份过滤（应用层强制） D. 检索后再过滤（post-filter）：先 Top-100，再按权限剔除

答案与解析

做完再看。评估自己：Best choice 答对只算一半，「What would change the answer」能独立复述才算通过。

EX01 — Best choice: A

Why

• 官方判断标准：知识库小于 200,000 token（约 500 页） 时最简单的方案就是最好的——全量进 prompt，不需要 RAG；配合 prompt caching 在延迟与成本上非常有竞争力（来源: https://www.anthropic.com/engineering/contextual-retrieval，访问于 2026-08-30）。
• 150k 在阈值内且更新频率极低 → 缓存前缀稳定，命中率高；查询可预测，无探索需求。
• 架构最简：检索失败模式（漏检/错检/索引陈旧）从结构上消失。

Why other choices are weaker

• B：为不存在的规模问题引入整套检索基础设施（嵌入、索引、reranker、评估），运维面与故障模式全是为负资产。
• C：agentic search 适合多轮探索/信源异构/查询不可预知；本场景查询可预测，多跳延迟是纯代价。
• D：每次全价计费 150k 输入 token 且 prefill 延迟高；缓存正是塞库方案的经济学配套。

Tradeoffs

• 库增长越过阈值（或占窗口比例过高）时需迁移 RAG，迁移是重构成本。
• context rot：塞得下 ≠ 塞得好，需靠长文档放前、查询放末尾的排布缓解（模块 05）。
• 每年更新使缓存失效一次（频率低，可接受）。

What would change the answer

• 库增长到数百 K+ token → B。
• 出现多租户/细粒度权限 → 若仍塞库须按租户组装副本，规模一大回到 RAG + pre-filter。
• 查询变为探索型/多轮 → C 或混合。

EX02 — Best choice: B

Why

• 8M token 远超窗口，「塞」这条路在物理上不存在；RAG 是唯一可扩展路径。
• 故障码/设备 SKU 是精确 token——官方 TS-999 例子明示向量检索的精确匹配盲区，BM25 词法路是必须项（hybrid）（来源: https://www.anthropic.com/engineering/contextual-retrieval，访问于 2026-08-30）。
• 多租户硬隔离必须落在检索的 pre-filter 层（应用强制），不是提示层请求（模块 11）。
• 每周更新要求 ingest 管线有增量与失效机制。

Why other choices are weaker

• A：「常用子集」靠人工策展，覆盖不了长尾故障；且每租户副本使缓存与维护成本翻 5 倍。
• C：砍掉 BM25 路 = 放弃精确 token 命中，故障码查询系统性漏检。
• D：让 agent 自己翻目录在 8M 语料上是低效的（多跳延迟、可能乱逛）；agentic 是检索的补充而非替代，规模场景应以预建检索为主。

Tradeoffs

• 引入索引运维（周更 ingest、嵌入模型版本管理）与检索失败模式。
• reranker 增加一跳延迟，需在延迟预算内实测收益。
• 权限元数据的维护成本（文档 ACL 变更要同步到块级）。

What would change the answer

• 若某租户库很小且私有 → 该租户可单独走塞库+缓存（分租户策略）。
• 若查询多为多轮排查（工程师坐席）→ 可在 B 之上叠加 agentic 层做探索。

EX03 — Best choice: B

Why

• 诊断先行：症状是「该用的文档没进上下文/没被用上」+ 失败 query 特征（口语短句、精确故障码）→ 病根在检索质量（query 侧 + 双路召回 + 精排），不在上下文量。
• 官方实验：Top-K 在 5/10/20 之间 20 块最好，但收益递减，「更多信息对模型是干扰」；把 K 提到 40 是拿 context rot 换假安全感（来源: 同上 contextual-retrieval，访问于 2026-08-30）。
• 口语 query → 查询改写（模块 07 §14）；故障码 → BM25；噪声块挤占注意力 → rerank 精排。
• 每项改进用 500 条评估集量化（recall@k 对比），不是拍脑袋。

Why other choices are weaker

• A：recall@10 只有 0.61——30% 的失败是「块根本没检索到」，K 提到 40 只能覆盖其中一部分，同时引入更多干扰块（LitM + context rot），延迟与成本同步上升。
• C：换嵌入模型只改语义路，故障码精确词与口语 query 两个病根都不在嵌入模型上；且是三项中成本最高的（全量重索引），应最后考虑。
• D：「更聪明的模型在 40 块里找对」是用最贵的手段补偿最差的检索；官方立场是先修管线（garbage in, garbage out）。

Tradeoffs

• B 引入三个新组件（BM25 索引、reranker、改写小模型）的运维与延迟成本。
• 查询改写多一跳 LLM 调用（小模型可控）；改写错误会传播，需保留原 query 双路召回。

What would change the answer

• 若诊断反过来：金标块 95% 都进了 Top-10 但端到端仍错 → 病根在生成侧（prompt/模型），B 的检索投资无效。
• 若延迟预算紧到容不下 rerank → 先做成本最低的 query 改写 + BM25。

EX04 — Best choice: B

Why

• 问题的两类知识形态不同：结构化精确聚合（销售额 Top5、毛利率对比）→ 查询数据库才是精确答案的唯一来源；非结构化策略文档 → RAG。
• 官方架构模式：Agent → 受控工具/查询 → database/API（模块 06）；text-to-SQL 限制在只读视图 + 行数/成本限额，模型构造查询、应用执行并校验。
• 数仓每日更新：查询时直查天然实时，无需为数值建索引。

Why other choices are weaker

• A：把数仓快照向量化 = 用语义相似度做精确数值检索——错误码尚且漏检，更别说聚合计算（Top 5 是算出来的不是检索出来的）。
• C：每日全量报表塞上下文：数值时效性错位（问的是「上季度」还好，问「本周」就错）、token 成本巨大、精确数字在长上下文中还要遭受 context rot/LitM。
• D：微调背数字 = 知识冻结在训练时刻，每日更新意味着模型永远过时；精确报表数字由权重「回忆」不可审计。

Tradeoffs

• text-to-SQL 有写错查询风险：需视图层收窄语义空间 + 查询校验 + 结果合理性检查；复杂多跳分析可能失败回退。
• 两套知识路径（工具查询 + RAG）需要路由判断（可由模型按问题类型自选工具，tool_choice: auto）。

What would change the answer

• 若数仓查询需求全部可枚举（就那 10 种报表）→ 连 text-to-SQL 都不需要，确定性代码直查（application decides）。
• 若精度要求放宽（方向性判断即可）→ A 的简化版可接受。

EX05 — Best choice: B

Why

• 时效性结构对比：RAG 的知识更新 = 重建索引（天级）；微调的知识更新 = 重新训练（周/月级 + 成本 + 回归风险）。手册每年必更新 → RAG 的更新路径是工程操作，微调的是项目工程。
• 审计要求可引用 → RAG + citations 天然满足（引用指向手册条目）；微调「背下来」的知识不可溯源。
• 编码手册是高度结构化文本（编码层级），结构化分块（按编码树）+ 精确编码号走 BM25，检索质量可做高。

Why other choices are weaker

• A：每年重训的边际收益（也许更快）远抵不上成本；且微调不保证逐条目的忠实回忆——合规场景「编错编码」就是事故。
• C：10 万条目远超窗口；就算塞得下，逐条目精确检索在长上下文里不可靠（context rot + LitM）。
• D：微调部分在没证明收益前是纯成本；「双管齐下」不是理由，是没做决策。

Tradeoffs

• RAG 每次回答多检索延迟；索引要跟随年度修订做全量重建（可计划）。
• 极高频的少数「骨干规则」若确实需要零延迟硬 recall，可少量放进 system prompt（策展制），而非微调。

What would change the answer

• 若任务其实是行为塑造（让模型总是按某固定格式/口径输出编码建议）而非知识注入 → 微调才进入讨论（那已经不是「记住手册」问题）。
• 若手册变小（几千 token）且不常更新 → C（塞库）最简。

EX06 — Best choice: B

Why

• 症状是典型的 Lost in the Middle：中部信息的利用率系统性低于头尾（Liu et al., https://arxiv.org/abs/2307.03172，访问于 2026-08-30）。
• 检索层已达标 → 投资应花在摆放与结构化上：位置是一种资源（模块 07 §15）。
• 编号标签 + 先引用再作答（<quotes> 技巧，模块 05 §1.2）让模型「定位」而非「扫描」，均为零延迟增量的提示层手段。

Why other choices are weaker

• A：接受可修复的系统性损失，且这是评估已量化的损失。
• C：两次请求 = 延迟与成本翻倍，且拼接答案引入新的一致性问题；延迟约束明确不允许。
• D：K 降到 5 会砍掉 recall（金标块 90% 进 Top-20，未必都在前 5），用漏检换位置是拆东墙补西墙。

Tradeoffs

• 「最高分放最前」依赖 reranker 分数质量；分数错位时位置策略放大错位。
• 结构化标签增加 prompt 维护复杂度（小）。

What would change the answer

• 若延迟预算放宽且块数继续增长 → C 的分批处理（map-reduce）成为正解。
• 若模型换代后中部衰减显著减轻（新模型长上下文能力提升）→ 位置策略的边际收益下降，可降级为「顺手做」。

EX07 — Best choice: B

Why

• 痛根是索引陈旧（漏上周的事）+ 查询不可预知（多轮探索）→ 动态信源正是 just-in-time / agentic search 的适用信号（来源: https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents，访问于 2026-08-30）。
• 固定档案稳定且高频使用 → 预先进上下文 + 缓存，省去每次检索。
• 官方样板即混合策略：Claude Code = 固定资料预先进上下文 + grep/glob 按需拉取（来源: 同上，访问于 2026-08-30）。

Why other choices are weaker

• A：把索引频率提到每天仍在追新鲜度（周更信源 + 日更索引 = 平均滞后半天到一天），且全量重索引成本线性上升；治标。
• C：固定档案也现查 = 放弃缓存与确定性，每次分析都多付几跳工具延迟；能预取的为什么要现查。
• D：微调「懂行业」解决的是通识不在权重里的问题，解决不了「上周的新闻」——知识新鲜度与微调是错配（EX05 同理）。

Tradeoffs

• agentic 层运行期慢（多跳）、可能乱逛：需要步数预算与停止条件（模块 08）。
• 混合策略两套机制并存，缓存与检索的职责边界要文档化。

What would change the answer

• 若信源集合固定且查询模式可枚举 → 退回纯预建 RAG（A 的低频版）。
• 若延迟要求降到秒级 → agentic 不可行，只能预建索引承担新鲜度代价。

EX08 — Best choice: C

Why

• 审计要求「越权文档根本不进候选集」= 权限必须是检索层的结构强制：块级 tenant/ACL 元数据 + 查询前 pre-filter，由应用按会话身份执行（应用层强制，非提示层请求——LLM 指令 ≠ 授权机制，模块 11）。
• 统一索引 + 过滤：权限变更即时生效（过滤条件来自身份系统实时数据，不需重建索引）。
• pre-filter 同时收窄候选空间，检索精度反升（模块 07 §5.1 三重收益：安全/新鲜/精度）。

Why other choices are weaker

• A：提示层约束是概率性的、可被注入与上下文漂移绕过；且把权限表塞上下文既烧 token 又泄漏权限结构本身。安全审计不可能通过。
• B：组合爆炸（200 租户 × 部门矩阵），索引碎片化使召回与运维全面恶化；权限变更涉及索引重建。
• D：post-filter 的漏洞：若 Top-100 里有 60 块越权，过滤后只剩 40 块——真正相关的块可能因越权块占位而根本没进 Top-100；且越权块已经过了检索器，「不进候选集」的审计语义被破坏。

Tradeoffs

• 块级 ACL 元数据的维护成本：文档权限变更必须同步到块（ingest 管线职责）。
• pre-filter 表达力受索引引擎支持的限制（复杂 ACL 表达式可能需简化模型）。

What would change the answer

• 若租户极少（3–5 家）且权限矩阵简单 → B 的独立索引因简单直接可重新评估。
• 若未来引入「跨租户共享文档」需求 → 元数据模型需预先设计共享标记，避免重构。