向量数据库深度对比：Weaviate、Milvus 与 Qdrant

在人工智能和机器学习领域，尤其是在构建如 RAG（检索增强生成）系统和语义搜索等应用时，高效地处理和检索海量非结构化数据变得至关重要。向量数据库应运而生，成为解决这一挑战的核心技术。它们不仅是存储高维向量数据的专门数据库，更是驱动下一代AI应用的关键基础设施。

本文将深入探讨向量数据库的概念、工作原理、应用场景，并对比分析当前主流的开源向量数据库 Weaviate、Milvus 和 Qdrant。旨在为读者提供一个全面而深入的向量数据库指南，帮助您理解其价值，并在实际项目中做出明智的技术选型。

什么是向量数据库？从传统数据库到向量检索

为了理解向量数据库的独特之处，我们首先需要了解什么是向量，以及为何传统数据库在处理向量数据时会显得力不从心。

向量：数据的数学表示

简单来说，向量是用于表示数据特征或属性的数学工具，可以看作是多维空间中的一个点。在向量数据库的语境下，我们通常讨论的是高维向量，这意味着这些向量拥有大量的维度，从数十维到数千维不等，具体维度取决于数据的复杂性和所需表示的粒度。

向量嵌入：非结构化数据的结构化表示

那么，这些高维向量是如何产生的呢？答案是通过嵌入函数，将原始的非结构化数据（如文本、图像、音频、视频等）转换为向量。这个转换过程，称为向量嵌入 (Vector Embedding)，利用机器学习模型、词嵌入技术或特征提取算法等方法，将数据的语义信息或特征压缩到一个紧凑的向量空间中。

例如，对于文本数据，我们可以使用如 Word2Vec、GloVe、FastText 或 Transformer 模型（如 BERT、Sentence-BERT）等技术，将每个词、句子甚至整篇文章转换为一个向量。在向量空间中，语义上相近的文本，它们的向量距离也会更近。

向量数据库的核心优势：相似性搜索

传统数据库，如关系型数据库（如 PostgreSQL、MySQL）和 NoSQL 数据库（如 MongoDB、Redis），主要设计用于存储和查询结构化或半结构化数据，它们擅长基于精确匹配或预定义标准进行数据检索。然而，当涉及到基于语义相似性或上下文含义查找数据时，传统数据库就显得效率低下。

向量数据库的出现，正是为了弥补这一不足。它们的核心优势在于能够高效地执行基于向量距离或相似性的相似性搜索和检索。这意味着，我们可以根据数据的语义或特征相似度来查找数据，而无需进行精确的关键词匹配。

向量数据库与传统数据库的关键差异

为了更清晰地理解向量数据库的独特性，我们将其与传统数据库的关键差异总结如下：

向量数据库的价值：AI 应用的基石

向量数据库在人工智能和机器学习领域扮演着越来越重要的角色，尤其是在以下几个方面：

• 下一代搜索引擎： 实现语义搜索，理解用户查询的意图，返回更相关、更符合语境的搜索结果，而不仅仅是关键词匹配。
• 智能推荐系统： 根据用户历史行为和物品特征，进行个性化推荐，提高推荐的准确性和用户体验。
• 大型语言模型 (LLM) 应用： 为 LLM 提供长期记忆和高效的上下文检索能力，支持构建更强大的聊天机器人、问答系统和内容生成应用。
• 多模态数据检索： 实现跨模态的相似性搜索，例如，通过文本描述搜索相关图像或视频。

总而言之，向量数据库是AI时代处理和检索非结构化数据的关键基础设施，它们赋予了机器理解语义、进行相似性推理的能力，从而驱动了众多创新性的AI应用。

向量数据库与 RAG：构建强大的检索增强生成系统

RAG（Retrieval-Augmented Generation，检索增强生成）系统是当前大语言模型应用领域的热门方向。RAG 的核心思想是在生成文本之前，先从外部知识库中检索相关信息，然后将检索到的信息作为上下文，引导语言模型生成更准确、更可靠的答案。

向量数据库在 RAG 系统中的核心作用

在 RAG 系统中，向量数据库扮演着知识库的角色，负责存储和高效检索海量知识文档的向量表示。RAG 系统的工作流程大致如下：

1. 知识库构建：
   • 将知识文档（例如，文本、网页、PDF等）进行向量嵌入，转换为向量表示。
   • 将这些向量及其对应的文档元数据存储到向量数据库中。
2. 查询检索：
   • 接收用户查询，并将查询也进行向量嵌入，得到查询向量。
   • 使用查询向量在向量数据库中进行相似性搜索，检索出与查询向量最相似的文档向量。
   • 获取检索到的文档向量对应的原始文档或文档片段。
3. 文本生成：
   • 将检索到的文档片段与用户查询一起作为上下文，输入到大型语言模型 (LLM)。
   • LLM 基于上下文信息生成最终的答案或文本。

利用Milvus实现的图片语义搜索

为何向量数据库是 RAG 系统的理想选择？

• 高效的语义检索能力： 向量数据库能够根据语义相似性检索文档，这与 RAG 系统需要从知识库中找到与用户查询相关的上下文信息的需求完美契合。
• 处理海量知识文档： RAG 系统通常需要处理大量的知识文档，向量数据库能够高效地存储和检索海量向量数据，满足 RAG 系统的扩展性需求。
• 快速响应用户查询： 向量数据库的相似性搜索速度非常快，能够保证 RAG 系统对用户查询的快速响应。

向量数据库选型：RAG 系统的关键决策

选择合适的向量数据库对于 RAG 系统的性能和效果至关重要。不同的向量数据库在性能、功能、易用性等方面存在差异。在后续章节中，我们将深入探讨向量数据库的选型要素，并对比分析 Weaviate、Milvus 和 Qdrant 这三款优秀的开源向量数据库，帮助您为 RAG 系统选择最合适的基石。

向量数据库选型：不止于性能，更要关注这些关键因素

在深入对比具体的产品之前，我们先来明确向量数据库选型的核心关注点。这些因素将直接影响您构建的 RAG 系统或 AI 应用的性能、可扩展性、稳定性和成本。

1. 开源与商业化：自主可控 vs. 易用性

• 开源向量数据库 (如 Milvus, Weaviate, Qdrant, Vespa)：
  • 优势： 更高的自主性和灵活性，可以自由定制和二次开发，更好地掌控数据安全和系统架构。拥有活跃的开源社区支持，迭代速度快，问题解决迅速。通常成本较低，甚至免费使用。
  • 挑战： 部署、运维和问题排查需要一定的技术能力。商业支持可能相对较弱，需要依赖社区或自行解决问题。
  • 适用场景： 对自主可控性要求高，有技术团队支持，希望降低成本，并能积极参与社区共建的项目。
