直接给结论：单纯靠向量召回 top-k，准确率到不了能用的程度。在召回后面加一层 reranker 重排，我这边的命中率从大概六成提到了八成五左右。这篇贴我自己的实测数字和配置。

背景是我搭了个内部文档问答的小助手，知识库大概 3000 个分块，全是产品手册和工单记录。一开始就是最朴素的 RAG：用户问题转向量，去库里捞最相似的 5 段，塞给模型答。

问题很快暴露。向量相似 ≠ 真能回答问题。比如用户问"导出失败怎么排查"，向量召回经常把"导入失败"的段落也捞上来——俩词长得太像，embedding 空间里挨得近，但答案根本不对路。

我做了组对比，同一批 50 个真实问题，看 top-5 里有没有命中正确段落：

重排这层做的事很简单：先用向量宽松地召回 20 个候选（召回阶段宁滥勿缺），再用一个专门的 reranker 模型，把"问题-候选段落"成对打分，按分数重新排，取前 5。reranker 和 embedding 不一样——embedding 是各自编码算距离，reranker 是把问题和段落拼一起过一遍模型，直接输出相关性分，所以更准，但也更慢。

实操几个点：

召回数量别太抠。我试过召回 10 个去重排，命中率反而不如召回 20。重排只能在召回给的候选里挑，召回阶段漏了正确段落，重排再神也救不回来。所以召回宽、重排准，这俩是分工。

混合召回那 3 个点提升，值不值看场景。我这库里有大量产品型号、错误码这种"精确词",纯向量对这类专有名词不敏感，加一路关键词（BM25）召回补上，89% 那行就是这么来的。但混合召回配置麻烦，要维护两套索引。如果你的库都是大段自然语言、没什么专有名词，老实说这 3 个点不一定值得折腾。

延迟翻倍要认。从 180ms 到 410ms，对问答场景无所谓，用户感知不到。但如果你这是个高并发、对延迟敏感的接口，重排这 200 多毫秒得提前算进预算。我的取舍是：问答类一律上重排，那种要求秒回的场景就只用向量、靠提示词兜。

说个翻车细节。我最早重排打分阈值设得太狠，低于某个分的候选直接丢，结果有些问题召回的 5 个全被砍光，模型没素材只能瞎答。后来改成"重排只负责排序、不负责过滤",哪怕最高分也不高，也老老实实把 top-5 给模型，让模型自己在 prompt 里判断"如果没有相关内容就说不知道"。这么改之后那种"明明库里没有却硬编一个答案"的情况少多了。

整个召回+重排的链路，我是在一个零代码就能配 RAG 的平台上拖出来的，知识库分块、向量召回、重排节点都是现成模块连一下。省下来的时间我全花在调召回数量和阈值上了——这俩参数没有标准答案，只能拿自己的真实问题集一遍遍测。

底层这些 embedding 和 rerank 调用我走的是讯飞星辰 MaaS，模型现成调，没自建。