工业企业的数据通常不会只在一个库里。生产数据在 MES，设备数据在 SCADA，质量数据在 QMS，销售数据在 CRM，财务数据在 ERP。管理者想查"3号产线上周的设备故障率和良品率"，答案可能分布在两个完全不同的系统里。

生产运营需要实时看数据，质量管理需要追溯不良品原因，设备管理需要掌握故障规律——但数据分散在不同系统里，普通用户根本不会写 SQL，技术人员也没时间一个个查。

用自然语言直接查数据是解决这个问题的思路。但实际做起来，会碰到四个绕不开的工程难点。本文结合 AIGS 框架的智能问数架构，分享这些难点和解法。

一、先搞定最基本的事：让 AI 理解你的表结构

第一个难点看起来简单，实际上最容易翻车：AI 不知道你的表里存的是什么。

工业数据库的表名和字段名往往不直观。t_prod_line 是产线表还是产品表？qty 是产量还是库存？status 是设备状态还是订单状态？AI 不理解字段含义，生成的 SQL 就会答非所问。

解法：给每张表写一份"说明书"。 包括这张表的业务用途、每个字段的中文含义和取值范围、几个常见查询示例。这些描述作为上下文输入给 AI，帮助它准确理解该查哪张表、哪个字段。

不同业务模块的表结构描述重点不一样。生产管理的表要说明产线编号、班次、产品型号之间的关联；质量管理的表要突出检验批次、不良类型、不合格数量；设备管理的表要写清楚设备编码、故障类型、维修状态。花在表结构描述上的时间，直接决定了后续查询的准确率。

二、数据分散在多个系统里怎么办

工业企业的数据分布在多个系统中，不同系统可能用不同的数据库。用户问一个问题，可能需要跨库查询。

解法：配置多数据源，让 AI 自己判断该查哪个库。 查询时先让 AI 根据用户问题和各数据源的描述，判断涉及哪些系统，然后分三种情况处理：

• 只需要一张表就能回答 → 直接生成 SQL 查询
• 需要多张表但各查各的 → 各数据源分别查，结果各自返回
• 需要多张表关联分析 → 通过关联字段合并查询结果

关键是每个数据源的描述要足够清晰，让 AI 能区分"生产数据该查 MES"、"设备数据该查 SCADA"。如果描述模糊，AI 就可能查错库。

框架的数据源选择器支持 MySQL、PostgreSQL、Oracle、SQL Server 四种数据库类型，基本覆盖了工业企业的主流数据库。

三、最大的坑：安全——不能让 AI 执行危险操作

让 AI 自动生成 SQL 并在数据库上执行，最大的风险不是查不准，而是安全问题。如果 AI 生成了 DROP TABLE 或 DELETE FROM 语句，后果不堪设想。

这不是危言耸听。在测试中，某些边界情况下 AI 确实可能生成带有写操作的 SQL，尤其是用户的问题比较模糊时。

解法：在 SQL 执行前做两道安全校验：

1. 语句类型检查：只允许以 SELECT 开头的查询，DROP、DELETE、UPDATE、INSERT、ALTER 等写操作全部拒绝
2. 危险关键词和注释符检查：即使语句以 SELECT 开头，也会检查是否嵌入了危险关键词或 SQL 注释符，防止通过注释注入攻击

这两道校验构成多层防护。尤其是生产环境中，建议把安全策略配置为默认开启，不要指望用户自己注意。

四、查出来的数字用户看不懂怎么办

"上周 3 号产线良品率 96.7%"——这个数字单独拿出来，用户不知道是高还是低，也不知道趋势是升还是降。工业用户对原始数字的敏感度远低于对图表的敏感度。

解法：查询结果自动生成可视化图表。 框架内置了 ECharts 图表渲染服务，根据数据特征推荐合适的图表类型：各产线对比用柱状图，月度变化用折线图，故障类型分布用饼图，多维对比用雷达图。用户看到的是直观的图表而不是一堆数字，理解成本大幅降低。

有个实操经验：图表默认开启比让用户自己选择更有效。工业用户往往不是技术人员，让他们选"看柱状图还是折线图"会增加认知负担。系统自动推荐，用户直接看结果，体验更好。

五、Excel 也能直接查

工业场景中还有一个常见情况：大量数据以 Excel 形式存在——生产日报、质检报告、设备巡检表，没导入数据库，散落在各个人手里。

解决思路是把 Excel 上传后直接变成可查询的数据源。每行数据作为 JSON 对象存储，表头信息单独记录，查询时通过 Text2SQL 实现查询操作。用户上传一份生产日报，直接问"哪个班次的产量最高"，Agent 自动解析并返回结果。

大文件需要分批处理，每批 1000 行，通过信号量控制并发，避免内存溢出。这个细节不注意，上传一个几万行的表格就可能把服务搞崩。

六、一个实际场景：质量管理数据怎么查

以质量管理场景为例，展示完整的查询链路：

质量主管问"最近三个月各供应商的来料不合格率趋势"。

系统处理过程：意图识别判断这是数据查询 → 数据源选择器定位到 QMS 数据源 → AI 根据表结构描述生成 SQL 查询 IQC 检验记录表 → 安全校验通过后执行 → 结果交给 AI 解读并生成 ECharts 折线图 → 主管看到趋势图，某供应商的不合格率从 2% 跳到 8%，直接在对话中追问"这个供应商主要不合格项是什么"，系统继续深挖数据返回。

整个过程质量主管不用写一行 SQL，不用知道数据在哪张表里，用业务语言就能完成数据查询和分析。

七、实战建议

1. 先单表单数据源跑通，验证 Text2SQL 的准确率，再逐步扩展到多数据源
2. 数据源描述一定要写清楚，这是 SQL 生成准确率的基础，没有捷径
3. SQL 安全策略必须默认开启，只允许 SELECT，做好危险关键词和注释符的过滤
4. 图表可视化默认开启，工业用户对数字不敏感，图表比文字更有效
5. 意图识别前置，避免每次查询都走数据库，通用问题应该走知识库或对话兜底

总结

工业企业多数据源查询的核心是解决四个问题：让 AI 理解表结构、处理多数据源路由、保证 SQL 安全、让查询结果看得懂。这在工业 AI 数字化转型中属于"数据能力层"的建设——把分散在 MES、SCADA、QMS 里的数据统一变成可查询的智能服务。JBoltAI 的智能问数架构把这些能力做了标准化封装，包括数据源查询节点、聚合对话节点、ECharts 图表渲染，工业企业不需要从零搭建 Text2SQL 和安全校验，聚焦在业务数据描述和场景设计上就能跑起来，是一种可快速落地的方案。