向量数据库如何助力 Text2SQL 处理高基数类别数据

导语

Agent 工作流和 LLMs （大语言模型）的出现，让我们能够以自然语言交互的模式执行复杂的 SQL 查询，并彻底改变 Text2SQL 系统的运行方式。其典型代表是如何处理 High-Cardinality Categorical Data （高基数类别数据）。

围绕这一问题，本文将以 Waii 和 Zilliz Cloud（完全托管的 Milvus 向量数据库）组合为例，展示如何将向量数据库与 Agentic Text2SQL 系统集成。

为什么 Text2SQL 不适合查询高基数类别数据

Categorical data （类别数据）在数据库中无处不在，比如各种产品类别、客户细分或交易类型。其典型代表如，人的性别分为男和女，中国一共有 34 个省级行政区。

不难发现，以上类别数据，其去重后唯一值的数量（cardinality）是可控的。相应的，这些低基数列对于 Text2SQL 系统来说相对容易处理，因为自然语言查询和数据库值之间的差距很小。

但当我们遇到高基数类别数据（某一类别特征的取值数量巨大）时，问题就出现了。比如，超过 60%的数据库大多长这样：包含数百万个唯一 ID 的产品目录，或包含数十万企业 ID 的金融数据库，甚至数据量超过上亿的身份识别库与电商 IP 地址库。

数据库需要对这些类别进行精确、严格的查找，但基于自然语言描述的查询通常是模糊和不精确的。比如，用户可能会问“最近什么剧比较火”或“最近哪个股票涨的比较好”。如何将这些模糊的描述转化为精准的数据库查询，Text2SQL 根本无法做到。

如何补足 Text2SQL 的短板

通常，Text2SQL 系统在做高基数类别数据的自然语言查询时会采用以下两种方法：

• 数据预处理技术（Preprocessed Database Techniques）：这种方法结合输入预处理并依赖于传统的数据库功能，如文本搜索和正则表达式。虽然它可以处理简单的匹配，但通常由于过于僵化而无法准确表示用户的想法，尤其是在复杂或精细化的查询中，我们的自然语言通常是非常多变的。

• 基于 LLM 的翻译（LLM-Based Translation）：在这种方法中，使用基于数据或少量示例训练的 LLM 来预测正确的类别值。虽然 LLM 在理解上下文和自然语言方面表现出色，但在处理高基数数据时经常产生错误的结果。这是因为 LLM 缺乏对完整（通常是私有的）数据集的了解，因此很难对那些不在训练数据中的如企业 ID 等信息进行查询。

对于高基数数据的处理，以上两种方法都有短板。

数据预处理技术过于僵化和字面化，无法有效处理自然语言查询的细微差别；而 LLM 虽然可以理解查询意图，但无法精准理解不在预训练数据中出现的特殊值。

向量数据库如何解决高基数类别数据查询困境

向量数据库旨在存储和高效查询数据的高维向量表达。不难发现，向量数据库的查询并非基于关键词匹配，而是主要是使用 embedding 进行语义搜索。因此，查询高基数类别数据，正是向量数据库的擅长之处。

接下来，我们会展示如何利用向量数据库来做基于自然语言的高基数类别数据查询。

工作原理：

• 创建 embedding（Create Vector Embeddings）：为高基数列中的每个唯一值创建 embedding。该 embedding 通过将值映射到高维空间中的向量来捕获其语义含义。

• 在向量数据库中索引（Index in a VectorDB）：将这些 embedding 存储在像 Milvus 这样的向量数据库中，该数据库针对高维空间中的快速相似性搜索进行了优化。

• 查询处理（Query Processing）：当用户提交自然语言查询时，使用 LLM 理解意图并生成初步 SQL 查询。对于高基数列，LLM 不是尝试生成特定值，而是生成所需值的描述或特征。

• 向量搜索（Vector Search）：使用此描述的 embedding 对向量数据库进行相似性搜索，检索相关的类别值。

• 优化（Refinement）：LLM 可以根据用户查询的完整上下文过滤掉任何不相关的匹配项。

• SQL 生成（SQL Generation）：通过使用优化的类别值列表构建相应的 filter 查询以及汇总来生成最终的 SQL 查询。

在 Text2SQL 中使用向量搜索的好处

向量数据库增强的方法提供了几个优势：

• 可扩展性（Scalability）：它可以处理具有数百万个唯一值的类别，而不会显著降低性能。

• 准确性（Accuracy）：通过结合 LLM 的语义理解和向量数据库的精确召回，可以更准确地将用户意图翻译为特定的数据库值。

• 灵活性（Flexibility）：这种方法可以适应数据库的更新，而无需重新训练整个系统。

选型与部署

落地中，我们可以考虑通过结合 Waii 和 Zilliz Cloud，来进行实际部署。

Waii 用于智能 Text2SQL

Waii 是世界上第一个基于 Agent 工作流构建的 Text2SQL API。它结合了编译器技术和自动生成的知识图谱，以实现最准确的查询生成。

• 自动检测（Automatic Detection）：Waii 自动识别这些高基数列，无需手动配置。

• 智能生成（Smart Embedding Generation）：它采用定制的工作流为不同类型的列构建和更新 embedding，优化准确性和资源效率。

• 自适应技术（Adaptive Techniques）：Waii 自动选择适合各种列类型的技术，确保最佳性能，而无需用户具备深厚的专业知识。

