←返回文章列表

Advanced RAG 入门:在检索前、检索时、检索后分别能做什么

RAG大语言模型AI 应用
11 分钟-阅读

基础 RAG 是一条直管子,Advanced RAG 是在管子的检索前、检索时、检索后各加几个阀门。

跑通一个最朴素的 RAG 不难——文档切片、Embedding、写入向量库、用户问题转向量、Top-K 检索、塞进 prompt、调 LLM 生成。这套链路上线一个原型可能只要一天。

上线一周后开始有用户来反馈:"你这答案对得不细""我明明问的是 A,它给我搜出了 B""有时候答得很流畅,但内容完全不对"。这时打开各种博客、论文、框架文档,会看到一堆名词扑面而来——HyDE、Multi-Query、Hybrid Search、Reranker、Contextual Retrieval ...... 它们都自称在做"Advanced RAG",但彼此关系不清楚。

Gao 等人 2023 年 12 月那篇 RAG 综述(arXiv:2312.10997)提供了一套合用的分类——把朴素 RAG 想成一条直管子,Advanced RAG 就是在管子的检索前、检索时、检索后各加几个阀门。所有那些花里胡哨的技术,都落在这三段中的某一段。

本文按这个三段框架走一遍。每段挑两到三个主流方法,每个方法只讲机制和一个例子,不讲原理推导。读完应该能在脑子里建出一张地图——下次再听到某个新名词,至少知道它属于哪一段。

三段是什么

先看图。

图 1:Advanced RAG 的三段式架构

flowchart TD
  Q[用户问题] --> Pre[检索前 Pre-retrieval<br/>改写问题, 改写索引]
  Pre --> R[检索时 Retrieval<br/>用什么策略找]
  R --> Post[检索后 Post-retrieval<br/>对召回结果再加工]
  Post --> LLM[LLM 生成]
  LLM --> A[答案]

每一段解决的核心问题不同:

阶段 核心问题 主要方向
检索前 用户问的问题适不适合直接拿去检索? Query 改写、HyDE、Multi-Query、Step-Back
检索时 找文档用什么策略最稳? Hybrid Search、Small-to-Big、Sentence Window
检索后 召回的东西怎么用得更好? Rerank、压缩、Contextual Retrieval

每段都可以独立加补丁,也可以叠加使用。下面逐个看。

检索前:让 query 在进库之前先变好

用户提问的方式和文档的表达方式经常对不上。一个用户问 "拆封过的耳机能退吗",文档里写的可能是 "已开封电子设备退货政策"。基础 RAG 直接拿用户原话去 embedding,召回偏掉的概率不小。检索前这一段做的事就是——在 query 进库之前先用 LLM 把它改写得更接近文档的表达方式。

HyDE:先生成一个假答案再用它检索

HyDE(Hypothetical Document Embeddings)来自 Luyu Gao 等人 2022 年 12 月的论文(arXiv:2212.10496)。机制非常反直觉但有效——用 LLM 根据问题先编一段"理想答案"(哪怕是假的、不准的也行),再拿这段假答案去做 embedding 检索。

直觉是这样:用户那句短问题和库里的完整文档段落,在向量空间里距离天然就远;让 LLM 先把问题展开成一段像答案的文本,这段文本和真实文档在风格、长度、术语上更接近,命中率更高。

例子:

用户问题: 极光是怎么形成的?
HyDE 生成: 极光是太阳风带电粒子与地球磁层相互作用产生的。
          带电粒子被地磁场引导到极地大气层, 与氧、氮分子碰撞激发出可见光...
真实检索: 用上面那段假答案做 embedding, 而不是用原问题

HyDE 的代价是多一次 LLM 调用。但在专业领域(医学、法律、技术文档)召回提升通常很明显。

Multi-Query:把一个问题改写成几个变体

Multi-Query 在 LangChain 里实现为 MultiQueryRetriever,是另一种思路——一个问题可能有多种表达方式,与其赌一个 query 命中,不如让 LLM 生成 3–5 个语义相近的变体,分别检索后取并集去重。

