完整题目
在RAG系统中是否可以引入重排（Re-ranking）模型？如果可以，它在检索流程中的作用是什么，常用模型有哪些？
本文目录
为什么需要重排
向量检索（双塔模型）追求效率，用内积/余弦相似度快速召回，但存在两个局限：
- 表示瓶颈：query和doc压缩成单一向量，细粒度语义丢失
- 交互缺失：query-doc没有早期交互，难以捕捉复杂匹配关系
重排模型正是弥补这个gap，在小范围候选集上做精准排序。
两阶段检索架构
Query → 向量检索（召回Top-K，K=100~1000） → 重排模型（精排Top-N，N=5~10） → 生成- 第一阶段：追求召回率，用ANN快速过滤
- 第二阶段：追求准确率，用重排模型精细打分
常用重排模型
| 类型 | 代表模型 | 特点 |
|---|---|---|
| Cross-Encoder | BERT-reranker、monoT5 | query和doc拼接输入，注意力层充分交互，效果最好但慢 |
| Late Interaction | ColBERT、ColBERTv2 | 保留token级向量，延迟交互，效率与效果平衡 |
| 轻量重排 | MiniLM、蒸馏版 | 边缘部署， latency敏感场景 |
实际落地要点
- 截断策略：重排输入不宜过长，通常对doc做滑动窗口或关键片段提取
- 级联过滤：可先过轻量模型（如ColBERT）再过重模型，控制成本
- 领域适配：通用重排模型在垂直领域往往需微调，可用点击/人工标注数据
字节等厂的实际系统中，重排基本是标配，尤其在搜索问答、客服等对准确性要求高的场景。
学习建议
建议系统学习该知识点
换一种问法，检查是否真正理解
场景切入
假设你在做一个企业知识库问答系统，用户问“报销流程怎么走”，向量召回了一堆相关文档。但结果里既有正式流程，也有员工吐槽，你怎么把最准确的那个排到最前面？
层层追问
RAG系统里向量召回完就直接丢给大模型了？……如果召回的top-10里混进几个不相关的怎么办……那有没有办法在中间加一道精排，用更精细的模型把相关文档挑出来？
直球架构
RAG系统里引入重排模型是标配吗？它在两阶段检索中的具体作用是什么？你了解哪些常用的重排模型，比如Cross-Encoder或者ColBERT？各自优缺点是什么？
练习口述回答 · 约4分钟
- 一句话定位：RAG中重排是召回后的精排环节，解决向量检索的交互缺失问题
- 边界划分：向量检索和重排互补，前者重效率后者重精度，真正落地是两阶段级联
- 业务场景：电商客服退款政策检索，先向量召回再重排精排，提升首问解决率
- 落地风险与前提：重排模型必须轻量化，否则延迟超标；输入截断策略影响大
- 工程师姿态判断：我更倾向用ColBERT做第一级重排，Cross-Encoder做最终精排，平衡效果与成本
这道题其实是在问[[RAG]]系统里，召回之后是不是还需要再做一轮排序，以及这一轮排序到底解决什么问题。我的看法是，[[重排]]不光是可引入，在线上对准确性要求高的场景，它基本是标配。
先说为什么需要重排。向量检索，也就是用 [[Bi-Encoder]] 把 query 和 doc 都压成一个向量，然后用内积去算相似度，这个做法效率很高，但有两个硬伤。一个是表示瓶颈，你把一整段文本压缩成一个向量，很多细粒度的语义信息就丢了。另一个是交互缺失，query 和 doc 从头到尾没有真正碰过，只是最后比了个向量距离，像这种“苹果手机退款政策”和“iPhone退货流程”这种语义相近但表述不同的匹配，它就很难抓住。重排模型就是来补这个 gap 的。
具体到架构，RAG 的检索链路其实是个两阶段流程。第一阶段用 [[ANN]] 做快速召回，比如从几百万文档里捞回 top 100 到 1000，这个阶段追求的是召回率，别把相关文档漏掉。第二阶段，在这个小候选集上，用重排模型做精细排序，把最相关的 top 5 到 10 个送进生成模块。说白了，第一阶段是海选，第二阶段是决赛。
这里有个边界划分的问题。很多人会问，为什么不用重排模型直接做召回？因为重排模型慢。典型的 [[Cross-Encoder]] 模型，比如 BERT-reranker，需要把 query 和 doc 拼接起来过 Transformer，计算量很大，不可能对上百万文档逐一打分。所以向量检索和重排是互补的，一个管效率，一个管精度。真正落地，一定是两者结合，而不是二选一。
举个例子，电商客服场景，用户问“我买的东西降价了，能退差价吗？”。向量检索先从知识库里召回一批相关文档，可能包括“价格保护政策”、“退款流程”、“优惠券使用规则”等等。但这里面有些文档可能只是沾边，比如提到了“价格”两个字但实际讲的是促销活动。这时候重排模型上场，它会仔细比对 query 和每个文档的语义相关性，把真正讲“降价退差价”的文档排到最前面。这样下游的生成模型拿到的上下文质量就高很多，回答也更精准，首问解决率能明显提升。
不过，引入重排也有几个落地风险。第一个前提是重排模型不能太重，否则整个检索链路的延迟会超标。我见过一些团队直接上 BERT-large 做重排，结果延迟从 50ms 飙到 500ms，线上根本扛不住。所以实际中常用的是轻量级模型，比如 MiniLM 或者[[蒸馏]]过的版本，或者用 [[ColBERT]] 这种延迟交互的方案，效果接近 Cross-Encoder 但快很多。第二个坑是输入截断。重排模型通常有长度限制，比如 512 tokens，而很多文档比这个长。如果不做截断策略，直接把文档尾巴切掉，可能会丢掉关键信息。我一般会先对文档做关键片段提取，或者用[[滑动窗口]]把长文档切成多段分别打分，再取最高分。