模块 07 — RAG 与上下文工程 (RAG & Context Engineering)

定位：模型的知识来自训练数据，你的应用知识来自你的数据。本模块回答一个架构师核心问题：怎么把正确的知识、以最小的 token 成本、放进 Claude 的上下文窗口 (Context Window)。覆盖 检索增强生成 (RAG, Retrieval-Augmented Generation) 全链路：嵌入向量 (Embeddings)、词法检索 (BM25/Lexical Search)、混合检索 (Hybrid Retrieval)、分块策略 (Chunking)、元数据过滤 (Metadata Filters)、重排序 (Reranking)、接地性 (Groundedness) 与检索评估指标，以及「更大上下文窗口 vs 更好检索」的决策框架。

📘 重要英语词汇：模块 07 词汇表

0. 学习目标

🎯 学习重点：用「离线索引、在线检索、接地生成、分层评估」四段框架串起全部组件与考点。

读完本模块你应能：

1. 画出一条完整的生产级 RAG 管线（ingest → chunk → embed/index → retrieve → rerank → generate → cite），并解释每一环为什么存在。
2. 区分语义检索 (Vector/Semantic Search) 与词法检索 (BM25/Lexical Search) 的强弱项，说明为什么混合检索 (Hybrid Retrieval) 是默认起点。
3. 按文档类型选择分块策略 (Chunking Strategy)：固定/重叠、语义、结构化（以及 Anthropic 官方的 上下文检索 (Contextual Retrieval) 思路）。
4. 用 Top-K、元数据过滤 (Metadata Filters)、重排序 (Reranking) 控制进入上下文的内容与数量。
5. 用 recall@k / precision@k / MRR / nDCG 度量检索质量，用 接地性 (Groundedness) 度量生成质量。
6. 在「整个知识库塞进 prompt / RAG / agentic search」之间做出有依据的选型——这是官方明确给过判断标准的题。

1. 为什么需要 RAG：上下文窗口不是仓库

🎯 学习重点：必考上下文窗口是工作内存而非仓库，1M token 只改变容量边界，不消除 context rot。

Claude 的知识截止于训练数据，且不知道你的私有数据。把外部知识接入模型有三条基本路径：

1. 直接塞进上下文 (stuff the context)：知识库小 → 全部放进 prompt。
2. RAG：知识库大 → 检索相关片段放进 prompt。
3. Agentic search：给模型搜索工具，让它自己按需检索（模块 08/09 展开）。

关键事实：上下文窗口不是越大越好。官方文档明确指出：随着 token 数增长，模型的准确率与召回率会退化，这一现象被称为 context rot（上下文腐烂），因此「策展上下文中放什么」和「窗口有多大」同样重要（来源: https://platform.claude.com/docs/en/build-with-claude/context-windows，访问于 2026-08-30）。Anthropic 工程博客进一步解释：transformer 中每个 token 要 attend 所有其他 token（n² 关系），上下文越长注意力被摊得越薄；LLM 有一个有限的「注意力预算 (attention budget)」，每个新 token 都在消耗它（来源: https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents，访问于 2026-08-30）。

架构师视角：上下文窗口是工作内存 (working memory)，不是硬盘。RAG 的本质是给模型配一个「外接硬盘 + 图书管理员」，每次只把真正相关的几页搬进工作内存。

截至 2026-08-30，Claude Opus 5 / Sonnet 5 / Sonnet 4.6 等模型在 API 上拥有 1M token 上下文窗口，其余多数模型为 200k（来源: https://platform.claude.com/docs/en/build-with-claude/context-windows，访问于 2026-08-30）。窗口变大改变了「塞得下」的边界，但没有取消 context rot——这正是本模块最后「窗口 vs 检索」决策框架的物理基础。

🔪 犀利细节｜容量不等于可用注意力：窗口上限回答「能不能提交请求」，context rot 回答「模型还能不能稳定利用」。反模式是按 1M 上限把所有历史、文档和工具定义全塞满；正解是先做相关性策展，并为系统提示、会话历史和输出预留独立 token 预算。

2. RAG 全链路：一张图看懂

🎯 学习重点：考试要能按 ingest → chunk → dual index → filter → retrieve → fuse → rerank → generate/cite 顺序复原管线。

各环节一句话职责：