例子:

原问题: RAG 怎么减少幻觉?
变体 1: 检索增强生成是如何降低大模型胡说的?
变体 2: 把外部文档塞进上下文能不能让回答更准确?
变体 3: RAG 在事实性问题上比纯 LLM 强在哪?

每个变体独立检索,召回结果做去重合并,最后送给 LLM。

Multi-Query 的好处是对原问题没有破坏性——即使变体写得不好,原问题那一路仍然在跑,最差情况就是退化成基础 RAG。

Step-Back:先抽象再回到具体

Step-Back Prompting 来自 Google DeepMind 2023 年 10 月的论文(arXiv:2310.06117)。机制是先让 LLM 把具体问题"退一步"抽象成更高层的概念性问题,用这个高层 query 检索背景知识,再回答原问题。

例子:

原问题: Estella Leopold 在 1954 年 8 月到 11 月去了哪所学校?
Step-back 问题: Estella Leopold 的教育经历是什么?
真实检索: 用高层问题去检索, 拿到她完整的教育时间线, 再回答具体年份

Step-Back 特别适合细节型问题——具体年份、具体条款、具体配置——直接检索容易因为时间字眼或编号字眼跑偏,先检索背景知识反而更稳。

这一段总结

检索前三种方法的对照:

方法 适用 代价
HyDE 用户问题简短、文档篇幅长、术语差距大 多一次 LLM 调用
Multi-Query 用户表达多样、单 query 易漏 N 次检索, N 倍向量库压力
Step-Back 细节型问题、问题字眼会误导 多一次 LLM 调用

入门阶段先上 Multi-Query 最稳——风险低、好理解、对原问题没破坏性。

检索时:用什么策略找

检索时这一段不改 query,改的是检索机制本身。

Hybrid Search:稠密 + 稀疏一起用

基础 RAG 用的是稠密检索(dense retrieval)——一个 embedding 向量算余弦距离。稠密检索擅长抓"意思相近",但对精确字眼不敏感——你问 "错误码 413",dense 可能召回一堆"上传失败"的文档,但偏偏漏掉那段真的写着 "413" 的。

Hybrid Search 把稠密检索和稀疏检索(BM25 这类基于词频的传统算法)放在一起。BM25 抓精确字眼,dense 抓语义意图,两路检索结果用 Reciprocal Rank Fusion (RRF) 合并——这个算法来自 Cormack 等人 2009 年的论文,公式简单:

score(d) = Σ 1 / (k + rank_i(d))

rank_i 是文档 d 在第 i 路检索中的排名,k 经验值取 60。一个文档在两路都排名靠前就会得到高分。

Microsoft 在 2024 年的 Azure AI Search 测试里反复印证一件事:hybrid + reranker 在他们客户基准上一致优于 dense-only。Pinecone、Elastic、Weaviate 等向量库也都默认推荐 hybrid。

Hybrid 的工程代价不大——绝大多数向量库(Qdrant、Weaviate、Milvus、pgvector)都原生支持 BM25 + dense + RRF。入门阶段如果只能加一项 retrieval-time 改造,应该是这个。

Small-to-Big:小块检索,大块回答

基础 RAG 有个绕不开的矛盾——embedding 喜欢短文本(主题集中、相似度更准),但 LLM 回答需要长上下文(有前后文、有定义、有例外)。

Small-to-Big 这套思路把这两件事拆开:索引时按小块切分(句子级、段落级),检索精度高;返回时回到包含小块的父块(章节级),给 LLM 更多上下文。

具体实现:

  • LangChain ParentDocumentRetriever:把文档按"大块 + 子块"两层切,子块写进向量库,父块单独存。检索命中子块后返回父块文本。
  • LlamaIndex HierarchicalNodeParser + AutoMergingRetriever:树状切分,子块到一定密度时自动合并到父节点。

例子:

用户问: SSO 登录失败先检查什么?
检索单元(子块): "先检查 IdP 元数据是否过期"
返回上下文(父块): 整段 "SSO 登录失败排查" 章节, 含 IdP 定义、SAML 流程、5 个常见错误

光给 LLM 那一句小块,它不知道 IdP 是什么;连同父块整段一起给,回答就完整了。

Sentence Window:固定窗口扩展

Sentence Window 和 Small-to-Big 经常被混在一起说,但机制不同。

  • Small-to-Big / Parent Document:扩展依赖文档结构上的父节点——章节、条款、Markdown 标题。
  • Sentence Window:以单句为检索单元,扩展是机械窗口——命中句的前后 N 句(不依赖结构)。

LlamaIndex 的 SentenceWindowNodeParser 默认窗口是前后各 3 句。文档结构平坦、靠句子粒度命中时选它;文档有清晰层级时选 Small-to-Big。

检索后:对召回结果再加工

检索完拿到 top-K(一般 10–30 条)。Top-K 不是直接喂给 LLM——这里面通常有重复、有相关度排序错乱、有冗余 token。检索后这一段做的就是"再加工"。

Cross-encoder Reranker:让 query 和 doc 互相看见

基础 RAG 的检索阶段是 bi-encoder——query 和 doc 各自独立 embedding,再算向量距离。这种方式快,但精度有限,因为 query 和 doc 在表示阶段从来没见过对方。

Cross-encoder reranker 反过来——把 [query, doc] 拼成一段输入送进一个专门的模型,让 query 和 doc 在每一层 attention 里互相看见,输出一个相关性分数。精度比 bi-encoder 高,但慢得多。所以工业实践是:

bi-encoder 召回 top-50 (粗排, 快)
       ↓
cross-encoder rerank 选 top-5 (精排, 慢)
       ↓
喂给 LLM

主流可选:

  • Cohere Rerank 3(2024-04):闭源 API,多语言效果好
  • BGE Reranker v2-m3(BAAI 2024):开源、可本地部署、中英双语强
  • bge-reranker-large(BAAI 2023):更轻量的开源版本

Reranker 是 advanced RAG 里性价比最高的一层——加上后,召回正确率提升经常以两位数百分比计算,工程代价是一次额外推理调用。

Contextual Compression:剔除冗余 token

检索回来的几段文档可能有大量和 query 无关的句子——一段 1000 token 的文档里真正回答问题的可能只有两句话。把整段塞进 prompt 既浪费 token 也容易让 LLM 抓不住重点。

Contextual Compression 用一个小模型按 token 重要性压缩检索结果。最有名的是 Microsoft 2023 年 10 月的 LongLLMLingua(arXiv:2310.06839),EMNLP 2024 收录。在它的 NaturalQuestions 实验里,4 倍压缩率下性能反而有提升——剔除冗余 token 让 LLM 的注意力更集中。

LangChain 里的 ContextualCompressionRetriever 实现了类似思路,用 LLM 抽取式压缩,门槛更低。

Anthropic Contextual Retrieval:索引时就把上下文写进 chunk

2024 年 9 月 19 日 Anthropic 发布的 Contextual Retrieval 同时改造了索引和检索两端,是这一年最被讨论的 advanced RAG 技术之一。

机制:索引时用 Claude 为每个 chunk 基于整篇文档生成一段 50–100 token 的位置和主题上下文,prepend 到 chunk 上再做 embedding 和 BM25 索引。

例子:

原 chunk: 该限制不适用于企业版。
contextualized chunk:
  本节讨论 API 调用频率限制, 说明不同套餐的限流规则。
  该限制不适用于企业版。

后者在脱离原文后仍然带有主题和位置信息,检索效果显著提升。Anthropic 在官方实验里给出的三组数字(top-20 检索失败率相对降低):

配置 失败率下降
Contextual Embeddings 单独 35%
Contextual Embeddings + Contextual BM25 49%
上述 + Reranker 67%

