也看大模型与数据库查询分析的落地结合：C3 Text2SQL方案及Data-Copilot数据自动化编排机制的实现思想阅读

今天是2023年8月5日，星期六，北京，天气晴。

天气又开始热了起来，我们来讲一讲大模型和数据库的一些事儿。

基于大模型进行数据库操作和分析，是text2sql这个任务的一个延伸，当前已经出现了一些性的探索工作。

而就Text到SQL这个任务而言，其目的是将自然语言问题转换为可执行的SQL查询，用于为关系数据库提供用户友好界面，并使数据管理的各个环节受益，如数据库的可访问性、网站设计的灵活性等。

传统的text到SQL方法通常使用一定量的训练数据对解码器-编码器模型进行微调，以实现适当的文本到SQL性能，但这些基于微调的方法需要一个由大量text-SQL对组成的训练集，在实践中，获取text-SQL对的成本极高。此外，这种微调模式会导致训练集过拟合，降低模型的可移植性。

紧接着，大型语言模型（LLM）的出现给人们留下了深刻的印象，并为文本到SQL任务指明了新的方向。由于上下文学习（ICL）的能力，GPT模型等LLM在许多NLP下游任务中的表现都不错。在LLM中，ICL中提示语的设计深刻影响着输出结果的质量，所以也涌现出我们常说的提示工程prompt engineering。

所以，将大模型与sql融合的工作也逐步受到关注，这也是今天技术社区讨论的话题【每日一话题】：

​

社区朋友对该领域进行调研，推荐出有以下几个代表性的工作，适用于理论侧：

《A Case-Based Reasoning Framework for Adaptive Prompting in Cross-Domain Text-to-SQL》

地址：https://arxiv.org/abs/2304.13301

《CHATDB: AUGMENTING LLMS WITH DATABASES AS THEIR SYMBOLIC MEMORY》

地址：https://arxiv.org/abs/2306.03901

《Retrieval-augmented GPT-3.5-based Text-to-SQL Framework with Sample-aware Prompting and Dynamic Revision Chain》

地址：https://arxiv.org/abs/2307.05074

《C3: Zero-shot Text-to-SQL with ChatGPT》

地址：https://arxiv.org/abs/2307.07306

《Interleaving Pre-Trained Language Models and Large Language Models for Zero-Shot NL2SQL Generation》

地址：https://arxiv.org/pdf/2306.08891.pdf

《SQL-PALM: IMPROVED LARGE LANGUAGE MODEL ADAPTATION FOR TEXT-TO-SQL》

地址：https://arxiv.org/abs/2306.00739

《MIGA: A Unified Multi-task Generation Framework for Conversational Text-to-SQL》

地址：https://arxiv.org/abs/2212.09278

《DIN-SQL: Decomposed In-Context Learning of Text-to-SQL with Self-Correction》

地址：https://arxiv.org/abs/2304.11015

而在实践端，也有社区朋友进行了实践，并给出了自己的一些观点，例如：

完全靠大模型自动生成SQL实测感觉效果一般，表和列比较多的数据库或者稍微复杂一点的查询条件基本上都很难准确，但是生成sql的能力基本上完全依赖chatgpt，另外还有一个蚂蚁的db-gpt，在llama上拿sql的数据去做了微调。

实际应用的时候应该是需要把所有的字段都给大模型或者需要有个前处理初步判断一下需要哪些字段，测的时候是只把相关字段给了大模型，这个过程其实也需要自动化。

这其实又引申出另一个定律，即用大模型进行领域场景探索时，尽量使用gpt4、Claude2、gpt3.5。你先知道LLM 行不行，再考虑次一级的模型是否具备这个能力。

而且，单独做数据查询可能并不那么系统，所有又出现一些直接与数据库通信，甚至加入数据分析的工作，包括：Data-Copilot（https://github.com/zwq2018/Data-Copilot）。

