智能问数：让人人都能成为数据分析师

X_taiyang18

已于 2024-11-11 15:53:47 修改

阅读量3.1k

点赞数 24

分类专栏： AI与机器学习文章标签：人工智能

于 2024-11-11 15:50:35 首次发布

本文链接：https://blog.csdn.net/weixin_46445090/article/details/143687501

版权

AI与机器学习专栏收录该内容

7 篇文章

订阅专栏

智能问数：让人人都能成为数据分析师

LLM的出现正在重塑信息检索的方式，引领数据分析领域的一种新范式（Chat BI | GBI | Chat2DB）。数据，已经渗透到当今每一个行业和业务职能领域，成为重要的生产因素。在这个数据驱动的时代，数据分析能力已经成为企业竞争的关键。但是，并不是每个人都精通 SQL 或具备专业的数据分析技能。这就带来了一个问题：如何打破人与结构化数据之间的壁垒,即普通用户可以通过自然语言描述完成复杂数据库的查询工作，得到想要的结果。

三年行动计划（2024—2026年）让数据真正服务于业务

640-1

什么是Text2SQL？

Text2SQL（也称为NL2SQL）是一项革命性的技术，利用LLM的能力（包括使用RAG技术）将自然语言文本（Text）转换成结构化查询语言SQL的过程，属于自然语言处理-语义分析（Semantic Parsing）领域中的子任务。简单来说，你只需用日常语言提出问题，比如"上个月销量最好的产品是什么？"，系统就能自动将其转换为相应的SQL查询，并返回准确的结果。

传统数据分析的痛点

在某科技公司，资深数据分析师张伟（化名）正在对新推出的贷款产品进行市场效果评估。面对传统自助式BI工具，张伟在功能界面中逐一配置复杂的筛选参数，进行繁琐的拖放操作，有时甚至还需要编写SQL语句。即便是像他这样经验丰富的分析师，也不得不耗费大量时间进行数据准备和手动分析。传统的自助式BI和报表工具虽然能够帮助用户自主查询数据，但操作复杂，要求用户具备较强的数据分析能力和技术背景。对于很多企业的业务人员来说，BI工具的高门槛让他们难以从数据中获取真正的价值。

痛点	具体表现	影响
数据分析效率低	需要分析师、研发等多方角色的协同	决策延迟、资源浪费、风险高
技术门槛高	需要SQL专业知识	分析能力受限
数据理解门槛高	面对复杂的报表时，难以直观地理解和分析数据。	无法快速得出有效的洞察结果
可视化展示复杂	从数据准备到页面开发，需要经历产品和美工设计、前后端开发、测试等多个过程，各个环节专业工具使用复杂	开发周期长、页面调整不灵活、迭代速度慢
个性化数据分析难	传统 BI 报表只能展示固定的分析维度和指标	无法匹配业务的发展变化

技术实现方案

现代智能数据分析平台通常采用以下方式之一：

对比维度	text-to-API	text-to-SQL	text-to-Code	text-to-JSON
概述	将自然语言查询转换为数据分析 API 的调用	将自然语言查询转换为 SQL 语句	通过 AI 生成数据分析代码（如 Python）执行，例如代码解释器（Code Interpreter）	将自然语言查询转换为结构化的 JSON 查询语句
技术特点	直接依赖于现有 BI 工具的 API 层来执行具体的数据查询和分析任务，需要 LLMs 理解自然语言并转换为 API 调用	直接生成标准 SQL 语句，由数据库执行查询，这不仅对模型的自然语言理解能力有较高要求，还需要模型具备一定的逻辑推理能力来构建有效的 SQL 查询	要求 LLMs 生成可以直接执行的数据分析代码，这不仅需要 LLMs 理解查询意图，还需要具备编程知识和逻辑推理能力来生成有效的代码	需要 LLMs 将自然语言转换为标准化的 JSON 查询结构，支持嵌套查询和复杂的数据筛选条件，适用于文档型数据库和 RESTful API
LLM 能力应用程度	中	高	高	高
优点	• 与现有 BI 工具紧密集成 • 实现相对简单	• 标准化、通用性强 • 实现路径短	• 灵活、功能强大 • 独立于数据库	• 格式统一、易于解析 • 跨平台兼容性好 • 适合微服务架构
缺点	• 需要预定义好 API，受限于 API 的功能和性能 • 可能需要额外的 API 开发	• 需要精确的自然语言理解和 SQL 生成能力 • 可能存在 SQL 性能优化的问题	• 对代码执行环境有要求 • 安全和效率可能是考虑因素	• 表达能力可能不如 SQL • 复杂查询可能导致深层嵌套 • 需要额外的解析处理

