RAG检索质量优化方案：从Rerank到Hybrid Search

🖨️

在构建基于大语言模型（LLM）的知识库问答系统时，RAG（检索增强生成）已经成为行业标配。然而，随着入库文档数量的增加，开发者普遍会遇到一个致命的痛点：检索回来的内容根本不是用户想要的。

传统的 Naive RAG（朴素 RAG）过度依赖 Dense Embedding（稠密向量嵌入）来进行语义相似度计算。这种方式虽然能捕捉到“意思相近”的片段，但在处理包含专有名词、产品型号或精确数值的查询时，往往会发生严重的“语义漂移”。

本文将带你跳出简单的向量比对，深入探讨如何通过引入 Hybrid Search（混合检索）与 Rerank（重排）模型，构建一个高准确率的企业级 RAG 检索管道。

为什么纯向量检索（Dense Retrieval）会失效？

假设你的知识库中包含了多款手机的使用说明书。用户提问：“如何重置 iPhone 15 Pro Max 的网络设置？”

•

纯向量检索的缺陷：Embedding 模型在编码时，可能会认为“iPhone 14 Pro Max”或“恢复出厂设置”在语义上与查询非常接近。最终召回的 Top-5 结果中，可能充斥着其他型号手机的说明，导致 LLM 生成错误的指导。

•

长尾实体匹配差：对于一些极其冷门的专有名词（如内部系统代号 SYS-REQ-009X），如果 Embedding 模型在预训练阶段没有见过，它就无法将其映射到正确的向量空间，从而彻底失效。

为了弥补这一缺陷，我们需要引入传统的关键词检索（Lexical Search）。

Hybrid Search (混合检索) 架构解析

混合检索（Hybrid Search）的核心理念是：将 Dense Retrieval（向量检索）的泛化能力与 Sparse Retrieval（稀疏检索，如 BM25）的精确匹配能力结合起来。

2.1 架构设计

在支持混合检索的现代向量数据库（如 Pinecone, Weaviate, Milvus 或 Elasticsearch）中，一次查询会同时触发两路召回：

向量路 (Dense)：使用 Embedding 模型（如 text-embedding-3-small）计算查询的向量，找出语义最接近的 Chunk。

关键词路 (Sparse/BM25)：将查询分词，统计词频（TF-IDF 的变种 BM25），找出包含精确关键词（如 iPhone 15 Pro Max）的 Chunk。

2.2 RRF (Reciprocal Rank Fusion) 融合排序

既然有两路召回，如何将它们的结果合并成一个统一的 Top-K 列表呢？业界最常用的算法是 RRF（倒数排名融合）。

RRF 的计算公式非常简单：它不依赖分数（Score）的绝对值，而是看文档在各自列表中的排名（Rank）。

(其中通常取 60)

通过 RRF，那些在两路召回中都排名靠前的文档，会被赋予最高的最终得分。

Rerank (重排) 机制解析：引入 Cross-Encoder

混合检索解决了“召回遗漏”的问题，但同时也带来了另一个挑战：召回的文档数量变多了（比如 Dense 召回 50 篇，BM25 召回 50 篇，合并去重后可能有 80 篇）。如果把这 80 篇全部塞给 LLM，不仅成本高昂，还会引发严重的“中间丢失（Lost in the Middle）”效应。

这时候，我们需要引入一个更强大的裁判——Rerank 模型（通常是 Cross-Encoder）。

3.1 Bi-Encoder vs Cross-Encoder

•

Bi-Encoder (现有的 Embedding 模型)：分别对 Query 和 Document 进行编码，然后计算余弦相似度。速度极快，适合从百万级文档中进行初筛。

•

Cross-Encoder (Rerank 模型)：将 Query 和 Document 拼接在一起（如 [CLS] Query [SEP] Document [SEP]），同时输入给模型进行深度交互计算。它能捕捉到两者之间极细微的逻辑关联，准确率极高，但计算成本很大。

3.2 经典的两阶段检索管道 (Two-Stage Pipeline)

实战：搭建包含 Hybrid Search + Rerank 的高级 RAG

下面我们将使用 Python（结合 LangChain 或 LlamaIndex 的概念）展示核心的配置逻辑。如果你在处理多语言环境时的重排遇到编码问题，可以使用文本对比工具或编码工具辅助调试。

代码块

Python

from langchain.retrievers import EnsembleRetriever

from langchain_community.retrievers import BM25Retriever

from langchain_openai import OpenAIEmbeddings

from langchain_community.vectorstores import FAISS

from langchain.retrievers import ContextualCompressionRetriever

from langchain.retrievers.document_compressors import CrossEncoderReranker

from langchain_community.cross_encoders import HuggingFaceCrossEncoder

# 1. 准备两路检索器# Dense 检索器 (向量)

embeddings = OpenAIEmbeddings()

vectorstore = FAISS.from_documents(docs, embeddings)

dense_retriever = vectorstore.as_retriever(search_kwargs={"k": 50})

# Sparse 检索器 (BM25 关键词)

bm25_retriever = BM25Retriever.from_documents(docs)

FAQ 常见问题解答

Q: Rerank 会增加多少延迟？如何平衡准确率与性能？ A: 延迟取决于 Rerank 模型的参数量和输入的文档数量（Chunk 越长，计算越慢）。对于实时的 QA 系统，建议：

初始混合检索不要召回太多（如控制在 30-50 篇）。

选用轻量级的 Rerank 模型（如 bge-reranker-v2-m3 或 Cohere 的轻量版）。

如果必须追求极速，可以使用商业的 Rerank API（如 Jina AI 或 Cohere Rerank），将计算压力转移到云端。

Q: 混合检索的权重应该怎么调？ A: 没有一成不变的公式。如果你的文档中包含大量的 ID、专有名词、代码片段，应该适当提高 Sparse (BM25) 的权重；如果查询大多是口语化的模糊描述，则应提高 Dense (向量) 的权重。

总结

在构建企业级 RAG 系统时，“大力出奇迹”地往 Prompt 里塞更多的文档往往适得其反。通过实施 Hybrid Search + RRF + Cross-Encoder Rerank 的两阶段检索管道，我们能够在不显著增加 LLM Token 成本的前提下，极大地提升召回的精确度，从而从根本上缓解幻觉问题。