重排序（Reranking）技术在检索增强生成系统中，正扮演着越来越重要的角色。如果说RAG是一个信息检索的漏斗，那么Reranking就是最后一道精细筛选的关卡——它能在后检索阶段对拿到的文档重新排序，进一步提升最终生成内容的精准度和可靠性。更妙的是，这招还能拓宽检索的视野，比如通过多路召回先捞回足够多的候选结果，再靠Reranking挑出最对路的。
RAG的完整流程可以参考下面的图示，一目了然：
为什么要用Reranking
公司内部的自研RAG系统支撑业务跑了几个月，回顾这个过程，真是一路从“这有问题，那也有问题”的吐槽声中，经过不断打磨才成为真正的生产力工具。我们先后优化了Prompt、分块策略、元数据过滤和检索策略，但团队还是经常反馈答案质量不够理想。问题根源在于检索内容的精准度——当然，这也跟知识库本身内容庞杂脱不了干系。
另一个坎儿出现在ElasticSearch上。没错，我们用的就是ES作为向量数据库。检索速度倒是够快，也支持全文搜索，但相关性有时候就是差点意思——更准确地说，是精度不够。ES内部用的是分层可导航小世界算法来计算近似最近邻距离，这种算法擅长在海量数据中快速找到近似最近邻，速度和效率确实没得说，但精度上难免打些折扣。
这里说的精度问题其实是个相对概念。受限于大模型的上下文窗口，我们每次只能把检索到的top_5文档喂给模型去生成。于是解决思路自然而然地浮现：先捞回更多的候选文档，再靠另一个模型——专门用来评估文档和用户查询相关度的模型——重新打分，最后根据评分挑出top_5。示意图里的路子就很清楚：相似度检索时top_k取5，重排序后再选出top_n=2。
Reranking的技术原理
重排序到底是什么？说到底，就是计算每个文档与用户查询的相似性得分，然后按分数重新排名。具体拆开来看，大致分三步：
第一步，计算嵌入向量。这一步通常依赖深度学习模型，比如句子变换器，把文档内容的语义信息捕捉成向量。
第二步，输出相似性得分。这里要用上交叉编码器这类模型，对给定的查询和文档对输出一个相关性分数。
第三步，根据这些得分重新排序。最相关的文档自然被推到前面，检索结果的质量就提上来了。
重新排序器的工作方式，说白了就是拿着查询和文档，走一遍完整的Transformer推理，输出一个单一的相似性得分。要注意的是，这里的“文档A”其实对应我们的查询。
目前主流的重排序方法分成两类：
一类是专门的重排序模型，比如网易有道的BCEmbedding、Jina Reranker、Cohere reranker。这类模型会深入分析查询和文档之间的交互特征，从而更准确地评估相关性。
另一类则是直接借助大语言模型。让LLM理解整个文档和用户查询，更全面地捕捉语义信息来做排序。具体又分三条路：对LLM做微调让它专门干重排序；写Prompt引导LLM去排序；或者用LLM生成的数据来增强训练集，间接提升重排序模型的性能。
BCEmbedding介绍
BCEmbedding是网易有道开源的工具包，包含检索模型和重排序模型，而且本地部署商用免费。这对开发者来说相当友好。
其他几个亮点：
- Embedding和Reranker两个模型都能直接用BCEmbedding、transformers、sentence-transformers框架来跑。
- 官方提供了LangChain和LlamaIndex的集成接口，可以轻松嵌入到现有产品中。
- Reranker的rerank方法支持长段落精排（token数超过512也不在话下）。
- 还能给出查询和段落之间0到1的语义相关分数，方便进一步过滤低质量内容，减少无关信息对LLM的干扰。
官方提供的LangChain集成样例代码很贴心，基本开箱即用。不过有几个小细节得注意：一是原来的一些包路径在LangChain迁移后已经过时，下面代码里已经做了修正；二是需要从Hugging Face下载模型，这得翻跟斗，而且BCEmbedding的模型库还要验证才能下载。省事的做法是把模型git clone到本地，再把代码里的embedding_model_name改成本地路径。
#python
# 我们在`BCEmbedding`中提供langchain直接集成的接口。
from BCEmbedding.tools.langchain import BCERerank
from langchain_community.vectorstores import FAISS
from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain_community.document_loaders import PyPDFLoader
from langchain_community.embeddings.huggingface import HuggingFaceEmbeddings
from langchain_community.vectorstores.utils import DistanceStrategy
from langchain.retrievers.contextual_compression import ContextualCompressionRetriever
# init embedding model
embedding_model_name = 'maidalun1020/bce-embedding-base_v1' #修改为本地路径
embedding_model_kwargs = {'device': 'cuda:0'}
embedding_encode_kwargs = {'batch_size': 32, 'normalize_embeddings': True}
embed_model = HuggingFaceEmbeddings(
model_name=embedding_model_name,
model_kwargs=embedding_model_kwargs,
encode_kwargs=embedding_encode_kwargs
)
reranker_args = {'model': 'maidalun1020/bce-reranker-base_v1', 'top_n': 5, 'device': 'cuda:1'} #修改为本地路径
reranker = BCERerank(**reranker_args)
# init documents
documents = PyPDFLoader("BCEmbedding/tools/eval_rag/eval_pdfs/Comp_en_llama2.pdf").load()
text_splitter = RecursiveCharacterTextSplitter(chunk_size=1500, chunk_overlap=200)
texts = text_splitter.split_documents(documents)
# example 1. retrieval with embedding and reranker
retriever = FAISS.from_documents(texts, embed_model, distance_strategy=DistanceStrategy.MAX_INNER_PRODUCT).as_retriever(search_type="similarity", search_kwargs={"score_threshold": 0.3, "k": 10})
compression_retriever = ContextualCompressionRetriever(
base_compressor=reranker, base_retriever=retriever
)
response = compression_retriever.get_relevant_documents("What is Llama 2?")
print(response)Reranking的不足之处
凡事都有两面性。重排序在提升生成内容精准度方面确实功不可没，但也会带来副作用：
首先是性能损失。从单段式流程变成两段式，多了一道计算环节，处理时间自然增加了。重排序模型的损耗还算可控，要是换成基于LLM的Reranking，性能损耗就明显了——特别是对比原来向量检索那毫秒级返回的速度，体验上的落差会非常直观。
其次是成本上升。无论是本地服务器部署，还是调用商业化在线服务，都需要额外买单。而且每次可能要从前50篇候选文档里筛出前5篇，计算量比原来大得多。
说到底，Reranking最适合那些对精准度和相关性要求极高的场景——比如专业的知识库查询或者客户服务系统。这类业务中，每一次查询都可能牵扯重大商业利益，严谨是第一位的。相比之下，性能损耗和成本控制都可以往后放。重排序带来的答案准确性提升，最终会转化成实实在在的用户满意度。