10万条巡检记录自动清洗：异常识别规则库怎么建

把一个季度的设备巡检、门店巡检或产线点检记录导出到一张表里，往往是这样的画面：10 万行数据、四十多个字段，里面混着重复上报的工单、空着责任人的记录、单位写着"℃"却填了"正常"的单元格，还有明明处于停机状态却被标成"已巡检"的行。领导要三天内出一份能上会的分析报告，而团队还在逐行肉眼比对——这是很多企业数据治理真实的一天。

Gartner 的研究曾指出，不良数据质量平均每年给企业造成的损失可达千万美元量级。而巡检数据恰恰是企业里"产生量最大、结构化程度最低、业务价值最容易被低估"的一类数据。本文要回答的就是一个具体问题：当巡检记录规模来到 10 万条这个量级，异常识别规则库到底该怎么建，才能让清洗从"人肉扫雷"变成"机器自动跑"。

一、10 万条巡检记录为什么"洗不动"

在讨论规则库之前，先要搞清楚这类数据到底脏在哪里。只有把"脏"的种类拆开，规则才有落点。

1.1 巡检数据常见的四类脏

• 结构脏：同一批记录来自 APP 表单、纸质巡检单 OCR、系统导出、班组手工 Excel 四个渠道，字段名不同、列顺序不同、甚至一个巡检项被拆成三列。
• 值域脏：温度填了"约 80"、压力填了"正常"、时间填了"昨天下午"，还有人把"未检出"写成"无"又写成"—"，机器无法直接判定。
• 逻辑脏：单条记录本身合法，但组合起来矛盾，例如同一设备同一时刻被两名巡检员分别上报了不同状态，或者"停机"状态下却产生了巡检结果数据。
• 时序脏：巡检周期本该是 4 小时一次，实际出现连续 36 小时空档，或者同一条记录被反复提交了五次。

1.2 人工清洗的三个天花板

大部分企业的第一反应是"先让两个人顶一顶"。这条路走不通，原因很明确：

• 一致性无法保证：A 同事认为"压力偏差 5%"算异常，B 同事认为 10% 才算，同一份数据两个人洗出两个结论。
• 经验无法沉淀：老师傅凭手感能挑出问题，但他说不清判断依据，人一走规则就断了。
• 过程无法追溯：改了什么、为什么改、谁改的，事后审计一问三不知，这在制造、能源、金融这类强合规行业是硬伤。

1.3 规则库才是自动清洗的"发动机"

自动清洗的本质不是"用 AI 把数据变干净"，而是把人的判断标准翻译成机器可执行的规则，再用规则批量扫描数据。规则库建得好，10 万条记录跑一遍可能只需要十几分钟；规则库建得糙，跑完还得再人工复核一遍，等于白干。

实在Agent 在这一层的定位很清晰：它不是替代业务专家去"想规则"，而是把专家脑子里的判断标准接收下来，转成可执行、可版本管理、可批量运行的规则资产，并驱动清洗流水线自动跑完。

二、一条"可执行"的异常识别规则长什么样

很多企业建规则库失败的根因，是把规则写成了自然语言句子——"巡检记录应当完整准确"。这种规则机器读不懂，也无法判定。

2.1 规则的五个必备要素

一条能被引擎执行的规则，至少要写清五件事：

• 作用对象：针对哪张表、哪类记录、哪个字段。
• 判定条件：用什么表达式判断，支持等于、区间、正则、跨字段引用、跨表关联。
• 阈值参数：把 5%、24 小时这类数字抽成参数，方便后续调优。
• 严重等级：致命 / 严重 / 提示，决定这条异常是拦截、告警还是仅记录。
• 处置建议：命中后是自动修正、退回补录，还是转人工确认。

举个具体例子。"巡检结果为空即为异常"这条，落地后应该是：对象=巡检明细表.结果字段；条件=IS NULL OR TRIM=''；等级=严重；处置=退回原巡检人补录，超 24 小时未补录升级至班组长。

2.2 六类规则构成规则库的骨架

在实践中，一个能覆盖 10 万条巡检记录的规则库，通常由六类规则分层组成：

• 完整性规则：必填项缺失、关键字段为空、附件未上传。
• 唯一性规则：同一设备同一时段的重复上报、工单号重复。
• 规范性规则：格式、单位、枚举值是否符合标准字典。
• 一致性规则：跨表比对，例如巡检记录与设备台账、工单系统、库存系统的状态是否对得上。
• 业务逻辑规则：阈值越界、状态互斥、工序先后顺序颠倒。
• 趋势统计规则：同比环比突变、连续 N 次异常、周期空档。

