自从数据科学界发现向量搜索能显著改善 LLM（大型语言模型）的回答以来，各种供应商和爱好者一直在争论存储嵌入向量的恰当解决方案。
有人说，最好将它们存储在专用引擎（即向量数据库）中。另一些人则认为，只需使用现有数据库的插件就足够了。
本文阐述了我们对该主题的看法和论点。我们将
- 解释为什么以及何时您真正需要一个专用的向量解决方案
- 驳斥一些毫无根据的主张和在构建向量搜索系统时应避免的反模式。
目录
- 每个数据库供应商迟早都会引入向量能力…… [点击]
- 拥有一个专用的向量数据库需要数据重复。 [点击]
- 拥有一个专用的向量数据库需要复杂的数据同步。 [点击]
- 您必须为向量服务的正常运行时间和数据传输付费。 [点击]
- 有什么比您当前的数据库添加向量搜索功能更无缝的呢？ [点击]
- 数据库可以端到端地支持 RAG 用例。 [点击]
回应主张
每个数据库供应商迟早都会引入向量能力。这将使每个数据库都成为一个向量数据库。
这种误解源于对术语“向量数据库”的不谨慎使用。当我们想到数据库时，我们潜意识里会想象一个像 Postgres 或 MySQL 这样的关系型数据库。或者更科学地说，是一个建立在 ACID 原则之上，提供事务、强一致性保证和原子性的服务。
大多数向量数据库并非此意义上的数据库。更准确的说法是称它们为搜索引擎，但不幸的是，“向量数据库”这个市场术语已经根深蒂固，不太可能改变。
是什么让搜索引擎与众不同，以及为什么向量数据库被构建为搜索引擎？
首先，搜索引擎假定不同的工作负载模式，并优先考虑系统的不同属性。这类解决方案的核心架构是围绕这些优先事项构建的。
搜索引擎优先考虑哪些类型的属性？
- 可扩展性。搜索引擎旨在处理大量数据和查询。它们被设计成可横向扩展，并能处理比单个机器容纳更多的数据。
- 搜索速度。搜索引擎应保证查询的低延迟，而更新的原子性则不那么重要。
- 可用性。如果集群中的大多数节点宕机，搜索引擎必须保持可用。同时，它们可以容忍更新的最终一致性。
数据库保证维度
这些优先事项导致了不同的架构决策，而这些决策在通用数据库中是无法重现的，即使它支持向量索引。
拥有一个专用的向量数据库需要数据重复。
从本质上讲，向量嵌入是主要源数据的衍生品。
绝大多数情况下，嵌入是从其他数据派生的，例如文本、图像或系统中存储的额外信息。因此，实际上，您系统中的所有嵌入都可以被视为某些原始源数据的转换。
衍生数据的显著特点是，当转换流水线改变时，它也会改变。对于向量嵌入而言，这些变化的场景非常简单：每次更新编码器模型时，所有的嵌入都会改变。
在向量嵌入与主要数据源融合的系统中，不可能在不显著影响生产系统的情况下执行此类迁移。
因此，即使您想使用单个数据库存储所有类型的数据，您仍然需要在内部重复数据。
拥有一个专用的向量数据库需要复杂的数据同步。
大多数生产系统倾向于将不同类型的工作负载隔离到独立的服务中。在许多情况下，这些隔离的服务甚至与搜索用例无关。
例如，用于分析和用于服务的数据库可以从同一源更新。然而，它们可以以适合其典型工作负载的方式存储和组织数据。
搜索引擎通常出于同样的原因而被隔离：您希望避免产生资源争夺并损害主数据库的性能。
为了让您对此有所了解，让我们考虑一个实际示例
假设我们有一个包含 100 万条记录的数据库。按照现代关系型数据库的标准，这是一个小型数据库。您可能可以使用任何云提供商的最小免费层级来托管它。
但如果我们想将此数据库用于向量搜索，100 万个 OpenAI text-embedding-ada-002 嵌入将占用约 ~6GB 内存（确实如此！）。如您所见，向量搜索用例完全超出了主数据库的资源需求。实际上，这意味着您的主数据库将背负高内存需求，并且无法有效扩展，受限于单机大小。
幸运的是，数据同步问题并非新生事物，也绝非向量搜索所独有。有许多成熟的解决方案，从消息队列到专用 ETL 工具。
例如，我们最近发布了与 Airbyte 的集成，允许您将各种来源的数据增量同步到 Qdrant 中。
您必须为向量服务的正常运行时间和两种解决方案的数据传输付费。
在开源世界中，您支付的是您使用的资源，而不是您运行的不同数据库的数量。资源更多地取决于每种用例的最佳解决方案。因此，运行专用的向量搜索引擎甚至可能更便宜，因为它专门针对向量搜索用例进行优化。
例如，Qdrant 实现了多种量化技术，可以显著减少嵌入向量的内存占用。
在数据传输成本方面，大多数云提供商在同一区域内的网络使用通常是免费的。只要您将原始源数据和向量存储放在同一区域，就不会产生额外的数据传输成本。
有什么比您当前的数据库添加向量搜索功能更无缝的呢？
与集成解决方案的短期吸引力相比，专用搜索引擎提供了灵活性和模块化方法。您无需在每次向量插件更新时更新整个生产数据库。专用搜索引擎的维护与主数据库的隔离程度就像数据本身一样。
事实上，对于更复杂的场景，例如读写分离，使用专用的向量解决方案要容易得多。您可以轻松构建跨区域复制，以确保用户获得低延迟。
读写分离 + 跨区域部署
这在大型企业组织中尤为重要，这些组织中系统不同部分的职责分散在不同的团队中。在这种情况下，为 AI 团队维护一个专用的搜索引擎比说服核心团队更新整个主数据库要容易得多。
最后，一体化数据库的向量能力与整个堆栈的开发和发布周期相关联。其悠久的使用历史也意味着它们需要为向后兼容性付出高昂的代价。
数据库可以端到端地支持 RAG 用例。
抛开性能和可扩展性问题不谈，关于在数据库中实现 RAG 的整个讨论都假定传统数据库中唯一缺少的是向量索引和进行快速 ANN（近似最近邻）查询的能力。
事实上，当前的向量搜索能力仅仅触及了其可能性的皮毛。例如，在我们最近的文章中，我们讨论了构建探索 API 来推动发现过程的可能性——这是 kNN（最近邻）搜索的替代方案，在探索过程中，您甚至不知道自己在寻找什么。
总结
最终，如果您只需要处理少量数据的简单向量搜索功能，您并不需要向量数据库。我们真诚地建议您先使用现有技术栈进行原型开发。但如果您希望从中获得更多功能，并且向量搜索是您应用的核心功能，那么您就需要一个向量数据库。这就像使用多功能工具快速完成某事，或者使用为特定用例高度优化的专用工具。
大规模生产系统通常由不同的专用服务和存储类型组成，这是有充分理由的，因为这是现代软件架构的最佳实践之一。这与微服务架构中独立构建块的编排类似。
当您在数据库中塞入向量索引时，您会损害主数据库的性能和可扩展性，同时也会损害向量搜索的能力。没有一种“一刀切”的方法可以在不损害性能或灵活性的情况下解决问题。因此，如果您的用例以任何重要方式利用向量搜索，那么投资一个专用的向量搜索引擎（即向量数据库）是值得的。