• 商业化向量数据库 (如 Pinecone, 等云服务商提供的托管向量数据库)：
  • 优势： 通常提供完善的托管服务和技术支持，简化部署和运维复杂性，易于上手和使用。性能和稳定性经过商业验证，服务质量有保障。
  • 挑战： 成本较高，长期使用可能产生显著费用。可能存在厂商锁定风险，定制化和二次开发受限。
  • 适用场景： 追求易用性和稳定性，希望快速上手，减少运维负担，预算充足，对厂商锁定风险不敏感的项目。

2. CRUD 支持：动态数据 vs. 静态数据

• CRUD (创建、读取、更新、删除) 支持：
  • 重要性： 对于 RAG 系统和许多动态数据应用至关重要。如果数据需要频繁更新、删除或修改，则必须选择支持完整 CRUD 操作的向量数据库。
  • 影响： 支持 CRUD 操作的数据库，可以方便地管理动态变化的数据，保持知识库的实时性和准确性。
• 静态数据场景：
  • 需求： 如果数据是静态的，例如预先构建好的知识库，数据更新频率很低，那么只读的向量库或不支持完整 CRUD 的数据库或许也能满足需求。
  • 选择： 在这种情况下，可以考虑一些轻量级的向量库，或者一些侧重于高性能检索而弱化数据更新功能的向量数据库。

3. 分布式架构与可扩展性：应对海量数据与高并发

• 分布式架构：
  • 必要性： RAG 系统和许多 AI 应用通常需要处理海量数据和高并发请求。分布式架构是应对这些挑战的关键。
  • 优势： 分布式向量数据库可以将数据分散存储在多台服务器上，并支持并行查询，从而提高数据处理能力和查询性能。
• 可扩展性：
  • 水平扩展： 优秀的向量数据库应该能够轻松进行水平扩展，通过增加节点来应对数据量和请求量的增长。
  • 弹性伸缩： 最好能支持弹性伸缩，根据实际负载动态调整资源，优化成本和性能。

4. 数据副本与高可用性：保障数据安全与服务稳定

• 数据副本：
  • 作用： 数据副本机制是保障数据安全和系统高可用性的重要手段。
  • 实现： 通过在多台服务器上存储相同的数据副本，即使部分节点发生故障，系统也能继续正常运行，数据不会丢失。
• 高可用性：
  • 重要性： 对于对服务稳定性要求较高的 RAG 系统和在线应用，高可用性至关重要。
  • 保障： 数据副本、故障自动转移、监控告警等机制共同保障系统的持续稳定运行。

5. 性能表现：检索速度与精度

• 检索速度 (Latency)：
  • 指标： 查询延迟，即从发起查询到获得结果的时间。
  • 影响因素： 索引算法、硬件资源、数据规模、查询复杂度等。
  • 需求： 对于实时性要求高的应用，需要选择检索速度快的向量数据库。
• 检索精度 (Recall, Precision)：
  • 指标： 召回率 (Recall) 和 精确率 (Precision)，衡量相似性搜索结果的准确性。
  • 权衡： 通常检索速度和精度之间存在权衡，需要根据应用场景选择合适的平衡点。例如，对于 RAG 系统，可能更看重召回率，确保尽可能多地检索到相关文档。

6. 持续维护与社区支持：长期稳定运行的保障

• 持续维护：
  • 重要性： 向量数据库技术发展迅速，持续的维护和更新至关重要。
  • 关注点： 数据库是否有活跃的开发团队持续维护和更新，及时修复 Bug，并跟进最新的技术发展趋势。
• 社区支持：
  • 价值： 活跃的社区能够提供丰富的文档、教程、示例代码和问题解答，降低学习和使用门槛。
  • 评估： 可以通过查看 GitHub 仓库的活跃度、社区论坛的讨论热度、用户数量等指标来评估社区支持力度。

7. 成本考量：开源 vs. 商业化，自建 vs. 托管

• 开源 vs. 商业化成本：
  • 开源： 数据库软件本身免费，但需要考虑硬件成本、运维成本、人力成本等。
  • 商业化： 需要支付软件许可费或云服务费用，但可能降低运维成本，并获得更好的技术支持。
• 自建 vs. 托管成本：
  • 自建： 需要自行负责硬件采购、部署、运维、监控等，初期投入和长期运维成本较高。
  • 托管： 使用云服务商提供的托管向量数据库服务，无需关心底层基础设施，按需付费，成本结构更灵活，但长期使用成本可能较高。

综合考量：

在进行向量数据库选型时，需要综合考虑以上七个关键因素，并根据具体的应用场景、需求和预算做出权衡和选择。没有绝对最优的数据库，只有最适合特定场景的数据库。

不同类型向量数据库方案对比：技术选型全景图

面对市场上众多的向量数据库方案，了解它们的类型和特点，有助于您缩小选择范围，更快找到适合您的方案。我们将向量数据库方案大致分为以下五类：

1. 向量库 (FAISS、HNSWLib、ANNOY)：轻量级索引，静态数据加速利器

向量库，例如 FAISS (Facebook AI Similarity Search)、HNSWLib (Hierarchical Navigable Small World Graphs Library) 和 ANNOY (Approximate Nearest Neighbors Oh Yeah)，本质上是用于构建向量索引和执行相似性搜索的软件库。它们通常以库的形式嵌入到您的应用程序中运行，而不是作为独立的数据库服务。

优势：

• 高性能： 专注于向量索引和相似性搜索算法的优化，检索速度极快。
• 轻量级： 资源占用少，部署简单，易于集成到现有应用程序中。
• 成熟稳定： 经过长期发展和广泛应用，技术成熟可靠，社区支持良好。

局限性：

• 静态数据为主： 主要用于存储静态数据，索引构建后数据不易更新。除了 HNSWLib，多数向量库不支持 CRUD 操作，数据更新和删除较为困难。
• 功能有限： 通常只提供基本的向量索引和相似性搜索功能，缺乏分布式、数据副本、权限管理、监控运维等高级数据库特性。
• 运维成本高： 需要自行构建部署生态系统、处理数据复制和容错，缺乏完善的运维工具和管理界面。

适用场景：