前四类是"硬规则"，确定性强，用规则引擎或小模型就能跑；后两类里涉及语义判断的部分属于"软规则"，需要大模型参与。

2.3 硬规则拦截，软规则研判

这是很多团队容易忽略的分工问题。把所有判断都交给大模型，成本和稳定性都不可控；全都写成硬编码，又覆盖不了"摘要写得含糊但实质异常"这类情况。

成熟的做法是双轨制：小模型和规则引擎负责确定性校验，把格式错、缺项、越界、重复这些一眼能看出的问题挡在门口；大模型负责模糊匹配和语义研判，比如"备注里写了'设备有异响待观察'但状态标为正常"这种只有读懂文字才能发现的矛盾。

某电力集团在单据审核场景中采用的就是这套思路，覆盖 92 类核心业务场景，初审替代率达到 66%，准确率提升至 99.2%。巡检数据的清洗，逻辑完全一致。

三、从零搭建异常识别规则库的五步法

规则库不是一次性写完的文档，而是一份需要持续迭代的资产。下面这五步是相对通用的落地路径。

3.1 第一步：把"老师傅的经验"显性化

规则的原料有四个来源，缺一不可：

• 制度与 SOP 文本：巡检管理办法、点检标准、异常分级手册。
• 历史异常台账：过去一年被人工挑出来的问题记录，这是最有价值的样本。
• 系统既有校验：ERP、MES、EAM 里已经存在的校验逻辑，可直接迁移。
• 一线访谈：让巡检员口述"你看到什么样的记录会皱眉"，往往能挖出制度里没写但实际在用的判断标准。

这一步的关键动作是"规则智能管理"：把制度文本上传，由大模型解析成结构化的规则草稿，人工只需做确认和修正，而不是从空白页开始写。相比逐条手写，规则初稿的产出效率通常能提升数倍。

3.2 第二步：规则分类、分级、去重

规则一多就容易打架。这一步要做三件事：

• 按业务域归类：设备类、安全类、环境类、人员类，避免规则散落。
• 按严重等级分层：把"数据不可用"和"数据不美观"区分开，前者拦截，后者提示。
• 合并冲突规则：同一个字段出现两条互斥判定时，必须明确优先级，否则引擎执行结果不可预期。

3.3 第三步：规则代码化与版本管理

规则从文本变成代码后，就变成了需要被管理的"软件资产"：

• 每条规则有唯一编号、负责人、生效时间、适用范围。
• 规则变更走版本流程，历史版本可回滚。
• 规则执行有全链路日志，哪条规则命中了哪条记录，可完整追溯。

这一步看起来是工程细节，实际上决定了规则库能不能长期活下去。没有版本管理的规则库，半年后没人敢动。

3.4 第四步：双轨执行，跑通第一遍全量扫描

规则库初步成型后，先拿一个月的历史数据做回溯验证：

• 用硬规则跑一遍，看命中量和误报率。
• 用大模型对硬规则漏掉的样本做语义复检，看能否补出新的规则。
• 对误报样本逐条分析，是规则写错了，还是阈值设偏了。

这一轮跑完，规则库才算真正"能用"。某制造企业在产线报工数据清洗中，就是通过 RPA 跨 MES、ERP 抓取数据，再由 Agent 按规则清洗异常并生成可视化报表，把原本需要人工汇总核对的工作压缩到了分钟级。

3.5 第五步：闭环反馈与规则自进化

规则库最怕的是"建完就封存"。健康的机制是：

• 每条被人工复核推翻的判定，自动回流成规则优化建议。
• 定期统计各条规则的命中率、误报率，长期零命中的规则要评估是否失效。
• 新增业务场景时，规则以"继承 + 增量"的方式扩展，而不是推倒重来。

某定制家居企业在解料数据看板场景中，就是靠这套闭环把异常管理做扎实的：余单底表实时更新、产量日报自动统计、异常信息即时推送责任人，每条异常都有记录、有状态、有闭环。规则库不是静态清单，而是这套闭环里持续被喂养的部分。

四、10 万条记录跑一遍：清洗流水线怎么设计

规则库是"判断标准"，流水线是"执行通道"。两者配套，自动清洗才成立。

4.1 接入与标准化

• 多源接入：手工表格、APP 表单、系统导出、OCR 识别的纸质巡检单统一进入同一通道。
• 字段映射：把不同来源的字段对齐到统一的数据模型。
• 单位与编码归一：温度统一到摄氏度、时间统一到标准格式、设备编码对齐台账主数据。

