原文地址：Text2SQL is Not Enough: Unifying AI and Databases with TAG

摘要

通过数据库为自然语言问题提供服务的人工智能系统有望释放出巨大的价值。此类系统可让用户利用语言模型（LM）的强大推理和知识能力，以及数据管理系统的可扩展计算能力。这些综合能力将使用户能够通过自定义数据源提出任意的自然语言问题。然而，现有的方法并没有充分探索这种场景。Text2SQL 方法只关注可以用关系代数表达的自然语言问题，而这只是真实用户希望提出的问题的一小部分。同样，检索增强生成（RAG，Retrieval-Augmented Generation）考虑的是可以通过对数据库中的一条或几条数据记录进行点查询来回答的有限查询子集。我们提出了表增强生成（TAG，Table-Augmented Generatio），这是一种统一的通用范式，用于回答数据库中的自然语言问题。TAG 模型代表了 LM 与数据库之间广泛的交互，而这些交互以前从未被探索过，它为利用 LM 的世界知识和数据推理能力创造了令人兴奋的研究机会。我们系统地开发了研究 TAG 问题的基准，并发现标准方法只能正确回答不超过 20% 的查询，这证实了在这一领域开展进一步研究的必要性。我们在 https://github.com/TAG-Research/TAG-Bench 上发布了该基准的代码。

一、引言

通过让用户对数据提出自然语言问题，语言模型有望彻底改变数据管理，这也导致了对 Text2SQL 和检索增强生成（RAG）方法的大量研究。然而，根据我们的经验（包括 Databricks 内部工作负载和客户的经验），用户的问题往往超越了这些范例的能力，因此需要对系统进行新的研究投资，以便将数据库系统的逻辑推理能力与现代语言模型的自然语言推理能力结合起来。

用户的问题往往超越了这些范例的能力，这就要求我们投入新的研究力量，将数据库系统的逻辑推理能力与现代语言模型的自然语言推理能力结合起来。
特别是，我们发现真实商业用户的问题往往需要领域知识、通用知识、精确计算和语义推理的复杂组合。数据库系统通过其存储的最新数据以及大规模精确计算（LMs 不擅长），显然提供了领域知识的来源。

LM 在两个关键方面扩展了数据库的现有功能。首先，LMs 拥有对文本数据进行语义推理的能力，这是许多自然语言用户查询的核心要素。例如，Databricks 的一项客户调查显示，用户希望提出的问题包括：哪些客户对 X 产品的评价是正面的？ 或者为什么这段时间我的销售额下降了？这些问题提出了复杂的推理任务，例如对自由文本字段进行情感分析或总结趋势。LM 非常适合这些任务，而传统数据库系统中的精确计算或关系基元无法对这些任务进行建模。

其次，LM 利用模型训练过程中学习到的知识和模型权重隐式存储的知识，可以利用数据库表模式未明确捕捉到的通用知识，有力地增强用户数据。例如，Databricks 的一位内部人工智能用户在一个包含账户名称、产品和收入属性的表上询问 “零售 ”垂直行业的季度趋势是什么？要回答这个问题，系统必须了解企业是如何定义季度的（例如，从上一季度到本季度或从去年本季度到今年本季度的季度趋势），以及哪些公司被认为属于零售垂直行业。这项任务非常适合利用经过预先训练或微调的 LM 所掌握的知识。

能够有效利用数据库和 LM 一起为自然语言查询提供全面服务的系统，有望改变用户理解数据的方式。遗憾的是，这些问题目前还无法用常见的方法（如 Text2SQL 和 RAG）来回答。尽管 Text2SQL 方法适用于具有直接关系对应关系的自然语言查询子集，但它们无法处理大量需要语义推理或世界知识的用户查询。例如，前面的用户查询询问哪些客户评论是正面的，可能需要对评论进行逻辑行向 LM 推理，将每条评论分为正面或负面。同样，询问销售额下降原因的问题也是一个推理问题，必须汇总许多表项的信息。

另一方面，RAG 模型仅限于对少数数据记录进行简单的相关性点查找，然后调用一次 LM。这种模型只能服务于可通过点查找回答的查询子集，也无法利用许多数据库系统更丰富的查询执行功能，从而将计算任务（如计数、数学和过滤）留给了容易出错的 LM 的单次调用。除了容易出错和计算任务效率低之外，LM 在长上下文提示方面的表现也很差，这限制了它们在 RAG 生成阶段大规模推理数据的能力。

