什么是混合搜索（Hybrid Search）？一种同时执行全文检索与向量检索的查询方式
混合搜索是 Azure AI Search 中的一种查询方式：单个查询请求同时包含全文检索与向量检索参数，两类检索并行执行，再用倒数排名融合（RRF）合并为单一结果集。它把关键词检索的精确性与向量检索的语义相似性结合起来，适用于需要兼顾精确匹配与语义召回的检索增强场景。
混合搜索（Hybrid Search）是 Microsoft Learn 官方文档中描述的一种检索方式：把全文检索（full-text search）与向量检索（vector search）配置在同一个查询请求中，让两类检索并行执行，再合并为单一结果集。按该文档的说法，它要解决的问题是单一检索方式的偏科——向量检索擅长找出与查询在语义上相近、但倒排索引里没有关键词命中的内容，关键词检索则擅长精确匹配；混合搜索试图同时拿到这两方面的能力。
为什么重要
在混合搜索出现之前，检索系统通常要在两条路线之间做选择。纯关键词或全文检索依赖倒排索引，优点是精确：查询词与文档中的词直接对上就能命中，还能叠加过滤、分面、排序、评分配置以及可选的语义排序（semantic ranking）来改善初始结果的质量。但它的短板也明显：如果用户描述的是概念而非原词，倒排索引里没有对应词项，就可能召回不到相关内容。
纯向量检索则相反。它把一段文本表示成向量，通过相似度计算找出概念上接近的内容，即使查询与文档之间没有共同关键词也能命中。但按该文档的说明，某些场景恰恰更依赖关键词检索的精确性，例如产品编码、高度专业化的术语、日期以及人名，这些内容需要的是精确匹配，而不是“意思差不多”。
因此痛点在于：真实查询往往同时包含这两类需求。一个查询里既有需要语义理解的描述性语句，也可能夹着必须精确命中的编号或专名。只选一种检索方式，就总有一类查询效果不佳。混合搜索的价值主张正是把两者放进同一个请求里，让系统不必在精确性与语义召回之间二选一。该文档还提到，在真实世界数据集与基准数据集上的基准测试表明，配合语义排序器的混合检索在搜索相关性上有明显收益——这是该文档陈述的测试结论，而非独立第三方评测。
工作机制
按该文档的描述，混合搜索的核心做法可以拆成以下几个要点。
- 单一请求、两类参数。混合搜索是一个单独的查询请求，请求中同时包含
search与vectorQueries两类查询参数。它不是先发一次关键词查询、再发一次向量查询，而是在一个请求里声明两种查询意图。 - 面向同时含文本与向量的索引。混合查询运行在一个搜索索引之上，该索引既包含可搜索的纯文本内容，也包含生成的嵌入（embeddings）。索引中的向量字段与文本字段、数值字段共存，若需要地理空间检索还可以包含地理坐标字段。
- 并行执行。全文检索与向量检索并行运行，各自使用不同的排序函数：文本侧例如 BM25，向量侧例如分层可导航小世界（Hierarchical Navigable Small World，HNSW）与穷举式最近邻（exhaustive K Nearest Neighbors，eKNN）。
- 用 RRF 合并。两路结果通过倒数排名融合（Reciprocal Rank Fusion，RRF）算法合并。查询响应只返回一个结果集，由 RRF 对统一后的结果排序。
- 保留文本侧既有能力。混合查询可以沿用文本字段上已有的功能，例如过滤、分面、排序、评分配置与语义排序，同时在同一请求中对向量执行相似度搜索。该文档指出，除自动补全（autocomplete）与建议（suggestions）这类纯文本的客户端交互外，Azure AI Search 的几乎全部查询能力都可以与向量查询一起使用。
该文档给出的一个代表性混合查询示例，是在酒店索引上检索“historic hotel walk to restaurants and shopping”，同时附带按地理距离的过滤条件、分面字段以及向量查询数组；为简洁起见，示例中的向量查询使用了占位值。这个例子说明混合查询可以把关键词、向量、过滤与分面组合进同一个请求。
典型例子
该文档中出现的真实用法与系统包括：
- Azure AI Search 本身。混合搜索是 Azure AI Search 的一项查询能力，可通过 Azure 门户、REST API 与 Azure SDK 使用；该文档还提到它支撑 Foundry IQ 这一托管知识层，用于把企业内容转化为可供 Microsoft Foundry 门户中智能体复用的、带权限感知的知识库。
- 酒店检索示例。文档给出的混合查询示例针对
hotels-vector-quickstart索引，查询语句为“historic hotel walk to restaurants and shopping”，并带有地理距离过滤、州/省分面以及向量查询。 - 适合关键词精确匹配的场景。文档明确列举产品编码、高度专业化的术语、日期与人名，认为这些场景用关键词检索表现更好，因为可以识别精确匹配——这也正是混合搜索需要保留全文检索一路的原因。
边界与常见误解
首先，混合搜索不等于“向量检索的升级版”。按该文档的定位，它是两种检索方式的组合，向量检索只是其中一路；在需要精确匹配编码、日期、人名的查询上，全文检索那一路仍然承担主要作用。把它理解成“只用向量就够了”会偏离其设计意图。
其次，混合搜索也不是“把所有查询能力都搬到向量上”。该文档明确指出，自动补全与建议这类纯文本客户端交互不适用于向量查询，因此这类交互不在混合查询的覆盖范围内。
第三，关于效果，应当注意信息来源。该文档称，在真实世界与基准数据集上的基准测试显示，配合语义排序器的混合检索在搜索相关性上有显著收益。这是 Microsoft 官方文档基于其自身测试给出的说法，不应被当作跨厂商、跨数据集的普遍结论；具体收益会随数据、查询分布与配置而变化。
第四，混合搜索有结构性代价。它要求索引中同时存在可搜索文本与生成的嵌入，意味着需要额外的向量化流程与存储；查询时要并行执行两路检索并做 RRF 融合，链路比单一检索更长。此外，RRF 是一种基于排名的融合方法，最终结果由两路排名共同决定，单路检索中排名靠前的结果未必在融合后仍居首位。
最后，混合搜索解决的是“召回与排序”层面的问题，它本身不是生成模型，也不保证生成式应用的答案正确；该文档把它描述为为生成式搜索应用提供高质量基础数据（grounding data）的检索环节。