RAG重排序实战：从向量检索到精准回答的LangChain接入指南

检索召回了20段资料，模型最后却答非所问，这种事我碰到过不止一次。后来排查了一圈，问题不在向量库，也不在生成模型，而是卡在“找回的资料里哪些真正有用”这一层。RAG（检索增强生成）做得越久越能感受到一个点：真正让RAG从“能查到”变成“答得准”的，往往是检索和生成中间那一道看不见的工序——重排序（Rerank）。这篇文章我会结合LangChain的实现，拆解重排序的原理、模型选型、完整接入流程，以及我踩过的几个印象比较深的坑。

如果你正在做RAG相关项目，尤其是那种“答案明明在知识库里但模型就是答不对”的场景，这篇文章应该能帮你少走不少弯路。内容不挑基础，就算你刚接触LangChain，跟着操作也能把整条链路跑通。

1. 为什么检索回来了，还是答不对题

1.1 向量检索的局限：初排只是“海选”

先聊一个基础问题：我们平时用的向量检索，本质上在做的是什么？

Embedding模型把query和document都映射成一个高维向量，然后通过余弦相似度或者内积去算“距离”，距离近的就认为相关。这套机制在大量场景下是高效且好用的，尤其适合快速从几百万条数据里捞出候选集。但你要明白一个关键点：embedding检索做的是“近似最近邻搜索”，它擅长的是“形似”和“语义位置相近”，而不是“精确判断这段文字能否真正回答这个提问”。

我经常用“海选”这个词来类比初排。海选的目的是用最小的成本把候选从几百万缩到几百个，它的核心诉求是“尽量别漏掉正确答案”，而不是“把答案严格排名”。所以你会发现，向量检索的分数本身并不代表真实的相关性，它只代表向量空间里的距离远近。这种距离受到embedding训练目标、文本长度、领域差异的影响，经常出现“明明内容相关，分数却不高；有些看似不相关的段落，分数反而高”的情况。

更麻烦的是分块（chunking）带来的噪声。同一个文档被切成固定大小的片段之后，答案所在的那一小段和你的提问未必有最高的向量相似度。它可能藏在第13位。你top_k设成5，它就丢了；设成10，前面还混着好几个噪音片段。上下文窗口有限，一塞就塞不进去了。

这还不是最棘手的。实际业务里，query经常是口语化、带指代、含错字的，比如“那个报表怎么导出来，就是上个月新加的那个”。embedding模型对这类query的匹配能力本身就有限，更别提不同文档来源之间的格式差异、术语不一致这些常态。向量检索初排出来的结果，往往只是“看起来沾边”，离“精确命中”还差一步。

1.2 重排序在RAG流程中的位置

重排序解决的就是刚才说的这一层问题。它的定位很明确：在初排召回结果的基础之上，用更精细的模型对候选片段重新打分排序，把真正和query语义相关的片段提到前面，把无关片段压下去，然后只保留排序靠前的部分送入LLM生成回答。

整个RAG链路可以这样理解：

• 文档加载与切分：把原始文档变成合适大小的chunk。
• 向量化与索引：用embedding模型生成向量，存入向量库。
• 初排召回（Retrieve）：根据query快速检索出top_k候选。
• 重排序（Rerank）：对top_k候选做精细化排序，压缩上下文。
• 生成（Generate）：把排序后的片段组装进context，交给LLM回答。

前两步是基础建设，一般只做一次。后三步才是每次query都会走的实时链路。而重排序恰恰是这四步里，对回答质量影响最大、但也最容易被忽略的一环。

我见过不少项目，向量库建得很用心，文档也切得分毫不差，却从来没做过重排序，结果就是RAG的效果一直让人“说不出来哪里不对，但就是差点意思”。对话场景尤其明显：你问一个明确的专业问题，模型叽里呱啦说了一堆，仔细一看，核心答对了一半，另一半被一个弱相关片段带偏了。这种问题去调prompt往往没用，根源是进入上下文的那几段文本，本身就排错了序、选错了档。重排序解决的就是这个“最后一公里”的质量问题。

2. 选型之前先搞懂：重排序模型到底在做什么

2.1 三类常见重排序方案对比

先说一个最常见的误解：很多人以为重排序就是再做一次向量检索，换个关键词再搜一遍。其实完全不是。重排序的核心差异在于，它会真正把query和候选片段放到一起做“交互式建模”。

现在常见的重排序方案大致有三类，各有各的适用场景：

