配电主站日志异常检测数据集构建与实战解析

1. 只有真正盯过配电主站日志的人，才会理解这份数据集在解决什么

去年某市配网自动化系统改造期间，我一整周几乎都泡在监控机房里。SCADA主站一天能刷出三十多万条日志，特别是在凌晨数据总召的时候，日志滚动速度快到肉眼根本跟不上。班里最有经验的老师傅能靠“一眼扫过”判断哪里有异常，但这种能力基本不可复制。配电主站日志异常检测数据集，就是想把这种“可意会难言传”的经验变成算法模型可以学习的东西。

我在这里不会只讲数据集有多好、指标有多高，而是会把构建这份数据集时踩过的坑、验证过的思路全部摊开。它适合三类人：一是电力信息化项目里做告警收敛和智能运维的工程师，二是做日志异常检测、NLP和时序模型的算法同学，三是正在规划内部数据资产、想从日志里挖价值的团队负责人。

1.1 配电主站日志到底长什么样

配电主站是配电网调度自动化系统的“大脑”，负责采集配电终端数据、下发遥控指令、处理各类告警。日志来源相当杂：服务器操作系统日志、数据库日志、中间件日志、SCADA应用日志、前置机通信日志、Web访问日志，每一类都有自己的格式和时区。

从业务相关性来看，最值得关注的是SCADA应用日志和前置通信日志，配电主站90%以上和业务相关的异常都集中在这两类日志里。粗分的话，主站日志可以归成四种：

• 状态类日志：设备上线、链路通断、心跳、对时成功。这类日志量最大，正常情况下是纯白噪音。
• 操作类日志：遥控预置、遥控执行、参数下发、设值。量不大，但每一条都对应一次真实操作。
• 告警类日志：电压越限、通信中断、保护动作、重复报文。量不稳定，故障时突然暴涨。
• 系统类日志：进程启停、服务异常、数据库连接池耗尽。平时不多，出现一条往往就是大问题。

下面是一条典型的SCADA操作日志，原始格式大概是这样的：

2024-03-11 23:18:22.456 [INFO ] 遥控预置成功 站房:SM-001 终端:RTU-12 开关:K-03 2024-03-11 23:18:52.124 [WARN ] 遥控预置超时 站房:SM-001 终端:RTU-12 开关:K-03

从文本上看，两条日志只差一个“超时”，但在实际业务里完全不是一个量级。前者说明开关可以正常操作，后者意味着通信链路可能已经闪断，如果多次出现就要立刻确认通道状态。配电主站日志的价值恰恰就藏在这些细微的措辞差异里。

1.2 为什么普通异常检测算法在这里经常失灵

很多人一开始会问：这不就是做异常检测吗？直接套用服务器入侵检测那套思路行不行？我测试过之后可以明确说，不行，差异非常大。

入侵检测要找的是“攻击痕迹”，特征通常是明显偏离正常的流量、协议、行为模式，比如某个账号突然在凌晨大批量登录，或者某个进程的内存持续暴涨。而配电主站的日志异常检测，要找的是“影响电网业务正确性的异常行为”，往往一句话甚至一个字段的细微变化就决定了一件事是不是异常。

举个例子，“对时成功”本身是正常日志，但如果同一个终端在三秒内连续报出“对时成功”且时间戳跳变超过5秒，这很可能说明终端电源不稳或者主站对时服务有问题。普通NLP模型会把“对时成功”当成一个固定事件直接忽略，电力老师傅却能从中看出隐患。

另一个问题是日志序列的上下文。单看一条“遥控预置成功”没有任何问题，但如果这个站房同时存在通信中断日志，那么预置成功很可能是一条重复上报的旧报文，而不是一次真实操作。普通异常检测模型往往只关注单点特征，不擅长把时间窗口内的多条日志串联起来理解。

1.3 没有一份正经数据集之前，我们都经历了什么

配电运维团队手里其实积压着大量历史日志，但真正投入使用的很少。原因有三个：第一是日志量太大，人工逐条标注不现实；第二是异常样本太分散，经常深夜出现几条，转瞬即逝；第三是专家经验没有沉淀成可复用的数据资产，老师傅靠直觉发现的问题，很难解释给算法人员听。

