Google新研究：适用于百万级单元格的TableRAG

发布时间：2024 年 10 月 07 日

RAG Text2Code NL2Code

TableRAG: Million-Token Table Understanding with Language Models

近期，语言模型在处理表格数据方面取得了显著进展，主要得益于程序辅助机制的引入，这些机制能够操纵和分析表格数据。然而，这些方法往往需要整个表格作为输入，这带来了位置偏差和上下文长度限制导致的可扩展性问题。为此，我们推出了 TableRAG，一个专为表格理解设计的检索增强生成框架。TableRAG 通过查询扩展与模式和单元格检索相结合，能够在提供信息给语言模型之前精准定位关键数据，从而实现更高效的数据编码和精确检索，大幅缩短提示长度并减少信息丢失。我们还从 Arcade 和 BIRD-SQL 数据集中创建了两个新的百万标记基准，以全面测试 TableRAG 的性能。实验结果显示，TableRAG 的检索设计在大规模表格理解任务中表现卓越，达到了业界领先水平。

https://arxiv.org/abs/2410.04739

picture.image

如遇无法添加，请+ vx: iamxxn886

另外请周二晚上文章免费赠书活动的三位幸运读者私信联系我快递地址

我们尽快为您安排《RAG》书籍快递

基于LLM的TableQA存在的问题

利用LLM来进行表格理解任务往往会将整个表格喂给LLM，但是这种方法存在一定的局限性：

• 首先，受限于LLM上下文长度的限制；比如，一个包含100列和200行的中等大小表格，单元格数量超过40,000个，超出了LLaMA和GPT系列等流行LMs的处理能力。
• 此外，过长的上下文可能会削弱推理能力，比如：Lost-in-the-Middle。
• 最后，随着表格尺寸的增加，计算成本和延迟也会显著上升。

所以，直接将表格全部喂给LLM这种方案不适合与大型表格。

因此，有人提出一些新的方案用于大型表格的理解任务，如截断表格或仅读取表格的Schema，但是这种方法往往会丢失关键信息。

以及，通过检索关键行和列来构建一个包含回答查询所需基本信息的子表，将整行和整列编码成稀疏或密集的嵌入，以减少LMs的标记成本。这种方法有两个问题：

• 1.对于包含数百万单元格的大型表格来说并不现实。
• 2.将长行和列压缩成固定大小的嵌入可能会丢失语义信息，尤其是当表格包含多样化或语义上不太丰富的内容时（例如，数值）。

什么是TableRAG

基于以上问题，Google Deepmind等团队联合提出了TableRAG方法。TableRAG融合了模式检索与单元格检索，从表格中提取出核心信息，使得LLM智能体能够依据这些信息解答查询。

picture.image

上图展示了TableRAG与传统表格理解任务的区别。

(a) - (d)：分别表示4种方法在提示词中包含的数据（阴影部分），其中（d）是TableRAG方法：

• (a) 完整读取表格 ：LM读取整个表格，在大型表格中往往不现实。
• (b) 只读取Schema ：LM只读取列名和数据类型组成的模式，这种方法会导致表格内容丢失。
• (c) 行-列检索 ：将行和列编码后，基于与问题相似度进行检索。只有行和列的交集被展示给LM。对于大型表格来说，编码所有行和列仍然不现实。
• (d) Schema-单元格检索 （TableRAG）：根据与LM生成的问题相关性，对列名和单元格进行编码和检索。只有检索到的Schema和单元格被提供给LM，从而在编码和推理上都提高了效率。

(e) 在ArcadeQA数据集上的检索结果显示: TableRAG在列和单元格检索方面均优于其他方法，进而增强了后续的表格推理过程。

2.1 TableRAG的核心组件

picture.image

上图是TableRAG的核心工作流程：问题通过语言模型扩展为多个模式和单元格查询。这些查询依次用来检索Schema和列-单元格配对。每个查询的前K个候选项汇总成提示词提供给LLM生成对应答案。

2.2 表格查询扩展

高效处理表格的关键在于精确地识别出查询所需的列名和单元格值 。与传统的表格理解任务不同的在于，TableRAG单独为Schema和单元格分别生成独立查询。比如：

对于问题“钱包的平均价格是多少？”，通过LLM生成针对列名如“产品”和“价格”的潜在查询，以及针对相关单元格值如“钱包”的查询。这些查询用于从表格中检索相关的模式和单元格值。

2.3 Schema检索

生成查询后，Schema检索通过预先训练的编码器fenc 获取相关的列名，fenc会对查询进行编码，并与编码的列名进行匹配以确定其相关性。检索到的Schema数据包括列名、数据类型和示例值。

将列转换为整数、浮点数或日期时间数据类型；如果这几种类型都不适合的话，保留为分类列。

• 对于被识别为数值或日期时间数据类型的列，将最小值和最大值作为示例值。
• 对于分类列，展示频率最高的三个类别作为示例值。

汇总每个查询的前K个检索结果，并根据它们与最接近查询的相似度进行排序。检索到的Schema提供了表格格式和内容的结构化概览，用于更精确的数据提取。

2.4 单元格检索

Schema检索后，提取回答该问题所需的特定单元格值。

单元格检索的作用在于：

