斯坦福、伯克利大学新思路：TAG，结合了Text2SQL和RAG的新设计范式，效果更好、速度更快

发布时间：2024 年 08 月 26 日

RAG

Text2SQL is Not Enough: Unifying AI and Databases with TAG

AI 系统通过自然语言查询数据库，潜力巨大。它们结合了语言模型的推理能力与数据管理系统的计算优势，使用户能自由查询自定义数据。但现有技术与评估标准未能充分挖掘这一潜力。Text2SQL 和 RAG 方法各自局限，前者仅处理关系代数可表达的问题，后者则限于点查找能解答的简单查询。为此，我们推出了表增强生成（TAG），一个全新的通用框架，旨在探索语言模型与数据库间更广泛的交互，并开辟了新的研究领域。我们创建了 TAG 基准测试，结果显示传统方法仅能正确回答不到 20%的查询，凸显了深入研究的迫切需求。基准代码已公开于https://github.com/TAG-Research/TAG-Bench。

https://arxiv.org/abs/2408.14717

picture.image

如遇无法添加，请+vx iamxxn886

背景

大语言模型出色的理解能力，使得使用自然语言来处理数据问题成为可能，这也可能带来数据管理领域的变革。这又进一步促进了Text2SQL和检索增强生成（RAG）方法在数据管理领域的研究。

但事实上，根据作者的经验，用户的问题，往往超出了现有研究范式的能力，这就需要投入精力研究，打造能够将数据库系统的逻辑推理能力与大语言模型的自然语言推理能力相结合的系统。

实际业务用户的问题通常需要领域知识、世界知识、精确计算和语义推理的复杂融合。显然，数据库系统凭借其存储的数据以及精确计算能力（这是大语言模型的短板），提供了领域知识的来源。

而，大语言模型又扩展了现有数据库的能力：

• 首先，LMs 具备语义推理能力，这是众多自然语言用户查询的核心要素。比如，Databricks 的客户调查表明，用户希望提出像“产品 X 的哪些客户评论是积极的？”或者“为什么我这段时间的销售额下降了？”这类问题。这些问题呈现出复杂的基于推理的任务，比如对自由文本字段的情感分析或者趋势总结。LMs 非常适合处理这些任务，而传统数据库系统中的精确计算或关系原语无法应对。
• 其次，借助在模型训练期间学习并由模型权重隐性存储的知识，LM 能够以数据库表没有包含的知识扩充用户数据。例如，Databricks 的内部 AI 用户询问“零售垂直领域的季度环比趋势是什么？”针对包含账户名称、产品和收入等属性的表。要回答这个查询，系统必须理解业务如何定义“季度环比”，以及哪些公司被视为属于“零售垂直领域”。此任务很适合利用预先训练或微调的 LM 所掌握的知识。

能够高效地将数据库和 LMs 结合起来服务于自然语言查询的系统，有可能改变用户理解其数据的方式。遗憾的是，如今这些问题无法通过常见方法（如 Text2SQL 和 RAG）来解决。

虽然 Text2SQL 方法适用于具有直接关系等价物的自然语言查询的子集，但它们难以处理需要语义推理或世界知识的大量用户查询。

例如，前面用户询问“哪些客户评论是积极的”可能需要对评论进行逻辑的逐行 LM 推理 ，以将每条评论归类为积极或消极。同样，询问“为什么销售额下降”的问题涉及一个推理问题，必须汇总众多表条目的信息。

另一方面，RAG 模型仅限于对数据记录进行简单相关性的查找，随后进行 LM 调用。此模型仅能服务于可通过点查找回答的查询子集，并且无法利用许多数据库系统更丰富的查询执行能力，这就把计算任务（例如，计数、数学运算和筛选）留给了容易出错的 LM 的调用。

除了在计算任务中容易出错且效率低下之外，LMs 还被证实在长上下文提示方面表现欠佳 。

所以作者提出“表增强生成（Table-Augmented Generation，TAG）”作为回答数据库上自然语言问题的系统的统一设计范式。

什么是TAG？

picture.image

具体来说，TAG 定义了三个关键步骤，如上图所示。

• 查询合成（Query Synthesis）：首先，查询合成步骤 syn 将用户的任意自然语言请求R转化为可执行的数据库查询Q 。
• 查询执行（Query Execution）：然后，查询执行步骤 exec 在数据库系统上执行 Q以高效地计算相关数据 T。
• 答案生成（Answer Generation）：最后，答案生成步骤 gen 利用 R和T ，其中 LM 可能以迭代或递归的模式 在数据上进行编排，以生成最终的自然语言答案。

