惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

M
MIT News - Artificial intelligence
WordPress大学
WordPress大学
GbyAI
GbyAI
S
SegmentFault 最新的问题
量子位
爱范儿
爱范儿
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
MyScale Blog
MyScale Blog
人人都是产品经理
人人都是产品经理
博客园 - 叶小钗
aimingoo的专栏
aimingoo的专栏
V
Visual Studio Blog
U
Unit 42
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
The Cloudflare Blog
Stack Overflow Blog
Stack Overflow Blog
博客园 - 聂微东
J
Java Code Geeks
The GitHub Blog
The GitHub Blog
Y
Y Combinator Blog
IT之家
IT之家
Martin Fowler
Martin Fowler
宝玉的分享
宝玉的分享
雷峰网
雷峰网

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
5000字教程:用AI实时查询数据库,自动生成可视化图表
饼干哥哥 · 2025-05-20 · via 人人都是产品经理

在数据分析工作中,如何快速从复杂数据库中提取信息并生成直观的可视化图表,一直是业务人员的痛点。本文带来一份超详细的5000字教程,教你如何利用Dify工作流结合AI技术,实时查询数据库并自动生成可视化图表。从基础的SQL查询到复杂的多表关联,再到借助知识库实现精准查询,最后通过Echarts生成专业图表,全方位提升数据分析效率。

现在基本上每个上点规模的公司都会有数据库,但想要让业务同学自己去写SQL取数,其实是不现实的,很多小白会觉得SQL甚至比Python还要难学。

现在,不怕了,我们可以用AI来帮我们完成数据库的查询,甚至生成文字洞察和可视化图表。

之前我写过一篇教程,用MCP的方式,让Cursor自动查询数据库并完成表结构的修改等操作。

但说实话,MCP的方式目前还是很不稳定的,不适合用在实际工作中。

更不用说把Excel直接扔给AI做分析的方式:1. 数据安全问题;2. 出来的结果准确率很低。

怎么办?

最好的方式就是在本地部署工作流,直接对接数据库,通过给SQL代码然后执行的方式来查询,准确率最高。

但数据库如果量比较大,又怎么才能让AI知道我表结构,并给出准确代码呢?答案是搭建数据库表结构的知识库。

以下就是具体怎么做的教程目录:

效果及逻辑如下:

给定一个查询需求后,AI会到知识库查询表结构,并据此生成SQL语句,执行后,调用Echarts图表的能力,以及数据科学家的Agent,最终生成一个图文并茂的可视化查询结果。

文末附工作流DSL文件获取方式数据准备

我准备了一个数据库,里面包含了销售表、产品表、地区表,可以实现复杂的多表查询,也是在实际业务中很常见的需求场景。

新增节点

在Dify里做SQL查询,逻辑是:1. 先用AI生成SQL代码  2. 执行SQL代码

这里可以直接搜索database工具,里面就包含了这两个功能:Text to SQL 和 SQL Execute

点去授权,按以下形式输入你的数据库地址和账号密码,以mysql为例:mysql+pymysql://root:8455be@152.12.12.12:3306/bgggtest

OK,接下来我们就来具体实现SQL查询。

模块一:SQL查询

为了让大家能理解我搭建这个工作流的逻辑,我逐步演示给大家看。同时,这也是从0开始搭建一个AI工作流的方式:小步快跑、不断测试。

坐稳扶好,马上出发!!!

假设SQL查询有分级。。。

第1级 青铜:指定表格、字段名称查询

这也是最简单的,如图,直接告诉AI我要查哪个表的什么字段的内容

就能得到如下结果,这步是为了来验证AI的运行是否有问题。

我们不可能说每个查询语句都自己写清楚表格和字段(如果是这样的话我自己都写完SQL了 还要AI干嘛)

所以这里,我们再加一步,把数据库的表结构全部导出来给到AI

那问题来了,怎么拿到数据库表结构呢?

我的方案是用Navicat,链接数据库后,如图,右键转储SQL文件-仅结构

就能得到以下的建表语句:

接下来要做的就很简单了:把提示词放到生成SQL语句的提示词里即可。这里就不重复演示了。

做了一下测试,继续验证数据的正确性统计每天销售额

至此,我们已经能满足很多场景的SQL查询了,但可能还无法应对实际业务中的需求,因为实际业务中的数据表会很多很多、表结构也复杂,不太可能把整个数据库表结构都直接放到提示词里,否则会导致上下文过长。

怎么办呢?

第3级 黄金:把表结构放到知识库里,调用RAG查询

如果可以让AI在查询的时候,顺手去查表结构,就好了!!!这就是解决方案。新建数据库表结构知识库

首先,在Dify创建知识库,如下图:

还记得之前我们导出来的数据库结构的文件吗,把它们放到txt文件里,然后上传。

知识库设置关键点:1. 如下图,正常来说按默认配置就好了,预览块看右边的分块结果,要确保一个Chunk一个表

2. 索引方式要选 高质量 的,否则永远查不出来结果

