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

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

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

维度传统方式智能问数查询方式写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. 统一指标口径— 这是地基，地基不稳全白搭

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

JOTO 企业落地观察

• 企业部署智能问数系统时，首要瓶颈往往不在模型能力，而在业务语义与数据库Schema的对齐质量；RAG知识工程需前置构建结构化指标词典与字段业务映射表，而非仅注入原始表结构文档。
• SQL校验环节不可简化为语法检查，必须嵌入权限上下文与业务规则引擎（如“退订率=退订数/订单数”），否则分析结论易因口径不一致而失真。
• 意图识别节点实质是轻量级业务路由网关，其设计直接影响系统可扩展性；若采用LLM分类，需配套建设可维护的场景标签体系与动态Schema绑定机制，避免硬编码导致迭代僵化。
• 安全治理不能仅依赖数据库只读账号，必须在工作流中显式植入字段级脱敏策略与查询结果截断逻辑，这对FDE驻场共创中客户侧数据主权诉求构成刚性支撑。