简介

表格理解任务包括基于表格的问答、表格事实验证等。与泛化的文本推理任务不同，限于表格数据的复杂性，基于表格的推理任务需要从自由形式的文本和半结构化的表格数据中提取出深层次的语义信息，才能更好地完成表格理解任务。

随着大语言模型（LLMs）的飞速发展，很多研究者试图用LLM来帮助完成这一任务，并且取得了巨大的突破。本文尝试总结一些当前已有的尝试，并对未来的发展趋势做一些简单的探讨。

总的来看，LLM应用在表格理解任务上的探索大致有两条不同的技术路线：

一种是针对表格数据类型，通过训练/微调的方式对LLM做一些领域适配，使得它能够更好地支持表格数据的理解任务。
另一种是直接使用预训练的通用LLM，采用一些额外的手段（比如Prompt技巧、工具使用等）让LLM完成表格理解任务。

本文聚焦于探讨第二类技术路线涉及的一些方法。

1. 方法概览

直接使用预训练LLM进行表格数据理解的技术路线，目前有两种主流的做法。一种是基于文本推理的直接方式，将全量表格数据以一定的分隔符的方式标记，作为Prompt的一部分输入LLM，并结合一些Prompt技巧，直接对问题进行文本推理；另一种是基于符号推理的间接方式，将表格的结构信息（如表头、数据样例等）输入Prompt，根据任务需求指导LLM编写一定的代码（如SQL、Python等），并调用对应的工具执行代码，得到想要的结果。

以下围绕这两类实现方式做一些详细的方法介绍。

1.1 文本推理的方式

1.1.1 GPT4Table

GPT4Table论文中提出了一个全新的benchmark，并在此基础上验证了ChatGPT在各个子任务上的效果。同时，提出了self-augmentation的Prompt技巧，进一步提升了理解效果。

研究团队将表格数据的结构理解能力进行了拆分，分为两大类：

区分出表格数据（从文本中定位出哪些内容表示的是表格数据）及解析表格数据（从各种类型，包括XML、CSV、XLSX等，中解析出表格数据的能力）
搜索（根据值进行位置搜索/根据位置定位到单元格值）和检索（根据行列信息找到对应的值）

围绕这些设计的能力，文中设计并对比了一系列Prompt方式进行文本推理进行表格数据理解任务的能力。文中的一些结论和技巧如下：

不同分隔符的差异：在prompt中使用HTML语言表示数据，能普遍取得比简单分隔符表示数据更好的效果。
1-shot相比0-shot效果提升明显：尤其是对于一些高度依赖结构解析能力的任务，1-shot能够带来巨大的提升。
Prompt顺序的影响：添加的外部信息的prompt放在表格数据之前比放在之后会更好。
有关Partition mark和format explanation的prompt可能损失搜索/检索相关的能力

此外，作者提出了self-augmented prompting的技巧，提升了文本推理的效果。该prompt技巧分为两步：

首先让LLM输出一些对表格数据的理解作为额外的知识
将这些额外的知识加入到之前的问题prompt里，用于生成最终的答案

更多细节可以参考论文原文或笔者之前的解读文章。

1.1.2 Rethinking Tabular Data Understanding with Large Language Models

这篇论文对LLM如何感知表格结构，如何确保它们在面对结构变化时的鲁棒性等问题进行了深入的研究。提出针对数据表的规范化方法来增强表格数据应对结构变化（如转置、乱序等）扰动的鲁棒性。

优化后的文本推理方式能够在面对表的结构扰动时表现出极强的鲁棒性，在面对乱序、转置、转置+乱序的场景下都能取得和标准格式的表格数据类似的效果。

此外，文中还对文本推理方式常见的出错类型进行了分析，指出文本推理方式最大的挑战在于正确地解释表格。

同时，本文也讨论了基于符号推理的实现方式，并提出将文本推理和符号推理的方式结合，能够进一步提升表格理解的效果。关于这部分的内容详见下文的符号推理章节以及融合章节。

更多细节可参考论文原文及笔者之前的解读文章。

