模块 07 — 考试题型（Exam Style）

题干中文、考试术语保持英文。答案与逐项解析在文件末尾「答案与解析」独立小节。

单选题

1. 官方对「知识库小于 200,000 token（约 500 页）」的场景给出的建议是：

A. 仍然搭建 RAG，为未来扩展做准备 B. 把整个知识库放进 prompt，配合 prompt caching，无需 RAG C. 必须使用 agentic search 才能保证质量 D. 先做 embedding 索引再按 Top-K 检索

1. 用户查询错误码 "Error code TS-999"，官方文档指出能命中精确字符串的检索方式是：

A. Vector search（语义检索） B. Embeddings + cosine similarity C. BM25（lexical search） D. Reranking（cross-encoder）

1. Anthropic 官方实验关于 Hybrid Retrieval 的结论是：

A. Embeddings 单路好于 Embeddings + BM25 B. Embeddings + BM25 好于单独 embeddings C. BM25 单路好于两者结合 D. 三者表现相同，选最便宜的即可

1. Contextual Retrieval 中「上下文前缀」的生成方式是：

A. 把每个块的关键词用 TF-IDF 加权后自动提取 B. 用廉价模型读「整篇文档 + 当前块」，生成 50–100 token 的情境说明前缀到块上 C. 在查询时由 reranker 现场生成 D. 把文档标题复制到每个块开头即可，无需模型

1. 官方实验数据：Contextual Embeddings + Contextual BM25 + Reranking 三层叠加后，Top-20 检索失败率的累计改善是：

A. 35%　B. 49%　C. 67%　D. 90%

1. 多租户 SaaS 的 RAG 系统中，「用户 A 不能看到租户 B 的文档」应在哪里强制执行？

A. 在 system prompt 里写「请不要引用其他租户的文档」 B. 在检索前的 metadata pre-filter 中由应用层按 tenant/acl 过滤候选集 C. 在生成后用另一个模型检查回答里是否含其他租户信息 D. 在 prompt 里加 XML 标签声明当前用户身份

1. Reranker（cross-encoder）只对召回的 Top-N（官方用 150）做精排，而不对全库做，原因是：

A. cross-encoder 无法处理短文本以外的内容 B. cross-encoder 把 query 与 chunk 拼接联合编码，精度高但慢，全库跑代价不可接受 C. 官方规定 Top-N 不能超过 150 D. 向量数据库不支持全库重排序接口

1. 一个 RAG 问答系统：回答的每句话都严格引用了检索到的原文段落，但该段落来自一份已作废的政策文档。对该次回答的正确评价是：

A. Groundedness 低、accuracy 低 B. Groundedness 高、accuracy 低 C. Groundedness 低、accuracy 高 D. Groundedness 与 accuracy 是同一概念，无须区分

1. 用户反馈「该查到的文档经常查不到」。按管线因果链，架构师应首先检查：

A. 生成侧 prompt 是否足够严格 B. 检索层 Recall@k（及 MRR） C. Precision@k 是否过高 D. temperature 设置

1. 关于 Citations 功能，官方列出的行为是：

A. cited_text 计入输出 token，因此更贵 B. cited_text 不计入输出 token；引用保证指向你提供的文档 C. 引用可以指向任意外部网页 D. 同一请求中可以对部分文档开启、部分关闭 citations

多选题

1. 关于 Citations 功能，下列说法正确的有：

A. 在 document 块上设置 citations.enabled=true 开启 B. 请求内所有文档要么全部开启、要么全部关闭 citations C. 当前仅支持文本引用 D. 引用保证指向你提供的文档，而非模型虚构的来源

1. 关于检索质量指标，下列说法正确的有：

A. Recall@k 可以靠无限加大 K 来提升（极端：全库塞入 recall=100%），因此必须与 precision/nDCG 一起看 B. MRR（Mean Reciprocal Rank）适合单正确答案的问答场景 C. nDCG 使用位置对数折损，适合分级相关度的排序质量评估 D. RAG 系统中应优先优化 Precision@k 而非 Recall@k