🔪 犀利细节｜先定位坏在哪一层：检索没命中是 recall 问题，命中但排序靠后是 ranking 问题，证据正确但答案乱编才是 generation 问题。反模式是端到端分数下降就改 prompt；正解是沿管线逐层观测候选集、排序和最终主张，避免用下游补丁掩盖上游漏检。

3. 检索三件套：Embeddings、BM25、Hybrid

🎯 学习重点：高频结论是 embedding 管语义、BM25 管精确 token、hybrid 用 rank fusion 同时保住两类召回。

3.1 嵌入向量与向量检索

嵌入向量 (Embeddings) 是把文本映射成一个高维实数向量，让「意思相近的文本在向量空间中距离近」。向量检索 (Vector Search) 就是在向量数据库里找与查询向量余弦相似度 (cosine similarity) 等度量最高的邻居（近似最近邻，ANN）。

强弱项：

• 强：语义泛化。「怎么退货」能检索到「退换货流程」，虽然没有共享关键词。
• 弱：精确匹配差。官方举例：用户查错误码 "Error code TS-999"，嵌入模型可能返回「错误码处理总论」，却错过含 TS-999 的那篇——BM25 才会命中精确字符串（来源: https://www.anthropic.com/engineering/contextual-retrieval，访问于 2026-08-30）。

选型注：Anthropic 官方 RAG cookbook 中把 Voyage AI 列为推荐的 embeddings 供应商，并提到 Gemini 嵌入在其测试中同样表现出色（来源: https://platform.claude.com/cookbook/capabilities-retrieval-augmented-generation-guide 与 https://www.anthropic.com/engineering/contextual-retrieval，访问于 2026-08-30）。

3.2 BM25：词法检索的老当益壮

BM25 (Best Matching 25) 是基于 TF-IDF 的排名函数：词在当前文档出现越多分越高（带饱和函数防止「的、了」刷分），词在整个语料越稀有权重越大，并按文档长度归一。它是稀疏/词法检索 (sparse / lexical retrieval) 的工业标准，倒排索引上毫秒级完成。

一句话分工：Embedding 管「意思像不像」，BM25 管「字面有没有」。错误码、型号 SKU、法条编号、函数名、人名——这些 token 没有语义分布可学，只能靠词法精确命中。

3.3 混合检索：官方默认姿势

混合检索 (Hybrid Retrieval) = 语义 + 词法双路召回 → 排名融合 (rank fusion) 合并去重。Anthropic 官方在 Contextual Retrieval 一文中给出的标准步骤（来源: https://www.anthropic.com/engineering/contextual-retrieval，访问于 2026-08-30）：

1. 语料切块（每块通常不超过几百 token）；
2. 为每块同时生成嵌入向量与 TF-IDF/BM25 编码；
3. BM25 取「精确匹配」Top 块，向量取「语义相似」Top 块；
4. 用 rank fusion（如 RRF, Reciprocal Rank Fusion）合并去重；
5. 取 Top-K 块进 prompt 生成。

官方实验结论：Embeddings + BM25 好于单独 embeddings；两者都做「上下文化 (contextualize)」后，Top-20 检索失败率下降 49%（5.7% → 2.9%）；再加 reranking 再降到 67% 改善（5.7% → 1.9%）（来源: 同上，访问于 2026-08-30）。

🔪 犀利细节｜融合排名，不要硬拼原始分数：向量相似度与 BM25 分数不在同一量纲，直接加权前必须校准；RRF 使用名次而非原始分数，可避开量纲不一致。反模式是看到同名 score 字段就直接相加，正解是从 rank fusion 建立稳健基线，再用金标集调融合策略。

4. 分块策略 (Chunking)：RAG 里被低估的设计

🎯 学习重点：分块题先看文档结构与答案自解释边界，再权衡块大小、边界和 overlap，不能背固定 token 数。

分块决定了「检索单元」和「拼装单元」的粒度，是 RAG 中性价比最高的调参点。官方在 Contextual Retrieval 的实现注意事项里明确：chunk size、chunk boundary、chunk overlap 都会影响检索性能（来源: https://www.anthropic.com/engineering/contextual-retrieval，访问于 2026-08-30）。

四种主流策略：

经验区间：官方流程里「每块通常不超过几百 token」（来源: https://www.anthropic.com/engineering/contextual-retrieval，访问于 2026-08-30）；官方 cookbook 用 800 token 块估算成本（同上）。块大小不是超参数玄学，而是由「一个答案需要多少上下文才能自解释」决定的。