Cross-Encoder和向量检索的Embedding模型最大的区别在于：向量检索是“双塔结构”，query和document各过一个编码器，最后只比向量距离，双方在编码阶段完全不交互。Cross-Encoder则是把query和document拼成一个序列，一起喂给Transformer，attention机制可以在建模过程中充分捕捉两者之间的词级交互，像“这个代词指代的是query里的哪个对象”“这两个词是不是同义替换”这种细粒度关系，它都能感知到。这也是为什么Cross-Encoder的重排序精度明显高于双塔结构。

LLM重排序是这两年冒出来的新玩法，做法很直白：把query和候选片段列进prompt，让大模型判断哪些片段最能回答问题，甚至直接生成一个排序结果。有些项目甚至让LLM输出排序理由。这种做法在小样本、适配特定领域时效果很惊艳，但延迟普遍较高，成本也不可控。我更倾向于把LLM重排序用在“候选数量不超过10条、回答质量要求极高、且你能接受两到三秒额外延迟”的离线分析场景，线上实时对话还是用Cross-Encoder更稳。

商业Rerank API是最省心的方案，不需要折腾模型部署，返回的分数一般也是规整的0到1之间，方便直接用阈值卡掉低分内容。适合团队资源紧张、追求快速上线的项目。缺点无非是钱和网络依赖，看你自己权衡。

2.2 分数不是越高越好：理解重排序输出的语义

这里我要重点提醒一下：重排序模型输出的分数，和你理解的那种“相关性百分比”并不完全是一回事，用的时候要小心。

Cross-Encoder模型的输出通常是一个logit值，也就是未归一化的得分。有些封装会帮你过一遍sigmoid或者softmax，把它变成0到1之间的值，但你得清楚这个值并不是严格的概率，甚至不同模型分布差异很大。有的模型分数普遍偏低，0.2就算高；有的模型普遍偏高，0.8以下都是垃圾。如果你拿同一个阈值去卡不同模型，结果会非常离谱。

商业API通常会把分数归一化到0到1，并且明确告诉你这个分数代表相关性强度，方便设阈值。但即便是同一个API，不同query类型下的分数分布也可能不稳定。我的习惯是：不要看单条分数的绝对值，要看候选集内部的相对排序和分数差距。重排序的第一价值是“排序”，第二价值才是“截断”。

还有一点容易被忽略：重排序分数与向量相似度分数之间的差异。如果你做的是多路召回（比如同时用BM25、向量检索、知识图谱检索各召回一批），你会得到多组分数体系完全不同的候选。这时候千万不能直接把两边的分数加在一起求平均。正确做法是先做分数归一化或者排名融合，再统一交给重排序模型重新打分。否则，某一路的分数天然偏高，就会带偏整个模型。

2.3 什么时候才需要加重排序

重排序不是银弹，也不是所有RAG都必须上。我个人的判断标准是这样的：

• 候选集小（比如top_k=3），且你已经人工验证过前三名绝大多数时候都正确：可以不加，收益不明显。
• 文档片段经常“答非所问”，正确答案排不进top_3：必须加，而且大概率收益明显。
• 做了多路召回：必须加，因为需要统一不同来源的排序尺度。
• 知识库文档风格多样、术语混乱、存在版本差异：强烈建议加，重排序模型能过滤掉不少语义飘忽的噪音段。
• 对延迟极其敏感且上下文限制很紧：可以尝试把初排top_k降到最小值，不加也行，但你要接受可能的精度损失。

重排序的开销是可控的。一般初排top_100召回，重排序时只对候选集前20到前50做打分，整个重排过程可能都到不了100毫秒。相对于一次LLM调用动辄一两秒的延迟，这点开销完全可以接受。反而是“上下文里塞满了垃圾片段导致模型反复推理错误”的浪费，才是真正的大头。

3. 在LangChain里落地：两条典型接入路径

3.1 路径一：压缩检索器 + 商业Rerank API

LangChain里接入重排序最标准的方式，是用ContextualCompressionRetriever。这个名字容易让新手误解，以为它只做上下文压缩、不涉及重排序。其实它的机制是：先让底层retriever召回候选，再由一个“文档压缩器”（Document Compressor）对候选进行重排、过滤、精简，最终输出的就是“压缩后的有用上下文”。重排序就是压缩器最核心的能力之一。

思路很简单：