最后那 67% 是入门 advanced RAG 一个很好的目标——三项叠加,把基础 RAG 的检索失败率打掉三分之二。

Contextual Retrieval 的代价是离线索引时多一次 LLM 调用,但 Anthropic 推荐配合 prompt caching 用,把成本压到可接受。

三段怎么叠起来:一张完整图

三段是正交的,真实生产系统常常叠加。下面是入门可以直接照抄的一套组合。

图 2:一套入门级的 Advanced RAG 完整链路

flowchart TD
  Q[用户问题] --> MQ[Multi-Query<br/>LLM 生成 3 个变体]
  MQ --> Hybrid[Hybrid Search<br/>BM25 + Dense + RRF]
  Hybrid --> Expand[Small-to-Big<br/>子块命中, 返回父块]
  Expand --> RR[Cross-encoder Reranker<br/>选 top-5]
  RR --> Prompt[组装 Prompt]
  Prompt --> LLM[LLM 生成]
  LLM --> Ans[答案 + 引用]

  subgraph 离线一次性做的事
    Doc[文档库] --> Ctx[为每个 chunk 生成上下文<br/>Anthropic Contextual]
    Ctx --> Idx[(向量库 + BM25)]
  end
  Idx -.被检索.-> Hybrid

这套配置在工程上的特点:

  • Pre-retrieval:Multi-Query,最便宜也最稳的 query 改造
  • Index-time:Anthropic Contextual Retrieval,离线一次成本,长期受益
  • Retrieval:Hybrid + Small-to-Big,覆盖语义和精确字眼
  • Post-retrieval:Cross-encoder reranker,把召回质量推到 top-5 可用水平

如果不想一次性全上,性价比排序是这样:

  1. Reranker(先上这个,加一次 API 调用换两位数百分比的召回率提升)
  2. Hybrid Search(向量库基本都原生支持,工程代价小)
  3. Anthropic Contextual Retrieval(如果文档库稳定、离线索引可控,收益最大的一项)
  4. Multi-Query / HyDE / Step-Back(query 改写视具体语料效果差异大,最后调)

一句话区分 Advanced RAG 和 Modular RAG

读到这里可能会问:那 Gao 综述里说的 Modular RAG 是什么?

一句话——Advanced RAG 是在一条线性 pipeline 上的三段加阀门;Modular RAG 是把 pipeline 拆成可插拔模块,允许迭代、循环、自适应。Self-RAG、CRAG、Adaptive-RAG 这些"让模型自己决定要不要再检索"的方案,都属于 Modular RAG 的范畴。

入门阶段不用深究——把 Advanced RAG 的三段先各加一两个阀门,效果通常已经能上一个台阶。Modular 是下一站。

小结

Advanced RAG 不是某个新算法,是一组可以叠加的工程补丁。把它按"检索前 / 检索时 / 检索后"分成三段,每段挑性价比最高的一两个先加,比追"最新论文"更能解决你的 RAG 实际问题。

附录:RAG 技术演化树名词对照

Gao et al. 2024 综述里那棵著名的 "Retrieval-Augmented Generation" 树状图,按 Pre-training / Fine-tuning / Inference 三个分支把 70 多种 RAG 相关方法一次列了出来。下面这张对照表给出每个缩写的全称和一句中文释义。标 (?) 的项在综述里只在图上引用、正文未展开释义,按字面 + 上下文做了最贴近的中文表述,使用时请回查原文确认。

入门读者不用全记。下表里标 * 的几个是和正文论点直接相关、或者是实战里最常碰到的:GenRead(HyDE 同源)、RePlug、IRCoT、ITER-RETGEN、Recomp、Self-RAG、CRAG、RAPTOR——掌握这 8 个已经覆盖了 80% 的实战场景。

Pre-training 分支(预训练阶段融入检索)

