还在手动跑数据？用Dify搭建智能问数，3步让数据自己开口说话

什么是智能问数？为什么企业需要它

智能问数（Text-to-SQL / NL2SQL），本质上是让大模型听懂业务方的"人话"，自动翻译成数据库能执行的SQL，查完数据还能帮你分析一波数据。

一句话总结：智能问数不是替代数据团队，而是把数据团队从"取数工具人"解放出来，去做更有价值的分析。

智能问数的工具选型：三条路径全对比

市面上 Text-to-SQL 的工具不少，在 Dify 中主要有三种获取方式，各有适用场景：

路径一：Dify Marketplace 插件市场（推荐新手）

Dify 自带的插件市场里已经有不少 Text-to-SQL 工具，直接安装即可使用。

优点：开箱即用，配置简单，适合快速验证

缺点：通用性强但定制性弱，复杂场景可能不够用

适用场景：POC 验证、简单查询、标准数据库结构

路径二：GitHub 开源工具 + 自定义插件封装

如果插件市场的工具不够用，可以去 GitHub 找更专业的 Text-to-SQL 项目，封装成 Dify 自定义插件。

优点：灵活度高，可以针对特定数据库优化

缺点：需要一定开发能力，维护成本中等

适用场景：中等复杂度查询、非标准数据库结构

路径三：完全自研（高阶玩家）

如果你的企业对安全性、合规性、隐私性有极高要求，数据不能经过第三方，那就走自研路线。

优点：完全可控，安全性最高

缺点：开发周期长，维护成本高

适用场景：金融、政务等强合规行业

选型建议： 90% 的团队，路径一+路径二的组合就够了。先把流程跑通，再逐步优化。别一上来就自研，容易陷入"完美主义陷阱"。

Dify 智能问数工作流设计

一个完整的智能问数工作流，不是简单丢一个 Text-to-SQL 工具就完事，而是需要一套完整的工作流。

一个成熟的智能问数工作流包含5 个关键节点：

① 意图识别 → ② Text-to-SQL → ③ SQL校验 → ④ 数据库查询 → ⑤ 数据分析

节点一：意图识别（决定走哪条路）

作用：分析用户到底想查什么，路由到不同的问数分支。

为什么需要意图识别？因为不同业务场景的数据表结构完全不同。查订单走订单表，查投诉走投诉表，如果不做意图区分，Text-to-SQL 很容易"张冠李戴"。

实践要点：

• 用 LLM 节点做意图分类，输出结构化的场景标识
• 每个场景绑定对应的表结构说明（Schema）
• 意图模糊时，主动追问用户确认，别瞎猜

节点二：Text-to-SQL（核心大脑）

作用：将用户的自然语言转化为可执行的SQL语句。

这里以 Dify 中 database 插件的 Text-to-SQL 能力为例。配置时有一个极其关键的细节：

Prompt 中必须包含以下信息：

• 当前日期时间（大模型不知道"今天"是哪天）
• 数据库类型和版本（MySQL / PostgreSQL / 其他，语法有差异）
• 完整的表结构说明（表名、字段名、字段含义、字段类型）
• 关键业务ID的映射关系（如 status=1 代表"已下单"）
• 查询规则约束（只读查询、LIMIT 限制、禁止DDL等）

踩坑提醒： 很多人配好 Text-to-SQL 就觉得完事了，结果查出来的数据各种不对。90% 的问题出在 Schema 描述不够详细——大模型不理解你的字段含义，怎么可能生成正确的SQL？

只能查询数据库中真实存在的表和字段。
只允许执行 SELECT 查询。
禁止 INSERT、UPDATE、DELETE、DROP、ALTER、TRUNCATE 等操作。（这里的数据库为了安全起见必须设置只读权限账号）
非聚合查询默认 LIMIT 100。
涉及xxx数量时，优先使用 COUNT(DISTINCT xxx)。
涉及xxx数量时，根据业务定义使用 COUNT(DISTINCT xxx)。
涉及xxxx数时，根据业务定义使用 SUM(recruiting_num)。
涉及“最多”“最高”时使用 DESC。
涉及“最少”“最低”时使用 ASC。
涉及时间时必须明确时间范围。
不允许查询敏感字段。
如果用户问题无法通过现有数据回答，不要编造 SQL。
SQL 必须可以直接在当前数据库执行。
优先使用索引字段进行查询。
查询结果需要具备明确的业务含义。

节点三：SQL校验（安全防线）

作用：对生成的SQL做二次检查，防止"翻车"。

校验规则建议：

• 禁止危险操作： DELETE / DROP / TRUNCATE / ALTER 等写操作一律拦截
• 权限控制：检查查询的表是否在用户权限范围内
• 性能保护：加 LIMIT 兜底，防止全表扫描拖垮数据库
• 语法校验：确保SQL语法正确，避免执行报错

这一步很多教程会跳过，但生产环境必须做。一旦大模型"幻觉"出一个 DELETE 语句，后果不堪设想。

节点四：数据库查询（拿数据）

作用：执行校验通过的SQL，拿到原始数据。

实践要点：

• 使用只读账号连接数据库，从源头杜绝写操作
• 设置查询超时，防止慢查询卡死整个工作流
• 大数据量结果做截断处理，别把10万行数据全塞给大模型

节点五：数据分析Agent（让数据会说话）

作用：将查询结果转化为用户能看懂的结论。

这一步决定了用户体验的上限。同样一份数据：

·差的输出：{"order_count": 12580, "refund_count": 320}

·好的输出：7月订单总量12580单，退订320单，退订率2.54%。环比6月订单增长15.3%，退订率下降0.8个百分点，整体趋势向好。建议关注华东区退订率偏高问题。

实践要点：

• 配置数据分析的Prompt，要求输出结论 + 趋势 + 建议
• 支持多轮对话，用户可以追问
• 复杂分析场景可以接入图表生成能力

智能问数落地避坑指南

理论讲完了，分享几个实战中踩过的坑，帮你少走弯路：

智能问数的核心公式

最后总结一个公式，帮你建立完整的认知框架：

智能问数 = 指标体系 + 语义理解 + Schema检索 + Text-to-SQL + SQL校验 + 数据分析 + 安全治理

注意，Text-to-SQL 只是其中一环。真正决定智能问数成败的，是指标体系的规范性和业务语义的准确传达。

如果你的智能问数效果不好，先别急着换模型、调Prompt，回头看看你的指标体系和Schema描述做得够不够好。

写在最后

智能问数不是炫技，而是实打实地解决"取数慢、分析难"的业务痛点。

用 Dify 搭建智能问数系统的关键路径：

1. 选对工具— Marketplace 插件起步，自定义插件进阶
2. 设计好工作流— 意图识别 → Text-to-SQL → SQL校验 → 查询 → 分析
3. 做好安全治理— 只读账号 + 权限校验 + 敏感脱敏 + 日志审计
4. 统一指标口径— 这是地基，地基不稳全白搭

如果你正在做或准备做智能问数，欢迎在评论区聊聊你遇到的坑。