弹性搜索虽好，向量数据库才是未来趋势

这篇文章最初发布在 The New Stack，并在此获得许可转载。

一直以来，关键词匹配，也称为全文搜索，例如Elasticsearch，一直是像企业搜索和推荐引擎这类信息检索系统中的默认选择。

随着人工智能搜索技术的发展，搜索正朝着语义搜索（https://zilliz.com/glossary/semantic-search）的方向前进，使系统能够理解用户查询的含义和意图。嵌入式模型和向量数据库（https://zilliz.com/learn/what-is-vector-database）已成为这一转变的关键。

语义搜索通过表示数据的向量嵌入，超越了关键词匹配，提供了对搜索意图的更细致的理解和表达，并将应用从检索增强生成（RAG）到多模态搜索进行了升级或改造。

实际上，一个有效的信息检索系统需要既能理解语义，又能精确匹配关键词。比如，用户希望搜索结果不仅展示相关的概念，同时也要考虑查询中使用的特定术语和名称，还要返回完全匹配的结果。

由密集向量支持的语义搜索有助于理解词语之间的关系（例如知道“car”和“automobile”是同义词），而传统全文搜索则提供用户期望的精确匹配结果（例如找到“Python 3.9”的精确搜索）。因此，许多组织开始采用混合搜索方法，结合这两种方法的优势，以达到灵活的语义相关性和精确的关键词匹配之间的平衡。

实现混合搜索的一个常见方法是使用如开源Milvus这样的专用向量数据库来进行高效和可扩展的语义搜索，同时利用传统的搜索引擎如Elasticsearch或OpenSearch进行全文搜索。

尽管这种方法可以取得良好效果，但也会引入新的复杂性。管理两个独立的搜索系统意味着要处理各自的基础设施、配置和维护任务，从而增加了操作负担，并且带来了潜在集成问题的风险。

图：看看 Elasticsearch 和 Milvus 在跨模态搜索上的对比

统一的跨平台搜索解决方案将带来很多好处。

• 减少基础设施维护： 管理一个系统而不是两个系统，大大降低了运营复杂性，节省了时间和资源。这意味着在两套不同API之间切换和记忆负担更少。
• 统一的数据管理： 统一的表结构允许你存储两种类型的数据：密集型数据（如向量）和稀疏型数据（如关键词），同时共享元数据标签。使用两个单独的系统则需要为每一侧都存储两次元数据标签，以便进行元数据过滤。
• 简化查询： 单个请求可以执行语义和全文搜索任务，无需分别向两个系统发起两次API调用。
• 增强安全性和访问控制： 统一的方法使安全管理更加简单和强大，因为所有的访问控制都可以在一个向量数据库中集中管理，从而增强安全合规性和一致性。

在语义搜索中，机器学习模型将文本转换为点，称为稠密向量，并基于其含义在高维空间中表示。具有相似语义的文本可能比“苹果”和“汽车”更接近“苹果”和“水果”。这使我们能够快速找出语义相关的文本，通过使用近似最近邻(ANN)算法计算各点间的距离。

这种方法同样可以用于全文检索，通过将文档和查询转化为稀疏向量。在稀疏向量中，每一维度代表一个词，而值表示该词在文档中有多重要。

文档中未出现的术语其值为零。由于任何给定的文档通常只使用词汇表中的一小部分术语，大多数术语不会出现在文档中。这意味着生成的向量通常是稀疏的——大多数值为零。例如，在常用的MS-MARCO数据集（用于评估信息检索任务）中，大约有900万份文档和100万个不同的词汇。搜索引擎通常会将这个大型集合分割成较小的部分以方便管理和处理。

即使在词汇层级，词汇量超过数十万个词条，每个文档通常只包含不到100个词条，这意味着每个向量中超过99%的值为零。这种极端的稀疏性对我们如何高效存储和处理这些向量具有重要的影响。

这种稀疏模式可以被利用来优化搜索性能，同时保持准确性。原本为稠密向量设计的向量数据库可以高效地处理这些稀疏向量。例如，开源向量数据库Milvus最近发布了原生的全文搜索支持，使用的是稀疏向量实现的Sparse-BM25算法，该算法也被Elasticsearch和其他全文搜索系统采用。Sparse-BM25 开启了基于近似的方法进行全文搜索优化：

• 具有数据剪枝的高效检索算法： 通过应用基于启发式规则的剪枝方法，丢弃分段索引中最低稀疏向量值的文档，并在搜索查询中忽略低值稀疏向量，向量数据库可以显著减小索引大小并优化性能，同时保持较低的损失。

• 解锁进一步的性能优化： 用稀疏向量表示词频，代替倒排索引，可以实现额外的基于向量的优化。这包括：

• 使用图索引进行更高效的搜索。

• 产品量化（Product Quantization，PQ）/标量量化（Scalar Quantization，SQ） 进一步减少内存占用量。

除了这些优化之外，Sparse-BM25 还继承了来自高性能向量数据库 Milvus 的几个系统级优势。

• 高效的底层实现和内存管理： Milvus 的核心向量索引引擎是用 C++ 实现的，相比基于 Java 的系统如 Elasticsearch，提供了更高效的内存管理，因此可以减少内存占用。这不仅节省了吉字节的内存，还比基于 JVM 的方法减少了内存占用。
• 支持 MMap： 类似于 Elasticsearch 使用页面缓存（page-cache）来存储索引，无论是内存还是磁盘，Milvus 也支持 内存映射 (MMap) 来扩展内存，当索引超出可用内存范围时。

Elasticsearch 是为传统的倒排索引设计的，这使得整个架构难以优化以支持稠密向量搜索。这种影响非常明显：即使只有100万个向量数据，Elasticsearch 也需要200毫秒（在全托管的 Elastic Cloud 上测试）才能返回搜索结果，而 Milvus 则只需要6毫秒（在全托管的 Zilliz Cloud 上测试）——这相当于超过30倍的性能差距。每秒查询数（QPS）的吞吐量也相差3倍，Zilliz Cloud 上最高效的实例每秒可处理6000次查询，而 Elastic Cloud 则最多只能处理每秒1900次查询。此外，Zilliz Cloud 在加载向量数据和构建索引方面比 Elastic Cloud 快15倍。随着扩展，这种性能差距会进一步加大，因为 Elasticsearch 的 Java/JVM 实现难以与基于 C++/Go 的向量数据库的扩展性相匹敌。此外，Elasticsearch 缺乏关键的向量搜索功能，比如基于磁盘的索引（如 DiskAnn、MMap）、优化的元数据过滤和范围搜索功能。

图：VectorDBBench 基准测试结果图 (source)

向量数据库，以 Milvus 为例，即将超越 Elasticsearch，作为统一的混合搜索解决方案。通过将密集向量搜索与优化的稀疏向量技术相结合，向量数据库提供了更优越的性能、可扩展性和效率。这种统一的方法简化了基础设施，减少了内存占用，并增强了搜索能力，成为满足未来高级搜索需求的理想选择。因此，向量数据库无缝地结合了语义搜索和全文搜索，超越了传统的搜索引擎，例如 Elasticsearch。