Chapter 04
前沿（带日期）：补漏斗短板，或把单次变成循环
前三章把 RAG 钉成一条 召回→精度漏斗（单次：检索→重排→生成）。这一章只收 2024–2026 仍在剧烈变动的方向，每一个都对应一个判据：它要么补漏斗的某一段短板，要么把单次漏斗变成一个循环。每条主张都带日期或版本号——前沿的保质期很短，时点本身就是信息。
本章你将建立的 schema
- 每个前沿技术钉在漏斗的哪一段：索引 / 嵌入 / 检索 / 重排 / 整条循环 / 漏斗之前
- Contextual Retrieval：在索引侧给 chunk 补回上下文（2024-09）
- GraphRAG → LazyGraphRAG：改语料结构与检索单元，攻全局/多跳（v1.0 2024-12）
- Agentic RAG：把整条漏斗包进 retrieve-评估-再决定 的控制循环（综述 2025-01）
- 视觉 / late-interaction：换嵌入单元，攻复杂 PDF 与 term-level 匹配（ColPali ICLR 2025）
- long-context vs RAG：在漏斗之前加一道按查询分流（Self-Route 2024-07）
沿用前几章的场景：公司内部问答助手，语料是员工手册 PDF。但这一章把它推到漏斗的边界——当用户不再问"住宿报销上限是多少"，而是问"总结整本手册关于差旅的所有规定"，或者干脆把手册换成几百份满是表格的扫描 PDF 时，单次漏斗会在哪一段崩，哪个前沿方向去补那一段。
本章定稿于 2026-06-02。所述版本号、发布日期、基准数字均以该时点公开资料为准。RAG 前沿迭代以月计，读到本章时若已隔半年以上，把每条的日期当成"它至少在那时成立"的下界，而非现状。下面 4.6 会用 index 页的「现状速览」三桶（稳定 / 在变 / 已被取代）把全章重新定位一次。
4.1Contextual Retrieval：在索引侧补回上下文
在嵌入和 BM25 建索引之前，给每个 chunk 前置一段 50–100 token 的「situating context」——用一句话讲清这段 chunk 在原文里属于哪、指代什么——再去嵌入与索引。
底层机制（比文档深一层）：§1.3 分块 与 §3.2 分块策略 留下一个结构性缺口——一段被切出来的 chunk 丢了它的指代与上下文。手册里"上限是 800 元"这句，脱离了"一线城市差旅住宿"的语境后，它的嵌入向量既不锐利、BM25 也对不上查询里的城市档关键词。Contextual Retrieval（Anthropic，2024-09）的做法：拿整篇文档 + 这段 chunk 喂给一个廉价模型，让它生成一句 situating context（如"本段出自《差旅管理》第 3 章，规定一线城市住宿费上限"），拼到 chunk 前面，再分别做 contextual embedding 和 contextual BM25 两路索引。成本由 prompt caching 压下来——整篇文档在缓存里只付一次费，逐段生成 context 时复用，每百万 chunk 的一次性成本约 1.02 美元（按 Anthropic 2024-09 公布口径）。
基准（检索失败率，越低越好）：仅 contextual embeddings，失败 −35%（5.7% → 3.7%，top-20）；叠加 contextual BM25，−49%；再叠加重排，−67%。三档逐级下降，恰好对应漏斗里"索引修一段、检索修一段、重排再修一段"的叠加效果。
补漏斗哪一段：索引侧。它不碰检索算法、不碰重排，只在 chunk 写进索引前把它"说清楚"。漏斗的入口质量上去了，后面每一阶的天花板随之抬高——这是为什么它和重排能叠加，而非二选一。
4.2GraphRAG → LazyGraphRAG：改语料结构与检索单元
GraphRAG（图谱增强检索）先从整个语料抽实体与关系、建一张知识图，再对图里的社区做分层摘要；查询时检索的不再是平铺的 chunk，而是图结构与社区摘要。
底层机制（比文档深一层）：平铺 chunk 检索有一类问题天生答不好——全局 / 多跳问题，例如"总结整个语料反复出现的主题""哪两个部门的政策互相冲突"。这类问题的答案不在任何单一 chunk 里，而分散在几十段、需要结构化聚合。§1.8 漏斗 的 top-k 检索只会捞回 k 段局部相关文本，拼不出全局图景。GraphRAG（Microsoft，开源 2024-07，v1.0.0 在 2024-12-11 发布）改的是检索单元的形态：用 LLM 把语料抽成「实体—关系」图，用社区检测把图切成层级化的社区，再为每个社区生成摘要；回答全局问题时直接 map-reduce 这些社区摘要，覆盖面来自图结构而非单次近邻搜索。
代价一直是建图——全量索引要对语料反复调用 LLM 抽取与摘要，成本远高于向量索引，这是它落地的主要阻碍。LazyGraphRAG（Microsoft 公布于 2024-11-25，2025 年并入 GraphRAG 主库）把这块修了：跳过昂贵的前置摘要，索引阶段只做与向量 RAG 同级的轻量处理，把图相关的 LLM 调用推迟到查询时按需做。其公布口径：索引成本约为 full GraphRAG 的 0.1%（与普通向量 RAG 持平），全局查询质量与 GraphRAG Global Search 相当。
开源 2024-07（pre-release）→ v1.0.0 2024-12-11 → LazyGraphRAG 公布 2024-11-25、2025 年进主库并进入 Azure / Microsoft Discovery 预览。判据没变：全局/多跳问题才值得上图；单点事实查询用平铺 RAG 更省。
补漏斗哪一段：改变语料结构 + 检索单元。它不是在原漏斗里换个更好的检索器，而是把"被检索的东西"从 chunk 换成图与社区摘要——漏斗的第一阶被换了底座。LazyGraphRAG 修的是这条路的成本，让判据从"全局问题 + 预算充足"放宽到"全局问题"。
用户问 "总结这 500 篇季度报告反复出现的共同主题"，朴素 RAG（向量检索 top-k → 重排 → 生成）为什么力不从心？哪个前沿方向补这个？（先停十秒）
展开答案（先自己答）
答案不落在任何单一 chunk 里，而是分散在 500 篇的几百段中、需要跨文档聚合。top-k 检索本质是"找最像查询的几段"，它捞回的是局部相关片段，无论 k 调多大都拼不出"反复出现"这种全局统计——加重排也没用，重排只在已召回的候选里重排序，召不全的东西排不出来。
对症的是 GraphRAG / LazyGraphRAG：先把语料抽成图、按社区分层摘要，全局问题走社区摘要的 map-reduce，覆盖面来自结构而非单次近邻。次选是 4.3 的 Agentic RAG，用多轮检索逐步聚合。
4.3Agentic RAG：把单次漏斗变成控制循环
Agentic RAG（智能体化检索增强）把一次性的"检索→重排→生成"换成一个 control loop：检索 → 对检索结果打分自评 → 据此决定重新检索 / 改写查询 / 直接作答 / 拒答 → 必要时再来一轮。
底层机制（比文档深一层）：前三章的漏斗是单次、开环的——检索一次，结果好坏照单全收，§3.4 失败模式 里"召回了噪声""漏了关键证据""query 表述差导致检索偏"全部直接灌进生成，无人把关。Agentic RAG 在漏斗外面加一圈反馈控制，让系统先评估自己检索得好不好、再决定下一步，而不是盲目往下走。这条路线在 2025-01 由 Singh 等人的综述（arXiv 2501.09136，提交于 2025-01-15）系统化，把几条代表性做法归到一个谱系：
| 路线 | 循环里加了什么 | 对应补的漏斗短板 |
|---|---|---|
| Self-RAG | 生成 reflection token 自反思：边检索边判断"要不要检索 / 这段证据相关吗 / 自己的输出有没有被证据支撑" | 生成侧的 grounding 失配、无谓检索 |
| CRAG（corrective） | 先给检索质量打分，差则触发 web 搜索等外部兜底，再进生成 | 检索召回不足 / 召回噪声 |
| Adaptive | 按查询难度路由：简单直答、复杂走多跳检索循环 | 对所有查询用同一套重流程的浪费 |
何时值得：多跳问题（答案要跨几段逐步推）、高风险场景（法律 / 医疗 / 金融，错答代价高，宁可多检几轮或拒答）。代价：每多一轮就多一次检索延迟和一批自评 token——把单次的"一发命中"换成"多发校准",延迟与成本同步上升。这是本章概念上最关键的一次转变：从"把漏斗调得更准"到"把漏斗放进一个会自我纠错的循环里"。
4.4视觉 / late-interaction：换嵌入与检索单元
两条线都在改"被嵌入和被检索的单元"：ColBERT 用 late interaction（延迟交互）保留 per-token 多向量，找回 dense 单向量丢掉的 term-level 匹配；ColPali 直接把渲染后的 PDF 页面图像嵌入，绕过 OCR 与版面解析。
底层机制（比文档深一层）：§2.1 讲过 dense 检索的有损瓶颈——一段文本被压成一个定长向量，term-level 的精确匹配信息在压缩中被抹平。ColBERT 的 late interaction 改了这个压法：不把文档压成单向量，而是保留每个 token 一个向量，检索时对 query 的每个 token 取与文档 token 的最大相似度再求和（MaxSim）。"延迟"指交互发生在检索打分阶段、而非编码阶段——既保住了 term-level 的细粒度匹配，又比 §2.4 cross-encoder 重排（query-doc 拼接逐词交互）便宜，因为文档向量仍可离线预算。
ColPali（arXiv 2407.01449，发表为 ICLR 2025 poster）把这套搬到视觉：复杂 PDF（带表格、图、多栏版面）走传统"OCR + 解析 + 分块"链路又长又脆，§3.4 把它列为一类典型失败。ColPali 让视觉-语言模型直接嵌入渲染后的页面图像，产出 per-patch 多向量，再用 late interaction 匹配——OCR/解析这一段被整体跳过。ColQwen2 是同族基于 Qwen2-VL 的实现，同走多向量 + late interaction 路线。
ColBERT late interaction 是更早的范式；ColPali（arXiv 2407.01449，2024-07 上传 / ICLR 2025）把它推到视觉文档检索，并随论文公开 ViDoRe 基准与模型权重。判据：语料里有大量视觉密集型文档（扫描件、表格、图表 PDF）时，ColPali 这类把"页面当图像直接嵌入"的路线，比先 OCR 再嵌入更稳。
补漏斗哪一段：嵌入 / 索引单元。ColBERT 把单向量换成多向量、找回 §2.1 丢掉的精确匹配；ColPali 把"文本 chunk"换成"页面图像"、专治 §3.4 的复杂 PDF 失败。两者都没动检索-重排-生成的骨架，只换了喂进去的最小单元。
4.5long-context vs RAG：在漏斗之前加一道分流
2024 年炒作的「RAG 已死、直接塞 1M 上下文」，到 2025–26 共识反转为：两者互补、按查询路由——在漏斗之前先判断"这条查询要不要进漏斗"。
底层机制（比文档深一层）：长上下文模型把"检索"外包给了模型自身的注意力，看似可省掉整条漏斗。但两个事实没消失：质量在约 500K token 之后下滑（context rot，Chroma 2025 在 GPT-4.1 / Claude Opus 4 / Gemini 2.5 等 18 个前沿模型上均测到逐增量退化），且 lost-in-the-middle（Liu 等 2023，arXiv 2307.03172）的 U 形注意力偏置仍在——关键证据落在上下文中段时检索准确率显著掉。一个反直觉的观察：更多上下文反而更糟——精选 48K token 的输入，F1 比全量塞 117K token 高出约 13 分。塞满 ≠ 答好。
Self-Route（arXiv 2407.16833，2024-07）给出工程化的折中：先让模型自评"靠现有检索片段能不能答"，能答就走 RAG、不能才升级到长上下文全量。其公布口径：长上下文与 RAG 的预测在超过 60% 的查询上完全一致——这部分查询用 RAG 不损质量、只省钱；整体成本相比纯长上下文降 65%（Gemini-1.5-Pro）/ 39%（GPT-4o），质量与纯长上下文持平。配套的提法是 context engineering（上下文工程，约 2025-08 成为通行术语）：把检索 + 组装 + 推理当一条流水线统一设计，RAG 与长上下文是其中两个可按查询切换的档位，而非你死我活。企业侧的落点同向——2025 年 RAG 部署不降反增（多家行业报告口径约 +280%），原因正是长上下文没能替代它、而是和它分工。
2024 上半年：「1M 上下文让 RAG 过时」。2024-07：Self-Route 给出按查询路由的量化证据。2025–26 共识：长上下文与 RAG 互补、按查询分流；context engineering 成为统一框架。判据轴：单条查询的"答案是否集中在可被检索的少数片段里"——集中则 RAG，弥散且总量可控则长上下文，难判则交给 Self-Route 这类自路由。
补漏斗哪一段：漏斗之前。它不改漏斗内部任何一阶，而是在最前面加一道分流闸——先问"这条查询要不要进漏斗"，再决定走 RAG、走长上下文、还是两者混合。
同一个模型、同一篇长文档，为什么"精选 48K token"喂进去，反而可能比"全量 117K token"答得更准？（先停十秒）
展开答案（先自己答）
因为更多上下文同时引入更多无关 token，触发两个退化：一是 context rot——输入越长、单位信息被稀释，模型在长输入上的输出质量逐增量下滑；二是 lost-in-the-middle——关键证据被埋在中段时，U 形注意力让它更难被用上。精选 48K 把信噪比拉高、把关键证据顶到模型注意力更强的位置，于是 F1 反超约 13 分。这也是 §4.5 共识"塞满 ≠ 答好""按查询路由"的直接证据。
4.6综合 + 现状速览回顾
把 4.1–4.5 钉回同一条漏斗：每个前沿不是孤立的新名词，而是落在漏斗某一段（或漏斗之外）的一块补丁。下图把它们的位置一次性标出。
用 index 页的「现状速览」三桶把全章重新定位，每条带日期：
| 桶 | 条目（带日期） |
|---|---|
| 已稳定 | retrieve-then-generate + 分块 + 向量检索（约 2023 落定）；hybrid + cross-encoder rerank（已成默认）；评估三件套 context precision / recall / faithfulness（约 2024 成型，见 第 3 章）。 |
| 在变 | 本章 4.1–4.5：Contextual Retrieval（2024-09）、GraphRAG→LazyGraphRAG（v1.0 2024-12 / Lazy 2024-11）、Agentic RAG（综述 2025-01）、视觉/late-interaction（ColPali ICLR 2025）、long-context vs RAG 路由（Self-Route 2024-07，context engineering 约 2025-08）。 |
| 已被取代 | 「RAG 已死、直接塞 1M 上下文」→ 按查询路由（2024-07 起反转）；纯固定分块 → 语义/上下文分块（见 §3.2）；纯 dense → hybrid（见 §2.1）。 |
把任何"RAG 新方法"丢进这套坐标只需问两句：它补的是漏斗哪一段（索引 / 嵌入 / 检索 / 重排 / 生成 / 漏斗之前），还是它把单次漏斗变成了循环。前者是局部增益、可与其他段叠加（Contextual + rerank 的 −67% 就是叠加）；后者是结构变更、换来纠错能力但付出延迟与 token。日期则告诉判据：这套定位至少在标注的时点成立。
§本章 self-check
先合上教程，把答案写在纸上或编辑器里。写完再点开对照——直接点开等于把这一节当再读一遍。
- Contextual Retrieval 在漏斗的哪一段动手？它给每个 chunk 加了什么、为什么这样能和重排叠加而非二选一？
- GraphRAG 把"被检索的单元"从什么换成了什么？LazyGraphRAG 修的是它的哪一个具体短板（给出量级）？
- Agentic RAG 相对单次漏斗，结构上多了什么？它把延迟和 token 换成了什么能力？
- （跨章）什么场景下你会放弃 RAG、直接用长上下文？什么场景反过来坚持 RAG？做这个决定的那条轴是什么？
答案（先做完再展开）
- 索引侧。在 chunk 嵌入与建 BM25 索引前，前置一段 50–100 token 的 situating context（讲清这段出自哪、指代什么），分两路做 contextual embedding 与 contextual BM25。它抬高的是漏斗入口质量，不碰检索算法也不碰重排，所以与重排正交可叠加——Anthropic 2024-09 口径：embeddings −35%、+BM25 −49%、+rerank −67%，逐级叠加。
- 从平铺 chunk 换成知识图 + 社区摘要（实体/关系图，分层社区摘要），攻全局/多跳问题。LazyGraphRAG（2024-11 公布）修的是建图索引成本：把前置摘要推迟到查询时，索引成本降到约 full GraphRAG 的 0.1%、与向量 RAG 持平，全局质量相当。
- 多了一圈反馈控制循环：检索后先自评（Self-RAG 的 reflection token / CRAG 的检索质量打分 / Adaptive 的难度路由），不合格则重检索、改写或拒答，合格才生成。它把单次"一发命中"换成多轮校准——付出每轮的检索延迟与自评 token，换来对多跳与高风险场景的纠错与拒答能力。
- 判据轴是"答案是否集中在可被检索的少数片段里"。集中（如单点事实、明确出处）→ RAG 更省更准，且可溯源；弥散但总量可控、或检索召不全又恰好放得进窗口 → 长上下文。难判时交给 Self-Route 这类自路由（2024-07，>60% 查询两者预测一致、成本降 65%/39%）。反例提醒：塞满 ≠ 答好——精选 48K 比全量 117K 高约 13 F1。
单点准、跨文档归纳总漏——加 rerank 没用
你的 RAG 在"单点事实查询"（报销上限是多少、某条款第几页）上很准，但凡是"跨多份文档归纳"（总结所有部门差旅政策的共性、找出互相冲突的条款）就总是漏关键面。你先加了重排，没用。问题出在漏斗哪一段？哪个前沿方向对症？
提示（卡住再展开）
重排只在已召回的候选里重排序——召不全的东西它排不出来，所以对"漏"无能为力。跨文档归纳的答案分散在多段、需要结构化聚合，单次 top-k 检索天生捞不全这种全局信息。往 4.2 的 GraphRAG / LazyGraphRAG 想（改检索单元为图 + 社区摘要，攻全局/多跳）；若问题还需多步推理与冲突比对，再叠 4.3 的 Agentic RAG（多轮检索逐步聚合 + 自评）。这不是调参问题，是漏斗第一阶的检索单元选错了。