🔪 犀利细节｜overlap 会按比例放大索引：对足够长的文档，重叠率为 r 时块数与 embedding/存储开销近似乘以 1/(1-r)；20% overlap 约是无重叠的 1.25 倍。反模式是默认高重叠掩盖坏边界；正解是优先按标题、函数、表格等结构切分，只在不可避免的边界处使用 10–20% 重叠。

4.1 分块的核心病：上下文丢失

传统 RAG 的系统性缺陷：块被切出文档后失去「它是谁」的上下文。官方例子：SEC 财报语料中，问题「ACME 公司 2023 Q2 收入增长多少？」，相关块内容是 "The company's revenue grew by 3% over the previous quarter."——这块既不含公司名也不含季度，检索器很难把它排上来，模型拿到了也无法确认归属（来源: https://www.anthropic.com/engineering/contextual-retrieval，访问于 2026-08-30）。

4.2 官方解法：上下文检索

上下文检索 = 上下文嵌入 + 上下文 BM25：索引前，用廉价模型（原文用 Claude 3 Haiku）把「整篇文档 + 当前块」喂进去，生成 50–100 token 的情境说明前缀到块上，再去做嵌入和 BM25 索引（来源: https://www.anthropic.com/engineering/contextual-retrieval，访问于 2026-08-30）：

contextualized_chunk =
  "This chunk is from an SEC filing on ACME corp's performance in Q2 2023;
   the previous quarter's revenue was $314 million."
  + "The company's revenue grew by 3% over the previous quarter."

成本上靠 prompt caching 摊薄：整篇文档进缓存一次，逐块生成前缀，官方估算 $1.02 / 百万文档 token（800 token 块假设，来源: 同上）。效果：上下文嵌入单独降低检索失败率 35%；叠加上下文 BM25 达 49%（同上）。这是「用一次性的索引期计算，换运行期检索精度」的典型架构交易。

5. 在线检索控制：Metadata Filters、Top-K、Reranking

🎯 学习重点：必须区分 pre-filter 的安全职责、Top-K 的上下文预算职责与 reranker 的精排职责。

5.1 元数据过滤

每个块入库时打上结构化元数据：{tenant, source, doc_type, updated_at, acl, product_line}。查询时先过滤再检索（pre-filter）或检索后过滤（post-filter）。它同时解决三个问题：

1. 安全：多租户隔离与权限——用户看不到的文档根本不进候选集（这是应用层强制，不是提示层请求，呼应模块 11）。
2. 新鲜度：updated_at > 政策下线日，防止已作废政策被引用。
3. 精度：问题明确指向「2024 年报」时，先砍掉其他年份的语料，检索器在更小的空间里更准。

🔪 犀利细节｜权限必须在候选集之前生效：post-filter 可能让未授权结果占满 Top-N，过滤后既召不满 K，也已经让后续 reranker 接触了不该见的数据。多租户系统应把 tenant/ACL 作为 pre-filter 强制执行；提示词里的「不要引用其他租户」没有授权效力。

5.2 Top-K：进上下文的块数

Top-K 是「给模型看几块」。官方实验：在 5 / 10 / 20 块之间，20 块效果最好——更多块提高命中概率；但块数不能无限加，「更多信息对模型是干扰」，有收益递减（来源: https://www.anthropic.com/engineering/contextual-retrieval，访问于 2026-08-30）。K 的本质是上下文预算的分配问题：K × 平均块长 + 系统提示 + 历史消息 + 预留输出 ≤ 上下文窗口，且越小越好（context rot）。

🔪 犀利细节｜把 K 写成预算公式：若沿用 cookbook 的 800-token 块和实验 Top-20，单是资料块就约 16,000 token，尚未计系统提示、历史和输出。反模式是只按命中率调大 K；正解是同时记录 K × 平均块长、recall@k、precision@k 与端到端延迟。

5.3 重排序

初始检索（双路召回）先宽进：取 Top-N（官方用 150）；重排序器（cross-encoder，把 query 与 chunk 拼在一起打相关分，如 Cohere/Voyage rerank）再严出：精排出 Top-K（官方用 20） 进 prompt（来源: https://www.anthropic.com/engineering/contextual-retrieval，访问于 2026-08-30）。

