Text2SQL还不够: 用TAG统一人工智能和数据库

今天分享一篇来自伯克利和斯坦福大学的研究论文，题目很直接：

。简单翻译就是——仅仅靠Text2SQL远远不够，我们需要用TAG（表增强生成）把AI和数据库真正统一起来。

论文地址：https://arxiv.org/pdf/2408.14717
代码仓库：https://github.com/TAG-Research/TAG-Bench

摘要

说到Text2SQL，目前主流的方法其实都绕不开一个局限——它们只能搞定那些能用关系代数表达的问题。但现实是，用户问的问题远远不止这些。检索增强生成（RAG）虽然能处理一些通过查找单条或少数记录就能回答的查询，但它的能力天花板也很明显。

为了打破这些束缚，这篇论文提出了

——一个统一且通用的方法论，专门用来覆盖语言模型（LM）与数据库之间那些尚未被充分探索的交互方式。TAG模型的核心思路，是利用语言模型已有的知识和推理能力来处理数据，这为研究如何更好地调动这些能力提供了全新的机会。

为了系统性地研究TAG问题，作者还开发了一套专门的benchmark。结果发现：现有的标准方法在正确回答查询方面能力非常有限，正确率甚至不到20%。这个发现本身就说明，这个领域迫切需要更多深入的研究。

主要方法

表增强生成（TAG）方法定义了三个关键步骤，整体流程如下图所示。

1. 查询合成（Query Synthesis）
   ：系统需要从用户的自然语言请求中合成出一个能在数据库上执行的查询语句。这包括理解用户意图，并将其转换为合适的数据库查询格式。

2. 查询执行（Query Execution）
   ：查询合成完成后，下一步就是实际执行查询，从数据库里高效地获取相关数据。这一步依赖后端数据库管理系统来完成。

3. 答案生成（Answer Generation）
   ：最后一步是生成最终答案。语言模型（LM）会利用原始请求和查询结果，可能通过迭代或递归的方式处理数据，最终以自然语言的形式输出答案。

查询合成

在TAG框架中，syn函数负责接收用户的自然语言请求，并生成一个数据库系统可以执行的查询。这个步骤要完成两件事：

• 推断哪些数据与回答请求相关
  （利用表结构）。比如在示意图的例子中，系统需要识别出哪些表或列包含电影名称（movie_title）、收入（revenue）、类型（genre）以及相关评论（review）等信息，判断哪些字段对回答问题是必要的。

• 进行语义解析
  ，把用户的请求翻译成数据库系统能执行的查询。这个查询可以是任何查询语言的形式。举个例子，如果用户问“总结票房最高的被认为是‘经典’的爱情电影的评论”，那么系统就得借助语言模型的语义推理能力，生成一个SQL查询，涉及电影标题、评论、收入和类型等属性。

查询执行

在查询执行步骤中，exec函数负责在数据库系统中执行查询，获取表格数据。示意图里展示的是一个用SQL编写的选取和排序查询——它利用语言模型判断哪些电影根据名称应被视为“经典”，再用过滤器筛选出爱情类型，然后按收入排序找出票房最高的。最终结果表格里包含了电影《泰坦尼克号》的评论。为了支持SQL查询和基于LLM的运算符（如基于LLM的过滤、排名和聚合），论文使用了Lotus API来支撑查询执行。

答案生成

TAG的答案生成步骤和RAG中的生成步骤有些相似。在这个步骤里，gen函数利用语言模型，根据计算得到的数据来生成对用户自然语言请求的回答。如图1所示，TAG管道的最后阶段输出了对《泰坦尼克号》评论的总结，作为对最初用户请求的回应。在这个例子里，相关数据被编码成字符串格式，以便模型处理。编码后的表格连同原始请求一起传递给语言模型。

实验

实验结果表明，TAG在精确匹配准确率上表现相当出色——达到了40%的准确率，而所有其他基线方法都没有超过20%。这说明TAG在处理自然语言查询到数据库的问题上有明显的优势。

• Text2SQL基线
  ：表现较差，精确匹配准确率不超过20%。特别是在需要排序的查询上，准确率只有10%，因为很多排序查询需要对文本进行推理。

• Text2SQL + LM生成基线
  ：表现同样不佳，尤其在基于匹配和比较的查询上准确率只有10%。原因是执行SQL后将大量行数据输入模型时，出现了上下文长度错误。

• RAG基线
  ：未能正确回答任何查询，明显暴露出它在处理这类查询时的短板。

• Retrieval + LM Rank基线
  ：仅在一个比较查询中正确回答了一个问题，总体表现依然垫底。

• TAG
  ：整体正确回答了55%的查询，在比较查询上达到了65%的精确匹配准确率。除排序查询外，它在所有查询类型上都保持了超过50%的准确率。

除了准确率更高，TAG在执行时间上也占优势——平均每个查询耗时2.94秒，比其他基线快最多3.1倍。举个例子，对于聚合查询，TAG能够提供从1999年至2017年在Sepang国际赛道举行的全部比赛的详尽总结。相比之下，RAG基线只能提供部分相关比赛的信息，而Text2SQL + LM基线则完全无法利用数据库管理系统中的信息，只能依赖参数知识，无法给出进一步分析。

实验中使用的是手写TAG（通过Lotus框架人工编写查询）。值得关注的是，其他方法在复杂问题上的准确率较低，很大程度上仍然与Text2SQL本身的准确性有关。所以，虽然LLM4DB相关任务不只有Text2SQL，但Text2SQL的准确性依然是核心问题。