Text2SQL智能报表方案技术详解

Text2SQL智能报表方案技术详解

引用

CSDN

1.

https://blog.csdn.net/m0_74823878/article/details/145828169

Text2SQL智能报表方案通过自然语言处理技术，让用户能够以自然语言的形式提出问题，并自动生成相应的SQL查询，从而获取所需的数据报表。本文将详细介绍该方案的技术框架、实现方法以及相关产品。

0 背景

Text2SQL智能报表方案旨在通过自然语言处理（NLP）技术，使用户能够以自然语言的形式提出问题，并自动生成相应的SQL查询，从而获取所需的数据报表。用户可以根据得到的结果进行展示和分析，为结论提供支撑。此外，该方案还可以通过对结果数据与用户问题的拆解，帮助识别可能存在的异常问题。

1 技术框架

智能报表整体架构分为5层，分别为资源配置层、数据存储模块、LLM、智能体开发框架、功能应用。在设计时需要考虑如何选型与适配各个层之间的交互，因为数据与大模型的本质决定了功能的上限。

1.1 资源配置层

• 机器算力：大模型部署需要足量的内存（RAM）与显存（GPU）。例如，部署7B（FP32/4Byter）可能需要7G左右内存，如果要进行微调则需要GPU的支持（如果部署在GPU上推理速度会更快）。

1.2 数据存储模块

• 知识库（外挂RAG）：包含用户需要查询的数据库表的详细描述信息（包含库、表、详细字段）；智能体系统描述信息，比如系统可能包含Text2SQL智能体、数据分析智能体，需要具体的系统描述信息（角色定位、工具信息描述，输出限制等）。
• 业务数据库：为数据分析等场景提供支持。
• 向量数据库：对知识库（表结构）进行向量化，方便快速检索。

1.3 大模型

• 使用方法分类：
• API接口调用（前期资源不到位情况可暂时使用API接口调用）
• 本地部署（数据属于保密资产时选择本地部署以解决泄漏问题）
• 功能分类：
• 大语言模型
• 词向量嵌入模型

1.4 开发框架应用

提供了一系列工具来简化大模型业务流程，支持快速开发迭代。

1.5 服务产品

可按照实现模块进行分期实现，优先实现Text2SQL、报表图示、报告生成、智能客服等功能。

1.6 Text2SQL

功能：Text-to-SQL（或Text2SQL，text2Code的子任务），顾名思义就是把文本转化为SQL语言，更学术一点的定义是：把数据库领域下的自然语言（Natural Language，NL）问题，转化为在关系型数据库中可以执行的结构化查询语言（Structured Query Language，SQL）。因此Text-to-SQL也可以被简写为NL2SQL。

• 输入：自然语言问题，比如“查询表t_user的相关信息，结果按id降序排序，只保留前10个数据”
• 输出：SQL，比如“SELECT * FROM t_user ORDER BY id DESC LIMIT 10”

优点：Text2SQL应用主要是帮助用户减少开发时间，降低开发成本。“打破人与结构化数据之间的壁垒”，即普通用户可以通过自然语言描述完成复杂数据库的查询工作，得到想要的结果。

目标：自然语言查询语句 -> SQL结构化查询语言

已知：数据库中的有限表，测试集合《text_question,SQL_answer,My_sql_result》

解决方法：PE + LLM

案例1 表少、简单

一个最基础、最直观的提示工程方案是，输入数据库的Database Schema，即数据库的基本结构（包括表名、列名、主外键关系等），以及用户的问题，提示模型输入该问题对应的SQL语句。这种提示范式可以很方便地让LLM适应各种不同的数据库与对应的用户查询。近期的一些研究表明，在输入中，额外增加表和列的文本描述、小样本示例（即few-shot Question-SQL pairs）、一定格式描述的数据样本（即数据库中每一个表的随机几行数据样本）等信息有助于LLM更好地理解数据库结构，从而生成更准确的SQL【比如：RSL-SQL】。

• 输入问题提示词以及相关的表结构信息，让大模型产出结果，如下：（通义千问）

解决方法2：PE + RAG / KAG +LLM

