向量数据库概述
向量数据库的特征
- 数据库多样性：向量数据库在实现、性能、可扩展性和易用性方面存在差异，支持语义搜索应用。
- 融资与地理位置：多数向量数据库初创公司集中在加州湾区，但资金并不直接反映数据库能力。
- 编程语言：现代数据库多采用Golang或Rust编写，以实现高性能。Java和Python也在一些数据库中使用。
- 时间线：Vespa是最早引入向量相似性搜索的供应商之一，随后Weaviate、Milvus等加入竞争。到2021年，更多新供应商如Vald、Qdrant和Pinecone出现。
- 源代码可用性：大多数数据库至少在部分代码库上是开源的，但Pinecone是完全闭源的。
- 托管方法：数据库提供自托管、托管/云原生和嵌入式模式。Chroma和LanceDB支持嵌入式模式。
- 索引方法：多数供应商使用HNSW算法，一些数据库如Milvus、Weaviate和LanceDB实现了DiskANN算法以处理大型数据集。
各向量数据库优缺点
1. Pinecone
- 优点：易于上手，完全云原生，无需了解向量化或索引知识。
- 缺点：完全专有，内部运作和路线图不透明，依赖外部托管服务，缺乏数据库控制。
2. Weaviate
- 优点：出色的文档，专注于提供优秀的开发者体验，快速搜索，支持关键字和向量搜索，混合搜索功能强大。
- 缺点：使用Golang构建，可扩展性通过Kubernetes实现，可能需要大量基础设施资源，完全托管服务的长期成本影响未知。
3. Qdrant
- 优点：良好的文档，使用Rust构建，资源利用低，通过分区和Raft共识协议实现可扩展性，混合搜索功能正在开发中。
- 缺点：相对较新，查询用户界面有待改进，部分功能正在开发中。
4. Milvus/Zilliz
- 优点：成熟，提供多种向量索引选项，使用Golang构建，具有强大的可扩展性，唯一提供DiskANN实现的主要供应商。
- 缺点：系统复杂，资源密集，客户端API不如较新数据库易读或直观。
5. Chroma
- 优点：提供Python/JavaScript接口，快速启动向量存储，市场首个默认提供嵌入模式的向量数据库。
- 缺点：主要是对Clickhouse和hnswlib的封装，没有自己的存储层，长期来看可能需要替代解决方案。
6. LanceDB
- 优点：专为多模态数据设计，使用嵌入式、无服务器架构，使用Rust构建，具有高性能和低资源消耗。
- 缺点：功能正在积极开发中，工程团队规模较小，功能优先级排序可能是一个挑战。
7. Vespa
- 优点：提供企业级混合搜索能力，结合关键字搜索和自定义向量搜索。
- 缺点：开发人员体验不够流畅，由于使用Java编写，维护难度较高。
8. Vald
- 优点：高度分布式架构，处理多模态数据存储，使用NGT算法提供快速ANN搜索。
- 缺点：使用量和关注度较低，文档中对向量索引描述不明确。
9. Elasticsearch, Redis and pgvector：
- 优点：如果已经在使用这些数据库，利用它们的向量索引和搜索功能较简单。
- 缺点：不是专门为向量搜索设计的，性能可能受到影响，Redis VSS在数据超过内存时需要考虑替代方案。
这些数据库各有优势和局限性，选择时应根据具体需求和场景进行权衡。
数据库的嵌入
嵌入是将原始数据（如图像、音频或文本）转换为数字向量表示的过程。这些嵌入保留了原始数据的关键特征和上下文信息，使其能够在高维空间中进行有效的比较和搜索。
嵌入的生成通常依赖于机器学习模型，特别是在自然语言处理（NLP）领域，Transformer模型被广泛用于生成高质量的文本嵌入。文本嵌入可以通过多种方式生成，包括使用开源库如Sentence Transformers，或者通过API服务如OpenAI和Cohere。不同的嵌入模型提供不同维度和大小的向量，通常维度越低，向量空间越紧凑，但可能牺牲一些质量。
向量数据库存储这些嵌入向量，通常是以矩阵的形式，其中每一行代表一个数据点，每一列是一个维度。为了提高查询效率，这些矩阵会被分成多个分片。
在向量数据库中，用户可以通过将自然语言查询转换为与数据相同的嵌入空间中的向量，来执行语义搜索。这种搜索方法能够找到与查询最相似的数据点，即使这些数据点在原始形式下没有明显的相似性。
向量数据库的工作原理
向量数据库是用于存储和查询向量数据的高效系统，通常用于执行相似性搜索。这些数据库通过将文本、图像等非结构化数据转换为高维向量，来捕捉数据之间的语义关系。在文本数据中，常用的相似度指标包括点积和余弦距离。点积产生非归一化的值，而余弦距离则提供介于-1和1之间的归一化值。余弦距离是通过计算向量与原点连线和向量之间角度的余弦值来定义的。
当数据规模扩大时，K近邻(KNN)方法的效率会降低。为了解决这个问题，近似最近邻(ANN)搜索算法被用于快速检索最相似的向量，虽然这可能会牺牲一些精度。为了提高搜索效率，向量数据库使用各种索引技术，如倒排文件索引(IVF)、分层可导航小世界(HNSW)图和Vamana(在DiskANN实现中使用)。
向量数据库在语义搜索方面表现出色，但关键字搜索在特定情况下可能更相关。因此，混合搜索系统结合了关键字和向量搜索的优势，使用交叉编码器模型重新排序结果以提高相关性。结合向量数据库和强大的语言模型，如GPT-4，可以构建生成式问答应用程序。这些应用程序允许用户通过自然语言查询数据，并利用向量数据库的高效搜索能力来提供准确的信息。
向量数据库为现代应用程序提供了强大的搜索能力，但了解其局限性很重要。它们不一定优先考虑关键词短语的精确匹配，并且受到嵌入模型最大序列长度的限制。在考虑使用向量数据库时，应深入理解业务需求和技术细节，以确保正确选择和实施。
与用于生成句子嵌入的双编码器不同，交叉编码器不会生成嵌入向量，而是通过softmax层为一对句子分配一个介于0和1之间的分数，从而对其进行分类。这被称为重新排序。
数据库的架构
向量数据库的架构包括存储层、数据摄入、查询引擎和应用程序层。存储层负责存储向量数据，而查询引擎通过索引快速检索数据。应用程序层允许用户通过API网关与数据库交互。
向量数据库的索引
在向量数据库的领域中，索引的构建和选择是至关重要的，因为它们直接影响到搜索的效率和准确性。
索引的第一个层次：数据结构
索引可以通过它们所基于的数据结构来进行分类，主要包括哈希索引、基于树的索引、基于图的索引和倒排文件索引。
1. 哈希索引（Hash-based index）
- 原理：利用哈希函数将高维数据转换为低维哈希码，通过保持相似数据的哈希碰撞来提高检索速度。
- 优点：在处理大量数据时非常快速。
- 缺点：准确性较低。
2. 基于树的索引（Tree-based index）
- 原理：使用二叉搜索树等结构在低维空间中进行快速搜索，通过保持相似数据的同一子树来提高检索速度。
- 优点：对低维数据表现较好，可以快速发现近似最近邻。
- 缺点：在高维数据中准确性较低，无法充分捕捉数据的复杂性。
3. 基于图的索引（Graph-based index）
- 原理：基于数据点在向量空间中形成图的思想构建索引，图中的节点表示数据值，边表示数据点之间的相似性。
- 优点：能够在高维数据中找到近似最近邻，具有较高的内存效率，提高性能。
- 缺点：尚未提及。
4. 倒排文件索引（Inverted file index，IVF）
- 原理：将向量空间划分为多个细分单元，称为Voronoi图，以缩小搜索空间。
- 优点：有助于设计快速缩小相似性感兴趣区域的ANN算法。
- 缺点：在细分向量空间的量化步骤可能对于非常大量的数据而言速度较慢。
总的来说，每种索引方法都有其独特的优势和局限性，选择哪种索引方法取决于具体的数据和应用需求。在实际应用中，可以结合多种索引方法以提高检索性能。
索引的第二个层次：压缩
向量数据库使用索引来提高搜索效率，并支持近似最近邻（ANN）搜索。
1. 索引的压缩级别
- 平坦索引：未经修改的向量存储，直接与数据库中的每个向量进行比较。
- 量化索引：通过将向量转换为较少字节的块来压缩数据，减少内存消耗和计算成本。量化通常分为标量量化（SQ）和产品量化（PQ）。SQ通过将浮点数转换为整数来压缩数据，而PQ更复杂，考虑了每个向量维度上的值分布，通过将向量映射到子空间中点的质心来进行压缩和降维。
2. 流行的索引方法
- IVF-PQ是向量倒排文件索引与产品量化的组合，它在缩小搜索空间的同时，通过量化向量来减少内存需求，并大幅提升速度。
- HNSW是一种分层可导航小世界图，它能够在复杂的高维向量空间中以高召回率找到近似最近邻，是当前最流行的索引类型之一。
- Vamana是一种新的基于图的索引算法，专为磁盘性能设计和优化，能够在存储大于内存的向量数据时表现出与HNSW相当的性能和速度。
3. 向量数据库中可用的索引
- Milvus、Weaviate、Qdrant和LanceDB等数据库提供了HNSW索引作为默认选项。
- 这些数据库还提供了简单的调整参数，用于控制Product Quantization组件中的压缩/量化级别。
在选择索引方法时，需要根据数据集的大小、搜索准确性需求和内存限制等因素进行权衡。
Flat索引是以原始形式存储向量的索引，用于精确的k最近邻搜索。它是最准确的，但也是最慢的。
IVF-Flat索引使用倒排文件索引来快速缩小搜索空间，比暴力搜索要快得多，但会在召回率方面牺牲一些准确性。
IVF-PQ使用IVF与Product Quantization结合，对向量进行压缩，减少内存占用并加快搜索速度，同时在召回率方面比纯索引更好。
HNSW是目前最流行的索引类型，通常与Product Quantization结合使用，以提高搜索速度和内存效率。
Vamana是一个相对较新的索引，专为磁盘性能设计和优化-它承诺在存储大于内存的向量数据时能够表现出与HNSW相当的性能和速度。然而，目前还没有很多数据库实现Vamana索引，这是由于磁盘性能方面的挑战。
LanceDB是市场上唯一将所有向量索引都基于磁盘的向量数据库。这是因为他们在多个方面同时进行创新：
LanceDB正在构建一种新的高效列式数据格式Lance，旨在成为parquet的现代继任者，并针对向量搜索进行了优化。
正是由于这种高效的存储层，LanceDB能够在基于磁盘的索引方面充满信心，与其他供应商不同。
LanceDB采用了嵌入式（无服务器）的专用架构，从头开始构建。零拷贝数据访问是对基于磁盘的索引的巨大性能提升。
数据的自动版本控制，无需额外的基础设施。
与AWS S3和Azure Blob Storage等云存储提供商直接集成，非常容易与现有的数据流水线集成。
向量数据库的分析权衡
本地部署与云托管
在考虑数据库的部署选项时，组织需要权衡本地部署和云托管解决方案的优缺点。
部署选项
1. 云原生（托管）+ 客户端-服务器模式
- 这是一种常见的数据库架构，其中数据库作为服务在云中托管，用户通过客户端连接到服务器进行数据查询和操作。
- 优点包括可扩展性和无需本地基础设施维护。
- 缺点是可能涉及更高的成本，尤其是随着数据量的增加，以及对云供应商的依赖。
2. 本地部署（自托管）+ 嵌入式
- 在这种模式下，数据库嵌入到应用程序中，并在本地服务器上运行。
- 优点包括对数据的完全控制、可能降低的成本和更好的隐私保护。
- 缺点可能是扩展性较差，需要本地硬件和IT支持。
3. 云原生（托管）+ 嵌入式
- 这种混合模式结合了云的可扩展性和嵌入式的灵活性。
- 优点是结合了云的弹性和嵌入式数据库的便利性。
- 缺点可能与成本和云服务的依赖性有关。
成本考虑
1. 云托管解决方案
- 通常基于存储的数据量和查询次数收费。
- 适合数据量快速增长且不想投资本地基础设施的组织。
- 可能不适合已有大量内部数据基础设施的组织，因为这些组织可能不需要将数据迁移到云端。
2. 本地或嵌入式托管
- 可能需要初始投资用于硬件和IT支持。
- 适合对数据敏感且需要与现有系统集成的大型组织。
选择数据库部署模型时，组织应该基于数据敏感性、成本、可扩展性和现有基础设施的能力来做出决策。云原生和嵌入式数据库解决方案各有优势，了解组织的具体需求和限制是做出正确选择的关键。
专业供应商与传统供应商
在添加向量/语义搜索功能时，组织可以选择专业向量数据库供应商或传统数据库供应商。
传统供应商如Elasticsearch、Meilisearch、MongoDB等虽然提供了向量搜索功能，但这些功能可能受到限制，并且可能需要特殊的部署和许可条款。相比之下，专业向量数据库供应商如Qdrant、Weaviate、LanceDB等专门为向量搜索优化了其存储、索引和查询策略，并且从头开始构建系统，通常使用现代编程语言如Go或Rust，以实现大规模可扩展性和性能。
组织在自己的数据上运行基准测试，以比较传统解决方案和专为向量搜索构建的解决方案的性能，并考虑解决方案是否能够随着数据的增长而扩展。现有的解决方案添加向量搜索功能的性能可能不如专为向量数据库那样高效。
插入速度与查询速度
在选择向量数据库时，插入速度和查询速度之间的权衡。
虽然某些供应商如Milvus/Zilliz专注于支持大规模流式应用案例，其中实时插入和索引大量向量是关键，但对于大多数组织来说，查询速度更为重要。这是因为插入和索引通常是不频繁的操作，而数据可能会被频繁查询，通常通过用户界面以实时的方式进行大规模查询。
Qdrant是一个开源的、专为向量数据库的解决方案，使用Rust编写，专门针对这种使用案例进行了优化，能够在实时环境中实现语义搜索，并满足应用程序的延迟要求。组织在做出决策时考虑他们将多频繁地插入大量向量，以及他们是否满足查询时的应用程序延迟要求。
召回率与延迟方面
在向量数据库中，召回率和延迟之间的权衡。召回率是指查询返回的相关结果的百分比，而延迟是指返回结果所花费的时间。不同的数据库供应商在优化这两方面时会做出不同的权衡。
- 原始向量存储的索引方法提供最准确的K近邻搜索，但速度最慢。
- IVF-Flat索引通过倒排文件索引快速缩小搜索空间，提高了速度但牺牲了一些召回率。
- IVF-PQ结合了IVF和Product Quantization，减少了内存占用并加快了搜索速度，同时比纯索引有更好的召回率。
- HNSW是目前最流行的索引方法，可以与Product Quantization结合使用以提高召回率，同时在内存效率上优于HNSW-PQIVF-PQ。
- Vamana是一种新的索引方法，专为磁盘性能优化，承诺在性能上与HNSW相当，但目前尚未被广泛采用。
对于早期阶段的使用案例和概念验证，VF-PQ是有意义的，因为它不要求完美的相关性。然而，为了获得更好的质量和相关性，大多数供应商使用HNSW索引。最近，像Weaviate和Qdrant这样的供应商已经开始将Product Quantization与HNSW结合使用，以提高处理大型数据集时的内存效率。
- 使用案例，搜索召回率有多重要？通常，通过对自己的数据和查询进行基准测试研究，可以帮助回答这个问题。
- 使用案例，延迟有多重要？如果数据集非常大，那么使用产品量化索引（如IVF-PQ或HNSW-PQ）来减少内存占用可能是有意义的。
内存中与磁盘上的索引和向量存储
向量数据库中的内存中索引与磁盘上索引和向量存储的权衡。
- 内存中数据库：如Redis，速度非常快，但只能存储小于内存的数据量。
- 磁盘上数据库：可以存储大量大于内存的向量。为了保持接近内存数据库的搜索速度，一些数据库采用了内存映射文件技术，如Qdrant和Weaviate。这允许向量存储在磁盘上，但查询时只有相关的页面会被加载到内存中。
从索引的角度来看，HNSW（层次导航稀疏工作空间）算法因其对内存需求较高而闻名。随着数据集变大，结合产品量化（PQ）可以减少内存需求。Vamana是一种新的索引方法，是DiskANN算法的一部分，适用于磁盘上的大数据集，性能与HNSW相当。
LanceDB是一个特别的例子，它所有支持的索引都是基于磁盘的，使用Lance列式向量存储，专为快速磁盘向量检索优化。
- 如果数据集很大，如何减少内存消耗？可以减少向量维度、调整HNSW图连接的最大数量或添加产品量化。
- 数据库是否有磁盘上向量存储的选项，如果有，它会如何影响查询速度？这需要在具体的数据和使用案例上进行测试。
组织在选择数据库时，应根据自己的数据集大小、查询速度和内存需求来做出决策。
稀疏向量存储与密集向量存储
在向量数据库中使用稀疏向量存储和密集向量存储的优缺点。
- 稀疏向量：由算法如BM25和SPLADE生成，基于文档的相对词频，其中大部分值为零。稀疏向量的计算和存储成本较低，Elasticsearch等数据库提供了专有的稀疏模型。
- 密集向量：由Transformer模型生成，如BERT，包含非零浮点数，更好地压缩了语言的语义。密集向量提供了更好的语义搜索性能，但索引成本更高。
在考虑使用稀疏向量还是密集向量时，组织应考虑以下问题：
- 语义搜索的重要性：如果语义搜索对使用案例至关重要，那么密集向量是首选。
- 延迟和索引速度的重要性：如果延迟和索引速度是关键考虑因素，那么可能需要考虑使用稀疏向量，尽管它们的语义搜索性能不如密集向量。
组织应根据自己的具体需求和约束来选择最合适的向量存储方式。
全文搜索与向量搜索混合策略
在信息检索系统中使用全文搜索与向量搜索混合策略的重要性。向量搜索虽然强大，但不是万能的解决方案，特别是在企业级应用程序中。纯向量搜索可能会将语义上相似的结果排在精确匹配之上，而关键词搜索则可能更关注精确匹配。因此，结合这两种搜索方法可以提高结果的质量。
几种混合搜索策略：
- 简单回退方法：首先使用支持BM25算法的全文搜索引擎（如Meilisearch或Elasticsearch）进行关键词搜索，然后将向量搜索结果与关键词搜索结果结合。
- 倒数秩融合（RRF）：将稀疏向量和密集向量获得的倒数秩相加，提供一个融合的排序分数。
- 交叉编码器重新排序：使用神经双编码器融合稀疏/密集排序分数，通常产生最佳结果，但可能导致更高的延迟。
一些实现混合搜索的方法，包括Vespa搜索引擎的HNSW-IVF组合索引，以及Elasticsearch和Weaviate等数据库提供的RRF方法。
过滤策略
在向量数据库中进行搜索时，过滤策略的重要性，尤其是在涉及元数据属性（如尺寸、价格、品牌等）的搜索中。过滤策略可以分为预过滤搜索、后过滤搜索和自定义过滤搜索。
- 预过滤搜索：在执行向量搜索之前，根据元数据属性对数据进行过滤。这种方法可以减少搜索空间，但可能会错过一些语义上相关但不符合过滤条件的结果。
- 后过滤搜索：在执行向量搜索并返回结果后，根据元数据属性对结果进行过滤。这种方法可以确保结果在语义上与查询相关，但可能会因为过滤条件过于严格而导致结果数量减少。
- 自定义过滤搜索：结合了预过滤和后过滤的优点，在向量搜索之前应用一些预过滤，但不过度限制搜索结果。在返回结果后，可能会进一步根据其他属性进行后过滤。
没有一种“一刀切”的过滤结果的解决方案，一些缓解策略，如构建额外的IVF索引以使用关键词辅助搜索，或在类别之间创建额外的HNSW图连接。