Zilliz Cloud 用于向量语义搜索

Zilliz Cloud 是支持高性能的向量数据库，它的扩展能力和低延迟精准召回的能力使其成为 AI 应用开发中的最佳选择，与 Waii 相辅相成。

• 可扩展性（Scalability）：Zilliz Cloud 可以轻松处理数十亿级的向量规模，使其成为高基数数据场景的理想选择。

• 高性能查询（Lightning-Fast Queries）：其优化的索引可以确保快速相似性搜索，保持低延迟。

• 安全性和访问控制（Security and Access Control）：Zilliz Cloud 通过安全网络选项和加密协议提供企业级数据安全和隐私合规性。这确保了数据在传输和静态时的安全性。此外，Zilliz Cloud 提供权限分明的身份控制和访问管理，包括基于角色的访问控制（RBAC）和 OAuth 2.0，以实现安全的集中式单点登录（SSO）功能。

Waii 和 Zilliz Cloud 的集成

• 自动工作流（Seamless Workflow）：Waii 的自动预处理和 Zilliz 的强大向量存储相结合，可以创建一个在处理 Text2SQL 系统中高基数数据的流畅、端到端解决方案。

• 生产级可用（Production-Ready）：专为现实世界的大规模挑战设计，适用于各个场景的生产部署。

通过利用 Waii 的自动检测和 Zilli 的高效向量查询，可以建立在 Text2SQL 系统中处理高基数类别数据的强大解决方案，而无需手动开发代码进行元数据管理或 embedding 生成。

实例

接下来，我们将展示如何部署一个监控全球数百万个新闻事件的查询平台。

数据库架构如下：

CREATE TABLE events (    event_id INT PRIMARY KEY,    event_name VARCHAR(255),    event_date DATE,    category VARCHAR(100),    total_spent DECIMAL(10, 2));

event_name 是一个高基数类别列，包含数百万个唯一的描述性名称，如“Global AI Ethics Summit 2024”、“Sustainable Living Expo: Greening Our Future”或“5th Annual Quantum Computing Breakthrough Conference”。

分析师可能会问：“How much money was spent on AI events last month?”

以下是处理这个问题的不同方法：

方法一：传统的关键词匹配

在这种方法中，我们直接把用户提供的术语作为查询的搜索词。我们在这里使用不区分大小写的全文搜索。

SELECT SUM(total_spent) FROM events WHERE event_name ILIKE '%AI%'  AND event_date >= DATE_TRUNC('month', CURRENT_DATE - INTERVAL '1 month')  AND event_date < DATE_TRUNC('month', CURRENT_DATE);

问题：这种方法错过了像“Machine Learning Symposium”或“Neural Network Workshop”这样与 AI 相关但不包含“AI”单词的事件，而且也可能错误地将“HAIR styling convention”这样含有“AI”字母的结果。

方法二：单独采用 LLM

在这种方法中，LLM 生成可能与搜索相关的多个术语，并据此构建 filter 查询。它通常会生成如下内容：

SELECT SUM(total_spent) FROM events WHERE (event_name ILIKE '%AI%'       OR event_name ILIKE '%Artificial Intelligence%'       OR event_name ILIKE '%Machine Learning%'       OR event_name ILIKE '%Neural Network%')  AND event_date >= DATE_TRUNC('month', CURRENT_DATE - INTERVAL '1 month')  AND event_date < DATE_TRUNC('month', CURRENT_DATE);

问题：虽然这种方法召回了更多与 AI 相关的事件，但它仍然局限于预定义的术语列表，可能会错过其他更新颖的 AI 相关的事件，依然无法实现精准召回。

向量数据库+LLM 方法

下图描述了整体流程。左侧是对事件表（events table）进行的预处理，右侧显示了生成查询的流程。

查询生成流程：

• Waii 解释查询并重写描述：“与人工智能、机器学习、神经网络和其他 AI 技术相关的事件。”

• 此描述用于查询 Zilliz Cloud，返回基于语义相似性的相关事件 ID 列表。

• Waii 优化此列表，过滤掉可能被错误召回的非 AI 事件。

• Waii 使用 Agent 工作流将这些事件 ID 纳入最终的 SQL 查询：

SELECT SUM(total_spent) FROM events WHERE event_id IN (1234, 5678, 9101, 1121, 3141, 5161, 7181, 9202, 1222, 3242) AND event_date >= DATE_TRUNC('month', CURRENT_DATE - INTERVAL '1 month') AND event_date < DATE_TRUNC('month', CURRENT_DATE);

这种方法可以准确识别与 AI 相关的事件，即使它们使用的是专业术语或并不包含明显的 AI 关键词，比如找到像“3rd Symposium on Generative Adversarial Networks”或“Workshop on Ethical Considerations in Reinforcement Learning”，而其他方法可能会错过。

通过利用向量相似性搜索，我们可以更准确地解释用户的意图，并将其与我们数据库中的高基数事件名称匹配，提供更全面和准确的结果。

结论

随着数据量的持续增长和用户对直观数据交互的期望增加，在 Text2SQL 系统中处理高基数类别数据将变得更加普遍。通过利用 Zilliz Cloud 与 Waii 的结合，可以创建更强大、可扩展和准确的系统。

本文作者：

陈将（Zilliz 生态和 AI 平台负责人）

Gunther Hagleitner（CEO and co-founder of Waii）