引言：大语言模型（LLMs）在各类文本任务上取得令人惊艳的效果。但在许多实际应用中，还存在大量结构化数据以存储规范化知识，例如知识图谱（KG），表格（Table），和数据库（Database）。本文想要探讨的问题是：大语言模型的能力边界能否扩宽到结构化数据，通过利用和理解结构化知识完成用户需求？我们的答案是：Yes！本文首次提出了一套统一通用的推理框架「StructGPT」以支持大语言模型在结构化数据上进行推理。并通过实验证明了其有效性和通用性。我们期待该方法为大语言模型落地各类实际应用提供灵感并促进大语言模型的进一步发展。
【StructGPT】已被 EMNLP-2023 Main Conference 正式接收，相关论文（最终版即将更新）和代码如下：
论文链接（提交版，正式版即将更新arxiv）：https://arxiv.org/pdf/2305.09645.pdf
开源项目：https://github.com/RUCAIBox/StructGPT
简介
本文研究了如何将大语言模型（LLMs）的通用能力扩宽到结构化数据场景，如知识图谱，表格，数据库。受到工具增强 LLMs 研究的启发，我们提出了一种迭代式阅读-推理（IRR）框架以支持 LLMs 在结构化数据上进行推理。在这套框架中，我们通过接口调用从结构化数据源收集相关证据（即阅读），并让 LLMs 基于收集到的信息推理求解用户需求（即推理）。基于这样一个指导思想，我们给出了一种具体方案，即 调用-线性化-生成，来支持 LLMs 在外部接口的帮助下基于结构化数据推理。通过使用提供的接口并迭代该方案，我们的方法可以让大语言模型逐渐接近给定查询的目标答案。在三种类型的结构化数据上进行了大量实验（共8个数据集），证明了该方法在 zero-shot 和 few-shot 场景下，均可显著提升 Davinci-003 以及 ChatGPT 的性能，并实现与全量监督模型相当的性能。
方法介绍
我们注意到结构化数据格式规范，并支持通过形式化语言或查询（称为通用接口）轻松访问。我们方法的基本思想是将 LLMs 的阅读和推理两个过程分离开来：首先利用结构化数据的接口实现精确、高效的数据访问和过滤（获取相关证据），并进一步利用 LLMs 的推理能力来确定问题的下一步需求或最终结果（求解任务）。通过这种方式， LLMs 可以集中精力完成求解推理，而不必考虑读取结构化数据的特定方法。具体而言，在我们的实现方法中，我们将结构化数据视为黑盒系统，并提供外部接口以支持结构化数据访问。此外，我们提出了一种调用-线性化-生成求解过程，使得 LLMs 可以通过相应的接口从结构化数据中读取和过滤有用的证据。通过使用提供的接口并迭代上述过程，我们可以利用LLMs的超强推理能力逐渐接近目标答案。下面依次介绍接口设计和调用-线性化-生成求解过程。
结构化数据接口设计
由于标准化的数据格式，结构化数据通常配备了高效的数据管理方式，例如数据库所使用的 SQL。在我们的方法中，我们旨在为大型语言模型提供基于这些结构化数据的专门接口，帮助它们读取和利用这些结构化数据。接下来，我们介绍针对知识图谱、表格和数据库专门设计的接口。
知识图谱接口：
def Extract_Neighbor_Relations(e):
'''extracts all the neighboring relations of the entity e.'''
def Extract_Triples(e, {r}):
'''extracts all the triples with the relation in {r} and head entity e.'''表格接口：
def Extract_Column_Name(T):
'''extracts all the column names of a table T.'''
def Extract_Columns(T, {c}):
'''extracts the contents of columns from a table T by indices {c}.'''
def Extract_SubTable(T, {c}, {j}):
'''extracts the sub-table specified by the column indices {c} and row indices {j} from a table T.'''数据库接口
def Extract_Table_and_Column_Name(D):
'''extracts the names of all the tables and their contained columns from the database.'''
def Extract_Tables_Information({T}):
'''extracts the table names, column names, and foreign keys from a set of tables {T}.'''请注意：该处的接口设计完全是可插拔的，用户可以根据自己的场景需求设计对应的结构化数据访
调用-线性化-生成
基于上述接口，我们提出了一种通用的调用-线性化-生成求解过程，可支持 LLMs 在多个回合中迭代使用接口在结构化数据上进行推理。每次迭代，基于当前收集的数据，我们首先调用接口从结构化数据中提取相关证据，然后将其线性化为文本提示，最后将提示输入LLMs理解生成（选择有用数据用于下一步迭代，或者预测最终答案结束推理）。具体过程如下图所示，关于这一通用流程在每类结构数据上的详细使用方式可参考论文中的具体描述。
样例展示
为了更直观的展示我们的方法，我们举例展示了三种结构化数据上的执行过程，具体的形式化过程期望感兴趣的读者参考我们的论文。
实验
为了验证我们方法的通用性和有效性，我们在三类结构化数据八个具体数据集上进行了实验。每个数据集上，我们的基线模型有两大类：
- 全量监督模型
- 直接使用大语言模型
其中，+ IRR (ours) 表示基于我们提出的方法在零样本场景下使用大语言模型；+ IRR (ours, few-shot) 表示基于我们提出的方法在少样本场景下使用大语言模型。
评测指标：
- KGQA：Hits@1，判断预测最高得分答案是否正确
- TableQA：Accuracy (TabFact)，Denotation Accuracy (WTQ和WikiSQL)，判断预测是否正确
- Text-to-SQL: Execution Accuracy，判断预测SQL和真实SQL的执行结果是否一致
通过上述实验可以看到，我们提出的方法在各种任务，各种场景下均可显著提升大语言模型在结构化数据上的表现，甚至能超过部分全量监督训练模型。
错误分析
为了进一步分析我们方法的不足之处，我们首先选择了三个具有不同结构化数据类型的数据集（即 WebQSP、WTQ 和 Spider），并从每个数据集中随机抽取了100个错误案例。然后，我们手动检查这些故障并将它们分类为五个类别，即：
- 选择错误：LLM 没有选取相关信息。
- 推理错误：在提取相关信息的基础上，LLM 未能生成正确的答案或 SQL。
- 生成格式错误：生成答案的格式异常，无法识别。
- 幻觉错误：LLM 生成的结果与提取的信息不一致。
- 其他错误：其他无法分类的错误。
首先，对于三个数据集而言，出现错误的分布是不同的。在 WikiSQL 中，生成格式、选择和推理错误的频率相对均衡。而在 WebQSP 中，选择错误是主要的错误类型（74％），因为 KGQA 任务要求从数千个关系中选择最相关的一个，这并不容易。在 Spider 中，推理错误更为常见（62％），因为 Text-to-SQL 任务要求 LLMs 生成可执行的 SQL 以获取答案，这对 LLMs 也是困难的。根据错误分布，为每个数据集的主要错误情况改进我们方法的设计很有希望提高性能。具体而言，我们可以设计更多的高质量提示，引导 LLMs 在 KGQA 和 Text-to-SQL 任务的选择和推理过程中进行谨慎决策。此外，我们还考虑增加更多的接口和迭代轮次，将困难的迭代分解成多个简单迭代，以简化复杂的推理任务以获得更好的性能。我们将在未来的工作中尝试上述解决方案。
总结
在本研究中，我们提出了一个通用框架，用于改善 LLMs 在结构化数据上的推理能力，即 StructGPT。在我们的方法中，我们首先构建了结构化数据的访问接口，以支持准确高效的数据访问，然后提出了一个调用-线性化-生成的求解过程，利用 LLMs 基于接口进行阅读和推理。通过按顺序使用接口迭代上述过程，LLMs 可以逐步捕获更有用和详细的证据，并最终生成答案。我们期待该方法能为大语言模型与结构化数据的结合提供灵感，也欢迎在实际落地遇到问题时与我们联系（jiangjinhao@ruc.eud.cn）。
快抢沙发！