为什么双阶段？向量检索是双塔 (bi-encoder)：query 和 chunk 分别独立编码再比距离，快但粗；reranker 是 cross-encoder：把两者拼起来一起过模型，能捕捉细粒度交互，准但慢——所以只对 Top-N 做。官方明确 reranking 的收益：更好回答 + 更低成本与延迟（模型处理的无关信息更少）；代价是运行期多一跳延迟，块数越多延迟成本越高，需在自己的用例上实验平衡（来源: 同上，访问于 2026-08-30）。

宽进：Hybrid 召回 Top-150 ──reranker 精排──> 严出：Top-20 进 prompt

6. 生成与接地：Groundedness、Citations

🎯 学习重点：易错点是 groundedness ≠ accuracy；Citations 提供可追溯证据，但不能证明来源本身正确或新鲜。

检索做完只是半程。生成侧的核心概念是接地性：

• 接地/有据性：回答是否贴着给定证据——每个主张都能落到检索到的块上。可以有据但不完全正确（引用了原文，但原文本身过时），所以 grounding ≠ accuracy，两者分开评。
• 系统层面的接地设计：

1. Prompt 层：官方长文档技巧——先让模型把相关原文放进 <quotes> 再作答（模块 05 §1.2，来源: https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices，访问于 2026-08-30）。
2. API 层：Citations 功能——在 document 块上设 citations.enabled=true，Claude 回答时返回支撑每条主张的精确原文段落（cited_text 与出处指针）。官方列出的优势：引用保证指向你提供的文档（可靠性）、更可能引用最相关的段落（质量）、cited_text 不计入输出 token（省钱）（来源: https://platform.claude.com/docs/en/build-with-claude/citations，访问于 2026-08-30）。注意：请求内所有文档要么全开要么全不开 citations；当前仅支持文本引用。
3. 评估层：见 §7——groundedness 作为独立评分维度。

7. RAG 评估：先度量，再调参

🎯 学习重点：漏检看 recall@k、噪音看 precision@k、首个命中位置看 MRR、分级排序看 nDCG，生成另看 groundedness。

官方 RAG cookbook 的评估分两层：检索层（检索到的块好不好）与端到端层（最终回答对不对，用 Claude 当评分员 grading）（来源: https://platform.claude.com/cookbook/capabilities-retrieval-augmented-generation-guide，访问于 2026-08-30）。上下文检索 cookbook 用的是 Pass@k：金标块是否出现在前 k 个检索结果里，248 条带 golden chunk 的评测查询（来源: https://platform.claude.com/cookbook/capabilities-contextual-embeddings-guide，访问于 2026-08-30）。

核心指标（设相关块集合为 R，检索返回 Top-k 列表）：

直感：recall 是「查全」，precision 是「查准」，MRR/nDCG 是「排得好不好」。RAG 里 recall 优先——块没检索到，生成模型再强也变不出来；但 recall 靠加大 K 就能涨（把全库塞进去 recall=100%），所以要和 precision/nDCG 一起看，否则指标作弊。调优顺序也应该按管线因果链：先检索指标后端到端指标——检索层崩了，端到端怎么调 prompt 都没用。

官方数据作参照：其 RAG cookbook 基线跑出 Precision 0.44 / Recall 0.69 / MRR 0.865 / 端到端正确率 0.81（同一评测集，来源: https://platform.claude.com/cookbook/capabilities-retrieval-augmented-generation-guide，访问于 2026-08-30）——注意这是特定数据集的演示值，不是通用基准。

🔪 犀利细节｜单指标很容易被“作弊”：把 K 扩到全库可让 recall 接近 100%，却会摧毁 precision、token 成本和模型注意力。正解是固定预算下联合看 recall/precision/排序指标，并把 cookbook 数值只当特定数据集基线，绝不当生产 SLO。

8. 决策框架：更大上下文窗口 vs 更好检索

🎯 学习重点：先问库能否经济地全塞，再按规模、更新频率、权限、查询可预测性选择长上下文、RAG 或 agentic search。

这是模块 05 铺垫过的「第一反应」问题，官方有明确判断标准。

8.1 官方规则第一层：能不能整个塞进去

如果你的知识库小于 200,000 token（约 500 页材料），最简单的方案就是最好的：把整个知识库放进 prompt，不需要 RAG——配合 prompt caching，这个方案在延迟与成本上非常有竞争力（来源: https://www.anthropic.com/engineering/contextual-retrieval，访问于 2026-08-30）。

