收藏！从NL2SQL到NL2MQL：大模型在制造业智能问数的实战指南

文章分析了NL2SQL在制造业应用中的三大局限：指标语义复杂、口径不统一和数据模型多变，提出NL2MQL解决方案。NL2MQL通过指标体系作为核心单元模型，屏蔽底层SQL复杂性，实现业务语义对齐。文章详细介绍了系统架构设计、四阶段实施步骤及关键技术细节，强调指标体系建设是企业知识体系的重要组成部分，为AI在制造业落地提供可行路径。

模型优化师

802人浏览 · 2025-09-29 18:05:03

模型优化师 · 2025-09-29 18:05:03 发布

引子

在自然语言问数的发展路径中，NL2SQL（自然语言转SQL）是最常见的技术路线。但在制造运营场景中，它其实很难取得理想效果，不断的踩坑复盘，大致列了一些主要的原因：

1. 指标语义复杂：制造业指标并不是简单的表字段拼接，比如“OEE”“直通率”往往需要跨多张表计算，还涉及停机时间、合格率、计划产量等逻辑组合。NL2SQL很难直接生成这种复杂口径的SQL。
1. 口径不统一：同样的“良品率”，不同工厂、不同部门口径各不相同，SQL只是“查询语言”，无法承载这些业务语义差异。
1. 数据模型多变：MOM系统中存在多级BOM、工序工艺路线、派工批次等复杂结构，SQL查询极易受数据模型变更影响，不够robust。

所以在制造业里，NL2SQL容易陷入“生成不准、执行不稳、解释不清”的困境。

对比来说，MQL（Manufacturing Query Language）在一开始就把“指标体系”作为核心单元模型，屏蔽了底层复杂的SQL和表结构，用统一的指标语义表达业务问题。

• 对齐业务语义：直接面向指标（如OEE、MTTR、直通率），减少对SQL细节的依赖。
• 增强跨领域适配：在MQL中可以预定义工厂的指标体系，支持不同企业的口径差异。
• 提升准确性与可维护性：生成的不是SQL，而是可解释、可复用的指标逻辑表达式，便于校验与演进。

这也是我认为AI智能问数的下一阶段不应停留在NL2SQL，而是要进化到NL2MQL（Metrics Query Language），并且现在的技术已经足够成熟。所以我想出了一个应该可以落地闭环的NL2MQL的方案，当然我们也在这个方向努力。

一、方案概述

NL2MQL是连接业务人员与制造业数据系统的自然语言接口，通过大语言模型（LLM）将非结构化自然语言查询转换为指标结构化MQL(Metrics Query Language)，实现“用自然语言问数据”的能力。

核心价值：

• 降低业务人员使用数据系统的门槛（无需掌握SQL/MQL语法）；
• 确保业务术语与指标体系的精准对齐（解决“同词异义”“异词同义”问题）；
• 支持多领域（生产、销售、仓储等）查询的统一处理。

二、系统架构设计

1. 核心组件

组件	核心功能	技术实现
用户交互接口	接收用户自然语言输入，展示MQL结果或自然语言回答	Web前端界面/API接口
领域分类器	识别用户查询所属业务领域（如生产/销售/仓储）	轻量文本分类模型
元数据存储库	存储各领域的"术语-指标-维度"映射关系	关系型数据库+向量库
元数据检索引擎	基于用户查询和领域标签，检索最相关的元数据	RAG技术（结合语义相似度匹配）
Prompt动态生成器	构建包含领域元数据、通用规则的提示词	模板引擎+动态内容拼接
微调LLM模型	接收Prompt和用户查询，生成初步MQL	基于Llama2的领域微调模型
MQL校验器	检查MQL的语法合规性、指标-维度兼容性	规则引擎+元数据校验接口
反馈学习模块	收集错误案例，用于模型迭代和元数据优化	错误日志分析+增量微调

2. 整体架构

我简单画了下整体的架构流程图，方便理解

1. 主流程：1-17步
用户输入：

业务用户在交互界面输入自然语言查询（“今日A仓库库存周转率”）；

2-3步查询分发：前端将查询文本同步传递给领域分类器（用于识别领域）和元数据检索引擎（为后续检索做准备）；

领域识别：

领域分类器分析文本，这个还是很重要的，返回领域标签（“仓储领域”）及置信度；

5-6步元数据检索：元数据检索引擎结合“查询文本+领域标签”，从元数据仓库中检索最相关的元数据（库存周转率→库存周转次数（M010））；

7-9步Prompt生成：Prompt构造器接收元数据和原始查询，生成包含领域知识的动态Prompt，传递给微调LLM模块；