from langchain.retrievers import ContextualCompressionRetriever from langchain.retrievers.document_compressors import CohereRerank from langchain.embeddings import OpenAIEmbeddings from langchain.vectorstores import FAISS # 1. 准备底层检索器 embeddings = OpenAIEmbeddings(model="text-embedding-3-small") vectorstore = FAISS.from_documents(docs, embeddings) base_retriever = vectorstore.as_retriever(search_kwargs={"k": 20}) # 2. 配置重排序压缩器 compressor = CohereRerank(model="rerank-multilingual-v3.0", top_n=5) # 3. 组合为压缩检索器 compression_retriever = ContextualCompressionRetriever( base_compressor=compressor, base_retriever=base_retriever )

这里面的关键参数是：底层检索器的“k”要设大一些，给重排序足够的候选。比如你要最终输出5段，初排就至少召回20条；要最终输出8段，初排就召回30到40条。初排太小的话，正确答案本身都没进候选池，重排序再怎么排也白搭。

3.2 路径二：本地开源Cross-Encoder接入

如果你不想依赖商业API，或者数据涉及隐私不能外传，用本地开源Cross-Encoder模型是更稳妥的选择。目前类似bge-reranker-v2-m3这样的模型就很好用，中英文混合场景下表现稳定，部署成本也不高。

在LangChain里的接入方式有两种：一是看看有没有现成的集成类，二是自己写一个DocumentCompressor。后者其实不复杂。文档压缩器本质上只需要实现一个接口，输入是候选文档列表，输出是重排和精简后的文档列表。

from langchain_core.documents import Document from langchain.retrievers.document_compressors.base import BaseDocumentCompressor from sentence_transformers import CrossEncoder class LocalCrossEncoderCompressor(BaseDocumentCompressor): def __init__(self, model_name: str, top_n: int = 5, threshold: float = 0.0): self.model = CrossEncoder(model_name) self.top_n = top_n self.threshold = threshold def compress_documents(self, documents, query): if not documents: return [] # 拼接query与文档，得到相关性得分 pairs = [[query, doc.page_content] for doc in documents] scores = self.model.predict(pairs) scored_docs = list(zip(documents, scores)) # 按分数降序排列 scored_docs.sort(key=lambda x: x[1], reverse=True) # 过滤低分，再截取top_n result = [] for doc, score in scored_docs: if score < self.threshold: continue result.append(doc) if len(result) >= self.top_n: break return result

这段代码逻辑上很清楚：拼接query和每一段文档，用CrossEncoder打分，降序排列，按阈值和top_n截断。你用ContextualCompressionRetriever装配它就行：

compressor = LocalCrossEncoderCompressor( model_name="BAAI/bge-reranker-v2-m3", top_n=5, threshold=0.0 ) compression_retriever = ContextualCompressionRetriever( base_compressor=compressor, base_retriever=base_retriever )

做到这一步，你就能在自己服务器上跑通完整重排序链路了。

3.3 把重排序结果喂给LLM时，上下文该怎么组装

重排序做完之后，下一步是把选出来的片段组装成context，送给LLM。这个环节看似简单，其实有几个细节直接影响回答质量。

第一个细节是顺序。Rescore后一定按最终排序把片段从高到低放进prompt，不要打乱。LLM在长上下文里对靠前内容的注意力通常更强，把最相关的答案片段放在最前面，能显著减少模型被后排噪音带偏的概率。

第二个细节是提示词里要不要告诉模型“资料来源按相关性排序”。我的经验是，简单注明一句就够了，比如“以下资料按与问题的相关度从高到低排列，回答时优先参考靠前的资料”。但不要花太多篇幅去描述排序规则，否则模型容易把注意力放在“排序”这件事本身上。

第三个细节，也是失误率最高的：不建议把重排序分数直接写进prompt。很多开发者为了让模型“重视”高分内容，把score: 0.98这种信息一起塞给LLM。多数情况下这不会带来收益，反而可能导致模型对着分数胡编乱造，比如“根据评分0.98的资料”这种鬼话。分数是给链路人用来看的，不是给模型用的。如果你确实想让模型知道“这段很可靠”，用文字描述“这段资料与问题高度相关”比数字更安全。

第四个细节是关于阈值的。重排序过滤的目的不是把所有低分都删掉，而是去掉“明显不相关”的噪声。阈值设太高，可能把答案所在但表述不佳的段落也过滤掉；阈值设太低，噪声又会混进来。我一般建议先用不设阈值的方式跑一批真实query，统计一下命中答案的片段的分数分布，再决定阈值放在哪个位置。这个习惯能救你很多次。

