使 Elasticsearch 和 Lucene 成为最佳矢量数据库：速度提高 8 倍，效率提高 32 倍
原创使 Elasticsearch 和 Lucene 成为最佳矢量数据库：速度提高 8 倍，效率提高 32 倍
原创
在Elastic，我们的使命是将Apache Lucene打造成最佳的向量数据库，并持续优化Elasticsearch，使其成为搜索和RAG检索平台的最佳选择。我们对Lucene的投入是关键，以确保Elasticsearch的每次发布都带来更快的性能和更大的规模。
在本文中，我们将总结最近对Elasticsearch和Apache Lucene的向量搜索性能进行的显著提升和优化，这些优化在Apache 9.9和Elasticsearch 8.12.x所提供的性能增益之上。
向量搜索的整合到Elasticsearch依赖于Apache Lucene，这是协调数据存储和检索的层。Lucene的架构将数据组织成段，这些段是定期进行合并的不可变单元。这种结构有助于有效管理倒排索引，这对于文本搜索至关重要。在进行向量搜索时，Lucene扩展了其处理多维点的能力，使用层次导航小世界（HNSW）算法来索引向量。
这种方法有利于扩展性，使数据集能够超过可用RAM大小，同时保持性能。此外，Lucene基于段的方法提供了无锁搜索操作，支持增量更改，并确保在各种数据结构中保持可见性一致性。然而，整合也带来了自身的工程挑战。合并段需要重新计算HNSW图，导致索引时间开销。搜索必须覆盖多个段，可能导致潜在的延迟开销。此外，为了达到最佳性能，需要随着数据的增长而扩展RAM，这可能会引发资源管理问题。
Lucene集成到Elasticsearch中带来了强大的向量搜索能力。这包括聚合，文档级别的安全性，地理空间查询，预过滤，以及与各种Elasticsearch特性的完全兼容性。想象一下，使用地理边界框运行向量搜索，这是Elasticsearch和Lucene启用的一个示例用例。
Lucene的架构为Elasticsearch内部的高效和多功能的向量搜索奠定了坚实的基础。让我们探讨一下我们已经实施的优化策略和增强功能，这些功能将向量搜索整合到Lucene中，为开发者提供了高性能和全面的特性集。
利用Lucene的架构实现多线程搜索
Lucene的分段架构使得可以实现多线程搜索功能。Elasticsearch的性能提升来自于同时有效地搜索多个段。通过使用所有可用的CPU核心的处理能力，可以显著降低单个搜索的延迟。虽然这可能不会直接提高总体吞吐量，但这种增强优先考虑最小化响应时间，确保用户尽快收到他们的搜索结果。
此外，这种优化对于层次导航小世界（HNSW）搜索特别有益，因为每个图都是独立的，可以并行搜索，最大限度地提高效率并进一步加快检索时间。
在无服务器环境中，拥有多个独立段的优势扩展到了架构层面。在这种新架构中，索引层负责创建新的段，每个段都包含自己的HSNW图。搜索层可以简单地复制这些段，无需承担索引操作的CPU成本。这种分离使得大部分计算资源可以专用于搜索，优化整体系统性能和响应速度。
加速多图向量搜索
尽管通过并行化实现了性能提升，但每个段的搜索仍然是独立的，对其他段搜索所取得的进展一无所知。因此，我们的关注点转向了如何优化多个段之间并发搜索的效率。
我们通过优化词法搜索的经验，启用了段搜索之间的信息交换，以实现向量搜索中的更好协调和效率。
在多图搜索场景中，挑战在于高效地导航各个图，同时确保全面的探索以避免局部最小值。虽然独立搜索多个图可以获得更高的召回率，但由于冗余的探索工作，运行时间增加。为了解决这个问题，我们设计了一种策略，智能地在搜索之间共享状态，使得基于全局和局部竞争阈值的有知识的遍历决策成为可能。
这种方法包括保持共享的全局和局部队列，这些队列是距离最近向量的距离，并根据每个图的局部搜索的竞争性动态调整搜索参数。通过同步信息交换并相应调整搜索策略，我们在保持与单图搜索相当的召回率的同时，实现了显著的搜索延迟改进。
这些优化的影响在我们的基准测试结果中显而易见。在并发搜索和索引场景中，我们注意到查询延迟减少了高达60%！即使对于在索引操作之外进行的查询，我们也观察到了显著的速度提升和所需向量操作数量的显著减少。这些增强功能，集成到Lucene 9.10和随后的Elasticsearch 8.13中，标志着在保持出色的召回率的同时，提高向量数据库搜索性能的重大进步。
利用Java的最新进展实现极致速度
在Java开发领域，自动向量化已经成为一种福音，通过HotSpot C2编译器将标量操作优化为SIMD（单指令多数据）指令。尽管这种自动优化带来了益处，但在需要对代码形状进行明确控制以获得更优性能的场景中，它有其局限性。这就是Project Panama Vector API的用武之地，这是JDK的最新添加功能，提供了一种在运行时可靠地编译为SIMD指令的计算API。
Lucene的向量搜索实现依赖于像点积、平方和余弦距离等基本操作，这些操作在浮点和二进制变体中都有应用。传统上，这些操作由标量实现支持，将性能增强留给JIT编译器。然而，最近的进步引入了一种范式转变，使开发者能够为最佳性能显式地表达这些操作。
考虑点积运算，这是一个基本的向量计算。这在Java中通常使用标量算术来实现，最近的创新利用Panama Vector API以适应SIMD指令的方式表达点积计算。这种修订后的实现在输入数组上迭代，批量乘积和累积元素，与底层硬件能力对齐。
通过利用Panama Vector API，Java代码现在可以与SIMD指令无缝地接口，释放出显著性能提升的潜力。当在兼容的CPU上执行时，编译的代码利用像AVX2或AVX 512这样的高级向量指令，从而加速计算。反汇编编译的代码会显示出优化的指令，这些指令是针对底层硬件架构定制的。
比较传统的Java实现和利用Panama Vector API的实现，微观基准测试显示出显著的性能改进。在各种向量操作和维度大小上，优化的实现显著优于其前身，展示了SIMD指令的变革力量。
这些优化的实际影响令人兴奋。向量搜索基准测试，如SO Vector，显示出索引吞吐量、合并时间和查询延迟的显著提高。Elasticsearch采纳了这些进步，将更快的实现作为默认选项，确保用户无缝地享受性能优势。
尽管Panama Vector API的状态仍在孵化，但其质量和潜在的好处是无可否认的。Lucene的务实方法允许选择性地采用非最终的JDK API，平衡性能改进的承诺与维护考虑。有了Lucene和Elasticsearch，用户可以毫不费力地利用这些进步，性能提升直接转化为实际工作负载。
将Panama Vector API集成到Java开发中，开启了性能优化的新时代，特别是在向量搜索场景中。通过采用硬件加速的SIMD指令，开发者可以解锁效率提升，这在微观基准测试和宏观级基准测试中都可见。随着Java的持续发展，利用其最新特性有望将性能提升到新的高度，丰富各种应用的用户体验。
通过标量量化最大化内存效率
内存消耗长期以来一直是有效的向量数据库操作的关注点，特别是对于搜索大数据集。Lucene引入了一种突破性的优化技术 - 标量量化 - 旨在显著降低内存需求，而不牺牲搜索性能。
考虑一种场景，查询数百万个高维的float32向量需要大量的内存，导致成本显著。通过采用字节量化，Lucene将内存使用量减少了大约75%，为向量搜索操作的内存密集型特性提供了一个可行的解决方案。
对于将浮点数量化为字节，Lucene实现了标量量化，这是一种损失压缩技术，将原始数据转换为压缩形式，牺牲一些信息以实现空间效率。Lucene的标量量化实现以最小的召回率影响实现了显著的空间节省，使其成为内存受限环境的理想解决方案。
Lucene的架构，包括节点、分片和段，这有助于搜索的文档的有效分布和管理。每个段存储原始向量、量化向量和元数据，确保优化的存储和检索机制。
Lucene的向量量化随着时间动态地进行适应，调整分位数在段合并操作中以保持最佳的召回率。通过智能地处理量化更新和在必要时进行重新量化，Lucene确保了在数据分布改变时的一致性性能。
实验结果证明了标量量化在减少内存占用和保持搜索性能方面的有效性。尽管与原始向量相比，Lucene的量化向量在召回率上有微小的差异，但其提供了显著的速度改进和召回率恢复，只需要很少的额外向量。
Lucene的标量量化提出了一种在向量搜索操作中进行内存优化的革命性方法。Lucene无需进行训练或优化步骤，就可以将量化无缝地整合到其索引过程中，自动适应随时间变化的数据分布。随着Lucene和Elasticsearch的持续发展，标量量化的广泛采用将彻底改变向量数据库应用的内存效率，为在大规模下提高搜索性能铺平了道路。
实现无缝压缩，对召回率影响最小
为了使压缩更好，我们的目标是将每个维度从7位降低到仅4位。我们的主要目标是在保持搜索结果准确的同时进一步压缩数据。通过进行一些改进，我们设法将数据压缩8倍，而不使搜索结果变得更糟。以下是我们的做法。
我们专注于在数据变小的同时保持搜索结果的准确性。通过确保我们在压缩过程中没有丢失重要的信息，我们仍然可以很好地找到东西，即使数据的详细程度较低。为了确保我们没有丢失任何重要的信息，我们添加了一个智能的错误纠正系统。
我们通过使用不同类型的数据和真实的搜索情况来检查我们的压缩改进。这帮助我们了解我们的搜索在不同的压缩级别下的效果如何，以及我们可能由于更多的压缩而在准确性上损失什么。
这些压缩功能被创建为与现有的向量搜索系统轻松地协同工作。它们帮助组织和用户节省空间，而无需在他们的设置中进行大的改变。有了这种简单的压缩，组织可以扩展他们的搜索系统，而不浪费资源。
简而言之，将标量量化的每个维度移至4位是使压缩更有效的一个重大步骤。它让用户将他们的原始向量压缩8倍。通过精心的优化、添加错误纠正、使用真实数据进行测试和提供可扩展的部署，组织可以节省大量的存储空间，而不会使搜索结果变差。这为高效和可扩展的搜索应用开启了新的机会。
为二进制量化铺平道路
将每个维度减少到4位的优化不仅带来了显著的压缩收益，而且为进一步提高压缩效率的进步铺平了道路。特别是，未来像二进制量化这样的进步进入Lucene，有可能革新向量存储和检索。
在不断挑战向量搜索中压缩的边界的努力中，我们正在积极地努力将二进制量化整合到Lucene中，使用和我们现有的优化策略相同的技术和原则。目标是实现向量维度的二进制量化，从而将向量表示的大小减少32倍，与原始浮点格式相比。
通过我们的迭代和实验，我们希望在最大化资源利用和可扩展性的同时，实现向量搜索的全部潜力。请继续关注我们将二进制量化整合到Lucene和Elasticsearch的进展，以及它将对向量数据库存储和检索产生的变革性影响。
Lucene和Elasticsearch中的多向量整合
许多实际应用依赖于文本嵌入模型和大型文本输入。大多数嵌入模型都有令牌限制，这需要将较长的文本分块成段落。因此，需要管理多个段落和嵌入，而不是单一的文档，这可能会使元数据的保留变得复杂。
Lucene的"join"功能，是Elasticsearch的嵌套字段类型的重要组成部分，提供了一个解决方案。此功能使得在顶级文档内部可以有多个嵌套的文档，允许跨嵌套文档进行搜索，然后与他们的父文档进行连接。那么，我们如何在Elasticsearch中提供向量在嵌套字段的支持呢？
关键在于Lucene如何在搜索子向量段落时连接回父文档。这里的并行概念是关于在kNN方法中预过滤与后过滤的讨论，因为连接的时间点显著影响结果的质量和数量。为了解决这个问题，最近对Lucene的增强使得能够在搜索HNSW图时预先针对父文档进行连接。
在实践中，预连接确保当检索查询向量的k个最近邻居时，算法返回的是k个最近的文档，而不是段落。这种方法在不使HNSW算法复杂化的情况下使结果多样化，只需要为每个存储的向量提供最小的额外内存开销。
通过利用某些限制，如父文档和子文档的不交集集合和文档ID的单调性，可以提高效率。这些限制允许使用位集进行优化，提供快速识别父文档ID的能力。
高效地通过大量的文档搜索需要在Lucene中投入到嵌套字段和连接中。这项工作有助于存储和搜索表示长文本中段落的密集向量，使Lucene中的文档搜索更有效。总的来说，这些进步代表了在Lucene内部的向量数据库检索领域的一个令人兴奋的进步。
总结（暂时）
客户们正在使用Elastic的向量数据库和向量搜索技术构建下一代的AI启用的搜索应用。例如，Roboflow被超过500,000名工程师用来创建数据集，训练模型，并将计算机视觉模型部署到生产中。Roboflow使用Elastic向量数据库来存储和搜索数十亿个向量嵌入。
我们致力于使Elasticsearch和Lucene成为每次发布的最佳向量数据库。我们的目标是让人们更容易找到东西。通过在本文中讨论的一些投资，我们已经取得了显著的进步，但我们还没有完成！
说AI生态系统正在快速发展是轻描淡写。在Elastic，我们希望为开发者提供最灵活和开放的工具，以跟上所有的创新——这些功能在最近的版本中都有提供，直到8.13。
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。