艾体宝洞察|语义搜索与关键词搜索？业务的抉择

包括我在内不少人第一次做搜索功能时都会觉得这是一件没什么技术含量的事用户输入几个词系统返回结果不就行了吗但只要你真正做过搜索系统尤其是参与过RAGRetrieval-Augmented Generation检索增强生成相关项目就会很快意识到​搜索本身就是最容易在 Demo 阶段表现非常完美、却在生产环境频频翻车的模块之一​。在测试环境里无论是搜索的结果相关度抑或是排序是否合理一切都非常每秒。可一旦真正给用户使用问题马上暴露出来明明是很直观的内容却怎么都搜不到搜索结果里混进了大量看起来相关、实际没用的文档这类问题​往往不是实现细节的问题而是搜索模型选错了​。现实情况是​不同搜索场景本来就应该使用不同的搜索策略​。有些场景需要系统理解数据库变慢了同性能调优在语义上的关联有些场景则必须精确命中SKU-2847-B这种编号不能模糊、不能联想真正的生产系统几乎都需要​语义搜索Semantic Search和关键词搜索Keyword Search同时存在​。本文会从工程视角出发系统性地说明这两种搜索方式各自是怎么工作的它们在能力边界上的根本差异为什么最终都会走向混合搜索Hybrid Search什么是语义搜索Semantic Search语义搜索解决的核心问题只有一个“理解你想表达的意思而不是具体的哪些词。”与传统搜索不同语义搜索并不依赖“关键词是否出现”而是通过神经网络模型把文本转换成 ​**向量嵌入vector embeddings**​。这些向量在数学空间中表达的是“语义距离”而不是字面相似度。因此只要语义接近即使查询词和文档里完全没有重合的词也依然可以被检索出来。语义搜索的基本工作流程从系统实现角度看语义搜索通常包含三个核心步骤​文本向量化​使用 Transformer 类模型例如 BERT将文本编码为高维向量。​向量相似度计算​常见做法是使用余弦相似度cosine similarity衡量语义接近程度。​按相似度排序结果​相似度越高结果越靠前。为什么说语义搜索能“理解含义”当文本输入到 embedding 模型后模型会先进行分词然后将这些 token 映射到一个高维向量空间中。 像 BERT 这样的模型生成的是​高维、稠密的向量表示​能够捕捉非常细腻的语义关系。这也是为什么搜索“汽车维修”系统可以返回只写了“车辆保养”“汽车维护”的内容从字面看完全不同但在向量空间中它们的距离非常近因此被判定为“语义相关”。在相似度计算阶段系统通常使用余弦相似度只关心向量方向是否接近而不关心数值大小。最终得到的分值通常在​1​语义几乎完全一致​0​基本无关-1语义相反整体来看语义搜索在召回能力和语义相关性上明显优于传统关键词搜索。什么是关键词搜索Keyword Search关键词搜索的逻辑非常直接也非常“工程化”你输入什么词我就找哪些文档里出现过这些词。它依赖的是一套成熟、稳定、经过几十年验证的经典搜索架构。关键词搜索的核心机制​**倒排索引Inverted Index**​每个词都对应一组包含该词的文档列表。搜索时直接定位文档而不是全表扫描。​查询解析与匹配​搜索“database optimization”时系统分别查找两个词对应的文档集合再做交集。​BM25 排序算法​一种基于概率模型的打分方式综合考虑词在文档中出现的频率该词在所有文档中的稀有程度文档长度的归一化处理BM25 为什么这么常用BM25 的两个参数非常实用​k1​限制词频带来的收益避免“堆关键词”​b​做文档长度归一化防止长文档天然吃亏这套机制在各种规模、各种领域的数据集上都表现稳定因此成为关键词搜索的事实标准。搜索前的文本处理流程在进入索引之前文本通常会经历分词tokenization统一大小写停用词过滤如 the / is词干化running / runs / ran → run关键词搜索的特点优点非常明显查询速度快行为可预测结果完全确定、可复现但代价也很清楚不理解同义词不理解上下文只能匹配“写出来的词”回到上面的例子如果文档里没出现“汽车维修”那就一定搜不到。语义搜索和关键词搜索的本质差异两者的根本区别不在“算法复杂度”而在​匹配方式​​关键词搜索​基于词项的字面匹配lexical matching​语义搜索​基于向量空间的语义相似semantic matching| 特性 | 关键词搜索 | 语义搜索 || ---------- | ---------------------------------- | ------------------------------------ || 匹配方式 | 基于倒排索引的字面精确匹配 | 高维空间中的向量表示与相似度匹配 || 内存占用 | 稀疏表示内存消耗相对较低 | 生产级索引通常需要较大的内存支持 || 延迟 | 大规模数据集下极快 | 较高涉及神经网络推理与向量检索 || 失败模式 | 无法处理同义词和上下文语义 | 容易漏掉特定的术语、编号或产品代码 || 最佳场景 | 精确标识符、布尔逻辑、合规性搜索 | 自然语言查询、概念相似性、RAG |这种差异会直接影响系统在生产环境中的表现。关键恰恰在于它们的“失败方式是互补的”。搜索“数据库内存问题”时语义搜索能联想到缓存淘汰、OOM 等内容搜索OOM-2024-047时只有关键词搜索是可靠的这正是生产系统必须同时使用两者的原因。什么时候更适合用语义搜索只要你的系统面对的是​自然语言表达​语义搜索往往是更优解。RAG检索增强生成实现RAG 的关键不在“搜到包含关键词的文档”而在于​搜到语义最接近的上下文片段​。语义搜索通过向量相似度能稳定为大模型提供高质量上下文。问答系统用户习惯用口语提问而技术文档通常使用专业术语。语义搜索能弥合这种差异。例如当用户问“怎么防止 Redis 内存爆掉”系统能自动关联到内存管理、淘汰策略、maxmemory 的文档。多语言应用向量空间天然支持跨语言语义对齐不必先做翻译。对话式 AI多轮对话需要理解上下文延续语义搜索在这里几乎是刚需。什么时候关键词搜索更合适当精确性和确定性优先级高于“理解语义”时关键词搜索依然不可替代。精确标识符处理产品编码SKU、模型号、数据库主键或法律条文编号时这些内容必须一个不差。复杂布尔条件字段过滤、短语匹配、距离搜索关键词搜索提供的是精确的控制力。合规与审计BM25 的结果完全可复现在合规场景下非常重要。小到中等规模数据集如果只是为一个简单的 CRUD 应用添加全文搜索功能关键词搜索的实现成本更低维护也更简单更省钱。现代应用的选择混合搜索 (Hybrid Search)由于单一方法都有局限生产系统通常采用​混合搜索​将稠密向量检索与稀疏关键词检索结合并使用RRF (Reciprocal Rank Fusion)算法合并两者的排名。在 Redis 中实现混合搜索Redis 通过集成向量检索和全文搜索组件提供了一站式的混合搜索能力。你不需要维护两套独立的数据库系统。# 示例使用 Redis 进行混合检索Python 伪代码from redis.commands.search.query import Query def perform_hybrid_search(index_name, user_query, query_vector):# 构建混合查询# 1. 关键词搜索 performance# 2. 向量相似度搜索 (KNN) base_query f(content:performance)[KNN 10 vector $vec_param AS score] search_query ( Query(base_query).sort_by(score).paging(0, 10).return_fields(id, content, score).dialect(2)) query_params {vec_param: query_vector # 预先生成的向量数据} results redis_client.ft(index_name).search(search_query, query_params)return resultsRedis 的优势​HNSW 索引​支持高性能、高精度的近似最近邻搜索。​统一 API​通过一个查询即可同时处理向量相似度和结构化过滤。​生态集成​原生支持 LangChain、LlamaIndex 等主流 AI 框架。没有完美的搜索算法只有最适合场景的组合。如果你也在构建适配新型业务场景的搜索方案混合搜索不失为一个利器。