大模型LLM | Google新研究：适用于百万级单元格的TableRAG

最新推荐文章于 2024-10-10 11:54:20 发布

沈页

最新推荐文章于 2024-10-10 11:54:20 发布

阅读量362

点赞数 9

文章标签：人工智能 AI大模型 ai LLM 大语言模型 agi 大模型

本文链接：https://blog.csdn.net/Androiddddd/article/details/142814711

版权

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

全套的AI大模型学习资源已经整理打包，有需要的小伙伴可以微信扫描下方CSDN官方认证二维码，免费领取【保证100%免费】

1. 基于LLM的TableQA存在的问题

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

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

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

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

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

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

2. 什么是TableRAG

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

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

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

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

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

2.1 TableRAG的核心组件

上图是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对，从而在处理大型表格时提高效率。

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

在这里插入图片描述

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

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

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

2.6 Token复杂性

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

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

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

• 读取表格：将整个表格提供给语言模型，导致推理过程中需要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. 效果如何？

3.1 回答准确性

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

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

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

3.2 检索性能

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

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

3.3 伸缩性测试

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

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