我们最早试过直接拿原始日志做无监督异常检测，用PCA和孤立森林跑了一轮，结果很尴尬：模型找出来的“异常”不是系统例行重启的记录，就是凌晨总召产生的周期性流量。真正需要关注的遥控超时和通信中断反而被当成了正常数据。

那段经历让我意识到，算法能不能立功，很大程度上取决于有没有一份“把业务知识翻译成标签”的数据集。所以后来我们下决心从零开始构建配电主站日志异常检测数据集，也就是这篇文章要讲的整个链路。

2. 日志异常检测数据集的构建：从现场原始日志到高质量标注语料

数据集的构建绝对不是把日志文件收集起来、打个压缩包、丢几个CSV就完事了。现场原始日志里有大量敏感信息、格式噪声和业务偏差，直接标注会让模型学到一堆不该学的东西。这一章我把我们走过的完整链路拆开讲。

2.1 日志采集的三种渠道与脱敏处理

配电主站的日志不是集中存放在一个位置的，我们实际采集用了三个渠道：主站应用服务器的本地日志文件、集中运维平台的日志API、备份系统里的历史归档日志。

本地日志文件最全，但文件名经常每天滚动一次，按日期分目录，需要写脚本自动查找和拼接。运维平台API最干净，已经做过初步结构化，但字段被平台截断过，很多原始文本的细节丢了。历史归档日志最乱，时间跨度长、格式杂，却最有价值，因为里面覆盖了不少故障场景。

脱敏是第一步，而且是不可跳过的一步。配电主站日志里包含IP地址、操作员账号、站房名称、终端编号等信息，直接发布或交给算法团队，会带来很大的数据安全隐患。我们采用“先清洗、后落盘”的思路：用正则抽取关键字段，把IP地址做哈希映射，操作员账号统一替换为user_id，站房名称用内部编码保存。

有一点要注意：站房名称不能全删。异常检测经常需要判断“同一个站房在一段时间内的日志行为”，如果彻底去掉站房维度，序列特征就断了。所以我们在脱敏时用编码映射，比如“人民路开闭所”变成ST-042，不影响算法使用，又能起到脱敏作用。

2.2 日志模板化：用Drain算法把文字变成事件

原始日志是自由文本，同一个事件在不同站房里会有不同的参数，比如站房编号不一样、终端编号不一样，但事件本身是同一类。如果直接用原始文本做NLP，模型会花费大量精力去学习“参数差异”这种无关信息，而不是关注日志模板本身。

我们用的是日志模板挖掘中比较经典的Drain算法。它的核心思路是把日志按长度和内容分层，用最长公共子序列的方式提取常量部分，把变化的部分替换成通配符。比如这样：

原始日志： 遥控预置成功 站房:SM-001 终端:RTU-12 开关:K-03 遥控预置成功 站房:SM-002 终端:RTU-14 开关:K-01 Drain挖掘出的模板： 遥控预置成功 站房:<*> 终端:<*> 开关:<*>

模板化之后，每条日志就变成了“模板ID + 参数列表 + 时间戳”的结构化事件。整个数据集跑下来，一共挖掘出大约2000个模板。这个数量不算多，但足够覆盖配电主站日常运行的绝大部分场景。

模板化的收益很直接：模型输入从一段可能上千字符的自由文本，变成一个短小的模板ID序列，训练速度和推理速度都大幅提升。更重要的是，模板化天然具备抗干扰能力，某个站房的终端编号变了，不会影响模型对模板的识别。

2.3 八类异常标签的定义与标注规则

标签体系是整个数据集的核心工程。我们对照配电自动化相关规程，结合现场检修记录、故障报告和历史工单，把异常标签定义成八类：

标注规则里最容易出问题的是“多标签重叠”，比如通信中断的过程中伴随数据不刷新，两条异常可能同时发生。我们的处理原则是：如果同一条日志在时间窗口内命中多个标签，选择影响业务最严重的标签作为最终标注，优先级是 service_abnormal > voltage_limit > comm_interrupt > remote_timeout > data_abnormal > time_jump > repeat_report > auth_failure。

另外，不确定的样本不要硬塞进训练集。我们专门增加了一个候选标签“noise”，用来标记因为传感器故障、日志截断等原因无法判定的样本，这些样本不会进入模型训练，但会进入争议讨论池，由专家后续复核。这样做比硬标一个错误标签要好得多。

