4. 数据清洗工程流程设计

在SPC系统中，控制图能否真实反映过程状态，取决于进入控制图计算的数据是否“干净”。数据清洗不是一次性脚本，而是一条从原始采集到控制图可用数据的工程流水线。本节围绕这条流水线的端到端设计展开，重点说明清洗规则库如何组织、版本如何管理、可追溯性与审计日志如何落地。

一、端到端流程的整体结构

一条完整的SPC数据清洗流水线通常包含六个阶段：采集接入、结构校验、值域与逻辑校验、异常值识别、修复与标记、控制图数据集生成。每个阶段都有明确的输入、输出和判定条件，且必须保留中间结果，否则后续无法追溯。

以某机加工车间外径尺寸采集为例，原始数据来自量具自动上传，字段包括：part_id、station_id、measure_time、value_mm、operator、gauge_id。原始记录中常见问题包括：时间戳格式不统一、量具编号缺失、同一零件重复上传、数值超出量程、以及因量具未校准导致的系统性偏移。

流水线的第一道关口是结构校验：检查字段是否齐全、类型是否正确、时间戳是否可解析。第二道是值域与逻辑校验：例如外径尺寸应在[9.90, 10.10] mm之间，超出即标记为“量程越界”；同一part_id在30秒内出现多条记录，标记为“重复采集”。第三道是异常值识别：在SPC语境下，异常值不等于错误值，可能是真实的过程偏移信号，因此不能直接删除，而应区分“数据错误”与“过程异常”。

二、清洗规则库的组织方式

清洗规则库是流水线的核心资产。建议按“规则ID + 适用字段 + 判定条件 + 处理动作 + 严重级别”五元组组织。例如：

规则库需要支持优先级和短路逻辑。例如R-001命中后，该条记录不再进入R-002至R-004，避免对空值做无意义计算。规则之间也可能冲突，例如一条记录同时满足“重复采集”和“3σ异常”，此时应按严重级别优先处理，并在审计日志中记录冲突判定结果。

三、版本管理与可追溯性

清洗规则一旦上线，就不能随意修改。每次规则变更都应生成新版本，版本号建议采用主版本.次版本.修订号，例如v2.3.1。主版本变更表示判定逻辑或处理动作发生不兼容调整；次版本表示新增规则或调整阈值；修订号表示文案、注释或日志格式修正。

可追溯性要求做到“三个可查”：查数据来源、查规则版本、查处理动作。每条进入控制图的数据记录，都应携带source_batch_id、rule_version、cleaning_action三个字段。这样当控制图出现异常点时，可以快速定位：是原始采集问题、规则误判，还是真实过程异常。

{
  "record_id": "M-20240612-00873",
  "part_id": "P-1024",
  "value_mm": 10.032,
  "source_batch_id": "BATCH-20240612-A",
  "rule_version": "v2.3.1",
  "cleaning_action": "KEEP",
  "flags": ["R-004:3sigma_candidate"],
  "audit_ref": "AUD-20240612-0091"
}

上例中，该记录被保留进入控制图，但带有“3σ候选”标记。控制图分析人员看到该标记后，应结合过程背景判断是否为真实异常，而不是直接删除。

四、审计日志的设计要点

审计日志不是简单的操作记录，而应覆盖数据级、规则级、任务级三个层次。数据级日志记录每条记录的清洗动作；规则级日志记录规则的新增、修改、停用；任务级日志记录每次清洗批次的开始时间、结束时间、输入条数、输出条数、各规则命中次数。

一个可用的审计日志应至少包含：log_id、timestamp、actor、action_type、target、before_value、after_value、rule_version、result。其中actor可以是人员账号，也可以是自动化任务ID。日志应只追加、不修改，并定期归档。

五、从清洗结果到控制图可用数据

清洗完成后，需要生成控制图数据集。该数据集不是简单过滤后的原始表，而应包含：用于计算控制限的基线数据、用于实时监控的监控数据，以及每条数据的清洗状态。基线数据应排除已确认的数据错误，但保留过程异常点，否则控制限会被“清洗”得过窄，导致后续误报率升高。

建议在生成控制图数据集时，同时输出一份清洗摘要，包括：输入总条数、有效条数、无效条数、各规则命中次数、人工复核条数、规则版本号。这份摘要应随控制图一起存档，作为数据质量证明。

上图展示了从原始采集到控制图可用数据的完整链路。可以看到，规则库同时作用于结构校验、值域校验和异常识别三个阶段；版本管理为规则库提供变更控制；审计日志贯穿数据级、规则级和任务级；最终输出分为基线数据、监控数据和清洗状态三部分。追溯关系将审计日志与控制图数据集连接起来，确保任何一个控制图上的点都能回答“它从哪来、经过了什么处理、依据哪版规则”。

在实际落地时，建议先用小批量数据跑通整条流水线，确认规则命中率和人工复核量在可接受范围内，再逐步扩大数据源。清洗规则库、版本记录和审计日志应作为独立资产维护，而不是散落在脚本注释或临时表中。只有流程、规则、版本、日志四者形成闭环，SPC控制图才具备真正的工程可信度。