不要在专用向量数据库上构建您的未来

向量数据库无法比传统 SQL 或 NoSQL 数据库更好地解决现代数据挑战。

译自 Don’t Build Your Future on Specialized Vector Databases,作者 Usama Jamil。

随着人工智能的兴起,向量数据库因其高效存储、管理和检索大规模、高维数据的能力而备受关注。此功能对于处理文本、图像和视频等非结构化数据的 AI 和生成式 AI (GenAI) 应用程序至关重要。

向量数据库背后的主要逻辑是提供相似性搜索功能,而不是传统数据库提供的关键字搜索。此概念已被广泛采用以提升大语言模型 (LLM) 的性能,尤其是在 ChatGPT 发布之后。

LLM 的最大问题是它们需要大量的资源、时间和数据进行微调。这使得保持它们更新变得非常困难。这就是为什么当你向 LLM 查询近期事件时,它们经常提供事实不正确、荒谬或与输入提示脱节的答案,从而导致“幻觉”。

一种解决方案是检索增强生成 (RAG),它通过集成从外部知识库检索的最新信息来增强 LLM。专用向量数据库旨在高效处理矢量化数据并提供强大的语义搜索功能。这些数据库经过优化,可存储和检索高维向量,这对于进行相似性搜索非常重要。向量数据库的速度和效率使其成为 RAG 系统不可或缺的一部分。

围绕向量数据库的炒作让许多人认为传统数据库可能会被向量数据库取代。是否可以将组织的整个数据集存储在向量数据库中并使用自然语言检索,而不是存储在传统 (SQL 或 NoSQL) 数据库中并编写手动查询?

但向量数据库并不像传统数据库那样运作。正如 Qdrant 首席技术官 Andrey Vasnetsov 所写,“从这个意义上说,大多数向量数据库都不是数据库。更准确地说,应该称它们为搜索引擎。”这是因为它们的主要目的是提供优化的搜索功能,并且它们并非设计用于支持诸如关键字搜索或 SQL 查询等基本功能。

专用向量数据库的局限性

随着用例的增加和人们专注于其应用程序的可扩展性,向量数据库的局限性变得更加明显。开发人员很快意识到他们仍然需要全文搜索引擎和向量搜索的功能。例如,根据特定条件过滤搜索结果对于向量数据库来说非常困难。这些数据库还缺乏对精确短语的直接匹配,这对于许多任务至关重要。

对复杂查询的支持有限

复杂查询通常涉及多个条件、联接和聚合,这使得专用向量数据库难以处理。这些数据库通过元数据过滤提供对复杂查询的有限支持。但是,向量数据库中的元数据存储非常有限,这限制了用户进行各种复杂查询的能力。

相比之下,SQL 数据库旨在处理大量的存储和处理,从而可以高效执行涉及多个条件、联接和聚合的复杂查询。这使得 SQL 数据库在处理复杂的数据检索和操作任务时更加通用和强大。

数据类型限制

专用向量数据库还面临数据类型限制。它们旨在存储向量和最少的元数据,这限制了它们的灵活性。对向量的关注意味着它们无法处理 SQL 数据库可以处理的各种数据类型,例如整数、字符串和日期,这允许更复杂和多样的数据操作。

总体而言,专用向量数据库的关注点非常狭窄。它们的架构主要针对语义搜索进行了优化,而不是更广泛的数据管理需求。这限制了它们执行各种任务的功能,而这些任务很容易由 SQL 数据库等更通用的系统处理。此外,它们无法存储和管理除向量之外的不同数据类型,这使得它们不太适合通用数据库任务。向量数据库适用于 RAG 应用程序 ,但它们不够通用,无法用于更广泛的用例。

集成挑战

将专用向量数据库集成到现有 IT 基础设施中充满了挑战。由于专用向量数据库与现有系统之间的固有差异,通常会出现兼容性问题,需要进行大量数据转换,并可能导致数据丢失或损坏。确保与遗留系统互操作并维护数据一致性和完整性也是复杂的任务。此外,集成过程需要专门的技能,而组织内部可能无法轻易获得这些技能,从而导致高昂的培训成本和陡峭的学习曲线。

