此前，我介绍了使用Elasticsearch实现混合检索。

本文我将介绍一种效果更好的混合检索方法，在实际问答场景中，优于向量数据库自带的混合检索功能。

 1 

什么是混合检索

目前，大模型RAG系统中普遍采用混合检索来提升检索准确性。 

针对要回答的问题，同时通过向量语义相似度检索以及基于关键词的全文检索，将检索到的文本块，进行融合处理，包括去重与排序，然后再把得分最高的文本块，给到大模型生成回答。

这，就是混合检索的原理。

通过引入向量数据库，比如Chroma, LanceDB或者上篇文章中提到的Elasticsearch，我们可以非常容易地实现向量检索。

所以，当我们要实现混合检索，一个问题就在于如何实现全文检索。

好在LlamaIndex提供了实现BM25检索的方法。

 2 

构建BM25检索器

BM25是一种文本相关度检索方法，主要是判断⼀个⽂档和查询语句匹配的程度的算法，比如在搜索引擎中用于排序搜索结果。

这种文本相关度的判断，主要基于词语权重和文档权重的融合。

• 词频 TF（Term Frequency），即一个词在一个文档中出现的频率越高，那么文档的相关性也越高。

• 逆向文档频率 IDF（Inverse Document Frequency），即每个词在索引中出现的频率越高，相关性越低。IDF主要是为了降低像“的” 这样高频词语的相关性，提升包含低频专业术语的文档的权重。

这两者结合起来就形成了TF-IDF算法。

BM25算法则基于TF-IDF作了优化，主要是降低长文档的权重。LlamaIndex实现了BM25算法的检索器：BM25Retriever【参考资料1】。

不过，BM25Retriever默认使用的tokenizer不支持中文，所以我们使用Jieba作为tokenizer。这样，我们定制一个适合中文的BM25检索器SimpleBM25Retriever。

代码如下：

import jiebafrom typing import Listdef chinese_tokenizer(text: str) -> List[str]:return list(jieba.cut(text))
class SimpleBM25Retriever(BM25Retriever):@classmethoddef from_defaults(cls, index, similarity_top_k, **kwargs) -> "BM25Retriever":docstore = index.docstorereturn BM25Retriever.from_defaults(docstore=docstore, similarity_top_k=similarity_top_k, verbose=True,tokenizer=chinese_tokenizer, **kwargs)

考虑到使用向量检索时，我们通常基于index构建向量检索器。同样，以上定制的BM25检索器，我们也将index作为参数载入，然后在构建BM25Retriever时，将index.docstore传递过去。

BM25检索的内容基于LlamaIndex框架中的文档存储（docstore）。

我在之前的文章中提到，可以采用MongoDB作为文档存储（doc store）和索引存储（index store）。

一个更好的选择就是使用Redis【参考资料2】，它还可以作为文本提取管道的缓存（ingestion cache）和问答记录存储（chat store）。

这样，我们在一个RAG系统中，就不需要引入太多不同种类的数据库。

 3 

实现混合检索

接下来，我们需要把向量检索和BM25检索到的内容进行融合处理。LlamaIndex提供了一个很好的方法：QueryFusionRetriever 【参考资料3】。

基于这个方法，我定制了一个新的类SimpleFusionRetriever。

首先，构建向量检索器（vector_retriever）和BM25检索器（bm25_retriever），然后构造QueryFusionRetriever，并设置两者的权重分别为0.6和0.4。

这里，向量检索器的权重（0.6）更高，表明向量检索器的得分在最终排名中被认为更重要。

代码如下：

class SimpleFusionRetriever(QueryFusionRetriever):def __init__(self, vector_index, top_k=2, mode=FUSION_MODES.DIST_BASED_SCORE):self.top_k = top_kself.mode = mode
# Build vector retriever from vector indexself.vector_retriever = VectorIndexRetriever(index=vector_index, similarity_top_k=top_k, verbose=True,)
# Build BM25 retriever from document storageself.bm25_retriever = SimpleBM25Retriever.from_defaults(index=vector_index, similarity_top_k=top_k,)
super().__init__([self.vector_retriever, self.bm25_retriever],retriever_weights=[0.6, 0.4],similarity_top_k=top_k,num_queries=1,# set this to 1 to disable query generationmode=mode,use_async=True,verbose=True,)

其中，融合处理的模式设置为dist_based_score【参考资料3】。LlamaIndex目前支持以下四种模式。

class FUSION_MODES(str, Enum):RECIPROCAL_RANK = "reciprocal_rerank"# apply reciprocal rank fusionRELATIVE_SCORE = "relative_score"# apply relative score fusionDIST_BASED_SCORE = "dist_based_score"# apply distance-based score fusion    SIMPLE = "simple"  # simple re-ordering of results based on original scores

先介绍relative_score，即相对得分融合算法（Relative Score Fusion），采用以下方法对检索内容进行处理：

• 最小-最大归一化：此步骤将每个检索器的得分归一化到一个共同的尺度上，通常在0到1之间。这是通过减去最小得分并除以得分范围（最大值 - 最小值）来完成的。

• 加权求和：归一化后，得分使用加权求和的方式组合成一个最终得分。权重反映了每个检索器得分在最终排名中的相对重要性。

我们采用的dist_based_score，是基于分布的得分融合算法（Distribution-Based Score Fusion）。作为relative_score的变体，它根据每个结果集的得分的均值和标准差来不同地进行归一化处理。

这种方法考虑了不同检索器得分的分布特性，从而在融合时更加公平地对待每个检索器的得分。

QueryFusionRetriever是一个很有趣的方法。

它可以将原始的查询（query），通过LLM改写生成最多4个新的查询，然后对每一个检索器，都逐一检索。也就是说，如果有2个检索器，那么一共进行 4 x 2 = 8 次检索。

最终，该方法会对8次检索的内容，采用上述算法进行融合处理，去除重复的内容，并重新排序。

由于我们此次仅实验混合检索，而且不希望过多的LLM调用，导致延迟响应，因此将参数num_queries设置为1，不进行query的生成。

 4 

下一步做什么

本文介绍了使用LlamaIndex实现稠密向量检索 + BM25全文检索的混合检索方法，属于2路召回。

值得注意的是，最近 IBM 的研究文章对比了各种检索方式的组合，并提出采用Blended RAG【参考资料4】，即使用 BM25全文检索 + 稠密向量检索 + 稀疏向量检索的3路召回的混合检索方法，可以达到更好地效果。

后续，我将探索使用LlamaIndex，实现3路召回混合检索，并向大家报告结果。

本文中的代码，都可以在ThinkRAG【参考资料5】这一开源项目中找到。

https://github.com/wzdavid/ThinkRAG

ThinkRAG是我基于LlamaIndex框架，前端使用Streamlit开发的大模型知识库RAG系统，可本地化部署和离线运行。

欢迎关注与交流！