注意这是 2024-09 的原文阈值（当时 200k 窗口）；到 2026-08，1M 窗口模型已是默认（来源: https://platform.claude.com/docs/en/build-with-claude/context-windows，访问于 2026-08-30），「塞得下」的阈值按你所用模型的窗口等比放大，但 context rot 与注意力预算的约束仍在——塞得下 ≠ 塞得好。

8.2 决策表

Claude Code 是混合策略的官方样板：CLAUDE.md 等固定资料预先进上下文，其余靠 grep/glob 等just-in-time 工具按需拉取，规避了陈旧索引问题（来源: https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents，访问于 2026-08-30）。

8.3 一句话决策原则

「窗口够小就塞，库大就检索，查询不可预知就交给 agent，三者常常组合。」 大窗口降低了对 RAG 的*必要性*，但永远不消除 context rot——官方判断是「可预见的未来里，任何尺寸的窗口都受上下文污染与相关性问题困扰」（来源: 同上，访问于 2026-08-30）。

8.4 五路选型对比：RAG vs 长上下文 vs 工具查询 vs 数据库直查 vs 微调

§8.2 的决策表回答了「塞库 vs RAG vs agentic search」；但完整的知识接入选型还有两条常被混进来的路：工具查询 (tool query)（把数据库/API 查询作为工具交给模型，即模块 06 的 Agent → MCP → database/API 模式）与微调。五路对比如下：

依据说明：①②③ 三路见 §8.1–8.2 及模块 06；④⑤ 两列是通用工程/机器学习权衡的本仓库综述——截至 2026-08-30 本仓库未收录官方 fine-tuning 专文，Claude 平台侧微调能力以官方文档现状为准，不在此断言。

决策要点（把五路排成优先级问句）：

1. 结构化 + 精确过滤/聚合的问题（报表、状态、数值）→ ④/③：让确定性代码直查，或让模型生成受控查询（text-to-SQL / API 调用）；别用向量检索做精确聚合；
2. 非结构化知识、库塞得下（§8.1 阈值）→ ①：最简方案最好；
3. 库塞不下、查询可预测 → ②：hybrid RAG；
4. 信源异构、查询不可预知、多轮探索 → ③：agentic search（常与预取内容混合）；
5. 问题出在行为/格式/语气而非知识 → ⑤ 才进入讨论；把私有知识「烧进权重」永远是最后手段（每次知识更新都要重训）。

注意五路不互斥：生产系统常是「①固定资料 + ②大库 RAG + ③/④结构化查询」的组合（Claude Code 官方样板即 ①+③ 混合，§8.2）。③与④的分界本质上是模块 04 的「谁决定什么」问题在数据获取上的投影：Claude decides（③）还是 application decides（④）。

🔪 犀利细节｜别用向量库回答确定性聚合：库存数量、账户状态、精确求和等结构化问题应走数据库直查或受控工具查询；RAG 的相似度排序不能保证完整扫描与精确聚合。反模式是“数据都进向量库”；正解是固定资料 + 非结构化 RAG + 结构化查询的组合架构。

9. Bad vs Better 架构对比

🎯 学习重点：能把单路向量、固定硬切、无权限过滤、无 rerank/citation/eval 的玩具管线逐项升级。

Bad：玩具式单路 RAG

症状：

• 查 错误码 TS-999 / 表 SK-2201 检索不到（向量检索精确匹配弱）；
• 块切断了主语与时间（"营收增长 3%"——谁的？哪季？）；
• top-5 里混入其他租户/已过期文档（无 metadata filter）；
• 没有评估集，检索坏了只能靠用户投诉发现；
• 回答不可审计（无 citations），幻觉无从定位。

Better：生产级混合 RAG

关键改进逐条对应：混合消灭精确匹配盲区；上下文前缀消灭主语丢失；pre-filter 把安全做在检索层；rerank 把 150 收敛到 20 高信号块（省上下文预算）；citations 让每个主张可回溯；评估集让每一次「调 chunk 大小 / 换嵌入模型 / 加 reranker」都有数字背书。

10. Tradeoffs 总表

🎯 学习重点：任何质量提升都要同时核算索引成本、在线延迟、输入 token、运维复杂度和权限风险。

11. Common Mistakes（常见错误）

🎯 学习重点：重点排雷“只上向量库、固定 512 硬切、K 越大越好、groundedness 等于 accuracy、权限靠提示词”。

