利用 LLM 增强表格数据分析

利用 LLM 增强表格数据分析

1. 简介

在快速发展的数据处理和分析领域，大型语言模型 (LLM) 处于领先地位，提供超越传统文本应用程序的突破性功能。一个特别有趣且较少探索的领域是使用 LLM 解释和推理表格数据。本博客深入探讨了利用 LLM 查询表格数据的复杂性，这是一个小众但功能极其强大的应用程序，有望改变我们与结构化数据集的交互方式。

我们探索的核心是两项创新技术：LlamaIndex 和 LocalAI。LlamaIndex 体现了最新论文“使用大型语言模型重新思考表格数据理解”和“表格链：表格理解推理链中的表格演变”中概述的原则，是我们探索的关键工具。它巧妙地实施了这些论文中的策略，使理论变得切实可行。作为 LlamaIndex 的补充，LocalAI 提供了一个无缝的环境，可以在本地启动和与 LLM 交互。这种协同作用不仅使高级数据查询方法的访问变得民主化，而且还将 LLM 的可用性推向了新的高度。

本博客旨在揭秘并演示 LLM 在使用人类语言查询表格数据中的用途。我们将踏上一段全面的旅程，展示使用 LocalAI 的 docker 镜像启动本地 LLM 的过程，并将它们与 OpenAI 兼容的 API 服务进行交互。我们的冒险不只是理论上的；我们将提供动手演示，在 docker 容器中设置整个系统，适用于仅配备 CPU 和配备 GPU 的机器。

2.理论背景

表格数据领域具有结构化和复杂性，为法学硕士带来了独特的挑战和机遇。在本节中，我们将根据两篇论文深入探讨理论基础，为我们的实践探索奠定基础。

“重新思考使用大型语言模型来理解表格数据”

本文是理解 LLM 在解释表格数据方面的能力和局限性的基础。它从三个核心角度进行：

1. 对结构扰动的鲁棒性：研究表明，当面对表格中的结构变化时，LLM 的性能会明显下降。这一见解至关重要，因为它凸显了对可以在表格格式发生变化的情况下保持准确性的稳健模型的需求。
2. 文本推理与符号推理：文本推理与符号推理的比较分析表明，文本推理在处理表格数据方面略有优势。然而，每种方法的优势因具体任务而异，这表明这些推理方法的应用有细微差别。
3. 通过推理路径提高性能：也许最重要的贡献是提出聚合多种推理路径。通过整合文本和符号推理并采用混合自洽机制，该模型实现了最先进的性能。这种方法不仅提高了准确性，而且为 LLM 中更复杂的表格处理范例铺平了道路

“表链：在推理链中不断发展的表格，以实现表格理解”

本文介绍了 Chain-of-Table 框架的创新概念，彻底改变了 LLM 与表格数据的交互方式：

1. 推理链中的表格数据：本文建议将表格数据明确纳入推理链。这种方法与主要依赖文本上下文的传统方法形成鲜明对比，提供了一种利用表格结构化特性的新方法。
2. 迭代表演化：该框架引导 LLM 迭代生成操作并更新表，有效地创建“表格推理链”。这种动态演化使模型能够根据先前的结果规划后续操作，从而反映出更像人类的推理过程。
3. 结构化的中间结果：这种方法的一个有趣之处在于演化表如何承载中间结果的结构化信息。这不仅使推理过程透明化，而且还提高了预测的可靠性和准确性。

理论与实践的桥梁

这些论文共同构成了一个强大的理论框架，指导我们在查询表格数据时实际应用 LLM。它们阐明了表格数据处理的细微差别，强调了对具有适应性、能够进行复杂推理并对表格的结构化格式敏感的模型的需求。随着我们在本博客中继续前进，这些理论见解将成为我们使用 LlamaIndex 和 LocalAI 进行实际演示的基础。

3.技术背景

LlamaIndex 及其骆驼包

LlamaIndex 是一个多功能的“数据框架”，对于构建 LLM 应用程序至关重要。它简化了从各种来源和格式（包括 API、PDF、文档和 SQL）提取数据的过程。该框架擅长使用索引和图表构建数据，确保与 LLM 无缝兼容。其主要功能之一是高级检索和查询界面，允许用户输入 LLM 提示并接收上下文丰富的响应。

Llama Packs 是对 LlamaIndex 的补充，它是一个社区驱动的中心，提供一系列预打包的模块，可帮助您快速启动 LLM 应用程序开发。这些模块专为各种应用程序而设计，从创建 Streamlit 应用程序到促进简历中的高级检索和结构化数据提取。Llama Packs 的一个主要功能是它为用户提供的灵活性，使他们不仅可以导入模块以供立即使用，还可以检查和自定义模块以满足特定需求和偏好。