因此，我们提出了表格增强生成（TAG），作为在数据库上回答自然语言问题的系统的统一范式。具体来说，TAG 定义了三个关键步骤，如图 1 所示。首先，查询合成步骤同步将用户的任意自然语言请求𝑅 转化为可执行的数据库查询𝑄。然后，查询执行步骤 exec 在数据库系统上执行𝑄，以高效计算相关数据 𝑇 。最后，答案生成步骤 gen 利用𝑅 和 𝑇，其中 LM 被协调（可能是数据的迭代或递归模式），以生成最终的自然语言答案𝐴。TAG 模型简单但功能强大：它由以下三个等式定义，但却能捕捉到 LM 与数据库之间以前未充分研究的广泛交互。

Query Synthesis: syn(𝑅) →𝑄 (1)
Query Execution: exec(𝑄) →𝑇 (2)
Answer Generation: gen(𝑅, 𝑇 ) →𝐴 (3)

值得注意的是，TAG 模型统一了之前的方法，包括 Text2SQL 和 RAG，它们代表了 TAG 的特殊情况，只服务于有限的用户问题子集。虽然之前有几项工作涉及 TAG 的这些特殊情况，但我们提供了首个端到端 TAG 基准，该基准由一系列需要 LM 推理和知识能力的现实查询组成。

我们展示了这类问题带来的重大研究挑战，以及高效 TAG 实现的前景。我们的评估分析了普通的 Text2SQL 和 RAG 基线，以及两个更强的基线：带有 LM 生成功能的 Text2SQL 和带有基于 LM 的重新排序功能的检索。在各种查询类型中，我们发现每种基线方法都无法达到很高的准确率，在基准测试中从未超过 20% 的精确匹配率。另一方面，我们在最近的 LOTUS 运行时之上实现了手写 TAG 管道，发现它们比基准方法的准确率高出 20 - 65%。这种显著的性能差距表明了构建高效 TAG 系统的前景。

二、标签模型

现在我们来描述一下 TAG 模型，它接收自然语言请求 𝑅 并返回一个基于数据源的自然语言答案 𝐴。我们概述了 TAG 系统实现的三个主要步骤：查询合成、查询执行和答案生成。我们将 TAG 定义为这些步骤的单次迭代，但也可以考虑以多跳方式扩展 TAG。

2.1 查询合成

合成函数接收自然语言请求 𝑅 并生成查询 𝑄 供数据库系统执行。给定用户请求后，该步骤负责：(a) 推断哪些数据与回答请求相关（例如，使用表模式）；(b) 执行语义解析，将用户请求转化为数据库系统可执行的查询。该查询可以使用任何查询语言，但在我们的示例中使用的是 SQL。图 1 显示了一个 TAG 实例化示例，用户查询的问题是 “总结被视为‘经典’的最高票房爱情电影的评论”。在这里，数据源包含每部电影的片名、收入、类型和相关评论的信息。在这一步中，系统利用 LM 的语义推理能力生成一个 SQL 查询，该查询使用了数据源中的 movie_title、review、revenue 和 genre 属性。请注意，在本示例中，数据库 API 能够在 SQL 查询中执行 LM UDF，
因此这一步也为每一行引入了对 LM 的调用，以便在查询中识别经典影片。

图 1：TAG 实现的一个示例，用于回答用户对有关电影的表格提出的自然语言问题。TAG 流程分为三个阶段：查询合成、查询执行和答案生成

2.2 执行查询

在查询执行步骤中，执行函数在数据库系统中执行查询𝑄，以获得表 𝑇。这一步利用数据库查询引擎在海量存储数据中高效执行查询。数据库 API 可由多种系统提供服务，我们将在第 3 节中对此进行探讨。有些应用程序接口可能允许使用基于 LM 的操作符，从而允许数据库引擎在执行过程中利用 LM 的世界知识和推理能力。