缩写 全称 / 出处 一句说明
CoG Copy-Generator (Lan et al., ICLR 2023) 把"生成下一个 token"改成"从训练语料里复制一段"
Retro++ Retrieval-Enhanced Transformer 改进版 (Wang et al., 2023) 在 DeepMind 原版 Retro 基础上加入指令微调能力
TIGER 生成式检索 / 推荐方向(?) 把检索目标做成可学习的 token 序列
RAVEN Retrieval-Augmented Encoder-Decoder 编码-解码架构里把检索作为前置 token 流融入
InstructRetro Instruction-tuned Retro (Wang et al., NVIDIA, 2024) 在 Retro 上做指令微调,让大模型学会用检索结果

Fine-tuning 分支(在微调阶段把检索能力训进去)

缩写 全称 / 出处 一句说明
RAG Retrieval-Augmented Generation (Lewis et al., NeurIPS 2020) RAG 开山论文,DPR 检索器 + BART 生成器联合训练
RAG-e2e End-to-end RAG 检索器和生成器端到端一起训
PROMPTAGATOR Few-shot Dense Retrieval From 8 Examples (Dai et al., Google, 2022) 用 LLM 从少量样例生成训练数据来微调检索器
Atlas Few-shot Retrieval-Augmented LM (Izacard et al., Meta, 2022) Meta 的 few-shot 检索增强模型
Zemi Zero-shot Multi-task Inference (?) 用检索辅助零样本多任务推理
R-GQA Retrieval-augmented Generative QA 检索增强的生成式问答
UPRISE Universal Prompt Retrieval for Improving Zero-shot Evaluation (Cheng et al., 2023) 通用 prompt 检索器,提升零样本表现
Self-Mem Self-Memory Augmented Generation (Cheng et al., 2023) 把模型自己之前的输出作为检索源
RRR Rewrite-Retrieve-Read (Ma et al., 2023) 先让 LLM 改写 query,再检索再读
AAR Augmentation-Adapted Retriever (Yu et al., 2023) 让检索器适配下游 LLM 的偏好
SUGRE Subgraph Retrieval Enhanced (?) 在子图层面做检索增强
SANTA Structure-Aware Dense Retrieval (?) 在密集检索里考虑结构化信息
Retrieve-and-Sample 检索后采样 在 top-K 之后做策略性采样而不是直接取头部
FLARE Forward-Looking Active REtrieval (Jiang et al., 2023) 生成时主动发起检索,"边写边查"
RA-DIT Retrieval-Augmented Dual Instruction Tuning (Lin et al., Meta, 2023) 检索器和 LLM 双向指令微调
LM-Indexer 把 LM 当索引器 LLM 直接预测文档 ID 而非走向量检索
Self-RAG * Self-Reflective RAG (Asai et al., 2023) 训练模型生成时输出 reflection token,决定是否检索
RAG_Robust Robust RAG 对噪声 / 反事实 / 错误检索结果鲁棒的 RAG
MK-ToD Multi-Knowledge Task-oriented Dialog 任务型对话中融合多源知识检索
RAST Retrieval-Augmented Self-Training (?) 用检索结果做自训练
Dual-Feedback-ToD 双反馈任务对话 任务型对话中引入双向反馈信号
EAR Expand-then-Answer / Embedding-Augmented Retrieval (?) 先扩展 query 再回答
BEQ Better Embedding for QA (?) 改进 QA 场景下的 embedding
CoN Chain-of-Note (Yu et al., 2023) 让 LLM 为每个检索片段先写一段笔记再综合
CT-RAG Contrastive Training RAG (?) 对比学习训练的 RAG
UniMS-RAG Unified Multi-Source RAG 统一多源(向量库、SQL、图谱)检索的 RAG

Inference 分支(推理时加检索,最大的一族)