• 静态数据集的相似性搜索： 例如，离线构建好的知识库、商品库、人脸库等，数据更新频率低的场景。
• 对性能要求极高，但数据更新频率低的场景： 例如，搜索引擎的离线索引构建，大规模推荐系统的离线特征索引。
• 作为其他数据库的向量索引加速组件： 例如，结合 Redis、MySQL 等数据库使用，利用向量库加速相似性搜索。

代表产品：

• FAISS (Facebook AI Similarity Search)： 由 Facebook AI Research 开发，广泛应用于学术界和工业界。提供了多种高效的索引算法，如 IVF、PQ、HNSW 等，尤其擅长处理大规模数据集。
• HNSWLib (Hierarchical Navigable Small World Graphs Library)： 基于 HNSW (Hierarchical Navigable Small World) 算法实现，以其高性能和高效率著称。HNSWLib 相对其他向量库，更灵活，支持 CRUD 操作和并发读写。
• ANNOY (Approximate Nearest Neighbors Oh Yeah)： 由 Spotify 开发，专注于快速的近似最近邻搜索。以其简洁高效的设计而闻名，适用于对延迟敏感的应用场景。

2. 全文搜索数据库 (ElasticSearch、OpenSearch)：向量检索的补充，非核心能力

全文搜索数据库，如 ElasticSearch 和 OpenSearch，主要设计用于全文检索和关键词搜索，它们基于倒排索引技术，在文本检索和高级分析方面功能强大。近年来，它们也开始增加向量检索功能，但向量检索并非其核心优势。

优势：

• 强大的全文检索能力： 支持复杂的文本查询、分词、同义词、拼写纠错、相关性排序 (如 BM25) 等功能。
• 丰富的分析功能： 提供聚合、统计、报表、数据可视化等功能，可用于数据分析和业务洞察。
• 成熟的生态系统： 拥有庞大的用户群体和完善的生态系统，易于集成和使用，周边工具和插件丰富。

局限性：

• 向量检索性能较弱： 与专用向量数据库相比，向量相似性搜索性能较低，尤其是在高维数据和大规模数据集上，查询延迟较高，精度可能不足。
• 资源消耗大： 为了支持全文检索和分析等功能，资源消耗较大，部署和运维成本较高。
• 不擅长语义搜索： 主要依赖关键词匹配和倒排索引，语义理解能力有限，难以满足复杂的语义搜索需求。

适用场景：

• 关键词搜索为主，向量检索为辅的应用： 例如，电商网站的商品搜索、新闻网站的文章搜索等，主要使用关键词搜索，向量检索作为辅助功能，提升搜索的语义相关性。
• 需要结合全文检索和向量检索的混合搜索场景： 例如，智能客服系统，同时支持关键词和语义搜索，满足用户多样化的查询需求。
• 日志分析、监控告警等需要强大分析功能的场景： 利用全文搜索数据库强大的分析能力，进行日志分析、监控告警、安全审计等。

代表产品：

• ElasticSearch： 基于 Lucene 构建，是最流行的开源全文搜索引擎之一，广泛应用于搜索、日志分析、数据可视化等领域。
• OpenSearch： 由 AWS 基于 ElasticSearch 和 Kibana 分支而来，保持了与 ElasticSearch 的兼容性，并增加了新的功能和改进，是 ElasticSearch 的一个重要分支。

结论： 虽然 ElasticSearch 和 OpenSearch 提供了向量检索功能，但其性能和功能与专用向量数据库相比仍有差距。对于以向量检索为主的 RAG 系统或 AI 应用，专用向量数据库是更优选择。全文搜索数据库更适合作为向量检索的补充，而非替代方案。

3. 支持向量的 SQL 数据库 (pgvector、Supabase、StarRocks)：传统数据库的向量扩展，轻量级应用之选

SQL 数据库，如 PostgreSQL，通过扩展 (例如 pgvector) 来支持向量数据类型和相似性搜索功能。这使得用户可以在现有的关系型数据库中存储和查询向量数据，无需引入新的数据库系统。

优势：

• 易于集成： 可以与现有的 SQL 数据库无缝集成，降低技术栈的复杂性，减少学习和迁移成本。
• 成熟稳定： SQL 数据库技术成熟稳定，数据管理和事务处理能力强大，数据一致性和可靠性有保障。
• 学习成本低： 对于熟悉 SQL 的开发人员来说，学习成本较低，可以快速上手使用向量检索功能。

局限性：

• 向量检索性能有限： 关系型数据库的架构并非为向量检索而设计，性能不如专用向量数据库，尤其是在处理大规模高维向量数据时，查询延迟较高。
• 可扩展性受限： 关系型数据库的扩展性相对较弱，难以应对海量向量数据和高并发查询，水平扩展能力有限。
• 向量维度限制： 例如，pgvector 支持的向量维度上限为 2000 维，低于专用向量数据库，可能无法满足高维向量数据的需求。

适用场景：

• 向量数据量较小（十万级别以下）的应用： 例如，小型推荐系统、简单图像搜索、个人知识库等，向量数据量不大，对性能要求不高。
• 向量数据作为辅助功能的应用： 例如，在电商网站的商品数据库中增加商品向量字段，用于商品推荐或相似商品查找，向量检索只是数据库的一个辅助功能。
• 已有成熟 SQL 数据库的应用，希望快速增加向量检索能力： 在已使用 PostgreSQL 等 SQL 数据库的项目中，希望快速引入向量检索功能，可以考虑使用 pgvector 等扩展。

代表产品：

• pgvector： PostgreSQL 的扩展，由 Crunchy Data 开发，提供了向量数据类型 (vector) 和索引 (IVF, HNSW)，以及向量相似性搜索功能。
• Supabase： 基于 PostgreSQL 的开源 PaaS 平台，集成了 pgvector，方便用户快速构建支持向量检索的应用。
• StarRocks： 一款面向 OLAP 的 MPP 数据库，也增加了向量检索功能，但向量检索并非其核心定位，主要用于 OLAP 分析场景。

结论： 支持向量的 SQL 数据库，如 pgvector，更适合于向量数据量较小、对性能要求不高、且向量数据仅作为应用程序补充功能的轻量级应用场景。如果向量数据是应用的核心，或者对可扩展性有较高要求，专用向量数据库会是更优选择。

4. 支持向量的 NoSQL 数据库 (Redis、MongoDB)：新兴尝试，潜力与挑战并存

NoSQL 数据库，例如 Redis 和 MongoDB，也开始尝试增加向量支持功能，例如 Redis 向量相似性搜索 (VSS) 和 MongoDB Atlas Vector Search。这使得 NoSQL 数据库也具备了处理向量数据的能力。