在图 1 所示的示例中，数据库查询是一个用 SQL 编写的选择和排序查询，它会返回一个包含相关行的表。查询使用 LM 进行选择，根据电影标题评估哪些电影是经典电影，并使用标准类型过滤器查找爱情电影。该查询还根据收入对结果进行排序，以找到票房最高的电影。如图所示，结果表中包含电影 “泰坦尼克号 ”的评论。

2.3 生成答案

TAG 中的答案生成步骤与 RAG 中的生成步骤相同。在这一步骤中，gen 函数使用 LM 来生成答案𝐴，利用计算出的数据 𝑇 来回答用户的自然语言请求𝑅。

图 1 显示了 TAG 流水线示例的最后阶段，即输出关于 “泰坦尼克号 ”的评论摘要，作为对用户原始请求的回答。在该示例中，相关数据 𝑇 被编码为字符串供模型处理。编码表与原始用户请求𝑅 一起传递给 LM。为了获得答案，这一步将利用模型对评论列的语义推理能力来总结评论。

三、TAG 设计空间

在本节中，我们将探讨 TAG 模型的通用性，并描述它所产生的丰富的设计空间，同时强调几个未得到充分研究的进一步研究机会。

查询类型 TAG 模型具有足够的表现力，可以为广泛的自然语言用户查询提供服务。我们根据 (a) 回答查询所需的数据聚合程度和 (b) 回答查询所需的知识和能力，考虑了两种重要的查询分类。首先，TAG 模型既能捕捉点查询，如基于检索的问题（需要查询数据库中的一行或几行），也能捕捉聚合查询，如基于摘要或排名的问题（需要对数据库中的许多行进行逻辑推理）。其次，TAG 模型支持对系统提出不同要求的自然语言查询，以提供基于数据或推理的功能，包括情感分析和分类等任务。

数据模型 基础数据模型有多种形式。我们的实施方案使用关系数据库来存储和检索结构化属性，以便在下游问题解答任务中建立知识基础。其他数据模型可用于非结构化数据（如自由文本、图像、视频和音频）或半结构化数据，这些数据可通过键值、图、矢量、文档或对象存储等多种数据模型进行存储。

数据库执行引擎和 API 用来存储数据的底层系统可以使用多种可能的数据库执行引擎。Text2SQL 考虑使用基于 SQL 的查询引擎，为用户查询检索关系数据。在这种情况下，Syn 将利用数据源的知识（如表模式），并返回一个 SQL 查询来执行检索步骤。在另一种常见的情况下，即向量嵌入的检索系统中，Syn 会将自然语言查询转换为嵌入，并在向量存储上执行基于相似性的检索。

虽然这两种设置已被广泛研究，但一些未被充分研究的替代设置为有效实施 TAG 系统以服务更广泛的查询提供了有趣的机会。例如，最近的研究用语义运算符增强了关系模型，提供了一组基于人工智能的声明式运算符（例如，过滤、排序、聚合和使用自然语言说明符执行搜索）或 LM 用户自定义函数，提供了通用的 LM 函数。此外，MADLib、Google 的 BigQuery ML 和 Microsoft 的 Predictive SQL 等查询语言利用基于 ML 的本地函数增强了基于 SQL 的 API。利用这些系统为执行基于推理的优化检索模式提供了独特的机会。例如，在图 1 所示的示例中，使用语义运算符实施的 TAG 管道可以使用 sem_filter 运算符，在查询执行步骤中根据行是否为 “经典 ”来过滤行。

LM 生成模式 给定相关数据表 𝑇 后，gen 可由大量的实现决策组成，以生成响应用户请求 𝐴 的最终自然语言答案 𝑅。Text2SQL 省略了最终生成步骤，并在查询执行后停止，而 RAG 管道通常利用单个 LM 调用生成实现，其中相关数据根据上下文输入。在这种情况下，有几项工作研究了与表编码、提示压缩和提示调整相关的子问题，以优化上下文学习结果。最近的研究，如 LOTUS，强调了组合迭代或递归 LM 生成模式的潜力，用于回答涉及基于推理的转换、聚合或跨多数据行排序的查询。早期的工作表明，这些基于 LM 的算法提供了丰富的设计空间，并在一些下游任务中取得了可喜的成果。

四、评估

