大型语言模型理解表格的三条路径

照片由 Rene Böhmer 拍摄，来自 Unsplash.

LLM（如其名称所示）最初是为了处理文本格式的非结构化数据。但它们能否应用于结构化信息，理解、提取和转换表格中的数据？答案是“可以，但……”。让我们一起来看看这个问题。在这篇文章中，我们将探讨三个主要问题的答案：

1. 在将表格数据输入LLM之前如何进行转换？
2. 如何创建上下文和提示？
3. 应该使用什么类型的框架？

当然你会看到很多例子哦！

我将根据Fang等人写的一篇精彩文章《大型语言模型在表格数据上的研究：预测、生成及理解——综述》（2024）来回答这个问题，我非常推荐这篇文章给那些想深入了解这个话题的人。该综述将现有的研究分为三大类表格数据的序列化技术。

• 基于文本的方法，
• 基于上下文嵌入的方法，
• 基于图的方法和基于树的方法，

以下是一些基于文本的序列化方法：

• DFLoader（Pandas DataFrame加载器） — 直接将Pandas DataFrame用作LLM的输入（Singha等人（2023）），

• JSON — 将数据表转换为JSON格式（Singha等人（2023）；Sui等人（2023b）），

• Data Matrix — 转换为数据矩阵（Singha等人（2023）），

• Markdown — 将表格转换为Markdown格式，这是非常流行的方法之一（Singha等人（2023）；Liu等人（2023e）；Zhang等人（2023d）；Ye等人（2023b）；Zhao等人（2023d）；Sui等人（2023b）），

• X-Separated — 将表格转换为X分隔的值形式，其中X可以是合适的分隔符，如制表符或逗号（Singha等人（2023）；Narayan等人（2022）），

• 属性值对 — 转换为属性值对形式，如 name:helen ; age:47 （Wang等人（2023c）），

• HTML — 转换成HTML格式（Singha等人（2023）；Sui等人（2023c；b）），

• 句子 — 转换为类似 “名字是helen，年龄是47” 的文本（Yu等人（2023）；Hegselmann等人（2023）；Gong等人（2020））。

或者可以使用从预训练的LM中微调而来的表格编码器，将表格数据编码成数值表示，作为LLM的输入。这里有一些使用这种编码器的例子。

• BERT（TAPAS（Herzig 等，2020），TABERT（Yin 等，2020b），TURL（Deng 等，2022a），TUTA（Wang 等，2021），TABBIE（Iida 等，2021），UTP（Chen 等，2023a）），
• 或 大模型（LLMs）（UniTabPT（Sarkar & Lausen，2023）（基于 T5 和 Flan-T5 模型），TableGPT（Gong 等，2020）（基于 GPT-2），TableGPT2（Zha 等，2023）（基于 Phoenix（Chen 等，2023b）模型））。

最后，第三个但较少使用的选项是将表转换成树或图。然而，在使用序列到序列的模型时，这些结构仍需转换回文本。对于赵等人（[2023a]），在将表格转换为树之后，每个单元格的层级结构、位置信息和内容都被表示成一个元组，并输入GPT3.5。

到底选哪种序列化技术呢？

在数据科学领域，像往常一样，没有简单的答案，必须通过实验来选择最适合数据、模型和任务的方案。但其他研究者提出了一些考虑：

• 辛哈等人（2023）发现，对于事实核查和表格转换，DFLoader 和 JSON 表现最佳，
• 随等人（2023a）指出，对于GPT的表格问答和FV任务，使用HTML或XML格式会更好，
• 随等人（2023b）还指出，特别是HTML，在GPT3.5和GPT4上超过了分隔格式数据（如CSV）的表现。他们认为，GPT模型是在大量网络数据上训练的，因此这些模型在训练过程中可能更多地接触到了HTML和XML格式的表格。

我建议先试着用DFLoader和HTML做些实验，不过，根据我的经验，DFLoader在强大的模型（如大型语言模型）上表现非常出色。记住，转换成HTML意味着传递给LLM的token数量会增多，这不仅会增加成本，还会导致上下文限制问题。

我们来看看提示工程相关的第二个问题吧。

当我们把表格数据作为上下文传递给提示时，我们立刻会遇到上下文大小限制的问题。一些模型的上下文窗口较短，你的表格可能无法完全放进。即使可以容纳，大模型在处理长序列时效率不高，更关注窗口的开始或结束部分。当然，更多的令牌会增加成本。

并没有直接的解决方案。一些研究（Herzig等人（2020）；Liu等人（2022c））建议简单地截断表格这种方法在实际操作中几乎没有意义。另一些研究则试图通过额外的工具，首先选择相关的表格、行或列来进行处理。例如Sui等人（2023c）、cTBLS Sundar 和 Heck （2023）、Dong等人（2023）的相关示例。

不过这里有一些关于提示工程的实用技巧。

• 包含关于表格（结构和统计信息）的附加信息（隋等人 (2023c))。
• 使用上下文学习（一-shot 或两-shot 学习方法对模型有好处（陈 (2023))）。
• 试验Chain-of-Thought、Self-Consistency等技术（例如，Chain-of-Thought、Self-Consistency 等技术）和角色模拟（赵等人 (2023a))）。

我们最后一个问题与建模单元有关。我们有一些选择。