因此，为了增进对该话题的了解，本文顺着这个话题进行介绍，主要介绍《C3: Zero-shot Text-to-SQL with ChatGPT》这篇text2sql、以及基于大模型进行数据分析可视化的整体系统Data-Copilot两个工作，供大家一起思考。

一、C3: Zero-shot Text-to-SQL with ChatGPT

《C3: Zero-shot Text-to-SQL with ChatGPT》（地址：https://arxiv.org/abs/2307.07306）提出了一种新颖的基于ChatGPT的zeroshot文本到SQL方法（称为C3），该方法每次查询只需使用大约1000个token。

这个工作很有趣，讲述了用大模型进行sql生成的一些偏见信息，并给出了如何设prompt来优化生成效果。

从其公开项目地址：https://github.com/bigbigwatermalon/C3SQL中，我们可以发现其处理流程：

python src/preprocessing.py 
    --mode "test" 
    --table_path $tables 
    --input_dataset_path $dataset_path 
    --output_dataset_path "./generate_datasets/preprocessed_test.json" 
    --db_path "$db_path" 
    --target_type "sql"
    
# recall tables
echo "recall tables..."
python src/table_recall.py 
    --input_dataset_path "./generate_datasets/preprocessed_test.json" 
    --output_dataset_path "./generate_datasets/table_recall.json" 

# recall columns
echo "recall columns..."
python src/column_recall.py 
    --input_dataset_path "./generate_datasets/table_recall.json" 
    --output_dataset_path "./generate_datasets/column_recall.json" 

# generate prompt
echo "generate prompt..."
python src/prompt_generate.py 
    --input_dataset_path "./generate_datasets/column_recall.json" 
    --output_dataset_path $processed_dataset_path 

## sql_post_process（后期的东西）

其中，在数据数据预处理阶段，包括remove_semicolon、double2single、add_asc以及remove_table_alias等操作。