OCR 这一步是很多企业的堵点。通过实在Agent 接入 OCR 能力，纸质巡检单可以直接识别并结构化落库，省掉手工录入环节，也顺手消除了录入错误这个最大的异常来源。

4.2 规则引擎批量扫描

数据标准化后进入规则引擎，按严重等级分批次执行。硬规则先跑，把确定性异常挑出来；软规则后跑，用大模型处理需要语义理解的部分。两条通道的判定结果合并成统一异常清单。

4.3 异常定界与源头穿透

发现异常只是第一步，找到"火源"才是关键。这一步要做两件事：

• 异常定界：扫描受影响的范围，是单条记录错了，还是整批数据都错位了。
• 源头穿透：顺着数据链路回溯，定位到是采集端、传输端还是汇总环节出的问题。

某电商企业在多店经营数据错位场景中，就是靠"雷达式扫描锁定受影响店铺 + 溯源映射链路替代人工逐行核对"这套组合，把数据修复从小时级压缩到了分钟级。

4.4 自动修复与安全回写

修复动作要分级：

• 可自动修正的：格式统一、单位换算、空白填充默认值，引擎直接改。
• 需回溯确认的：数据矛盾、逻辑冲突，先标记再退给责任人。
• 需撤回重写的：整批错位，一键撤回并按正确映射重写。

所有修复动作必须留痕，写入审计日志，保证事后可查。

4.5 实时哨兵与可视化看板

批处理解决存量，实时哨兵解决增量。规则库常态化运行后，新产生的巡检记录在入库瞬间就被扫描一遍，异常直接推送到责任人手机或企业微信。

看板层则承担三件事：异常总量趋势、各类规则命中分布、责任人处理时效。这三个指标基本能反映规则库的健康度。

五、落地时最容易踩的四个坑

• 坑一：规则写得太抽象。凡是出现"合理""适当""符合要求"这类词的规则，一律要重写，机器不认模糊表述。
• 坑二：一上来就追求全覆盖。先把高频、高价值的 30 条规则跑通，比写 300 条跑不动的规则更有价值。
• 坑三：忽略主数据治理。设备编码、部门编码不统一，跨表一致性规则根本跑不起来，这是前置条件。
• 坑四：把大模型当万能钥匙。确定性判断交给规则引擎，语义理解交给大模型，边界不清会导致成本和准确率双输。

写在最后

10 万条巡检记录的自动清洗，难点从来不在算力，而在"标准"二字。规则库的本质，是把散落在制度文件、老员工经验和历史台账里的判断标准，变成一份可执行、可追溯、可迭代的数字化资产。它建得越扎实，后续每新增一个业务场景，边际成本就越低。

如果你的团队现在还在用人工逐行核对巡检数据，不妨从一个最小的动作开始：把这一个季度被人工挑出来的异常记录整理成清单，逐条追问"判断依据是什么"，把它写成五要素齐全的规则。这 30 到 50 条规则，就是异常识别规则库的第一块地基。

常见问题解答

Q1：规则库需要多少条规则才算够用？
没有标准答案，但有个经验区间：单一业务场景下，覆盖 80% 常见异常通常需要 40 到 80 条规则。关键是命中率而非数量，长期零命中的规则应该清理掉，而不是堆在库里。

Q2：大模型会取代规则引擎吗？
短期内不会，两者是分工关系。规则引擎处理确定性判断，速度快、成本低、结果可解释；大模型处理语义模糊、非标表述的部分。双轨并行才是当前最务实的方案。

Q3：巡检记录涉及设备参数等敏感数据，能上云吗？
多数企业的做法是私有化部署。实在Agent 支持私有化部署，配套国密加密、三员分立、数据脱敏等安全体系，规则执行和数据处理都在企业内网完成。

Q4：规则建好之后，业务人员还要做多少人工复核？
取决于规则成熟度。初期可能需要复核 20% 到 30% 的判定结果，随着规则迭代和反馈闭环运转，复核比例通常会降到 5% 以内，人工主要处理规则库里没有覆盖的新类型异常。

Q5：多个部门的巡检标准不一致，规则库怎么统一？
建议采用"公共规则 + 部门扩展规则"的分层结构。公共规则覆盖全公司通用标准，部门规则在公共规则基础上做增量，冲突时以公共规则优先，同时保留部门差异的显性说明。

实在Agent