1. 基于LLM的TableQA存在的问题
利用LLM来进行表格理解任务往往会将整个表格喂给LLM，但是这种方法存在一定的局限性：
• 首先，受限于LLM上下文长度的限制；比如，一个包含100列和200行的中等大小表格，单元格数量超过40,000个，超出了LLaMA和GPT系列等流行LMs的处理能力。
• 此外，过长的上下文可能会削弱推理能力，比如：Lost-in-the-Middle。
• 最后，随着表格尺寸的增加，计算成本和延迟也会显著上升。
所以，直接将表格全部喂给LLM这种方案不适合与大型表格。
因此，有人提出一些新的方案用于大型表格的理解任务，如截断表格或仅读取表格的Schema，但是这种方法往往会丢失关键信息。
以及，通过检索关键行和列来构建一个包含回答查询所需基本信息的子表，将整行和整列编码成稀疏或密集的嵌入，以减少LMs的标记成本。这种方法有两个问题：
• 对于包含数百万单元格的大型表格来说并不现实。
• 将长行和列压缩成固定大小的嵌入可能会丢失语义信息，尤其是当表格包含多样化或语义上不太丰富的内容时（例如，数值）。
2. 什么是TableRAG
基于以上问题，Google Deepmind等团队联合提出了TableRAG方法。TableRAG融合了模式检索与单元格检索，从表格中提取出核心信息，使得LLM智能体能够依据这些信息解答查询。
上图展示了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的核心组件
上图是TableRAG的核心工作流程：问题通过语言模型扩展为多个模式和单元格查询。这些查询依次用来检索Schema和列-单元格配对。每个查询的前K个候选项汇总成提示词提供给LLM生成对应答案。
2.2 表格查询扩展
高效处理表格的关键在于精确地识别出查询 所需的列名和单元格值 。与传统的表格理解任务不同的在于，TableRAG单独为Schema和单元格分别生成独立查询。比如：
对于问题“钱包的平均价格是多少？”，通过LLM生成针对列名如“产品”和“价格”的潜在查询，以及针对相关单元格值如“钱包”的查询。这些查询用于从表格中检索相关的模式和单元格值。
2.3 Schema检索
生成查询后，Schema检索通过预先训练的编码器获取相关的列名，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有效。
3.4 与WikiTableQA上最先进技术的比较
如上表所示，TableRAG超越了所有现有方法，包括TaBERT 、Text-to-SQL 、Binder 和Dater 。表明TableRAG即使在小规模环境中也具有有效性。
尽管TableRAG旨在应对大规模TableQA任务，但其方法具有通用性，并能在不同规模和复杂性的表格上保持最先进水平的性能。
3.5 消融研究
3.5.1 TableRAG中检索方法的影响
上表比较了TableRAG内部不同的检索方法。
• BM25：著名的基于统计的检索方法，效率上表现出色，能够处理所有单元格，但缺乏语义理解能力。
结果表明：基于嵌入的检索方法性能最佳，超越了BM25和混合方法，尽管由于编码限制它并未处理整个表格。
3.5.2 检索结果数量K的影响
上图展示了改变顶级检索结果(K)数量对性能和后续语言模型推理的令牌成本的影响。
结果表明：增加K的数量增加了提示长度，但并未一致地提升性能。
较大的K值虽然允许语言模型访问更多信息，但也导致了更长的上下文，可能加剧“Loss in the middle”现象。
TableRAG通过减少K值的需求，降低了所需的上下文令牌数量，减少了后续推理的成本，同时仍然超越了其他方法。
3.5.3 编码预算的影响
上图展示了不同的token编码预算(B)如何影响TableRAG和RowColRetrieval的性能。
虽然更高的预算理论上允许检索更多信息，但结果表明这并不总是导致更好的性能。特别是，随着预算的增加，RowColRetrieval的性能有所下降，可能是因为检索到的更多行使得选择正确的行变得更加复杂，并产生了来自更长列序列的噪声嵌入。
TableRAG在不同预算下保持了一致的性能，表明其通过单元格频率构建语料库的方法即使在有限的预算下也能有效地捕获基本信息。
3.5.4 查询扩展的影响
上图分析了查询扩展方法的有效性。结果表明：查询扩展一致地提升了TableRAG在不同数据集和语言模型中的性能。
3.5.5 模式检索和单元格检索
上表分析了Schema检索和单元格检索对性能的影响。
• 模式检索在不同数据集和语言模型中一致地提升了推理性能，最大提升了9.4%，无论是否考虑单元格值。
• 即使对于列数较少的表格（ArcadeQA中平均20.5列，BirdQA中平均11.1列），模式检索仍然有助于只为后续推理提供相关列。
• 单元格检索在所有数据集和语言模型中一致地提高了准确性，最大提升了11.5%，表明单元格检索可以从表格内容中有效地提取关键信息。
• 论文原文:
本文转载自，作者：