📑 本页目录（点开跳转）
08 · RAG：先搭出一个能用的
⏱ 22 分钟 ｜ ⭐ 切分和混合检索 —— 决定上限的那两步
🎯 一句话
RAG 不是「把文档塞给模型」，它是一个搜索系统：召回 → 粗排 → 精排 → 重排，和推荐系统同构。 这一页解释最小系统的选择。需要真正执行时，直接进入11b 入库实验与11c 检索实验。 ⭐ 这两步决定上限：它们没做好，后面加多少花活都救不回来。
😅 先看差距有多大
信息关系
🔗 看出来了吗：这个漏斗结构和推荐算法第 6 章的召回→粗排→精排→重排一模一样。 RAG 本质上就是一个搜索系统。 ⭐ 做过推荐或搜索的人，那套知识在这里可以直接迁移 （本站《推荐算法》讲的就是这一套）；没做过也不必绕路，这一章会把漏斗每一环都讲一遍。
🧱 环节一：切分（最被低估的一环）
关键信息
- ❌ 固定长度切分（每 500 字一刀）
- → 一句话被拦腰砍断、表格被切碎、上下文丢失
- ✅ 常用策略
- 按结构切：Markdown 标题、章节、段落 优先
- 语义切分：相邻句子语义相似度突变处下刀
- 重叠窗口：块之间重叠 10–20%，防止边界信息丢失
- 父子块：检索用小块（精准），喂给模型用大块（完整）⭐ 很好用
⭐ 上下文检索（Contextual Retrieval）
一个简单但效果显著的技巧：给每个分块补一句「它在讲什么」的上下文说明再做向量化。
对照
原始块：「该季度收入增长 3%。」
↑ 单独看：哪个公司？哪个季度？检索不到
补充后：「本段出自 ACME 公司 2024 Q2 财报，讨论季度业绩。
该季度收入增长 3%。」
↑ 现在能被「ACME 2024 收入」这样的问题检索到 ✅
在 Anthropic 的原实验中，Contextual Embeddings 使 top-20 检索失败率相对下降 35%；加 Contextual BM25 后为 49%，再加重排为 67%。这是特定数据与配置下的相对变化，不是业务保证。原始实验与条件。
额外成本是入库时生成块上下文；文档更新也要重算，并核查生成的说明有没有引入错误。
📏 块大小怎么定（一个实用的起点）
信息关系
💡 为什么"太大反而不准"值得单独说：
一个块的 embedding 是它整体语义的平均。 塞进三个不同主题，这个向量就落在三者中间的"没人区"—— 对哪个主题的问题都不够近。 这是很多人调不好 RAG 的隐形原因。
🔗 高维向量的一个反直觉陷阱
数学页的 500 维实验使用随机点，展示的是特定分布下的距离集中。学习到的文本向量不是均匀随机点，不能由这个实验推出“必须加 BM25”“必须重排”或“换 embedding 无效”。
遇到错误时先看候选集：型号混淆，比较词项检索；同义表达漏召回，检查 embedding 的语种、前缀和截断；正确资料已有但靠后，再测重排。选择依据是本地消融结果，见检索实验。
🔍 环节二：混合检索（别只用向量）
| 对照项 | 向量检索（语义） | 关键词检索 BM25（字面） |
|---|---|---|
| 优势 | ✅ 懂同义、懂意图 | ✅ 精确匹配术语、型号、人名、代码 |
| 限制 | ❌ 精确的专有名词反而不准 | ❌ 不懂同义词 |
同一个查询的结果
- 例：查「XR-2000 的功率」
- 向量检索可能找到「XR-3000 的功率」（语义相近但答案错误！）
- BM25 能精确锁定 XR-2000 ✅
起点：分别建立两路基线，验证它们是否互补，再决定是否融合。常用 RRF（倒数排名融合）——不需要分数可比，只用排名。
$$\text{RRF}(d) = \sum_{r \in \text{检索器}} \frac{1}{k + \text{rank}_r(d)}$$
💡 人话：每个文档在各路检索里的排名越靠前，得分越高，加起来排序。简单粗暴但极其有效。
🔗 和站内其他章的关系
⭐ RAG 是全导论迁移余地最大的一块，但迁移是有条件的——对上了是白赚，没对上也不影响学（它同时是门槛最低的几章之一）：
| 如果你已经知道 | 那么在这一章它对应什么 |
|---|---|
| 召回→粗排→精排→重排（推荐算法 06） | RAG 是同一个漏斗 |
| 双塔召回 + 精排交叉（推荐算法 08） | Embedding 检索 + Cross-Encoder 重排 |
| Recall@K / NDCG（推荐算法 12） | 检索侧评估直接用 |
| 向量检索 ANN（推荐算法 10） | RAG 的基础设施完全相同 |
| RAG 入门（智能体工程 11） | 那是入门，这一章是它的完整版 |
🔑 做过推荐或搜索的人，在 RAG 上等于开局领先半场——那一套搜索/排序知识至少一半可以直接用。 没做过也别绕路：上表右列就是你要学的东西本身，只是别人已经在另一个领域学过一遍而已。
✅ 检查点
- RAG 的漏斗结构和推荐系统的什么结构对应？
- 块太大为什么反而检索不准？（说出机制）
- 为什么不能用随机点的距离集中，推断所有文本向量检索都会失败？
- 混合检索可能改善哪些问题？怎样证明值得增加一路检索？
- 上下文检索（Contextual Retrieval）做了什么？效果如何？
👀 答案
- 召回→粗排→精排→重排。RAG 本质是一个搜索系统。
- 一个块的 embedding 是它整体语义的平均。塞进三个主题，向量就落在三者中间的“没人区”，对哪个主题的问题都不够近。
- 随机点实验的分布条件不同于学习到的文本向量。先检查真实失败样本和输入配置，再比较词项、向量、融合与重排，不能套固定处方。
- 向量懂语义但对精确的专有名词/型号/代码不准（可能召回 XR-3000 而不是 XR-2000）；BM25 精确匹配但不懂同义。两路融合（RRF，只用排名不用分数）互补。
- 给每个分块补一句“它在讲什么”的上下文说明再向量化，让孤立的块也能被检索到。原实验的相对下降为35%（上下文向量）、49%（再加上下文 BM25）、67%（再加重排），不能脱离基线推广。
🛑 可以停在这里
读到这里，你已经知道如何选择切分与检索策略；完成可运行项目还需要实现、评测和权限检查。先让它跑起来、先看真实的召回结果，比继续往下堆技术更重要。
⚠️ 什么时候看下一页：正确文档已经被召回了，但排得太靠后被截断 —— 那是重排该解决的事。
⚡ 走神救援
先记住这几件事
- RAG 的第一步是把正确资料检索出来，而不是一次塞入更多文档。
- 分块保留语义与来源，让孤立片段也能说明自己在讲什么。
- 向量检索与关键词检索各有盲区，可以用混合检索互补。
下一节 👉 08b-重排与Embedding选型.md