4. 直接可以抄的实操笔记

4.1 一个完整的最小可跑示例

下面是我实际用过的完整流程，从原始文档到最终问答，你可以直接参考。这里统一用伪代码示例，你换成自己的文档路径即可。

from langchain.document_loaders import TextLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain.embeddings import OpenAIEmbeddings from langchain.vectorstores import FAISS from langchain.retrievers import ContextualCompressionRetriever from langchain.retrievers.document_compressors import CohereRerank from langchain.chains import RetrievalQA from langchain.chat_models import ChatOpenAI # 1. 加载并切分文档 loader = TextLoader("manual.txt") documents = loader.load() text_splitter = RecursiveCharacterTextSplitter( chunk_size=800, chunk_overlap=100 ) docs = text_splitter.split_documents(documents) # 2. 建索引 embeddings = OpenAIEmbeddings(model="text-embedding-3-small") vectorstore = FAISS.from_documents(docs, embeddings) # 3. 初排检索器，召回20条候选 base_retriever = vectorstore.as_retriever(search_kwargs={"k": 20}) # 4. 重排序压缩器，保留最相关的5条 compressor = CohereRerank(model="rerank-multilingual-v3.0", top_n=5) compression_retriever = ContextualCompressionRetriever( base_compressor=compressor, base_retriever=base_retriever ) # 5. 组装QA链 llm = ChatOpenAI(model="gpt-4o-mini", temperature=0) qa_chain = RetrievalQA.from_chain_type( llm=llm, retriever=compression_retriever, return_source_documents=True ) # 6. 跑一次 result = qa_chain.invoke({"query": "这个设备的最大负载是多少？"}) print(result["result"])

这套流程跑通之后，你可以先不换模型、不换参数，只看看return_source_documents里返回的文档顺序和内容。我强烈建议你多打印几次中间结果，把“初排前五”“重排前五”“答案所在片段排第几”这三个信息对比着看。这一步能帮你直观建立对重排序价值的感知。

4.2 参数调优记录：top_k、底分阈值、窗口大小

参数怎么调，不同项目差异很大，但有几个经验规律是通用的。

初排候选数（k）：我实测下来，最终希望保留n条内容，初排候选建议在3n到5n之间。比如最终取5条，初排设15到20条比较合理。还有，如果你发现重排后排序仍然不稳定，可以先试着加大初排候选数，有时候候选太少本身就会导致重排结果抖动。

重排保留数（top_n）：这取决于LLM上下文窗口和回答任务的复杂度。简单的事实型问题，3条足够；需要综合多个来源才能回答的问题，5到8条更稳。超过8条后，边际收益开始递减，而且无关内容混入的概率明显上升。文档来源特别杂时，我倾向于少保几条，靠重排序的过滤能力多压一压噪声。

底分阈值（threshold）：上面提过，先看分布再定值。以bge-reranker-v2-m3为例，它输出的分数普遍偏低，实测很多完全相关的片段也只有0.4上下，所以阈值设到0.35以上就很容易误杀。相反，某些商业API分数集中在0.9以上，低于0.5的基本可以直接丢。永远不要拿着别人项目的阈值套自己的场景。

切分窗口（chunk_size）：和重排序强相关。片段太长时，片段内信息太杂，一个片段里可能只有一小段是答案内容，但重排序模型打分会把整个片段的综合相关性算进去；片段太短时，上下文不完整，模型又判断不出这段是否真的回答了问题。我目前的习惯是：普通文档800到1000字符，同时设置100到150的overlap。代码和技术文档可以放到1500，因为术语密度高，太短了反而切碎。想更精细的话，可以试试父子分块，就是“小块检索、重排后映射回大块父文档”，只是工程量会大一些。

5. 常见问题与排查实录

5.1 重排序“没生效”

这是我遇到得最多的情况，也是最好排查的一类。现象是：加了重排序链路之后，回答质量和之前没什么区别，甚至有时候明显更差。

先检查三件事。

第一，基础检索器返回的候选数是不是太小。比如你初排k=3，重排序只是把3条换了个顺序，第一条还是那条。这种情况下效果自然不会有本质变化。把初排候选数改成20，再看效果。

第二，压缩器配置是不是真的挂载上了。有时候代码写成了base_retriever=vectorstore.as_retriever()原始检索器，压缩器根本没被调用。打印一下最终返回的Document列表，如果顺序和初排一样，而且数量仍是初排候选数，那大概率压缩器没有生效。