技术难点

1. 大模型固有的“黑箱”和“幻觉”技术问题

大模型在处理复杂查询时，可能会遇到幻觉问题，即模型返回的数据可能不准确或不符合逻辑，是需要解决的一个技术挑战。

通过以下措施确保模型的返回可控性：

高质量训练数据与知识库：选用高质量的训练数据和知识库对BI领域的大模型进行训练，确保模型能够准确理解和处理BI相关的查询
云原生技术 和 强化学习微调：支持基于云原生技术的全量和参数高效微调，以及基于强化学习的对齐微调，专门针对BI场景进行优化
- 进行 Text2NLU 微调, 提升意图识别准确率
- 进行 Text2GQL微调,可以通过自然语言生成图查询语句
工程化Agent调用中控：通过工程化的Agent作为调用大模型的中控，根据不同场景进行路由优化，确保模型返回的稳定性和可控性
自我纠正：引导 LLMs 依据预定义的纠正准则生成修订后的 SQL 查询，但仅能处理有限范围的错误
执行反馈：通过利用在数据库管理系统（DBMS）上执行这些查询所得到的反馈来优化 SQL 查询，确保可激发性并改进结果。这方法对于那些未触发执行异常的问题却无能为力

2. SQL 查询中的错误

问题

条件不匹配（Mismatch of Conditions）

SQL 查询中条件子句的不匹配可能导致空结果或错误结果。
在真实场景中，用户问题的多样性和不规则性导致 LLMs 难以将问题与数据库精准对齐并生成正确的 SQL 条件子句。

更严格约束的不匹配（Mismatch of Stricter Constraints）

在真实场景中，SQL 查询通常需要遵循更严格的约束，这源于 SQL 的固有特性或用户自定义的规则。
例如，前者可能涉及与外键关系或列数据类型相关的限制，后者可能包含诸如“NULL”值或特定数据格式等强制流程。
这些更严格约束的不匹配在执行时未被体现，但不满足这些约束的 SQL 查询可能无法产生预期结果。
这使得 LLMs 难以在单个流程中生成准确的 SQL 查询，需要多步优化才能完成 SQL 生成。

方法

数据库检索器（Database Retriever）

用户问题的模糊性可能使即便是高级代理也难以在条件子句中找到正确的列名
当 SQL 条件子句与数据库中的任何条目均不匹配时，通过检索相似的数据库单元作为反馈来协助基于 LLM 的代理

错误检测器（Error Detector）
```
执行未经检查的 SQL 查询存在风险，因为它可能导致大型数据库中的响应时间变慢
在检查过程中，首先提取数据库的模式信息，包括所有表名、列名和类型、外键关系等
诊断过程重点检测基于 SQL 特性的错误：包括执行错误以及由 SQL 规则或领域专家定义的更严格约束的不匹配
```
通过 Python 解释器执行动作序列，工具集中的每个工具都会依据问题和数据库进行调用，以检查函数调用中的不同错误。若检测到错误，每个工具都会向智能体提供特定反馈，帮助智能体优化特定的 SQL 子句，而非盲目修改 SQL 查询。