LocalAI框架

LocalAI 是 OpenAI 的免费开源替代方案，为寻求本地推理功能的用户提供独特的解决方案。它充当无缝插入式替代 REST API，完全兼容 OpenAI 的 API 规范。LocalAI 旨在运行大型语言模型 (LLM)、生成图像和制作音频等功能，其应用范围十分广泛。值得注意的是，LocalAI 支持多种模型系列和架构，并且无需 GPU 即可有效运行。

4. 实际演示

演示环境

有关配置 AWS EC2 CPU 或 GPU 实例以在 Docker 容器中运行本地 LLM 的指导，请参阅此博客。

在 AWS CPU 实例上运行

为了在 AWS CPU 实例上启动演示，这里有一个简明的分步指南可帮助您入门：

1. 将此 repo 克隆到您的 EC2 CPU 实例：

git clone https://github.com/LinkTime-Corp/llm-in-containers.git克隆https://github.com/LinkTime-Corp/llm-in-containers.git 

cd llm-in-containers/tabular-data-analysis

2. 将您的 OpenAI API 密钥插入 conf/config.json 中的“OPENAI_API_KEY”。如果您不想针对 OpenAI 后端进行评估，可以跳过此步骤。
3. 下载本地模型。如果您在使用 wget 命令时遇到问题，可以从此链接手动下载模型并将其保存在“models”目录中。

bash 下载-models.sh

4.启动演示：

运行

5.访问http://{EC2 CPU 实例的IP}:8501的UI。

6. 关闭演示。

关机命令

打开 Web 用户界面

现在让我们通过上传一些示例数据来试用一下 UI：

1. 访问提供的链接下载一组示例 CSV 文件。解压下载的文件。对于演示，我们将使用位于“WikiTableQuestions/csv/200-csv/11.csv”的文件。
2. 进入 UI 后，首先上传一个 CSV 文件，例如您刚刚解压的文件。选择“LLM 类型”来处理您的查询。您可以在“ChatGPT”和“Local_LLM”之间进行选择。
3. 选择查询表格数据文件的引擎。有两个选项：“ MixSelfConsistency ”和“ ChainOfTable ”。
4. 完成这些选择后，您现在可以询问与 CSV 文件中的数据相关的问题。例如，“谁获得了 1972 年最佳男演员奖？”。单击“查询”按钮提交您的问题并从所选的 LLM 获得答案。
5. 在用户界面的侧边栏上，有一个选项可以查看 LLM 推理轨迹。此功能可让您查看 LLM 对您的问题的逐步处理，从而深入了解答案的得出方式。

用于查询 CSV 文件的 Web UI

在 AWS GPU 实例上运行

要在 AWS GPU 实例上启动演示，这里有一个简明的分步指南可帮助您入门。它类似于 CPU 实例设置，但在“run.sh”和“shutdown.sh”脚本中添加了“-gpu”标志：

1. 将此 repo 克隆到您的 EC2 GPU 实例：

git clone https://github.com/LinkTime-Corp/llm-in-containers.git克隆https://github.com/LinkTime-Corp/llm-in-containers.git 

cd llm-in-containers/tabular-data-analysis

2. 将您的 OpenAI API 密钥插入 conf/config.json 中的“OPENAI_API_KEY”。
3. 启动演示：

bash 运行.sh-gpu

4. 访问http:// {EC2 GPU 实例的 IP} :8501处的 UI 。
5. 关闭演示。

bash关机.sh-gpu

5.代码结构

该演示的代码结构设计简单直观，不同的组件组织到单独的文件中，以提高清晰度和易于维护：

• main.py：此文件包含用户界面（UI）的代码。
• backend.py：负责处理选择LLM和查询引擎的逻辑以及与LLM交互。
• constants.py：整个代码库中使用的所有常量都在这里定义。

6. 揭示查询引擎的机制

在演示中，我们使用了“WikiTableQuestions/csv/200-csv”示例数据集中名为“11.csv”的 CSV 文件。此 CSV 文件包含下表所示的结构化表格数据。让我们探索查询引擎如何回答“哪位提名者获得了 1972 年奥斯卡最佳男演员奖？”这个问题。

演示中使用的 CSV 文件

6.1 “MixSelfConsistency”查询引擎

“MixSelfConsistency”引擎通过循环两种不同类型的查询路径来运行，这些路径可以根据迭代进行配置。这两条路径被称为**“文本推理”和“符号推理”**。

“文本推理”路径

这条路径很简单。它通过将 CSV 文件的内容直接集成到提示中来运行，从而形成一个综合查询，然后呈现给 LLM。由于我们运行了三次这条路径，因此我们得到了结果列表：

