LangChain4j RAG检索重排序实战：解决答非所问的排序瓶颈

1. 为什么你的RAG系统总是答非所问

做过RAG应用的人大概率都遇到过这种尴尬：用户问了一个非常具体的问题，系统检索回来一堆文档，但大模型给出的回答要么答非所问，要么把不相关的信息拼凑在一起。你检查向量库，发现相关文档明明就在里面，可它就是没被排到前面来。

这个问题的根源往往不在检索环节，而在排序环节。向量检索基于语义相似度做粗筛，它擅长从海量文档中快速缩小范围，但它的精度有限。打个比方，向量检索像是用一张大网捞鱼，能捞上来不少，但里面混杂着水草和杂物。而重排序就是那张细密的筛子，把真正有用的鱼挑出来，把杂物滤掉。

LangChain4j作为Java生态里做AI应用集成的主流框架，在RAG链路上提供了完整的检索和重排序支持。这篇内容我会围绕一个实际场景，把LangChain4j中RAG检索重排序的完整实现路径拆开来讲，包括为什么要加重排序、重排序模型怎么选、代码怎么写、参数怎么调、踩过的坑怎么填。适合已经用LangChain4j搭过基础RAG链路、但检索精度不理想的开发者，也适合正在选型RAG技术方案、想搞清楚重排序到底值不值得加的技术负责人。

2. RAG检索链路的核心瓶颈拆解

2.1 向量检索的天花板在哪里

向量检索的本质是把文本映射到高维空间，然后计算向量之间的距离。这个过程中，文本被压缩成了一个固定维度的向量，信息损失是必然的。一篇500字的文档和一个20字的问题，被映射到同一个向量空间后，它们的语义相似度计算其实是非常粗糙的。

具体来说，向量检索有几个天然短板。第一，长文档的语义稀释。一篇文档如果包含多个主题，它的向量表示会是这些主题的某种平均，导致它和任何一个具体问题的相似度都不够突出。第二，关键词匹配的缺失。向量模型对精确的关键词匹配并不敏感，比如用户问“XX接口的超时时间怎么配置”，向量检索可能返回一堆讲“接口设计”的文档，但真正包含“超时时间”配置的那篇反而排在后面。第三，Top-K的硬截断。你设Top-K为5，那第6条不管多相关都进不来，但前5条里可能有两三条是噪音。

注意：向量检索不是不好，它是RAG链路的第一道粗筛，负责从百万级文档中快速缩小到几十条候选。问题在于，很多人直接把粗筛结果喂给大模型，跳过了精排这一步。

2.2 重排序到底在做什么

重排序的核心思路是：用一个小模型对粗筛出来的候选文档逐条打分，然后按分数重新排列。这个打分模型通常是交叉编码器架构，它和向量检索用的双编码器有本质区别。

双编码器是分别把问题和文档编码成向量，然后算余弦相似度。问题和文档之间没有交互，所以速度快，适合大规模检索。交叉编码器是把问题和文档拼在一起输入模型，模型内部会做完整的注意力计算，能捕捉到问题和文档之间细粒度的语义关系。代价是速度慢，没法对百万级文档做实时打分。

所以标准做法是两阶段：第一阶段用双编码器从海量文档中召回Top-50到Top-100，第二阶段用交叉编码器对这50到100条做精排，取Top-3到Top-5喂给大模型。这样既保证了速度，又保证了精度。

2.3 LangChain4j在链路中的角色定位

LangChain4j对RAG链路的抽象比较清晰。它把检索过程拆成了ContentRetriever和ContentAggregator两个核心接口。ContentRetriever负责从数据源拿候选文档，ContentAggregator负责对候选文档做聚合和排序。重排序的逻辑就挂在ContentAggregator这一层。

具体来说，LangChain4j提供了ReRankingContentAggregator这个实现类，它接收一个ScoringModel接口的实现，对每个候选文档打分，然后按分数降序排列，最后截取Top-N。这个设计的好处是，你可以自由替换底层的重排序模型，不管是调远程API还是跑本地模型，只要实现ScoringModel接口就行。

3. 重排序模型选型与LangChain4j集成方案

3.1 重排序模型的三种技术路线

目前主流的重排序方案可以分成三类，各有各的适用场景。

第一类是基于API的云端重排序服务。这类服务通常由大模型厂商提供，你把问题和文档列表发过去，它返回每条的相关性分数。优点是接入简单、效果稳定、不用自己维护模型。缺点是每次调用都有网络延迟和费用，而且文档内容要传到外部服务，有数据隐私顾虑。