MQL生成：

LLM模块基于Prompt，将自然语言转换为初步的结构化MQL；

11-12步MQL校验：校验引擎向元数据仓库请求校验规则（指标-维度兼容性），完成多层校验；

13-17步执行与结果返回：校验通过的MQL经MQL引擎转换为SQL，查询底层数据源后，结果通过UI以自然语言形式返回给用户。
1. 分支流程（异常处理）：18-21步
领域澄清（18-19步）：若领域分类器置信度低（需要测试再设定个阈值），触发前端向用户确认领域（您查询的是生产还是仓储指标？），补充信息后重新进入主流程；

MQL澄清（20-21步）：MQL存在歧义（术语映射不唯一），校验引擎触发UI向用户澄清（“效率”是否指设备OEE？），补充信息后重新生成MQL。
1. 闭环优化流程（22-24步）
校验失败的MQL（术语未识别、格式错误）被发送至反馈学习引擎；

23-24步反馈引擎将错误案例转化为增量训练数据，并提出元数据更新建议（如新增术语映射）；定期用增量数据微调LLM模型，同时更新元数据仓库，持续提升系统准确率。

三、实施步骤

阶段1：需求分析与数据准备

目标：明确业务范围、梳理元数据、构建初始样本集。

1. 业务范围界定
这个阶段应该就是整个NL2MQL的最大拦路虎，很多制造业厂商和软件商都卡在这里出不来。因为如果没有指标体系的沉淀，后续再多的模型、Prompt工程都只是“空中楼阁”。
1.1. 输出《业务领域清单》：明确覆盖的核心领域（生产、仓储、质量、维护）及每个领域的核心场景（生产领域的“OEE查询”“产线效率分析”），业务领域也可以称作主题；
1.2. 输出《指标口径收集清单》：也有其他小伙伴命名为指标黑话，主要还是通过业务访谈收集各领域高频术语映射（生产：计划、工单、报工数等等）。
1. 元数据标准化

2.1. 设计元数据模型（核心表结构）：

表名	核心字段	说明
原子指标表	指标ID、指标名称、业务定义、计算逻辑、关联维度ID、数据来源	“订单数量（M001）=count(distinct order_id)，关联维度：时间/区域”
维度表	维度ID、维度名称、层级关系、取值范围、关联字段	“时间（D001）=年/月/日，取值：今日/昨日”
术语映射表	术语ID、术语文本、所属领域、对应指标ID/维度ID、同义词	“OEE”→指标“设备综合效率（M003）”，同义词“设备综合效率”
版本表	版本号、生效时间、变更内容、操作人	支持元数据回溯

2.2. 输出《元数据标准化手册》，并完成首批元数据录入（至少覆盖80%高频指标）。
1. 训练数据构建
3.1. 生成“自然语言→MQL”种子样本：每个领域至少100条，覆盖单指标/多指标、单维度/多维度、含条件/无条件场景；

   样本=（“昨日A线OEE”，{"metric":"设备综合效率（M003）","dimensions":{"时间（D001）":"昨日","产线（D005）":"A"}}）

3.2. 输出《训练数据集规范》，样本格式统一为JSONL（每行一个样本）。

阶段2：核心组件

目标：开发领域分类器、元数据检索引擎、Prompt构造器等核心模块。

1. 领域分类器
1.1. 技术选型：用TextCNN或BERT-base应该都可以；
1.2. 训练流程：

• 用标注数据（每条查询标注领域标签）训练分类模型；
• 优化目标：准确率≥90%，支持多领域标签（“跨生产和仓储”）；

1.3. 输出：领域分类API（输入文本，输出领域标签+置信度）。
1. 元数据检索
2.1. 技术栈：向量库+Embedding；
2.2. 核心功能：

• 元数据向量化：将术语映射表中的“术语文本”转换为向量，存储到Milvus；
• 语义检索：输入用户查询+领域标签，检索Top5最相关的元数据（相似度≥0.7）；

2.3. 输出：元数据检索API（输入查询+领域，输出相关元数据列表）。

以"库存周转率"和"仓储领域"为检索条件,在向量数据库中匹配最相关的3条元数据：

[    {        "term":"库存周转率",        "metric":"库存周转次数（ID:M010）",        "dimensions":[            "时间",            "仓库"        ]    },    {        "term":"A仓库",        "dimension":"仓库（ID:D008）",        "values":[            "A",            "B",            "C"        ]    },    {        "term":"今日",        "dimension":"时间（ID:D001）",        "value":"current_day"    }]