[‘吉恩·哈克曼’，‘吉恩·哈克曼’，‘吉恩·哈克曼’]。

“符号推理”路径

此路径使用 LlamaIndex 的 PandasQueryEngine。此查询引擎将 CSV 文件加载到 pandas 数据框中，然后针对给定的问题生成 panda 指令以获取结果。对于演示，我们获得了三个 pandas 指令，每个指令对应于三个迭代运行中的一个。

第一次运行：

df[(df['奖项'] == '1972 年奥斯卡金像奖') & (df['类别'] == '最佳男演员') & (df['结果'] == '获奖')]['提名人']

第二次运行：

df[(df['奖项'] == '1972 年奥斯卡金像奖') & (df['类别'] == '最佳男演员') & (df['结果'] == '获奖')]['提名'].iloc[0]

第三次运行：

df[(df['奖项'] == '1972 年奥斯卡金像奖') & (df['类别'] == '最佳男演员') & (df['结果'] == '获奖')]['提名人']

因此结果列表为：

[ 
    '2 Gene Hackman\n姓名：提名人，dtype：对象', 
    'Gene Hackman', 
    '2 Gene Hackman\n姓名：提名人，dtype：对象' 
]

自洽聚合

最后一个过程汇总了“文本推理”和“符号推理”生成的组合列表中出现的项目的计数。然后返回计数最高的项目。在我们的演示中，出现计数最高的项目（表明它是最有可能的答案）是“Gene Hackman”。

优点和缺点

“MixSelfConsistency”查询引擎通过融合文本和符号推理并利用混合自一致性机制来提高准确性。但是，对这些查询路径进行多次迭代可能会导致整体响应时间更长。

6.2 “ChainOfTable” 查询引擎

“ChainOfTable”引擎首先采用一系列操作将原始表格修改为直接解决查询的格式。随后，它将修改后的表格与问题结合起来，形成提示，使 LLM 能够得出最终答案。最后一个阶段与“MixSelfConsistency”引擎中的“文本推理”路径相似。

表操作链

让我们深入研究其构建操作链的方法。在每次迭代中，引擎都会提示 LLM 建议下一个操作，同时考虑当前表状态和先前操作的历史记录。潜在的操作包括：

1. f_add_column()：此函数用于添加新列，尤其是当表需要额外的推断数据才能准确响应查询时。
2. f_select_row()：当只有特定行与问题相关时，使用此操作来隔离并关注这些行。
3. f_select_column()：与行选择类似，此函数将表的焦点缩小到被认为回答查询所必需的某些列。
4. f_group_by()：对于涉及具有相同值及其计数的项目的查询，此操作对这些项目进行分组，从而增强数据呈现的清晰度。
5. f_sort_by()：如果查询涉及列中项目的顺序或排名，此函数会根据问题的上下文对项目进行排序。

演示案例

回到我们的演示，让我们重新审视一下查询“哪位提名者获得了 1972 年奥斯卡金像奖最佳男演员奖？”。作为响应，“ChainOfTable”引擎在其第一次迭代期间执行操作 f_select_row([‘row 3’])。此操作将创建一个新表，其结构如下：

f_select_row([‘row 3’]) 的结果

最终的查询变得简单明了，直接得出最终答案：“吉恩·哈克曼”。

优点和缺点

“ChainOfTable”引擎创建了一系列操作，将原始表格转换为更符合最终问题的版本。这种方法显著提高了原始表格无法立即显示答案的查询的准确性，因此需要一系列表格操作来澄清问题。但是，此过程要求每次与 LLM 交互时都将当前表格的内容纳入提示中。这种方法可能会影响 LLM 的性能，尤其是在处理大型表格时，因为数据的大小会直接影响处理负载。

6.3 性能比较

在我们的查询引擎演示中，每次执行查询都会提供两个关键信息：查询引擎的响应和生成该响应所需的时间。从我们在演示中使用 CSV 文件的实验中，我们观察到当选择 ChatGPT 作为 LLM 时，“MixSelfConsistency”引擎往往比“ChainOfTable”引擎更快、更准确。

但需要注意的是，这些发现并非来自系统的基准测试或对两个查询引擎的全面比较。我们提到的结果完全基于我们有限的实验。因此，它们应该被视为初步观察，而不是明确的结论。

我们鼓励对此领域感兴趣的个人使用我们的演示作为更广泛的比较或基准测试的起点。

7. 其他要点

与法学硕士 (LLM) 互动

此演示中实现的一个关键方面是建立与用于查询 LLM 的 API 的连接。这包括设置与 ChatGPT 的 OpenAI API 以及与本地 LLM 的类似 API 的连接。以下是代码的第一部分：

