向量搜索索引 vs 向量数据库#
本指南提供了关于向量搜索索引和功能完善的向量数据库之间区别的信息。有关选择和配置向量搜索索引的更多信息，请参阅我们的选择和配置索引指南
向量数据库索引与传统数据库索引的主要区别之一在于，向量搜索通常使用近似方法来权衡结果的准确性与速度。因此，虽然许多成熟的数据库提供了调整索引以实现更好性能的机制，但如果向量数据库索引除了性能调优外，没有针对合理的搜索质量水平进行调优，它们可能会返回完全无用的结果。这是因为向量数据库索引与机器学习模型的关系比与传统数据库索引的关系更密切。
向量数据库与向量搜索索引有什么区别？#
向量搜索本身是指在给定查询向量集周围的索引中找到最近向量的目标。在最低级别上，向量搜索索引只是机器学习模型，它们具有构建、搜索和召回性能，这些性能可以根据算法和各种超参数进行权衡。
向量搜索索引本身被认为是支持向量数据库的构建块，但其本身并非功能完善的向量数据库。向量数据库提供了更多生产级别的功能，它们通常将向量搜索算法与其他流行的数据库设计技术结合使用，以增加持久性、容错性、垂直扩展性、分区容错性和水平扩展性等重要能力。
在向量数据库领域，有一些专门构建的数据库主要关注向量搜索，但也可能提供一些通用数据库的少量能力，例如能够跨向量和元数据执行混合搜索。许多通用数据库，例如关系型数据库和 NoSQL / 文档数据库，也开始添加一流的向量类型支持。
那么这一切对您意味着什么呢？有时一个简单的独立向量搜索索引就足够了。通常它们可以被训练并序列化到文件中以供以后使用，并且通常提供在搜索过程中过滤出特定向量的能力。有时它们甚至提供一种机制来扩展以利用多个 GPU 等，但它们通常就止步于此了——并建议您使用自己的分布式系统（如 Spark 或 Dask）或功能完善的向量数据库来实现横向扩展。
FAISS 和 cuVS 是独立向量搜索库的示例，它们更接近于机器学习库，而不是功能完善的数据库。Milvus 是一个专用向量数据库的示例，而 Elastic、MongoDB 和 OpenSearch 是添加了向量搜索能力的通用数据库的示例。
向量数据库如何使用向量搜索？#
在向量数据库的上下文中，向量搜索索引有两种主要的使用方式，了解您正在使用的是哪一种非常重要，因为它会影响参数相对于数据的行为。
许多向量搜索算法通过将向量空间分成更小的部分来提高可伸缩性，同时减少距离计算次数，这通常是通过聚类、哈希、树和其他技术实现的。另一种流行的技术是减小空间的宽度或维度，以降低计算每个距离的成本。相比之下，数据库通常会对数据进行分区，但这可能只是为了改善诸如 I/O 性能、分区容错性或扩展性等方面，而不考虑最终将用于向量搜索的底层数据分布。
这让我们看到了向量数据库中遇到的两种核心架构设计
本地分区向量搜索索引#
大多数数据库遵循这种设计，向量通常首先写入预写日志（write-ahead log）以保证持久性。在写入一定数量的向量后，预写日志变为不可变，并可能与其他预写日志合并，最终转换为新的向量搜索索引。
搜索通常是在每个本地分区索引上进行的，然后将结果合并。设置超参数时，只需要考虑本地向量搜索索引，尽管所有本地分区都会使用相同的超参数。因此，例如，如果您摄入了 1 亿个向量，但每个分区只包含大约 1000 万个向量，那么索引的大小只需要考虑其本地的 1000 万个向量。索引中向量数量等细节非常重要，例如，在基于 IVF（倒排文件索引）的方法中设置聚类数量时，我将在下面介绍。
全局分区向量搜索索引#
一些专用向量数据库遵循此设计，例如 Yahoo 的 Vespa 和 Google 的 Spanner。一旦有足够的向量，就会预先训练一个全局索引来对整个数据库的向量进行分区（通常这些数据库规模足够大，初始引导了大量向量，因此避免了冷启动问题）。摄入的向量首先通过全局索引（例如聚类，但也使用了基于树和图的方法）来确定它们属于哪个分区，然后向量被直接写入该分区。单个分区可以包含图、树或简单的 IVF 列表。这些类型的索引已经能够扩展到数百亿甚至数万亿个向量，并且由于这些分区本身通常隐含地基于邻域，而不是像本地分区架构那样基于均匀随机分布的向量，因此可以将这些分区组合在一起或有意分开，以支持局部搜索或负载均衡，具体取决于系统的需求。
设置全局分区索引的超参数时的挑战在于，它们需要考虑整个向量集，因此全局索引的超参数通常要考虑数据库中的所有向量，而不是任何本地分区。
当然，上面概述的两种方法也可以结合使用（例如，训练一个全局的“粗粒度”索引，然后在每个全局索引中创建本地化的向量搜索索引），但据我所知，还没有这样的架构实现了这种模式。
当前向量数据库中使用 GPU 的一个挑战是，生成的向量索引需要适应可用 GPU 的内存以实现快速搜索。也就是说，目前尚不存在一种有效机制来卸载或交换 GPU 索引，以便可以将它们从磁盘或主机内存缓存等。我们正在研究实现这一目标的机制，并利用 GPUDirect Storage 和 GPUDirect RDMA 等技术进一步提高 I/O 性能。
调优和超参数优化#
不幸的是，对于大型数据集，对整个数据集进行超参数优化并非总是可行，这正是本地分区向量搜索索引的优势所在，因为您可以将较大索引的每个较小段视为数据集中总向量的均匀随机样本。这意味着可以在较小的子集上执行超参数优化，并找到应该很好地推广到整个数据集的合理可接受的参数。通常，这种超参数优化需要在子集上使用暴力搜索等精确方法计算地面真相（ground truth），然后使用它来评估对随机抽样向量的多次搜索。
完全的超参数优化也并非总是必要——例如，一旦您在子集上构建了一个地面真相数据集，很多时候您可以从使用默认构建参数构建索引开始，然后尝试不同的搜索参数，直到获得所需的质量和搜索性能。对于可能达到数 TB 的大型索引，您也可以取这个子样本，比如 1000 万个向量，训练一个索引，然后从那里调优搜索参数。尽管可能存在很小的误差，但选择的构建/搜索参数对于构建本地分区索引的数据库应该能够很好地推广。
有关如何根据您的需求高效、自动地调优向量搜索索引的更多信息和示例，请参阅我们的调优指南。