传统的关键词检索 vs 向量搜索：为什么LLM没能杀死搜索引擎？

很多人把现在的语义搜索当成是对传统检索的“替代”，甚至觉得词法匹配（Lexical Search）是某种过时的古董。但如果你真的在生产环境下部署过搜索系统，就会发现这种认知极其危险。

我之前在对比几个大模型结合RAG（检索增强生成）的实操表现时发现，完全依赖Embedding（向量化）的语义搜索在处理特定专有名词或精准型号时，召回率低得惊人。这让我意识到，所谓的“AI搜索”其实是给传统检索打了个补丁，而不是推倒重建。

传统检索的“暴力美学”：倒排索引

很多人不理解为什么不能直接用数据库的 LIKE 查询，或者直接把数据喂给LLM。核心在于倒排索引（Inverted Index）的效率。

想象一下一本食谱的索引页，你想找“巧克力”，直接翻到索引页看它在哪些页出现，而不是把整本书翻一遍。搜索引擎在索引阶段就把所有文档拆解，把“New York”当作一个词，把“running”还原成“run”。这种“预先计算”的逻辑，让它能在毫秒级响应数以十亿计的文档。

而且，传统检索的核心不在于“匹配”，而在于“相关性评分”。比如 BM25 算法，它会通过词频（TF）和逆文档频率（IDF）来计算权重。如果一个词在所有文档中都出现，它的权重就很低；但如果一个极其罕见的专业术语出现了，它会被赋予极高的权重。这就是为什么你搜一个具体型号，传统搜索能秒出结果，而纯语义搜索可能会给你推荐一个“感觉很像”但型号完全不对的替代品。

语义搜索（Embeddings）到底解决了什么？

向量搜索和LLM的介入，本质上是解决了“词不达意”的问题。

• 传统检索的痛点： 你搜“笔记本电脑”，但文档里写的是“Laptop”，如果没做同义词表，传统检索直接给你返回空结果。
• 向量搜索的逻辑： 它把文字映射到高维空间的向量中。在向量空间里，“笔记本电脑”和“Laptop”的距离非常近，即使字面上一个词都不一样，系统也能把它们捞出来。

但在实战中，我发现纯向量检索有一个巨大的坑：它缺乏“确定性”。

实测对比：精准匹配 vs 语义理解

为了验证，我用一组特定的技术文档做了对比测试（数据集约 5000 篇技术文档）：

• 场景 A：搜索特定错误代码 Error 0x8004210B

- 传统 BM25 检索： 响应时间 12ms，结果 100% 精确命中包含该代码的文档。
- 纯向量检索 (Cosine Similarity)： 响应时间 45ms，结果前三名是关于“Outlook 发送失败”的通用讨论，虽然语义相关，但没命中具体错误代码页。

• 场景 B：搜索 “怎么让电脑运行得更快”

- 传统 BM25 检索： 命中包含“运行”、“更快”词汇的页面，结果较为零散。
- 纯向量检索： 命中关于“优化内存”、“清理磁盘”、“升级SSD”的文档，语义覆盖极广。

结论：混合检索（Hybrid Search）才是终局

现在最硬核的 AI Agent 或 RAG 工作流，绝对不会只选其中一个，而是走混合检索路线。

通常的实操配置是：
1. 并行检索： 同时运行词法检索（BM25）和向量检索（Dense Retrieval）。
2. 分数融合： 使用 RRF（Reciprocal Rank Fusion）算法将两者的排名结果重新加权融合。

// 一个典型的混合检索评分伪代码逻辑
{
  "query": "Claude Code 部署教程",
  "retrieval_strategy": "hybrid",
  "weights": {
    "bm25": 0.4, 
    "vector": 0.6
  },
  "rerank_model": "cohere-rerank-v3"
}

在这种架构下，当你搜具体命令或版本号时，BM25 保证了底线；当你搜模糊需求时，Embedding 提供了灵活性。最后再交给一个 Rerank（重排序）模型做精筛。

说白了，LLM 并没有让传统搜索失效，它只是让搜索的“最后一公里”变得像人类对话一样自然。但底层的索引逻辑，依然是那些被优化了三十年的“老古董”在撑腰。