如何利用 BGE-M3 提升本地知识库在长文本检索时的召回率

BGE-M3 最大的杀手锏是 Multi-Vector 机制，它能同时处理稠密检索（Dense）、稀疏检索（Sparse/BM25）和多向量检索（ColBERT），这直接解决了本地知识库在面对长文档时，由于 Embedding 向量被强行压缩导致关键信息丢失的痛点。

很多人的误区是把 BGE-M3 当成普通的 Embedding 模型直接用，这样其实只发挥了它的 Dense 性能，面对长文本召回率依然拉胯。要真正提升召回率，必须配置「混合检索」。

核心配置路径：

如果你用的是 Milvus 或 Qdrant 这种支持多向量的数据库，建议直接开启 Hybrid Search。对于轻量化本地部署，可以尝试在检索层做 RRF（Reciprocal Rank Fusion）重排序。

实战代码片段（基于 Python 和 Sentence-Transformers）：

from SentenceTransformers import SentenceTransformer

# 加载模型
model = SentenceTransformer('BAAI/bge-m3')

# 关键：分别获取稠密向量和稀疏向量
sentences = ["这里是一段很长的技术文档内容...", "另一段关于配置的细节..."]
queries = ["如何配置本地知识库？"]

# 1. Dense Embedding (用于语义匹配)
dense_embeddings = model.encode(sentences, return_dense=True)

# 2. Sparse Embedding (用于关键词精准匹配，解决长文本丢失问题)
sparse_embeddings = model.encode(sentences, return_sparse=True)

# 在检索时，将 Dense 检索结果和 Sparse 检索结果按权重叠加
# 权重建议：Dense 0.7 + Sparse 0.3 (根据数据集微调)

几个避坑技巧：

分块策略不要太死板。 很多教程说固定 512 token 一个 chunk，但在处理长文本时，建议采用「重叠分块（Overlapping）」。设置 500 token chunk 且重叠 50-100 token，这样能有效防止语义在切割点被截断，配合 BGE-M3 的长文本支持（最高 8192 token），其实可以适当调大 chunk size 到 1000+，召回效果反而更稳。

警惕内存溢出。 BGE-M3 虽然强，但如果开启多向量存储，索引体积会剧增。如果显存吃紧，建议对 Dense 向量进行量化（Quantization），比如从 FP32 转到 INT8，召回率几乎没损耗，但内存占用直接砍半。

Prompt 调优。 检索到内容后，喂给 LLM 之前一定要做一次 Rerank。BGE-M3 负责把候选集从 100 万条拉到 50 条，再用 BGE-Reranker 把最相关的 5 条精选出来，这样能极大程度减少 LLM 的幻觉。