例如下面左边就是经济(无法击中)、右边是高质量(能准确查到)

3. 检索设置中的 Top K 可以根据数据复杂程度选高一点,正常来说一次查询最多就3-5个表做连接。如果再多的话,或许就不太适合用AI 了。

新建知识检索节点

回到我们的工作流,在开始的之后,新建一个知识检索,也就是说,在用户对话的时候,就根据用户的需求,提前先到知识库里找好需要用到的表结构,喂给AI。

此时,因为我们需要用到知识检索的结果,就要用用LLM大模型节点来生成,只需要设置好提示词,以及把检索到 的表结构通过上下文的形式放进去即可:

完整提示词:

但注意,大模型跑出来的SQL语句里面有很多换位符等需要清洗,这里我们简单加个Python代码执行

目前的工作流和对话效果如图所示,也就完成了我们第一个模块:text2SQL

升级测试需求,做多表查询:查询各地区销售数据

得到的SQL代码:

最终运行结果(节选示例):

结果没问题的✅

番外:调用Agent能力

本来,我想测试Dify用Agent的查SQL的能力。

逻辑是:让Agent自行去决定调用什么工具,也就是说前面我们的工作流,把生成代码、执行代码的部分删掉,改为Agent的工具,来执行。

结果不知道是bug还是什么问题,一直跑不出来。

虽然工作流看上去比较简单了,但实际上工作量也没少多少,还依赖大模型的工具调用能力,不确定性比较高,不适合在实际业务中使用。大家可以自己试一下。

模块二:可视化图表

接下来完成可视化图表的部分。

1.0 青铜

首先,新增插件Echarts图表生成

但这个工具目前只有三种图可以用:线性图(折线图)、柱状图、饼图。正常来说也是最常用的。

继续来看我怎么从0开始创建这个工作流的。

刚开始,我肯定不知道这个组件怎么用,所以要先看看这个图表的逻辑是什么样的,如下图,随便填数据

得到的图表是这样的,我们就明白了组件里的参数怎么填:标题:很好理解数据:就是y轴上的数据X轴:就是x轴上的标签或者数据显示

柱状图和饼图都是一样的数据结构:

OK,测试后,我们就明白了:现在的问题就变成了怎么把sql查询出来的结果,转成Echarts需要的数据结构?

有两种方法可以解决

方法一:用Dify内置工具参数提取器

适用场景:这个方法本质还是用AI去提取数据,所以适合数据量比较小的时候,上下文不大,才不容易出错。

参考提示词:## 任务从JSON数据中提取出不同的数据参数,用于生成echarts图表

然后再把提取器的数据给到图表中引用即可,如图:

方法二:AI编程,写一个脚本从JSON中提取出数据。

适用场景:查询出来的数据量比较大的时候,用代码处理不容易出错。

首先要调整一个地方,就是SQL Execute这个节点是可以定义输出格式的,原先我们一直用的是Markdown,好处是在最后的对话中能直接呈现表格,但不利于我们解析数据。要改成JSON

现在看下这个节点输出的SQL结果长什么样:计算2021年5月的每日销售

就得到以下的JSON数据格式(节选示意)

根据这个输入,就可以让Deepseek V3帮我们写一个Python语句了

大家也可以直接用我的:

这里的一个麻烦的地方就在于SQL运行后的名字的不确定,所以就不能直接用名字去获取,例如item[‘日期’]

而是改用数字的形式 例如 list(item.values())[0] 这样

同时,用代码的方式,标题就要再用一个AI节点来生成了,相对来说比较麻烦。

除非是流程非常确定的情况下,否则不推荐使用这种方式。

这样我们就初步完成了可视化图表的模块。

为了让结果更丰富,我们可以新增一个数据科学家的AI节点,让AI做一段定性的文字分析,参考提示词:

这样就像模像样了。

接下来解决另一个问题:

前面我们做的案例是线性图表的,难道接下来要对柱状图、饼图都做一样的流程吗?如果后面有了更多图表,岂不是很麻烦?2.0 白银

所以,我们就需要在前面新增一个判断用哪种图片的节点,然后让AI自动选择好后,呈现出合适的可视化类型。

怎么做呢?

还记得我们的参数提取器吗,它本身就是一个AI的运行逻辑,所以我们可以在里面新增一个ChartType的参数,同时在指令里也给出对应的要求和示例,如下图:

然后在参数提取器的后面新增条件分支,如下图,一个类型对应一个图表,而每个图表都是引用一样的参数即可。

最后,为了让AI回复部分用同样的参数,我们需要新增一个会话变量chart_var

然后在每个图表后面都新增一个变量赋值的节点,把对应的图表结果都赋值给它,这样直接回复的部分直接引用这个chart_var就好了。

最终效果还是不错的。

本文由人人都是产品经理作者【饼干哥哥】,微信公众号:【饼干哥哥AGI】,原创/授权 发布于人人都是产品经理,未经许可,禁止转载。

题图来自Unsplash,基于 CC0 协议。