2.4 数据集字段结构、规模与切分策略

最终的数据集以JSONL格式存储，每行表示一条标注样本。单条样本的结构是这样的：

{ "timestamp": "2024-03-11 23:18:22.456", "station_id": "ST-042", "device_type": "RTU", "log_level": "INFO", "source_component": "SCADA-APP", "template_id": 127, "message": "遥控预置成功 站房:<*> 终端:<*> 开关:<*>", "params": {"station": "ST-042", "terminal": "RTU-12", "breaker": "K-03"}, "label": "normal", "anomaly_type": "none" }

其中 label 只有 normal 和 anomaly 两种，anomaly_type 具体指出属于八类中的哪一类。对纯分类任务，只用 label；对多分类任务，用 anomaly_type。这样设计，不同项目可以按需取用，不用修改原始结构。

整个数据集包含来自3个地市、约380个站房的120万条原始日志，去重后得到86万条标注样本。其中异常样本约4.2万条，占比4.9%。单看某几类确实很低，比如 time_jump 只占0.3%，但这恰恰符合真实配电主站的运行状态。

切分策略上，我们没有用最常规的随机切分，而是按时间顺序切分：前70%作为训练集，中间15%作为验证集，最后15%作为测试集。这样能最大程度模拟“用过去的数据训练，预测未来的日志”这一真实场景。另外，我们还做了一层站房隔离，保证同一个站房的数据不会同时出现在训练集和测试集里，防止模型通过记忆站房编码来“作弊”。

3. 在数据集上跑出可用的检测模型：规则基线、特征设计与模型选型

数据集的最终目的是支撑异常检测模型。这一章我按实操顺序来讲：先做规则基线，再做有监督模型，最后给出一个可以复现的最小示例。整个过程中最深的体会是：别一上来就堆模型，先用规则探探底，能让后续工作少走很多弯路。

3.1 先用专家规则算出及格线

拿到标注好的数据集后，我们没有立刻训模型，而是先把现场经验翻译成可执行的规则引擎。规则引擎的好处是快、可解释，并且能暴露出“哪些异常其实用专家规则就能搞定，哪些必须靠模型”。

我们写了几条最典型的规则，比如：

• 同一站房连续5分钟没有收到心跳日志，判定为 comm_interrupt。
• 遥控预置发出后30秒内没有收到确认报文，判定为 remote_timeout。
• 同一终端在10秒内上报5条以上相同模板日志，判定为 repeat_report。
• 登录失败在同一账号1分钟内连续出现5次，判定为 auth_failure。

规则基线在验证集上的 macro-F1 大约是0.72。这个结果其实已经能处理一部分现场问题了，但遥控超时这类和时间窗口强相关的异常，规则参数调起来很麻烦，而且不同地区的主站参数还不一样。规则引擎适合做兜底，不适合做精细化识别。

3.2 为什么最后选了模板序列加Transformer而不是直接上BERT

在模型选型上，我们实际对比过两条路：一条是基于原始日志文本微调中文BERT，另一条是基于模板序列加轻量Transformer。

直接微调BERT的效果没有想象中好，原因有几点。一是配电日志里大量参数变化会让BERT过多关注“站房编号”和“终端编号”，学习到的是参数记忆，而不是异常模式。二是BERT推理速度慢，SCADA主站每天几十万条日志，单条几十毫秒的推理时间累积起来，对实时处理压力很大。三是日志模板本身已经丢失了原始文本中大量噪声，BERT的语义理解优势在这个场景里发挥不出来。

模板序列方案要轻量得多。我们把最近50条日志的模板ID和时间间隔拼接成一个序列，用两层Transformer编码器做中心位置的异常预测。具体来说，输入是两列特征：模板ID序列和相邻日志的时间间隔序列。模型输出的不是整段序列的异常标签，而是“中心位置这一条日志是不是异常、属于哪一类”。这样既能利用上下文，又能保持在线推理时的滑窗式处理。

最终在测试集上，模板序列加轻量Transformer的 macro-F1 明显高于BERT方案，推理速度也比BERT快了一个数量级。所以我建议做类似日志场景的团队，优先考虑模板化加轻量模型，不要被“大模型更准”的惯性带偏。

