2024 年我给一个产品文档站做了个智能问答检索:用户输入一句话,我去几万篇文档里找最相关的几篇,喂给大模型生成回答。怎么把这个"找"做准?这件事我压根没多想。第一版我做得很顺手:这都什么年代了,还用关键词搜索?我把所有文档转成 embedding 向量、存进向量库,用户的问题也转成向量,去库里找语义最接近的几篇。就完事了。本地拿一批问题一测——真不错:问"怎么让网站变快",它能召回标题叫《性能优化指南》的文档,一个字都不重合也照样命中。我心里很笃定:"语义检索这么先进,关键词搜索那套老古董早该淘汰了,有了向量检索还要关键词干嘛?"可等这检索真正上线、被各种各样的真实用户搜,一串问题冒了出来。第一种最先把我打懵:用户搜一个精确的产品型号 X-2000、一个错误码 ERR_4012,向量检索返回的全是"语义沾边、但根本不是那个东西"的文档,那篇标题里就写着 X-2000 的文档却没排进来。第二种最难缠:用户用了一个很冷门的专有名词、一个内部缩写,embedding 模型压根没见过这个词,向量检索完全在抓瞎。第三种最头疼:我意识到该补上关键词检索,可两路结果的分数根本不在一个量纲上,一个是 0 到 1 的相似度、一个是没有上界的 BM25 打分,我没法把它们合在一起排序。第四种最莫名其妙:同一个查询,有时向量那一路结果好、有时关键词那一路好,没有哪一路是稳定更优的。我盯着这一连串问题想了很久才彻底想明白,第一版错在一个根本的认知上:我以为"语义检索更先进,有了向量检索,关键词检索就该淘汰了"。这句话把向量检索和关键词检索当成了"先进替代落后"的关系。可它们根本不是替代关系。我脑子里,检索技术是一条单向进化的直线:关键词检索是老一代,向量检索是新一代,新的全面优于旧的,所以用新的就行。可这个想法,完全误判了这两种技术的本质——它们擅长的根本是两类不同的查询,谁也替代不了谁。向量检索擅长的是"语义的、模糊的匹配":你问"怎么让网站打开更快",它能理解这句话的意思,召回讲"性能优化"的文档,哪怕字面一个词都不重合——这是它的主场。但它有个致命的短板:对那些"精确的、字面的、低频的 token"——产品型号 X-2000、错误码 ERR_4012、函数名、内部缩写、人名地名——它表现极差。因为这些 token 在 embedding 模型的训练语料里要么压根没出现过,要么被稀释进了一个泛泛的语义区域,向量空间里它们彼此挨得很近、根本区分不开。而关键词检索(BM25 这类)恰好长在向量检索的短板上:它做的是字面 token 的精确匹配加词频统计,你搜 X-2000,它就老老实实去找包含 "X-2000" 这个 token 的文档——精确型号、错误码、专有名词,全是它的主场。但它也有对应的短板:它完全不懂语义,你把"网站变快"换成"性能优化",它就两眼一抹黑。所以这两种检索,不是一条进化线上的新旧两代,而是能力上互补的两个工具:一个管语义模糊匹配,一个管精确字面匹配,各自的强项正好是对方的弱项。我用纯向量检索,等于只带了一把只会模糊匹配的工具就上了战场,那些需要精确匹配的查询,我从一开始就注定搜不好。真正把检索做扎实,核心不是"用最先进的那一种检索",而是认清向量检索擅长语义模糊匹配、关键词检索擅长精确字面匹配,两者互补而非替代,要用混合检索两路并行召回,用 RRF 倒数排名融合解决两路分数量纲不一致的问题,再叠加重排序做精排,并持续评测混合检索相对单路的真实增益。这篇文章就把 RAG 混合检索这个坑梳理一遍:为什么纯向量检索会漏掉精确匹配的查询、BM25 关键词检索擅长的恰好是向量的短板、混合检索怎么两路并行召回、分数融合为什么要用 RRF 而不是加权求和、混合检索和重排序怎么分工,以及一些把混合检索做扎实要避开的工程坑。
问题背景
这个坑普遍,是因为这几年"向量检索""语义搜索"被讲得太多太响,给人一种强烈的暗示:关键词检索是上个时代的东西,新项目直接上向量就对了。它错得隐蔽,是因为用"语义型"的查询去测,纯向量检索表现确实好:你测的问题如果都是"怎么让网站变快"这种自然语言提问,向量检索召回得又准又漂亮,你根本看不出它在精确匹配上的瘸腿。它只在真实用户带着五花八门的查询涌进来时才暴露——有人搜型号、有人搜错误码、有人贴一段代码符号、有人用冷门缩写,这些精确型查询纷纷搜不到,而你还以为"我用的是最先进的检索"。
把这个现象拆开,错误认知和真相是这样对应的:
- 现象:搜精确型号错误码搜不到;冷门专有名词向量抓瞎;两路分数量纲不一致没法合并;不同查询有时向量好有时关键词好。
- 错误认知一:以为向量检索全面优于关键词检索。真相是两者擅长不同查询,向量管语义模糊、关键词管精确字面,互补。
- 错误认知二:以为分数高就是更相关,两路分数能直接加权合并。真相是两路分数量纲不同,直接加权会被量纲大的一路碾压。
- 错误认知三:以为召回和排序是一回事。真相是混合检索负责"广撒网召回",重排序负责"精挑细选",是两个分工。
- 真相:好的检索是混合检索——两路并行召回、用 RRF 按排名融合、再叠加重排序精排,并持续评测它相对单路的真实增益。
一、为什么纯向量检索会漏掉精确匹配的查询
先把第一版那个纯向量检索摆出来。它就是字面意思——把查询转成向量,去库里找最近的几篇:
# 第一版:纯向量检索(反面教材)
def search_vector_only(query: str, top_k=5):
# 查询转成 embedding 向量
q_vec = embed(query)
# 去向量库里找语义最接近的 top_k 篇
hits = vector_db.search(q_vec, top_k=top_k)
return hits
# 对"语义型"查询,它表现很好:
search_vector_only("怎么让网站打开更快") # 能召回《性能优化指南》
# 但对"精确型"查询,它经常翻车:
search_vector_only("X-2000") # 召回一堆"型号相关"的文档,
# 唯独那篇标题就写着 X-2000 的没排进来
search_vector_only("ERR_4012") # embedding 没见过这个错误码,
# 它在向量空间里和别的错误码挤成一团
这段代码没有任何错误,它对语义型查询的表现也确实优秀。它唯一的问题是偏科:它只会一种匹配方式——语义相似。当用户搜 X-2000 这种精确 token,问题就来了。X-2000 对 embedding 模型来说,可能是个训练时压根没见过的字符串,模型没法给它一个有意义的语义向量;就算见过,型号、错误码这类 token 在语义上彼此极其相似(都是"某种标识符"),它们在向量空间里挤成一团,向量检索根本分不出 X-2000 和 X-2001。于是那篇标题、正文里明明白白写着 X-2000 的文档,在纯向量检索里反而排不进 top-k。这不是 bug,这是向量检索能力边界之外的事——它本来就不是干精确匹配这个活的。
这里要建立的第一个、也是最重要的认知是:当你选择一个工具去解决问题时,你必须清楚地知道它的"能力边界"在哪——它不只有"能做什么",还有同等重要的"做不好什么"。一个工具的强项和它的弱项,常常是同一个设计取舍的一体两面:向量检索之所以擅长语义模糊匹配,正是因为它把文本压缩成了一个"抓住大意、丢掉字面细节"的稠密向量;而它压缩掉的那些"字面细节",恰恰就是精确匹配所依赖的东西。所以它的强项(懂语义)和它的弱项(丢字面),是同一个机制带来的,你不可能只要前者不要后者。我第一版栽的跟头,根子是只看见了向量检索那个亮眼的强项,就脑补它"什么都行",完全没问一句"它做不好什么"。这个认知在工程里到处适用:NoSQL 数据库强在水平扩展和灵活 schema,代价就是弱在多表事务和复杂关联查询;消息队列强在削峰和解耦,代价就是弱在强一致和实时性;缓存强在快,代价就是弱在数据可能过期。这些都不是缺陷,是取舍——一个工具为了把某件事做到极致,必然在另一些事上让步。所以拿到任何一个工具,你要养成一个习惯:别只问"它擅长什么",更要追着问一句"那它为了擅长这个,放弃了什么、做不好什么?"。把工具的能力边界摸清楚,你才不会在它的弱项上押注,然后对着一个"它本来就不该做好的事"百思不得其解。
二、BM25 关键词检索:它擅长的恰好是向量的短板
既然向量检索的短板是精确字面匹配,那就得请回来一个专门干这个的工具——关键词检索,它最经典的算法叫 BM25。BM25 不懂任何语义,它做的事很朴素:把查询和文档都拆成 token,统计查询里的 token 在文档里出现的频次,再结合"这个 token 有多稀有"(越稀有的词命中越值钱)算一个相关性分数。这套朴素的机制,恰恰让它在精确匹配上极其可靠:
# BM25 关键词检索(用 rank_bm25 库,Elasticsearch 底层也是 BM25 同族)
from rank_bm25 import BM25Okapi
# 把每篇文档分词成 token 列表(中文需要先用分词器切词)
tokenized_corpus = [tokenize(doc.text) for doc in docs]
bm25 = BM25Okapi(tokenized_corpus)
def search_bm25(query: str, top_k=5):
tokens = tokenize(query)
scores = bm25.get_scores(tokens) # 给每篇文档算一个 BM25 分
ranked = sorted(range(len(scores)), key=lambda i: -scores[i])
return [(docs[i], scores[i]) for i in ranked[:top_k]]
# 对"精确型"查询,BM25 是主场:
search_bm25("X-2000") # 老老实实找含 "X-2000" 这个 token 的文档,精准命中
search_bm25("ERR_4012") # 错误码原样匹配,稳稳召回
# 但对"语义型"查询,BM25 是短板:
search_bm25("怎么让网站打开更快")
# 它只会找含"网站""打开""快"这些字的文档,
# 那篇标题叫《性能优化指南》、却一个查询词都不含的文档,它召回不到
把两种检索的强弱并排放一起,互补关系就一目了然了:
向量检索 vs 关键词检索(BM25):各自擅长什么
查询类型 向量检索 关键词检索 BM25
─────────────────────────────────────────────────
自然语言提问/换种说法 强 弱
同义词/近义表达 强 弱(字面不重合就抓瞎)
精确型号/错误码/编号 弱 强
函数名/代码符号 弱 强
冷门专有名词/内部缩写 弱(没见过) 强(字面匹配不需要见过)
长尾稀有词 弱 强(稀有词命中分还更高)
结论:两者的强项,精确地落在对方的弱项上 —— 这就是要混合的理由
这里要建立的认知是:看到 BM25 这个"老"算法在精确匹配上稳稳赢过光鲜的向量检索,你要建立一个特别重要的判断——技术的"新旧",和它在某个具体场景下的"优劣",是两件完全不相干的事。一个技术比另一个出现得晚,只意味着它针对某些问题提供了新的解法,绝不意味着它在所有问题上都更强。BM25 是个有几十年历史的算法,但它在"精确字面匹配"这件事上,至今没有被向量检索取代,因为向量检索压根不是冲着解决这个问题来的。我第一版的傲慢,就是被"新即是好"这个偷懒的直觉骗了:我没有去比较两种技术在我的真实场景下各自的表现,我只是因为向量检索"更新、听起来更高级",就认定它全面占优。这种用"新旧"代替"实测"来做技术选型的思维,在这个领域里害人无数——总有更新的框架、更潮的范式冒出来,如果你养成了"新的就用、旧的就弃"的习惯,你会不断地用一个不一定更适合你场景的东西,去替换一个本来工作得好好的东西。正确的工程判断永远是反过来的:不看它新不新,只看它在你的具体问题、你的真实数据上,表现到底如何。一个技术值不值得用,从来不由它的发布年份决定,而由它和你手上这个问题的匹配度决定。把"它很新"从你的选型理由里彻底删掉,换成"我测过,它在我的场景下确实更好"——这一条,能帮你避开技术选型里一大半的坑。
三、混合检索:两路并行召回
认清了两种检索互补,下一步就顺理成章:两路都用。这就是混合检索(hybrid search)——同一个查询,同时丢给向量检索和关键词检索,各自召回一批结果,再把两批结果融合成最终的一份。整个流程是这样:
[mermaid]
flowchart TD
A[用户查询进来] --> B[向量检索这一路]
A --> C[关键词检索 BM25 这一路]
B --> D[召回一批语义相关的文档]
C --> E[召回一批字面匹配的文档]
D --> F[分数融合 用 RRF 按排名合并两路]
E --> F
F --> G[重排序 对融合后的候选做精排]
G --> H[取最终 top-k 喂给大模型]
代码上,"两路并行召回"这一步没什么玄机——就是把前两节的两个检索各跑一遍,各拿一批候选:
# 混合检索第一步:两路并行召回,各自先多召回一些(比如各取 20)
def hybrid_recall(query: str, recall_k=20):
# 第一路:向量检索,管语义模糊匹配
vec_hits = search_vector_only(query, top_k=recall_k)
# 第二路:关键词检索,管精确字面匹配
bm25_hits = search_bm25(query, top_k=recall_k)
return vec_hits, bm25_hits
# 关键细节:召回阶段每一路都要"宁可多召回",取 recall_k=20 甚至更多,
# 而不是只取最终需要的 5 个。因为这一步的目标是"别漏",
# 把好结果尽量都捞进候选池,精挑细选是后面融合和重排序的事。
这里有个容易被忽略的细节:召回阶段每一路都要宁可多召回——如果最终只需要 5 篇,召回时每一路应该取 20 篇甚至更多。因为召回这一步的唯一目标是"别把好结果漏在门外",至于把好结果从候选池里精挑出来,那是后面融合和重排序的职责。召回阶段就抠抠搜搜只取 5 个,等于在还没看清候选之前就提前做了筛选,好东西很可能在这一步就被丢了。
四、分数融合:RRF 为什么比加权求和好
两路召回各拿到一批结果,真正的难点来了:怎么把它们合并成一份排序?第一反应通常是"加权求和"——把两路的分数各乘一个权重加起来。但这条路一上来就撞墙,撞的就是第一版那个"分数量纲不一致"的问题:
为什么"加权求和"融合两路分数行不通:
向量检索的分数:余弦相似度,范围固定在 0 ~ 1
文档 A: 0.82 文档 B: 0.79 文档 C: 0.75
BM25 的分数:没有上界,取决于词频和语料,可能是 0 ~ 30+
文档 X: 24.5 文档 Y: 11.2 文档 Z: 6.8
如果直接 0.5*向量分 + 0.5*BM25分:
BM25 那一路动辄二十几分,向量那一路最多就 1 分,
相加之后,结果几乎完全由 BM25 决定 —— 向量这一路被彻底淹没
根因:两路分数的"量纲/分布"根本不同,不可比,
强行相加,就是拿"米"和"公斤"做加法
归一化能缓解一点,但不同查询下两路的分数分布还会变,归一化也不稳。真正干净的解法是 RRF(Reciprocal Rank Fusion,倒数排名融合):它干脆不用分数,只用排名。一个文档在某一路里排第几名,就贡献一个 1/(k+排名) 的分数,把它在各路的这个贡献加起来,就是最终分:
# RRF 倒数排名融合:不看分数,只看"在每一路里排第几名"
def reciprocal_rank_fusion(vec_hits, bm25_hits, k=60, top_k=10):
scores = {}
# 向量这一路:遍历它的排名,rank 从 0 开始
for rank, hit in enumerate(vec_hits):
scores[hit.doc_id] = scores.get(hit.doc_id, 0) + 1.0 / (k + rank)
# 关键词这一路:同样按排名贡献分数
for rank, hit in enumerate(bm25_hits):
scores[hit.doc_id] = scores.get(hit.doc_id, 0) + 1.0 / (k + rank)
# 按融合后的总分排序
fused = sorted(scores.items(), key=lambda kv: -kv[1])
return fused[:top_k]
# RRF 的妙处:
# 1. 只用排名,彻底绕开了"两路分数量纲不一致"的死结
# 2. 1/(k+rank) 让靠前的名次贡献大、靠后的迅速衰减
# 3. 一个文档若在"两路里都靠前",分数会被两路叠加 —— 这正是我们想要的
# 4. k(常取 60)是个平滑项,避免第一名的权重过分压倒第二名
这里要建立的认知是:RRF 这个小技巧,藏着一个极其深刻、值得反复回味的工程智慧——当你要融合多个来源的信息、而这些来源的"度量标准"不可比时,聪明的做法不是费力去把它们的度量"强行对齐",而是把它们一起转换到一个更抽象、但天然可比的共同尺度上。向量分和 BM25 分,一个是 0 到 1 的相似度、一个是无上界的统计量,它们的绝对数值不可比——这是死结。归一化想做的是"强行对齐量纲",但治标不治本。RRF 的高明,在于它根本不在"分数"这个层面纠缠,它向上抽象了一层:它注意到,无论分数的量纲多么不同,"排名"这个东西是天然可比的——向量路的第 1 名和 BM25 路的第 1 名,都叫"第 1 名",含义完全对等。于是它把两路信息全部从"分数"翻译成"排名",在"排名"这个共同尺度上做融合。这个"放弃对齐原始度量,转而寻找一个更高层的共同尺度"的思路,威力极大:跨部门评估业绩,各部门的 KPI 数值不可比,但"排名/百分位"可比;合并多个评委的打分,各评委的打分松紧不同,但用"名次"就消除了松紧;不同量纲的指标做综合评分,与其归一化,不如都转成排名或分位数。所以下次你遇到"几个东西度量标准不一样、没法直接合并"的难题时,先别一头扎进"怎么把它们的数值对齐"——那往往很难、也不稳。先退一步问:有没有一个更抽象的层面,在那个层面上它们天然就是可比的?排名、分位数、等级、序关系——这些"相对的、序数的"尺度,常常就是那个能让不可比变可比的共同语言。
五、混合检索 + 重排序:召回与精排的分工
RRF 融合出一份排序后,其实还能再上一个台阶。混合检索(两路召回 + RRF)本质上是一个召回环节——它的强项是"广撒网,尽量别漏",但它判断相关性的方式还是相对粗糙的(向量相似度、词频、排名)。如果想要最终结果的顺序更精准,可以在后面再叠加一个重排序(rerank)环节,用一个更精细但更慢的模型,对融合后的候选做一次精挑:
# 在混合检索之后,叠加一个 cross-encoder 重排序做精排
from sentence_transformers import CrossEncoder
# cross-encoder:把 (查询, 文档) 成对喂进模型,直接输出一个相关性分
# 它比向量检索准得多,但慢得多 —— 所以只用来对少量候选做精排
reranker = CrossEncoder('cross-encoder/ms-marco-MiniLM-L-6-v2')
def hybrid_search(query: str, final_k=5):
# 1. 召回:两路并行,各多召回一些
vec_hits, bm25_hits = hybrid_recall(query, recall_k=20)
# 2. 融合:RRF 合并成一份候选(比如 20 个)
fused = reciprocal_rank_fusion(vec_hits, bm25_hits, top_k=20)
candidates = [get_doc(doc_id) for doc_id, _ in fused]
# 3. 精排:cross-encoder 对这 20 个候选逐一打分,重新排序
pairs = [(query, doc.text) for doc in candidates]
rerank_scores = reranker.predict(pairs)
reranked = sorted(zip(candidates, rerank_scores), key=lambda x: -x[1])
# 4. 取精排后的前 final_k 个
return [doc for doc, _ in reranked[:final_k]]
# 分工:混合检索负责"从几万篇里广撒网捞出 20 个候选"(快、求全),
# 重排序负责"把这 20 个候选精挑成最好的 5 个"(慢、求精)
这就是检索系统里经典的召回 + 精排两段式结构。它为什么要分两段?因为"快"和"准"很难兼得:重排序的 cross-encoder 很准,但它要把查询和每篇文档成对喂进模型算一遍,你不可能拿它去算几万篇文档。所以让快而粗的混合检索先从几万篇里筛出 20 个候选,再让慢而精的重排序在这 20 个里精挑——各自只做自己最擅长、且代价可承受的那一段。
这里要建立的认知是:召回加精排这个两段式结构,是一个能迁移到无数场景的通用架构范式——当你面对"要从一个巨大的集合里,精准地选出极少数最优项"这个问题,而"精准"和"快"又无法兼得时,标准解法就是把它拆成两段:先用一个快而粗的方法,把候选集从"巨大"砍到"不大"(这一步要求是"高召回"——宁可错放,不可漏杀);再用一个慢而精的方法,在这个"不大"的候选集里做精细排序(这一步要求是"高精度",而因为候选集已经小了,慢一点也付得起)。这个范式的精髓,是承认"快"和"准"在单一方法里不可兼得,于是用两个不同的方法、在数据规模的两个不同尺度上分别求其一。你一旦认出这个范式,会发现它无处不在:推荐系统是"召回层 + 排序层";搜索引擎是"初步检索 + 精排";很多 AI Agent 是"先用快模型粗筛、再用强模型细判";甚至代码里的多级缓存、数据库的"先走索引缩小范围、再回表取精确数据",骨子里都是这个结构。它的通用价值在于:它教你面对一个又大又要求精确的问题时,不要去幻想找到一个"既快又准"的银弹方法(那往往不存在),而是把问题按"规模"切成两段,在大规模那段用快方法保证不漏,在小规模那段用精方法保证质量。学会主动地把"求全"和"求精"这两个目标拆开、分给两个环节,你就掌握了构建高性能筛选系统的一把总钥匙。
六、工程里那些混合检索的坑
混合检索的主线理顺了,落地时还有几个工程坑反复咬人。第一个,中文分词决定 BM25 的上限。BM25 是基于 token 的,中文不像英文有天然空格,分词切得好不好直接决定 BM25 准不准;专有名词、产品型号要进自定义词典,否则会被切碎、匹配不上。第二个,RRF 的 k 值和召回数量要一起调。k 太小,头部名次权重过大;每路召回数太少,好结果可能根本没进候选池。第三个,混合不总是赢,要用评测说话。对纯语义型的查询集,混合检索未必比纯向量强;你必须维护一批有标注的评测查询,用 recall 和 NDCG 这类指标,实测混合相对单路到底有没有增益、增益在哪类查询上。第四个,两路索引要同步更新。文档增删改时,向量索引和关键词索引必须一起更新,否则两路会出现数据不一致,融合出来的结果就乱了。第五个,重排序是有成本的,它会增加延迟,候选数量(rerank 多少个)要在质量和延迟之间权衡。把这些都接进监控,你才有数据判断检索健不健康:
混合检索上线后必须盯死的几个指标:
recall@k 召回率,标注查询里该召回的有没有进 top-k
NDCG@k 考虑排序位置的相关性指标,衡量"好结果排得够不够前"
per_route_hit 最终结果里,来自向量路 / BM25 路的占比各是多少
zero_result_rate 返回空结果的查询占比,过高说明召回有盲区
rerank_latency 重排序环节的耗时,别让精排拖垮整体延迟
hybrid_vs_single 混合检索相对纯向量 / 纯 BM25 的增益,要持续对比验证
这里要建立的认知是:把这一节的坑串起来看,会浮现一个对"混合检索"乃至所有"组合多个方案"的工程的总体判断——把两个东西组合在一起,并不天然地等于"取两者之长",组合本身会引入新的、原来不存在的复杂度,而这份复杂度需要你主动去管理。第一版我以为检索的进步路线是"用更强的单一方法";到了混合检索,我又可能滑向另一个天真的想法:"把向量和 BM25 一加,不就两者优点都拿到了?"可这一节的每一个坑都在说不是这么回事:你引入了 BM25,就引入了"中文分词"这个全新的、向量检索里根本不存在的问题;你引入了两路融合,就引入了"RRF 参数怎么调""两路索引怎么保持一致"这些新问题;你引入了重排序,就引入了新的延迟成本。组合方案带来的,从来不是"优点的简单相加",而是"优点相加,同时缺点也相加,还附赠一堆接缝处的新问题"。这就是为什么"用评测说话"在这一节如此关键——你不能假设"混合一定比单路好",你必须用真实数据去测量这个组合的净收益:它带来的检索质量提升,有没有超过它引入的复杂度、延迟和维护成本。这里要建立的通用认知是:每当你想通过"组合多个方案"来解决问题时,要清醒地记住,组合是有代价的——更多的组件、更多的接缝、更多要保持一致的状态、更多会出错的地方。组合值不值得,取决于"它带来的增益"能不能明确地、可测量地盖过"它引入的复杂度"。所以引入任何一个组合方案时,都要同时做两件事:一是把它引入的新复杂度老老实实列出来、并为之建立管理手段(分词词典、参数调优、一致性保证、监控);二是用评测持续验证它的净收益是正的。不为组合的"看起来更全面"而陶醉,只为它"经过测量的、实实在在的净收益"而采用——这才是对待组合方案该有的清醒。
关键概念速查
| 概念 | 说明 | 关键点 |
|---|---|---|
| 向量检索 | 把文本转向量 按语义相似度召回 | 擅长语义模糊匹配 弱在精确字面匹配 |
| 关键词检索 BM25 | 按 token 词频与稀有度算相关性 | 擅长精确字面匹配 弱在语义理解 |
| 能力边界 | 一个工具做不好什么和能做什么同样重要 | 强项和弱项常是同一个取舍的两面 |
| 混合检索 | 向量与关键词两路并行召回再融合 | 两者强项互补 取长补短 |
| 分数量纲不一致 | 向量分 0-1 BM25 分无上界 不可比 | 直接加权融合会被大量纲一路淹没 |
| RRF 倒数排名融合 | 不用分数 只用排名做融合 | 1/(k+rank) 绕开量纲问题 在两路都靠前者得分高 |
| 召回 | 从海量文档里快而粗地捞出候选 | 目标是高召回 宁可错放不可漏杀 |
| 重排序精排 | 用慢而精的模型对候选做精细排序 | cross-encoder 准但慢 只对少量候选用 |
| 召回加精排 | 快而粗筛选 加 慢而精排序的两段式 | 承认快准不可兼得 按规模分两段 |
| NDCG | 考虑排序位置的相关性评测指标 | 衡量好结果有没有排到前面 |
避坑清单
- 别迷信纯向量检索,精确型号、错误码、专有名词是它的短板,必须配关键词检索。
- 别用"新旧"做技术选型,BM25 很老但精确匹配至今没被取代,只看场景实测。
- 两路召回都要宁可多召回,召回阶段目标是别漏,精挑是融合和重排序的事。
- 别用加权求和融合两路分数,量纲不一致会被大量纲那路淹没,用 RRF 按排名融合。
- RRF 的 k 值和每路召回数要一起调,k 太小头部权重过大,召回太少好结果进不了池。
- 分清召回和精排,混合检索负责广撒网,重排序负责精挑,是两个分工别混。
- 中文分词决定 BM25 上限,专有名词、产品型号要进自定义词典,否则被切碎匹配不上。
- 向量索引和关键词索引要同步更新,文档增删改时两路一起改,否则数据不一致。
- 混合不总是赢,要维护标注查询用 recall 和 NDCG 实测混合相对单路的真实增益。
- 重排序有延迟成本,候选数量要在质量和延迟之间权衡,别让精排拖垮整体延迟。
总结
回头看,第一版栽的跟头,根子是一个认知误判:我以为检索技术是一条单向进化的直线,向量检索是新一代、关键词检索是该淘汰的老古董,用新的就行。可这两种检索根本不在一条进化线上——它们擅长的是两类不同的查询:向量检索管语义模糊匹配,你换种说法它也懂;关键词检索管精确字面匹配,型号、错误码、专有名词是它的主场。一个的强项,精确地落在另一个的弱项上。我只用纯向量检索,等于只带了一把模糊匹配的工具上场,所有需要精确匹配的查询从一开始就注定搜不好。
真正把检索做扎实,工作量不在"用最先进的那一种",而在一次思路的转变:不再追求一个全能的单一方法,而是把两种互补的方法组合起来。一旦接受这一点,该做的事就都浮现出来了——两路并行召回、各自宁可多召回,用 RRF 倒数排名融合绕开分数量纲不一致的死结,再叠加一个重排序做精排,并用标注查询持续评测混合相对单路的真实增益。每一步都不复杂,难的是先承认:你要的不是一把削铁如泥的神兵,而是一个工具箱——把擅长不同活的工具各放一把,该用哪把用哪把。
我后来常拿在图书馆找书来想这件事。向量检索,像是你跟图书管理员描述"我想找一本讲怎么把生活过得更从容的书"——管理员凭对意思的理解,给你推荐《断舍离》,哪怕你一个字都没提到书名,这是它的本事。关键词检索,像是你直接报出一个精确的 ISBN 号或一字不差的书名,让管理员去目录卡片里精确比对——你要的就是那一本,不要"语义相近"的别的书。这两种找书的方式,谁也代替不了谁:你只知道大概意思时,得靠前一种;你手里攥着精确编号时,得靠后一种。混合检索,就是让管理员两种方式都试一遍,再把两边的结果合到一起给你。而 RRF 解决的,是两边结果没法直接比的问题——管理员不去纠结"语义推荐的可信度"和"编号匹配的可信度"哪个数值更高,他只看:这本书在两种方式里,是不是都排在前面?都靠前的,就是最该给你的。
这类问题最咬人的地方,在于它在开发测试时几乎永远是"对"的:你用一批自然语言提问去测纯向量检索,它召回得又准又漂亮,你完全看不出它在精确匹配上的瘸腿——因为你的测试集里压根没有型号、错误码、冷门缩写这类查询。它只在真实用户带着五花八门的查询涌进来之后才暴露:有人搜型号搜不到、有人贴错误码抓瞎、有人用内部缩写一片空白,而检索质量这个东西又从不在日志里报错,它只是让用户慢慢觉得"这搜索怎么搜不到我要的"。所以别等用户开始抱怨搜不准,才想起检索的能力边界:做检索的第一天,就该想清楚你的用户会用哪些类型的查询来搜,既有语义型的、也一定有精确型的,然后从一开始就把混合检索的架子搭起来——关键词这一路不该是"以后发现搜不准了再补"的补丁,而该是你设计检索系统时,和向量检索一起摆上桌的另一半。把"两种检索互补、缺一不可"这件事在一开始就认下来,你才算真正跳出了那个迷信单一先进方法、对着搜不到的精确查询百思不解的坑。
—— 别看了 · 2026