Chapter 05

自测题库：把漏斗取回来

前四章沿漏斗走了一遍：01 立起召回→精度漏斗与 grounding 契约，02 下探检索机制，03 把质量拆成"检索对不对 × 答得忠不忠实"，04 看仍在演进的前沿。这一章不教新东西——只逼你把它从记忆里取回来、并在没见过的场景里判别。

三层梯度，约 16 道题。概念层测词汇（对应 01），原理层测机制（对应 02·03），应用判别层给你没见过的场景、逼你选"该用哪一段的哪个技术"（跨章，是这份教程的迁移训练）。所有答案集中在文末一个折叠块里——每道题先自己写下答案，再展开对照。直接看答案，等于把这一章当成又读了一遍正文。

概念层 词汇 what · 对应 01 原理层 机制 how/why · 02·03 应用判别层 跨章场景 难度↑ 迁移↑
图 5.0三层难度梯度：底层概念（词汇，对应 01）→ 原理（机制，对应 02·03）→ 应用判别（跨章场景）。注意：越往上越逼近真实工作——能背出概念不等于能在场景里判别该用哪一段的哪个技术。判别层做不出来，说明前面是"读得顺"而非"学会了"。

5.1概念层（对应 01）

  1. RAG 把知识从模型权重搬到外部索引——它改变的是参数化记忆还是非参数化记忆？这带来哪一项微调给不了的能力？参考 §1.1
  2. 索引侧和查询侧唯一的交汇点是什么？参考 §1.2
  3. 为什么离线嵌 chunk 和在线嵌 query 必须用同一个嵌入模型？参考 §1.2
  4. chunk 切得太大，为什么含有答案的那段反而排不进检索前列？参考 §1.3
  5. 漏斗第一阶（检索）和第二阶（重排）分别最大化什么？参考 §1.8
  6. "检索质量是答案质量的上限"——用一句话说清这句话的含义。参考 §1.7

5.2原理层（对应 02·03）

  1. dense 检索为什么对 ERR-5023 这类罕见、靠精确字形识别的 token 不可靠？参考 §2.1
  2. BM25 靠什么命中 dense 漏掉的精确词？它本身又对什么盲？参考 §2.2
  3. RRF 融合两条检索结果时，为什么用排名（rank）相加、而不是相似度分数？参考 §2.3
  4. cross-encoder 比 bi-encoder 准在哪一个机制上？为什么它只能用在 top-k、不能扫全语料？参考 §2.4
  5. HyDE 为什么去嵌入一个 LLM 编出来的"假设答案"、而不是问题本身？参考 §2.5
  6. faithfulness 和 context recall 各自量的是漏斗的哪一段？为什么两个都要量？参考 §3.3
  7. lost-in-the-middle 是什么现象？它是不是由 RoPE 位置编码导致的？参考 §3.4

5.3应用判别层（跨章场景 · capstone）

这一层是这份教程的重心。每道题给一个没见过的场景，逼你在不同章节的方案之间做选择，并说出决定的那条轴。题号后标注了它考的章节。

  1. ［01·02］用户搜 "ERR-5023 错误码怎么解决" 总召回不到那段明明存在的文档；另一个用户搜 "登录失败怎么办" 却找得很准。问题出在漏斗哪一段？该上 dense / BM25 / hybrid 里的哪个？为什么？
  2. ［01·02］预算只够加一个组件。情形 A：正确文档经常根本没进 top-100。情形 B：正确文档进了候选，但排在第 50。两种情形分别该加什么（查询改写/hybrid，还是 rerank）？加错了会怎样？
  3. ［03］线上 faithfulness 0.95、answer relevance 0.92，用户却投诉"答得不全、不对"。最该先查哪个指标？为什么不是继续优化 faithfulness？
  4. ［01·03·04］"第 7 条款的赔偿上限是多少" 与 "总结这 300 份合同的共同风险点"——两个问题该用同一套朴素 RAG 吗？后者朴素 RAG 为什么力不从心？哪个前沿方向对症？
  5. ［04］语料是一份 80K token 的合同，要做整体审阅式问答；查询量很低、可容忍 30 秒延迟。上 RAG 还是直接塞长上下文？决定的那条轴是什么？
亲手画一张图

合上教程，在纸上或 Excalidraw 里画 RAG 的召回→精度漏斗——只画 3 个阶段框（检索 / 重排 / 生成），在每个框旁写下它最大化的目标（召回 / 精度 / grounding）。然后把这 5 个技术各钉到它作用的阶段上：hybrid、rerank、HyDE、Contextual Retrieval、GraphRAG。

画完回到 图 1.3 和 §4.6 的映射图对照——你有没有把 GraphRAG 钉错地方（它改的是语料结构 / 检索单元，不是生成）？有没有发现 HyDE 钉在了"入口"而不是某个阶段框内部？

进阶挑战 · 刚好够不着

把一个真实失败，倒推回漏斗

线上反馈：用户问"我们公司在欧盟的数据合规要求"，系统答了一段看起来专业、但其实是模型编的通用 GDPR 常识，并未引用你语料里那份内部合规手册。请按漏斗倒推，列出至少 3 个可能的故障点（分别落在索引侧 / 检索 / 生成），以及你会用哪个指标或检查去区分到底是哪一个。

提示（卡住再展开）

从出口往入口查：生成阶段（grounding 没约束住、faithfulness 低）→ 检索阶段（手册那段根本没进候选，context recall 低；或进了但被排下去）→ 索引侧（那份手册压根没入库 / 已过期未重建 / 分块把关键句切碎）。三类各对应一个不同的修法，别一上来就调 prompt。

5.4答案

先把上面三层的答案都写下来，再展开。