优势：

• NoSQL 数据库的固有优势： 例如，Redis 的高性能缓存、低延迟、高吞吐量；MongoDB 的灵活文档模型、易扩展性、丰富的文档操作功能。
• 技术新颖： 代表了数据库技术的发展趋势，将向量检索能力融入到成熟的 NoSQL 数据库中，具有一定的创新性和发展潜力。

局限性：

• 功能尚不成熟： 向量支持功能还处于早期阶段，功能和性能有待完善和验证，生态系统相对不成熟。
• 生态系统不完善： 相关工具、库和生态系统相对匮乏，使用和维护成本可能较高，社区支持相对较弱。
• 性能有待考量： 虽然 Redis VSS 声称性能优异，但实际效果还需要在更多场景下进行验证，在高维数据和大规模数据集上的表现可能不如专用向量数据库。

适用场景：

• 对性能有较高要求，且向量数据量不大的场景： 例如，基于 Redis 的实时推荐系统、在线广告检索等，需要低延迟、高吞吐量的向量检索。
• 希望尝试新技术，并愿意承担一定风险的场景： 对于技术尝鲜者，可以尝试使用 NoSQL 数据库的向量支持功能，探索其潜力。
• 已在使用 NoSQL 数据库，希望在其基础上增加向量检索能力： 在已使用 Redis 或 MongoDB 的项目中，希望在其基础上快速引入向量检索功能，可以考虑使用其向量扩展模块。

代表产品：

• Redis 向量相似性搜索 (VSS)： Redis 的模块，提供了向量索引 (HNSW) 和相似性搜索功能，强调高性能和低延迟，适用于实时性要求高的场景。
• MongoDB Atlas Vector Search： MongoDB 云服务 Atlas 的一项新功能，旨在将向量搜索集成到 MongoDB 的文档数据库中，提供更全面的数据处理能力。

结论： NoSQL 数据库中新增加的向量支持功能，目前还处于发展初期，成熟度和稳定性有待进一步验证。虽然它们具有一定的潜力，但在功能和性能上可能仍不如专用向量数据库成熟和强大。选择时需要谨慎评估，并充分考虑其局限性。

5. 专用向量数据库 (Pinecone、Milvus、Weaviate、Qdrant、Vespa、Vald、Chroma、Vearch)：为向量而生，RAG 系统和 AI 应用的首选

专用向量数据库，例如 Pinecone、Milvus、Weaviate、Qdrant、Vespa、Vald、Chroma、Vearch 等，从设计之初就专注于向量数据的存储、索引和检索，天生具备处理高维向量数据的优势。它们是构建 RAG 系统、语义搜索、推荐系统等 AI 应用的首选方案。

优势：

• 卓越的向量检索性能： 针对向量相似性搜索进行了深度优化，检索速度快、精度高，能够高效处理大规模高维向量数据。
• 强大的扩展性： 通常采用分布式架构，易于水平扩展，可应对海量数据和高并发查询，满足大规模应用的需求。
• 丰富的功能特性： 通常提供完善的向量数据管理、索引构建、查询优化、监控运维等功能，以及丰富的相似性搜索算法和距离度量指标。
• 灵活的索引选择： 支持多种向量索引算法 (如 IVF、HNSW、PQ、树结构索引等)，可以根据不同的应用场景和数据特点选择最优的索引策略。
• 成熟的生态系统 (部分产品)： 部分产品拥有活跃的社区和完善的生态系统，提供丰富的文档、工具和集成方案，易于使用和集成。

局限性：

• 学习成本较高： 相比传统数据库，专用向量数据库的学习曲线可能较陡峭，需要理解向量索引、相似性搜索等相关概念。
• 技术选型复杂： 产品众多，功能和特性各异，选型需要仔细评估，对比不同产品的优缺点。
• 部分产品商业化： 部分优秀的专用向量数据库是商业化产品 (如 Pinecone)，使用成本较高，可能存在厂商锁定风险。

适用场景：

• 以向量检索为核心的应用： 例如，RAG 系统、语义搜索、图像搜索、音频搜索、视频搜索、推荐系统、生物信息学分析等，向量检索是应用的核心功能。
• 需要处理海量高维向量数据的应用： 例如，大规模知识图谱、海量商品库、用户行为数据分析等，需要处理大规模高维向量数据。
• 对检索性能和精度有较高要求的应用： 例如，金融风控、安全监控、精准推荐等，对检索速度和精度有严格要求。
• 需要灵活的扩展性和高可用性的应用： 例如，大型在线服务、云平台等，需要支持水平扩展和高可用性，保障服务的稳定性和可靠性。

代表产品：

• Pinecone： 商业化的云端向量数据库，由专业团队维护，提供了易于使用和高度可扩展的向量检索服务。以其易用性和高性能著称，是云端向量数据库的代表。但开源性和定制化方面有所限制，免费版本功能有限。
• Milvus： 开源的分布式向量数据库，由 Zilliz 公司主导开发，性能强大、功能丰富、社区活跃，是开源向量数据库的标杆之作。支持多种索引类型、距离度量和查询方式，可灵活应对各种应用场景。
• Weaviate： 开源的图向量数据库，由德国公司 SeMI Technologies 开发，将向量搜索与图数据库技术相结合，提供了独特的数据建模和查询能力。支持 GraphQL 查询语言，方便进行复杂的数据查询和分析。
• Qdrant： 开源的向量数据库，由俄罗斯团队开发，采用 Rust 语言编写，注重性能和易用性，架构轻巧，资源消耗低。以其高性能、低延迟和易部署性受到欢迎。
• Vespa： 由 Yahoo 开发并开源的搜索引擎和向量数据库，功能强大、性能卓越，但架构较为复杂，学习曲线陡峭。适用于对性能和功能有极高要求的场景。
• Vald： 开源的分布式向量数据库，由日本团队开发，专注于高精度和高可靠性的向量检索。强调高精度和低延迟，适用于对精度要求极高的场景。但与 Langchain 的集成方面存在不足，社区规模较小。
• Vearch： 开源的分布式向量数据库，由中国团队开发，提供了高性能、高可用的向量检索服务。侧重于易用性和可扩展性，适用于需要快速构建向量检索应用的项目。与 Langchain 的集成方面存在不足，社区规模较小。
• Chroma： 开源的嵌入式向量数据库，专注于轻量级和易用性，采用 SQLite 作为文档存储。适用于本地开发、原型验证或小型应用，可扩展性和效率相对有限。Chroma 专门为音频数据设计，但在处理文本数据方面并未进行特别优化，综合性能基准测试资料相对匮乏。