检查和优化过程是迭代式的。智能体生成一系列动作后，会调用所有工具来检查潜在问题。若所有工具都认可动作序列，它将用于组装最终的 SQL 查询。反之，若有任何工具检测到问题，代理将依据原始序列和工具的反馈生成新的动作序列。

此过程可能会重复多次，直至所有工具都认可序列或达到最大尝试次数。

3. SQL 数据预处理

一个关系型数据库，比如一个MySQL数据库,包含了一个或多个表（table），每个表中又包含了多个列（column），表和表之间会通过一些公共的列进行联系，这些列也就是数据库中常见的主键外键。

在这里插入图片描述

在输入的预处理阶段，可以将所有的输入想象建模为图网络，图网络中的每一个节点就是输入的单词或者短语，他们之间的边则是我们所定义的各种不同类型的关系，通常来说一共有五大类型的关系：

模式编码 (Schema Encoding)：
- 记录数据库的结构关系，特别是通过主键和外键的连接关系
- 保留表与表之间的二维结构信息
- 避免在序列化过程中丢失表间关系
模式链接 (Schema Linking)：
- 建立自然语言问题与数据库模式之间的映射关系
- 用户提问时可能不会精确的说出哪一些表哪一些列的名字
  
  需要模型能够去判断用户问题中隐含的表和列的引用
问题依存结构 (Question Dependency Structure)：
- 分析自然语言问题中的句法依存关系
- 理解复杂问句中各个成分之间的关联
- 由于用户是用自然语言进行询问，因此在语法上存在一些依存关系
问题共指关系 (Questions Coreference)：
- 处理多轮对话中的指代问题
- 追踪代词（如"they"）指向的具体对象
- 维护对话上下文的连贯性
数据库内容提及 (Database Content Mentions)：
- 用户在询问一个问题时，提到一个具体列中的某个值，在这种情况下，信息内容匹配就显得非常重要
- 由于并不是数据库的表名或一个列名，进行模式编码或者说在序列化的时候并不会被考虑
- 模型根本就无法猜测到他们到底是属于哪一个列，需要使用模糊匹配的方式，来搜寻可能的数据库内容

序列化方法

从数据库中找到与一个问题最匹配的行列数据信息，将该行列的相关数据库的结构（表名、列名、主键、外键等）用自然语言描述出来

让我总结一下如何用自然语言将数据库Schema进行序列化

Schema序列化的主要步骤如下：

数据准备阶段：
- 使用JDBC API的Statement接口连接数据库
- 将数据库结构信息转换为统一的JSON格式

JSON结构组织：

{
  "query": "SQL查询语句",
  "question": "输入的问题",
  "db_id": "数据库名称",
  "db_table_names": ["表名列表"],
  "db_column_names": [{"table_id": "表ID", "column_name": "列名"}],
  "db_column_types": ["列类型"],
  "db_primary_keys": [{"column_id": "主键ID"}],
  "db_foreign_keys": [{"column_id": "外键ID", "other_column_id": "关联ID"}]
}

序列化转换：
- 通过自定义函数将Schema转换为自然语言描述
- 描述包含：
  - 数据库名称
  - 表的结构和关系
  - 列的名称和类型
  - 主键信息
  - 外键关系

输出格式：

{
  "instruction": "自然语言描述的schema信息",
  "input": "用户问题",
  "response": "对应的SQL查询"
}

示例输出：

"concert_singer(数据库名) contains tables(表) such as stadium, singer... 
Table stadium has columns(列) such as stadium_id, location... 
stadium_id is the primary key(主键)... 
The stadium_id is the foreign key(外键) of..."

提示模板：

"I want you to act as a SQL terminal in front of an example database.
Below is an instruction that describes a task..."

这种序列化方式的优点是：

保留了完整的数据库结构信息
使用自然语言描述更容易理解
便于模型理解和生成SQL查询
支持复杂的表间关系表达

产品目标

1. 数据问答

