表格增强生成TAG登场：解锁AI自然语言与数据库的完美结合

与 Text2SQL 或 RAG 不同，TAG 充分利用了数据库系统和 LLM 的功能。

人工智能已经改变了人们的工作方式和与数据交互的方式。回想几年前，研究人员必须编写 SQL 查询和代码才能从大量数据中提取有用信息。如今，他们只需输入问题，由语言模型驱动的底层系统会完成其余工作，让用户只需与数据对话即可立即获得答案。

这些新系统向数据库提供自然语言交互，这种转变取得了丰硕成果，但仍存在一些问题。从本质上讲，这些系统仍然无法处理各种查询。

本文，来自 UC 伯克利和斯坦福大学的研究人员现在正努力用一种名为表格增强生成 (TAG，Table-Augmented Generation) 的新方法来解决这一问题。

论文地址：https://arxiv.org/pdf/2408.14717
项目地址：https://github.com/TAG-Research/TAG-Bench
论文标题：Text2SQL is Not Enough: Unifying AI and Databases with TAG

TAG 是一种统一且通用的范式，用于回答数据库中的自然语言问题。TAG 模型代表了 LM 和数据库之间未曾探索过的广泛交互。

TAG 是如何工作的

目前，当用户对自定义数据源提出自然语言问题时，主要采用两种方法：文本到 SQL 或检索增强生成 (RAG)。

虽然这两种方法都能很好地完成工作，但当问题变得复杂并超出系统能力时，用户就会遇到问题。

举例来说，文本到 SQL 的方法（这是一种将文本提示转换为数据库可以执行的 SQL 查询）仅关注可以用关系代数表达的自然语言问题，但只能查询用户可能想要询问的一小部分问题。

相似的，RAG 只能通过对数据库中的一个或几个数据记录的点查找来回答相关的查询。这种方法专注于直接从数据库中检索特定信息点，而不涉及更复杂的数据处理或分析。

然而，对于商业用户来说，他们的问题通常需要复杂的领域知识、世界知识、精确计算和语义推理的组合。

为了解决这一问题，该研究提出了 TAG 系统，其实现主要包含三个步骤：查询合成、查询执行和答案生成。

TAG 模型很简单，但功能强大，由以下三个方程定义：

值得注意的是，TAG 模型统一了之前的方法，包括 Text2SQL 和 RAG，它们仅代表了 TAG 的特殊情况并且仅能解决有限的用户问题子集。

查询合成

首先，LM 推断哪些数据与回答问题相关，并将输入转换为该数据库的可执行查询（不仅仅是 SQL）。

其中，syn 函数接受自然语言请求 𝑅 并生成要由数据库系统执行的查询 𝑄。对于给定的用户请求，此步骤负责 (a) 推断哪些数据与回答请求相关，以及 (b) 执行语义解析以将用户请求转换为可由数据库系统执行的查询。此查询可以使用任何查询语言。论文示例中使用了 SQL。

如图 1 所示，该查询的问题是「总结票房最高的被认为是经典的爱情电影的评论」。在这里，数据源包含有关每部电影的名字、收入、类型和相关评论的信息。在此步骤中，系统利用 LM 的语义推理能力来生成 SQL 查询，该查询使用来自数据源的电影标题、评论、收入和类型的属性。

查询执行

在查询执行阶段，exec 函数在数据库系统中执行查询𝑄，获取表𝑇。此步骤利用数据库查询引擎对大量存储的数据进行有效地查询。

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

答案生成

在这一步中，gen 函数使用 LM 生成用户自然语言请求 R 的答案 A。

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

实验及结果

表 1 显示了每种方法的精确匹配准确率和执行时间。如表所示，在选定的 BIRD （一个数据集，用于测试 LMs 的文本到 sql 的能力）查询类型中，研究者发现手写 TAG（hand-written TAG）基线始终能达到 40% 或更高的精确匹配准确率，而其他基线的准确率均未超过 20%。

具体而言，Text2SQL 在所有基线上的表现都不佳，执行准确率不超过 20%，但在 Ranking 查询上的表现尤其糟糕，准确率只有 10%，因为许多 Ranking 查询需要对文本进行推理。Text2SQL + LM 在各个基线上的表现都同样糟糕，但在基于匹配和比较的查询上表现更差，准确率只有 10%。

对于 RAG，可以看到它在所有查询类型中都不能正确回答单个查询，这表明 RAG 不适合这个领域的查询。

手写 TAG 总体上正确回答了 55% 的查询，在比较查询中表现最佳，精确匹配准确率为 65%。由于精确排序商品的难度较高，该基线在所有查询类型（排名查询除外）中的表现始终良好，准确率超过 50%。总体而言，与标准基线相比，此方法的准确率提高了 20% 至 65%。

表 2 表明，由于省略了答案生成步骤，vanilla Text2SQL 在需要 LM 推理的查询上表现较差，精确匹配准确率为 10%。与此同时，RAG 基线和 Retrieval + LM Rank 基线在所有查询类型上都表现不好，只能正确回答一个查询。相比之下，手写 TAG 基线在需要知识的查询和需要推理的查询上都实现了超过 50% 的准确率。

值得注意的是，除了提供卓越的准确率外，手写 TAG 方法还提供了高效的实现，与其他基线相比，执行时间少用了 1/3。手写基线对所有查询的平均耗时为 2.94 秒。

最后，该研究定性分析了每个基线在聚合查询上的结果。图 2 为一个示例展示，查询的内容为「提供有关雪邦国际赛车场的比赛资料」。

结果显示，RAG 基线只能提供有关部分比赛的信息，因为大多数相关比赛都无法被检索到。另一方面，Text2SQL + LM 基线无法利用 DBMS 中的任何信息，仅依赖于参数知识并且不提供进一步的分析。

相比较来说，手写基线提供了 1999 年至 2017 年在雪邦国际赛道举行的所有比赛的详尽摘要。

^{参考链接：}

^{https://venturebeat.com/data-infrastructure/table-augmented-generation-shows-promise-for-complex-dataset-querying-outperforms-text-to-sql/}

工程表格增强生成