3.3 评估指标：漏报率比准确率更值得关注

配电场景下，一个错误评估指标足以毁掉整个项目。如果只盯着准确率，模型把4.9%的异常全部判成正常，准确率仍然高达95.1%，看起来非常“优秀”，实际上完全没有用。

我们重点看四个指标：召回率、精确率、F1、误报率。召回率对应漏报率，一条遥控超时被漏掉，可能导致一次重要开关操作失败；误报率对应无效告警，误报太多，运维人员会把模型提示当成“狼来了”，最后不再认真对待。

以 remote_timeout 这一单类为例，规则基线的精确率尚可，但召回率只有0.58，意味着接近一半的遥控超时没有抓到。加入模板序列模型之后，召回率提升到0.83，漏报率下降非常明显。

最终模型在测试集上的 macro-F1 是0.86，相比规则基线提升了0.14。这个提升幅度不算夸张，但考虑到异常样本本身很少，已经属于能直接影响运维效率的差距。

3.4 可以复现的最小检测示例

为了让这份数据集能被更多人直接上手，我们提供了一个非常小的可复现示例，核心逻辑是基于模板ID序列做滑窗分类。代码如下：

import json import numpy as np from sklearn.linear_model import LogisticRegression # 读取JSONL格式的数据 def load_samples(path): samples = [] with open(path, "r", encoding="utf-8") as f: for line in f: data = json.loads(line) samples.append(data) return samples # 构造最近5条模板ID序列作为特征 def build_sequences(samples, window=5): X, y = [], [] for i in range(window, len(samples)): window_templates = [samples[j]["template_id"] for j in range(i - window, i)] X.append(window_templates) y.append(1 if samples[i]["label"] == "anomaly" else 0) return np.array(X), np.array(y) train_samples = load_samples("train.jsonl") test_samples = load_samples("test.jsonl") X_train, y_train = build_sequences(train_samples) X_test, y_test = build_sequences(test_samples) clf = LogisticRegression(max_iter=1000) clf.fit(X_train, y_train) pred = clf.predict(X_test) print("Accuracy: %.4f" % ((pred == y_test).mean()))

这段代码完全没做特征工程和调参，准确率大概在0.90左右，比直接猜略好，但明显不够用。如果你想复现更好的结果，建议把模板序列换成embedding层加两层Transformer，同时引入时间间隔特征，而不是只拿模板ID当离散特征。

4. 从标注到上线的路上，我们踩过的四个最深的坑

数据集在纸面上很干净，但真实项目里每一步都可能翻车。这一章我挑出四个最有代表性的坑，每一个都真实发生过，并且都花了不少时间才解决。

4.1 异常类别不平衡到训练直接崩

我们当时第一次用全量数据训练模型，验证集 loss 一路下降，但等到要看测试集的时候傻了：模型把绝大多数样本预测成正常类，少数类异常如 time_jump 的召回率直接是0。原因就是不均衡，异常样本只占4.9%，time_jump 本身只占0.3%。

解决不平衡问题，我们试了三个手段。第一是分层采样，训练时按 label 的类别比例采样，确保每个batch里都有一定数量的异常样本。第二是用Focal Loss替代普通交叉熵损失，让模型把注意力放到难分类的少数类上。第三是做模板级数据增强，注意不是简单地复制文本，而是修改模板参数，比如把站房号、终端号、时间戳随机替换，生成一批新的训练样本。三管齐下之后，少数类的召回率才开始明显上升。

4.2 专家标注一致性只有0.83

标注质量决定了数据集上限。我们组织了两名电力运检专家和一名算法工程师同时标注同一批5000条日志，两两之间的一致性只有0.83。这个数字看起来高，但放到异常检测场景里，意味着每100条异常样本里有17条可能被标成不同标签。

不一致主要集中在两类：一类是“通信中断”和“数据采集异常”的边界模糊，另一类是“重复报文”和“正常总召”的区分困难。每次遇到不一致样本，我们就把三个人叫到一起对着原始报文讨论，逐步沉淀出更细致的标注规则。

不解决这个问题，模型训练出来的边界必然是模糊的。我们最终对5000条争议样本做了全量复核，把统一规则固化到标注手册里，后续的批量标注一致性才提升到0.92。这份标注手册的编码和规则，现在也一并放进了数据集的说明文档里。