展开全部答案（先做完再看）

概念层

  1. 改变的是非参数化记忆（外部索引），参数化记忆（权重）不动。带来的能力：知识可随时更新、可溯源（指出答案来自哪份文档第几页），且不重训模型即可换知识。
  2. 索引。索引侧离线写入它，查询侧在线读取它。
  3. 因为近邻搜索比的是 chunk 向量与 query 向量在同一空间里的距离；两者用不同模型嵌入，会落在不同空间，距离失去意义。
  4. 一个大 chunk 里塞了多个主题，它的嵌入是这些主题的"平均"，对任何单一问题都不够锐利，于是排不过那些主题单一、向量更聚焦的 chunk。
  5. 检索最大化召回（别把正确答案漏在候选之外），重排最大化精度（把噪声压下、真正相关的顶上来）。
  6. 证据没被检索到，生成无论如何答不对——所以检索召回的上限，就是答案正确率的上限。反过来不成立：证据齐全也不保证答对。

原理层

  1. dense 把整段文本压成一个定长向量，是有损的——保留语义主旨、抹平精确字形。ERR-5023 的精确形态在压缩中被平均掉，于是它和一堆"语义沾边但不是这条"的段落挤在一起。
  2. BM25 基于字面词项重叠：罕见且精确出现的词获得高 IDF 权重，不依赖语义。代价是它对同义/改写盲——零词面重叠就是零分。它和 dense 的盲区正好互补。
  3. 因为 BM25 分数无界、cosine 有界，两者尺度不可比；归一化再相加很脆弱。RRF 用 Σ 1/(k+rank) 干脆丢掉数值大小、只看名次，换来尺度无关与稳健（代价是丢掉了置信度信息）。
  4. cross-encoder 把 [query; doc] 拼成一次前向，让 query 与 doc 逐词互相注意，建模点积建模不了的细粒度相关性。代价是每个候选都要单独跑一次、不可预计算，所以只能用在 top-k 小名单上，扫全语料代价无法承受。
  5. 因为"答案"和真实的答案段落落在嵌入空间的同一邻域，而"问题"不在。嵌入那个假设答案，query 向量就落得离正确段落更近；编造的细节被嵌入的有损瓶颈"洗掉"，不太影响检索。
  6. context recall 量检索段（需要的证据是否都被检索到了），faithfulness 量生成段（答案是否扎根于检索到的上下文、没编造）。两个都要量，因为系统可以"忠实地基于不完整的证据作答"——faithfulness 高而 recall 低，不分开量就定位不到。
  7. 它指模型在长上下文里对中间位置的信息利用率显著下降、呈 U 形（首尾好、中间差）。它是 Liu 等 2023 的经验测量结果，并非由 RoPE 位置编码机制推出；且在长上下文模型上依然出现。

应用判别层

  1. 问题在检索段的召回：ERR-5023 是精确 token，纯 dense 漏掉它（§2.1 有损瓶颈），而"登录失败"是语义查询、dense 本就擅长。该上 hybrid——用 BM25 这一路把精确词项捞回来，再与 dense 融合（§2.2、§2.3）。只换更强的 dense 模型治不了这个病。
  2. 情形 A 是召回问题：正确文档没进候选，加 hybrid / 查询改写去扩召回（§2.2、§2.5）。情形 B 是精度问题：进了但排不上，加 rerank（§2.4）。加反了没用——给"没进候选"的系统加 rerank，它仍然无米下锅；给"排不上"的系统拼命扩召回，噪声更多。这就是漏斗两阶必须分开诊断的理由（§1.8）。
  3. 最该查 context recall（§3.3）。faithfulness 0.95 说明答案忠实于检索到的上下文，但若 recall 低，模型就是在"忠实地基于不完整的证据作答"——证据本身就缺。继续优化 faithfulness 只会让它更忠实地答错。
  4. 不该用同一套。第一个是单点事实查询，标准 RAG 足够。第二个是全局 / 多跳归纳，答案分散在 300 份文档里、需要结构化聚合，平铺 chunk 检索每次只捞回局部片段，凑不出全局结论（§3.4 的失败、§1.8 漏斗的局限）。对症的是 GraphRAG（知识图 + 社区摘要）或 Agentic RAG（多轮迭代检索）（§4.2、§4.3）。
  5. 这种场景长上下文更合适：语料小（80K，远在质量下滑的 ~500K 之前）、需要全局推理、查询量低、可容忍延迟——RAG 的分块反而可能切碎跨条款的关联。决定的轴 = 语料大小 / 相关信息占比 / 延迟 SLO / 查询量（§4.5）。若语料涨到几百万 token、或查询量很高、或要求秒级响应，结论就反过来。

进阶挑战参考

三类故障点举例：索引侧——合规手册根本没入库，或已更新但索引未重建，或分块把"欧盟/GDPR"与具体条款切到了不同 chunk（§3.2、§3.4）；检索段——手册那段没进 top-k（context recall 低），或进了被排到后面（精度问题，§2.4）；生成段——证据其实检索到了，但 grounding 没约束住、模型用参数化的 GDPR 常识覆盖了它（faithfulness 低，§3.1）。区分手段：先看 context recall 判断"证据有没有进来"，再看 faithfulness 判断"进来了有没有被用"，最后查索引里到底有没有这份文档及其新鲜度。

洞察 · 怎么算真的学会了

概念层、原理层答得出，只说明你记住了。真正的检验在判别层——给一个没见过的场景，你能不能立刻定位到漏斗的某一段、说出该用哪个技术、为什么不是另一个。如果判别题让你卡住、或答完心里没底，那正是该回头重读对应章节的信号，而不是"读着顺就当学会了"。