结论： 对于 RAG 系统和大多数 AI 应用而言，专用向量数据库是最佳选择。它们在性能、功能和扩展性方面都更胜一筹，能够更好地满足这些应用的需求。在众多专用向量数据库中，Weaviate、Milvus、Qdrant 和 Vespa 是当前最受关注和广泛使用的几款产品。

为了更直观地对比 Weaviate、Milvus 和 Qdrant 这三款优秀的开源向量数据库，我们总结了以下表格：

总结：

• Qdrant： 架构轻巧，资源开销小，性能出色，易于部署和使用，Rust 语言开发，注重性能和效率。
• Weaviate： 功能全面，融合了向量搜索、对象存储和倒排索引，支持 GraphQL 查询，数据建模能力强，Go 语言开发，社区活跃。
• Milvus： 性能强劲，功能丰富，社区活跃，支持多种索引类型和查询方式，可灵活应对各种复杂场景，Go 和 C++ 语言开发，生态完善。

您可以根据自身的需求、技术栈偏好和团队能力，选择最适合您的向量数据库。

向量数据库的搜索方式详解：解锁向量检索的多种姿势

向量数据库的核心功能是相似性搜索，不同的向量数据库提供了多种搜索方式，以满足不同的应用需求。理解这些搜索方式，有助于您更有效地利用向量数据库，构建更强大的 AI 应用。

6. 向量数据库的搜索方式对比

我们将重点介绍 Milvus、Weaviate 和 Qdrant 这三款数据库的主要搜索方式：

6.1 Milvus：灵活多样的搜索策略，满足不同场景需求

Milvus 提供了丰富且灵活的搜索策略，可以根据不同的数据结构和查询需求选择合适的搜索方式。

• 单向量搜索 (Single Vector Search)： 这是最基本的搜索方式，使用 search() 方法，将一个查询向量与集合中的现有向量进行比较，返回最相似的实体 ID 及其距离。您可以选择返回结果的向量值和元数据。适用于简单的相似性搜索场景，例如，查找与某个商品最相似的商品，查找与某张图片最相似的图片等。
• 多向量搜索 (Multi-Vector Search)： 适用于包含多个向量字段的集合，通过 hybrid_search() 方法执行。该方法可以同时执行多个近似最近邻 (ANN) 搜索请求，并将结果进行融合和重排，以返回最相关的匹配项。Milvus 最新 2.4.x 版本支持最多使用 10 个向量进行搜索。多向量搜索特别适用于需要高精度的复杂场景，例如：
  • 同一数据使用不同嵌入模型处理： 例如，同一个句子可以使用 BERT、Sentence-BERT、GPT-3 等不同的模型生成不同的向量表示，多向量搜索可以融合这些不同模型的向量表示，提高搜索的准确性。
  • 多模态数据融合： 例如，将个人的图像、指纹和声纹等多种模态信息转换为不同的向量格式，进行综合搜索。多向量搜索可以将这些不同模态的向量信息融合起来，实现更全面的相似性搜索。
  • 提高召回率： 通过“多路召回”策略，为不同向量分配权重，综合利用多个向量的信息，可以显著提高召回能力和搜索结果的有效性，避免遗漏相关结果。
• 基本搜索 (Basic Search Operations)： 除了单向量和多向量搜索，Milvus 还提供了丰富的基本搜索操作，包括：
  • 批量向量搜索 (Batch Vector Search)： 一次性提交多个查询向量，提高搜索效率，适用于需要批量处理查询的场景。
  • 分区搜索 (Partition Search)： 在指定的分区内进行搜索，缩小搜索范围，提高搜索速度，适用于数据量大的场景，可以将数据按分区存储，提高查询效率。
  • 指定输出字段搜索 (Specify Output Fields)： 只返回指定的字段，减少数据传输量，提高搜索效率，适用于只需要部分字段信息的场景。
• 过滤搜索 (Filter Search)： 基于标量字段的过滤条件来细化搜索结果，例如，根据商品价格、用户年龄、商品类别等条件进行过滤，在相似性搜索的基础上，进一步筛选结果，提高搜索的精确性。
• 范围搜索 (Range Search)： 查找与查询向量距离在特定范围内的向量，例如，查找与目标商品相似度在 0.8 以上的商品，适用于需要限定相似度范围的场景。
• 分组搜索 (Grouped Search)： 根据特定字段对搜索结果进行分组，确保结果的多样性，避免结果过于集中，适用于需要结果多样性的场景，例如，推荐系统，希望推荐不同类别的商品。

6.2 Weaviate：强大的混合搜索能力，融合多种检索技术

Weaviate 提供了强大的混合搜索能力，可以将向量相似度搜索、关键词搜索、生成式搜索等多种搜索方式灵活组合，满足复杂的查询需求，提供更全面的检索方案。

• 向量相似度搜索 (Vector Similarity Search)： 提供多种近似搜索方法，寻找与查询向量最相似的对象，是 Weaviate 的核心搜索能力。
• 图像搜索 (Image Search)： 支持使用图像作为相似度搜索的输入，实现以图搜图功能，适用于图像检索场景。
• 关键词搜索 (Keyword Search)： 使用 BM25F 算法对结果进行排名，支持高效的关键词检索，适用于传统关键词搜索场景。
• 混合搜索 (Hybrid Search)： 将 BM25 关键词搜索和向量相似度搜索相结合，对结果进行融合排名，兼顾语义相关性和关键词匹配度，适用于需要同时考虑关键词和语义信息的混合搜索场景。
• 生成式搜索 (Generative Search)： 利用搜索结果作为 LLM 的提示，生成更符合用户意图的答案，将搜索与生成式 AI 技术结合，提供更智能的搜索体验。
• 重新排序 (Re-ranking)： 使用重排序模块 (Re-rank) 对检索到的搜索结果进行二次排序，提高结果的准确性和相关性，进一步优化搜索结果的质量。
• 聚合 (Aggregation)： 从结果集合中聚合数据，进行统计分析，提供数据分析能力，辅助用户进行数据挖掘和分析。
• 过滤器 (Filters)： 对搜索应用条件过滤，例如，根据元数据字段进行过滤，提高搜索的精确性，支持复杂的过滤条件。

6.3 Qdrant：专注于向量搜索，兼顾全文过滤，轻量高效

Qdrant 专注于提供高性能的向量搜索服务，同时兼顾了全文过滤功能，以其轻量级、高性能和易用性著称。

Qdrant 支持的基本搜索操作：

