向量检索 vs 关键词检索RAG 为什么不能只靠其中一种RAG检索增强生成系统的效果本质上被一个环节牢牢卡住——检索。检索搜不到对的内容再强的 LLM 也只能对着错误的上下文“一本正经地编”。很多人把检索简单地理解成“把问题转成向量去查相似度”但真正跑过生产的人都会撞到同一堵墙用户搜“RTX 4090 显卡功耗”知识库里明明就写着“RTX 4090”向量检索却死活召不回来。问题的根源不在于模型不够好而在于检索方式本身有盲区。今天就把向量检索和关键词检索这两条路线彻底拆开讲清楚它们各自的擅长与短板以及为什么生产环境的 RAG 几乎都不会只用其中一种。检索要解决的核心问题检索的本质是给定一段查询从海量文档里找出最相关的那几条。而“相关”这个词本身就有两种截然不同的理解一种是字面意义上的词汇重叠另一种是语义层面的意思接近。关键词检索和向量检索恰好分别对应这两种理解。很多人误以为“检索 搜关键词”其实那只是其中一种方式也有人误以为“向量检索更高级应该全面取代关键词检索”这同样是个误区。两种方式各有盲区而且刚好互补这才是理解混合检索的关键。关键词检索BM25字面匹配靠统计关键词检索的代表算法是 BM25Best Match 25它是 Elasticsearch、Lucene 等传统搜索引擎的核心。它的底层数据结构是倒排索引——记录的不是“每篇文档里有哪些词”而是反过来记录“每个词出现在哪些文档里”。打分时BM25 主要看两个因素。第一个是词频TF这个词在这篇文档里出现了几次出现越多说明越相关。第二个是稀缺度IDF这个词在整个语料里有多罕见。IDF 的存在非常关键因为“的”“是”“在”这类词在任何文档里都高频出现如果只看词频每篇文档都会因为这些常用词拿到高分根本区分不出哪篇真正相关。所以 IDF 的作用就是给常见词降权、给罕见词加权让真正有区分力的词来决定排序。BM25 在 TF-IDF 的基础上又加了饱和度限制防止某个词重复出现太多次后权重无限叠加。BM25 的优势是精确词命中率极高产品型号“iPhone 15 Pro Max”、专有名词“LSTM”、缩写“RAG”只要文档里有这个词它就能精准找到。但它的劣势同样致命——遇到同义词就束手无策。用户查“手机截图”文档里写的是“iPhone 截屏教程”BM25 看到没有任何词汇重叠分数直接为零哪怕这篇文档正是最相关的答案。向量检索语义匹配靠 Embedding向量检索要解决的是另一个问题让系统“理解意思”而不是“匹配字面”。它的做法是先用 Embedding 模型把每段文本转成一个高维向量比如 1024 维的浮点数列表这个向量可以理解为这段文本在“语义空间”里的坐标。语义相近的文本坐标就靠近语义不相关的坐标就离得远。这样一来“苹果手机怎么截图”和“iPhone 如何截屏”这两句话虽然字面完全不同但经过 Embedding 之后余弦相似度可以高达 0.95。向量检索通过近似最近邻ANN算法在向量库里找和查询向量最近的 Top-K 条工程上常用 HNSW、IVF、PQ 等结构百万量级的向量库通常几十毫秒就能返回结果。但向量检索也不是万能的。它的短板恰好落在 BM25 的强项上——对精确词汇不敏感。产品型号、人名、版本号这类词在 Embedding 空间里彼此距离可能并不近向量检索容易把它们混淆在一起。这就是为什么“RTX 4090”“M4 Pro”这类精确专有名词用向量检索反而召不回来而 BM25 却能秒找到。这个局限不是换更强的 Embedding 模型能解决的它是“只看语义、不看字面”这一检索方式本身的固有属性。两者核心区别对比维度关键词检索BM25向量检索匹配方式词汇重叠统计语义空间距离索引结构倒排索引稀疏向量库稠密同义词处理无法处理天然支持精确词命中极好容易漏计算方式基于统计可解释黑盒向量距离适合场景专有名词、代码、精确查询语义问答、模糊表达这张表一眼就能看出两种方式的“短板”和“擅长”恰好互换谁也无法替代谁。这直接引出了下一节的核心结论。混合检索两路都跑取长补短既然两种方式各有盲区且刚好互补最自然的想法就是两路都跑。工程实践中的标准做法叫混合检索Hybrid Search同时跑向量检索和 BM25各自召回一批候选再用 RRFReciprocal Rank Fusion倒数排名融合把两路结果合并排序。这里有个容易踩的坑为什么不直接把两路分数加权平均因为向量相似度0 到 1 的余弦值和 BM25 分数可能是任意正数的量纲完全不同直接相加就像拿摄氏度和华氏度相加一样没有意义。RRF 的巧妙之处在于它不看原始分数只看排名用排名的倒数来打分RRFscore(d)∑r∈R1krankr(d)\text{RRFscore}(d) \sum_{r \in R} \frac{1}{k \text{rank}_r(d)}RRFscore(d)r∈R∑krankr(d)1其中kkk是平滑参数通常取 60rankr(d)\text{rank}_r(d)rankr(d)是文档ddd在第rrr路结果中的排名。排名越靠前倒数越大一个文档在多路检索里都排名靠前它的 RRF 综合分就越高就像多位评委都打了高分的选手综合排名自然靠前。这个方法不需要训练、计算量极小工程落地成本很低。混合检索还有一个额外好处两路检索可以并行执行总延迟取两路中的最大值而不是两者相加几乎不增加时间代价但召回质量比单路明显更好。这也是为什么生产环境的 RAG 系统很少只用纯向量检索混合检索已经成为行业默认做法。从两路到多路补上表述差异的盲区向量 BM25 解决了“语义匹配”和“精确词匹配”的问题但还有一种场景它们都覆盖不到——用户提问的角度和文档表述的角度根本不一样不是同义词的问题而是整个视角的差异。比如用户问“产品多久能送到”文档里写的是“配送时效说明”两句话角度完全不同向量相似度可能不高BM25 也匹配不到关键词。这时候就需要第三路多 Query 扩展。做法是用 LLM 把用户的原始问题改写成 35 个不同角度的版本分别去检索再把所有结果合并去重。只要有一个改写版本和文档的表述对上了就能把正确内容召回来。代价是增加 LLM 调用开销但在用户提问风格多变的场景下召回覆盖率能提升 10%20%。Rerank 精排把粗排结果筛到最前RRF 融合本质上还是粗排它只看排名、忽略原始相似度分数适合做候选集合并。如果对最终召回精度要求很高还要在 RRF 融合之后接一个 Cross-Encoder 结构的精排模型比如 bge-reranker-v2-m3、Qwen3-Reranker 等做深度打分。精排模型会把“查询—文档”逐一配对做完整推理给出精确的相关性分数把真正相关的内容筛到最前再把最终上下文交给 LLM。实战建议不是每个场景都需要三路全上按业务特点来选即可。知识库里存在大量专有名词、产品型号、数字的场景电商、IT 文档向量 BM25 双路是标配用户提问方式多变、和文档表述差异大的场景客服问答再加上多 Query 扩展对召回质量要求极高的场景三路全上并接 Rerank 精排把质量做到天花板。写在最后一句话总结既然没有任何一种检索方式是全能的那就同时走多条路——向量检索管语义BM25 管精确词多 Query 扩展管表述差异RRF 融合三路结果Rerank 负责最后的精排。把“为什么单路不够”和“多路怎么组合、怎么融合”这两条线讲清楚无论是面试还是实际落地都算真正把检索这件事吃透了。
向量检索 vs 关键词检索RAG 为什么不能只靠其中一种RAG检索增强生成系统的效果本质上被一个环节牢牢卡住——检索。检索搜不到对的内容再强的 LLM 也只能对着错误的上下文“一本正经地编”。很多人把检索简单地理解成“把问题转成向量去查相似度”但真正跑过生产的人都会撞到同一堵墙用户搜“RTX 4090 显卡功耗”知识库里明明就写着“RTX 4090”向量检索却死活召不回来。问题的根源不在于模型不够好而在于检索方式本身有盲区。今天就把向量检索和关键词检索这两条路线彻底拆开讲清楚它们各自的擅长与短板以及为什么生产环境的 RAG 几乎都不会只用其中一种。检索要解决的核心问题检索的本质是给定一段查询从海量文档里找出最相关的那几条。而“相关”这个词本身就有两种截然不同的理解一种是字面意义上的词汇重叠另一种是语义层面的意思接近。关键词检索和向量检索恰好分别对应这两种理解。很多人误以为“检索 搜关键词”其实那只是其中一种方式也有人误以为“向量检索更高级应该全面取代关键词检索”这同样是个误区。两种方式各有盲区而且刚好互补这才是理解混合检索的关键。关键词检索BM25字面匹配靠统计关键词检索的代表算法是 BM25Best Match 25它是 Elasticsearch、Lucene 等传统搜索引擎的核心。它的底层数据结构是倒排索引——记录的不是“每篇文档里有哪些词”而是反过来记录“每个词出现在哪些文档里”。打分时BM25 主要看两个因素。第一个是词频TF这个词在这篇文档里出现了几次出现越多说明越相关。第二个是稀缺度IDF这个词在整个语料里有多罕见。IDF 的存在非常关键因为“的”“是”“在”这类词在任何文档里都高频出现如果只看词频每篇文档都会因为这些常用词拿到高分根本区分不出哪篇真正相关。所以 IDF 的作用就是给常见词降权、给罕见词加权让真正有区分力的词来决定排序。BM25 在 TF-IDF 的基础上又加了饱和度限制防止某个词重复出现太多次后权重无限叠加。BM25 的优势是精确词命中率极高产品型号“iPhone 15 Pro Max”、专有名词“LSTM”、缩写“RAG”只要文档里有这个词它就能精准找到。但它的劣势同样致命——遇到同义词就束手无策。用户查“手机截图”文档里写的是“iPhone 截屏教程”BM25 看到没有任何词汇重叠分数直接为零哪怕这篇文档正是最相关的答案。向量检索语义匹配靠 Embedding向量检索要解决的是另一个问题让系统“理解意思”而不是“匹配字面”。它的做法是先用 Embedding 模型把每段文本转成一个高维向量比如 1024 维的浮点数列表这个向量可以理解为这段文本在“语义空间”里的坐标。语义相近的文本坐标就靠近语义不相关的坐标就离得远。这样一来“苹果手机怎么截图”和“iPhone 如何截屏”这两句话虽然字面完全不同但经过 Embedding 之后余弦相似度可以高达 0.95。向量检索通过近似最近邻ANN算法在向量库里找和查询向量最近的 Top-K 条工程上常用 HNSW、IVF、PQ 等结构百万量级的向量库通常几十毫秒就能返回结果。但向量检索也不是万能的。它的短板恰好落在 BM25 的强项上——对精确词汇不敏感。产品型号、人名、版本号这类词在 Embedding 空间里彼此距离可能并不近向量检索容易把它们混淆在一起。这就是为什么“RTX 4090”“M4 Pro”这类精确专有名词用向量检索反而召不回来而 BM25 却能秒找到。这个局限不是换更强的 Embedding 模型能解决的它是“只看语义、不看字面”这一检索方式本身的固有属性。两者核心区别对比维度关键词检索BM25向量检索匹配方式词汇重叠统计语义空间距离索引结构倒排索引稀疏向量库稠密同义词处理无法处理天然支持精确词命中极好容易漏计算方式基于统计可解释黑盒向量距离适合场景专有名词、代码、精确查询语义问答、模糊表达这张表一眼就能看出两种方式的“短板”和“擅长”恰好互换谁也无法替代谁。这直接引出了下一节的核心结论。混合检索两路都跑取长补短既然两种方式各有盲区且刚好互补最自然的想法就是两路都跑。工程实践中的标准做法叫混合检索Hybrid Search同时跑向量检索和 BM25各自召回一批候选再用 RRFReciprocal Rank Fusion倒数排名融合把两路结果合并排序。这里有个容易踩的坑为什么不直接把两路分数加权平均因为向量相似度0 到 1 的余弦值和 BM25 分数可能是任意正数的量纲完全不同直接相加就像拿摄氏度和华氏度相加一样没有意义。RRF 的巧妙之处在于它不看原始分数只看排名用排名的倒数来打分RRFscore(d)∑r∈R1krankr(d)\text{RRFscore}(d) \sum_{r \in R} \frac{1}{k \text{rank}_r(d)}RRFscore(d)r∈R∑krankr(d)1其中kkk是平滑参数通常取 60rankr(d)\text{rank}_r(d)rankr(d)是文档ddd在第rrr路结果中的排名。排名越靠前倒数越大一个文档在多路检索里都排名靠前它的 RRF 综合分就越高就像多位评委都打了高分的选手综合排名自然靠前。这个方法不需要训练、计算量极小工程落地成本很低。混合检索还有一个额外好处两路检索可以并行执行总延迟取两路中的最大值而不是两者相加几乎不增加时间代价但召回质量比单路明显更好。这也是为什么生产环境的 RAG 系统很少只用纯向量检索混合检索已经成为行业默认做法。从两路到多路补上表述差异的盲区向量 BM25 解决了“语义匹配”和“精确词匹配”的问题但还有一种场景它们都覆盖不到——用户提问的角度和文档表述的角度根本不一样不是同义词的问题而是整个视角的差异。比如用户问“产品多久能送到”文档里写的是“配送时效说明”两句话角度完全不同向量相似度可能不高BM25 也匹配不到关键词。这时候就需要第三路多 Query 扩展。做法是用 LLM 把用户的原始问题改写成 35 个不同角度的版本分别去检索再把所有结果合并去重。只要有一个改写版本和文档的表述对上了就能把正确内容召回来。代价是增加 LLM 调用开销但在用户提问风格多变的场景下召回覆盖率能提升 10%20%。Rerank 精排把粗排结果筛到最前RRF 融合本质上还是粗排它只看排名、忽略原始相似度分数适合做候选集合并。如果对最终召回精度要求很高还要在 RRF 融合之后接一个 Cross-Encoder 结构的精排模型比如 bge-reranker-v2-m3、Qwen3-Reranker 等做深度打分。精排模型会把“查询—文档”逐一配对做完整推理给出精确的相关性分数把真正相关的内容筛到最前再把最终上下文交给 LLM。实战建议不是每个场景都需要三路全上按业务特点来选即可。知识库里存在大量专有名词、产品型号、数字的场景电商、IT 文档向量 BM25 双路是标配用户提问方式多变、和文档表述差异大的场景客服问答再加上多 Query 扩展对召回质量要求极高的场景三路全上并接 Rerank 精排把质量做到天花板。写在最后一句话总结既然没有任何一种检索方式是全能的那就同时走多条路——向量检索管语义BM25 管精确词多 Query 扩展管表述差异RRF 融合三路结果Rerank 负责最后的精排。把“为什么单路不够”和“多路怎么组合、怎么融合”这两条线讲清楚无论是面试还是实际落地都算真正把检索这件事吃透了。