第二类是本地部署的开源重排序模型。比如BGE-Reranker系列、Cohere的rerank模型开源版本等。这类模型参数量通常在1亿到10亿之间，用ONNX Runtime或者PyTorch在本地推理，单条打分延迟在几十毫秒级别。优点是没有网络依赖、数据不出本地、可以针对垂直领域做微调。缺点是需要自己搭推理服务，对运维有一定要求。

第三类是基于大模型Prompt的重排序。直接让大模型对每个文档打相关性分数。优点是灵活，可以自定义打分标准。缺点是成本高、延迟大，而且大模型对打分这种细粒度任务的稳定性不如专门训练的重排序模型。

3.2 LangChain4j中ScoringModel接口的实现要点

LangChain4j的ScoringModel接口定义很简洁，核心方法就一个：接收一个Query和一个List<Content>，返回一个List<Double>，每个分数对应一条内容的相关性。

public interface ScoringModel { List<Double> scoreAll(Query query, List<Content> contents); }

实际实现的时候有几个关键点需要注意。第一，批量打分还是逐条打分。如果底层模型支持批量推理，尽量一次把多条内容传进去，减少调用次数。第二，分数归一化。不同模型输出的分数范围不一样，有的在0到1之间，有的在负无穷到正无穷。如果后续要做阈值过滤，需要先做归一化。第三，异常处理。重排序服务可能超时或返回异常，要有降级策略，比如打分失败时保留原始顺序。

3.3 一个可落地的重排序集成方案

我实际项目里用的方案是：本地部署一个轻量级重排序模型，通过HTTP接口暴露服务，LangChain4j这边实现一个ScoringModel，内部用HTTP客户端调本地服务。

选这个方案的原因有三个。一是数据不出内网，满足合规要求。二是本地推理延迟可控，P99在100毫秒以内。三是模型可以按需替换，今天用BGE-Reranker，明天换个更好的模型，只要接口协议不变，LangChain4j这边的代码不用动。

具体实现上，重排序服务的接口设计成接收JSON格式的请求体，包含query和documents两个字段，返回一个scores数组。LangChain4j这边的ScoringModel实现类负责组装请求、发送HTTP调用、解析响应、处理异常。

4. 完整实操：从零搭建带重排序的RAG链路

4.1 环境准备与依赖引入

先确认基础环境。JDK版本建议17以上，LangChain4j的版本用1.0.0以上，这个版本对RAG链路的抽象比较稳定。Maven依赖需要引入核心包和HTTP客户端。

<dependency> <groupId>dev.langchain4j</groupId> <artifactId>langchain4j</artifactId> <version>1.0.0</version> </dependency> <dependency> <groupId>dev.langchain4j</groupId> <artifactId>langchain4j-embeddings-all-minilm-l6-v2</artifactId> <version>1.0.0</version> </dependency>

如果重排序服务走HTTP调用，还需要引入一个HTTP客户端。我用的是OkHttp，轻量且稳定。

<dependency> <groupId>com.squareup.okhttp3</groupId> <artifactId>okhttp</artifactId> <version>4.12.0</version> </dependency>

提示：LangChain4j的版本迭代比较快，不同版本之间API可能有变动。建议锁定一个稳定版本，不要频繁升级。

4.2 文档加载与向量化入库

这一步是RAG的基础。把领域文档加载进来，切分成合适大小的片段，然后用嵌入模型转成向量，存到向量库里。

文档切分有个经验值：片段长度控制在300到500个token之间。太短了语义不完整，太长了向量表示会被稀释。切分的时候要保留一定的重叠，通常设置50到100个token的重叠区，避免一个完整的语义单元被切断。

DocumentSplitter splitter = DocumentSplitters.recursive(500, 50); List<Document> documents = FileSystemDocumentLoader.loadDocuments( Paths.get("/data/docs"), splitter);

向量化用LangChain4j内置的嵌入模型就行。如果对中文支持要求高，可以换成BGE的中文嵌入模型。

EmbeddingModel embeddingModel = new AllMiniLmL6V2EmbeddingModel(); EmbeddingStore<TextSegment> embeddingStore = new InMemoryEmbeddingStore<>(); EmbeddingStoreIngestor ingestor = EmbeddingStoreIngestor.builder() .embeddingModel(embeddingModel) .embeddingStore(embeddingStore) .build(); ingestor.ingest(documents);

生产环境建议用外部向量库，比如PgVector、Milvus或者Qdrant。内存向量库只适合做原型验证，重启就没了。

4.3 重排序服务的搭建与对接

重排序服务我选的是BGE-Reranker-Base模型，用Python起一个FastAPI服务。模型加载用FlagEmbedding库，推理用ONNX Runtime加速。

