1. 为什么召回之后还需要一道重排序工序做过RAG检索增强生成的人大多经历过这样一个阶段把向量库搭起来把文档切好灌进去用户提问时top-k一取直接丢给大模型然后发现回答质量时好时坏。问题往往不在生成端而在召回端——向量检索返回的那一批候选里真正能回答问题的文档可能排在第7、第8位而排在前面的几篇只是语义上沾边。这就是重排序Rerank要解决的核心问题。向量检索本质上是双塔Bi-Encoder架构查询和文档分别编码成向量再算余弦相似度。这种架构的优点是快文档向量可以离线算好、建索引线上只算查询向量百万级文档毫秒级返回。但代价是查询和文档在编码阶段从未见过彼此语义交互被压缩进一个固定维度的向量里细粒度的匹配信息丢失严重。重排序用的是交叉编码器Cross-Encoder把查询文档拼成一个序列一起送进模型让注意力机制在两者之间充分交互最后输出一个相关性分数。精度显著高于双塔但代价是无法预计算——每个查询-文档对都要现场跑一次前向推理。所以工程上的标准做法是两阶段向量检索先粗筛出top-50到top-100再用Cross-Encoder精排取top-3到top-5喂给大模型。这一章要讲的不只是接一个Reranker模型这么简单。真正落地时会遇到三个绕不开的问题Reranker怎么选、怎么部署是调云端API还是本地跑本地跑用什么推理框架模型格式怎么选重排之后还有冗余top-5里可能有三篇讲的是同一件事全塞给大模型既浪费上下文窗口又容易让模型在重复信息里绕圈。延迟和成本的平衡Cross-Encoder是串行推理候选集越大越慢怎么在质量和响应时间之间找平衡点。MMRMaximal Marginal Relevance最大边际相关性就是解决第二个问题的经典算法。它的思路很朴素选下一篇文档时不只看它和查询的相关性还要看它和已选文档的差异度两者加权打分挑综合分最高的。这样选出来的结果集既相关又多样不会出现五篇文档说同一句话的尴尬。把Reranker和MMR串起来就构成了召回之后的一道完整精加工流水线Reranker负责把真正相关的挑到前面MMR负责把重复的挤出去。这一章我会把这条流水线从原理到代码完整拆一遍包括模型选型、llama.cpp部署、GGUF格式的坑、MMR的参数调优以及我在实际项目里踩过的那些坑。2. Cross-Encoder与Bi-Encoder的本质差异2.1 双塔模型为什么快但不够准先把这个事情讲透后面选型和调参才有依据。Bi-Encoder的工作方式是把查询和文档独立编码query_vec encoder(query) doc_vec encoder(doc) score cosine(query_vec, doc_vec)因为文档编码和查询无关所以可以离线把所有文档向量算好存进向量库。线上来了查询只算一次查询编码然后做近似最近邻搜索ANN比如HNSW、IVF这些索引结构百万级文档也能在几十毫秒内返回top-k。但问题在于编码器在生成doc_vec的时候根本不知道用户会问什么。它只能把文档的通用语义压缩进一个向量。如果用户问的是Ch09里MMR的lambda参数怎么调而文档里写的是MMR通过调节λ平衡相关性与多样性两者语义相关但Bi-Encoder可能因为措辞差异给出一个中等偏上的相似度排在几篇泛泛讲RAG的文档后面。一句话总结Bi-Encoder把匹配这件事提前到了编码阶段用空间换时间精度必然有损。2.2 Cross-Encoder的注意力交互Cross-Encoder把查询和文档拼在一起input [CLS] query [SEP] doc [SEP] score classifier(encoder(input))这时候Transformer的自注意力机制会在query的token和doc的token之间自由交互MMR这个token可以直接attend到文档里的MMRlambda可以attend到λ匹配信号非常强。分类头最后输出一个标量分数直接就是相关性。代价是每个查询-文档对都要跑一次完整前向。假设候选100篇每篇平均200个token加上查询50个token就是100次250token的推理。用base级别的模型比如bge-reranker-base约1.1亿参数在CPU上单次可能100-300ms100篇就是10-30秒完全不可接受。所以必须用GPU或者量化后的本地推理。2.3 两阶段流水线的工程意义把两者结合就得到了工业界通用的召回-精排架构阶段模型类型候选规模延迟目标作用召回Bi-Encoder ANN百万级 → top-50~10050ms快速缩小范围精排Cross-Encodertop-50~100 → top-3~5100-500ms精确排序去冗余MMRtop-3~510ms提升信息密度这个架构的关键洞察是召回阶段允许漏掉一些但精排阶段必须捞回来。所以召回阶段的top-k不能设太小一般50起步100更稳妥。我见过有人召回只取top-10就上Reranker结果Reranker再强也救不回来——真正相关的文档压根没进候选集。2.4 一个容易忽略的细节Reranker的输入长度Cross-Encoder的输入是querydoc拼接总长度受模型最大序列长度限制。bge-reranker系列一般是512有些模型支持到8192。如果你的文档chunk切得比较长比如1000 token拼接后超长会被截断截断的位置很关键——如果关键信息在文档后半段被截掉了Reranker的分数就会失真。我的经验是Reranker的输入文档chunk控制在256-512 token之间最合适。太短信息不全太长截断风险高且推理慢。这反过来也约束了你的切分策略——切分和重排是联动的不能分开设计。3. Reranker模型选型与本地部署实战3.1 主流Reranker模型横向对比选型这件事没有绝对答案取决于你的场景中文还是英文、有没有GPU、延迟要求多严、能不能联网。模型语言参数量特点适用场景bge-reranker-base中英1.1亿平衡社区成熟通用首选bge-reranker-large中英3.4亿精度更高慢质量优先bge-reranker-v2-m3多语言5.7亿多语言强支持长文本多语言场景Cohere Rerank多语言闭源API调用免部署无GPU、快速上线Jina Reranker多语言闭源/开源API本地都有灵活Qwen3-Reranker中英0.6B/4B中文强新中文场景我个人的建议中文场景优先试bge-reranker-v2-m3或Qwen3-Reranker英文场景bge-reranker-base够用。如果完全没有GPU、又不想折腾部署Cohere的API是最省事的但要注意数据出境的合规问题这个自己评估。3.2 为什么考虑llama.cpp GGUF如果你要在本地跑Reranker尤其是想在CPU或者边缘设备上跑llama.cpp GGUF格式是一条很实用的路线。llama.cpp是一个用C/C写的推理引擎专门为消费级硬件优化支持CPU、Metal苹果、CUDA、Vulkan等多种后端。GGUF是它用的模型格式特点是量化友好支持Q4、Q5、Q8等多种量化等级模型体积能压到原来的1/4甚至更小单文件一个.gguf文件包含权重和元数据部署简单内存映射加载快内存占用可控跨平台Windows、Linux、macOS、Android都能跑对于Reranker这种小模型高并发的场景llama.cpp的优势很明显不需要装PyTorch那一大堆依赖一个二进制文件加一个模型文件就能跑启动快、内存省。但这里有个大坑要先说清楚不是所有Reranker模型都能直接转成GGUF。GGUF格式对模型架构有要求必须是llama.cpp支持的架构LLaMA、Qwen、BERT类等。bge-reranker-base是BERT架构llama.cpp对BERT的支持是后来才加的早期版本跑不了。所以转之前一定要确认你的llama.cpp版本支持目标架构。3.3 从HuggingFace模型到GGUF的完整转换流程假设你选定了bge-reranker-v2-m3想转成GGUF在本地跑。完整流程如下。第一步准备环境# 克隆llama.cpp git clone https://github.com/ggerganov/llama.cpp cd llama.cpp # 编译以CPU为例有CUDA加-DGGML_CUDAON cmake -B build cmake --build build --config Release -j # 安装Python依赖 pip install -r requirements.txt第二步下载原始模型# 用huggingface-cli下载 pip install huggingface_hub huggingface-cli download BAAI/bge-reranker-v2-m3 --local-dir ./bge-reranker-v2-m3第三步转换为GGUFllama.cpp提供了转换脚本但注意——Reranker模型的转换和普通生成模型不一样。普通模型转完是能生成文本的Reranker转完是要输出相关性分数的。llama.cpp对Reranker的支持是通过--reranking参数启用的。# 转换需要指定模型类型 python convert_hf_to_gguf.py ./bge-reranker-v2-m3 \ --outfile bge-reranker-v2-m3-f16.gguf \ --outtype f16如果转换脚本报错说不支持这个架构说明你的llama.cpp版本太老需要更新到最新版。bge-reranker-v2-m3是XLM-RoBERTa架构llama.cpp较新版本才支持。第四步量化可选但推荐# 量化到Q8_0体积减半精度损失很小 ./build/bin/llama-quantize \ bge-reranker-v2-m3-f16.gguf \ bge-reranker-v2-m3-q8_0.gguf \ Q8_0 # 或者更激进的Q4_K_M体积更小但精度有损 ./build/bin/llama-quantize \ bge-reranker-v2-m3-f16.gguf \ bge-reranker-v2-m3-q4_k_m.gguf \ Q4_K_M量化等级的选择有个经验法则Reranker对量化比生成模型更敏感。因为生成模型输出的是token概率分布稍微扰动一下还能选出合理的token而Reranker输出的是一个标量分数量化误差会直接影响排序。所以Reranker建议至少Q8_0Q4_K_M要实测对比排序结果再决定。第五步启动Reranker服务./build/bin/llama-server \ -m bge-reranker-v2-m3-q8_0.gguf \ --reranking \ --host 0.0.0.0 \ --port 8080 \ -c 512 \ -np 4关键参数说明--reranking启用重排序模式这是必须的不加的话模型会当成生成模型用输出一堆乱码-c 512上下文长度Reranker的querydoc拼接不能超过这个值-np 4并行槽位数影响并发处理能力启动后调用方式是一个POST请求curl http://localhost:8080/rerank \ -H Content-Type: application/json \ -d { query: MMR的lambda参数怎么调, documents: [ MMR通过调节λ平衡相关性与多样性λ0.5是常用起点, RAG系统需要向量数据库支持, Cross-Encoder精度高于Bi-Encoder ] }返回的是每个文档的相关性分数按分数排序即可。3.4 那个让人抓狂的no lm runtime found for model format gguf错误这个报错在社区里出现频率极高我至少见过几十个人问。它的字面意思是找不到处理gguf格式的运行时但根因有好几种得逐个排查。原因一llama.cpp版本太老早期版本的llama.cpp只支持GGML格式不支持GGUF。GGUF是2023年8月才引入的。如果你的代码是更早的版本就会报这个错。解决方法是更新到最新版。原因二用了错误的加载方式有些人把GGUF模型当成普通模型加载比如用llama-cpp-python的Llama类去加载Reranker模型或者用AutoModelForCausalLM.from_pretrained去加载GGUF。GGUF不是HuggingFace的标准格式这些接口不认。Reranker必须用支持reranking的接口。原因三模型架构不被支持即使llama.cpp版本够新如果模型架构不在支持列表里也会报类似的错。比如某些自定义架构的Rerankerllama.cpp压根没有对应的实现。这时候只能换模型或者用其他推理框架比如ONNX Runtime、vLLM。原因四文件损坏或下载不完整GGUF文件下载中断会导致文件头损坏加载时报格式错误。用sha256sum对比一下官方提供的哈希值。排查顺序建议先确认版本再确认加载方式再确认架构支持最后查文件完整性。这个顺序能覆盖90%的情况。3.5 不用llama.cpp的替代方案如果llama.cpp这条路走不通还有几个选择ONNX Runtime把模型导出成ONNX用onnxruntime推理。跨平台好但Reranker的导出需要处理分类头稍微麻烦。vLLM如果你有GPUvLLM支持Reranker模型吞吐量很高适合高并发场景。Text Embeddings Inference (TEI)HuggingFace出的推理服务专门为embedding和reranker优化部署简单性能好。直接PyTorch最原始的方式transformers加载模型手动跑前向。灵活但性能一般适合原型验证。我的实际选择逻辑是原型阶段用PyTorch快速验证生产环境有GPU用TEI或vLLM无GPU用llama.cpp。4. MMR去冗余让上下文窗口装下更多有效信息4.1 冗余是怎么产生的Reranker把最相关的文档排到前面了但最相关不等于最互补。考虑一个场景用户问Ch09里Reranker和MMR怎么配合向量检索召回了5篇文档Reranker打分后top-5是文档A讲Reranker原理提到MMR0.92分文档B讲Reranker原理措辞不同0.90分文档C讲Reranker原理又是另一个版本0.89分文档D讲MMR原理0.85分文档E讲Reranker和MMR的配合0.83分A、B、C三篇高度重复全塞给大模型等于浪费了2/3的上下文窗口而真正讲配合的E反而排在最后。大模型看到三篇重复内容容易陷入复读或者被冗余信息干扰。MMR就是来解决这个问题的。它的核心思想是选下一篇文档时既要它和查询相关又要它和已选文档不重复。4.2 MMR的数学形式与直觉MMR的打分公式MMR argmax_{d_i ∈ R\S} [ λ · sim(d_i, q) - (1-λ) · max_{d_j ∈ S} sim(d_i, d_j) ]拆解一下R是候选文档集S是已选文档集sim(d_i, q)是文档i和查询的相关性就是Reranker的分数max sim(d_i, d_j)是文档i和已选文档中最相似的那篇的相似度λ是平衡参数0到1之间直觉上第一项鼓励选相关的第二项惩罚选重复的。λ越大越偏向相关性λ越小越偏向多样性。λ的取值很关键λ1退化成纯相关性排序MMR失效λ0只追求多样性可能选出完全不相关的文档λ0.5平衡点常用起点λ0.7偏相关性适合问答场景答案通常集中在少数文档λ0.3偏多样性适合综述、调研场景我的经验是问答类RAG用0.6-0.7摘要/综述类用0.4-0.5。这个参数没有理论最优必须用你的实际数据调。4.3 相似度用什么算MMR公式里的sim有两个查询-文档相似度和文档-文档相似度。查询-文档相似度直接用Reranker的分数就行但要注意归一化——Reranker输出的分数范围因模型而异有的是logits可能负几十到正几十有的是sigmoid后的0-1。MMR要求两个相似度在同一量纲上所以必须先把Reranker分数归一化到0-1。文档-文档相似度则用embedding的余弦相似度。这里有个细节用哪个embedding可以用召回阶段用的那个Bi-Encoder的向量因为已经算好了直接复用零额外成本。也可以用另一个专门的embedding模型但没必要召回模型的向量质量通常够用。import numpy as np def mmr_select(query_scores, doc_embeddings, top_k5, lambda_0.6): query_scores: 归一化后的相关性分数shape (n,) doc_embeddings: 文档向量shape (n, d)已归一化 top_k: 选出的文档数 lambda_: 平衡参数 n len(query_scores) selected [] candidates list(range(n)) # 先选相关性最高的 first int(np.argmax(query_scores)) selected.append(first) candidates.remove(first) while len(selected) top_k and candidates: best_score -np.inf best_idx -1 for i in candidates: # 相关性项 rel query_scores[i] # 冗余项和已选文档的最大相似度 sims [np.dot(doc_embeddings[i], doc_embeddings[j]) for j in selected] redundancy max(sims) # MMR分数 mmr lambda_ * rel - (1 - lambda_) * redundancy if mmr best_score: best_score mmr best_idx i selected.append(best_idx) candidates.remove(best_idx) return selected这段代码是MMR的标准实现。注意几个点第一个文档直接选相关性最高的因为此时没有已选文档冗余项为0每次迭代遍历所有候选计算MMR分数选最高的复杂度是O(k·n·k)k是选出数量n是候选数量。对于k5、n50完全可接受4.4 一个容易踩的坑归一化方式Reranker分数归一化这件事我踩过坑。最开始我用min-max归一化scores_norm (scores - scores.min()) / (scores.max() - scores.min())结果发现如果候选集里有一篇分数特别高、其他都很低min-max会把其他文档压到接近0MMR的多样性项就失效了。后来改用sigmoidscores_norm 1 / (1 np.exp(-scores))sigmoid的好处是保序且平滑不会因为极值把其他分数压扁。但sigmoid对logits的尺度敏感如果logits范围是-20到20sigmoid后大部分会挤在0或1附近。所以更稳妥的做法是先看Reranker输出的实际分布再决定归一化方式。如果Reranker本身输出就是0-1比如用了sigmoid激活那直接用不用再归一化。bge-reranker系列默认输出logits需要自己处理。5. 把Reranker和MMR串成一条流水线5.1 完整流程的代码骨架前面分开讲了Reranker和MMR现在把它们串起来。假设你已经有了一个向量库比如Milvus、Qdrant、FAISS召回接口返回top-50的文档和向量。import requests import numpy as np class RerankMMRPipeline: def __init__(self, rerank_url, lambda_0.6, recall_k50, final_k5): self.rerank_url rerank_url self.lambda_ lambda_ self.recall_k recall_k self.final_k final_k def rerank(self, query, docs): 调用llama.cpp的rerank接口 resp requests.post( f{self.rerank_url}/rerank, json{query: query, documents: docs} ) results resp.json()[results] # 按分数排序 results.sort(keylambda x: x[relevance_score], reverseTrue) return results def normalize(self, scores): sigmoid归一化 scores np.array(scores) return 1 / (1 np.exp(-scores)) def mmr(self, query_scores, embeddings, top_k): MMR选择 n len(query_scores) selected [] candidates list(range(n)) first int(np.argmax(query_scores)) selected.append(first) candidates.remove(first) while len(selected) top_k and candidates: best_score -np.inf best_idx -1 for i in candidates: rel query_scores[i] redundancy max( np.dot(embeddings[i], embeddings[j]) for j in selected ) mmr self.lambda_ * rel - (1 - self.lambda_) * redundancy if mmr best_score: best_score mmr best_idx i selected.append(best_idx) candidates.remove(best_idx) return selected def run(self, query, recalled_docs, recalled_embs): recalled_docs: list[str]召回阶段返回的文档文本 recalled_embs: np.ndarray对应的向量已归一化 # 1. Rerank rerank_results self.rerank(query, recalled_docs) # 2. 按rerank顺序重排文档和向量 ordered_docs [] ordered_embs [] ordered_scores [] for r in rerank_results: idx r[index] ordered_docs.append(recalled_docs[idx]) ordered_embs.append(recalled_embs[idx]) ordered_scores.append(r[relevance_score]) # 3. 归一化分数 norm_scores self.normalize(ordered_scores) # 4. MMR选择 selected_idx self.mmr( norm_scores, np.array(ordered_embs), self.final_k ) return [ordered_docs[i] for i in selected_idx]这个骨架可以直接用但有几个地方要根据实际情况调整。5.2 召回数量、精排数量、最终数量的配比这三个数字的配比是有讲究的不是随便定的。召回数量recall_k建议50-100。太小会漏太大会让Reranker变慢。如果你的向量库支持可以先召回100Reranker只跑前50因为向量检索的top-50通常已经覆盖了大部分相关文档这样能省一半推理时间。精排数量等于召回数量因为Reranker要对所有候选打分。如果召回100Reranker就要跑100次前向。最终数量final_k3-5。这是喂给大模型的文档数。太少信息不全太多浪费上下文且引入噪声。具体取决于你的chunk大小和模型上下文窗口。如果chunk是256 token模型上下文8k那final_k可以到10如果chunk是512 tokenfinal_k建议3-5。延迟估算假设Reranker单次推理50msGPU或200msCPU量化召回50篇GPU50 × 50ms 2.5秒串行或 500msbatch10并行CPU50 × 200ms 10秒串行或 2秒batch10并行所以batch推理是必须的。llama.cpp的rerank接口支持一次传多个文档内部会batch处理。如果你的推理框架不支持batch那就要自己控制并发。5.3 缓存策略哪些能缓存哪些不能Reranker和MMR的缓存策略不一样。Reranker不能缓存查询-文档对因为每个查询都是新的。但可以缓存文档的编码——不过Cross-Encoder没有独立的文档编码所以这条不成立。MMR的文档-文档相似度可以缓存。因为文档向量是固定的任意两篇文档的相似度是常量。如果你的文档库不大比如几千篇可以预先算好相似度矩阵MMR时直接查表省去重复计算。查询级别的缓存如果同一个查询被反复问比如FAQ场景可以缓存整个流水线的结果。用查询的hash做key结果做value设个TTL。from functools import lru_cache import hashlib lru_cache(maxsize1000) def cached_pipeline(query_hash, query): # 实际流水线逻辑 ...注意lru_cache的key要包含query_hash因为query本身可能很长直接做key占内存。5.4 实测中的意外情况情况一Reranker把正确答案排到了后面我遇到过Reranker分数和人工判断不一致的情况。排查后发现是文档chunk切分有问题——关键信息被切到了两个chunk里每个chunk都不完整Reranker看到的是半截信息自然打不出高分。解决办法是调整切分策略用重叠切分overlap保证关键信息至少在一个chunk里完整出现。情况二MMR选出了不相关的文档λ设得太小比如0.3MMR为了多样性选了和查询关系不大的文档。解决办法是把λ调回0.6以上或者给相关性项设一个下限——低于某个分数的文档直接排除不参与MMR。情况三延迟波动大Reranker的延迟和输入长度强相关。如果文档长度参差不齐短文档50ms、长文档300ms总延迟就会波动。解决办法是统一chunk长度或者对超长文档先截断再送Reranker。情况四llama.cpp的并发瓶颈llama.cpp的-np参数控制并行槽位但每个槽位是独立的上下文。如果并发请求超过槽位数请求会排队。生产环境要根据QPS调整-np或者部署多个实例做负载均衡。6. 参数调优与效果评估6.1 怎么判断Reranker有没有起作用最直接的方法是对比实验同一批查询分别用纯向量检索top-5和向量检索top-50 Reranker MMR top-5跑看最终答案的质量。评估指标可以用命中率Hit Rate正确答案是否在最终top-k里MRRMean Reciprocal Rank正确答案排名的倒数的均值NDCG考虑排序位置的加权指标如果这些指标没有提升说明Reranker没起作用可能的原因召回集里压根没有正确答案召回问题、Reranker模型不适合你的领域模型问题、或者chunk切分有问题数据问题。6.2 λ参数的网格搜索λ没有理论最优只能实验。做法是固定其他参数λ从0.3到0.9以0.1为步长跑一遍看哪个λ在你的评估集上指标最好。for lambda_ in [0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9]: pipeline RerankMMRPipeline(rerank_url, lambda_lambda_) score evaluate(pipeline, test_queries) print(flambda{lambda_}, score{score})注意λ的最优值和你的评估集强相关。如果你的评估集里问题都比较集中答案在少数文档里λ偏大更好如果问题发散λ偏小更好。所以评估集要尽量覆盖真实场景的查询分布。6.3 量化等级对排序质量的影响前面提到Reranker对量化敏感这里给个实测参考。用bge-reranker-base在同一个评估集上跑量化等级模型体积单次推理(CPU)NDCG5相对F16F16220MB180ms0.847基准Q8_0115MB120ms0.845-0.2%Q5_K_M80MB95ms0.838-1.1%Q4_K_M65MB80ms0.821-3.1%可以看到Q8_0几乎无损Q4_K_M有3%左右的损失。对于Reranker这种排序任务3%的NDCG损失可能意味着top-5里少了一篇关键文档所以建议至少Q8_0。如果硬件实在受限必须用Q4那要实测确认排序结果没有明显劣化。6.4 一个反直觉的发现Reranker不是越多越好我一度以为Reranker的候选集越大越好后来发现不是。当召回数量从50增加到200时Reranker的延迟翻了4倍但NDCG只提升了不到1%。原因是向量检索的top-50已经覆盖了绝大多数相关文档后面的150篇大多是长尾噪声Reranker再强也捞不出金子。所以我的建议是召回50-100Reranker跑全部MMR选top-5。这个配置在延迟和质量之间比较平衡。如果你的场景对延迟极其敏感可以召回100但Reranker只跑前30牺牲一点召回率换速度。7. 生产环境部署的几个实际问题7.1 Reranker服务的资源规划Reranker是计算密集型服务资源规划要看QPS和延迟要求。假设单次Reranker推理batch10每篇256 token在GPU上耗时100ms那么单卡理论QPS是10。如果业务QPS是50就需要5张卡或者5个实例。CPU场景下Q8_0量化的bge-reranker-base单次推理约120msbatch10约500ms单实例QPS约2。要支撑50 QPS需要25个实例成本很高。所以CPU只适合低QPS场景高QPS必须上GPU。7.2 降级策略Reranker服务挂了怎么办不能整个问答系统就瘫了。降级策略一级降级Reranker超时比如超过500ms直接用向量检索的top-5跳过Reranker和MMR二级降级Reranker服务不可用用向量检索top-5 简单的去重比如按文档ID去重三级降级向量库也不可用返回预设的兜底回答降级要打日志和监控方便事后分析。7.3 监控指标生产环境要监控这些指标Reranker P99延迟超过阈值告警Reranker错误率接口报错比例MMR选中文档的平均相似度如果太高说明去冗余没起作用λ可能设小了最终答案的采纳率用户是否满意这是终极指标7.4 一个真实的踩坑模型版本不一致有次线上Reranker效果突然变差排查了半天发现是部署时用了不同版本的模型文件。测试环境用的是bge-reranker-v2-m3线上误部署成了bge-reranker-base两者分数分布不一样MMR的归一化和λ都失配了。教训模型文件要版本化管理部署时校验hash。GGUF文件尤其要注意因为文件名可能一样但内容不同。8. 一些零散但重要的经验8.1 关于llama.cpp的Android版社区里有人问llama.cpp能不能在Android上跑Reranker。技术上可以llama.cpp有Android的编译支持但实际意义不大——手机端算力有限Reranker推理慢而且Reranker通常是服务端组件没必要放端上。如果真要在端上做检索用轻量的Bi-Encoder做召回就够了Reranker留给服务端。8.2 GGUF模型下载的注意事项GGUF模型文件通常比较大下载容易中断。建议用支持断点续传的工具比如huggingface-cli自带下载后校验SHA256国内下载HuggingFace可能慢可以用镜像站自己找合规的8.3 Reranker和生成模型的显存竞争如果Reranker和生成模型部署在同一张卡上要注意显存竞争。Reranker推理时会占用显存如果生成模型也在跑可能OOM。解决办法是分开部署或者用显存隔离比如MPS。8.4 关于reranker模型和reranker的搜索差异社区里搜reranker和reranker模型结果不太一样。前者更多是英文资料和代码后者更多是中文教程。如果你在找中文实践用reranker模型搜更有效。这个细节看似无关紧要但能帮你更快找到对口的资料。8.5 最后分享一个调试技巧Reranker效果不好的时候不要急着换模型。先把Reranker的输入输出打出来看query是什么、doc是什么、分数是多少。很多时候问题出在输入上——query被截断了、doc里有大量无关的HTML标签、或者拼接格式不对。我遇到过doc里混进了导航栏文本Reranker被这些噪声干扰分数全乱。清理输入后效果立刻正常。这个技巧适用于所有RAG组件先看输入再看输出最后才怀疑模型。