1. 「知识库大就无脑上向量库」：跳过了「全量塞入 + prompt caching」这个官方认可的简单方案。小库塞 prompt 常常又便宜又准。
2. 只用向量检索：错误码、SKU、函数名、条款编号这类精确 token 是向量检索的盲区，BM25 才管用（官方 TS-999 例子）。
3. 分块不看文档结构：固定 512 硬切把表格切成两半、把代码函数拦腰斩断；结构化文档应按标题/函数/表格行切并保留层级元数据。
4. 忽略块的主语丢失："增长了 3%" 没有公司名与时间就是废数据——要么结构化分块带标题链，要么上上下文前缀。
5. 把元数据过滤当可选：多租户/权限场景不过滤 = 数据泄露；且 pre-filter 还能提升检索精度。
6. K 一直往上调来「提升效果」：recall 涨是假象，块多了 context rot 和干扰成本同步涨；官方 20 块已近收益拐点。
7. 不做检索层评估，只看端到端人工感受：检索层指标崩了，调 prompt 无用；先 recall/precision/MRR，后端到端。
8. 把 groundedness 当 accuracy：有据 ≠ 正确（引用可能过时）；正确 ≠ 有据（碰巧对但无引用）。两个维度分开评。
9. 索引一建永不更新：文档更新、政策作废后索引是陈旧的；ingest 管线要有增量更新与失效机制（agentic 检索派把这一点当作 just-in-time 的优势）。
10. RAG 里做权限靠提示词：「请不要引用其他公司的文档」不是授权机制——权限必须在检索的 pre-filter 层由应用强制（呼应模块 11 的 LLM instruction ≠ application enforcement）。

12. 重要英文术语（考试可能原文出现）

🎯 学习重点：必须熟练辨析 lexical/semantic/hybrid、bi-encoder/cross-encoder、recall/precision 与 context rot/LitM。

13. 认证相关性

🎯 学习重点：认证场景题通常用错误码、多租户、陈旧政策或小知识库等信号，测试你能否选对组件而非默认 RAG。

• 「什么时候用 prompt / 更大上下文 / 更好检索」是仓库验收测试明列的问题，也是本模块 §8 的直接考点：小库塞入 + prompt caching；大库 hybrid RAG；探索型任务 agentic search。
• RAG 各组件的职责边界（谁负责精确匹配：BM25；谁负责语义：embeddings；谁负责精排：reranker；谁负责权限：metadata pre-filter）是场景选择题的高频考察方式。
• 检索指标与 groundedness：给定一组场景（漏检多 vs 噪音多 vs 排序差），选对要看的指标——recall / precision / MRR-nDCG；「回答贴证据但不正确」考 groundedness vs accuracy 的区分。
• Citations 是 Claude 平台特性级的考点：citations.enabled 的行为、cited_text 不计输出 token、全开或全不开的约束（来源: https://platform.claude.com/docs/en/build-with-claude/citations，访问于 2026-08-30）。
• 与模块 05（long context prompting、<quotes> 接地技巧）、模块 06（MCP 数据源接入）、模块 08（agentic search）、模块 12（评估）直接联动，跨模块综合题常从这些接缝出。

14. 查询改写：检索质量的另一半

🎯 学习重点：查询侧掌握改写、扩展、分解与 HyDE，并用原 query 双路召回和金标 A/B 控制改写漂移。

§2 的管线图把「用户问题 Query」当作检索起点原样使用——生产级系统常在它前面加一站：查询改写。索引侧我们花大力气做 contextual retrieval（§4.2），查询侧却放着口语化的原句不管，是常见失衡。

14.1 为什么需要：query 与文档的「形态差」

用户 query 与库内文档天然不同形态：query 口语、短、缺主语（「咋退款」），文档书面、长、主语齐全（「XX 平台退款流程说明」）。检索是在两种形态之间匹配——语义路（embeddings）能桥接一部分，但多意图、缺关键词、词汇体系不一致（用户黑话 vs 官方术语）会让 recall 在查询侧就丢掉。改写/扩展/分解的目标：把 query 变成「更接近文档形态、意图更纯粹」的检索单元。

14.2 三种基本手法 + HyDE

HyDE (Hypothetical Document Embeddings) 的原理：假设答案与真实答案文档同为「陈述句、书面语、含细节」的形态，在向量空间里用「假设文档↔真实文档」的距离替代「query↔文档」的距离，匹配更紧（来源: Gao et al., Precise Zero-Shot Dense Retrieval without Relevance Labels, https://arxiv.org/abs/2212.10496（访问于 2026-08-30））。代价：多一次 LLM 调用，且模型编造的假设答案可能把检索带偏（幻觉传导到检索层）。