• 按相关分数过滤 (Filtering by Score)： 根据向量相似度分数进行过滤，只返回相似度较高的结果，提高搜索结果的质量。
• 单次请求负载多个搜索操作 (Multi-Search Requests)： 一次性提交多个搜索请求，提高搜索效率，适用于需要批量处理查询的场景。
• 推荐 API (Recommend API)： 提供专门的推荐 API，用于构建推荐系统，简化推荐系统的开发流程。
• 分组操作 (Grouping Operations)： 对搜索结果进行分组，提高结果的多样性，适用于需要结果多样性的场景。

Qdrant 支持的其他搜索方式：

Qdrant 的核心定位是向量搜索引擎，在不影响向量搜索性能的前提下，提供了有限的全文搜索支持，满足基本全文过滤需求。

• 使用全文过滤器搜索 (Full-text Filtering)： 可以使用全文过滤器对向量数据进行过滤，例如，查找包含特定关键词的向量数据，实现简单的全文检索功能。
• 将全文过滤器应用于向量搜索 (Full-text Filter with Vector Search)： 在具有特定关键词的记录中执行向量搜索，实现更精确的搜索，将全文过滤和向量搜索结合，提高搜索的精确性。
• 前缀搜索和语义即时搜索 (Prefix Search and Semantic Instant Search)： 支持前缀搜索和语义即时搜索，提供更友好的用户体验，支持模糊搜索和实时搜索。

Qdrant 未来计划引入的功能：

• 支持稀疏向量 (Sparse Vectors)： 例如，SPLADE 或类似模型中使用的稀疏向量，增强对稀疏数据的处理能力，提高向量检索的效率和精度。

Qdrant 不打算支持的功能：

• BM25 或其他非向量基础的检索或排名函数 (Non-Vector Based Retrieval)： Qdrant 坚持以向量搜索为核心，不打算支持传统的基于关键词的检索方法，保持架构的简洁和高效。
• 内置本体论或知识图谱、查询分析器和其他 NLP 工具 (Built-in Ontology or Knowledge Graph)： Qdrant 专注于向量搜索的底层基础设施，不涉及上层应用和 NLP 功能，保持核心功能的专注和性能优化。

BM25 和简单的关键词搜索有何区别？深入解析相关性评分

在关键词搜索领域，BM25 (Best Matching 25) 算法是一种比简单的关键词匹配更先进、更有效的相关性评分方法。理解它们之间的区别，有助于您更好地选择合适的搜索策略，尤其是在需要进行关键词搜索或混合搜索的场景下。

1. 相关性评分机制：

• 简单关键词搜索 (Simple Keyword Search)： 通常基于词频 (TF - Term Frequency) 进行评分，即关键词在文档中出现的次数越多，文档的相关性越高。这种方法简单直接，但容易忽略文档长度和关键词的重要性，容易导致长文档被过度评分，以及常用词和停用词对结果的干扰。
• BM25 (Best Matching 25)： 采用更复杂的算法，综合考虑词频 (TF)、逆文档频率 (IDF - Inverse Document Frequency) 和文档长度等因素，对文档进行相关性评分。BM25 能够更准确地衡量文档与查询的相关程度，有效解决简单关键词搜索的局限性。

2. 文档长度处理：

• 简单关键词搜索： 可能不考虑文档长度，导致长文档更容易被认为相关，因为长文档包含关键词的概率更高，造成长文档偏向性。
• BM25： 通过引入文档长度归一化因子，解决长文档偏向性问题，保证长文档和短文档在相关性评分上的公平性，避免长文档因为长度优势而获得过高的评分。

3. 查询词的重要性：

• 简单关键词搜索： 通常将所有关键词视为同等重要，忽略了关键词在文档集合中的稀有程度，导致常用词和停用词对结果产生干扰。
• BM25： 利用逆文档频率 (IDF) 来衡量关键词的重要性。IDF 值越高的关键词（即在文档集合中越稀有的关键词），对文档相关性评分的贡献越大，有效区分关键词的重要性，提高搜索结果的质量。

4. 参数可调性：

• 简单关键词搜索： 通常参数较少，难以进行精细化调优，灵活性较低。
• BM25： 提供了可调参数 (如 k1 和 b)，允许用户根据具体的应用场景和数据特点，对算法进行精细调整，优化搜索结果，提高搜索的灵活性和可定制性。

总结：

与简单的关键词搜索相比，BM25 算法在相关性评分、文档长度处理、查询词重要性衡量和参数可调性等方面都更胜一筹，能够提供更准确、更符合用户期望的搜索结果。因此，在对搜索质量有较高要求的场景下，BM25 算法是更优的选择，尤其是在需要进行关键词搜索或混合搜索的场景下，BM25 算法是提升搜索效果的关键技术。

7. 性能基准测试与指标详解：量化评估向量数据库的优劣

性能是选择向量数据库的重要考量因素。基准测试是评估向量数据库性能的有效手段。但需要注意的是，基准测试结果会受到多种因素的影响，因此在参考基准测试结果时，需要结合具体的应用场景和需求进行综合分析。

7. 附录

7.1 ANN Benchmarks：权威的性能评估平台

ANN-Benchmarks (Approximate Nearest Neighbors Benchmarks) 是一个权威的近似最近邻算法性能评测平台，由 Erik Bernhardsson 创建和维护。它提供了统一的基准测试框架和数据集，用于评估各种近似最近邻搜索算法和向量数据库的性能。ANN-Benchmarks 为向量数据库的性能评估提供了重要的参考依据，是了解不同向量数据库性能差异的重要工具。

基准测试的影响因素：

• 搜索类型： 过滤搜索 vs. 常规搜索，不同搜索类型对性能的影响不同。
• 配置设置： 数据库的配置参数，如索引类型、索引参数、缓存设置等，会显著影响性能。
• 索引算法： 不同的索引算法 (如 IVF, HNSW, PQ) 具有不同的性能特点，适用于不同的数据分布和查询场景.
• 数据嵌入： 数据嵌入的质量和维度，会影响向量数据库的性能和精度。
• 硬件环境： CPU, 内存, 磁盘, 网络等硬件资源，直接影响数据库的运行性能。

选型时除了基准测试，还需要关注的关键因素：