TAG 模型整合了 Text2SQL 和 RAG，Text2SQL和RAG代表了 TAG 的特殊情形 ，并且仅能服务于用户问题的有限子集。

TAG 模型

2.1. 查询合成（Query Synthesis）

syn 函数接收自然语言请求，并生成可供数据库系统执行的查询。

对于给定的用户请求，此步骤负责：

• （a）推断哪些数据与回答请求相关（比如，利用表模式）
• （b）进行语义解析，将用户请求转化为能被数据库系统执行的查询。这个查询可以是任何查询语言，比如：SQL。

picture.image

上图展示了针对用户“总结被视为‘经典’的票房最高的浪漫电影的评论”这一查询的 TAG 实例化示例。

在这里，数据源包含每部电影的标题、收入、类型以及相关评论等信息。

系统借助语言模型的语义推理能力生成一个使用数据源中“movie_title”、“review”、“revenue”和“genre”属性的 SQL 查询。请注意，在此示例中，数据库 API 能够在 SQL 查询中执行语言模型的用户自定义函数（UDF），所以此步骤还为每一行引入对语言模型的调用 ，以在查询中识别经典电影。

2.2. 查询执行（Query Execution）

在查询执行 步骤中，exec 函数在数据库系统中执行查询以获取表。

借助数据库查询引擎在大量存储的数据上执行查询，数据库 API 可以由各种各样的系统提供服务。

数据库查询是用 SQL 编写的选择和排序查询，返回一个包含相关行的表。

利用语言模型根据“movie_title”评估哪些电影是经典电影来进行选择，并通过“genre”上的标准过滤器查找浪漫电影。

还依据“revenue”对结果进行排序，以找出票房最高的电影。

2.3. 答案生成（Answer Generation）

TAG 中的答案生成步骤与 RAG 中的生成步骤差不多。

gen 函数利用语言模型根据计算的数据为用户的自然语言请求生成答案。

picture.image

如上图，将“泰坦尼克号”评论的摘要作为对原始用户请求的答案输出。相关数据被编码为字符串以供模型处理。编码后的表与原始用户请求一同传递给语言模型。

TAG 设计思路

3.1 查询类型

TAG 模型能够服务于各式各样的自然语言用户查询。

依据（a）回答查询所需的数据聚合程度，以及（b）回答查询所需的知识与能力，对查询进行了两种重要分类。

• 首先，TAG 模型既涵盖了点查询，比如需要对数据库的一行或几行进行查找的基于检索的问题，也包括了聚合查询，例如需要对数据库多行进行逻辑推理的总结或基于排名的问题。
• 其次，TAG 模型支持对系统提供数据或基于推理的能力有不同需求的自然语言查询，涵盖了像情感分析和分类之类的任务。

3.2 底层的数据模型形式多样

借助关系数据库来存储和检索结构化属性，以便在下游的问答任务中实现知识落地。

其他的可能在非结构化的数据（比如自由文本、图像、视频和音频）或半结构化数据上运行，这些数据可能采用各种数据模型进行存储，例如键值、图形、向量、文档或对象存储。

3.3 数据库执行引擎和 API

用于存储数据的底层系统能够运用众多可能的数据库执行引擎。

• Text2SQL：基于 SQL 的查询引擎的设置，用于为用户查询检索关系数据。syn 会利用数据源的知识，比如表模式，并返回一个 SQL 查询来执行检索步骤。
• 基于向量嵌入的检索系统：syn 将自然语言查询转换为嵌入，并在向量存储上执行基于相似度的检索。
• 基于API：此外，像 MADLib、Google 的 BigQuery ML 以及 Microsoft 的 Predictive SQL 这类查询语言通过原生的基于 ML 的函数来增强基于 SQL 的 API。

3.4 LM 生成模式

面对丰富的数据表，可以通过众多的执行决策来构建生成模式，以生成对用户请求的自然语言答复。

Text2SQL跳过了最终的生成阶段，在执行查询后便告一段落；

RAG流程则通常采用单一的智能体调用生成实现，将相关数据嵌入到上下文中。

效果评估

作者引入首个 TAG 基准，旨在解答以下问题：

• 1. 现有的表格问答方法在应对需要语义推理或世界知识的查询时表现如何？
• 2. TAG 模型的手写实现（将计算和推理步骤分布于 DBMS 和 LM 操作之间）在这些查询中的表现怎样？

4.1 测试基准

4.1.1 Text2SQL

