RAG 召回阶段技术评估框架：embedding_rerank_retrieval

想象一下，你是一位图书管理员，面对一位顾客的模糊提问——"我想要那本关于某个历史时期科技发展的书"。你需要快速在数万本书中定位最相关的内容，并将最好的答案排在最前面。这正是 RAG（检索增强生成）系统中 Retrieve 阶段每天都在做的事。

percent4/embedding_rerank_retrieval 是一个专注于 RAG 召回阶段算法效果评估的开源实验框架，使用 LlamaIndex 作为核心引擎，对比评测了 BM25、向量检索、混合检索、Rerank 重排序等多种召回策略的优劣，并通过 Gradio 提供了可视化对比界面。

项目背景：为什么 RAG 召回如此重要

大型语言模型（LLM）固然强大，但它的知识受限于训练数据，且存在"幻觉"问题。RAG（Retrieval-Augmented Generation）通过从外部知识库检索相关文档，再将文档内容注入 prompt，来弥补这一缺陷。整个 RAG 流程中，检索（Retrieve）质量直接决定了最终回答的上限——如果召回的内容不相关或不完整，再强大的 LLM 也无法给出正确答案。

RAG 召回阶段通常面临两大核心挑战：

第一，召回的命中率（Hit Rate）问题。 传统的关键词检索（BM25）擅长精确匹配，但无法理解语义。向量检索（Embedding）可以捕捉语义相似性，但对专有名词、缩写、代码片段的召回效果不稳定。单一的召回方式往往顾此失彼。

第二，排序的准确性（MRR）问题。 即使召回了一批相关文档，如何将最相关的那一篇排在最前面？Top-1 的相关性直接影响最终回答的可用性，而 Top-3 到 Top-5 的整体排序质量则决定了回答的完整度。

本项目正是在这一背景下应运而生，通过系统性的实验对比，帮助开发者找到最适合自己场景的召回方案。

技术架构：模块化的召回评估框架

项目采用 LlamaIndex 0.9.21 作为底层框架，围绕检索器的可插拔设计构建了完整的评估流程。核心模块包括：

custom_retriever/ —— 六大召回器实现

BM25 检索器（bm25_retriever.py）：基于 Elasticsearch 实现 BM25 算法。BM25 是一种经典的概率检索模型，通过 TF-IDF 的改进版本计算文档与查询的相关性得分。它对精确关键词匹配非常有效，是信息检索领域的基线方法。项目使用 http://localhost:9200 连接本地 Elasticsearch 服务。

向量检索器（vector_store_retriever.py）：基于 FAISS 向量索引实现语义检索。使用 OpenAI Embedding 或 BGE 系列 embedding 模型将文本转为高维向量，通过余弦相似度在向量空间中寻找最相似的文档。OpenAI 版本使用 1536 维向量，BGE 使用 1024 维。项目还实现了 embedding 缓存机制（build_embedding_cache.py），避免重复调用 API。

混合检索器（ensemble_retriever.py）：将 BM25 和向量检索的结果通过 RRF（Reciprocal Rank Fusion） 算法融合。RRF 是一种无需训练的融合策略，对每个文档计算 weight * (1 / (rank + c))，其中 c=60 为平滑参数，BM25 和向量各占 50% 权重。这种方法综合了关键词精确性和语义理解能力。

Rerank 重排序检索器（ensemble_rerank_retriever.py）：在混合检索初步召回的基础上，使用 BGE-Rerank 模型对候选文档进行二次排序。Rerank 模型是 Cross-Encoder 架构，对查询-文档对进行精细化打分，能够捕捉更细致的相关性信号。

查询改写混合检索器（qr_bm25_retriever.py）：引入 LLM 对原始查询进行改写，生成多个语义等价的查询变体，分别检索后用 RRF 融合。这解决了用户查询措辞与文档表述不一致的问题——用户说"AI"，文档可能写的是"人工智能"。

services/ —— 服务层

embedding_server.py 基于 FastAPI 构建 embedding 服务，使用 BAAI/bge-large-zh-v1.5 模型作为主力 embedding 引擎，支持 /embedding 接口。同时还有基于 Google Gemini 的 embedding 评估，测试了 Gemini Embedding 768/1536/3072 维三种规格。

server_gradio.py 是核心的可视化界面，提供 5 种检索方法的对比：BM25、纯向量检索、混合检索、混合+Rerank、查询改写+混合。用户输入查询词后，系统实时返回每种方法的 Hit Rate、MRR 指标以及 Top-K 召回内容，直观对比效果差异。

late_chunking/ —— 迟分策略评估

迟分（Late Chunking）是 2024 年提出的创新分块策略。传统做法是先分块再编码（Early Chunking），每个 chunk 独立 embedding。迟分则先将整个长文档编码为 token 序列的向量，再对 token 序列按语义边界（如句子）进行池化，生成每个句子的向量表示。项目使用 Jina 的 jina-embeddings-v2-base-zh 模型实验迟分策略，并通过 Gradio 界面对比迟分与传统分块的效果差异。