在本节中，我们将介绍首个 TAG 基准，并对一系列基准进行评估，旨在解决以下问题：
(1) 现有的表格问题解答方法在需要语义推理或通用知识的查询中表现如何？
(2) TAG 模型的手写实现将计算和推理步骤划分为 DBMS 和 LM 操作，该模型在这些查询中的表现如何？

4.1 基准方法

现有的基准测试探讨了模型在完全由数据源中的数据回答的基本查询中的表现。我们在先前工作的基础上对查询进行了修改，使其需要数据源中无法直接获得的知识或语义推理来回答。我们选择了 BIRD，这是一个广泛使用的 Text2SQL 基准，LM 已在该基准上进行了评估，因为它有大规模的表格，以及各种不同的领域和查询类型。

数据集 我们的查询跨越了从 BIRD 中选取的 5 个领域，每个领域都包含多种查询类型。我们选择 california_schools、debit_card_specializing、formula_1、codebase_community 和 european_ football_2 作为查询的数据库源。

查询 BIRD 基准定义了基本查询类型，包括基于匹配的查询、比较查询、排序查询和聚合查询。我们从 BIRD 基准中选择了这些类型的查询，并对其进行了修改，要求模型回答世界知识或语义推理。以需要世界知识的修改查询为例，在 california_schools 数据库中，修改后的查询添加了一个附加子句，要求只查询湾区的学校。该信息不在表中，因此需要模型的现实世界知识来回答。接下来，一个需要 LM 推理的修改查询会询问 codebase_community 数据库中某个帖子的前 3 条最讽刺的评论。在对这些查询进行评估时，我们依赖于人类标注的基本事实。我们的最终基准包括 80 个修改后的查询，其中 40 个需要参数知识，40 个需要推理，4 种选定的 BIRD 查询类型各占 20 个。

评估指标 对于基于匹配、比较和排序的查询类型，我们用精确匹配的百分比与标注的正确答案的百分比来衡量准确性。对于聚合查询，我们提供了使用每个基线的结果的定性分析。我们还测量了每个查询的执行时间（以秒为单位）。

实验设置 我们使用 Meta 的 Llama-3.1 模型的指令调整变体（参数为 70B）作为我们的 LM，用于 Text2SQL 和最终输出生成。我们在涉及 SQL 的基线中使用 SQLite3 作为数据库 API，在 RAG 基线中使用 E5 基础嵌入模型 。我们在 8 个 A100 80GB GPU 上使用 vLLM 运行 Llama-3.1- 70B-Instruct。

4.2 基线

Text2SQL 在此基线中，LM 生成 SQL 代码并运行以获得答案。对于给定的 NL 查询，我们使用与 BIRD 工作中相同的提示格式，构建了一个 LM 提示，其中包含查询域中每个表的表架构。我们将在 SQLite3 中执行生成的 SQL 代码，并测量错误答案的数量，包括模型未能生成有效 SQL 代码的情况，从而对这一基线进行评估。

检索增强生成（RAG） RAG 风格方法已被用于表格检索，其中表格数据被嵌入到索引中进行搜索。对于我们的基线，我们使用行级嵌入。在嵌入 FAISS 索引之前，给定行的每一列都被序列化为“- col: val”。在查询过程中，我们会执行向量相似性搜索，检索出 10 条相关行，将上下文与 NL 问题一起反馈给我们的模型。

检索 + LM 排名（Retrieval + LM Rank） 我们对 RAG 基线进行了扩展，利用 LM 为检索到的行分配一个介于 0 和 1 之间的分数，以便在输入到模型之前对行进行重新排名，正如 STaRK 工作中所做的那样[25]。我们使用 Llama-3.1-70B-Instruct 作为排序器。

Text2SQL + LM 在此基线中，我们的模型首先要生成 SQL，以检索一组相关行来回答给定的 NL 查询。这是与 Text2SQL 基线的重要区别，在 Text2SQL 基线中，模型被要求直接生成 SQL 代码，在执行时只提供查询答案。与 RAG 基线类似，相关行在检索后会根据上下文反馈给模型。