缩写 全称 / 出处 一句说明
RECITE Recitation-Augmented LM (Sun et al., 2022) 让模型"背诵"训练时见过的相关段落再回答
GenRead * Generate-then-Read (Yu et al., 2022) 用 LLM 生成"上下文文档"再当检索结果用,HyDE 的近亲
DSP Demonstrate-Search-Predict (Khattab et al., Stanford, 2022) 把 RAG 工作流抽象成可编程的"示范-搜索-预测"模块
RePlug * Retrieve-and-Plug (Shi et al., 2023) 把检索器外挂到任意黑盒 LLM 上,不动模型权重
ICRALM In-Context Retrieval-Augmented LM (Ram et al., 2023) 把检索结果直接拼进 in-context prompt
Filter-Reranker 过滤 + 重排 检索后先过滤明显无关,再用 reranker 精排
LLM-IE LLM-based Information Extraction 用检索辅助大模型做信息抽取
SCM4LLMs Self-Controlled Memory for LLMs (?) 让 LLM 自主管理长期记忆
PKG Parametric Knowledge Guiding (Luo et al., 2023) 用一个"领域小模型"引导大模型使用参数知识
COQ Chain-of-Question (?) 链式提问扩展检索
ITER-RETGEN * Iterative Retrieve-Generate (Shao et al., 2023) 检索 → 生成 → 拿生成结果再检索,反复迭代
LLM-R LLM-based Retriever 让大模型直接担任检索器
IRCoT * Interleaving Retrieval with CoT (Trivedi et al., 2022) 思维链每一步穿插一次检索
KnowledGPT Knowledge + GPT 在 GPT 推理时接入知识图谱
KGP Knowledge Graph Prompting 用知识图谱做 prompt 增强
ITRG Iterative Retrieval-Generation 迭代式的检索-生成循环
Recomp * Retrieval Compression (Xu et al., 2023) 用小模型压缩检索回来的长 context
SKR Self-Knowledge Retrieval (Wang et al., 2023) 让 LLM 先判断"自己知不知道",知道就不检索
KALMV Knowledge-Augmented LM Verification (?) 检索结果用于校验 LLM 输出
QLM-Doc-ranking Query Likelihood Model 文档排序 用 query 似然度对召回文档排序
FABULA (?) 故事生成或叙事增强 RAG 长篇叙事场景的检索增强
Token-Elimination Token 级裁剪 在 token 粒度剔除检索结果里的冗余
ToC Tree of Clarifications (Kim et al., 2023) 用一棵"澄清问题树"探索歧义 query
1-PAGER One-Pass Generative Retrieval (?) 单次推理完成"检索 + 生成"两件事
PRCA Pluggable Reward-driven Contextual Adapter (?) 可插拔的奖励驱动上下文适配
ARM-RAG Auxiliary Rationale Memory RAG (?) 把推理过程的中间结论存为可检索单元
CREA-ICL Creative In-Context Learning (?) 用检索增强做创造性 ICL
DRAGON-AI Diverse Retrieval-Augmented Generation (?) 多样化检索增强
PaperQA 论文问答系统 (Lála et al., 2023) 专门针对学术论文的 RAG 系统
FILCO Filter Context (Wang et al., 2023) 过滤检索结果里跟问题无关的内容
HyKGE Hybrid Knowledge Graph Enhanced 混合知识图谱增强的检索
IAG Iterative Augmented Generation 迭代式增强生成
BGM Bridging the Gap Model (Ke et al., 2024) 弥合检索器和生成器之间偏好差异
RAPTOR * Recursive Abstractive Processing for Tree-Organized Retrieval (Sarthi et al., Stanford, 2024) 递归地把文档摘要成多层树,按层级检索
CRAG * Corrective RAG (Yan et al., 2024) 检索后加评价器判断结果好坏,差就重检或改走网络搜索
RADA Retrieval-Augmented Decision Agent (?) 检索增强的决策智能体
G-Retriever Graph Retriever (He et al., 2024) 在图结构数据上做检索增强

参考资料

YL

我是姚磊

大模型应用开发者,关注 RAG、Agent 和产品化工程。沉淀实践中的判断、踩坑记录和可复用方法。联系我:yaolei_agent@163.com

LLM AppsRAGProductEngineering Notes