• 单元格识别：使LLM能够精确地检测表格中特定关键词的存在。例如，区分“tv”和“television”，确保搜索和操作基于精确的数据条目。
• 单元格-列关联：使LLM能够将特定单元格与其相关的列名关联起来。对于处理特定属性的问题至关重要，如将“钱包”直接与“描述”列关联，实现行索引。

单元格检索在需要通过单元格值进行索引时特别有用。例如：

要回答“平均价格是多少？”的问题，只需识别与价格相关的列名，因为平均值的实际计算可以由程序处理。

2.5 编码预算下的单元格检索

在最坏的情况下，不同值的数量可能与单元格的总数相匹配（即全表都用来喂给模型）。为了在这种情况下保持TableRAG的可行性，引入了一个单元格编码预算B。如果不同值的数量超过B，将编码限制在出现频率最高的B对，从而在处理大型表格时提高效率。

编码预算仅影响单元格检索过程。即使某个单元格未包括在检索中，只要通过模式检索或其他单元格知道了其列名，后续求解器仍然可以访问该单元格。

picture.image

如上图所示，“description”列包含自由格式文本，可能导致大量独特的值，许多可能因单元格编码预算而被截断。然而，只要求解器识别了该列，它仍然可以对该列执行操作以提取所需信息。

在获得与问题相关的列名和单元格值之后，LLM可以使用这些信息有效地与表格交互。TableRAG与可以以编程方式与表格交互的语言模型智能体兼容。

智能体使用了ReAct框架，上图展示了TableRAG如何使用ReAct。

2.6 Token复杂性

调用LLM的效率和延迟很大程度上取决于输入token的数量。

假设列名、单元格值和问题的长度均为O(1)。其中，N代表行数，M代表列数，D代表不同文本单元格值的数量，B代表单元格编码预算，K代表顶级检索结果的数量。

主要表格提示方法的token复杂性如下表：

picture.image

• 读取表格：将整个表格提供给语言模型，导致推理过程中需要O(NM)数量的令牌。
• 读取Schema：只向语言模型提供模式，仅需O(M)数量的令牌，但会丢失表格内容的信息。
• 行-列检索：将所有行和列编码到嵌入中，导致编码过程中需要O(NM)数量的令牌。然后它检索前K个行和列以构建一个K×K的子表进行推理，其复杂性为O(K^2)。

对TableRAG中每一步的token复杂性进行分析：

• 表格查询扩展：对语言模型的提示主要基于问题，通常只包含少量词汇，因此这部分的令牌复杂性为O(1)。
• 构建Schema数据库：每个列名都使用编码器函数fenc进行编码，导致编码器的令牌复杂性为O(M)。
• 构建单元格数据库：这一操作涉及使用fenc编码不同的列-值对。当超过限制时，不同对的总数D被限制在B以内。因此，构建单元格数据库的令牌复杂性为O(min(D, B))，确保处理最频繁的数据以优化性能。
• 语言模型推理：查询扩展过程通常产生大约3-5个查询，这些查询的复杂性为O(1)。每个查询随后检索前K个结果，导致语言模型提示中包含的列和单元格值的总复杂性为O(K)。这一步确保语言模型只处理表格中最相关的信息，从而提高生成响应的效率和有效性。

总体而言，由于通常M远小于B和D，TableRAG的令牌复杂性在编码时为O(min(D, B))，在推理时为O(K)，且两者均不依赖于表格的整体大小。因此，TableRAG即使面对大型表格，也能保持可控的成本，优化计算资源和大规模表格理解任务的响应时间 。

效果如何？

3.1 回答准确性

picture.image

上表展示了测试结果，TableRAG在ArcadeQA和BirdQA上的所有语言模型中均一致超越其他方法，准确率最高。

读取全表的方法在这两个数据集上的表现均不佳，表明它在长上下文中存在劣势。

在三种语言模型中，GPT 3.5 Turbo无论采用哪种表格提示方法，都能稳定提供最佳性能。

3.2 检索性能

picture.image

上表评展示了召回率、精确度和f1分数。

• 在列检索方面，由于列数较少，所有方法都实现了较高的召回率，但TableRAG在两个数据集上都展现了更高的精确度，这表明它在快速识别最相关列方面非常有效。
• ReadSchema和RowColRetrieval的精确度较低，说明这两个方法检索到了更多不相关的列。
• 在单元格检索方面，TableRAG在所有指标上均持续超越其他方法。TableRAG在单元格检索上的高召回率与其他表格提示方法相比有了显著提升，表明它能够检索到后续推理所需的大多数单元格。总

3.3 伸缩性测试

为了探究在相似条件下不同表格大小对性能的影响，基于TabFact创建了一系列合成数据，表格尺寸从50×50到1000×1000不等。

picture.image

• 如上图所示，ReadTable在初始数据上表现强劲，随着表格尺寸的增加，其准确性急剧下降，在表格尺寸达到100及以上时变得不可行，这是由于上下文长度的限制。
• TableRAG展现了最为稳定和可伸缩的性能，即使在表格尺寸增加到1000行和列时，其性能也只是适度下降，从83.1%降至68.4%，证明了其在处理大型表格方面的有效性。
• ReadSchema和RowColRetrieval随着表格尺寸的增加也显示出性能下降，但仍然保持了一定的准确率，这表明它们相对于ReadTable具有较好的可伸缩性，但在处理大型表格方面不如TableRAG有效。