• 基于数字的问答 是仅包含一个大语言模型的框架，意味着我们将直接向模型提问，例如“美国运通每笔交易的平均支付量是多少？”（赵等人，2023d）。在这样的框架中，GPT-4的表现优于开源模型，
• 基于操作的问答 是一个包含额外步骤的框架，需要决定使用何种操作、表格、行或列。例如，我们将要讨论的表格链框架（王等人，2024），
• Text2SQL：SQL生成在业界很受欢迎，有许多开源的微调模型可供使用。

在下一节中，我们将比较三种方法。准备好了没，上手吧？

我们来比较一下这三种方法：Numeric QA、Operation-based QA 和 Text2SQL。电商数据集将由来自 Kaggle 的 e-commerce 数据集 提供，我将使用 GPT-4 来进行所有这些方法。方法。 我将使用 GPT-4 来进行所有这些方法。你可以在 GitHub 上找到包含完整代码的 Jupyter 笔记本。

为了比较这三种方法，我将在我会测试几种不同类型的问题上测试它们。

• 关于特定行的信息查询（例如，某个特定产品的宽度是多少？），
• 需要对一列进行聚合的查询（例如，所有产品的平均宽度是多少？），
• 需要根据条件筛选行的查询（例如，某个特定类别的产品有多少个？），
• 需要对表格进行排序的查询（例如，最重的三个产品是哪些？），
• 如果算法允许，我也会尝试合并表格。

请留意，我不会在一个足够大的样本上做彻底的测试，而只是看看几个问题，来快速了解这三种方式的潜力。

让我们来获取数据吧。

模型是这样的：

现在准备好了，我们可以开始试一试第一个方法。

我来创建一个一次性学习的提示，该提示包含两个参数——一个是用户的提问，另一个是作为上下文的数据框：

数值QA的功能将处理问题、数据集、模型、提示以及一个布尔参数to_html，因为我打算试验两种序列化方法——DF加载器和HTML：

我们来检查一下这四种类型的问题该如何解答。

注意，正如我们之前讨论过的，转换为HTML使上下文的长度变大，超出了GPT-4的上下文窗口的限制。

GPT-4 正确回答了最简单的问题，即检索特定产品ID的信息。有趣的是，将数据转换为HTML帮助模型子集划分行（例如问题“有多少类别为出口激光的产品？”）。但在处理其他类型的数据操作问题时，LLM 都失败了。

另一个缺点是缺乏透明度，让人无法理解模型是如何得出答案的过程。数据量也十分重要，增加上下文的大小也会提高成本和出错的概率。不过，从积极的一面来看，答案格式也很规范。

我很好奇几个月前王等人提出的链式表框架（2024年，文献链接：https://arxiv.org/pdf/2401.04398），想试一试。

王等人提出的链表解释（2024年）(2024)

这个想法听起来很吓人。一旦用户的问题提交给框架，它就会从操作集合中选择最合适的操作。可能的操作有排序、添加列、选择行和分组。然后，框架为选定的操作生成新的参数，例如新列的名称，并转换数据内容。接下来，它会检查是否需要进一步操作，或者任务是否已经完成。

让我们用ChainOfTablePack来测试这种方法。先拿到这个包，写一个函数，无需序列化数据。

现在我们来测试一下。该包对数据集大小有限制，所以我再次使用了一个子数据集。

该函数会逐步打印出解释，这些解释我在文章中截断了这些解释（查看该笔记本以查看完整输出），但从这些解释中可以看到，模型经常正确地执行了一些操作，如排序，但在选择正确行以回答问题时却失败了。最终，只有问题被精确地回答了。其他不足包括答案的格式、可使用的操作数量有限以及样本大小的限制性。

我觉得这个框架前景不错，但还有很多改进的空间。

用于理解表格的Text2SQL模式

最后，我们研究的明星是Text2SQL方法。其原理是将用户的提问转换为SQL语句并执行查询。必要时可以直接在数据库中执行查询。我希望答案格式更美观，因此我增加了一个步骤。通过LLM提示根据数据库回复生成答案（或见解）。

Text2SQL还有一个非常棒的功能，那就是可以合并表格！

首先，我创建了三个表格的描述文字。这一步骤是可选的，但在列名和表名不够说明时非常有帮助。

接下来，我创建了一个一次性提示语，将用户的问题转换为SQL语句：

一个将SQL查询结果转换成易于理解的答案的单次提示：

最后，Text2SQL包括三个步骤：1）将问题转换为SQL查询，2）查询SQLite数据库中的信息，3）根据数据、问题和查询生成一个友好的答案。

我们来试试Text2SQL，

太棒了！所有的问题都回答正确了，甚至那些需要合并两个或三个表的问题也不例外！这种方法完全透明，我们可以获取每个中间步骤的信息，而且所有答案都因第二次模型调用而格式化得很好。上下文窗口限制仅适用于数据描述字符串，对于非常大的数据库来说，这可能才会成为一个问题。你可以查看这个笔记本文件以获取完整代码。

无需对数据进行序列化处理：在第一次LLM调用时，模型根本看不到数据；而在第二次调用时，来自数据库的表通常很小，DFLoader在这里表现得不错。无论如何，需要注意那些SQL查询返回大数据样本的情况，以避免高昂的LLM使用成本。

结尾

大型语言模型主要用于处理非结构化数据，它们直接应用于表格数据的情况仅限于非常简单的任务。如果需要任何表格操作（如采样、聚合、排序或合并），我建议使用Text2SQL方法，根据任务的不同，可能需要一到两次大型语言模型的调用。