📢 转载信息
原文链接：https://machinelearningmastery.com/the-complete-guide-to-vector-databases-for-machine-learning/
原文作者：Bala Priya C
在本文中，您将学习向量数据库如何为现代机器学习应用提供快速、可扩展的相似性搜索，以及何时有效利用它们。
我们将涵盖的主题包括：
- 为什么传统的数据库索引在高维嵌入中会失效。
- 核心ANN索引家族（HNSW、IVF、PQ）及其权衡。
- 生产环境的考量：召回率与延迟的调整、扩展、过滤和供应商选择。
让我们开始吧！
机器学习向量数据库完全指南
图片作者：Author
引言
向量数据库已成为大多数现代AI应用中不可或缺的一部分。如果您构建了任何涉及嵌入（embeddings）的东西——例如语义搜索、推荐引擎或RAG系统——您很可能已经遇到了传统数据库性能不足的瓶颈。
构建搜索应用听起来很简单，直到您尝试扩展规模。当您从原型转向包含数百万文档和数亿向量的真实数据时，就会遇到障碍。每次搜索查询都会将您的输入与数据库中的每一个向量进行比较。对于1024维或1536维的向量，每搜索一百万个向量就需要超过十亿次的浮点运算。您的搜索功能将变得无法使用。
向量数据库通过专门的算法来解决这个问题，避免了暴力计算距离。它们不是检查每个向量，而是使用分层图和空间划分等技术，只检查一小部分候选向量，同时仍然能找到最近的邻居。关键的见解是：您不需要完美的结果；从一百万个相似项中找到最相似的10个，与找到绝对前10个几乎没有区别，但近似版本可以快上千倍。
本文将解释为什么向量数据库在机器学习应用中有用，它们在底层是如何工作的，以及您何时真正需要一个。具体来说，它涵盖了以下主题：
- 为什么传统数据库索引在高维空间的相似性搜索中会失效
- 驱动向量数据库的关键算法：HNSW、IVF和乘积量化（Product Quantization）
- 距离度量及其选择的重要性
- 理解召回率-延迟权衡并在生产环境中进行调整
- 向量数据库如何通过分片、压缩和混合索引来处理规模问题
- 何时真正需要向量数据库，而不是更简单的替代方案
- 主要选项概述：Pinecone、Weaviate、Chroma、Qdrant、Milvus 等
为什么传统数据库不适合相似性搜索
传统数据库在处理精确匹配方面效率很高。您会进行诸如：查找ID为12345的用户；检索价格低于50美元的产品等操作。这些查询依赖于完美映射到B树索引的相等和比较运算符。
然而，机器学习处理的是嵌入，它们是表示语义意义的高维向量。您的搜索查询“附近最好的意大利餐厅”会变成一个1024维或1536维的数组（对于您常用的OpenAI和Cohere嵌入而言）。因此，查找相似向量需要在数百或数千个维度上计算距离。
一种天真的方法是计算查询向量与数据库中每个向量之间的距离。对于拥有超过1000个维度的一百万个嵌入，每次查询大约需要15亿次的浮点运算。传统索引在这种情况下帮不上忙，因为您不是在寻找精确匹配——而是在高维空间中寻找邻居。
这就是向量数据库发挥作用的地方。
向量数据库有何不同？
向量数据库是为相似性搜索而专门构建的。它们使用专门的数据结构来组织向量，从而支持近似最近邻（ANN）搜索，以巨大的速度提升来换取完美的准确性。
关键区别在于索引结构。向量数据库不使用针对范围查询优化的B树，而是使用专为高维几何设计的算法。这些算法利用嵌入空间的结构来避免暴力计算距离。
一个调优良好的向量数据库可以在几毫秒内搜索数百万个向量，使实时语义搜索变得可行。
向量数据库背后的核心概念
向量数据库依赖于算法方法。每种方法在搜索速度、准确性和内存使用之间都有不同的权衡。我将在这里介绍三种关键的向量索引方法。
分层可导航小世界（HNSW）
分层可导航小世界（HNSW）构建了一个多层图结构，其中每一层包含通过边连接的向量子集。顶层是稀疏的，只包含少数分布良好的向量。每一层添加更多的向量和连接，底层包含所有向量。
搜索从顶层开始，贪婪地导航到最近的邻居。一旦找不到更近的向量，它就会移动到下一层并重复此过程。这个过程一直持续到到达底层，从而返回最终的最近邻居。
分层可导航小世界（HNSW）| 图片作者：Author
这种分层结构意味着您只检查一小部分向量。搜索复杂度为 O(log N)，而不是 O(N)，使其能够高效地扩展到数百万个向量。
HNSW 提供了出色的召回率和速度，但需要将整个图保留在内存中。这对于海量数据集来说成本很高，但非常适合对延迟敏感的应用。
倒排文件索引（IVF）
倒排文件索引（IVF）使用 K-均值等聚类算法将向量空间划分为区域。在索引过程中，每个向量被分配到其最近的簇中心点。在搜索时，您首先识别最相关的簇，然后在这些簇内进行搜索。
IVF：将向量空间划分为簇 | 图片作者：Author
权衡是明确的：搜索更多簇可以获得更好的准确性，搜索更少簇可以获得更好的速度。典型的配置可能是搜索 1000 个簇中的 10 个，只检查 1% 的向量，同时保持超过 90% 的召回率。
IVF 比 HNSW 使用更少的内存，因为它在搜索时只加载相关的簇。这使其适用于内存容纳不下的数据集。缺点是在相同速度下召回率较低，尽管添加乘积量化可以改善这种权衡。
乘积量化（PQ）
乘积量化通过压缩向量来减少内存使用并加速距离计算。它将每个向量分割成子向量，然后独立地对每个子空间进行聚类。在索引过程中，向量由一系列簇ID表示，而不是原始浮点数。
乘积量化：压缩高维向量 | 图片作者：Author
一个1536维的float32向量通常需要约6KB。使用PQ和紧凑代码（例如，每个向量约8字节），这可以减少几个数量级——在这个例子中是约768倍的压缩。距离计算使用预先计算的查找表，使其速度大大加快。
成本是量化导致的精度损失。PQ与其他方法结合使用效果最佳：IVF用于初始过滤，PQ用于高效扫描候选。这种混合方法在生产系统中占主导地位。
向量数据库如何处理规模问题
现代向量数据库结合了多种技术，以高效地处理数十亿个向量。
分片（Sharding）将向量分布到不同的机器上。每个分片运行独立的ANN搜索，然后使用堆（heap）合并结果。这并行化了索引和搜索过程，实现了水平扩展。
过滤将元数据过滤器与向量搜索集成。数据库需要在不破坏索引效率的情况下应用过滤器。解决方案包括与向量结果相交的单独元数据索引，或跨过滤器值复制数据的分区索引。
混合搜索将向量相似性与传统的全文搜索相结合。BM25得分和向量相似度使用加权组合或倒数排名融合（reciprocal rank fusion）进行合并。这可以处理需要语义理解和关键字精度的查询。
动态更新对基于图的索引（如HNSW）构成挑战，因为它们针对读取性能进行了优化。大多数系统会队列写入操作，并定期重建索引，或者使用支持增量更新的特殊数据结构，但这会带来一定的性能开销。
关键的相似性度量
向量相似性依赖于距离度量，这些度量量化了两个向量在嵌入空间中的接近程度。
欧几里得距离测量直线距离。它很直观，但对向量幅度敏感。两个方向相同但长度不同的向量被认为是不相似的。
余弦相似度测量向量之间的角度，忽略幅度。这对于方向编码含义而尺度不编码含义的嵌入来说是理想的。大多数语义搜索使用余弦相似度，因为嵌入模型会生成归一化的向量。
点积是在不进行归一化的情况下得到的余弦相似度。当所有向量都是单位长度时，它等同于余弦相似度，但计算速度更快。许多系统在索引时进行一次归一化，然后在搜索时使用点积。
选择很重要，因为不同的度量会产生不同的最近邻拓扑结构。使用余弦相似度训练的嵌入模型，也应该使用余弦相似度进行搜索。
理解召回率和延迟的权衡
向量数据库通过近似搜索来牺牲完美的准确性以换取速度。理解这种权衡对于生产系统至关重要。
召回率衡量您的搜索返回了多少比例的真正最近邻。90%的召回率意味着找到了实际最接近的10个向量中的9个。召回率取决于索引参数：HNSW的ef_search、IVF的nprobe，或总体的探索深度。
延迟衡量查询花费的时间。它随着检查的向量数量而扩展。更高的召回率需要检查更多的候选向量，从而增加延迟。
最佳平衡点通常在 90%–95% 的召回率之间。从 95% 提高到 99% 可能会使您的查询时间增加两倍，而语义搜索质量几乎没有改善。大多数应用无法区分第10个和第12个最近邻。
请针对您的具体用例进行基准测试。使用穷举搜索建立一个地面实况数据集，然后衡量召回率如何影响您的应用指标。您通常会发现，85%的召回率产生的效果与 99% 相当，但成本却低得多。
您何时真正需要向量数据库
并非所有带有嵌入的应用都需要专门的向量数据库。
当您出现以下情况时，您实际上不需要向量数据库：
- 向量少于 10 万个。使用 NumPy 进行暴力搜索应该足够快。
- 向量持续频繁变化。索引的开销可能超过搜索带来的节省。
- 需要完美的准确性。使用像 FAISS 这样的优化库进行精确搜索。
当您出现以下情况时，请使用向量数据库：
- 拥有数百万个向量并需要低延迟搜索。
- 正在大规模构建语义搜索、RAG或推荐系统。
- 需要在保持搜索速度的同时按元数据过滤向量。
- 需要处理分片、复制和更新的基础设施。
许多团队从简单的解决方案开始，随着规模的扩大迁移到向量数据库。这通常是正确的做法。
生产向量数据库选项
在过去几年里，向量数据库的格局呈爆炸式增长。以下是您需要了解的主要参与者。
Pinecone 是一项完全托管的云服务。您定义索引配置；Pinecone 负责处理基础设施。它使用结合了 IVF 和基于图的搜索的专有算法。最适合希望避免操作开销的团队。定价随使用量扩展，在高用量时可能会变得昂贵。
Weaviate 是开源的，可以部署在任何地方。它将向量搜索与 GraphQL 模式相结合，使其对于需要非结构化语义搜索和结构化数据关系的应用程序非常强大。模块系统集成了 OpenAI 和 Cohere 等嵌入提供商。如果您需要灵活性和控制，这是一个不错的选择。
Chroma 专注于开发者体验，它是一个为AI应用设计的嵌入数据库。它强调简洁性——最少的配置，开箱即用的默认设置。可以嵌入在您的应用程序中运行或作为服务器运行。非常适合原型设计和中小型部署。其底层实现通过hnswlib使用 HNSW。
Qdrant 使用 Rust 构建，追求高性能。它通过与向量搜索并行的有效负载索引，高效地支持过滤搜索。其架构将存储与搜索分离，支持基于磁盘的大型数据集操作。是高性能要求的有力选择。
Milvus 负责大规模部署。它构建在计算和存储分离的解耦架构之上。它支持多种索引类型（IVF、HNSW、DiskANN）和广泛的配置。操作起来更复杂，但比大多数替代方案具有更强的扩展能力。
带 pgvector 的 Postgres 为 PostgreSQL 添加了向量搜索功能。对于已经使用 Postgres 的应用程序，这消除了对单独数据库的需求。性能足以应对中等规模，并且您拥有事务、连接和熟悉的工具。支持包括精确搜索和 IVF；其他索引类型的可用性可能取决于版本和配置。
Elasticsearch 和 OpenSearch 通过 HNSW 索引添加了向量搜索功能。如果您已经为日志记录或全文搜索运行它们，添加向量搜索非常简单。结合 BM25 和向量的混合搜索尤其强大。它们不是最快的纯向量数据库，但集成价值通常更高。
超越简单的相似性搜索
向量数据库正在从简单的相似性搜索演进。如果您关注搜索领域的动态，可能会看到开发社区测试和采用的几项改进和新方法。
混合向量索引结合了多种嵌入模型。同时存储句子嵌入和关键字嵌入，并跨两者进行搜索。这可以捕捉相似性的不同方面。
多模态搜索在同一空间中索引来自不同模态（文本、图像、音频）的向量。类似 CLIP 的模型可以实现用文本查询图像或反之。支持每项存储多种向量类型的向量数据库可以实现这一点。
学习型索引使用机器学习来优化特定数据集的索引结构。而不是使用通用算法，而是训练一个模型来预测向量的位置。这仍处于实验阶段，但在特定工作负载中显示出潜力。
流式更新正成为主要操作，而不是批处理重建。新的索引结构支持增量更新而不牺牲搜索性能——这对数据快速变化的应用至关重要。
结论
向量数据库解决了一个特定的问题：对高维嵌入进行快速的相似性搜索。它们不是传统数据库的替代品，而是语义相似性工作负载的补充。它们在实现上的算法基础保持一致。不同之处在于工程方面：系统如何处理规模、过滤、更新和操作。
从小处着手。当您确实需要向量数据库时，请了解召回率–延迟的权衡，并根据您的用例调整参数，而不是盲目追求完美的准确性。向量数据库领域正在迅速发展。三年前还是实验性研究的内容，现在已成为驱动大规模语义搜索、RAG应用和推荐系统的生产基础设施。了解它们的工作原理有助于您构建更出色的AI应用。
所以，祝您构建顺利！如果您需要具体的实践教程，请在评论中告诉我们您希望我们涵盖的内容。
🚀 想要体验更好更全面的AI调用？
欢迎使用青云聚合API，约为官网价格的十分之一，支持300+全球最新模型，以及全球各种生图生视频模型，无需翻墙高速稳定，文档丰富，小白也可以简单操作。
评论区