场景决策题（S1）

Scenario

你在为一家 B2B 软件公司构建售前助手，知识库是完整的产品文档集，约 60,000 token（约 150 页）。文档每季度随版本发布更新一次；查询以「产品功能/限制/价格」的事实型问答为主，模式相对可预测。公司已有 1M token 上下文窗口的模型可用，且对首次响应延迟与成本敏感。

Constraints

• 知识库 60k token ≪ 200k token 官方阈值（也仅占 1M 窗口的 6%）
• 更新频率低（每季度一次，缓存失效少）
• 查询可预测、事实型，不需要多轮探索
• 团队没有向量数据库运维经验
• 延迟与成本是硬指标

Options

A. 全量知识库塞进 system prompt + prompt caching B. Hybrid RAG（Embeddings + BM25 + RRF + Reranking） C. Agentic search（把搜索工具交给模型按需检索） D. 不用缓存，每次请求全量拼接知识库

Best choice

A — 全量塞进 prompt + prompt caching。

Why

• 官方明确判断：知识库小于 200,000 token（约 500 页）时，最简单的方案就是最好的——把整个知识库放进 prompt，不需要 RAG；配合 prompt caching，延迟与成本非常有竞争力。
• 本例 60k ≪ 200k 阈值；查询可预测、事实型，不存在「库大塞不下」的压力。
• 架构最简：没有检索失败模式（漏检、错检、索引陈旧都从结构上消失），无需向量库/倒排索引/reranker 的选型与运维。
• 每季度更新一次 → 缓存前缀稳定，缓存命中率天然高。

Why others are weaker

• B（Hybrid RAG）：为不存在的规模问题引入一整套检索基础设施（嵌入模型、向量库、BM25 索引、reranker、金标评估集），增加运维面与故障模式；且检索层漏检（如精确 token 走向、chunk 切分不当）会成为新的质量风险——在库小且查询可预测时纯属负资产。
• C（Agentic search）：官方定位是「多轮探索、来源异构、查询不可预知」的场景；本场景查询可预测，agentic 检索的运行期多跳延迟与不确定性是纯代价。
• D（无缓存全量拼接）：每次请求都按 60k 输入 token 全价计费且 prefill 延迟高；prompt caching 正是官方让「塞库方案」在延迟与成本上有竞争力的配套手段。

Tradeoffs

• 放弃了检索带来的「按需取用」扩展性：知识库增长到接近或超过窗口阈值（或每查询只需极小切片）时，必须迁移到 RAG——迁移本身是重构成本。
• 全量拼接把整个库都放进上下文：context rot 意味着「塞得下 ≠ 塞得好」，需靠提示结构（长文档放前、查询放后等，模块 05）缓解。
• 每季度文档更新会使缓存前缀失效一次，该窗口期成本回升（可接受，因为频率低）。

What would change the answer

• 知识库增长到数百 K/数 M token（超过窗口或占窗口比例过高）→ B（Hybrid RAG）。
• 查询变为多轮探索型、来源异构、不可预知 → C（Agentic search）或与预取内容组合的混合策略。
• 出现多租户/权限硬隔离要求 → 若仍走塞库方案，必须由应用层按租户组装各自的知识库副本；规模一大通常还是回到 RAG + metadata pre-filter。
• 权限/新鲜度要求细粒度到单文档级（例如同库不同租户不同版本）→ B + metadata pre-filter 更自然。

答案与解析

单选

1. B。官方原文（Contextual Retrieval 一文「A note on simply using a longer prompt」）：库小于 200,000 token 时直接全量进 prompt，配合 prompt caching 在延迟与成本上很有竞争力。A 违背「最简单的方案就是最好的」；C 是查询不可预知场景的方案；D 是库大时的方案。考什么：更大上下文 vs RAG 决策框架第一层——先问能不能整个塞进去。

1. C。官方 TS-999 例子：embedding 模型可能返回「错误码处理总论」而错过精确匹配，BM25 按精确字符串命中。A/B 正是会漏的那一路；D 是精排不是召回，救不了没进 Top-N 的块。考什么：语义检索 vs 词法检索的分工——错误码/SKU/编号类 token 只能靠 BM25。