# remove ";"
    def remove_semicolon(s):
        if s.endswith(";"):
            s = s[:-1]
        return s
    # double quotation -> single quotation 
    def double2single(s):
        return s.replace(""", "'")

    def add_asc(s):
        pattern = re.compile(
            r'order by (?:w+ ( S+ )|w+.w+|w+)(?: (?:+|-|<|<=|>|>=) (?:w+ ( S+ )|w+.w+|w+))*')
        if "order by" in s and "asc" not in s and "desc" not in s:
            for p_str in pattern.findall(s):
                s = s.replace(p_str, p_str + " asc")
        return s
    def remove_table_alias(s):
        tables_aliases = Parser(s).tables_aliases
        new_tables_aliases = {}
        for i in range(1, 11):
            if "t{}".format(i) in tables_aliases.keys():
                new_tables_aliases["t{}".format(i)] = tables_aliases["t{}".format(i)]
        tables_aliases = new_tables_aliases
        for k, v in tables_aliases.items():
            s = s.replace("as " + k + " ", "")
            s = s.replace(k, v)
        return s

此外，在得到sql后也会进行后处理。

这是流程上的事儿，那其在实现方式上，又有哪些实现思想？

如表1所示，C3由三个关键部分组成：清晰提示(CP)、提示校准(CH)和一致输出(CO)，它们分别对应于模型的输入、模型偏差和模型输出。

其中：

1、CP(Clear Prompting)

CP(Clear Prompting)是一种用于zeroshot文本到SQL的新型提示范例，它通过采用适当的输入来提高zeroshot文本到SQL的性能。清晰提示（CP）组件旨在为文本到SQL解析提供有效的提示，由清晰的布局和清晰的上下文两个部分组成。

其中，清晰的上下文指的是数据库的表名和字段。在提示符的上下文部分包含整个数据库模式会导致两个问题。

由于在一般做法下，在提示中引入过多无关项会增加ChatGPT在输出SQL中生成无关模式项的可能性，而且使用完整的数据库模式会导致文本过长，从而产生不必要的API成本。

为了克服这两个问题，需要进行模式schema链接，以调用相关的表和列【这个很像我们进行KBQA的思想】，可分为以下两个步骤：

首先是表召回（Table Recall）

设计一个zeroshot提示，指示ChatGPT通过三个步骤召回表格，提示模板如下：

其思想在于：首先，根据表与问题的相关性对表进行排序。其次，模型应检查是否已考虑了所有表格。最后，以列表形式指定输出结果。为确保表格召回的稳定性，模型会生成十组检索结果，每组包含前四张表。最终结果通过选择十组结果中出现频率最高的一组来确定。

其次是列召回（Column Recall）

在表格检索结果的基础上，进一步检索候选表格中的列。设计一个zeroshot提示，并指示ChatGPT分两步召回列，对应的prompt如下：

其思想在于：首先，根据与问题的相关性对每个候选表中的所有列进行排序。然后，将输出格式指定为字典，并在提示中强调，与问题单词或外键匹配度更高的列应放在前面，以帮助获得更准确的调用结果，并且，对于每张表，都会一次性生成十组被召回的列。然后，选择每组中出现频率最高的五列作为最终结果。

除了调用表和列之外，我们还在上下文部分添加了调用表的外键信息，以指定JOIN操作所需的列，结合”清除布局”和”清除上下文”，我们提出了”清除提示”，如图2c所示。

2、CH（Calibration with Hints）

不过，通过分析生成的SQL查询中出现的错误，该工作发现有些错误是由ChatGPT固有的某些偏差造成的。如图3所示，ChatGPT更喜欢提供额外的列和额外的执行结果。

这可以总结为以下两种偏差，为了校准这两种偏差，提出了一种插件式校准策略，称为”提示校准”（CH, Calibration with Hints)，CH通过使用包含历史对话的上下文提示，将先验知识纳入ChatGPT。在历史对话中，最初将ChatGPT视为优秀的SQL写入者，并引导它遵循我们提出的偏差提示。

其一，ChatGPT的输出倾向于保守，经常选择与问题相关但并非必须的列，这种倾向在涉及数量问题时尤为明显。 例如，对于图3（左）中的第一个问题，ChatGPT在SELECT子句中选择了Year和COUNT()。然而，Spider数据集中的黄金SQL只选择了Year，因为COUNT()仅用于排序目的。

对于第这个偏差，设计了一个提示，引导ChatGPT只选择必要的列，强调在SELECT子句中不应包含COUNT(*)这样的项目，因为它只是为了排序的目的。

其二，ChatGPT在编写SQL查询时倾向于使用LEFTJOIN、OR和IN，但往往不能正确使用它们。 这种偏差往往会导致执行结果中出现额外的值，图3（右）中有一些例子说明了这种偏差。

对于这个偏差，设计一个提示来防止ChatGPT误用SQL关键词，直接要求ChatGPT避免使用LEFTJOIN、IN和OR，而使用JOIN和INTERSECT，此外，还提示ChatGPT在适当的时候使用DISTINCT或LIMIT，以避免重复执行结果。

3、CO(Consistency Output)

通过结合这两个提示，ChatGPT可以生成更符合所需输出的SQL查询。

但这又存在另一个问题，也就是大型语言模型输出中的随机性和不确定性，由于大型语言模型固有的随机性，ChatGPT的输出并不稳定。

为了增强一致性，保持生成的SQL查询的一致性，CO(Consistency Output)被采用。

其思想在于：首先对多种不同的推理路径进行采样，然后选择最一致的答案，具体的， 在文本到SQL的过程中采用了多种路径来生成不同的SQL答案。然后，在数据库中执行这些SQL查询并收集执行结果。从所有结果中剔除错误后，通过对这些执行结果应用投票机制，找出最一致的SQL作为最终SQL。

例如，在图5中，根据执行结果对SQL查询进行分类，并用不同颜色表示。然后，我们对这些类别进行比较，以确定哪个类别包含更多SQL查询，并从该类别中选择一个SQL作为最终SQL。

4、评估效果

为了评估效果，该工作在Spider数据集上进行实验。

Spider是一个大型复杂的跨领域文本到SQL数据集。该数据集由10,181个问题和5,693个独特的复杂SQL查询组成，涉及200个数据库的多个表格，涵盖138个不同领域。数据集分为146个数据库中的8659个训练样本、20个数据库中的1034个评估样本和34个数据库中的2147个测试样本。

每个样本集所使用的数据库之间没有重叠。同时，根据难度级别，这些样本被分为四类：简单、中等、困难和其他。

在具体实验上，使用OpenAIChatGPTAPI：GPT-3.5-Turbo-0301作为实验模型，通过Chat-GPT根据给定问题分两步召回表格和列。然后，使用CP和CH方法构建输入提示，利用ChatGPT一次生成20个SQL查询，并使用CO方法选择最一致的SQL作为最终结果。

对比模型采用ChatGPT-SQL（引入了一种简单的”0-shot”方法来评估ChatGPT在Text2SQL任务中的能力）、RATSQL（利用关系感知自关注来编码数据库模式和查询的关系结构）、PICARD（引入了一种带有约束解码的增量解析方法，该方法在每一步生成过程中都会检查并过滤掉不合适的标记）、Graphix（根据预训练的T5模型对语义和结构信息进行组合编码）、SC-Promp（将Text2SQL任务分解为两个子任务，分别预测结构和内容）、RESDSQL（以解耦模式链接和骨架解析，基于微调的最佳方法）以及DIN-SQL（将文本到SQL任务分解为更小的子任务，并为每个子任务设计不同的提示，以指示GPT-4完成每个子任务并获得最终的SQL）。

其中，《DIN-SQL: Decomposed In-Context Learning of Text-to-SQL with Self-Correction》，地址为：https://arxiv.org/abs/2304.11015

最终对比效果如下：

可以看到，取得了较好的效果，其对影响因素也做了分析，如下：

有一些比较有趣的结论：

从表2中可以看出，清晰布局比复杂布局高出7.0%，这表明清晰的提示布局对于基于chatGPT的零点文本到SQL非常重要，这是因为清晰的布局可以让ChatGPT更好地理解提示，而复杂的布局可能会模糊信息。 因此，清晰的布局可以帮助ChatGPT更好地遵指令，充分利用提示中提供的信息。

从表3中可以看出，去掉调用表和列的操作后，C3的性能降低了2.3%；去掉指定外键的操作后，C3的性能降低了2.6%，这表明，召回表和列以及指定外键的操作对于C3来说是必要的，因为这些操作提供了清晰的提示内容。

为了清楚地证明方法的有效性，在开发集上对ChatGPT-SQL和C3方法进行了错误分析，手动检查了生成的SQL答案中出现的错误，并将其分为六类，如图7所示。

首先，可以看到，与ChatGPT-SQL相比，C3方法，错误总数减少了约34%。最显著的减少发生在schema链接类别中，该类别包含三个子类别。在这些子类别中，Extra-columns子类别主要由Bias1造成，因此，但基于C3方法，属于该子类的错误比例下降了11%，这说明CH在校准模型偏差方面效果显著。

其次，嵌套类中的Setop子类别显示了INTERSECT和EXCEPT等操作的误用，其他类中的Distinct子类别显示了重复执行的结果。属于这些子类别的错误大多是由偏差2引起的，虽然这些类别的比例略有变化，但这些类别的实际错误数量却有所减少，这表明CH可以有效校准偏差2。

二、Data-Copilot基于LLM的数据处理平台

上面讲述了一个text2sql的实现方法，但还不能够直接落地，贯穿整个数据处理平台，而随着最近autoGPT、BabyAGI、huggingGPT这些利用大模型进行目标分解规划并执行相应操作，从而最终实现复杂问题建模的方法的提出，有的工作也很自然地利用这一点，用来解决数据查询、数据分析的工作。

Data-Copilot是一个基于LLM的系统，它通过自行设计复杂的界面工具，完成对大量不同来源数据的自动管理、调用和处理，其思想与huggingGPT这些很类似，如下图是个具体工作流的图，不过从其开源的项目源码中可以看到，其未用到数据库，而是用的几个csv文件等做的查询。

项目地址：https://github.com/zwq2018/Data-Copilot

论文地址：https://arxiv.org/abs/2306.07209.pdf

先看一个具体的例子，图3提供了一个用户输入请求的详细示例：”预测中国未来4个季度的GDP增长率”。

在执行阶段，Data-Copilot首先根据当地时间解读用户的意图。随后，部署了一个分三步的工作流程：第一步是调用{get-GDP-data}接口获取历史GDP数据。第二步是调用{predict-next-value}接口进行预测，最后一步是将输出结果可视化。

其流程可以整理成如下的架构，如图2所示：

首先，LLM扮演设计师的角色（界面设计 interface design），自主构建工作流程的每个组件。

此外，LLM还扮演调度员的角色（接口调度interface dispatch），使用生成的接口自动部署工作流。

通过这两个阶段的整合，Data-Copilot可以高效处理大量与数据相关的任务，并满足各种用户需求。

我们具体来看每个部分的实现细节：

1、界面设计

Data-Copilot设计了大量界面作为数据管理工具，其中界面是由自然语言（功能描述）和代码（实现）组成的模块，负责数据采集、处理等。

如图2所示，Data-Copilot维护着一个接口工具库，其中存储着当前生成的接口。

首先，LLM会收到一些种子请求，并自主生成大量请求。然后，LLM针对这些请求设计相应的接口（只有描述和参数），并在每次迭代中逐步优化接口设计。最后，利用LLM强大的代码生成能力，为接口库中的每个接口生成特定代码。

具体来说，其首先为每个数据源生成一个解析文件，以帮助LLM理解数据。每个解析文件都包括数据描述、每列（属性）名称、访问示例及其输出的第一行和最后一行，如下图所示（来自于https://github.com/zwq2018/Data-Copilot/blob/main/create_tool/all_atomic_api.json）：

然后，采用自请求流程来探索数据，即把这些解析文件和一些种子请求作为提示输入LLM，并指示LLM生成更多样化的请求，这些生成的请求将用于下一步（接口定义）。

我们来看看什么是接口定义，在这一步中，Data-Copilot会定义各种接口工具，以满足之前生成的请求，也就是说，将接口库中存储的所有数据解析文件和所有接口（第一次迭代时为空）作为提示输入Data-Copilot。

如图2所示，每个请求都被逐一输入Data-Copilot，Data-Copilot会被提示使用接口库中的现有接口或重新定义一个新接口来满足当前请求，详细提示如图10所示。

如上图所示，每次迭代都会提示LLM以JSON格式生成接口库：””，函数描述：”””，输入和输出：”””}，使用这些接口生成解决方案Solution=”首先使用getBankData获取数据，然后……”。

其次，我们再看看接口合并，为使接口更具通用性，Data-Copilot会考虑每个新设计的接口能否与库中现有的接口合并。具体来说，当Data-Copilot为一个新请求设计一个新界面时，会检查该界面在功能、参数等方面是否与之前的界面相似。两个相似的接口会被合并，以创建一个新的通用接口。

如图2所示，{Interface：查询-GDP}和{接口：查询-CPI}的两个接口已经合并：查询-CPI}合并为一个{接口：查询-GDP-CPI}：查询-GDP-CPI}。

这个过程类似于软件开发人员在开发过程中将相似的模块封装成一个新模块。

通过这一过程，大量相似的接口被合并。接口库中的每个接口都有非常明确的功能，并且与其他接口有明显区别，这有利于在实时响应中部署简洁明了的工作流程。

最后，我们再来看接口实现，每个请求都会陆续输入Data-Copilot，以便进行接口定义和接口合并。最终，当库中的接口可以满足所有请求时，Data-Copilot会利用LLM强大的代码生成功能，为每个接口生成实现代码，如下表时定义的接口情况：

2、接口调度

首先是意图分析，为准确理解用户请求，Data-Copilot首先要分析用户意图，意图分析包括解析时间、地点、数据对象和输出格式。

例如，如果用户的问题是：”我想比较一下我们地区过去五年的GDP和CPI走势”，Data-Copilot在准确理解语义后会将其解析为：”绘制一张中国经济发展的折线图”：”绘制2017年5月至2023年5月中国每季度全国GDP和CPI的折线图进行对比”（时间：201705-202305，地点：中国：中国，对象：中国季度GDP和CPI，格式：折线图）：折线图）。

这里的时间处理很有必要，为了将时间对齐，其首先调用外部API获取本地时间和网络IP地址，然后将这些外部信息与原始请求一起输入LLM，生成解析结果。

图11提供了一个详细的提示设计，以指导LLM完成这一阶段的工作，这也是对应的prompt工程。

其次是规划工作流程。 一旦准确理解了用户的意图，Data-Copilot就会规划一个合理的工作流程来处理用户的请求。在具体执行上，其也是指示LLM生成一个固定格式的JSON，代表调度的每个步骤，

step={"arg":"","function":"","output":""，"description":""}

项目地址https://github.com/zwq2018/Data-Copilot/blob/main/prompt_lib/prompt_task.json中所指出的prompt样式如下#

除了在设计阶段生成的界面描述外，Data-Copilot还在提示中加入了几个样例，作为上下文学习的一部分。

在界面描述和fewshot的提示下，LLM会根据用户的请求和接口定义自主决定调用哪些接口以及调用的顺序。

例如，对于图2中的第一个请求：”比较今年沪深300指数、创业板指数和中证1000指数的收益率”，Data-Copilot首先在工作流程中规划了五个步骤。

第一步，并行调度{数据采集接口}获取三个指数的数据，第二步同样获取三个指数的收益率。最后三个步骤依次调用{可视化接口}，在同一画布上绘制三个指数的趋势图。

此外，Data-Copilot部署了一个循环工作流，通过调用{循环和排名接口}完成所有50只成分股的财务指标计算。

最后是多形式输出。在部署和执行工作流程后，Data-Copilot会以图形、表格和描述性文本的形式生成所需的结果。

例如，针对可视化部分通过设定prompt来执行，参考地址：

https://github.com/zwq2018/Data-Copilot/blob/main/prompt_lib/prompt_visualization.json

此外，Data-Copilot还提供了整个工作流程的全面总结。这种系统总结不仅提供了简洁明了的结果，还揭示了实现这些结果的步骤，从而提高了数据相关任务的透明度和理解度，这相当于打通了最后一环。

3、体验地址与效果

huggingface上的也给出了一些DEMO:https://huggingface.co/spaces/zwq2018/Data-Copilot

总结

为了增进对该话题的了解，本文主要介绍《C3: Zero-shot Text-to-SQL with ChatGPT》这篇text2sql、以及基于大模型进行数据分析可视化的整体系统Data-Copilot两个工作。

可以看的出，其核心在于prompt工程的设计，把一个复杂的工作进行拆解，但其底层还是依赖大模型的能力，例如chatgpt，这些其实都是后期落地中需要考虑的问题。

夜色已晚，到家已是虫鸣的天下，愿大家周末愉快。

​

参考文献

1、https://github.com/zwq2018/Data-Copilot

2、https://arxiv.org/abs/2306.07209.pdf

3、https://github.com/bigbigwatermalon/C3SQL

关于我们

老刘，刘焕勇，NLP开源爱好者与践行者，主页：https://liuhuanyong.github.io。

老刘说NLP，将定期发布语言资源、工程实践、技术总结等内容，欢迎关注。

对于想加入更优质的知识图谱、事件图谱、大模型AIGC实践、相关分享的，可关注公众号，在后台菜单栏中点击会员社区->会员入群加入。