做知识库检索时，团队最容易先上一个纯向量检索，然后很快发现有些查询怎么调都召回不好：不是相似度阈值的问题，而是这一路检索本身就有它够不到的东西。
这篇文章把「混合检索」讲清楚：它为什么存在、两路各自补什么、以及用 RRF 怎么把结果合起来。
纯向量检索会漏什么
向量检索把文本映射到向量空间，靠距离找「语义相近」的内容。它对改写、同义、跨语言这类模糊匹配很擅长。
但它对精确词项不敏感。产品型号、合同编号、专有名词、人名、罕见词，这些在向量空间里往往没有稳定的近邻。中文尤其明显：分词不当的向量把整句当成一个 token，用户搜一个精确词条时，召回质量就靠运气。
结论不是「向量检索不好」，而是它擅长的是语义相似，不是词项命中。知识库查询两者都要。
全文检索补什么
全文检索（PostgreSQL FTS、BM25 这类）按词项匹配：把文档切词建倒排索引，查询时按词命中并打分。它正好补上向量检索的短板——精确关键词、编号、专有名词，命中就是命中。
中文有一个额外前提：必须先分词。PostgreSQL 默认的全文检索解析器按空格切词，中文整段会变成一个词，等于失效。要让它对中文生效，需要 zhparser 这类基于 SCWS 的中文分词扩展。
RRF 怎么把两路合起来
两路检索各出一个排序，接下来要合并。RRF（Reciprocal Rank Fusion，见 Cormack 等 2009 的论文）的做法是：把每个结果在其所在排序里的名次，转成一个分数再求和。
具体是 1 / (k + rank)，k 通常取 60。一个结果在向量路排第 1、全文路排第 5，它的分数就是 1/61 + 1/65。最后按总分重排。
RRF 的价值在于确定性：它不需要训练、不需要手动调两路的权重，给定同样的输入就得到同样的输出。对知识库这种要「可复现、可追溯」的场景，这一点比黑盒调参更值钱。
代价
混合检索不是免费的：
- 要维护两套索引（向量 + 倒排），写入时都要更新；
- 查询要走两路再融合，延迟略高；
- 两路结果要在同一套文档 ID 上对齐。
这些代价在「既要语义召回、又要精确命中」的知识库场景里通常是值得的。但如果你的场景只有模糊语义匹配，纯向量反而更简单。
琅嬛怎么落
琅嬛的混合检索是 pgvector 向量 + PostgreSQL 全文检索（zhparser 中文分词），双路召回后用确定性 RRF 融合，每个结果带来源锚点。具体实现可以在 琅嬛仓库 与 架构文档 里核对。
如果你的知识库查询经常同时出现「找意思相近的」和「找这个词」，那大概率已经到了该上混合检索的时候。