手写 TAG（Hand-written TAG） 我们还对手写 TAG 管道进行了评估，它利用了表模式的专家知识，而不是从自然语言请求到数据库查询的自动查询合成。我们使用 LOTUS 实现了手写 TAG 管道。LOTUS API 允许程序员使用标准关系运算符和语义运算符（如基于 LM 的过滤、排序和聚合）声明式地指定查询管道。LOTUS 还提供了一个优化的语义查询执行引擎，我们用它来实现手写 TAG 管道的查询执行和答案生成步骤。

4.3 结果

表 1：TAG 基准查询的准确性和执行时间（ET），所有查询和每种查询类型的平均值： TAG 在实现最快或接近最快的执行时间的同时，大大提高了答案质量。

表 1 显示了每种方法的精确匹配准确率和执行时间。如表所示，在所选的 BIRD 查询类型中，我们发现手写 TAG 基线始终保持 40% 或更高的精确匹配准确率，而所有其他基线的准确率均未超过 20%。

Text2SQL 基线在所有基线中的表现都很差，执行准确率不超过 20%，但在排名查询中的表现尤其糟糕，准确率只有 10%，因为许多排名查询都需要对文本进行推理。Text2SQL + LM 生成基线在所有基线上的表现都差不多差，但在基于匹配和比较的查询上表现更差，准确率只有 10%。在这些查询类型中，在执行 SQL 后向模型输入许多行时，会出现一些上下文长度错误。

将注意力转向 RAG 基线，我们会发现它在所有查询类型中都无法正确回答一条查询，这凸显了它对该领域查询的适应性较差。添加 LM 重排后，Retrieval + LM rank 可以在比较查询中正确回答一个查询，但除 RAG 外，该基线的表现仍然不如其他所有基线。

我们的手写 TAG 基线能正确回答 55% 的查询，在比较查询中表现最佳，精确匹配准确率为 65%。除排序查询外，基线在所有查询类型中的准确率都超过了 50%，这是因为准确排序项目的难度较高。总体而言，与标准基线相比，该方法的准确率提高了 20% 到 65%。

表 2：TAG 基准结果（需要知识或推理的查询的平均值）： 在知识和推理查询类型上，TAG 的准确匹配准确率始终保持在 50%以上。

此外，表 2 强调了标准方法在回答第 3 节讨论的查询类型时的弱点。也就是说，vanilla Text2SQL 由于省略了答案生成步骤，在需要 LM 推理的查询中表现尤为吃力，准确匹配率仅为 10%。同时，RAG 基线和 Retrieval + LM Rank 基线在所有查询类型上都很吃力，只正确回答了一个查询，这是因为它们依赖 LM 来处理对数据的所有精确计算。相比之下，手写 TAG 基线在需要知识的查询和需要推理的查询上都达到了 50% 以上的准确率，这强调了 TAG 模型在封装查询方面的多功能性。

值得注意的是，手写 TAG 方法不仅准确率高，而且执行效率高，执行时间比其他基线低 3.1 倍。手写基线处理所有查询的平均时间为 2.94 秒。这种相对较低的执行时间突出表明，通过利用高效的 LM 批量推理，可以设计出高效的 TAG 系统。

最后，我们定性分析了每个基线在聚合查询上的结果。图 2 显示了 RAG、Naive TAG 和手写基线在示例查询 “提供有关在雪邦国际赛道举行的比赛的信息 ”上的结果。RAG 基线只能提供部分赛事的信息，因为大部分相关赛事都没有检索到。另一方面，Text2SQL + LM 基线无法利用数据库管理系统中的任何信息，只能依靠参数知识，无法提供进一步的分析。手写基线提供了 1999 年至 2017 年在雪邦国际赛道举行的所有比赛的详尽摘要。我们在基准提供的其他汇总查询中观察到了类似的趋势，初步结果凸显了 TAG 系统成功汇总大量数据以提供信息答案的潜力。我们将在今后的工作中进行定量分析。

问题：提供有关在雪邦国际赛车场举行的比赛的信息