此外,集成的财务影响也很大。成本包括软件许可、硬件升级、人员培训和持续维护。此外,可能需要修改或重写现有应用程序以与向量数据库交互,这是一个昂贵且有风险的过程,可能会引入新的错误或性能问题。对专用向量数据库的持续支持和更新需求也可能导致长期的财务承诺。

数据处理需要混合方法

专用向量数据库的基础是向量存储和向量搜索,主要用于 RAG 应用程序。但是,传统数据库也应该能够处理向量,而向量搜索是一种查询处理方法,而不是一种处理数据的新方法基础。

RAG 是一种流行的 AI 技术,受益于向量数据库。虽然向量数据库非常适合语义搜索和处理高维数据,但它们专注的功能通常会忽视组织的运营和功能需求。这可能会限制它们在具有不同运营和功能需求的更广泛应用程序中的使用。

同样,传统数据库已尝试整合向量存储和向量搜索功能,以提供一种高效的解决方案,用于大规模处理复杂的数据类型。例如,PostgreSQL 和 Elasticsearch 引入了向量搜索功能。但是,它们的向量搜索性能并不如 Pinecone 和 Qdrant 等专用向量数据库,并且落后于它们。例如,Qdrant 以 0.9822 的精度率实现了仅 45.23 毫秒的平均延迟。相比之下,尽管功能强大,但 OpenSearch 记录的延迟较高,为 53.89 毫秒,精度略低,为 0.9823。完整的基准 可在 GitHub 中获得。

专用向量数据库的架构经过专门设计,可以高效地处理高维向量数据,但传统数据库主要用于关系数据,并且天生不支持向量搜索的特定需求。

另一种选择是向当前数据库或搜索引擎添加向量扩展。这种方法通过将传统数据库的优势和灵活性与现代向量搜索的高级功能相结合,直接支持业务需求。

混合模型可以更紧密地满足业务的多样化数据处理需求,并简化其数据基础设施。这可以降低运营成本和复杂性,最终导致更具可扩展性和效率的解决方案,以满足组织的全面数据处理需求。

SQL 向量数据库弥合差距

半个世纪以来,SQL 一直是可扩展应用程序的主干,它与向量搜索功能的集成有望弥合传统和现代数据处理需求之间的差距。将 SQL 与向量集成将提高数据建模的灵活性,并简化开发。这将使系统能够处理涉及结构化数据、向量数据、关键字搜索和跨多个表的联接查询的复杂查询。

虽然专用向量数据库在以精度和速度处理高维数据方面表现出色,但将向量搜索集成到 SQL 数据库中提供了一个引人注目的替代方案。它平衡了大规模处理复杂数据类型所需的效率与在熟悉且广泛采用的框架内工作的便利性。这种集成解决了专用向量数据库面临的许多挑战,例如缓慢的迭代、低效的查询和管理单独数据库的高成本。通过采用SQL 向量数据库,企业可以利用 SQL 久经考验的可扩展性和可靠性,同时获得应对现代数据处理多方面挑战所需的高级功能。

结论

完全依赖于仅处理向量的专门向量数据库会限制数据管理策略的灵活性。多功能或集成向量数据库提供了更有前景的解决方案。

MyScaleDB 是一款开源 SQL 向量数据库,它不仅可以高效管理向量,还可以作为传统数据库使用,因此适用于广泛的应用程序。

MyScale 基于 ClickHouse 构建,它将传统 SQL 数据库的优势与向量数据库的功能相结合,使用 SQL 高效存储和管理高维向量,适用于 GenAI 应用程序。它也是第一个 SQL 向量数据库,在性能和成本效益方面都优于专门的向量数据库,打破了集成向量数据库本质上效率低于其他数据库的神话。

在当今的人工智能技术世界中,拥有一个可以管理传统数据和向量数据的数据库至关重要。这种方法确保了可扩展性、灵活性和成本效益,消除了管理多个系统需求。通过选择一个多功能数据库,您可以为未来做好数据基础设施的准备,并满足现代应用程序不断增长的需求。

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注