案例2：真实的业务场景面对的是多库、多表、多字段，并且存在表字段描述信息存在语义，在提示中包含完整的数据库信息会导致输入token过多，计算成本增加，更重要的是会引入大量噪音。在生成SQL之前，用一些方法提前找到与用户问题相关的表和列，然后，输入给大模型的是被显著简化后的Database Schema，从而达到减小输入噪音并增强SQL生成性能的目的【RAG】。

1. 首先是如何得到详细描述数据库表的信息，这一个需要具体业务部门（用户）有一个深入的理解；
2. 过滤掉与用户问题无关的数据表描述信息（简单、详细、过滤不必要冗余信息）；

解决方法3: PE+RAG+SFT+LLM

案例3：存在大量的表、并且已经收集到大量的训练数据；

• 基于积累的训练数据进行微调，得到特定领域的大模型（按照业务、主题划分）；

注意：

• 1 记录用户的提问日志，分析用户的行为信息，为下次用户使用提供参考；
• 2 模型微调数据收集：是否正确，如果正确直接放到标注数据中，不正确可以把查询的语句写入；
• 3 如果大模型能力有限，可按照业务或者主题进行切分，增加模型的抗干扰能力；

1.7 大模型

1.2.1 语言大模型（预训练数据库）

目前，基于LLM的Text-to-SQL主要分为两类技术路线，一类是对一些开源的参数较小的LLM（如Deepseek-7B）进行微调，另一类则是基于闭源的参数较大的LLM（如GPT-4、GPT-4o）的提示工程方法。

精度/通用性与模型大小是一个矛盾点，高精度意味着需要更多的参数（记住所有信息）。如何落地优选平衡二者之间的关系，可以从下面出发：

1. 预算足够（有钱），直接使用开源的大模型，通用性能广、理解用户的需求能力更强；
2. 预算不足，那就做垂直领域的大模型，基于非房/房订单业务数据（SQL对话数据）对大模型进行微调，数据质量直接决定模型的上线，并且数据的收集需要时间。其次可以通过提示词工程等引导大模型回答；

1.2.2 开源大模型选择

text2SQL：目标是具备coder、function calling能力；

本地部署会占用大量内存，下面是目前几个开源大模型。当然如果需要再进行微调，那么需要更多的内存，比如选择Adam优化器，需要额外3倍的模型大小内存，共计4倍（比如deepSeek V2,需要16 * 4 = 64G）

常见底座模型概览：（深度求索、智谱、零壹万物、阿里）

大模型下载地址：

1. HuggingFace：Hugging Face – The AI community building the future.
2. 魔塔社区：魔搭社区
3. Ollama：统一管理部署

1.2.3 嵌入大模型

目标：为了RAG提供理论模型支持（多维度1024，英文+中文），提前找到与用户问题相关的表和列；

BAAI/bge-large-zh-v1.5

未来主要技术工作内容：

1. 提示词工程：新表信息完善、few-shot库构建+召回/COT技术；
2. RAG：词向量嵌入，表召回、列召回、粗排到精排；
3. 大模型微调；
4. SQL语法修正，多路执行结果投票；

1.8 数据分析与报表

• 智能分析：提供数据理解能力、数据趋势解析等，可借助业务文档提出切合业务的问题分解，支持归因、TopN、维度下钻、时序预测等算法，以及动态的操作推荐；
• 智能图示：根据SQL查询结果（或者代码）提供给前端按照具体图例展示；
• 动态预警：借助大模型的动态趋势预警能力，实现数据自动找人，将业务数据的异常波动主动推送到相关人，帮助业务部门及时发现问题并采取有效措施。
• 智能洞察：具备时序异常检测、因果关联、波动归因等主动洞察能力，自动发现有用结论。

1.9 明确目标

1. 用户定位；
2. 数据源以及权限定位：所有库表是否有使用限制等条件，需要业务完善相关表信息

功能：

1. 为用户提供参考SQL语句；
2. 执行SQL代码；
3. 为前端提供图（图片），还是为前端提供具体执行代码等。

2 成熟的产品

论文标题：
RSL-SQL: Robust Schema Linking in Text-to-SQL Generation
论文链接：
https://arxiv.org/abs/2411.00073
代码链接：
https://github.com/Laqcce-cao/RSL-SQL