包括我在内，不少人第一次做搜索功能时，都会觉得这是一件没什么技术含量的事：用户输入几个词，系统返回结果，不就行了吗？
但只要你真正做过搜索系统，尤其是参与过 RAG（Retrieval-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 results
Redis 的优势：
- HNSW 索引：支持高性能、高精度的近似最近邻搜索。
- 统一 API：通过一个查询即可同时处理向量相似度和结构化过滤。
- 生态集成：原生支持 LangChain、LlamaIndex 等主流 AI 框架。
没有完美的搜索算法，只有最适合场景的组合。如果你也在构建适配新型业务场景的搜索方案，混合搜索不失为一个利器。
