重排模型教程：Cross Encoder、BGE Reranker、ColBERT和业务排序
摘要
重排模型位于召回和生成之间，决定哪些证据最终进入用户可见答案。向量检索负责把可能相关的候选找出来，但候选集合往往包含语义相近但事实不匹配、权限不合适、时间过期或业务价值较低的片段。Cross Encoder、BGE Reranker 和 ColBERT 的价值，只有放在候选规模、延迟预算、证据质量和业务排序目标中才清楚。本文把重排视为一个证据治理问题，而不是简单的“给搜索结果再打分”。
关键词
重排模型；Cross Encoder；BGE Reranker；ColBERT；Late Interaction；RAG；业务排序；NDCG；候选集
研究问题与方法
本文讨论三个问题：为什么向量相似度不能直接等于最终相关性；不同重排结构如何在精度、延迟和吞吐之间取舍；业务排序怎样在模型分数之外纳入权限、时效、来源权威和用户意图。方法上，文章把检索链路拆成初召、重排、业务融合和答案生成四段，使用 NDCG、MRR、引用正确率、延迟和人工复核样本共同评估重排收益。
下图说明重排的分析位置。重排不是替代向量库，而是在候选集已经形成后，把“可能相关”压缩成“足以支撑答案”的证据集合。
重排效果常用排序指标衡量，例如：
其中 是第 个结果的相关性等级， 是理想排序的 DCG。这个指标适合重排场景，因为它不仅看相关结果有没有出现，还看高价值证据是否排在更靠前的位置。
搜索和知识库问答里，召回不是终点。向量检索、全文检索、混合检索把一批候选文档找出来之后，系统还要决定哪些内容真正应该排在前面，哪些内容虽然词面相近却不能进入答案上下文，哪些内容只适合作为补充证据。这个位置就是重排模型的主场。
很多 RAG 系统早期效果不稳定，不是因为大模型不够强，而是因为上下文给错了。用户问“合同终止后保证金多久退”，向量检索可能召回“保证金缴纳方式”“合同续签流程”“违约责任说明”“终止条款”四类片段；生成模型看到这些片段后，会把相关但不够精确的内容拼成答案。重排模型要做的事，是在生成之前重新判断候选片段与用户问题的真实相关性，把最能回答问题的片段排到前面。
这篇教程系统讲 Cross Encoder、BGE Reranker、ColBERT 和业务排序。重点不是堆模型名，而是讲清楚每种重排方式解决什么问题、付出什么成本、如何接进 RAG、如何做评测、如何和业务规则结合。读者可以把它当作知识库搜索、问答系统、企业检索、客服助手、内容推荐和内部资料平台的重排设计指南。
引言：为什么有了向量检索还需要重排
向量检索解决的是大规模候选召回。它把查询和文档编码成向量，靠近的向量代表语义相似。这个设计非常适合在百万、千万甚至更多片段里快速找到一批候选，因为文档向量可以提前离线计算，查询时只需要编码用户问题，再做近似最近邻搜索。
但向量检索的短板也很明显。第一，它通常把一个查询或一个片段压缩成一个向量，细粒度词项和条件容易丢失。用户问“员工试用期离职是否需要提前三天通知”，片段里只要同时出现“试用期”“离职”“提前通知”，向量就可能很近；但真正关键的是“是否需要”“三天”“谁通知谁”“公司制度还是劳动法”。单向量语义相似不能稳定表达这些条件。
第二，向量检索容易召回语义宽泛的片段。比如“退款流程”“售后政策”“会员权益”都可能与用户问题相关，但其中只有一个片段包含具体答案。若直接把 top 5 塞给大模型，模型可能会从宽泛片段里推断答案，而不是基于精确条款回答。
第三，向量模型和业务目标不一定一致。通用 embedding 模型学习的是语言相似性，业务系统关心的是可回答性、权限、时效、权威等级、用户意图、证据完整度和风险等级。一个片段语义相似，不代表它应该排在第一；一个片段词面不完全相同，也可能是业务上最权威的答案。
第四，RAG 的上下文窗口虽然越来越大，但“能塞更多”不等于“应该塞更多”。上下文越多，生成模型越容易分心，成本越高，延迟越长，引用也越难解释。更好的策略是先召回较大的候选集，再用重排模型精筛，把最有价值的证据放在前面。
因此，典型生产链路会分成两段：第一段是高召回，第二段是高精度。第一段用 BM25、向量检索或混合检索找出 top 50、top 100、top 200；第二段用 Cross Encoder、BGE Reranker、ColBERT 或业务排序模型重新打分，最终只把 top 5、top 8、top 12 放进答案生成。这个二阶段架构比直接相信初始检索更稳。
重排模型到底在排什么
重排模型的输入通常是一组“查询和候选文档”对。给定用户问题 q 和候选片段 d，模型输出一个相关性分数。分数越高，表示这个片段越适合回答这个查询。系统对候选片段按分数排序，再截取前若干条给后续模块。
这里要注意，“相关性”不是一个单一概念。信息检索里的相关性可能表示主题相似；RAG 里的相关性更接近“能否支持答案”；电商搜索里的相关性还包含商品可售、库存、价格、转化率；企业知识库里的相关性会受到权限、版本、文档状态和权威等级影响。重排模型只负责语言和语义判断，业务排序还要叠加系统规则。
一个实用的重排目标至少包含四层。第一层是主题相关：候选片段是不是在讨论同一件事。第二层是答案相关：候选片段是否包含能直接回答问题的信息。第三层是证据质量：片段是否来自权威文档、是否足够新、是否有明确条款或数据。第四层是业务可用：当前用户是否有权限、当前场景是否允许引用、是否需要人工确认。
Cross Encoder 和 BGE Reranker 主要加强前两层，尤其是查询与片段之间的细粒度匹配。ColBERT 兼顾检索和重排，它用 late interaction 保留 token 级交互，适合在效率和精度之间做更细的折中。业务排序则负责后两层，把模型分数和业务信号融合起来。
重排还有一个容易被忽略的作用：降低幻觉。生成模型如果拿到错误或弱相关上下文，即使本身能力很强，也可能给出看似合理但无依据的回答。重排把证据质量提前处理，能让生成阶段少犯“资料给错”的错误。RAG 质量提升往往不是换更大的生成模型，而是让检索和重排链路先把证据摆对。
Cross Encoder：最常见的高精度重排器
Cross Encoder 是重排模型里最容易理解的一类。它把查询和候选文档拼在一起输入同一个 Transformer，让模型在自注意力层里同时看到查询和文档的所有 token，然后输出一个相关性分数。因为查询和文档从一开始就共同编码，模型能学习非常细的交互关系。
与 bi-encoder 相比，Cross Encoder 的优势是精度高。bi-encoder 把查询和文档分别编码成向量，然后用余弦相似度或点积比较；文档向量提前算好，效率高，但交互少。Cross Encoder 每次都同时编码查询和文档，能判断“问题里的限制条件是否在片段里满足”“片段是不是只是同主题背景”“片段是否回答了真正问题”。SentenceTransformers 的 Retrieve & Re-Rank 文档也把 Cross Encoder 放在二阶段检索架构中，用于对第一阶段候选重新评分。
Cross Encoder 的代价是慢。若每个用户问题召回 100 个候选片段，就要跑 100 次查询-片段对的前向推理。候选片段越多，片段越长，延迟越高。它不适合直接在全量文档库上检索，只适合作为第二阶段或第三阶段重排器。
生产使用 Cross Encoder 时，最重要的参数不是模型名字，而是候选数量和片段长度。候选太少，初始召回漏掉答案，重排再强也救不回来；候选太多，延迟和 GPU 成本上升。片段太短，答案证据被切碎；片段太长，Cross Encoder 处理成本变高，还可能超过模型最大长度。常见起步策略是初始召回 top 50 或 top 100，重排后取 top 5 到 top 10。
Cross Encoder 的另一个关键是训练数据。通用模型在公开问答、网页搜索、英文检索上可能表现好，但企业内部文档、政策条款、中文客服、行业术语、代码仓库和合同文本都有自己的语言分布。若业务对准确性要求高，应该采集真实查询、点击、人工标注、引用片段和失败样本，对重排器做微调或至少做离线评测。
Cross Encoder 输出分数时，不要把分数解释成绝对概率。不同模型的分数范围不同，有些是 logits，有些经过 sigmoid，有些适合排序但不适合跨查询比较。一个查询下 0.82 和 0.71 可以用于相对排序，但不能直接说 0.82 等于“82% 正确”。如果要做阈值过滤，需要在本业务数据上校准。
BGE Reranker：中文和多语言 RAG 的常用选择
BGE Reranker 是中文团队非常常见的重排选择。BAAI 的 BGE 系列不仅有 embedding 模型，也有 reranker 模型，FlagEmbedding 文档和 Hugging Face 模型页都给出了使用方式。BGE Reranker 本质上属于 Cross Encoder 路线：输入查询和候选文本对，输出相关性分数，用于重新排序候选片段。
BGE Reranker 的优势在于中文和多语言场景友好，生态资料多，接入门槛低。很多中文知识库项目已经在使用 BGE embedding 做向量检索，再用 bge-reranker-base、bge-reranker-large 或 bge-reranker-v2-m3 做二阶段重排。对于企业内部中文文档、产品手册、政策问答、客服知识库、教育资料和技术文档，这是一条很务实的起步路线。
选择 BGE Reranker 时，要理解不同版本的定位。较小模型速度快、显存压力低，适合低延迟场景或 CPU 兜底；较大模型相关性判断更强，但吞吐更低；支持多语言和更长输入的新版本适合混合中英文资料、跨语言检索和长片段重排。不要只看模型榜单，要拿自己的数据测试。
BGE Reranker 接入 RAG 时，通常放在向量检索之后。流程可以是：用户问题先经过必要的改写或标准化；检索层从向量库和全文索引拿到候选片段；去重、权限过滤和状态过滤后，把候选片段与查询组成 pairs；BGE Reranker 计算分数；排序后选择前若干条进入答案生成；生成模型必须引用这些片段或说明未找到依据。
BGE Reranker 对中文 RAG 的帮助，常体现在几个问题上。第一，区分同主题但不同问题。比如“账号注销”和“账号冻结”都属于账号管理，但答案不同。第二，区分定义和操作步骤。用户问怎么操作时，纯定义片段不该排第一。第三，区分旧制度和新制度。模型本身不知道文档版本，业务排序要结合发布日期，但语义重排能先把真正讨论该问题的片段排出来。第四，减少“关键词相近但关系错误”的召回。
需要注意的是，BGE Reranker 不是业务规则引擎。它不会自动知道某份文档是否过期、用户是否有权访问、某个片段是否来自草稿、某类资料是否不能用于对外回答。这些条件必须由检索过滤和业务排序处理。最稳的做法是：权限和可见性在重排前过滤，语义相关性由 reranker 判断，权威性和时效性在重排后融合。
ColBERT：Late Interaction 的效率与精度折中
ColBERT 的核心思想是 late interaction。它不像普通 bi-encoder 那样把整段查询和整段文档都压成一个向量，也不像 Cross Encoder 那样每次把查询和文档一起完整编码。ColBERT 会分别编码查询和文档，但保留 token 级向量；查询时再计算查询 token 与文档 token 之间的细粒度相似度，并用 MaxSim 等方式聚合成相关性分数。
这个设计带来一个重要折中：文档可以提前编码和索引，查询时仍然保留细粒度匹配。相比 Cross Encoder，ColBERT 更适合参与较大规模检索；相比单向量 embedding，它能更好地保留词项级证据。ColBERT 论文和 ColBERTv2 论文都强调 contextualized late interaction 在检索效果和效率上的价值，ColBERTv2 还通过压缩和去噪监督降低空间占用。
ColBERT 适合哪些场景？第一，大规模文档库中对召回质量要求较高，不满足于单向量检索。第二，查询和文档存在细粒度匹配要求，例如法律条款、技术文档、医学说明、代码搜索、FAQ 和规范检索。第三，系统希望在检索阶段就有更强相关性建模，而不是把所有压力放到最后的 Cross Encoder。第四，团队能接受更复杂的索引和存储。
ColBERT 的代价主要是工程复杂度和索引空间。单向量检索每个片段只存一个向量；ColBERT 需要存 token 级向量或压缩表示，索引结构更复杂，存储更大，部署和调优门槛更高。它不是所有小型知识库的默认选择。如果文档量不大，BGE embedding 加 BGE Reranker 往往更简单。
在生产架构里，ColBERT 可以有两种位置。第一种是作为高质量检索器，替代或补充普通向量检索，从全量索引里直接取高质量候选。第二种是作为中间重排器，先用 BM25 或向量检索取 top 1000，再用 ColBERT 缩到 top 100，最后用 Cross Encoder 缩到 top 10。这种多阶段排序常见于搜索系统：前面追求召回和吞吐，后面追求精度。
ColBERT 对中文场景要特别关注分词和模型基础。英文 token、中文字符、子词切分、多语言模型都会影响 token 级交互质量。若使用多语言 ColBERT 变体或中文适配模型，要用真实中文查询测试，不要默认英文论文结论可以原样迁移。中文资料里有大量简称、编号、条款、日期、单位、产品名和组织名，这些细粒度实体正是 late interaction 可能发挥作用的地方。
业务排序：把模型分数放进真实产品
模型重排只回答“这段文本和这个问题有多相关”。业务排序还要回答“这段文本该不该展示给当前用户，是否应该进入答案，排在前面是否符合业务目标”。生产系统不能只按 reranker 分数排序。
业务排序常见信号包括权限、文档状态、发布时间、来源权威、点击反馈、人工推荐、产品线、地域、客户等级、知识类型、风险等级、语言、片段长度、引用完整度和历史命中质量。比如同样相关的两个片段，一个来自正式制度，一个来自历史会议纪要，正式制度应排前；一个是今年版本，一个是去年版本，新版本应排前；一个用户无权访问，必须完全排除，而不是降低分数。
业务排序最重要的原则是先过滤，再排序。权限、租户、密级、删除状态、草稿状态、合规限制这些硬条件，应该在重排前或至少进入生成前严格过滤。不能把无权限片段交给重排模型，再指望后续不展示。模型上下文里出现无权限资料，本身就是越权处理。
过滤之后，再做分数融合。一个简单可解释的公式可以是：最终分 = 语义分数 × 语义权重 + 权威分 × 权威权重 + 时效分 × 时效权重 + 用户反馈分 × 反馈权重 - 风险惩罚 - 长度惩罚。公式不是为了看起来科学，而是为了让团队能调整。若客服知识库总是把旧话术排前，可以提高时效权重；若内部论坛帖子压过正式手册，可以提高权威权重。
业务排序还要分场景。知识库问答重视答案证据；站内搜索重视用户点击和标题匹配；客服助手重视可执行话术和政策一致；代码搜索重视文件路径、函数名和最近修改；推荐系统重视用户兴趣和转化。不要把同一个 reranker 分数用于所有排序目标。模型可以共享，排序策略要按业务拆分。
当业务排序和模型分数冲突时，要明确优先级。高权威但语义弱的片段不应强行排第一，因为它可能答非所问；语义强但来源低质的片段也不应无条件排第一，因为它可能误导用户。较稳的策略是先保证语义相关达到阈值，再按权威和时效微调；若权威资料没有命中，要提示资料不足，而不是用低权威内容凑答案。
RAG 质量：重排改变的是证据入口
RAG 的质量可以拆成四段：问题理解、资料召回、证据排序、答案生成。很多团队只调提示词和生成模型，却忽略证据排序。结果是模型越强，越会把错误上下文包装成流畅答案。重排模型真正改变的是证据入口。
一个健康的 RAG 链路应该先追求召回，再追求排序。召回阶段要尽量保证答案片段进入候选集。可以用向量检索、BM25、关键词扩展、同义词、查询改写、结构化过滤和混合检索提高召回。重排阶段再把候选里最有用的片段挑出来。若初始候选没有答案，重排器没有办法凭空创造证据。
重排对 RAG 的提升通常体现在 context precision。也就是进入生成上下文的片段更精确，噪声更少。RAGAS 等评测工具会关注上下文精确率、上下文召回、忠实度和答案相关性，这些指标能帮助团队判断重排到底提升了哪一段。若加了 reranker 后答案更准确但召回率下降，说明候选截断或阈值可能太激进。
重排还会影响引用质量。很多知识库要求答案附引用，如果 top 片段不准确，引用就会变成装饰。好的重排链路应该让引用片段本身就能支撑答案，而不是生成模型从多个弱相关片段里综合推断。对于企业制度、法律政策、医疗教育、财务规则等场景，引用质量比回答流畅度更重要。
重排也能降低上下文长度。以前可能需要塞 20 个片段才能覆盖答案，加重排后也许只需要 6 个。上下文更短，生成成本更低，延迟更低，答案更聚焦。但不要盲目追求短。若问题需要多跳证据，例如“哪些客户同时满足条件 A 和条件 B”，系统可能需要保留多个片段或结构化数据结果。
RAG 里的重排不应该只发生一次。复杂链路可以有多级重排：先对文档级候选排序，再对片段级候选排序；先按用户问题排序，再按生成答案需要的证据类型排序；先找直接答案，再找限制条件、例外说明和来源。多级重排要控制延迟，但它能让复杂问题更稳。
候选集、阈值和延迟怎么调
重排系统调参时，最常见的三个旋钮是候选集大小、分数阈值和最终上下文数量。候选集大小决定重排器能看到多少可能答案；阈值决定低相关片段是否被丢弃；最终上下文数量决定生成模型能看到多少证据。
候选集过小，最大风险是漏召回。比如初始检索只取 top 10，真正答案在第 18 名，重排器再强也看不到。候选集过大，最大风险是延迟和成本。Cross Encoder 对每个候选都要推理，top 200 的成本可能是 top 50 的四倍。实际系统可以从 top 50 起步，评测答案片段落在候选集里的比例，再决定是否扩大。
分数阈值要谨慎。很多模型分数不适合跨查询比较，同一个阈值对不同问题可能意义不同。短问题、长问题、定义类问题、操作类问题、模糊问题的分数分布都不同。更稳的方式是结合排序位置、分数差距和最低数量。例如至少保留 top 3；若第 4 名之后分数明显断崖，就截断；若所有分数都低，则让系统回答“当前资料中未找到明确依据”。
最终上下文数量也要按问题类型变化。定义类问题可能 2 到 4 个片段足够；流程类问题需要步骤上下文；对比类问题需要多个来源；合规类问题需要正式条款和例外说明；代码问题可能需要函数、调用方和错误日志。固定 top 5 很简单，但不一定最优。可以让问题分类器或轻量规则决定上下文预算。
延迟优化有几种方法。第一，减少候选数量，但要用评测保证不损失召回。第二，限制片段长度，保留标题路径和关键正文，避免把整篇文档送入 Cross Encoder。第三，批量推理，把同一查询的多个 pairs 合并处理。第四，使用更小的 reranker 或量化版本。第五，对高频查询和稳定文档做缓存。第六，把重排放到异步流程里，例如搜索页先展示初排结果，随后更新精排结果。
延迟预算要面向用户体验。客服实时问答可能只能给 reranker 100 到 300 毫秒预算；内部研究助手可以接受 2 到 5 秒；离线报告生成可以跑更重的多级重排。不要为了所有场景统一架构，把低延迟场景拖慢，也不要为了快牺牲高风险场景的证据质量。
如何评测重排效果
重排评测不能只看“感觉答案好了”。需要把检索、排序和生成分开看。第一步是建立查询集。查询应该来自真实用户问题、客服工单、搜索日志、失败案例、人工设计的边界问题和高风险场景。每个查询要标注理想答案片段，至少标出哪些片段是强相关、弱相关、无关。
第二步看召回指标。初始检索的 top 50 或 top 100 里是否包含正确片段？如果没有，问题在召回层，不在重排层。常用指标包括 Recall@K。比如正确片段是否出现在 top 50 候选里。若 Recall@100 很低，应该先改分块、embedding、BM25、查询改写或混合检索。
第三步看排序指标。重排后正确片段是否排到前面？可以用 MRR、NDCG@K、Precision@K、Hit@K。MRR 关注第一个正确结果的位置，适合问答；NDCG 能处理强相关和弱相关等级，适合多证据排序；Precision@K 看前 K 个里有多少相关片段，适合上下文质量。
第四步看 RAG 端到端指标。答案是否忠实于上下文，是否回答用户问题，是否引用正确，是否拒绝资料不足的问题，是否减少幻觉。RAGAS、TruLens、LangSmith、DeepEval 等工具能提供自动评测框架，但业务标准仍要自己定义。自动评分只能辅助，关键样本必须人工抽查。
第五步看线上行为。用户是否点击更靠前结果，是否减少追问，客服是否少改答案，人工审核是否更快，用户点踩是否下降，搜索无结果率是否变化。线上指标能反映真实使用，但容易受到 UI、流量、用户群和季节变化影响，所以要与离线金集合并看。
评测时要做消融实验。只用向量检索是什么效果；向量加 BM25 是什么效果；加 BGE Reranker 后提升多少；换 Cross Encoder 或 ColBERT 后提升多少；加入业务排序后是否改善正式文档命中；扩大候选集是否值得延迟成本。没有消融，就不知道提升来自哪里。
数据标注和微调怎么做
通用 reranker 能解决很多问题，但高价值业务通常需要自己的数据。数据来源可以分为显式标注和隐式反馈。显式标注是人工判断查询和片段的相关等级，质量高但成本高。隐式反馈包括点击、停留、复制、引用、采纳、人工改写、投诉、追问和搜索后无结果，数量多但噪声大。
标注时不要只有“相关/不相关”。更实用的等级是：强相关，能直接回答；中相关，提供背景或部分信息；弱相关，同主题但不能回答；不相关。这样训练和评测都更细。对 RAG 来说，“能否支持答案”比“是否同主题”更重要，标注规范要写清楚。
负样本很关键。很多业务文档之间高度相似，最难区分的是 hard negative。比如同一产品不同版本、相似政策不同地区、同一流程不同角色、同一错误码不同系统。训练数据如果只有明显不相关的负样本，模型上线后会被相似片段骗过。可以从初始检索 top 结果中人工挑错，构造高质量 hard negatives。
微调前要先建立基线。不要一上来就训练。先用现成 BGE Reranker、SentenceTransformers Cross Encoder 或其他 reranker 跑一遍评测，看薄弱点在哪里。如果只是业务排序没融合时效和权威，微调模型解决不了；如果是分块太差，训练也救不了；如果是同主题片段混淆，微调才更有价值。
微调后要防止过拟合。企业查询集往往不大，模型很容易记住标注样本。要划分训练集、验证集、测试集和长尾回归集。测试集不要参与调参。每次改模型、改分块、改检索器、改业务排序，都跑同一套回归，记录版本和指标。
数据闭环要持续。上线后把失败查询、低分回答、用户点踩、人工修改、无引用答案和召回空结果收集起来，定期进入标注池。重排模型不是一次性工程，而是搜索质量团队长期维护的资产。
常见架构方案
最小可用方案是“向量检索加 Cross Encoder 重排”。文档分块后生成 embedding，存入向量库；用户查询时取 top 50；用 Cross Encoder 或 BGE Reranker 打分；取 top 5 生成答案。这套方案适合中小知识库、客服 FAQ、内部文档和教程站搜索，工程简单，收益明显。
更稳的中文 RAG 方案是“混合检索加 BGE Reranker”。BM25 负责精确词和编号，向量检索负责语义相似；两路结果合并去重；权限和状态过滤；BGE Reranker 排序；业务分数融合；生成答案和引用。这套方案能处理中文简称、产品名、错误码、法规条款和自然语言问题。
大规模高质量搜索可以考虑“BM25/向量召回加 ColBERT 加 Cross Encoder”。第一阶段快速取 top 1000，第二阶段用 ColBERT 做细粒度筛选到 top 100，第三阶段用 Cross Encoder 精排到 top 10。它更复杂，但适合文档规模大、搜索质量要求高、能承担索引和 GPU 成本的团队。
电商和内容平台常用“模型分数加业务排序”。语义相关只是一个信号，还要融合库存、价格、转化率、新鲜度、作者质量、违规风险、用户兴趣、商业策略和多样性。这里的 reranker 不一定直接决定最终顺序，而是进入学习排序或规则排序框架。
企业知识库要特别加入“权限前置过滤和引用校验”。不管使用哪种重排模型，都不能让无权限片段进入模型上下文。生成后还要检查答案中的引用是否来自最终上下文，是否对应原文，是否出现未引用的强事实。对于严肃业务，重排和引用校验要一起设计。
容易踩的坑
第一个坑是把重排当成检索替代品。Cross Encoder 不能在全库逐条打分。它需要前面有召回器。召回器漏掉答案，重排器无能为力。所以先看 Recall@K，再看重排后的 Precision@K。
第二个坑是候选片段太脏。重复片段、过期片段、无标题片段、切断表格、丢失章节路径、混入导航栏和页脚，都会让重排模型误判。重排之前要把文档解析和分块做好。高质量片段应该保留标题路径、正文、来源、版本和必要结构。
第三个坑是只看答案，不看引用。生成模型可能用一个弱相关片段写出看似正确的常识答案。若业务要求可追溯，评测时必须检查引用是否支持答案。答案对但引用错，在生产知识库里仍然是问题。
第四个坑是把分数阈值写死。不同查询的分数分布不同，固定阈值容易误杀或放进噪声。阈值要基于评测校准，最好结合 top 差距、最低保留数量、问题类型和资料不足策略。
第五个坑是忽略时效和权威。模型会把语义最像的片段排前，但业务可能需要最新制度和正式文档。业务排序必须补上来源等级、发布时间、文档状态和适用范围。
第六个坑是没有延迟预算。加 reranker 后质量提升，但接口从 800 毫秒变成 6 秒，用户体验可能更差。重排要按场景分层：实时搜索用轻量模型，严肃问答用强模型，离线任务用多级重排。
第七个坑是把线上反馈直接当真值。点击高不一定代表答案正确，可能只是标题吸引人；用户没点踩不代表满意，可能已经离开。隐式反馈要和人工标注结合。
落地清单
第一，先定义问题类型。你的系统是知识库问答、站内搜索、客服辅助、代码搜索、内容推荐，还是企业制度查询？不同任务的相关性标准不同。
第二，建立基线。记录当前检索方式、候选集大小、最终上下文数量、答案准确率、引用准确率、延迟和成本。没有基线，就无法证明重排有效。
第三，准备评测集。至少收集 100 到 300 个真实查询，标注强相关片段和不可接受片段。高风险业务要单独建回归集。
第四，选择第一版模型。中文 RAG 可以从 BGE Reranker 开始；通用多语言可以评估 SentenceTransformers Cross Encoder；大规模细粒度检索可以研究 ColBERT。
第五，设计链路。召回 top 50 或 top 100，权限和状态过滤，重排，业务分数融合，截取上下文，生成答案，引用校验，日志记录。
第六，调候选和阈值。先保证答案片段进入候选，再优化排序和延迟。不要为了降低成本过早压缩候选集。
第七，上线灰度。把新旧排序并行跑一段时间，比较点击、采纳、人工修改、点踩、延迟和成本。不要一次替换所有流量。
第八，建立闭环。把失败样本回流到评测集和标注池，定期复盘分块、召回、重排、业务排序和生成提示词。
怎么选择 Cross Encoder、BGE Reranker 和 ColBERT
如果团队刚开始做中文知识库，优先选 BGE Reranker。原因很简单：中文资料多，接入成熟，和 BGE embedding 组合常见，效果通常比只用向量检索明显。先用它把 RAG 证据排序做稳，再考虑更复杂方案。
如果任务是通用二阶段重排，且已有 SentenceTransformers 生态，Cross Encoder 是标准路线。它适合小到中等候选集，尤其是问答、FAQ、网页片段、搜索结果精排。它的缺点是不能直接处理太多候选，需要严格控制延迟。
如果文档规模大、检索质量要求高、单向量召回不够，ColBERT 值得评估。它不是最简单的方案，但 late interaction 能在大规模检索和细粒度匹配之间提供好折中。对法律、技术、医学、代码和复杂资料库，ColBERT 可能比普通 embedding 更适合作为高质量检索层。
如果业务排序信号很强，不要让模型分数独断。电商、内容推荐、企业制度、客服政策都有大量非语义信号。模型负责判断文本相关性，业务系统负责最终排序和安全边界。
最终选择不应由模型名决定，而应由评测决定。拿真实查询、真实文档、真实延迟预算和真实成本跑对比。看 Recall@K、NDCG@K、引用准确率、答案忠实度、用户采纳率和每次请求成本。哪个组合在你的业务里稳定，哪个才是正确选择。
重排与查询改写如何配合
查询改写和重排经常一起出现，但它们解决的问题不同。查询改写发生在检索前，目标是把用户的自然表达变成更适合检索的表达；重排发生在召回后，目标是判断候选片段与原始意图是否匹配。一个系统如果只做查询改写，可能召回更多候选，但仍然不知道哪些候选真正能回答问题；如果只做重排，而原始查询太短、太口语、缺少关键实体，候选集中可能根本没有正确片段。
实用做法是保留原始问题，同时生成一个或多个检索查询。比如用户问“这个能不能退”，上下文里可能有商品、订单、课程、服务包或合同。系统可以根据会话上下文补齐实体，生成“某课程购买后退款条件”“某服务包未使用退款规则”等查询。召回候选后，重排时仍然应把原始用户问题、补齐后的查询、会话关键上下文一起考虑，避免改写把用户意图带偏。
查询改写也可以为重排提供意图标签。若改写器判断问题是“操作步骤”，重排和业务排序可以提高流程类片段权重；若问题是“定义解释”，可以提高概念说明权重；若问题是“比较选择”，可以保留多个来源而不是只取单一答案；若问题是“风险判断”，可以优先正式制度、例外条款和审批说明。这样重排不只是按语义相似排序，而是按任务需要组织证据。
需要警惕的是，查询改写不能替代用户确认。用户问题缺少关键条件时，系统不应该强行改写成一个确定问题再重排。例如“离职赔偿怎么算”可能涉及劳动合同、试用期、公司裁员、个人辞职、地区政策和工作年限。若资料库中有多个相关制度，重排器可能选出某一类片段，但这不代表系统已经知道用户真实情况。此时更好的答案是先说明需要补充哪些条件，或给出不同情形下的资料入口。
重排链路还要记录改写版本。若线上出现错误答案，团队要知道当时原始问题是什么，改写查询是什么，召回了哪些候选，重排分数如何，最终引用了哪些片段。没有这些日志，排查时只能看到最终答案，很难判断是改写错、召回漏、重排错、业务排序错，还是生成模型误读。
长文档、表格和代码片段的重排差异
不同资料类型对重排的要求不同。普通短文本片段最适合 Cross Encoder 或 BGE Reranker，查询和片段都比较短，模型能直接判断相关性。长文档、表格和代码则需要额外结构，否则重排模型看到的文本可能不完整。
长文档重排要保留章节路径。一个片段如果只写“应在七个工作日内处理”，没有标题，模型不知道这是退款、审批、入职还是售后。把“售后政策 > 退款规则 > 处理时限”放进片段文本或元数据，重排效果通常会更稳。标题路径不是装饰，而是语义上下文。
表格重排要保留表头、行列含义和单位。很多知识库把表格按单元格切开，结果片段里只有“标准版 299 元 10 次”，模型无法判断这些数字属于价格、配额还是优惠。更好的做法是把表格行转成结构化句子，例如“套餐：标准版；月费：299 元；包含次数：10 次；适用对象：个人用户”。重排模型处理自然语言化后的表格行，会比处理碎片数字更可靠。
代码重排要保留文件路径、函数名、类名、调用关系和错误信息。用户问“这个接口为什么 401”，只看某个中间件片段可能不够，还要看到路由、鉴权配置、环境变量和调用方。代码搜索里，ColBERT 这类细粒度匹配有时能帮助识别函数名和参数，但业务排序也要加入路径权重、最近修改、语言类型和测试失败上下文。
长文档还可以采用父子块策略。检索和重排时使用较短子块，生成时带上父级章节或相邻片段。这样既让 reranker 能精确判断，又避免生成阶段缺少上下文。父子块策略要小心引用：答案引用应指向真正支持结论的子块，同时允许用户打开完整章节查看上下文。
多租户和权限场景下的重排边界
企业知识库、SaaS 后台和内部 AI 助手必须把权限放在重排之前。很多系统为了省事，先从全库召回候选，再把候选交给 reranker，最后才过滤权限。这种顺序不安全。即使最终不展示无权限片段，无权限资料也已经进入模型处理和日志链路。
正确顺序是：先确定当前用户、租户、空间、角色和任务范围；再从有权访问的索引或带权限过滤的查询中召回；然后重排；最后再做一次生成前校验。若使用共享向量库，索引查询必须带租户和权限元数据过滤。若使用 ColBERT 或其他专用索引，也要保证索引分区或过滤条件不会让跨租户片段进入候选。
权限变化要能影响重排结果。文档从公开改成私密、员工退出项目、合同到期、资料归档、客户删除空间，这些变化都应让相关片段立即退出候选。若索引是异步更新，系统至少要在查询时读取最新权限状态，不能只相信旧 embedding 或旧索引。
多租户还会影响反馈数据。A 租户用户点击某片段，不代表 B 租户也应该把类似片段排前。业务排序里的点击、采纳和人工推荐要按租户、空间、资料类型分层，避免大客户或高频团队的行为污染其他团队。通用语义模型可以共享，业务反馈要谨慎共享。
审计也很重要。一次 RAG 回答应能追踪：用户是谁，在哪个租户，检索范围是什么，候选片段有哪些，哪些被过滤，重排后顺序是什么，最终引用哪些片段。面向用户的界面不需要展示这些内部细节，但系统必须能在事故复盘时还原。
从教程到工程：一个可落地的版本路线
第一版不要追求完美。先用现有 embedding 加 BGE Reranker 或 SentenceTransformers Cross Encoder，做出可评测的二阶段链路。重点是把日志打全：原始查询、候选 ID、初排分数、重排分数、最终上下文、答案引用、耗时和错误。没有日志，后续优化没有依据。
第二版补混合检索。中文业务资料里，编号、专有名词、产品型号、错误码、合同条款和人名地名很重要。纯向量检索容易漏掉精确词，BM25 或全文检索可以补上。混合检索后再重排，通常比单一路线稳定。
第三版加入业务排序。把文档状态、来源等级、发布时间、适用范围、用户反馈和风险等级融合进最终分。这个阶段要让产品、运营、业务专家参与，因为权威性和时效性不是模型能自己决定的。
第四版建立标注和回归。收集真实失败样本，标注强相关和弱相关片段，定期对比不同 reranker、不同候选大小、不同分块策略和不同业务权重。每次上线新模型或新索引，都跑回归集。
第五版再考虑 ColBERT、微调和多级重排。只有当现有链路证明瓶颈在细粒度检索或语义精排时，复杂模型才值得引入。工程复杂度要服务质量目标，而不是为了架构好看。
最终，一个成熟重排系统应该让团队能回答三个问题：用户为什么看到这些证据，系统为什么没引用其他候选，下一次如何让排序更准。能回答这三个问题，重排才真正从模型能力变成生产能力。
参考资料
- SentenceTransformers Retrieve & Re-Rank 文档：https://www.sbert.net/examples/applications/retrieve_rerank/README.html
- SentenceTransformers Cross Encoder 训练与 Reranker 文档：https://sbert.net/docs/cross_encoder/training_overview.html
- SentenceTransformers Rerankers 示例：https://sbert.net/examples/cross_encoder/training/rerankers/README.html
- BGE Reranker 官方教程：https://bge-model.com/tutorial/5_Reranking/5.2.html
- BAAI bge-reranker-base 模型页：https://huggingface.co/BAAI/bge-reranker-base
- FlagEmbedding 项目：https://github.com/FlagOpen/FlagEmbedding
- ColBERT 论文：https://arxiv.org/abs/2004.12832
- ColBERTv2 论文：https://arxiv.org/abs/2112.01488
- ColBERT GitHub 项目：https://github.com/stanford-futuredata/ColBERT
- BEIR 检索评测基准论文：https://arxiv.org/abs/2104.08663
- MS MARCO 数据集：https://microsoft.github.io/msmarco/
- RAGAS 文档：https://docs.ragas.io/
- LlamaIndex reranker 文档：https://docs.llamaindex.ai/en/stable/module_guides/querying/node_postprocessors/
- Haystack Ranker 文档：https://docs.haystack.deepset.ai/docs/rankers