易于使用，像与真人对话一样简单（即使用户没有数据分析背景，也可以拿到想要的数据分析结果）
支持多轮对话和复杂查询（让每个人都可以得出有价值的数据洞察，实现数据普惠）
句句有回应，支持多意图识别（即使是混杂的表达也可以理解并准确回应，真正听懂提问者的“话中话”）
增添指标，即时响应（在报表搭建过程中，用户还可以通过输入自然语言的查询来细化或扩展报表内容）
自我纠错，安全可靠（用户也可以随时参与进来，提供反馈和修正，让分析结果更加符合实际需求）
查询过程透明可追溯（把AI的思考过程白盒化，可以让AI的每一步都可以被看到，每一个结果都可以被追溯和验证）
上传知识库，所问即所得（支持企业上传自己的特定行业术语知识库，使得模型能够更精确地理解企业内部的数据及其语境）

2. 数据可视化

自动选择最适合的图表类型
图表类型可切换、图表可下钻
将持久化的可视化图组装为仪表板（大屏）
支持图表交互和钻取分析

3. 数据洞察

AI自动检测数据异常（标注）
提供分析建议和见解（归因分析、预测分析）

4. 数据分析报告

快速生成报表摘要
根据用户指令自动完成完整的数据分析报告

2024年Text2Sql开源项目介绍

名称	描述	优点	缺点
Chat2db	人工智能驱动的数据管理平台，支持多种数据库。	支持多种数据库，提供7B开源模型。	需要集成多种数据库，可能存在兼容性问题。
SQL Chat	基于聊天的SQL客户端，使用自然语言与数据库通信。	支持多种数据库系统，用户友好。	可能需要额外的配置来适应特定的数据库。
Vanna	开源Python RAG框架，整合上下文和领域知识文档训练模型。	支持自定义可视化UI，灵活度高。	需要专业知识来训练和维护模型。
Dataherald	自然语言到SQL引擎，用于企业级问答。	模块化设计，易于扩展和维护。	需要业务用户适应自然语言到SQL的转换。
WrenAI	文本到SQL解决方案，无需编写SQL即可查询数据。	易于使用，安全可靠，高度准确。	需要用户适应自然语言查询的方式。
SuperSonic	腾讯音乐开发的模型知识库和语义解析器。	强大的语义解析能力，支持多种数据库。	可能需要专业的知识来理解和使用。
Awesome Text2SQL	精选教程资源库，包含LLMs、Text2SQL等方面的模型。	提供丰富的学习资源和模型。	主要作为资源库，可能需要额外的开发工作来集成到实际应用中。
DuckDB-NSQL	为DuckDB SQL分析任务构建的Text 2SQL LLM。	帮助用户利用DuckDB的全部功能。	特定于DuckDB，可能不适用于其他数据库系统。
Langchain	在SQL数据库上构建问答链代理的应用框架。	支持构建问答链代理，运行生成的查询并从错误中恢复。	需要一定的技术背景来构建和维护问答系统。

智能数据分析系统架构（独立开发）

在这里插入图片描述

可视化方法

apache/echarts

数据集

yechens/NL2SQL: Text2SQL 语义解析数据集、解决方案、paper资源整合项目

DB-GPT-Hub/README.zh.md at main · eosphoros-ai/DB-GPT-Hub

应用场景示例

1. 业务分析场景

销售数据分析
用户行为分析
运营效果分析

2. 决策支持场景

实时数据监控
趋势预测
异常预警

3. 报表自动化

日常运营报表
定期分析报告
自动化数据简报

结语

Text2SQL和智能数据分析正在改变我们与数据打交道的方式。它让数据分析变得更加民主化，让非技术背景的人员也可以通过简单的自然语言输入来生成复杂的 SQL 查询语句，对于市场运营人员，还可以直接生成可视化数据报表，让每一个人都能轻松掌握数据。未来，随着技术的进一步发展，我们将看到更多创新应用，让数据分析变得更加简单、高效和智能。