• 分布式能力： 是否支持分布式部署，能否水平扩展以应对海量数据和高并发。
• 数据副本与缓存： 是否支持数据副本和缓存机制，保障数据安全和提高系统性能。
• 索引算法： 采用何种索引算法，算法的性能特点和适用场景，是否支持多种索引算法。
• 向量相似性搜索能力： 是否支持混合搜索、过滤、多种相似性度量等高级搜索功能，满足复杂查询需求。
• 分片机制： 是否支持数据分片，如何进行数据分片和管理，提高数据管理和查询效率。
• 集群方法： 如何构建集群，集群的扩展性和稳定性，保障系统的高可用和可扩展性。
• 可扩展性潜力： 系统的可扩展性上限，能否满足未来业务增长的需求，预估系统的扩展能力。
• 数据一致性： 如何保证数据一致性，尤其是在分布式环境下，保障数据的一致性和可靠性。
• 系统整体可用性： 系统的稳定性和可靠性，能否保证 7x24 小时稳定运行，满足业务连续性需求。

角度度量 vs. 欧几里得度量：文本检索的关键指标

在文本检索领域，向量数据库在角度度量 (Angular Distance) 上的性能通常比欧几里得度量 (Euclidean Distance) 更为重要。这是因为角度度量对文本文档的语义相似性更为敏感，而欧几里得度量更侧重于文档的长度和规模。

• 角度度量 (如余弦距离)： 关注向量的方向，对向量长度不敏感，更适合衡量文本的语义相似性，适用于文本检索、文档分类等场景.
• 欧几里得度量 (如欧氏距离)： 同时考虑向量的大小和方向，对向量长度敏感，更适合衡量向量的绝对距离，适用于图像识别、语音识别等场景。

因此，在 RAG 系统选型时，应重点关注向量数据库在不同维度的角度数据集上的性能表现，例如 glove-100-angular 和 nytimes-256-angular 数据集。

性能分析 (glove-100-angular 数据集)：

• 吞吐量 (Queries per Second, QPS)： 在召回率低于 0.95 时，Milvus 表现出最高的吞吐量，意味着 Milvus 在保证一定召回率的前提下，能够处理更高的查询并发，性能更优。当召回率超过 0.95 后，各数据库的吞吐量差距缩小，高召回率下性能差距不明显。
• 索引构建时间 (Build Time)： Vespa 的索引构建时间最长，Weaviate 和 Milvus 的构建时间相近，但 Milvus 略长。索引构建时间直接影响数据库的启动速度和数据更新效率，构建时间越短，数据库启动和数据更新越快。
• 索引大小 (Index Size)： Weaviate 的索引最小，Milvus 的索引最大。索引大小影响存储成本和内存占用，索引越小，存储成本和内存占用越低。尽管 Milvus 的索引较大，但对于包含 120 万个 100 维向量的数据集，索引大小也小于 1.5GB，仍然可以接受，实际应用中需要根据数据规模评估索引大小的影响。

7.1.2 nytimes-256-angular 数据集性能

性能分析 (nytimes-256-angular 数据集)：

在该数据集上的性能表现与 glove-100-angular 数据集相似，整体趋势一致。

• 索引构建时间： Weaviate 的索引构建时间最长，Milvus 和 Qdrant 相对较短，构建时间排序与 glove-100-angular 数据集一致。
• 索引大小： Weaviate 的索引最小，Milvus 的索引最大，但仅为 440MB (包含 290,000 个 256 维向量的数据集)，索引大小排序与 glove-100-angular 数据集一致。

总结：

ANN Benchmarks 提供了宝贵的性能参考数据，帮助我们了解不同向量数据库的性能特点。Milvus 在吞吐量方面表现突出，适合高并发查询场景；Weaviate 在索引大小方面具有优势，节省存储空间；Vespa 在构建时间上相对较长，需要考虑索引构建效率。

实际选型时，需要结合具体的应用场景、数据特点和性能需求进行综合评估，不能仅依赖基准测试结果。

7.2 向量相似度指标：选择合适的度量方式，提升检索效果

向量相似度指标用于衡量两个向量之间的相似程度，不同的相似度指标适用于不同的数据类型和应用场景。选择合适的相似度指标，直接影响向量检索的精度和效果。不同的向量数据库支持的相似度指标有所差异，需要根据实际需求选择合适的数据库和相似度指标。

7.2.1 余弦距离 (Cosine Distance)：文本相似度计算的首选

余弦距离通过计算两个向量夹角的余弦值来衡量向量的相似度。余弦值越接近 1，向量越相似；余弦值越接近 -1，向量越不相似；余弦值为 0，向量正交，表示不相关。

• 优点：
  • 关注向量方向，忽略向量长度： 余弦距离主要关注向量的方向，对向量的长度不敏感。这使得它非常适合处理文本数据，因为在文本相似度计算中，文档的长度往往不是关键因素，而文档的主题和语义方向才是重要的。
  • 适用于高维稀疏数据： 在高维稀疏数据场景下，余弦距离仍然能够保持良好的性能，适用于文本、用户行为等高维稀疏数据的相似度计算。
• 缺点：
  • 对向量长度信息不敏感： 在某些场景下，向量的长度信息可能也很重要，例如，在推荐系统中，用户的活跃度 (向量长度) 可能是一个重要的特征。余弦距离会忽略这部分信息，可能导致信息损失。
  • 不适用于非凸数据集： 如果数据分布不是凸集，余弦距离可能无法提供准确的相似性度量，需要根据数据分布选择合适的相似度指标。
• 适用场景：
  • 文本相似度计算： 例如，计算两篇文章、两个句子或两个段落的语义相似度，是文本相似度计算的常用指标。
  • 文档分类： 将文档划分到不同的类别，基于文档向量的相似度进行分类。
  • 推荐系统： 基于用户行为或物品特征进行推荐，计算用户向量和物品向量的相似度，进行个性化推荐。
  • 高维稀疏数据场景： 例如，用户行为数据、商品特征数据等高维稀疏数据的相似度计算。

7.2.2 欧几里得距离 (Euclidean Distance, L2)：直观易懂，但高维空间性能受限

欧几里得距离，也称为 L2 范数，计算的是多维空间中两个向量之间的直线距离。距离越小，向量越相似；距离越大，向量越不相似。

• 优点：
  • 直观易懂： 欧几里得距离的概念简单直观，易于理解和使用，是人们最常用的距离度量方式之一。
  • 同时考虑向量大小和方向： 欧几里得距离同时考虑了向量的大小和方向，能够更全面地反映向量的差异，适用于需要考虑向量大小和方向的场景。
• 缺点：
  • 受“维度灾难”影响，高维空间性能下降： 在高维空间中，所有点之间的欧几里得距离都趋于相等，导致区分度下降，影响相似性搜索的精度，在高维数据场景下性能受限。
  • 对异常值敏感： 欧几里得距离对异常值比较敏感，异常值会显著影响距离计算结果，鲁棒性较差。