14.3 架构位置与对称性

• 对称性（本仓库综合视角）：contextual retrieval（§4.2）在索引侧给块补上下文、把块变得更「可检」；查询改写在查询侧把 query 变得更「像文档」。两者解决同一个形态差问题，正交且可叠加——索引侧收益已有官方实验背书（§4.2 数据），查询侧收益需用 §7 指标自行验证；
• 成本位置：改写是检索前的轻量 LLM 步骤（小模型 + 结构化输出返回改写结果，模块 05），用延迟与成本换 recall；必须先用金标集 A/B 验证 recall@k 真的提升再全量上线——「感觉更好」不算（§7 纪律）；
• 陷阱：改写错误会传播——分解把意图拆错、HyDE 幻觉方向偏，检索会比不改写更差；「原 query + 改写 query」双路召回（类比 hybrid 思路）是稳妥起步。

🔪 犀利细节｜改写增加的是串行关键路径：HyDE 至少多一次 LLM 生成，分解还可能放大后续检索次数；收益若未体现为 recall@k 提升，就是纯延迟与成本。反模式是所有 query 强制 HyDE；正解是按口语化、多意图、词汇错配等信号触发，并保留原 query 作为召回兜底。

14.4 Bad vs Better

15. Lost in the Middle：长上下文的位置性衰减

🎯 学习重点：区分 context rot 的总量性退化与 Lost in the Middle 的位置性退化，并掌握重排、结构化、分段处理三类缓解。

§1 引入了 context rot（token 越多，准确率与召回率整体退化）。本节补它的位置维孪生兄弟：Lost in the Middle——即使 token 总量不变，信息摆放的位置也决定它被利用的程度。

15.1 现象

Liu et al.（2023）在多文档问答实验中观察到 U 形曲线：当相关信息位于上下文开头或结尾时模型表现最好，位于中部时表现系统性下降（来源: Liu et al., Lost in the Middle: How Language Models Use Long Contexts, https://arxiv.org/abs/2307.03172（访问于 2026-08-30；该文后发表于 TACL 2024））。这与官方 attention budget 的解释（§1）相互印证：注意力是有限预算，头尾位置天然占据注意力优势。

架构含义：位置是一种资源。你花 §4/§5 的功夫决定了「哪些块进上下文」，但块进去后摆在哪里，同样在影响最终质量。

15.2 三类缓解手段

1. 重排摆放 (rerank + reposition)：rerank（§5.3）之后不要无脑按检索分数顺序罗列——把最相关的块放在最前（或首尾），把「陪跑块」放中部；配合「先引用再作答」的提示结构（模块 05 §1.2 的 <quotes> 技巧）进一步锁定注意力。
2. 结构化 (structuring)：官方 long context 排布建议——长文档放 prompt 顶部、查询放末尾、多文档用 <document index> 与 <source> 标签（官方测试中查询放末尾最多带来约 30% 质量提升，来源: https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices，访问于 2026-08-30）——结构化标签与编号让模型能「定位」而非「扫描」。
3. 分段处理 (chunked processing)：与其一次塞 50 块赌模型不丢中部，不如 map-reduce 式分批处理（每批少量块抽取/摘要，再汇总）或交给多 agent 各自带独立上下文压缩（模块 08）——用工程结构消灭「中部」这个位置本身。

15.3 与本模块决策框架的连接

• §8.1「塞得下 ≠ 塞得好」的实验注脚：塞库方案的隐性成本就是 LitM——不是所有塞进去的知识都被平等对待；
• §5.3 的 rerank 因此多了一重职责：不仅筛选哪些块进上下文，还决定它们的位置分布；
• §10 tradeoffs 表「大 K：recall 高 vs context rot」应读作三维权衡：K 的大小、块的相关度、块的位置。

考试提醒（术语辨析）：LitM（位置性）与 context rot（总量性）是一对互补概念——题干说「信息在中部被忽略」指向 Lost in the Middle，「上下文越长整体退化」指向 context rot，别混。

16. 本模块文件地图

🎯 学习重点：亲跑混合检索与五种分块实验，用 hit@1、recall/precision/MRR 把设计选择变成可观察结果。