向量检索够用了吗：重排序在真实业务里的收益测算

做了向量检索之后，很多人会发现一个尴尬现象：召回的 10 条里，真正有用的只有 3 到 4 条。

问题不在向量模型，而在向量检索本身的表达能力上限。

为什么向量召回会漏

向量检索把 query 和文档各压缩成一个向量，用余弦距离排序。这个过程的损失在于：

• query 通常很短，语义信息稀疏
• 文档被压成单一向量后，细节被平均掉
• 一词多义、否定、数值条件几乎无法表达

举个真实 case：问"2025 年差旅标准里北上广深的住宿上限是多少"。向量检索很可能召回"2024 年差旅标准"和"北上广深办公用品采购"，因为它们整体语义接近，但都答非所问。

重排序做了什么

重排序（rerank）是第二阶段：向量先粗召回 50–200 条，再用一个交叉编码器逐条给 query-文档对打分。

    graph LR
    A[用户提问] --> B[向量粗召回 Top-100]
    B --> C[Cross-Encoder 逐条打分]
    C --> D[取 Top-5 拼装上下文]
    D --> E[LLM 生成答案]
  

区别在于：向量检索是"各自编码再比距离"，交叉编码器是"把 query 和文档拼在一起过一遍模型"，能捕捉到向量丢掉的细粒度匹配。

实测收益

在我们的企业知识库场景（约 8 万片段）上的对比：

准确率提升约 54%，代价是延迟翻倍。

什么时候可以不加 rerank

不是所有场景都值得。满足以下任一条件时，纯向量检索就够了：

1. 文档总量小（几千片段以内），召回空间本就不大
2. 查询是导航型的（用户知道要找哪份文档），而非探索型
3. 延迟预算极紧（如实时客服对话，<300 ms）

反之，如果是开放域问答、文档量大、允许多花 200–300 ms，rerank 的投入产出比非常高。

落地建议

• 粗召回数量取 50–100 就够，再往上收益递减明显
• rerank 模型不需要很大，参数是向量模型的 1/3 即可
• 把 rerank 做成可开关的：按 query 类型动态决定是否启用

一句结论

向量检索解决"找得到"，重排序解决"排得对"。在 RAG 里，后者的收益经常被低估。