1. B。官方实验结论原文："Embeddings+BM25 is better than embeddings on their own"。A/C 与结论相反；D 忽略了混合的实际收益与精确匹配场景的必要性。考什么：Hybrid 是官方默认姿势的直接论断。

1. B。Contextual Retrieval 的定义：把「整篇文档 + 当前块」喂给廉价模型（原文用 Claude 3 Haiku），生成 50–100 token 情境说明前缀到块上，再做嵌入与 BM25 索引；成本靠 prompt caching 摊薄（$1.02/百万文档 token）。A 不是官方机制；C 时机错误（前缀在索引期生成，不是查询期）；D 是结构化分块保留标题链的做法，可视为近似但不是官方定义的 Contextual Retrieval。考什么：机制层理解——什么模型、什么输入、什么时机。

1. C。官方数据链：上下文嵌入单独 -35%（5.7%→3.7%）；+上下文 BM25 -49%（→2.9%）；+reranking 累计 -67%（→1.9%）。A/B 是中间档位数字。考什么：三层改进的量化顺序（35→49→67）。

1. B。权限/租户隔离必须在检索的 pre-filter 层由应用强制：用户看不到的文档根本不进候选集。A/D 是提示层「请求」，不是授权机制（LLM instruction ≠ application enforcement，模块 11 联动）；C 是事后检测，泄露已经发生。考什么：安全边界放哪一层。

1. B。cross-encoder 把 query 与 chunk 拼接后联合编码，能捕捉细粒度交互但计算量随候选数线性增长且不可预计算，因此只对双路召回的 Top-N（官方 150）做；bi-encoder 双塔可预计算、快而粗，负责全库召回。A 无依据；C 的 150 是官方实验值不是硬性规定；D 与机制无关。考什么：bi-encoder vs cross-encoder 的性能-精度权衡。

1. B。每个主张都能落到检索证据上 → groundedness 高；但证据本身过时 → accuracy 低。grounding ≠ accuracy，两个维度分开评（README §6/§11）。这正是官方场景里「可以有据但不完全正确」的定义。考什么：Groundedness 与 accuracy 的区分——高频概念辨析。

1. B。「该查到的查不到」是查全率问题 → 先看检索层 Recall@k（辅以 MRR 看排序）。按管线因果链，先检索指标后端到端指标：检索层崩了调 prompt 无用。A/D 是生成侧，因果链下游；C 与症状无关（precision 高不是病）。考什么：症状 → 指标 → 管线层次的路由。

1. B。官方 Citations 优势：cited_text 不计入输出 token（省钱）；引用保证指向你提供的文档（可靠）。A 与此相反；C 错——引用指向你提供的文档，不是外部网页；D 错——请求内所有文档要么全开要么全不开。考什么：Citations 的计费行为与指向性。

多选

1. A, B, C, D。四项均为官方文档行为：document 块上 citations.enabled=true 开启；全开或全不开的约束；当前仅支持文本引用；引用指向你提供的文档（可靠性优势）。考什么：Citations 平台特性的完整约束面。

1. A, B, C。A 是「指标作弊」提醒——recall 单看会被全库塞入式方案作弊，必须与 precision/nDCG 同看；B、C 是 MRR/nDCG 的标准定义与适用场景。D 反了——RAG 里 recall 优先：块没检索到，生成模型再强也变不出来。考什么：指标语义与 RAG 的评估优先级。

场景决策题 S1

见题内「Best choice / Why / Why others are weaker / Tradeoffs / What would change the answer」各节。核心考点：不要条件反射式上 RAG——官方判断标准第一层是「能不能整个塞进去」（<200k token 且更新慢 → 塞 + prompt caching）；第二层才是「库大 → Hybrid RAG」「查询不可预知 → Agentic search」。改变答案的关键变量：知识库规模增长、查询模式转向探索型、多租户权限与新鲜度的细粒度要求。