第三，模型版本或者参数名问题。LangChain的API更新频率很快，不同版本里某些重排序封装类的参数名可能已经变了。我发现好几个人升级依赖之后，参数不识别直接静默忽略了。所以，装好依赖第一件事就是跑一个单条测试，确认模型真的在打分。用类似compressor.compress_documents(documents, query)的方法直接验证，不要等整个链路串完了再排查。

5.2 重排序后效果反而变差

这个现象初看很反直觉：更精细的模型怎么还会变差？实际踩过之后才明白，问题往往不出在排序本身，而出在“排序方式”与“下游使用方式”不匹配。

最大的坑是：重排序模型选出的是“最相关的片段”，但LLM需要的可能是“上下文最完整的片段”。比如答案分散在三个连续片段里，按重排结果选了第一条和第三条，中间第二条被滤掉了。模型拿到的上下文缺了一块，反而答不对。这种情况我遇到几次之后，开始在切分和组装阶段下功夫：要么给LLM的上下文里多保留一条衔接片段，要么改用父子分块，让重排在“小片段”粒度做，送入LLM时再映射回完整父块。

另一个常见问题是query本身不够清楚。重排序模型和embedding模型一样，都吃“query表达质量”。如果提问太含糊、指代不明，重排序模型也会跟着糊涂。有个项目里用户经常问“那个功能怎么用”，模型分不清到底是哪个功能。后来我加了query改写环节，把这类指代消解后再送进重排序，效果立刻上来了。如果你的query普遍较长、口语化、带指代，建议先做一次query重写或者纠错，再做检索。

还有一个我在自己项目里踩过的坑：上下文里被过滤掉的片段其实承担着“背景信息”的角色。比如用户问“为什么报错101”，最相关的片段可能是“错误101是网络超时”，但“网络超时的常见原因包括防火墙设置”这个背景片段得分略低，被过滤了。结果模型只能干巴巴回答报错含义，没法给出排查建议。后来我的策略是：主题性回答保留5条，并且对说明性、步骤性的内容单独设置一个较低的阈值，允许部分背景片段混入。这个取舍要自己根据业务来。

5.3 长文档场景的片段漂移

处理长文档时，最常见的问题是“片段漂移”：答案相关的信息分散在好几个地方，初排候选里可能有片段A提到相关概念但没给结论，片段B给了结论但缺少前提，片段C是另一个子话题的讨论。重排序模型单独看每个片段都觉得不那么相关，排序自然不稳定。

我用的一个有效方案是：重排序时，不只针对“单片段”打分，而是对“片段 + 其前后相邻片段”做合并打分，选出后再决定保留哪种粒度。这个思路非常实用。LangChain里虽然没直接封装这个逻辑，但你可以自己写一个合并逻辑：在重排序之前，把候选片段进行轻量合并，再送进压缩器。这相当于在RAG链路里加入了一个“段落组装”的步骤，代价很小，但能大幅提升长文档场景的稳定性。

另外要留意重排序模型对“长序列”的输入限制。有些模型对拼接后的token长度有限制，超过阈值会报错或截断。如果你的片段普遍很长，建议先查一下模型的max_length，别等上线了才发现动不动报错。

6. 一点实操心得

做了这么多RAG项目，我个人的体感是：重排序不是银弹，但它是目前性价比最高的质量增强手段。你不需要换更强的embedding，不需要换更大的LLM，只要在初排和生成之间加一道重排序，整体回答质量经常会有肉眼可见的跃升。

如果你准备把这个方案落到自己的项目里，我建议按这个顺序推进：先把最朴素的RAG链路跑通，确保数据加载和检索没问题；再接入重排序，用一批真实问题对比前后效果；最后再调候选数、阈值、切分窗口这些参数，每次只动一个变量，别同时改一堆东西，否则你根本不知道是哪个变更带来的提升。

最后分享一个小技巧：很多人在调试RAG时只盯着最终回答看，中间结果一概不打印。这个习惯很危险。重排序的价值要在中间层才能体现出来，你至少要把“初排候选”“重排后结果”“最终上下文”这三层打出来对比一次。哪怕只是在本地调试时打印，也能帮你快速定位到底是检索、重排序还是生成环节出了问题。我自己后来做每个RAG项目，都会先用50到100条真实query跑一遍，把中间状态落成日志，再开始优化。这套习惯帮我避掉了很多“看起来是模型问题，其实是上游数据问题”的暗坑。