SQL向量数据库正在塑造新的LLM和大数据范式

将矢量数据库与 SQL 相结合可以提供构建现代生产级 GenAI 应用程序所需的准确性和性能。

译自 SQL Vector Databases Are Shaping the New LLM and Big Data Paradigm,作者 Linpeng Tang。

像 GPT-4、Gemini 1.5 和 Claude 3 这样的强大大型语言模型 (LLM) 的兴起已成为人工智能和技术领域的颠覆者。一些模型能够处理超过 100 万个 Token,它们处理长上下文的强大能力令人印象深刻。然而:

  1. 许多数据结构过于复杂且不断发展,LLM 无法有效地自行处理。
  2. 在上下文窗口内管理海量异构企业数据根本不切实际。

检索增强生成 (RAG) 有助于解决这些问题,但检索准确性是端到端性能的主要瓶颈。一种解决方案是通过高级 SQL 向量数据库将 LLM 与大数据集成。LLM 与大数据之间的这种协同作用不仅使 LLM 更有效,而且使人们能够从大数据中获得更好的智能。此外,它在提供数据透明性和可靠性的同时进一步减少了模型幻觉。

向量数据库的现状

作为 RAG 系统的基石,向量数据库在过去一年中发展迅速。它们通常可以分为三类:专用向量数据库、关键字和向量检索系统以及 SQL 向量数据库。每种类型都有其优点和局限性。

专用向量数据库

一些向量数据库(如 Pinecone、Weaviate 和 Milvus) 从一开始就专门设计用于向量搜索。它们在该领域表现出良好的性能,但通用数据管理能力有些受限。

关键字和向量检索系统

以 Elasticsearch 和 OpenSearch 为代表,这些系统因其全面的基于关键字的检索能力而被广泛用于生产中。然而,它们消耗大量的系统资源,并且关键字和向量混合查询的准确性和性能往往令人不满意。

SQL 向量数据库

SQL 向量数据库 是一种专门的数据库类型,它将传统 SQL 数据库的功能与向量数据库的功能相结合。它提供了借助 SQL 高效存储和查询高维向量的能力。

上图展示了两个主要的 SQL 向量数据库:pgvector 和 MyScaleDB。Pgvector 是 PostgreSQL 的向量搜索插件。它易于上手,适用于管理小型数据集。然而,由于 Postgres 的行存储劣势和向量算法限制,pgvector 对于大规模、复杂的向量查询往往具有较低的准确性和性能。

MyScaleDB 是一个开源 SQL 向量数据库,建立在 ClickHouse(一个列式存储 SQL 数据库)之上。它旨在为 GenAI 应用程序提供高性能且经济高效的数据基础。MyScaleDB 也是第一个在整体性能和成本效益方面 优于专用向量数据库 的 SQL 向量数据库。

MyScale 基准测试与竞争对手

来源: MyScale GitHub

SQL 和向量联合数据建模的强大功能

尽管 NoSQL 和大数据技术不断涌现,但在 SQL 诞生半个世纪后,SQL 数据库仍继续主导着数据管理市场。即使是 Elasticsearch 和 Spark 等系统也添加了 SQL 接口。借助 SQL 支持,MyScaleDB 能够在向量搜索和分析中实现高性能

在实际的 AI 应用中,集成 SQL 和向量可以增强数据建模的灵活性并简化开发。例如,一个大型学术产品使用 MyScaleDB 对海量的科学文献数据进行智能问答。主要的 SQL 架构包含 10 多个表,其中几个表具有基于向量和关键字的反向索引结构,并通过主键和外键连接。该系统处理涉及结构化、向量和关键字数据以及跨多个表的联接查询的复杂查询。这对专门的向量数据库来说是一项艰巨的任务,这通常会导致缓慢的迭代、低效的查询和高昂的维护成本。

SQL 向量数据库架构

MyScale 支持的大型学术产品的 SQL 向量数据库架构(加粗的列具有关联的向量索引或反向索引)。

提高 RAG 的准确性和成本效益

在实际的 RAG 系统中,克服检索准确性(以及相关的性能瓶颈)需要一种有效的方法来组合对结构化、向量和关键字数据的查询。

例如,在金融应用中,当用户查询文档数据库时,询问“2023 年全球 <company_name> 的收入是多少?”时,语义向量可能无法捕获“<company_name>”和“2023”等结构化元数据,或者这些元数据不存在于连续文本中。整个数据库中的向量检索可能会产生杂乱的结果,从而降低最终准确性。

但是,公司名称和年份等信息通常可以作为文档元数据获得。使用WHERE year=2023 AND company LIKE "%<company_name>%"作为向量查询的过滤条件可以精确定位相关信息,从而显著提高系统可靠性。在金融、制造和研究领域,我们观察到 SQL 向量数据建模和联合查询将精度从 60% 提高到 90%。

虽然传统的数据库产品已经认识到在 LLM 时代向量查询的重要性并开始添加向量功能,但其组合查询的准确性仍然存在重大问题。例如,在过滤器搜索场景中,当过滤比率为 0.1 时,Elasticsearch 的每秒查询数 (QPS) 速率下降到大约 5,而使用 pgvector 插件的 PostgreSQL 在过滤比率为 0.01 时准确率仅为大约 50%。这表明不稳定的查询准确性和性能极大地限制了它们的使用。相比之下,SQL 向量数据库 MyScale 在各种过滤比率场景中实现了超过 100 QPS 和 98% 的准确性,成本仅为 pgvector 的 36% 和 Elasticsearch 的 12%。

LLM + 大数据:构建下一代代理平台

机器学习和大数据推动了 Web 和移动应用程序的成功。但随着 LLM 的兴起,我们正在转向构建具有大数据解决方案的新一代 LLM。这些解决方案解锁了大规模数据处理、知识检索、可观察性、数据分析、少样本学习等关键功能。它们在数据和 AI 之间创建了一个闭环,为下一代 LLM + 大数据代理平台奠定了基础。这种范式转变已经在科学研究、金融、工业和医疗保健等领域展开。

随着技术的快速发展,预计在未来 5 到 10 年内会出现某种形式的人工通用智能 (AGI)。关于这个问题,我们必须问:我们需要一个静态的虚拟模型,还是需要一个更全面的解决方案?数据无疑是连接 LLM、用户和世界的纽带。我们的愿景是有机地集成 LLM 和大数据,创建一个更专业、更实时、更协作的 AI 系统,它也充满了人性化的温暖和价值。

欢迎您探索 GitHub 上的 MyScaleDB 存储库,并利用 SQL 和向量构建创新的生产级 AI 应用程序。

发表回复

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