from fastapi import FastAPI from pydantic import BaseModel from FlagEmbedding import FlagReranker app = FastAPI() reranker = FlagReranker('BAAI/bge-reranker-base', use_fp16=True) class RerankRequest(BaseModel): query: str documents: list[str] @app.post("/rerank") def rerank(req: RerankRequest): pairs = [[req.query, doc] for doc in req.documents] scores = reranker.compute_score(pairs, normalize=True) return {"scores": scores}

这个服务启动后监听本地端口，LangChain4j这边通过HTTP调用。注意normalize=True这个参数，它会把分数归一化到0到1之间，方便后续做阈值过滤。

Java这边的ScoringModel实现：

public class RemoteScoringModel implements ScoringModel { private final OkHttpClient client; private final String endpoint; private final ObjectMapper mapper; public RemoteScoringModel(String endpoint) { this.endpoint = endpoint; this.client = new OkHttpClient.Builder() .connectTimeout(5, TimeUnit.SECONDS) .readTimeout(10, TimeUnit.SECONDS) .build(); this.mapper = new ObjectMapper(); } @Override public List<Double> scoreAll(Query query, List<Content> contents) { List<String> texts = contents.stream() .map(Content::text) .collect(Collectors.toList()); try { Map<String, Object> body = Map.of( "query", query.text(), "documents", texts ); Request request = new Request.Builder() .url(endpoint) .post(RequestBody.create( mapper.writeValueAsString(body), MediaType.parse("application/json"))) .build(); try (Response response = client.newCall(request).execute()) { JsonNode node = mapper.readTree(response.body().string()); List<Double> scores = new ArrayList<>(); node.get("scores").forEach(n -> scores.add(n.asDouble())); return scores; } } catch (Exception e) { // 降级：返回原始顺序的均匀分数 return contents.stream().map(c -> 0.5).collect(Collectors.toList()); } } }

4.4 组装完整的检索重排序链路

把检索器、重排序器、聚合器串起来，形成完整的RAG链路。

EmbeddingStoreContentRetriever retriever = EmbeddingStoreContentRetriever.builder() .embeddingStore(embeddingStore) .embeddingModel(embeddingModel) .maxResults(50) .minScore(0.6) .build(); ScoringModel scoringModel = new RemoteScoringModel("http://localhost:8000/rerank"); ContentAggregator aggregator = ReRankingContentAggregator.builder() .scoringModel(scoringModel) .maxResults(5) .minScore(0.3) .build(); RetrievalAugmentor augmentor = DefaultRetrievalAugmentor.builder() .contentRetriever(retriever) .contentAggregator(aggregator) .build(); Assistant assistant = AiServices.builder(Assistant.class) .chatLanguageModel(chatModel) .retrievalAugmentor(augmentor) .build();

这段代码的关键参数有两个。retriever的maxResults设50，意思是粗筛召回50条候选。aggregator的maxResults设5，意思是精排后取前5条喂给大模型。minScore是分数阈值，低于这个分数的直接丢弃。

4.5 参数调优与效果验证

参数调优不能拍脑袋，要有评估集。我一般会准备50到100条问答对，每条标注好标准答案和应该命中的文档ID。然后跑一遍链路，看Top-5里有没有包含正确文档，算一个命中率指标。

调参的顺序是这样的：先调retriever的maxResults，从20开始往上加，看命中率什么时候趋于平稳。通常50到100之间是个平衡点。然后调aggregator的maxResults，从3开始往上加，看大模型回答质量什么时候不再提升。最后调minScore，观察误召回和漏召回的权衡。

实操心得：minScore不要设太高。我见过有人设0.8，结果很多相关文档被过滤掉了。重排序模型的分数分布不是均匀的，0.3到0.5之间往往藏着不少真正相关的内容。

5. 常见问题与排查技巧实录

5.1 重排序后效果反而变差了

这是最常见的问题。原因通常有三个。第一，重排序模型和嵌入模型不匹配。比如嵌入模型是英文的，重排序模型是中文的，两者对语义的理解不一致。第二，分数归一化没做。如果重排序模型输出的分数范围很大，而minScore设了一个不合适的值，会把好文档过滤掉。第三，候选集太小。如果粗筛只召回了10条，重排序再厉害也挑不出花来。

排查方法：先把minScore设为0，看完整排序结果。如果正确文档在重排序后的排名比原始排名还低，那就是模型不匹配的问题。如果正确文档根本没进候选集，那就是粗筛的问题，需要调大maxResults或者换嵌入模型。

5.2 重排序服务超时导致链路不稳定

本地部署的重排序模型如果没做并发优化，QPS一高就容易超时。解决方案分两层。第一层是服务端优化，用ONNX Runtime做推理加速，开多个worker进程，加请求队列。第二层是客户端降级，在ScoringModel实现里加超时和异常捕获，打分失败时返回原始顺序，保证链路不中断。

// 降级逻辑：超时或异常时保留原始顺序 catch (Exception e) { logger.warn("Rerank service failed, fallback to original order", e); return contents.stream() .map(c -> 0.5) .collect(Collectors.toList()); }

注意：降级策略要记录日志和监控指标。如果降级频繁触发，说明重排序服务需要扩容了。

5.3 中文文档重排序效果不理想

中文重排序对模型的要求比英文高。如果用的是英文重排序模型，中文效果会打折扣。建议换用专门针对中文优化的模型，比如BGE-Reranker的中文版本。另外，中文文档切分的时候要注意，不要按空格切，要按标点符号和语义边界切。

还有一个容易被忽略的点：查询改写。用户的问题往往很短，比如“超时配置”，这种查询直接拿去重排序，模型很难判断相关性。可以在重排序之前加一步查询改写，把短查询扩展成完整的问句，比如“XX接口的超时时间应该怎么配置”。这一步能显著提升重排序的准确率。

5.4 重排序的延迟和成本怎么平衡

重排序的延迟主要花在模型推理上。如果候选集是50条，每条都要过一遍交叉编码器，延迟大概在200到500毫秒之间。这个延迟对于实时对话场景是可以接受的，但如果要求极致响应速度，就需要做取舍。

几个优化方向：一是减少候选集，把粗筛的maxResults从50降到30，延迟能降三分之一。二是用更小的模型，BGE-Reranker-Base换成BGE-Reranker-Small，延迟能降一半，效果损失在可接受范围内。三是异步重排序，先返回粗筛结果，重排序完成后更新，适合对实时性要求不高的场景。

6. 重排序链路的进阶优化方向

6.1 混合检索与重排序的结合

单纯靠向量检索做粗筛，有时候会漏掉关键词匹配的文档。一个常见的优化是混合检索：同时跑向量检索和关键词检索，把两边的结果合并后再做重排序。LangChain4j支持自定义ContentRetriever，可以自己实现一个混合检索器，内部调两个检索源，合并去重后返回。

这样做的好处是召回率更高。向量检索擅长语义匹配，关键词检索擅长精确匹配，两者互补。代价是候选集变大，重排序的压力增加。所以混合检索之后，重排序的maxResults要相应调大。

6.2 重排序模型的微调

通用重排序模型在垂直领域的效果往往不够好。比如医疗、法律、金融这些专业领域，术语和表达方式跟通用语料差别很大。这时候可以考虑用领域数据对重排序模型做微调。

微调的数据准备是关键。需要构造正样本和负样本，正样本是问题和相关文档的配对，负样本是问题和不相关文档的配对。数据量不用太大，几千条就能看到明显效果。微调后的模型在领域内的排序准确率通常能提升10到20个百分点。

6.3 多路重排序的融合策略

如果条件允许，可以同时跑多个重排序模型，然后把分数融合。比如一个通用模型加一个领域模型，两个模型的分数加权平均。这样做能兼顾通用性和领域性，但延迟和成本都会翻倍。

融合策略上，简单的加权平均通常就够了。权重可以根据评估集上的表现来定，哪个模型在验证集上表现好，权重就高一些。更复杂的做法是用一个小的学习模型来学习融合权重，但收益递减，不太建议在初期就上。

6.4 重排序结果的可解释性

重排序的分数本身就是一个可解释性信号。如果一条文档的分数很高，说明模型认为它和问题高度相关。可以在返回结果的时候把分数一起带上，方便调试和监控。

更进一步，可以用注意力可视化工具看模型在打分时关注了文档的哪些部分。这对理解模型行为、发现bad case很有帮助。不过这个属于进阶调试手段，日常开发中用得不多。

7. 我在实际项目中的几点体会

重排序这个环节，说到底是RAG链路里“最后一公里”的精度保障。我踩过最大的坑是过早优化——一开始就上重排序，结果发现粗筛的召回率本身就不行，重排序再厉害也救不回来。后来调整了顺序，先把嵌入模型和切分策略调好，确保粗筛的召回率在80%以上，再加重排序，效果提升才明显。

另一个体会是，评估集比模型选型更重要。没有评估集，你根本不知道调参是在往好的方向走还是往坏的方向走。我现在的习惯是，每换一个模型或者调一组参数，都跑一遍评估集，看命中率和回答质量的变化。这个习惯帮我避免了很多次“感觉变好了但实际变差了”的情况。

最后分享一个小技巧：重排序的minScore可以设成动态的。比如取所有候选文档分数的中位数作为阈值，这样能自适应不同查询的分数分布。固定阈值在查询类型变化大的场景下很容易失效，动态阈值更稳。