高级 RAG
评估暴露出来的问题，就是进阶方案要解决的对象：上下文缺失导致召回失败，上 Contextual Retrieval；跨文档关系型问题答不好，上 GraphRAG；多步推理和检索决策复杂，上 Agentic RAG。先有度量，再谈方案。
Contextual Retrieval：解决块缺少上下文
分块最大的副作用是上下文缺失：一个块脱离文档后，指代、术语定义、所属章节全丢了，检索时匹配到但模型理解不了。Anthropic 2024 年的方案：嵌入前用 LLM 给每个块补一段上下文。
做法：把“整个文档的标题 + 块前面的内容 + 块本身”交给 LLM，让它生成 50 到 100 token 的块上下文说明，拼在块前面再嵌入。同样的上下文也用于建 BM25 索引（Contextual BM25）。
实测数字：Contextual Embeddings 把 Top-20 检索失败率降低 35%（5.7% 到 3.7%）；叠加 Contextual BM25 降低 49%（5.7% 到 2.9%）。成本用 Prompt Caching 摊薄，因为每个块补上下文用的是同一个文档前缀。
GraphRAG：解决跨文档的关系型问题
向量检索擅长找相似片段，不擅长回答“这些实体之间什么关系”这类需要全局视角的问题。GraphRAG 的思路：索引阶段用 LLM 抽取实体和关系构建知识图谱，社区检测（Leiden 算法）划分社区并生成社区摘要；查询阶段按需做全局或局部检索，从社区摘要里综合答案。
适合多文档语料、需要全局总结和关系推理的场景，代价是索引成本高（每个块都要过 LLM 做实体抽取），小知识库不值得。
Agentic RAG：解决检索决策
传统 RAG 的流程是固定的：每次都检索、每次都生成。Agentic RAG 把决策权交给 Agent：要不要检索、查哪个数据源、检索结果够不够、要不要再查一次、还是直接回答。
典型形态是自适应路由：查询先进分类器，简单事实性问题走 Naive/Advanced RAG（快、便宜），复杂多跳推理走 Agentic 循环，关系型问题走 GraphRAG，无需检索的直接 LLM 回答。让简单查询走快速通道，复杂查询获得充分推理资源。
自适应 RAG 路由
面试追问
- Contextual Retrieval 解决什么？ 块脱离文档后的上下文缺失：指代、术语定义、章节归属。嵌入前用 LLM 补 50-100 token 上下文，Top-20 失败率降 49%
- GraphRAG 什么时候值得上？ 跨文档、需要全局视角和关系推理的问题。代价是索引成本高，小知识库不划算
- Agentic RAG 和普通 RAG 的区别？ 普通 RAG 流程固定，每次都检索生成；Agentic RAG 由模型决定何时检索、查什么、结果够不够、要不要再查
- 为什么用自适应路由？ 不同查询的复杂度差异大，统一走复杂链路浪费成本和延迟。简单走快通道，复杂走 Agentic，各取所需
- 高级方案怎么选？ 从评估数据出发：上下文缺失上 Contextual Retrieval，关系问题上 GraphRAG，多步决策上 Agentic。没有银弹，按问题选方案