1. Prompt生成
3.1. 设计通用prompt模板（可动态注入）：```plaintext
已知【{领域}】领域的术语对应关系：{元数据列表，每条一行}请将以下查询转换为MQL，需包含：-metric：原子指标名称及ID-dimensions：维度名称、ID及取值（若有）-conditions：查询条件（若有）输出格式为JSON，不包含多余文本。输入查询：{用户查询}输出MQL：
3.2. 功能：接收元数据和用户查询，对话式问答，自动填充模板生成Prompt；
3.3. 输出：Prompt生成API。

阶段3：MQL生成

目标：让LLM理解“业务术语→MQL”的映射能力。

1. 基础模型选型

• 基于私有化部署等考量，中小场景使用开源的Llama2-7B应该就足够了。

1. 微调效果评估
2.1. 定量指标：MQL生成准确率（格式正确+术语映射正确）≥85%；
2.2. 定性评估：人工检查歧义术语处理能力（“效率”这个关键词可能在不同的领域均有定义，需要问答方式来精准定位）；
2.3. 输出：微调后的LLM模型或者API都可以。

{"metric":"库存周转次数（ID:M010）","dimensions":{   "时间（ID:D001）":"current_day",   "仓库（ID:D008）":"A"   }}

阶段4：MQL校验

目标：过滤无效MQL，确保输入下游系统的查询合法。

1. 校验规则设计
1.1. 语法校验：检查MQL是否包含必填字段（metric/dimensions）、格式是否为JSON；
1.2. 兼容性校验：验证指标与维度是否匹配（如“订单数量”是否支持“时间”维度）；
1.3. 版本校验：确认使用的指标版本为当前生效版本；
1.4. 输出：《MQL校验规则手册》。
1. 引擎开发
2.1. 技术实现：规则引擎（如Drools）+元数据接口调用；
2.2. 功能：接收MQL后，依次执行上述校验，返回“通过/不通过+错误原因”；
2.3. 输出：MQL校验API。
1. 结果返回
3.1. 校验通过的MQL发送至MQL引擎执行；
3.2. 最终将数据结果转换为自然语言返回给用户。

四、关键技术细节

1. 元数据检索优化
1.1. 先用领域过滤，再用语义匹配检索：先按领域过滤元数据，再计算语义相似度，提升检索效率；
1.2. 定期更新向量数据库：元数据新增/修改后，自动重新生成向量并更新索引。
1. 歧义处理机制
2.1. 检索到多个可能的术语映射（“效率”对应“OEE”和“生产效率”），Prompt构造器自动加入“请根据上下文选择最可能的指标”提示；
2.2. 若LLM生成的MQL存在歧义，校验引擎触发UI向用户澄清（“您查询的‘效率’是指设备OEE还是生产效率？”）。

五、结语

事实上，指标体系的建设，不仅是NL2MQL的起点，更是企业知识体系建设的一部分。一个组织如果缺少统一的知识与指标语言，就像个人缺少思维框架一样——碎片化、低效、难以传承。

这也是我在之前的文章里提到过的：无论是企业转型，还是个人职业发展，知识体系的沉淀都尤为重要。企业需要构建覆盖战略、运营、制造、质量的指标与知识框架，才能让AI真正落地.而个人同样需要整理自己的知识体系，就像是金字塔原理说的“清晰的结论之上，需要有结构化的思维支撑”，才能持续复利。

最后

为什么要学AI大模型

当下，⼈⼯智能市场迎来了爆发期，并逐渐进⼊以⼈⼯通⽤智能（AGI）为主导的新时代。企业纷纷官宣“ AI+ ”战略，为新兴技术⼈才创造丰富的就业机会，⼈才缺⼝将达 400 万！

DeepSeek问世以来，生成式AI和大模型技术爆发式增长，让很多岗位重新成了炙手可热的新星，岗位薪资远超很多后端岗位，在程序员中稳居前列。

在这里插入图片描述

与此同时AI与各行各业深度融合，飞速发展，成为炙手可热的新风口，企业非常需要了解AI、懂AI、会用AI的员工，纷纷开出高薪招聘AI大模型相关岗位。
在这里插入图片描述
最近很多程序员朋友都已经学习或者准备学习 AI 大模型，后台也经常会有小伙伴咨询学习路线和学习资料，我特别拜托北京清华大学学士和美国加州理工学院博士学位的鲁为民老师给大家这里给大家准备了一份涵盖了AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频 全系列的学习资料，这些学习资料不仅深入浅出，而且非常实用，让大家系统而高效地掌握AI大模型的各个知识点。