self.openai_llm = OpenAI（模型=OPENAI_API_MODEL）
self.local_llm = OpenAILike（
   api_base=API_BASE，
   api_key=API_KEY，
   模型=MODEL_NAME，
   is_chat_model= True，
   is_function_calling_model= True，
   context_window= 3900，
   超时=MAC_M1_LUNADEMO_CONSERVATIVE_TIMEOUT，
）

除了上述代码之外，为这些 LLM 设置 ServiceContext 也很重要，尤其是对于本地 LLM。对于本地 LLM，它涉及使用来自 Huggingface 的本地 embed_model（来自此 文档，本地 embed_model 指的是“BAAI/bge-large-en”）：

如果llm_type == GPT_LLM：
   chosen_llm = self.openai_llm 
   embed_model = OpenAIEmbedding（embed_batch_size= 10）
   service_context = ServiceContext.from_defaults（
       chunk_size= 1024，llm=chosen_llm，embed_model=embed_model）
否则：
   chosen_llm = self.local_llm 
   service_context = ServiceContext.from_defaults（
       chunk_size= 1024，llm=chosen_llm，embed_model= “local”）
   set_global_service_context（service_context）  

上述实现是可行的，但在不同 LLM（例如 OpenAI 和本地 LLM）之间切换时，灵活性和易用性并不理想。在理想的设置中，像“OpenAI”或“OpenAILike”这样的类应该能够与 OpenAI 模型和本地 LLM 建立连接。只需为这些兼容 API 指定“api_base”和“api_key”即可实现这一点。

正如 LlamaIndex 所解释的那样，OpenAILike 类是 OpenAI 模型的薄包装器。其目的是确保与提供 OpenAI 兼容 API 的第三方工具兼容。然而，由于 LlamaIndex 目前限制使用其 OpenAI 类中的自定义模型，因此出现了一个限制，这主要是因为需要从模型名称中推断某些元数据。

这一限制凸显了未来需要优化实现。这样的增强将使用户能够轻松地集成和切换不同的 LLM，无论是 OpenAI 还是本地 LLM。

OpenAI 兼容 API 服务

决定使用 OpenAI 兼容 API 服务作为应用程序和 LLM 之间的中介是战略性的，旨在增强模块化和灵活性。这种方法允许无缝交换 LLM，而无需更改应用程序的代码，从而减轻直接集成可能产生的兼容性问题。这样的设置可确保应用程序与它们交互的特定 LLM 保持无关，从而更轻松地进行更新和维护。

在选择合适的 API 服务的过程中，我们最初的选择是 GPT4all Rest API。众所周知，GPT4All 是一款不错的工具，它通过在标准硬件上启用 LLM 来实现对 LLM 的民主化访问。但是，目前 GPT4all Rest API 与当前的 OpenAI API 规范不兼容，因此我们无法切换后端 LLM 服务。随后，我们评估了 LocalAI，事实证明它与 LlamaIndex OpenAILike 类兼容且运行有效。这种兼容性对于我们的要求至关重要，证明了 LocalAI 遵守当前规范并能够与我们的框架顺利集成。

管理 Docker 镜像的大小

选择在 Docker 容器中运行我们的演示是因为 Docker 为 LLM 应用程序提供了众多优势，例如增强的可移植性、可重复性、可扩展性、安全性、资源效率和简化的部署流程。然而，在为我们的演示构建 Docker 镜像的过程中，我们观察到安装 PyTorch 后镜像大小显著增加。为了解决这个问题并减少 CPU 实例的 Docker 镜像大小，我们选择直接从http://download.pytorch.org/whl/cpu 上的官方 wheel 安装 PyTorch：

pip 安装 --no-cache-dir -r requirements.txt \ 
    --extra-index-url https://download.pytorch.org/whl/cpu

这种方法显著减少了压缩后镜像的大小，仅为 435.06 MB，而 GPU 实例的压缩后镜像大小则大得多，为 5.38 GB。采用此策略对于那些希望专门为 CPU 实例构建镜像的人来说尤其有效，可以在功能和效率之间取得平衡。

8.Github链接：

http://download.pytorch.org/whl/cpu:)

pip 安装 --no-cache-dir -r requirements.txt \ 
    --extra-index-url https://download.pytorch.org/whl/cpu

这种方法显著减少了压缩后镜像的大小，仅为 435.06 MB，而 GPU 实例的压缩后镜像大小则大得多，为 5.38 GB。采用此策略对于那些希望专门为 CPU 实例构建镜像的人来说尤其有效，可以在功能和效率之间取得平衡。

8.Github链接：

https://github.com/LinkTime-Corp/llm-in-containers/tree/main/tabular-data-analysis

博客原文：专业人工智能社区