Text2SQL 已过时？TAG 如何一统 AI 与数据库江湖！ 精华

1.引言

语言模型的发展使得用户期望能通过自然语言对数据进行查询，从而引发了 Text2SQL 和 RAG 等方法的大量研究。但在实际应用中，用户的问题往往超出这些方法的能力范围。例如，企业用户的问题常涉及领域知识、世界知识、精确计算和语义推理的复杂组合。数据库虽能提供领域知识和大规模精确计算能力，但在语义推理方面较弱；而语言模型虽擅长语义推理和利用世界知识，却在精确计算和大规模数据处理效率上存在不足。

像 Text2SQL 方法仅适用于能转换为关系代数的自然语言查询，无法处理需要语义推理或世界知识的大量用户查询。例如，对于“哪些客户对产品 X 的评价是积极的？”这样的问题，可能需要对评论进行逻辑行级别的语言模型推理来判断正负，这超出了 Text2SQL 的能力。RAG 模型则局限于对少量数据记录的简单相关性点查找和单次语言模型调用，无法充分利用数据库的查询执行能力，且在计算任务上容易出错、效率低下，长上下文提示下的表现也不佳。因此，需要一种新的方法来统一和扩展数据库与语言模型的能力，这就是 TAG 模型产生的背景。

2.TAG 模型

查询合成

查询合成步骤由 syn 函数完成，它将用户的自然语言请求 R 转换为数据库可执行的查询 Q。在这个过程中，系统首先要依据表结构等信息推断出与回答请求相关的数据，然后利用语言模型的语义推理能力将用户请求解析为数据库查询语言（如 SQL）。例如，对于“总结被视为‘经典’的票房最高的爱情电影的评论”这样的用户查询，系统需从数据源中包含电影标题、收入、类型和评论等信息中，确定使用 movie_title、review、revenue 和 genre 等属性生成 SQL 查询。并且，由于要识别经典电影，此步骤还可能在查询中引入对语言模型的调用，以评估每行数据中的电影是否为经典。

查询执行

exec 函数负责在数据库系统中执行查询 Q 以获取结果表 T。这一步利用数据库的查询引擎在大量存储数据上高效执行查询。数据库 API 有多种形式，常见的如基于 SQL 的查询引擎和基于向量嵌入的检索系统。在 SQL 查询引擎设置中，syn 函数会利用数据源知识（如表结构）生成 SQL 查询；在向量嵌入检索系统中，syn 函数将自然语言查询转换为嵌入，exec 函数在向量存储中进行相似性检索。此外，还有一些新兴的设置，如使用语义操作符增强关系模型，这些操作符提供了基于 AI 的声明性操作（如过滤、排名、聚合和自然语言指定的搜索），或者使用语言模型用户定义函数，为执行优化的基于推理的检索模式提供了独特机会。例如在前面提到的电影查询示例中，使用语义操作符的 TAG 管道可能在查询执行步骤中使用 sem_filter 操作符根据电影是否为“经典”来过滤行。

答案生成

答案生成步骤的 gen 函数利用语言模型，根据用户的自然语言请求 R 和计算得到的数据 T 生成最终答案 A。此步骤类似于 RAG 中的生成步骤，但在 TAG 模型中，语言模型的使用方式更加灵活。例如，对于电影评论的查询，相关数据 T 会被编码为字符串与原始用户请求 R 一起传递给语言模型，模型利用其语义推理能力对评论列进行总结，从而生成最终答案。

3.TAG 设计空间

查询类型

TAG 模型具有很强的表达能力，能够处理多种自然语言用户查询。从数据聚合程度来看，它涵盖了点查询（如基于检索的问题，只需查找数据库中的一行或几行数据）和聚合查询（如需要对多行数据进行逻辑推理的总结或排名问题）。从所需知识和能力角度，它支持需要情感分析、分类等不同系统能力的自然语言查询。例如，在商业数据分析中，既可以查询特定产品的某条销售记录（点查询），也可以对某类产品在一段时间内的销售趋势进行总结（聚合查询），还能分析客户对产品的情感倾向（涉及情感分析的查询）。

数据模型

TAG 模型的底层数据模型可以多样化。虽然本文的实现主要使用关系数据库来存储和检索结构化属性，为下游问答任务提供知识基础，但也可以处理更非结构化的数据（如自由文本、图像、视频和音频）或半结构化数据。这些不同类型的数据可以采用多种数据模型存储，如键值、图、向量、文档或对象存储。这为 TAG 模型在不同领域的应用提供了广泛的可能性，例如在医疗领域，可以处理病历文本（非结构化数据）、医学影像（图像数据）以及患者基本信息（结构化数据）等多种类型的数据，以回答医生或患者的各种查询。

数据库执行引擎和 API

存储数据的底层系统可以采用多种数据库执行引擎和 API。Text2SQL 主要考虑基于 SQL 的查询引擎来检索用户查询的关系数据，而在其他常见设置中，如基于向量嵌入的检索系统也有应用。除了这些已被广泛研究的设置外，还有一些未被充分探索的替代设置，为高效实现 TAG 系统提供了机会。例如，一些新兴的系统通过语义操作符增强关系模型，或者在 SQL-based APIs 中增加原生 ML-based 函数，如 MADLib、Google’s BigQuery ML 和 Microsoft’s Predictive SQL 等。这些系统在执行查询时能够利用语言模型的能力，实现更复杂的检索和推理模式。

