27 · 重排序 Rerank

一句话：先用向量检索快速粗筛一批候选，再用更精准的 rerank 模型对这批精排，是提升准确率的生产标配。

本章标 🔥，是把 RAG/搜索从"能用"提到"好用"的关键一步。

1. 为什么需要重排

向量检索（bi-encoder）为了快，把 query 和文档分别编码成向量再比距离——这会损失一些精度：

• 它只看"向量方向接近不接近"。
• 无法细致判断"这段文字到底能不能回答这个问题"。

结果：Top-10 里往往有几条"看着相关、其实不切题"的。

重排（rerank） 用更强的模型，把 query 和每个候选文档一起输入，直接打一个精准的相关性分数，重新排序。

2. 两阶段检索架构（核心）

第一阶段（粗排 / Retrieve）：
  向量检索/混合检索  ──►  快速取回 Top-50 ~ Top-100 候选
       特点：快，召回广，但排序不够精

第二阶段（精排 / Rerank）：
  rerank 模型逐一给 (query, 候选) 打分  ──►  重新排序，取 Top-5
       特点：慢一点，但排序非常精准

一句话：用便宜的检索广撒网，用贵的 rerank 精挑细选。

3. bi-encoder vs cross-encoder

	检索用（bi-encoder）	重排用（cross-encoder）
编码方式	query、文档分开编码	query+文档 一起编码
速度	快（可预计算、建索引）	慢（每个候选都要实时算）
精度	中	高
用途	从海量里粗筛	对少量候选精排

正因为 cross-encoder 慢，才不能直接用它扫全库，而是只对粗排出的几十条用。

4. 常见 rerank 模型

• bge-reranker-large / v2-m3（开源，中文友好，常用）
• Cohere Rerank（在线 API）
• jina-reranker（在线/开源）

这些模型输入 (query, passage)，输出一个相关性分数。

5. 落地流程（伪代码）

1. query 向量化
2. 向量检索取 Top-50 候选（pgvector 完成）
3. 把 (query, 候选_i) 逐一送 rerank 模型，得到分数
4. 按 rerank 分数排序，取 Top-5
5. Top-5 交给大模型做 RAG（或直接展示）

对应 SQL 只负责第 2 步的粗排：

-- 第一阶段：粗排取 50 条候选（多取一些给 rerank 挑）
SELECT id, content
FROM doc_chunks
ORDER BY embedding <=> '[查询向量]'
LIMIT 50;

第 3~4 步在应用层调 rerank 模型完成（pgvector 不做 rerank）。

6. 为什么粗排要多取一些

• 粗排 LIMIT 5 直接给用户 → 那几条不够精。
• 粗排 LIMIT 50 → rerank 有足够候选去"捞回"那些排在 10~50 名但其实最相关的。

经验：粗排取 50~100，rerank 后保留 3~10。

7. 效果与代价

收益：

• 准确率（尤其 Top-1、Top-3）通常有明显提升。
• 对 RAG 帮助极大：喂给大模型的资料更切题，回答更准、更省 token。

代价：

• 增加一次模型调用，延迟上升（几十~几百 ms）。
• 在线 rerank API 有费用。

权衡：对质量敏感的场景（客服、知识库）值得；对延迟极敏感的可跳过或只 rerank 前 20。

8. 和混合检索的关系

三者可以叠加，形成生产级检索管线：

混合检索(向量+关键词, RRF) ──► Top-50 ──► rerank 精排 ──► Top-5 ──► RAG

• 混合检索：保证召回全（该找到的都找到）。
• rerank：保证排序准（最相关的排最前）。

9. 一句话总结

重排是"两阶段检索"：向量/混合检索粗筛 Top-50，再用 cross-encoder 精排到 Top-5；显著提升准确率，代价是一次额外模型调用。

---

➡️ 下一章：28-RAG检索增强生成入门.md，把检索结果喂给大模型，做出会回答的系统。