大语言模型(LLMs)的发展日新月异,为表格理解任务带来了新的可能性。表格理解任务,如基于表格的问答和表格事实验证,要求从自由形式的文本和半结构化的表格数据中提取深层次的语义信息。与泛化的文本推理任务不同,表格数据的复杂性对推理任务提出了更高的要求。
目前,研究者们主要探索了两种技术路线来应用LLMs于表格理解任务。
- 针对表格数据类型对LLMs进行领域适配,以更好地支持表格数据的理解。
- 直接使用预训练的通用LLMs,并借助一些额外手段(如Prompt技巧、工具使用等)来完成表格理解任务。
1、方法概览
直接使用预训练LLMs进行表格数据理解的技术路线主要有两种主流做法。第一种是基于文本推理的直接方式,将全量表格数据以一定分隔符的方式标记,作为Prompt的一部分输入LLMs,并结合Prompt技巧,直接对问题进行文本推理。第二种是基于符号推理的间接方式,将表格的结构信息(如表头、数据样例等)输入Prompt,根据任务需求指导LLMs编写一定的代码(如SQL、Python等),并调用对应的工具执行代码,得到想要的结果。
1.1、文本推理的方式
1.1.1、GPT4Table
GPT4Table提出了一种全新的benchmark,并在此基础上验证了ChatGPT在各个子任务上的效果。研究团队提出了self-augmentation的Prompt技巧,进一步提升了理解效果:
- 首先让LLM输出一些对表格数据的理解作为额外的知识
- 将这些额外的知识加入到之前的问题prompt里,用于生成最终的答案
他们将表格数据的结构理解能力分为两大类:
- 区分出表格数据(从文本中定位出哪些内容表示的是表格数据)及解析表格数据(从各种类型,包括XML、CSV、XLSX等,中解析出表格数据的能力)
- 搜索(根据值进行位置搜索/根据位置定位到单元格值)和检索(根据行列信息找到对应的值)
他们设计并对比了一系列Prompt方式进行文本推理进行表格数据理解任务的能力,得出了一些结论和技巧。
- 不同分隔符的差异:在prompt中使用HTML语言表示数据,能普遍取得比简单分隔符表示数据更好的效果。
- one-shot相比zero-shot效果提升明显:尤其是对于一些高度依赖结构解析能力的任务。
- Prompt顺序的影响:添加的外部信息的prompt放在表格数据之前比放在之后会更好。
- 有关Partition mark和format explanation的prompt可能损失搜索/检索相关的能力
论文原文
1.1.2、Rethinking Tabular Data Understanding with LLM
这篇论文深入研究了LLMs如何感知表格结构,以及如何确保它们在面对结构变化时的鲁棒性。文中提出了一种针对数据表的规范化方法,以增强表格数据应对结构变化(如转置、乱序等)的鲁棒性。同时,文中还对文本推理方式常见的出错类型进行了分析,指出文本推理方式最大的挑战在于正确地解释表格。
论文原文或解读文章。
1.2、符号推理的方式
相较于文本推理,基于符号推理的研究以及尝试会更加丰富多样。可以分成单轮推理和多轮推理两大类。单轮推理是利用LLMs生成代码时,期望只生成一份代码就能够完整回答用户的问题,而多轮推理则是采用类似CoT的思想,寄希望于LLMs强大的逻辑推理能力,让LLMs每次只完成一个小的功能,从而一步步地完成问题。
1.2.1、单轮推理
单轮推理的主要实现方式是使用ReAct的思想指导LLMs生成一段代码并运行来得到答案。此外,PandasAI是一个开源的表格数据问答框架,它支持使用类似dataframe的语法进行数据问答。OpenAgents中的data agent提供了搜索、处理、操作、可视化等方面的数据能力。
1.2.1.1、简单Prompt
这篇论文就提出了使用ReAct的思想指导LLM生成一段python代码并运行,最后得到答案的方式。详细的Prompt如下。
同时分析出符号推理最大的挑战是在于生成错误的代码,导致代码本身无法运行或者得到错误的结果。
1.2.1.2、PandasAI
PandasAI主要的实现方式是单轮的符号推理,使用固定的模版代码框架,同时支持自定义工具函数,让LLM生成数据处理的代码并执行得到运算结果。同时支持多种不同的输出类型(包括纯文本输出、DataFrame输出、图表等)。此外,针对生成的代码可能会报错的问题,PandasAI设计了修改代码的流程,一旦发生语法错误,会将python解释器的报错也一起加入prompt,进行retry,默认的retry次数是三次。
1.2.1.3、OpenAgents
OpenAgents中的data agent使用ReAct的思想,根据现有的数据和问题,选择合适的工具(Python或者SQL)以及代码生成的Prompt模板(如可视化就使用Echarts的代码生成模版,数据处理就用普通的代码生成模板)进行代码生成和结果回答。同时也会根据Observation的结果判定当前是否能够正确回答用户问题,如果能够正确回答就返回结果,不能则重复以上流程。
1.2.2、多轮推理
多轮推理采用的是类似CoT的思想,让LLMs每次只完成一个小的功能,从而一步步地完成问题。TaskWeaver是微软开源的代理框架,用于无缝规划和执行数据分析任务。Chain-of-Table提出针对一个表格问答问题,可以在每步动态地根据当前表格内容、已选择的操作历史、用户的问题,动态地确定下一步应该采用什么样的操作,从而一步步地递进对表格进行处理,得到最终的答案。
1.2.2.1、全局规划
TaskWeaver这种创新框架通过代码片段解释用户请求,并以函数的形式有效协调各种插件,以有状态的方式执行数据分析任务。
该框架会事先利用LLM进行任务和计划拆分,然后针对每个sub-task去生成不同的代码去执行得到中间结果,最终得到答案。
1.2.2.2、动态生成计划
- Chain-of-Table
整体来看,随着需要的推理步数的增加,意味着问题复杂度的增加,各种方法的效果都会有所下降。Chain-of-Table似乎比其他的常规方法更加稳健,即便是在操作步数适当增加的情况下,其性能下降也比较小。这意味着Chain-of-Table可能更加有利于处理实际世界中复杂多变的表格推理问题,因为它可以在问题难度升高时,保持较为稳定的性能表现。
论文原文或详细解读。
- ReAcTable
和Chain-of-Table类似,ReAcTable框架是以迭代的方式逐步对表数据进行变换,每一步输入当前表数据及用户查询,采用ReAct的思想,让LLM有个观察-思考-行动的过程,判断选择使用SQL工具、Python工具进行数据转换或者是直接给出回答。
论文原文或详细解读
1.3、融合方法
单次LLM的输出结果往往不一定可靠,为了提高表格数据问答的准确性,很多方法都会设计一定的技巧对多次输出的结果进行融合(其实就是机器学习中的Bagging思想)。采用一定的融合方式能够提升LLM在数据问答任务上的精度,但同时也大幅度增加了模型调用的成本,在做实际应用时要根据具体场景做取舍。
1.3.1、投票
ReAcTable方法中提出了三种投票方式,并进行了一系列比较。得出的结论是简单的多数投票法就能取得不错的融合效果,其他更复杂的投票方式(如Tree-exploration voting、Execution-based voting方式)也能达到和多数投票类似的效果。
1.3.2、借助大模型进行整合
这篇论文为了有效结合文本推理和符号推理两种方法的优势,研究者们提出了两种融合策略,并对它们进行了比较。
- 自我评估(Self-Evaluation),它利用LLM来对文本推理和符号推理的结果进行选择,从中确定一个最终答案。这种方法依赖于LLM的判断能力,以决定哪种推理方式更可靠。
- 混合自我一致性(Mix Self-Consistency),它结合了自我一致性和自我评估的思路。具体来说,文本推理和符号推理各独立产生五个可能的结果,然后将这十个结果进行投票,以决定最终的答案。这种方法不仅利用了LLM的判断力,还通过多数投票来增加结果的稳定性。
实验结果表明,混合自我一致性方法在提高答案准确性方面表现更佳,因此,这种方法已经被纳入llamaindex中,以供实际应用中使用。
2、挑战与研究方向
应用于实际场景的一些挑战包括如何应对复杂的问题、如何进行多表的联合分析、准确率不够、运行效率/成本等如何权衡。下一步的研究方向包括借鉴RAG等技术增强对领域知识的理解能力,提高问答效果,以及分析的可靠性保证等。
参考资料
- GPT4Table: Can Large Language Models Understand Structured Table Data?
- https://github.com/gventuri/pandas-ai
- https://github.com/xlang-ai/OpenAgents
- Rethinking Tabular Data Understanding with Large Language Models
- Chain-of-Table: Evolving Tables in the Reasoning Chain for Table Understanding
- ReAcTable: Enhancing ReAct for Table Question Answering
- TaskWeaver: A Code-First Agent Framework代码