Elasticsearch 很棒，但向量数据库才是未来_

专用矢量数据库通过将 Sparse-BM25 算法和语义搜索统一在一个高效的操作中，从而胜过双系统设置。

几十年来，以 Elasticsearch 为代表的关键字匹配（也称为全文搜索）一直是企业搜索和推荐引擎等信息检索系统的默认选择。

随着 AI 驱动的搜索技术的进步，人们正在向语义搜索转变，使系统能够理解用户查询背后的含义和意图。嵌入模型和向量数据库已成为这一转变的核心。

语义搜索将数据表示为向量嵌入，从而超越了关键字匹配，从而提供了对搜索意图的更细致的理解，并改变了从检索增强生成（RAG）到多模态搜索的应用程序。

在实践中，有效的信息检索系统需要语义理解和精确的关键字匹配。例如，用户希望搜索结果显示与其搜索查询相关的概念，同时还遵循查询中使用的文本（如特殊术语和名称），并返回完全匹配的结果。

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

混合搜索挑战

实施混合搜索的一种常见方法是使用专门构建的矢量数据库（如开源 Milvus）进行高效且可扩展的语义搜索，并使用 Elasticsearch 或 OpenSearch 等传统搜索引擎进行全文搜索。

虽然这种方法可以产生良好的结果，但它也引入了一个新的复杂性层。管理两个不同的搜索系统意味着处理不同的基础设施、配置和维护任务，从而造成更沉重的运营负担，并增加潜在集成问题的可能性。

混合搜索的统一解决方案将提供许多好处：

减少基础设施维护：管理一个系统而不是两个系统可大大降低操作复杂性，从而节省时间和资源。这也意味着掌握两组不同的 API 所需的上下文切换和脑力开销更少。
整合数据管理：统一的表结构允许您将密集（基于矢量）和稀疏（基于关键字）数据与共享元数据标签一起存储。使用两个单独的系统需要为双方存储两次元数据标签，以便能够进行元数据筛选。
简化的查询：单个请求可以同时执行语义和全文搜索任务，无需对单独的系统进行两次 API 调用。
增强的安全性和访问控制：统一的方法可实现更直接和强大的安全管理，因为所有访问控制都可以在矢量数据库中集中管理，从而提高安全合规性和一致性。

统一向量方法如何简化混合搜索

在语义搜索中，机器学习根据文本的含义将文本作为点（称为密集向量）嵌入到高维空间中。在这个空间中，具有相似语义的文本彼此更接近。例如，在此空间中，“apple” 和 “fruit” 可能比 “apple” 和 “car” 更接近。这使我们能够通过使用近似最近邻（ANN）算法计算每个点之间的距离来快速找到语义相关的文本。

此方法还可以通过将文档和查询编码为稀疏向量来应用于全文搜索。在稀疏向量中，每个维度代表一个术语，该值表示每个术语在文档中的重要性。

文档中不存在的术语的值为零。由于任何给定的文档通常只使用词汇表中所有可能术语的一小部分，因此大多数术语不会出现在文档中。这意味着生成的向量是稀疏的 — 它们的大多数值为零。例如，在通常用于评估信息检索任务的 MS-MARCO 数据集中，虽然大约有 900 万个文档和 100 万个唯一术语，但搜索系统通常会将这些大型集合划分为较小的部分，以便于管理。

即使在句段级别，其词汇表中有数十万个术语，每个文档通常包含的术语也不到 100 个，这意味着每个向量的值的 99% 以上为零。这种极端的稀疏性对我们有效存储和处理这些载体的方式具有重要影响。

可以利用这种稀疏模式来优化搜索性能，同时保持准确性。最初为密集向量设计的向量数据库可以适应以有效地处理这些稀疏向量。例如，开源向量数据库 Milvus 刚刚发布了使用 Sparse-BM25 的原生全文搜索支持，Sparse-BM25 是 Elasticsearch 和其他全文搜索系统使用的 BM25 算法的稀疏向量实现。Sparse-BM25 通过以下方式为全文搜索解锁了基于近似的优化：

具有数据修剪的高效检索算法：通过应用基于启发式的修剪来丢弃段索引中具有最低稀疏向量值的文档，并忽略搜索查询中的低值稀疏向量，向量数据库可以显著减少索引大小并优化性能，同时将质量损失降至最低。
解锁进一步的性能优化：将术语频率表示为稀疏向量而不是反向索引可以启用其他基于向量的优化。这些包括：

图形索引用于比暴力扫描更高效的搜索。
乘积量化（PQ） / 标量量化（SQ）以进一步减少内存占用。

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

高效的低级实现和内存管理：Milvus 中的核心向量索引引擎是用 C++ 实现的，与基于 Java 的系统（如 Elasticsearch）相比，它提供了更高效的内存管理。与基于 JVM 的方法相比，仅此一项就通过节省 GB 来减少内存占用。
支持 MMap：与 Elasticsearch 使用页面缓存在内存和磁盘中存储索引类似，Milvus 支持内存映射（MMap）在索引超过可用内存时扩展内存容量。

为什么传统搜索堆栈在向量搜索方面存在不足

Elasticsearch 是为传统的倒排索引构建的，因此从根本上说很难针对密集向量搜索进行优化。影响是显而易见的：即使只有 100 万个向量，Elasticsearch 也需要 3770 毫秒（ms）才能返回搜索结果，而 Milvus 则需要 6 毫秒，相差 600 倍。这种性能差距在规模上会扩大，Elasticsearch 的 Java/JVM 实现难以与基于 C++/Go 的矢量数据库的可扩展性相匹配。此外，Elasticsearch 还缺乏关键的向量搜索功能，例如基于磁盘的索引（DiskAnn、MMap）、优化的元数据筛选和范围搜索。