质量管理问数：不良率与客诉怎么算得又细又准

质量管理的瓶颈已经从数据采集转移到数据分析的深度与主动性。企业手里不良率、PPM、客诉记录越来越全，真要用这些数据提前发现问题、拦住客诉，分析却还停在每周一张汇总表。若能把自然语言问数能力架在质量数据库之上，质量工程师有助于随时切维度、看趋势、追根因，推动从被动救火向主动预防转变。本文沿质量数据能回答的问题、当前分析短板、技术链路与落地价值讲清楚。

质量数据能回答什么

质量数据的价值，不仅在于存储量，更在于能被切成多细的维度来回答问题。平均不良率会盖住结构问题，这是分析的第一课。

PPM 表示每百万件中的不良件数，等于不良率乘以一百万。精密制造用 PPM，是因为百分比精度不够看细微波动，10000 PPM 才对应百分之一。

分层法把数据按班次、设备、供应商等维度切开看，是质量分析的基本动作。一条线日产十万颗、整体 100 PPM，分层后夜班那一半产能里 PPM 是 180，白班是 20，平均数 100 可能掩盖夜班的问题。只看总数，局部异常发现不了。

统计过程控制（SPC）的基线做法是给每条产线、每个产品算近 90 天 PPM 均值，实时值偏离基线多个标准差就报警。这是从数据里发现问题的常见做法之一。

帕累托排序按 defect_type 聚合缺陷类型，少数几类占了大部分不良，先打头部，改善资源才花在对的地方。

三个数据分析的短板

分析可能较多停留在汇总层。周报只给平均数，分布里的尖峰难以看到，比如某班次、某设备的小幅抬升可能被总数掩盖，等它变成客诉才被注意到。

想下钻就得临时拉数。要看“哪个工序、哪个班次在拉高不良率”，得重新写 SQL 或找人导表，这可能造成较多时间消耗。

预防一直缺抓手。缺陷抬头前没有预警，客诉来了才反查。工程师难以用历史数据快速查询“这类缺陷过去在哪些条件下出现”，预防规则就建不起来，可能反复出现同类问题。

从业务词到可执行 SQL

解决这些问题的一种重要方式是一层自然语言问数能力，技术上叫 NL2SQL（natural language to SQL）。系统读取数据库 schema（表结构与字段），把"不良率""PPM""客诉数""基线"这类业务词映射到真实列。

这里主要的工程工作量之一在字段注释映射。不良率未必是一个现成列，它可能由不良品数除以生产总数实时算出，列名也常是 defect_ratio 或 bad_rate。系统启动时扫描表结构，把中文业务别名挂到物理字段上，提问"本月各产品不良率"有助于落到正确计算。

第二步是生成与执行的循环。模型产出 SQL 后直接跑，遇到语法错或字段不存在，把报错回灌给模型重新生成，直到能执行为止。这个自我纠错循环把"看起来对的 SQL"压成"能跑的 SQL"，是问数系统能否可用的重要环节。大模型层可接 DeepSeek、GPT-4 或智谱 AI，按场景切换，与具体库结构解耦。

从发现到预防：图表、下钻与预警

问数系统产出的不只是表格。时间序列的不良率走折线，看的是斜率而不是单点，连续上升比一次超阈更危险；不同缺陷类型的 PPM 走柱状做帕累托对比，有助于快速识别哪几类占大头，这两张图有助于推动讨论。

多轮追问靠状态维持实现。第一轮问"某产品 PPM 在升"，第二轮问"下钻到工序"，第三轮问"哪个班次、哪类缺陷最多"，系统记住前两轮上下文，把产品编码、时间窗可自动带入后续查询。这套多轮状态由工作流引擎承载，每一轮引用结果来自上一轮输出，通常无需重复说明。从现象到工序再到班次与缺陷类型，三次提问有助于把一根波动拆到根因层。

预警把分析变成日常动作。把"偏离基线超 N 个标准差"或"连续 M 日上升"存成固定问法，周期跑一遍，命中就进质量例会跟踪。缺陷有助于在变成客诉前被发现，这是从救火到预防的关键一步。

质量管理的重点，是把数据用成预见力，而非仅关注存储量。继续堆表难以解决例会里的猜测。先把字段映射做细，SQL 执行链路跑通，分层与基线建起来，质量的账才更可能算得准，问题才更有可能拦住。

小艾智能体的智能问数报表系统核心功能之一是 NL2SQL：自然语言进，SQL 出，图表自动生成。系统以 FastAPI 与 Python 构建服务，工作流编排基于 LangGraph，可支持多轮下钻与状态传递；大模型可接 DeepSeek、GPT-4、智谱 AI，按业务切换。质量库、客诉库的 schema 在部署时可完成字段注释映射，私有化部署可支持产品与质量数据在本地处理。对质量部门而言，它有助于将每周拼表转变为按需查询，将事后汇总推进到事前预警。