语言模型生成模式

在答案生成阶段，给定相关数据表 T，gen 函数有多种实现方式来生成最终答案 A。与 Text2SQL 省略最终生成步骤和 RAG 通常采用的单次语言模型调用生成方式不同，更近期的研究如 LOTUS 强调了采用迭代或递归语言模型生成模式的潜力。这种方式在处理涉及跨多行数据的推理转换、聚合或排名的查询时表现出优势。例如，在分析大量用户对不同产品的评论数据时，通过迭代调用语言模型，可以逐步提炼和总结出用户的主要观点和情感倾向，生成更准确和全面的答案。

4.评估

基准方法

为了评估 TAG 模型及现有方法的性能，本文构建了一个新的基准。该基准基于 BIRD 进行改进，选择了其中 5 个领域的查询，并对这些查询进行修改，使其需要世界知识或语义推理才能回答。例如，在 california_schools 数据库中，将查询修改为要求仅返回旧金山湾区的学校信息，这需要模型的世界知识；在 codebase_community 数据库中，要求找出特定帖子上最具讽刺意味的前 3 条评论，这需要语言模型推理。最终基准包含 80 个修改后的查询，其中 40 个需要参数知识，40 个需要推理，且每个选定的 BIRD 查询类型各有 20 个。

在实验设置中，使用 Meta 的 Llama-3.1 模型（70B 参数的指令调优变体）作为语言模型，SQLite3 作为涉及 SQL 的基线数据库 API，E5 基础嵌入模型作为 RAG 基线。并在 8 个 A100 80GB GPU 上运行 Llama-3.1 70B-Instruct 与vLLM。评估指标包括测量与标记正确答案的精确匹配百分比作为准确性（对于匹配、比较和排名查询类型），对于聚合查询则进行定性分析，同时还测量每个查询的执行时间。

基线

Text2SQL：在这个基线方法中，语言模型生成 SQL 代码，然后在数据库中运行该代码以获取答案。对于给定的自然语言查询，构建包含查询域中每个表的表结构的语言模型提示，使用与 BIRD 工作相同的提示格式。通过在 SQLite3 中执行生成的 SQL 代码并统计错误答案数量（包括模型无法生成有效 SQL 代码的情况）来评估该基线。例如，对于一些复杂的查询，如涉及多表连接和条件筛选的查询，模型可能生成错误的 SQL 代码，导致无法得到正确答案。

RAG：RAG 风格的方法在表格检索中已有应用，本文的基线采用行级嵌入。在将数据嵌入 FAISS 索引之前，将每一行序列化为“col: val”的形式。在查询时，通过向量相似性搜索检索 10 个相关行，并与自然语言问题一起作为上下文提供给模型。然而，在实验中发现，该基线在所有查询类型中都无法正确回答单个查询，表明其在处理此类查询时存在严重不足。

Retrieval+LM Rank：此基线是对 RAG 基线的扩展，利用语言模型为检索到的行分配 0 到 1 之间的分数，在输入模型之前对行进行重新排名。使用 Llama-3.1-70B-Instruct 作为重新排名器。虽然在比较查询中能够正确回答一个查询，但总体性能仍然较差，不如其他基线方法。

Text2SQL+LM：在这个基线中，模型首先生成 SQL 以检索一组相关行来回答给定的自然语言查询，然后将检索到的行作为上下文提供给模型。与 Text2SQL 基线不同的是，这里模型不是直接生成提供答案的 SQL 代码。在实验中，该基线在匹配和比较查询上表现不佳，因为在执行 SQL 后将许多行提供给模型时会出现一些上下文长度错误。

Hand-written TAG：该基线利用 LOTUS 实现手写的 TAG 管道，通过专家知识构建查询管道，而不是从自然语言请求自动合成数据库查询。LOTUS API 允许程序员使用标准关系运算符和语义运算符（如基于语言模型的过滤、排名和聚合）声明性地指定查询管道，并提供了优化的语义查询执行引擎。

结果

实验结果表明，手写的 TAG 基线在所有方法中表现突出。在准确性方面，它在所有选定的 BIRD 查询类型上始终达到 40%或更高的精确匹配准确率，而其他基线方法均未超过 20%。Text2SQL 基线在所有查询类型上执行准确率不高于 20%，在排名查询上尤其差，仅为 10%，因为许多排名查询需要对文本进行推理。Text2SQL+LM 生成基线在各方面表现类似，在匹配和比较查询上仅为 10% 的准确率。RAG 基线如前所述无法正确回答任何查询，Retrieval+LM Rank 基线虽然在比较查询中有一定改进，但整体仍较差。

