从关键字匹配到向量检索：搜索技术的三条路

搜索系统并不是只有一种做法。关键字匹配擅长找“写出来的词”，模糊搜索擅长救“写错或写不全的词”，向量检索擅长找“意思接近的内容”。到了 RAG 场景，它们往往不是互相替代，而是组合成一条更稳的检索链路。

先用一个例子定调：

用户真正想问	输入	更适合的检索方式
查某条明确规则	`退款政策`	关键字匹配
输入有拼写或错别字	`退宽政策` / `retun policy`	模糊搜索
说法很口语化	`买了东西后还能不能反悔`	向量检索
要既准又能理解语义	`会员买错套餐怎么退款`	混合检索 + 重排序

关键字匹配：找到“字面上出现过”的内容

关键字匹配是最经典的信息检索方式。它的核心思想很朴素：把文档切成词，建立索引，查询时看哪些文档包含这些词，再根据词频、字段权重、文档长度等因素排序。

搜索引擎、数据库 LIKE 查询、日志平台、站内搜索、文档系统都大量使用这种思路。工程上最常见的结构是倒排索引：不是从文档找词，而是从词直接找到包含它的文档。

特点	说明
匹配依据	查询词和文档词项的字面重合
常见算法	TF-IDF、BM25、布尔查询、字段权重
优点	快、稳定、可解释、容易加过滤条件
缺点	不懂同义词和上下文，用户换一种说法就可能搜不到
适合	商品 SKU、订单号、日志关键字、法规条款、代码符号、标题搜索

例如用户搜索 redis setnx，关键字检索非常合适，因为这个词本身就是准确术语；如果用户搜索 如何防止重复下单，纯关键字系统就可能漏掉只写了 幂等、分布式锁 的文章。

模糊搜索：解决“写错了也要搜到”

模糊搜索仍然是词面检索，只是比关键字匹配宽容一点。它关注的是：用户输入和真实词项长得像不像。

常见手段包括：

技术	解决的问题	例子
编辑距离	少字、多字、错字、相邻字母颠倒	`retun` → `return`
n-gram / trigram	子串相似、短文本近似匹配	`microserv` → `microservice`
前缀匹配	搜索建议、自动补全	`kuber` → `kubernetes`
拼音/同音纠错	中文输入法误差	`shiliangjiansuo` → `向量检索`
同义词词典	人工维护近义表达	`售后` ≈ `退货`

它最适合搜索框体验：用户没有输入完整词、英文拼错、中文有错别字、商品名只记得一半。Elasticsearch、OpenSearch、Solr、PostgreSQL trigram、Algolia 这类系统里都有对应能力。

但要注意，模糊搜索的本质不是“理解语义”。退款 和 退货 语义相关，但字面未必相似；苹果手机 和 iPhone 字面差异很大，靠编辑距离很难自然匹配。模糊搜索放宽召回后，还会带来误匹配，所以需要阈值、字段权重、热度、点击率等信号做排序。

向量检索：找到“意思接近”的内容

向量检索会先用 Embedding 模型把文本、图片、音频等内容转成一串数字。语义相近的内容，在向量空间里的距离也更近。查询时，系统把用户问题也转成向量，再找距离最近的内容。

这就是很多 RAG 系统的检索底座：先从知识库中召回相关片段，再把片段塞进 Prompt，让大模型基于资料回答。

特点	说明
匹配依据	Embedding 空间里的语义相似度
常见索引	HNSW、IVF、PQ、DiskANN
常见度量	余弦相似度、内积、欧氏距离
优点	能处理同义表达、口语化问题、跨语言/跨模态相似
缺点	成本更高，可解释性弱，精确过滤和强约束不如传统检索
适合	知识库问答、相似文章、相似图片、推荐、智能客服、代码语义搜索

比如文档里写的是：

1

用户在订单完成后的 7 天内，可申请无理由退货。

用户问：

1

买完后不想要了还能退吗？

关键字匹配可能只看到 买完、不想要，命中不稳定；向量检索更容易把它和 退货、订单完成后、7 天内 这些语义相关片段拉近。

向量检索也不是银弹。它对数字、版本号、专有名词、权限过滤、精确字段并不天然可靠。问 HTTP 451、订单 202610020001、Go 1.22 这类问题时，关键字和结构化过滤往往更可信。

它们到底差在哪

维度	关键字匹配	模糊搜索	向量检索
关注点	词是否出现	词是否相似	意思是否接近
用户输入	明确、短、术语化	有错字、缩写、前缀	口语化、描述性、长问题
召回能力	精确但可能漏	比关键字更宽	语义召回强
排序可解释性	强	中等	弱，需要额外解释
延迟与成本	低	中	中到高
典型工具	MySQL、Lucene、Elasticsearch BM25	Elasticsearch fuzzy、trigram、Algolia	FAISS、Milvus、Qdrant、Pinecone、Weaviate
常见问题	同义词搜不到	误匹配变多	召回噪声、Embedding 漂移、难调参

可以把它们理解成三层：

1
2
3


关键字匹配：你说了 A，我找 A
模糊搜索：你大概写的是 A，我帮你找 A
向量检索：你说的是 A 的意思，我找和 A 意思接近的内容

经典应用

场景	推荐方案	为什么
日志检索	关键字 + 时间/服务过滤	错一个字符都可能代表不同错误码，精确性优先
电商搜索	关键字 + 模糊搜索 + 向量召回	商品名要准，用户输入也常常不完整，还需要语义推荐
代码搜索	符号索引 + 关键字 + 语义向量	函数名要精确，需求描述又可能很口语
企业知识库问答	向量检索 + BM25 + 重排序 + RAG	需要理解问题、召回资料、生成答案并引用来源
图片以图搜图	向量检索	图像相似度很难靠关键字解决
站内帮助中心	关键字 + 模糊 + 同义词 + 向量	用户可能输入术语，也可能输入自然语言问题

最典型的例子是企业知识库 RAG。用户不会严格复述文档标题，而是问“这笔报销为什么被驳回”“试用期请病假怎么算”“客户要求删数据怎么办”。系统通常会先做权限过滤，再用 BM25 和向量各召回一批候选，最后重排序，选少量片段交给大模型回答。

实战选型：不要急着三选一

一个实用的判断方式：

你遇到的问题	优先考虑
用户会输入订单号、错误码、函数名、固定术语	关键字匹配
用户经常拼错、少打、只输入前几个字	模糊搜索
用户用自然语言描述需求，文档表达方式又不固定	向量检索
既要精确过滤，又要语义理解，还要给 LLM 喂资料	混合检索

生产系统里更常见的是组合拳：

结构化过滤：先按权限、租户、时间、类目过滤，避免召回不该看的内容。
关键字召回：用 BM25 保住精确术语、标题、编号、实体名。
向量召回：补足同义表达、口语化问题和长文本语义。
融合排序：用 RRF 或加权分数合并两路候选。
重排序：用 cross-encoder、LLM reranker 或业务规则做精排。
生成回答：RAG 场景只把最相关、最可信、来源清楚的片段交给 LLM。

一个容易记住的结论

关键字匹配解决的是有没有这个词，模糊搜索解决的是这个词是不是写歪了，向量检索解决的是这句话大概在说什么。

如果你在做一个普通搜索框，先把关键字、分词、字段权重和模糊纠错做好；如果你在做知识库问答或智能客服，再引入向量检索和 RAG；如果你在做面向真实用户的生产系统，最终大概率会走向混合检索。因为用户既会输入精确编号，也会说一大段含糊的话，而好的搜索系统要同时接得住这两种输入。