摘要：紧接AIGC系列三提出的通用的NL2SQL的解决方案存在数据查询准确率低的问题，通过自然语言查询数据库，分析数据，不需要繁琐的报表开发流程。然而在企业实际应用场景中，数据查询的准确性极大的限制了技术的落地使用。有些场景数据错误带来损失惨重，比如给客户交付数据、重要的公司汇报。。。

本文基于这个问题，给出了优化方案。

目前的NL2SQL数据查询的准确率‍‍
常见的优化解决方案

01

—

NL2SQL数据查询的准确率‍

大模型现阶段在NL2SQL的表现还是比较一般，闭源模型效果要优于开源，下面是国外的一组测试数据。

spider是斯坦福大学开源的一个NL2SQL基准测试数据集

按照系统流程从前到后，我们有几种领域实践比较有效的方法，优化NL2SQL的表现。

增加AI Agent，用于用户意图识别和问题改写优化

使用Few-shot-prompt

基于RAG的数据库schema信息和业务背景知识增强

Fine-tune大模型

垂直大模型

02

—

常见的优化方案

AI Agent‍‍

AI Agent可以更好地理解用户的需求，并根据需求改写问题，使其更清晰、更具体，提高后续查询的准确性和效率。这个Agent还能用于处理上下文信息，根据历史聊天记录来猜测用户的输入意图。

例如，用户可能会提出一些含糊不清或不完整的查询，而AI Agent可以识别这些问题，并向用户请求进一步的信息，以澄清查询。同时，AI Agent还可以根据用户的输入生成更详细、更准确的查询，从而提高与数据库的交互效率。

简单的说就是在用户输入的问题都进行一组promt处理，适用大模型的能力来猜测用户的输入意图，以及历史信息，来优化生成SQL的内容‍‍

Few-shot-prompt

这个Prompt的好处就不用过多介绍了，在NL2SQL领域，这种Prompt方法更加重要。模型需要将自然语言问题映射到SQL查询，通常需要大量的训练数据才能获得良好的表现，这个对于大多数大模型来说不现实。

question：查询成绩大于90分的学生姓名。
sql answer：SELECT Name FROM Students WHERE Score > 90;

question：查询年龄小于20岁的学生姓名。
sql answer：SELECT Name FROM Students WHERE Age < 20;

通过优化这两个示例，我们可以改进模型的泛化能力，使其能够更好地处理类似的查询。在实际应用中，可以使用更多的少量示例来优化模型，以提高其在NL2SQL任务中的性能。

简单的说明就是在大模型生成sql的时候可以给大模型一组参考实例进行参考，这个也是在生成sql的过程中使用一次Prompt‍‍‍‍‍‍

RAG

企业的业务知识对于大模型来说都是不知道的，每个企业对指标的定义都有所不同。数据库表信息、字段信息、关联关系这些schema信息，特别是业务复杂，数据库比较大的时候。我们知道添加这些背景信息能让大模型输出更准确，但静态的Prompt没法承载这么大的文本信息。

第二个，对于Few-shot-prompt也是一样的问题，当我们有大量的自然语言问题和SQL查询样例时，每次对话可能只需要选择其中最相近的，没办法也没必要都作为Prompt输入给大模型。

提前整理好业务知识、数据库schema信息、自然语言问题和SQL查询样例，通过RAG生成增强Prompt，提升大模型表现，同时保证不突破token limit的限制。按照其它人的实际测试结果，可以比原来提升40%的准确率。

简单的说即是在从自然语言生成sql的过程中，从自然语言提取关键词，然后去向量数据库匹配到对应的数据库，表，字段信息给到大模型去生成sql语句。提高sql的准确性。‍‍‍‍

Fine-tune

在企业实际应用场景，我们除了有人工标识的自然语言问题和SQL查询样例外，还可以通过用户反馈得到大量的准确样例，这些数据作为数据集可以用于微调大模型。微调的成本大于RAG，但在任务特定的数据集上进行 fine-tune，可以使大模型更好地适应特定任务的处理。

有人做过基于spider数据集微调openai gpt-3.5-turbo，结果准确率是高于gpt-4的，而且费用比gpt-4降低了30倍，速度快了12倍。

简单的说即使用一组标准的自然语言问题和sql 语句，输入到大模型进行微调，微调后大模型另存一个副本，然后后期调用副本的API进行SQL的输出。‍‍‍‍

垂直大模型

使用专门优化过的垂直大模型，这是一种思路，给企业提供了另一种方案。在实际场景中，虽然我们只是通过大模型来生成SQL，并不会存在泄露数据的风险。但是Prompt、RAG等的使用也会给大模型输入数据库以及业务相关的信息，对于一些比较敏感的企业来说也是不可接受的。开源、可以私有化部署的大模型就是一种很好选择。

SQLCoder，是一个使用基于StarCoder模型的基础模型进行微调的开源模型。在defog.ai的sql-eval框架上，它在自然语言到SQL生成任务上表现优于gpt-4和gpt-4-turbo，并且明显优于所有流行的开源模型。 github：https://github.com/defog-ai/sqlcoder

DuckDB-NSQL，是一个7B参数的文本到SQL模型，专门设计用于SQL生成任务。该模型基于Meta原始的Llama-2 7B模型，并进一步在一组通用SQL查询的数据集上进行预训练，然后在由DuckDB自然语言到SQL对组成的数据集上进行微调。

github：https://github.com/NumbersStationAI/DuckDB-NSQL

企业应用场景中，可以形成用户反馈-迭代优化的闭环，而且是持续性的。随着大模型技术的发展，准确性和性能只会越来越好。‍

欢迎加入【数据行业交流群】社群，长按以下二维码加入专业微信群，商务合作加微信备注商务合作，AIGC应用开发交流入群备注AIGC应用