手写的 TAG 基线总体上能正确回答 55%的查询，在比较查询上表现最佳，精确匹配准确率为 65%，在除排名查询外的所有查询类型上准确率均超过 50%。在执行时间方面，手写的 TAG 方法也具有优势，平均执行时间为 2.94 秒，比其他基线方法快达 3.1 倍。这得益于其利用了语言模型的高效批量推理。在聚合查询的定性分析中，以“提供雪邦国际赛道举办的比赛信息”为例，RAG 基线只能提供部分比赛信息，Text2SQL+LM 基线无法利用数据库信息，而手写的 TAG 基线能够提供全面的总结，进一步证明了 TAG 系统在处理聚合查询方面的潜力。

5.相关工作

Text2SQL

先前的工作对使用语言模型的 Text2SQL 进行了广泛研究，WikiSQL、Spider 和 BIRD 等都是用于跨域 Text2SQL 的流行数据集。这些数据集包含多个领域的结构化数据，用于评估将自然语言查询转换为 SQL 的任务。然而，这些方法仅局限于 SQL 生成，无法处理需要超出静态数据源的推理或知识的查询。

RAG

RAG 使语言模型能够扩展到其参数知识之外的大量文本集合。SQuAD 和 HotPotQA 分别专注于单文档和多文档源的问答，密集表检索（DTR）模型将 RAG 扩展到表格数据。与先前的 RAG 工作不同，TAG 模型在查询执行步骤中利用语言模型能力，并允许数据库管理系统进行大规模数据的精确计算，从而涵盖了更广泛的用户查询领域。

NL Queries over Semi-structured Data

先前的工作探索了半结构化数据源中表实体和非结构化实体字段之间的关系信息。STaRK 评估了跨半结构化知识库（SKBs）的表检索方法，SUQL 解决了对话式搜索任务。与这些工作相比，本文的 TAG 模型旨在探索更广泛的查询，利用更多语言模型能力来处理搜索和查找之外的任务。

Agentic Data Assistants

近期的工作探索了将语言模型作为数据助手的代理，如 Spider2-V 探索了多模态代理在涉及代码生成和 GUI 控制任务中的性能。虽然本文将 TAG 模型定义为 syn、exec 和 gen 函数的一次迭代，但未来的工作可以探索在代理循环中扩展它。

6.结论

本文提出的 TAG 模型为解决自然语言与数据库交互问题提供了一种统一的新范式。通过构建专门的基准来研究需要世界知识和语义推理能力的查询，发现基线方法在这些任务上表现不佳，而手写的 TAG 管道能够实现高达 65%的准确率提升。这表明 TAG 模型具有巨大的研究潜力和应用前景，为后续构建更高效的自然语言与数据库交互系统指明了方向，有望在数据分析、商业智能等众多领域引发新的技术变革，推动人工智能与数据库技术的深度融合与发展。未来的研究可以进一步探索 TAG 模型在不同数据类型、应用场景下的优化和扩展，以及与其他新兴技术的结合，不断提升其性能和适用性。

7.如何使用

话不多说，上代码

创建 conda 环境并下载依赖项

conda create -n tag python=3.9 -y
conda activate tag
pip install -r requirements.txt
pip install -e .

下载 BIRD DB 并将其转换为 Pandas DataFrames

cd setup
chmod +x get_dbs.sh
./get_dbs.sh

现在您应该有一个 dev_folder ​包含数据库的文件夹和一个pandas_dfs DataFrames 的文件夹。

在每个表上创建索引（建议使用 GPU）

cd setup
chmod +x embed_all_dfs.sh
./embed_all_dfs.sh

现在您应该有一个 indexes包含索引的文件夹。

获取 Text2SQL 提示

cd setup
chmod +x get_text2sql_prompts.sh
./get_text2sql_prompts.sh

在执行上述设置步骤后，你可以运行以下内容来重现论文中的结果。在 TAG 目录中运行这些内容以获得方法输出。你应该编辑每个文件中的对象，使其指向你想要使用的语言模型服务器。查看  LOTUS 文档以配置 models.lm。

LOTUS上运行手写 TAG​​
​​

python hand_written.py \
    --pipelines 0134568101113161819202124108109110111 \
    25 27293033353637383940414243444546474849 \
    50 5152535455565758596061626364651061079521000 \
    81 828586878889909192939495969799100101102103 \
    --output_dir out_hand_written

Text2SQL

python text2sql.py --output_dir out_text2sql

Text2SQL + LM

python text2sql_lm.py --output_dir out_text2sql_lm

RAG

python rag.py --output_dir out_rag

Retrieval+LM Rank

python rag.py --output_dir out_rerank --rerank

然后，每种方法的准确性和延迟可以通过以下命令进行评估。

python analyze.py --output_dir out_hand_written

[1] 论文地址：​​https://ar​​xiv.org/pdf/2408.14717

[2] 代码地址：​​https://github.com/TAG-Research/TAG-Bench​​

​​[3] 论文标题：Text2SQL is Not Enough: Unifying AI and Databases with TAG​​

​​[4] LOTUS ：https://github.com/guestrin-lab/lotus ​​

本文转载自​​ AIGC前沿技术追踪​​，作者： AIGC前沿技术追踪