• 适用场景：
  • 图像识别： 例如，人脸识别、物体识别等，基于图像特征向量的欧几里得距离进行相似性比较。
  • 语音识别： 例如，语音特征匹配，基于语音特征向量的欧几里得距离进行相似性比较。
  • 手写分析： 例如，手写字符识别，基于手写字符特征向量的欧几里得距离进行相似性比较。
  • 低维数据场景： 在低维数据场景下，欧几里得距离仍然是一个有效的相似度度量指标，适用于低维数据的相似性搜索。

7.2.3 内积 (Dot Product)：高效计算，适用于推荐系统

内积，也称为点积，计算的是两个向量对应分量乘积之和。内积越大，向量越相似；内积越小，向量越不相似。

• 优点：
  • 计算速度快： 内积的计算速度非常快，尤其是在向量维度较高的情况下，性能优势更加明显，适用于大规模数据和高并发场景。
  • 同时反映向量大小和方向： 内积同时考虑了向量的大小和方向，能够反映向量的整体相似度，适用于需要考虑向量大小和方向的场景.
• 缺点：
  • 对向量尺度敏感： 内积的值会受到向量尺度的影响，如果向量的尺度差异较大，内积的相似度度量可能会失真，对向量尺度敏感。
  • 可能需要数据归一化： 为了消除向量尺度差异的影响，通常需要对数据进行归一化处理，例如，将向量归一化到单位长度，保证内积的相似度度量的准确性。
• 适用场景：
  • 推荐系统： 例如，计算用户向量和物品向量的相似度，进行个性化推荐，内积是推荐系统中常用的相似度指标。
  • 协同过滤： 基于用户或物品的相似度进行推荐，利用内积计算用户或物品之间的相似度。
  • 矩阵分解： 用于降维和特征提取，内积可以用于衡量向量之间的相似度，辅助矩阵分解算法的实现。
  • 需要高性能计算的场景： 例如，大规模在线推荐系统、实时检索系统等，需要快速计算向量相似度的场景。

7.2.4 L2 平方距离 (Squared Euclidean Distance)：放大差异，特定场景有效

L2 平方距离是欧几里得距离的平方，计算公式为欧几里得距离的平方值。

• 优点：
  • 惩罚向量元素之间的大差异： 平方操作会放大向量元素之间的差异，使得距离值对差异更加敏感。在某些情况下，这种特性可能更有利于区分相似度，突出差异性。
  • 避免平方根计算，提高计算效率： 在某些计算场景下，可以避免平方根计算，提高计算效率，简化计算过程。
• 缺点：
  • 平方操作可能扭曲距离： 平方操作会改变距离的尺度，可能导致距离的解释性降低，距离的含义不如欧几里得距离直观。
  • 对异常值更敏感： 平方操作会进一步放大异常值的影响，使得 L2 平方距离对异常值更加敏感，鲁棒性较差。
• 适用场景：
  • 图像处理： 例如，比较两张图片在像素级别的差异，L2 平方距离可以放大像素差异，更有效地比较图像的细微差别。
  • 异常检测： 放大异常值的影响，更容易检测到异常数据，适用于异常值敏感的异常检测场景。
  • 需要放大差异的特定场景： 在某些需要突出差异性的特定场景下，L2 平方距离可能比欧几里得距离更有效。

7.2.5 汉明距离 (Hamming Distance)：二进制数据的专属度量

汉明距离测量的是两个等长二进制向量对应位置不同值的数量，用于衡量二进制向量之间的差异程度。

• 优点：
  • 适用于二进制或分类数据： 汉明距离专门用于衡量二进制或分类数据的差异，适用于二进制向量的相似度计算。
  • 计算速度快： 汉明距离的计算非常简单高效，只需要比较二进制向量的对应位置，统计不同值的数量即可。
• 缺点：
  • 不适用于连续数值型数据： 汉明距离只能用于二进制或分类数据，无法处理连续数值型数据，适用范围有限。
• 适用场景：
  • 错误检测与纠正： 例如，在通信编码中，汉明距离用于衡量码字之间的差异，用于错误检测和纠正，是编码理论中的重要概念。
  • DNA 序列比对： 将 DNA 序列转换为二进制表示，使用汉明距离进行序列比对，用于生物信息学分析。
  • 分类型数据相似度计算： 适用于分类型数据的相似度计算，例如，用户标签、商品属性等分类数据的相似度计算。

7.2.6 曼哈顿距离 (Manhattan Distance, L1)：更鲁棒的距离度量，抵抗异常值

曼哈顿距离，也称为 L1 范数或城市街区距离，计算的是两个向量在所有维度上绝对差值之和。

• 优点：
  • 比欧几里得距离对异常值更鲁棒： 曼哈顿距离对异常值不如欧几里得距离敏感，因为它只计算绝对差值，而不是平方差值，鲁棒性更强，抵抗异常值干扰能力更强。
  • 计算速度相对较快： 曼哈顿距离的计算速度比欧几里得距离略快，适用于需要快速计算距离的场景。
• 缺点：
  • 几何意义不如欧几里得距离直观： 曼哈顿距离的几何意义不如欧几里得距离直观，不如欧几里得距离容易理解，几何解释性较差。
• 适用场景：
  • 棋盘距离计算： 例如，计算国际象棋棋盘上两个格子之间的距离，曼哈顿距离常用于计算棋盘距离。
  • 城市街区距离计算： 例如，计算城市中两个地点之间的距离，忽略对角线方向的距离，曼哈顿距离又称城市街区距离。
  • 物流规划中的最短路径问题： 曼哈顿距离可以用于评估物流规划中的路径长度，辅助最短路径算法的实现。
  • 对异常值敏感度较低的场景： 在需要降低异常值影响的场景下，曼哈顿距离比欧几里得距离更适用，鲁棒性更好。

8. 参考资料

1. https://github.com/milvus-io/milvus
2. Powering Al With Vector Databases: A Benchmark - Part I - Data - Blog - F-Tech
3. Fundamentals - Qdrant
4. Milvus documentation
5. Home | Weaviate - Vector Database
6. Qdrant Documentation - Qdrant
7. Vector Database Use Cases - Qdrant
8. Vector Databases: Intro, Use Cases, Top 5 Vector DBs
9. ANN-Benchmarks
10. Distance Metrics in Vector Search - Weaviate
11. BM25 - 百度百科