1.2 符号推理的方式

相较于文本推理，基于符号推理的研究以及尝试会更加丰富多样。按照推理的迭代次数来分类的话，可以分成单轮推理和多轮推理两大类。单轮推理会提示LLM一次性调用工具（如生成SQL、Python 代码）执行之后得到问题答案；多轮推理则会递进地一步步调用工具，对表格数据进行转换，将最后一轮的结果作为最终的答案。

1.2.1 单轮推理

这里所谓的单轮推理，并不是严格意义上的只会生成并运行一次代码，而值得是利用LLM生成代码时，期望只生成一份代码就能够完整回答用户的问题，而不需要通过step by step的方式每次向正确答案靠拢。当代码出现错误或者LLM判定到未能正确回答问题时，仍可能进行一些重试的操作来试图正确回答问题。

1.2.1.1 简单Prompt

这篇论文就提出了使用ReAct的思想指导LLM生成一段python代码并运行，最后得到答案的方式。详细的Prompt如下。

也取得了与文本推理接近的准确率。

同时分析出符号推理最大的挑战是在于生成错误的代码，导致代码本身无法运行或者得到错误的结果。

1.2.1.2 pandasai

pandasai是一个开源的表格数据问答框架，它支持使用类似dataframe的语法进行数据问答。其主要的实现方式也是单轮的符号推理，使用固定的模版代码框架，同时支持自定义工具函数，让LLM生成数据处理的代码并执行得到运算结果。同时支持多种不同的输出类型（包括纯文本输出、DataFrame输出、图表等）。此外，针对生成的代码可能会报错的问题，pandasai设计了修改代码的流程，一旦发生语法错误，会将python解释器的报错也一起加入prompt，进行retry，默认的retry次数是三次。

1.2.1.3 OpenAgents 的dataagents

OpenAgents中的data agent提供了搜索（快速定位数据）、处理（简化数据采集和处理）、操作（对数据进行修改）、可视化这几大方面的数据能力。

实现上，它也是使用ReAct的思想，根据现有的数据和问题，选择合适的工具（Python或者SQL）以及代码生成的Prompt模板（如可视化就使用Echarts的代码生成模版，数据处理就用普通的代码生成模板）进行代码生成和结果回答。同时也会根据Observation的结果判定当前是否能够正确回答用户问题，如果能够正确回答就返回结果，不能则重复以上流程。

1.2.2 多轮推理

多轮推理，采用的是类似CoT的思想，寄希望于LLM强大的逻辑推理能力，让LLM每次只完成一个小的功能，从而一步步地完成问题。关于详细的推理步骤，可以是事先进行全局规划，然后按照计划执行；也可以每个步骤单独根据当前的局部信息动态生成下一步的计划。

1.2.2.1 全局规划

TaskWeaver是微软开源的代理框架，用于无缝规划和执行数据分析任务。这种创新框架通过代码片段解释用户请求，并以函数的形式有效协调各种插件，以有状态的方式执行数据分析任务。

该框架会事先利用LLM进行任务和计划拆分，然后针对每个sub-task去生成不同的代码去执行得到中间结果，最终得到答案。

1.2.2.2 动态生成计划

Chain-of-Table

chain-of-table提出针对一个表格问答问题，可以在每步动态地根据当前表格内容、已选择的操作历史、用户的问题，动态地确定下一步应该采用什么样的操作，从而一步步地递进对表格进行处理，得到最终的答案。

论文中的各项实验结果也表明了该方法的有效性，尤其是这中递进推理的方式，的确增强了表格问答的效果。

整体来看，随着需要的推理步数的增加，意味着问题复杂度的增加，各种方法的效果都会有所下降。Chain-of-Table似乎比其他的常规方法更加稳健，即便是在操作步数适当增加的情况下，其性能下降也比较小。这意味着Chain-of-Table可能更加有利于处理实际世界中复杂多变的表格推理问题，因为它可以在问题难度升高时，保持较为稳定的性能表现。

更多详情可以参考论文原文及笔者的详细解读。

