做企业智能知识库的这两年我几乎每个月都要和 Rerank 重排序打交道。同事经常问“向量召回 Top50 都出来了为什么还要再做一次排序”这个问题的答案直接决定了一套 RAG 检索链路是“能用”还是“好用”。今天不聊理论只聊我在生产环境里把重排序真正落到知识库检索链路上时踩过的坑、验证过的方案以及模型选型、部署、评估、排障这几个环节沉淀下来的实操经验。这篇内容适合正在搭或者已经上线 RAG 知识库的研发、算法、架构同学。如果你现在的知识库只有几十篇文档随便排序都不会太差但一旦文档数量上千、分块上万几乎必然要面对“召回里啥都有排在前面的却总不对”的尴尬。后面我会用一个真实案例作为切入点讲清楚为什么 Rerank 不是加分项而是必答题再给出可以直接抄作业的落地路径和排障清单。1. 为什么知识库里的 Rerank 不是可选项而是一道必答题1.1 一次真实问答事故答案明明在库里LLM 就是看不到有一次 HR 在知识库里问“离职补偿金怎么算”。Embedding 召回 Top50 之后按余弦相似度排在最前面的几段全是“离职流程”“交接手续”这类标题相关、内容不相关的文档。真正的答案在一份《员工离职管理细则》的表格段落里却排在第 12 位。而 LLM 默认只取前 4 段拼答案结果输出了一段完全不符合劳动法常识的内容。这个案例不是个例。我们抽了 100 条真实业务问题做离线评估Top5 命中正确文档的比例只有 16%。这里说的“命中”指的是正确答案所在的块能排进前 5。16% 意味着在绝大多数问题里LLM 在动手生成之前就已经没有机会看到正确答案。员工问到的不是冷门条款而是离职补偿这种高频问题这已经不是“体验不好”而是知识库在核心场景上不可用。1.2 召回负责粗筛重排负责精排为什么向量召回会产生这种问题核心原因是 embedding 模型的结构限制。向量召回常用双塔模型query 和 document 分别编码成向量再算余弦相似度。这个过程中词与词之间的交互信息被压缩成了一个固定维度的向量很多东西必然丢失。“离职补偿金”和“离职流程”在向量空间里距离很近因为它们的主题词高度重合但语义重心完全不同。Rerank 模型通常是交叉编码器Cross-Encoder做法是把 query 和 passage 拼在一起作为一个整体输入 Transformer让每个词都能和另一边的所有词做注意力交互。这个“深度交互”能力决定了它能比双塔模型更细致地判断“这句话到底是不是用户想要的答案”。生活里做个类比向量召回是海选简历只看技能标签和关键词Rerank 是面试官要综合看项目经历、表达方式和岗位匹配度。企业知识库的文档里大量正确信息藏在长句、表格、同义改写后面没有这一层“面试”海选出来的排序很难直接用。1.3 混合召回也解决不了排序问题很多人以为加了 BM25 混合召回Rerank 就可以先不上。我一开始也这么想。我们当时的链路是 “embedding Top30 BM25 Top20 去重”覆盖问题确实改善了不少召回率明显上去了。但业务反馈依然集中在同一个点正确内容捞进来了就是排不上去。原因也很好理解。混合召回解决的是“候选是否出现”的覆盖问题说白了是“有没有”而 Rerank 要解决的是“哪一个最有用”是“优不优”。企业知识库里有大量的同主题文档制度文件 V1、V2、V3 并存FAQ 里有重复表达销售话术和培训材料讲的是同一件事。这时候召回阶段会把所有“看起来沾边”的都给你但排序依然可能把所有标题相近、内容次要的文档放在前排。只有真正会读内容的交叉编码器才能在“都相关”的文档里排出“最有用”的优先级。1.4 判断该不该上 Rerank 的三个信号到底什么时候该上 Rerank我的判断标准有三个离线评估里 Top5 命中率持续低于 70%且问题不是出在分块质量上业务方频繁反馈“检索不到”“给了错的文档”而不是“回答太啰嗦”这类生成层问题知识库规模已经到了上千个分块同主题、同关键词文档大量存在。反过来也要说一句如果你的知识库只有几百篇文档问题场景非常垂直先别急着上 Rerank。优先去做分块优化和召回调参很多问题在更早的环节就能解决。重排是增加复杂度的模型部署、阈值维护、版本升级都要持续投入简单系统强行上重排只会给自己找事。2. Rerank 模型选型与部署动手前先想清楚的三个决策2.1 自部署模型怎么选效果、成本与约束目前企业知识库场景里开源自部署最常用的是 BGE 系列 Rerank 模型。我梳理过一张对比表方便快速决策模型参数量约推理相对速度最适合场景备注bge-reranker-base278M快大多数中文企业知识库FP16 显存需求低优先选择bge-reranker-large560M中对长尾细节要求极高、硬件充足精度高但延迟和成本明显上升bge-reranker-v2-m3560M中多语言、跨语种、超长上下文检索上下文长度 8192分数尺度与 base 不同托管 API如 Cohere Rerank依赖服务商取决于网络不想运维 GPU、数据可出内网按量付费需要评估数据合规企业知识库场景我通常优先推荐 bge-reranker-base。原因是多数知识库文档是中文文本base 模型在通用中文问答上的表现已经够用而且 FP16 权重只有 0.6GB 左右单张 T4 就能轻松跑起来。bge-reranker-large 精度更高但如果你的知识库是面向全公司的通用问答base 带来的性价比更合适。只有当业务对答案准确率的容忍度极低且硬件资源充足时才值得上 large。至于托管 API优势是省运维效果也很稳定。但企业知识库数据往往涉及内部制度、客户信息、财务数据数据是否允许出内网本身就是一道红线。即便合规上没问题高频调用下的按量费用也很可观。所以我们在实际项目里几乎都是私有化部署开源模型。2.2 版本差异和“要不要微调”BGE 系列不同版本之间有一个容易忽略的点分数分布不统一。bge-reranker-base 和 bge-reranker-v2-m3 输出分数的尺度、集中区间都不一样甚至同一个 query 在不同版本下的绝对分差了 0.3 都不奇怪。这直接带来的后果是换模型版本之前调好的阈值基本作废必须重新采集分数分布、重新定阈值。后面第 4 章会专门讲这个坑。另一个决策是“要不要微调”。通用 Rerank 模型在大部分业务场景里已经可用但以下情况建议微调领域专有词特别多比如法务、医疗、金融条款“通用模型”经常把表面相关但实质无关的内容排得很高检索对象包含大量表格、代码片断、半结构化数据模型没见过类似写法已经有用户点击、人工反馈等高质量正负样本沉淀。微调的做法你可以在社区里找到很多方案核心是构造 query 与正负 passage 样本使用交叉编码器的排序损失训练。需要提醒的是如果通用模型连“正确块进入 Top10”都做不到问题多半出在召回或分块层微调重排意义不大。微调重排最有效的场景是“正确答案已经在 Top10 里但进不了 Top5”。我还见过一上来就砸几百条标注去微调的团队效果反而不如通用模型。原因就是样本质量太差负样本全是“完全不相关”而没有“表面相关实质不相关”的困难样本。这类困难样本才是 Rerank 微调最需要学习的对象。2.3 部署形态与显存规划部署 Rerank 服务前先把显存算清楚。FP16 权重大概是“参数量 × 2 字节”base 约 0.56GBlarge 约 1.1GB。推理时还要加上激活值这个取决于 batch size 和最大序列长度。以我常用的 base 模型为例一次处理 16 对、每对最长 512 token 的请求峰值显存在 2~3GB 左右16GB 的 T4 完全能扛住留出大量余量。不过这里我有一个很实际的经验Rerank 服务最好不要和 embedding 模型共用同一个 GPU。两个模型同时推理会互相抢占显存和算力高峰时两边延迟一起劣化。我们最初为了省机器把两个模型塞在一张卡上结果线上 P99 延迟从 90ms 飙到 600ms排查了半天才发现是显存抖动和算力竞争。后来拆成独立服务即使共用一台物理机也给 Rerank 单独分配了一张 GPU 或至少独立的计算队列问题才解决。部署形态上Rerank 内部用 HTTP 服务暴露接口就可以。请求字段就两个query 和 docs 列表返回排好序的结果。超时时间建议控制在 200~500ms 这个量级避免下游 LLM 等待过久。召回候选如果超过 100 条不建议一次全塞给 Rerank先做一轮粗筛再重排既省时间又省显存。3. Rerank 落地实践在线重排服务与离线评估完整实现3.1 把 Rerank 快速包装成在线服务我用 FastAPI 封装重排服务的代码很简单核心就几十行。先装依赖pip install -U FlagEmbedding fastapi uvicorn gunicorn然后写服务文件# rerank_server.py from typing import List from fastapi import FastAPI, HTTPException from pydantic import BaseModel from FlagEmbedding import FlagReranker app FastAPI() model FlagReranker(/models/bge-reranker-base, use_fp16True) class RerankRequest(BaseModel): query: str docs: List[str] top_k: int 5 app.post(/rerank) def rerank(req: RerankRequest): if not req.docs: raise HTTPException(status_code400, detaildocs不能为空) pairs [[req.query, doc] for doc in req.docs] scores model.compute_score(pairs, normalizeTrue) items list(zip(req.docs, scores)) items.sort(keylambda x: x[1], reverseTrue) return { items: [ {text: text, score: float(score)} for text, score in items[: req.top_k] ] }这个服务只需要一个 GPU worker。启动命令gunicorn -k uvicorn.workers.UvicornWorker rerank_server:app -w 1 --threads 4 --timeout 10这里故意用单进程多线程而不是多进程。多进程模式下每个进程都会把模型加载一份到显存显存翻倍不说还容易造成 GPU 资源竞争。PyTorch 在做 GPU 推理时会释放 GIL多线程能在一定程度上并行进入 forward吞吐量够用。线程数也不要拍脑袋开太大先从 2 到 4 开始压测观察显存和延迟再慢慢往上加。如果候选数量很大可以在服务端内部再按 batch 循环处理但单次请求 docs 列表最好限制在 100 条以内防止请求体过大拖垮 HTTP 层。模型权重如果没法访问外网内网环境下可以用 ModelScope 下载到本地目录pip install modelscope python -c from modelscope import snapshot_download; snapshot_download(BAAI/bge-reranker-base, local_dir/models/bge-reranker-base)加载路径换成本地目录部署流程就完全离线了。另外一句提醒早期我用sentence-transformers的CrossEncoder也做过一版效果一样FlagEmbedding 的优势是接口天然针对 pair 打分优化代码更少。3.2 阈值怎么定才不怕模型漂移Rerank 模型输出的是一个相关性分数。我们代码里用了normalizeTrue这是把原始 logits 用 sigmoid 拉到一个 0~1 的范围便于设定统一门槛。但阈值不能拍脑袋写死我的做法是建一个几十到上百条的标注集包含正样本相关块和负样本不相关块让模型先跑一遍记录两组分数分布。举一个真实案例某次我们针对“离职补偿”这类问题建了 60 条正样本、90 条负样本。正样本的分数中位数是 0.72P5 大概是 0.55负样本的中位数是 0.36P95 大概是 0.48。正负分布的重叠区在 0.45~0.55 之间。我们最后把阈值定在 0.5这个值能挡住绝大多数负样本同时很少误杀正样本。低于阈值的块就不让进入 LLM 上下文直接回答“未找到相关内容”并触发转人工。没有标注集的时候也可以用历史查询分数分布的 P5 作为临时拒绝线但必须尽快补标注集。这里要特别强调阈值只是护栏不是精确裁决器。它解决的是“明显不相关的候选不要混进上下文”而不是“判断哪一条是最佳答案”。Rerank 之后的 Top 排序结果仍然要交给 LLM 或后续业务逻辑去综合判断。3.3 在 RAG 链路里放在哪个位置最合理Rerank 在 RAG 链路中的位置非常固定整体顺序如下用户 query 进入embedding 检索和 BM25 检索并行执行合并两路结果并去重得到候选块集合通常控制 in Top50~100将 query 和全部候选块发送给 Rerank 服务一次批量打分过滤低于阈值的块截断到 TopK通常 3~8 条将最终块列表拼入 LLM 上下文生成答案并附带引用来源。放在这个位置有一个极大的好处Rerank 和 embedding 模型是解耦的。embedding 模型负责构建向量索引Rerank 只对“已经召回的候选”打分因此换 Rerank 模型完全不需要重建索引灰度成本和试错成本都非常低。还有一个细节要注意候选集合应该尽量是“块级”而不是“文档级”。很多 Rerank 落地翻车问题就出在先用某个代表块重排文档再进文档里取内容。这个坑会在第四章详细展开。简单说块级重排更可靠因为正确答案往往不在文档的标题块或开头块里。最后说说 TopK 给多少。我们在大多数内部知识库场景中用 5~6 条。给太少容易漏答案给太多会稀释 LLM 的注意力上下文占用也更大。如果你的 LLM 上下文窗口很长可以放宽到 8~10 条但要在 Prompt 里明确提示“优先参考排序靠前的材料”否则效果大概率会打折扣。3.4 100 条标注集就能做的离线回归重排序效果的评估不需要一开始就做得非常复杂。我们内部就是一张简单的标注表字段就四列query_id、doc_id、relevance0 不相关、1 部分相关、2 完全相关。手工标注 100~300 条就能算出一组可靠的指标。我常用的指标是 NDCG5、MRR 和 RecallK。NDCG 能反映排序质量MRR 关注第一个正确答案的位置Recall 关注正确答案是否被召回。重排阶段主要看 NDCG 和“Top1 命中率”。我写了一个轻量函数import numpy as np def ndcg_at_k(scores, labels, k5): order np.argsort(scores)[::-1][:k] dcg 0.0 for i, idx in enumerate(order): rel labels[idx] dcg (2 ** rel - 1) / np.log2(i 2) ideal np.sort(labels)[::-1][:k] idcg 0.0 for i, rel in enumerate(ideal): idcg (2 ** rel - 1) / np.log2(i 2) return dcg / idcg if idcg 0 else 0.0跑评估的时候把标注集的候选块全部过一遍重排服务得到每个 query 的分数列表再和人工标注的 relavance 列表一起算出 NDCG5。这个流程不仅是模型选型的依据也是每次换模型、改参数之后必跑的回归测试。我们对版本迭代有一个硬性要求NDCG5 不能比线上版本低 1 个百分点否则不许上线。4. Rerank 踩坑实录六个让我通宵排障的典型问题4.1 坑一长文本拼接被截断结论直接被截没了我第一次接重排服务后第一周就遇到一个诡异的问题明明答案在文档后半部分重排分数却非常低怎么调都调不上去。后来打开模型 tokenizer 一看bge-reranker-base 的最大序列长度是 512而文档块经常超过这个长度。拼接后的序列默认从头截断后半段的结论根本没参与打分。这个坑的根因在分块阶段不在重排阶段。解决办法有几个层面把知识库分块长度控制在 500 字以内换算成 token 约 400 以内留出 query 的拼接空间如果某些长块无法避免就做“滑窗重排”把一块拆成多个不超过长度限制的片段分别打分取片段最高分作为整块的得分预算充足的话可以换用 bge-reranker-v2-m3它支持 8192 上下文长文场景几乎不会再被截断。我最推荐第一种。分块优化是所有检索链路的地基重排只是锦上添花。一个 800 字的长块无论重排模型多强都难以准确判断“哪一截才是用户要的答案”。4.2 坑二文档级重排把正确答案整丢了有段时间我们为了让重排候选更清爽先对每个文档挑一个“代表块”一般取第一个块做重排选出 Top10 文档再进这些文档里取更多块。结果发现很多问题明明文档里有正确答案最终还是答错。原因是“代表块”根本代表不了整篇文档。很多制度文件的第一个块是标题、适用范围和名词解释真正的条款在文档中后部。代表块分数低整篇文档就被刷掉了后面再做什么都白搭。正确做法是如果候选集合已经是块级召回结果就直接在块级上重排不要多做一层文档筛选。如果一定需要先选文档也绝不能只取“第一个块”做代表而要对文档内所有块都打分取最大分或前几个高分块的平均分作为文档分。这个经验后来被我写进了团队规范Rerank 的输入永远是块不是文档。4.3 坑三batch_size 调大精度反而变差为了提升吞吐我曾经把 batch size 从 8 调到 64结果离线评估 NDCG 反而降了一点。排查过程很痛苦因为模型代码、请求链路都没变最后发现问题出在 padding 上。Rerank 是交叉编码器输入是 query 和 passage 的拼接序列。一个 batch 里不同 pair 长度差异很大时短序列会被 pad 到跟最长的序列一样长。padding 比例越高模型打分时受到的干扰越大。batch 越大这种“不齐”的情况越严重精度自然会往下掉。解决办法是动态长度分桶。在服务端把所有候选 pair 按序列长度排序相近长度的放进同一个 batch这样 padding 的浪费最小打分精度也最稳。我们还在日志里加了total_padding_ratio这个指标如果某个请求的 padding 占比超过 30%就会触发告警去查是不是分块长度又失控了。4.4 坑四升级模型后阈值集体失效有一段时间我们打算把 bge-reranker-base 升级到 bge-reranker-v2-m3理由是它能处理更长上下文。上线前跑了一遍评估集NDCG 确实是升的于是直接切换。结果第二天就收到投诉一批原来能答上的问题突然变成“未找到相关内容”。原因就是分数尺度漂移。v2-m3 的分数经过 sigmoid 归一化后分布区间和 base 完全不同原来定的 0.5 阈值在 v2-m3 下明显偏高大量正样本被卡掉了。我们当时没有做分数分布对比只看了 NDCG 指标等于被“平均效果变好”迷惑了。这件事之后我的操作规范变成任何模型版本切换除了跑评估集还要导出新旧模型在同一个标注集上的分数分布对比 P5、P50、P95 和阈值通过率再决定要不要改阈值。上线后继续监控一周的每日分数分位确认稳定后才摘掉灰度。4.5 坑五并发和跑批任务互相抢资源Rerank 服务上线初期是白天交互为主延迟很漂亮P99 稳定在 80~100ms。后来知识库管理员加了夜间批量任务每天晚上定时把几千条文档做重复处理和交叉验证也会调用同一个 Rerank 服务。结果夜间高峰 P99 直接飙到 900ms白天的缓存数据全部失效第二天早上用户反馈“系统卡成狗”。这次问题的本质不是 Rerank 本身不够快而是没有任何资源隔离和优先级控制。后来我们做了三件事Rerank 服务独立部署不跟批量任务共用同一个 GPU 实例在服务入口加了一个信号量限制最大并发数超过并发上限直接返回 429让调用方退避重试批量任务和在线交互使用不同的请求队列在线请求永远优先。这套改造做完之后P99 延迟重新回到 120ms 以内。虽然批量任务偶尔会被限流但不影响核心体验业务方也没有抱怨。4.6 坑六把重排分数当成了绝对相似度业务方经常拿着 Rerank 的分数来质问我“这两个文档都是一样的主题为什么一个打 0.95另一个只有 0.02”其实这不是模型坏了而是 Rerank 的分数本质上是“一个候选相对其他候选的相关性比较”不是标准的相似度度量。同样一个文档放在不同的候选集合里分数都可能不一样。所以我不建议业务方或者上游链路直接用 Rerank 分数字面值做硬性判断。更可靠的做法是看“分差结构”如果 Top1 和 Top2 的分差超过 0.1说明排序置信度很高可以直接只保留 Top1如果分差很接近就要把多个候选都交给 LLM 综合判断。我们内部管这招叫“分数缝隙法”它在处理模糊领域问答时特别管用。把上面六个坑列成一张速查表方便遇到问题快速对照症状可能根因一句话解法答案在长块后半截但分数低拼接超长被截断控制分块长度或滑窗重排正确文档被刷掉先文档后块、代表块选错直接在块级候选上重排batch 调大后 NDCG 下降padding 比例过大按序列长度动态分桶换模型后阈值失效分数尺度漂移重新评估分布并重定阈值夜间并发延迟雪崩与批量任务抢资源独立部署、限流、优先级队列业务方质疑分数不合理分数是比较性结果看 Top 分差别绝对化5. 效果护航重排链路的可观测性与灰度回归5.1 业务指标引用命中率比 NDCG 更贴近用户感受NDCG 和 MRR 是给算法看的业务方和老板真正关心的是“答案有没有答对”。RAG 场景里我强烈推荐多跟踪一个指标答案引用命中率。它的定义是LLM 生成答案时引用的文档块中是否包含人工标注的正确答案块。这个指标比 NDCG 更贴近真实体验。NDCG 提升 1 个点用户未必感知得到但答案的引用命中率从 60% 提到 65%业务方会明显觉得“系统靠谱了不少”。我们内部每个版本上线前都会统计引用命中率如果低于旧版本哪怕 NDCG 是涨的也不会放行。顺带一提这里有个容易忽略的点LLM 引用的块未必是正确答案块。有时候重排把正确块排到了第 6 位LLM 还是倾向于引用第 1 位。这时候问题可能出在 Prompt 对引用顺序的引导不够不一定是重排的锅。所以“引用命中率”低的时候要先看正确块被重排到了第几再决定改重排还是改 Prompt。5.2 链路日志重排问题定位的关键我踩过的那些坑几乎每一个都靠日志定位。重排服务上线前一定要在链路里埋好结构化日志。这是我们线上日志的一个简化示例{ trace_id: 20250101-abc123, query: 离职补偿金怎么算, model_version: bge-reranker-base-20241201, recall: { total: 46, top5_hit: false }, rerank: { batch: 46, p50_score: 0.34, p95_score: 0.81, top1_score: 0.78, top2_gap: 0.11, latency_ms: 85 }, llm: { prompt_docs: 6, cited_docs: [3, 5] } }recall.total用来观察召回是否突然变少rerank.p50_score用来发现阈值漂移rerank.top2_gap用来判断排序置信度llm.cited_docs用来反查引用命中情况。你不需要一开始就上全链路追踪系统只要把这几行关键字段打进日志文件按天聚合绝大部分问题都能快速定位到“召回、重排、生成”的哪个环节。5.3 回归 case 与灰度发布的最小标准重排模型不是上线就完事后续每次调参、换模型都要有回归流程。我们团队沉淀了一个“case 库”里面装着 100 条业务方反馈过的高频问题和曾经答错的 case每条都有标注好的正确答案块。灰度发布策略也很朴素新模型服务先只接 10% 的流量跟线上旧版本并行跑一周。对比三个指标——答案引用命中率、点踩率、P99 延迟。任何一项出现回退都切回旧版本再排查。只有三项数据都不低于线上才慢慢放量到 30%、50%、全量。回归 case 库还有一个附带价值它逼着你把“什么是正确答案”这件事想清楚。很多知识库项目之所以效果差并不是模型不行而是连团队内部都对“正确答案长什么样”没有共识。建 case 库的过程其实也是在帮业务方梳理内容质量。最后分享一个我一直在用的判断标准重排一定要放到一个能看见分数分布的地方再上线。我第一次上线时只盯着 Top1 对不对没记录分数分布后来模型一升级阈值崩了都没发现。现在我们的做法很朴素每次迭代都给重排服务加版本号七天分位分布对比图挂在监控页上谁要改阈值都得先给我看数据。重排不是一锤子买卖把评估集、日志、灰度这三件事先做扎实比换更贵的模型有用得多。