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