ReAcTable

和Chain-of-Table类似，ReAcTable框架也是以迭代的方式逐步对表数据进行变换，每一步输入当前表数据及用户查询，采用ReAct的思想，让LLM有个观察-思考-行动的过程，判断选择使用SQL工具、Python工具进行数据转换或者是直接给出回答。

各项实验结果也表明了这种层层递进方式的有效性，从下图的实验结果也可以看到和Chain-of-Table类似的结论。

迭代2次效果比迭代1次效果好
随着迭代次数继续增加，准确率在下降，这可能由于问题本身更复杂所导致。

更多详情可以参考论文原文及笔者的详细解读。

1.3 融合方法

单次LLM的输出结果往往不一定可靠，为了提高表格数据问答的准确性，很多方法都会设计一定的技巧对多次输出的结果进行融合（其实就是机器学习中的Bagging思想）。采用一定的融合方式能够提升LLM在数据问答任务上的精度，但同时也大幅度增加了模型调用的成本，在做实际应用时要根据具体场景做取舍。

1.3.1 投票

ReAcTable方法中提出了三种投票方式，并进行了一系列比较。得出的结论是简单的多数投票法就能取得不错的融合效果，其他更复杂的投票方式（如Tree-exploration voting、Execution-based voting方式）也能达到和多数投票类似的效果。

1.3.2 借助大模型进行整合

这篇论文为了将文本推理和符号推理两种路线的结果进行融合，提出了两种融合的方式并进行了比较。

Self-Evaluation
用LLM对文本推理和符号推理的输出结果进行二选一，确定最终结果。
Mix Self-Consistency
融合和self-consistency和self-evaluation的思想。文本推理和符号推理各输出5个结果，然后对这10个结果进行投票，确定最终结果。

实验结果表明，采用mix self-consistency能够取得更好地结果，相关的方法也被llamaindex收录进行了实现。

2. 一些思考

2.1 应用于实际场景的一些挑战

如何应对复杂的问题

目前的表格理解任务，可能就是关注一些通用的能力，如表格结构的理解、简单的数据定位/搜索等问题，面对一些需要复杂推理的问题，能力仍然远远不够，这点ReAcTable/Chain-of-Table里也进行了一些分析。要想真正在实际场景取得比较好的效果，还需要进一步提升LLM的推理能力。

如何进行多表的联合分析

当前的研究/尝试多数还是局限于针对单个数据表的分析，而实际的应用场景往往可能会涉及多个表之间的关联关系，有些问题可能需要联合多个表的信息才能有效回答。

目前来看，pandasai具备多表联合查询的能力，但是其实只是利用不同表的同字段名进行了join，本质上只是合成了一个大的宽表进行分析；如何应对更为复杂的情况还需要进一步探索。

准确率不够

目前，SOTA方法在多个数据集上的准确率大致在70%左右，距离能够让用户放心使用仍然存在一定差距。

运行效率/成本等如何权衡

许多研究采用一些融合的策略提升了回答问题的准确性，但是在实际应用场景中还需要考虑到成本和运行效率等因素，一味地通过融合方式提高精度也不可取。

2.2 下一步的研究方向

借鉴RAG等技术增强对领域知识的理解能力，提高问答效果

针对一些领域特定的场景，如果能将一些相关的背景知识通过RAG等技术与表格理解任务理解结合起来，或许能够有效提升推理能力。

分析的可靠性保证

对于每次的分析结果，能否采用一定的方式对本次回答的置信度进行评估，对于一些特殊的场景，就可以根据置信度的阈值，对可靠性低的结果做出诸如“我无法回答”、“我也不确定”之类的应答结果，避免误导用户。

整体规划与动态计划的整合

当前的方法要么就是事先制定计划之后就遵照执行，要么就是全部计划都是动态生成。是否能够结合这两种方式，先生成固定的计划，然后在执行的过程中根据实际情况对计划进行修改完善，从而提升推理的能力？

RexKing6's Note

LLM在表格数据理解任务中的应用思考

简介