生产制造：产线良率与产量问数，现场问题当场有数

制造现场每天产生大量数据，产线良率、产量、停机时长都在其中。这些数据随手可问，意义在于让现场立刻去排查故障、改进工艺，不必等报表出来再复盘。多数工厂把这些指标锁在滞后报表与IT排期里。班组长若能在产线旁用自然语言问出“昨夜A线良率几何、哪个工序拖了后腿”，有助于更快定位问题、及时调整，数据才更有可能被有效利用。本文从制造现场的数据结构讲起，拆解自然语言问数的技术链路，以及它如何让数据落到具体动作上。

现场两套系统的数据割裂

MES（制造执行系统）脱胎于车间管控需求，记录工单开工、设备停机、工序良率、物料消耗这类产线事件。ERP（企业资源计划）源于财务与供应链的统筹逻辑，承载订单、库存、成本与排产。两套系统由不同团队在不同时期建设，字段命名和统计口径各自一套。

查良率就是典型例子。MES里良率字段可能命名为 yield_rate，ERP侧没有这一项，要计算停机时长得先关联设备状态表与工单时间表。班组长脑中想的是"按班次看A线良率"，落到系统里是三张表联查加上时间窗口过滤。这类问题在多数工厂要写进IT工单，经过排期、取数、回传，隔天才能见到结果。

固定报表的覆盖盲区

固定报表解决了标准看板问题。班组长每天盯的看板、周会用的汇总表，都是提前设计好的查询固化。但现场变化快过报表的设计周期。

换线之后想看新产品的工序分布，月底想按设备维度复盘停机，固定报表可能无法覆盖。等IT排期，生产决策的时效性可能受到影响。班组长想换个维度看数，在固定报表体系里等于重新提一次需求。

自然语言问数怎么落地

把"昨夜A线良率"变成数据库能执行的查询，核心技术是自然语言转SQL（NL2SQL）。

第一步是读取生产库Schema。Schema是数据库对表结构的约定描述，系统连接MES或数据仓库后，自动拉取表清单、字段与注释。字段注释是整条链路的重要环节之一。工厂数据库字段多是英文缩写或拼音，良率对应 yield_rate，停机时长对应 downtime_min，产量对应 output_qty。把中文业务词和物理字段建立映射，模型才知道用户说的"良率"去哪张表取。

第二步是生成查询。模型结合Schema与业务词表，把自然语言翻译成带正确表连接、过滤条件和聚合方式的SQL。这一步通常引入检索增强（RAG），补充字段含义与口径规则。比如"良率"在甲工厂定义为良品数除以投产数，在乙工厂要扣除返工批次，RAG把这类口径带进生成过程，有助于降低模型套错公式的风险。生成后的SQL还要经过语法与权限校验，防止越权查全表。

第三步是按问题类型返回不同形态。趋势类问题，例如"近七天A线日良率"，系统自动绘制折线图，斜率与拐点一眼可见。多维度明细，例如"各工序停机时长排名"，输出排序表格，方便直接引用。意图识别在很大程度上影响结果形态，带时间轴的聚合走图，逐条列举走表。

第四步是多轮追问下的下钻。用户接着问"那B班次呢"，系统要继承上一轮上下文，把筛选从整条产线收窄到指定班次，再下钻到具体工序。这依赖对话状态管理，把前序条件自动带入后续查询，用户不必每次重复限定词。

第五步是结果可导出。生成的图表与表格能一键导出，不必手工拼报表。

跨多表联查的准确率通常低于单表查询，而工厂现场多数问题恰好落在多表联查区间。这是落地时应当优先投入评测与打磨的环节，不能只看演示环境的单表效果。

数据要落到动作上

不少工厂把"建了数据中台、接了BI"等同于用好了数据。实际衡量标准更简单：这些数据有没有帮现场把事做成。产线异常时，班组长当场问出"哪台设备近一小时停机最多""哪个工序良率突降"，故障点马上锁定，不用等日报。工艺改进同样依赖随手可取的趋势数据，哪道工序长期偏低、哪个参数调整后良率回升，都要靠随时能问出来的明细去验证。要走流程、等排期、靠专人取的数据，可能难以及时支撑现场决策。能被现场随手调取的实时数据，更有可能转化为排查故障和工艺改进的具体动作。

小艾智能体的智能问数报表系统可基于NL2SQL实现自然语言转SQL并生成图表。系统可支持自动读取生产库Schema，借助字段注释可将“良率”“停机时长”等业务词映射到物理字段。趋势指标可自动输出折线图，多维度明细可输出表格，多轮对话可支持逐层下钻到班次与工序。报告可支持导出，用于班前会。整套系统可支持私有化部署，生产数据可在厂区本地留存，通常无需离开内部网络。