Advanced RAG 入门:在检索前、检索时、检索后分别能做什么
基础 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 可用水平
如果不想一次性全上,性价比排序是这样:
- Reranker(先上这个,加一次 API 调用换两位数百分比的召回率提升)
- Hybrid Search(向量库基本都原生支持,工程代价小)
- Anthropic Contextual Retrieval(如果文档库稳定、离线索引可控,收益最大的一项)
- 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) | 在图结构数据上做检索增强 |
参考资料
- Yunfan Gao et al., "Retrieval-Augmented Generation for Large Language Models: A Survey," 2023. https://arxiv.org/abs/2312.10997
- Luyu Gao et al., "Precise Zero-Shot Dense Retrieval without Relevance Labels" (HyDE), 2022. https://arxiv.org/abs/2212.10496
- Huaixiu Steven Zheng et al., "Take a Step Back: Evoking Reasoning via Abstraction in Large Language Models," 2023. https://arxiv.org/abs/2310.06117
- Cormack, Clarke, Büttcher, "Reciprocal Rank Fusion outranks Condorcet and individual Rank Learning Methods," SIGIR 2009.
- Huiqiang Jiang et al., "LongLLMLingua: Accelerating and Enhancing LLMs in Long Context Scenarios via Prompt Compression," EMNLP 2024. https://arxiv.org/abs/2310.06839
- Anthropic, "Introducing Contextual Retrieval," September 19, 2024. https://www.anthropic.com/news/contextual-retrieval
- Microsoft Azure AI Search, "Outperforming vector search with hybrid retrieval and reranking," 2024. https://techcommunity.microsoft.com/blog/azure-ai-services-blog/azure-ai-search-outperforming-vector-search-with-hybrid-retrieval-and-reranking/3929167
- LangChain Docs, "MultiQueryRetriever." https://python.langchain.com/docs/how_to/MultiQueryRetriever/
- LangChain Docs, "ParentDocumentRetriever." https://python.langchain.com/docs/how_to/parent_document_retriever/
- LlamaIndex Docs, "Sentence Window Retrieval." https://docs.llamaindex.ai/en/stable/examples/node_postprocessor/MetadataReplacementDemo/
- Cohere, "Rerank 3," April 2024. https://cohere.com/blog/rerank-3
- BAAI, "bge-reranker-v2-m3." https://huggingface.co/BAAI/bge-reranker-v2-m3
我是姚磊
大模型应用开发者,关注 RAG、Agent 和产品化工程。沉淀实践中的判断、踩坑记录和可复用方法。联系我:yaolei_agent@163.com