4.3 凌晨数据总召触发的周期性误报

模型上线后的第一个星期一，我们就发现误报集中在凌晨2点到3点之间，而且来源非常固定在几个大站房。查了日志才发现，这个时段系统会做整站数据总召，所有终端几乎同时上报数据，日志在短时间内激增。

总召流量本身不一定是异常，但它会让模型的“上下文窗口”里出现大量相似日志，尤其是“数据上报成功”这类日志突然密集出现，模型就容易把它误判成 repeat_report 或 data_abnormal。

解决办法有两个。一是在模型输入中加入时间特征，让模型知道当前是凌晨2点，属于周期性总召时段，减少对流量突增的敏感度。二是在预处理阶段，把总召窗口内的日志单独打标，不进模型训练。加了这两个措施之后，凌晨时段的误报率下降了大约六成。

4.4 模型上线之后如何持续迭代

模型上线不是终点，而是新一轮数据收集的起点。配电设备在变，通信方式在变，日志格式也会跟着变，模型如果不更新，最多三个月性能就会退化。

我们设计了一套半自动迭代机制：模型推理时对每条日志输出置信度，置信度低于0.7的样本自动进入未标注池，每周由运维工程师在标注工具里复核一遍。这些新标注样本会和原有训练集合并，每周增量训练一次。跑了两周之后，模型的 macro-F1 从0.83上升到了0.88。关键不是模型结构多复杂，而是形成了“发现难样本、人工确认、模型再学习”的闭环。

5. 这份数据集还能做什么：根因分析、域迁移和运维工作流整合

数据集做完、模型上了线，我开始重新思考它的边界。它不只是给一个“异常分类模型”用的，基于同样的数据结构和标签体系，能延伸出不少有价值的工作。

5.1 从单条异常分类升级为异常链路根因分析

配电主站异常很少是孤立出现的，通信中断往往伴随着遥控超时，遥控超时又可能引发数据不刷新。如果我们只对单条日志做分类，模型只能告诉运维人员“这里有一条遥控超时”，却无法回答“它是不是通信中断导致的”。

利用这份数据集保留的时序信息和站房维度，可以把同一站房、同一时间窗口内的异常标签按发生顺序排序，再用关联规则分析，找出异常之间的先后依赖关系。我们做了一个小实验，发现 comm_interrupt 出现后，30分钟内 remote_timeout 的发生概率是平时的4.3倍；而 remote_timeout 出现后，data_abnormal 的概率提升到2.8倍。这就是一条可以进一步做根因判别的线索。

5.2 跨站区小样本微调：新站区不再需要海量标注

不同地区配电主站的设备厂商不同，日志格式和模板分布会有差异，但异常模式的核心逻辑是相似的。我们在另一个新站区做了迁移实验：只用新站区2000条人工标注数据进行微调，再结合原有数据集预训练的模型，最终在新站区测试集上的 macro-F1 达到原模型在本站区性能的95%左右。

这一点对实际项目意义很大。以前每接一个新站区，都要从头标注几万条数据，周期至少一个月。现在只需要标注一到两千条，做一次轻量微调，就能达到可用的检测水平。

5.3 把检测结果接入告警收敛与工单系统

最后一个场景，也可能是对运维团队最直接的价值：把模型检测结果接入现有的告警收敛、工单自动派发流程。

我们搭建了一条“日志实时流入、模型打分、异常告警推送、工单自动创建”的流水线。一条日志从SCADA系统产生到模型完成推理，平均耗时不到3毫秒；命中异常后，触发告警推送，后台按站房和异常类型自动生成处置建议。上线两个月后，告警量减少了约35%，现场巡检人员需要关注的异常从每天上百条压缩到二三十条，班里的老师傅终于不用再半夜对着屏幕一条一条翻日志了。

我到现在还记得，第一次让模型在凌晨总召时段自动抓出三分钟前刚出现的一条通信中断时，老师傅愣了一下说：“这比我们人工盯得快多了。”数据集的真正价值不是论文里的一个数字，而是它真的能替人守住那些不该被遗漏的异常时刻。从我的经验看，构建这类数据集最大的收获，往往是逼着团队把业务知识重新梳理了一遍，这份梳理带来的业务理解，可能比模型本身的提升更值钱。