RAG	Text2SQL + LM	Hand-written TAG
根据给定的数据点，可获得有关雪邦国际赛道举办的比赛的以下信息： 在该赛道举行的比赛是马来西亚大奖赛。该赛道位于马来西亚吉隆坡。在这条赛道上举行过的比赛有 2001 年马来西亚大奖赛、2003 年马来西亚大奖赛、2002 年马来西亚大奖赛、2000 年马来西亚大奖赛。	所提供的数据点并不包含有关雪邦国际赛道所举办赛事的具体信息。不过，根据常识，雪邦国际赛车场是位于马来西亚雪邦的一条赛车场，从 1999 年到 2017 年曾举办过世界一级方程式锦标赛马来西亚大奖赛。	位于马来西亚吉隆坡的雪邦国际赛车场在 1999 年至 2017 年期间举办了马来西亚大奖赛。比赛举办日期如下： 1999: 1999年：10月17日（第15轮） 2000年：10月22日（第2轮 2000年：10月22日（第2轮），2001年：3月18日（第2轮），2002年：3月17日（第2轮），2003年：3月17日（第2轮 2002年：3月17日（第二轮），2003年：3月23日（第二轮 3 月 23 日（第二轮），2004 年 3 月 21 日（第二轮）， 2005 年 3 月 20 日（第 2 轮），…，2016 年： 2016 年：10 月 2 日（第 16 轮），2017 年：10 月 1 日（第 15 轮）： 10 月 1 日（第 15 轮）。

图 2：聚合结果示例： RAG 基线为查询提供了不完整的答案，而 Text2SQL + LM 则未能使用数据库中的任何数据回答问题。手写 TAG 基线提供了最全面的答案，它综合了数据库中的数据和自身的知识。

五、相关工作

Text2SQL 使用 LM 的 Text2SQL 已在之前的工作中得到广泛探索。WikiSQL、Spider 和 BIRD 都是跨领域 Text2SQL 的流行数据集。这些数据集包含许多领域的结构化数据，在这些数据集上可以评估将自然语言查询转换为 SQL 的任务。然而，这一方向并没有利用 SQL 生成之外的模型功能，因此需要推理或静态数据源之外的知识的查询不在此范围内。

检索增强生成 检索增强生成（RAG）使 LM 能够将其参数知识扩展到大型文本集合之外。SQuAD 和 HotPotQA 分别侧重于单文档和多文档源的问题解答。密集表格检索（DTR）模型 将 RAG 扩展到表格数据，嵌入表格上下文以检索查询的相关单元格和行。联接感知表检索为 DTR 模型添加了一个表-表相似度得分项，以提高涉及联接表的复杂查询的性能。与之前的 RAG 工作不同，TAG 模型在查询执行步骤中利用了 LM 功能，并允许 DBMS 操作对大量数据进行精确计算，从而涵盖了用户对其数据进行查询的更大领域。

半结构化数据的 NL 查询 之前的工作探索了半结构化数据源中表实体和非结构化实体字段之间的关系信息。STaRK 评估了半结构化知识库 (SKB) 中的表格检索方法，包括结构和非结构信息。SUQL 解决了会话搜索的任务，将 LM 用作语义解析器来处理混合数据上的非结构化组件用户查询。虽然这些工作主要侧重于半结构化数据的自然语言搜索查询，但我们试图探索更广泛的查询范围，利用更多的 LM 功能来完成搜索和查找以外的任务。

代理数据助手 最近的工作探索了作为数据助手的 LM 代理。Spider2-V 探索了多模式代理在涉及代码生成和图形用户界面控制任务中的性能。虽然我们将 TAG 模型定义为 syn、exec 和 gen 函数的一次迭代，但未来的工作可能会探索在代理循环中对其进行扩展。

六、结论

在这项工作中，我们提出了表格增强生成（TAG）作为回答数据库中自然语言问题的统一模型。我们开发了基准来研究两种重要的查询类型：需要现实世界广泛知识的查询和需要语义推理能力的查询。我们的系统评估证实，基线方法无法在这些任务上取得有意义的进展。不过，手写 TAG 管道的准确率最高可提高 65%，这为构建 TAG 系统提供了大量研究机会。

七、致谢

本研究过去得到了斯坦福破晓项目和伯克利天空计算实验室的附属成员和支持者的支持，包括埃森哲、AMD、Anyscale、思科、谷歌、IBM、英特尔、Meta、微软、穆罕默德-本-扎耶德人工智能大学、英伟达、三星 SDS、SAP、VMware 和斯隆奖学金。本资料中表述的任何观点、发现、结论或建议均为作者个人观点，并不一定反映赞助商的观点。