核心功能：量化对比实验结果

项目提供了完整的评估数据集（doc_qa_test.json），包含 321 个问答对，覆盖日本半导体发展史、美日半导体协议等主题。每个问答对有标准答案节点 ID，用于计算 Hit Rate 和 MRR 两大核心指标。

Hit Rate（命中率）：Top-K 召回结果中是否包含正确答案，衡量"有没有召回对的内容"。

MRR（平均倒数排名）：正确答案在召回列表中的平均排名分之一，衡量"最好的答案排在哪里"。

以下是不同策略在 Top-5 召回下的对比结果：

检索策略	Hit Rate (Top-5)	MRR (Top-5)
BM25	94.1%	85.0%
OpenAI Embedding	79.4%	67.9%
BGE-Base Embedding	81.0%	68.4%
混合检索 (BM25+Embedding)	93.8%	80.8%
混合 + BGE-Rerank-Large	96.6%	90.9%
混合 + 微调 BGE-Rerank-Large	96.9%	90.3%

关键发现

BM25 单独使用时 Hit Rate 高达 94.1%，说明经典信息检索方法在特定语料上依然强劲。但 MRR 仅为 85.0%，意味着正确答案虽然被召回，却不一定排在第一位。

纯向量检索（OpenAI/BGE）MRR 偏低（约 68%），说明向量检索擅长找到"大致相关"的内容，但在精确定位上不如 BM25。这与向量检索的"压缩"特性有关——将复杂语义压缩为有限维向量，必然损失精度。

混合检索在 Hit Rate 上与 BM25 基本持平（93.8% vs 94.1%），但 MRR 显著提升到 80.8%，说明融合策略有效改善了排序质量。

引入 Rerank 后的提升最为明显：混合+Rerank 将 MRR 从 80.8% 推高到 90.9%，提升了 10 个百分点。Rerank 模型的 Cross-Encoder 架构对每个查询-文档对独立编码，能够捕捉更精细的相关性特征。

微调版 BGE-Rerank（ft-bge-rerank-large）在 Hit Rate 上达到 96.9%，是目前最优策略。但值得注意的是，微调版在 MRR 上（90.3%）与基础版（90.9%）接近，说明基础版在 Top-1 排序上已经相当优秀，微调带来的主要是尾部召回的改善。

上手使用：环境配置与运行

前置依赖

Python 3.9+ 环境。核心依赖包括 llama-index 0.9.21、Elasticsearch 7.17.0（用于 BM25 检索）、faiss-cpu 1.11.0、gradio 4.12.0、sentence-transformers（BGE 模型用）。

安装依赖：

pip install -r requirements.txt

启动 Elasticsearch

BM25 检索器依赖本地 Elasticsearch 服务：

docker run -d -p 9200:9200 -e "discovery.type=single-node" elasticsearch:7.17.0

数据导入后（使用 preprocess/add_corpus.py），即可运行 Gradio 对比界面。

启动 Gradio 可视化界面

cd services
python server_gradio.py

访问 http://localhost:7860 即可看到检索方法对比界面。

单独评估脚本

使用 evaluation/evaluation_exp.py 批量评估不同配置组合，输出 CSV 结果文件。

局限性与注意事项

依赖 Elasticsearch：BM25 和查询改写检索器强制依赖本地 Elasticsearch，增加了部署复杂度。如果没有 Elasticsearch，这部分功能无法使用。

Embedding API 费用：向量检索依赖 OpenAI Embedding API（text-embedding-ada-002），生产环境中需考虑 API 调用成本。项目中包含 Gemini Embedding 和本地 BGE 模型作为替代方案。

测试集局限：评估数据基于日本半导体发展史相关语料，对其他领域（如代码、医疗、法律）的召回效果需要自行验证。

无 Docker 支持：项目未提供 Dockerfile 或 docker-compose，对于需要快速复现的场景不够友好，需要手动配置 Python 环境和各项服务依赖。

行业意义与趋势

本项目反映了 RAG 检索领域几个重要趋势：

混合检索成为行业共识：BM25 + 向量检索的 RRF 融合策略已在 LangChain、LlamaIndex 等主流框架中成为默认配置。本项目的实验数据有力地支持了这一选择。

Rerank 是当前最优的精度提升手段：在混合检索基础上增加 Rerank 层，可以将 MRR 从 80% 提升到 90% 以上，这对需要精确答案的生产场景（如客服、问答系统）价值巨大。

Embedding 微调正在普及：项目中微调 BGE-Rerank 的实验代码（embedding_finetune/embedding_fine_tuning.ipynb）表明，针对特定领域微调 embedding 模型正在成为行业趋势。相比通用模型，专业微调模型的 Hit Rate 提升约 2-3 个百分点。

迟分（Late Chunking）策略值得关注：这是一种新兴的分块思路，在长文档场景下可能比传统分块更有效地保留语义完整性，但其计算开销较大，需要权衡使用。

整体而言，本项目为 RAG 开发者提供了一套完整的召回策略评估范式，无论是研究检索算法还是选型生产方案，都有重要参考价值。