RAG Improvements - Retrieval

在 RAG 架构中，检索（Retrieval）作为第一步，其质量直接决定生成上限。

传统 RAG 依赖向量检索，而用户 Query 的复杂，模糊，多变，使得单一检索往往存在 “盲区”。

作为业界共识 GIGO “Garbage in, garbage out”，不仅要关注数据和索引质量，检索质量同样是关键变量。

🔍 聚焦 RAG 检索阶段的几种主流优化策略：从 “找到” 到 “找对”。

TL;DR

优化 RAG 检索的本质是构建一个聪明的 “图书馆长”。他能根据不同场景和意图智能路由检索路径。

• 🤔 HyDE | 面对读者模糊的问题，他会根据经验先行预判和脑补你的想法。
• 🌊 Hybrid Search | 找书时双管齐下，既看字面意思，也懂言外之意。
• 🧐 Rerank | 面对一堆候选书，再次精挑细选。
• 🔗 Multi-hop | 遇到难题还会多走几步路，顺藤摸瓜。

Hybrid Search

👉 混合检索（HyBrid Search）：各取所长，互补短板

典型组合：向量检索抓取语义意图，关键词检索锁定精确细节

• 向量检索（Embedding）-> 补语义理解
  高维语义空间，能理解同义词、指代和模糊意图
• 关键词检索（BM25）-> 补不漏关键字
  基于词频和逆文档频率，能确保精确匹配的关键字和专有名词

Document Case

商品支持7天退款。订单状态包括：pending（发货中）、success（成功）、failed（支付失败）

Query 1：“多久能退？”

• ✅ 向量检索：理解 “多久” 与【时间， 有效期， x 天】相关
• ❌ BM25: MISS

Query 2：“FAILED 是啥意思”

• ⚠️ 向量检索：Token 很奇怪，可能检索不到
• ✅ BM25：精确命中

双路检索后如何合并？

BM25 排前面的 ≠ 向量检索排前面的，最终结果不能简单相加。

1）加权融合（简单）

score = α * bm25_score + β * vector_score
- e.g. α = 0.4, β = 0.6

缺点是不同模型的分数尺度难以归一化，可能需要反复调参。

2）多检索融合算法 RRF

RRF（Reciprocal Rank Fusion）：倒数排名融合

核心思想：“英雄所见略同”，“大家都认可的才是真的好”

• 不关心原始分数（Score），只关心文档在各自路中的排名（Rank）
• 多路检索共同认可的文档，最终排名一定会靠前。
• 相较加权融合更加稳定，

RRF 的核心公式为：

score = 1/(k + rank)
- k: 常用 60，越小表示更看重前几名，越大者排名差异被拉平

根据公式参数可以看出：

• 排名越靠前 -> 分数越高
• 多个检索方式都觉得好的 -> 最终一定分高

HyDE

HyDE（Hypothetical Document Embedding）

👉 核心思想：“问题找答案” --> “虚拟答案找答案”

与其直接用用户模糊的问题去搜索，不如先让大模型根据 query 编一个‘可能的答案’，再用这个答案去做向量检索”。

Why need it ?

1）传统 RAG 链路：用户问题 -> embedding -> 检索

当问题太短 / 太模糊，以及 embedding 向量表达能力本身限制 --> 结果：召回不准确。

2）HyDE 链路： 用户问题 -> LLM 生成一个 “假设答案” --> embedding(对假设答案) --> 检索

本质不是为了去 “生成答案”，而是生成一个包含更多特征，更容易被 embedding 理解的语义载体。

Case：query = “退款多久”

• 传统 RAG：这种语义不太完整的 case 即使结合 Hybrid（“退款”， “多久”）召回信息也很难全面。

• HyDE

  1. LLM 先生成假设答案 “一般退款会在7个工作日内完成，具体取决于支付方式和平台政策。”
  2. embedding 时，向量就包含了 【“退款”， “时间”， “平台政策”】 等丰富特征，从而提高检索范围。

HyDE 最佳实践

• 长度控制：50 ～ 150 tokens，太长导致噪音 ↑，embedding 偏移

• 不能纯瞎编：Prompt 约束

  text

  Copy

  请根据问题生成一个可能出现在知识库中的答案，要求：
  - 客观、中立。
  - 信息密度高，包含关键概念和术语。
  - 不要编造任何具体的数据、人名或日期。

• 融合策略：不要完全丢弃原始 Query，query embedding + HyDE embedding 一起检索（merge / rerank），避免 HyDE 偏了 -> 全盘偏

Rerank

👉 从 “全” 到 “准”：把已经召回的一堆候选，再精排一次，挑最相关。

当作 RAG 召回后的补充阶段。

• Retrieval（召回阶段）：目标”全” - 尽量不漏。
• Rerank（精排阶段）：目标是”准” - 选最相关。

Retrieval 阶段无论是向量 还是 BM25，本质都是在比索引 “相似度”，而非真正的“相关性”，没有真正理解 “问题 - 答案的关系”。

👉 Rerank 就是补充这一点：通过模型判断相关性（这个 doc 能不能回答这个 query？），而不是相似度。

如何去做？

1. 专用 Reranker 模型（主流方案）
2. LLM 大语言模型：更贵更慢，但灵活（体现在可以加业务规则，例如去掉不合规的）做一些 reranker 不懂， LLM 懂的事

Multi-hop RAG

👉 多跳信息检索增强生成 --> 让 AI 更深入思考

“单跳” 到 “多跳”
传统 RAG 在问题检索时通常只进行一次检索（单跳），这种方式适用于那些可以在当个文档或数据块中找到的简单问题。

但某些问题，例如 “2020 年 NBA 总决赛 MVP 离开湖人队后加入了哪支球队 ？” 它其实包含了：

1. 检索 2020 NBA MVP 是谁 ？
2. 检索该球员 2020 这个人去了哪支球队（或职业生涯轨迹 / 动态） ？

多跳就是用来解决这类问题而设计：让大模型能够回答那些需要综合多个信息来源进行推理的复杂问题，它通过多次连续搜索来收集和整合信息，从而克服传统单次检索方法的局限性。

工作原理：依靠迭代式检索与推理

1. 问题分解：将一个复杂问题分解为多个逻辑上关联的子问题，这个过程可以由大模型通过思维链（Chain-of-Thought）等技术完成。
2. 迭代检索：系统针对第一个子问题检索
3. 信息综合与上下文构建：检索到的信息会被用来形成下一个中间答案或新的上下文。
4. 下一次检索：新的上下文将指导系统进行下一步检索，以解答下一个子问题
5. 最终答案生成：完成所有必要信息检索的跳跃后，将收集到的所有信息整合汇聚层全面的最终答案。

References

[1] RAG Implementation Guide