LM 生成 SQL 代码，运行以获取答案。对于给定的 NL 查询，使用与 BIRD测试数据集工作相同的提示格式构建一个包含查询域中每个表的表模式的 LM 提示。通过在 SQLite3 中执行生成的 SQL 代码并统计错误答案的数量（包括模型无法生成有效 SQL 代码的情况）。

4.1.2 检索增强生成（RAG）

针对表格检索的 RAG 方法已经有前人进行了尝试，将表格数据嵌入到索引中以进行搜索。这里作者采用行级嵌入。给定的行在嵌入到 FAISS 索引之前，对于每个列都被序列化为“- col: val”。在查询时，执行向量相似性搜索以检索 10 个相关行，将其与 NL 问题一起作为上下文提供给我们的模型。

4.1.3 检索 + LM 排名

通过利用 LM 为检索到的行分配 0 到 1 之间的分数来重新排名行，然后将其输入到模型中，从而扩展了 RAG 基线，这与 STaRK 工作中的做法相同。

4.1.4 Text2SQL + LM

首先要求模型生成 SQL 以检索一组相关行来回答给定的 NL 查询。这与 Text2SQL 基线的重要区别在于，在 Text2SQL 基线中，模型被要求直接生成单独执行时就能为查询提供答案的 SQL 代码。与 RAG 基线类似，一旦检索到相关行，就将其作为上下文提供给模型。

4.1.5 手写 TAG

借助了表模式的专家知识，而非从自然语言请求到数据库查询的自动查询合成。使用 LOTUS 来实现手写 TAG 管道。

LOTUS API 允许程序员使用标准关系运算符以及语义运算符（如基于 LM 的过滤、排名和聚合）声明性地指定查询管道。LOTUS 还提供了优化的语义查询执行引擎，用它来实现我们手写 TAG 管道的查询执行和答案生成步骤。

4.2 评估结果

picture.image

上表展示了每种方法的准确性和执行时间。

• 手写 TAG ：始终能达到 40％或更高的精确匹配准确率，而其他所有基线的准确率均未超过 20％。
• Text2SQL：在所有基线上的表现都欠佳，执行准确率不高于 20％，在排名查询上尤其糟糕，准确率仅为 10％，因为许多排名查询需要对文本进行推理。
• Text2SQL + LM：在所有基线上的表现类似不佳，在基于匹配和比较的查询上表现更差，准确率仅为 10％。在这些查询类型上，在执行 SQL 后尝试向模型输入许多行时会出现几个上下文长度错误。
• RAG：在所有查询类型中都未能正确回答一个查询，凸显了RAG对这个领域查询的不足。
• 检索 + LM 排名：能够在比较查询中正确回答一个查询，但是仍然比除 RAG 之外的所有其他基线表现更差。

手写 TAG 基线总体上能正确回答 55％的查询，在比较查询中表现最佳，精确匹配准确率为 65％。该方法在除排名查询 之外的所有查询类型上都表现出色，准确率超过 50％，因为准确排序项目的难度较大。

picture.image

此外，上表展示了标准方法的弱点：

• 普通的 Text2SQL 尤其在需要 LM 推理的查询上表现糟糕，精确匹配准确率仅为 10％，因为它省略了答案生成步骤。
• 同时，RAG 基线和检索 + LM 排名基线在所有查询类型上都表现不佳，仅能正确回答一个查询，因为它们依赖 LM 来处理所有关于数据的精确计算。
• 手写 TAG 基线在需要知识和需要推理的查询上均达到了 50％以上的准确率，强调了 TAG 模型在其所涵盖的查询中的通用性。除了提供出色的准确率外，手写 TAG 方法还提供了一种高效的实现，执行时间比其他基线低多达 3.1 倍 。手写基线对所有查询的平均执行时间为 2.94 秒。这种相对较低的执行时间表明，可以通过利用 LMs 的高效批量推理来设计高效的 TAG 系统。
• Text2SQL + LM 无法利用 DBMS 中的任何信息，仅依赖参数知识，并且没有提供进一步的分析。
• 手写TAG 提供了 1999 年至 2017 年在雪邦国际赛道举行的所有比赛的全面总结。在基准提供的其他聚合查询中观察到类似的趋势，初步结果表明 TAG 系统成功聚合大量数据，提供丰富信息答案的潜力。

• 论文原文: https://arxiv.org/abs/2408.14717
• 获取更多最新 Arxiv 论文更新: https://github.com/HuggingAGI/HuggingArxiv!
• 加入社群，+v: iamxxn886
• 点击公众号菜单加入讨论

picture.image