# 电力数据分类分级落地实录：356 个类目、3.1 万字段与一次全量实测

> 发布日期：2026-09-01　作者：模界数智
> 原文链接：https://mojiedata.com/insights/power-data-classification-practice

---

《能源行业数据分类分级指南（2026年版）》于 2026 年 6 月 30 日发布、7 月 1 日施行。文件不长，十五条，但对电力企业来说，真正的工作量不在读条文，而在条文结束的地方。

本文记录的是一个省级电网企业把这份指南落成可执行标准的完整过程。**为保护客户，文中不出现企业名称、地域和任何专属业务标识；结构、方法与全部测试数字为真实记录。**

## 直接回答

指南规定了一级分类（能源品种）和二级分类（能源活动）两个维度，**三级和四级由企业自行划分**——这意味着一份十五条的行业文件，落到一个省级电网企业身上会变成三百多个类目、每个类目都要有定级理由和可判定的边界。本案例最终建成 356 个类目（277 个叶子），覆盖 2,336 张表、31,493 个字段的全部数据资产，文档侧在 520 篇合成测试集上四级精确命中 91.2%，字段侧抽样 78%。**过程中最重要的发现不是准确率数字，而是判定稳定性**：同一批数据连跑两轮的一致率从 86.3% 提升到 97.0% 之后，准确率才第一次成为一个可度量的量。

## 关键结论

1. 指南只给两级分类维度，**三、四级的建设成本远大于读懂条文的成本**。
2. A 域（能源业务）与 B 域（系统运行与安全）的边界，可以用一句话判定：**这份数据描述的是电网，还是系统本身**。
3. **数据仓库分层不改变数据的分类归属**。不写死这一条，客户拿数据中台盘点时会把大半个营销与运检的数据堆进「元数据」。
4. 树只管归属，**其余维度全部由属性标签承担**——包括组织责任、公开状态、坐标属性、监管报送。
5. **重要数据和核心数据只能出候选清单，不能出认定结论**，因为关键的认定权不在企业手里。

## 一、指南结束的地方，工作才开始

指南第四条给了两个分类维度：按能源品种分一级，按能源活动分二级，然后一句「能源数据处理者可按数据内容和特点，进行三级和四级分类」。

这一句话背后是全部工作量。一个省级电网企业的数据现实是：一百多个数据库、两千多张表、三万多个字段，加上以文档形态存在的规划资料、设计图纸、试验报告、运检记录、专项方案。要让每一份数据都有「确定的类别、等级」（指南第三条「边界清晰」原则的要求），三、四级必须建到足够细，细到人和机器都能判。

第八至十一条的重要数据识别规则同样有一个执行落差。规则本身很具体——750 千伏以上变电站、开关站、换流站精度优于 100 米的坐标数据及任何含该坐标的资料，特级重要电力用户的电力消费原始数据——但「特级重要电力用户」按国家有关文件规定和程序认定，**认定权不在企业**。企业能做的是把符合特征的对象排查出来形成候选清单，前置动作包括获取法定认定清单、核实用户数计数口径、确认换流站电压等级条款解释、普查坐标资料存放点。

这一点在标准文本里必须体现为措辞纪律：**全部用「候选 / 拟识别 / 待核实」，不出具认定结论**。

## 二、356 个类目是怎么长出来的

依据 GB/T 43697—2024「先行业领域、再业务属性」的思路，设三个顶层管理域：

- **A 能源业务数据域** —— 监管分类主树，按「能源品种 → 能源活动 → 专业子域 → 数据主题」四级展开
- **B 系统运行与安全数据域** —— 只收「关于系统本身」的数据
- **C 企业经营管理数据域** —— 经营职能数据

![图 1　三个企业数据域与五根导入单树：A 域按「能源品种 → 能源活动 → 专业子域 → 数据主题」四级展开，B 域只收关于系统本身的数据，C 域为经营职能数据。](./images/fig-01.png)

最终规模：

| 根 | 二级 | 三级 | 四级 | 类目合计 | 叶子数 |
|---|---|---|---|---|---|
| E01 电力 | 8 | 44 | 177 | 230 | 177 |
| E02 风能 | 3 | 3 | 7 | 14 | 7 |
| E03 太阳能 | 3 | 3 | 7 | 14 | 7 |
| B 系统运行与安全 | 3 | 42 | — | 46 | 42 |
| C 企业经营管理 | 7 | 44 | — | 52 | 44 |
| **合计** | **24** | **136** | **191** | **356** | **277** |

电力主干八类能源活动的细度分布，可以看出重心落在哪里：

| 能源活动 | 专业子域 | 叶子 | 覆盖要点 |
|---|---|---|---|
| 01 规划 | 4 | 14 | 电网发展规划、电源与新能源接入、负荷预测与供需、投资计划 |
| 02 设计 | 4 | 13 | 接入系统设计，输电、变电、配电工程设计 |
| 03 建设 | 5 | 18 | 项目管理、施工、安全质量、造价招采、验收投产 |
| 04 生产 | 6 | 38 | 调度运行、系统运行（含电网模型、GIS、数字孪生、三维点云）、调度计划与预测、继保与安控、新能源运行控制、安全生产与应急 |
| 05 储运 | 6 | 27 | 输变配设施运检（含设备状态评价与健康度）、储能设施、状态监测与巡检、灾害防治 |
| 06 消费 | 8 | 39 | 客户档案、用采与电量电费、重要用户与保电、业扩报装、计量、负荷管理与需求响应、分布式与充换电、大客户与算力负荷 |
| 07 科研 | 5 | 13 | 科研项目、试验检测、仿真与模型、技术监督、专利标准成果 |
| 08 交易与服务（企业扩展） | 6 | 15 | 市场主体注册、交易申报与出清、结算、绿电绿证、信息披露 |

「交易与服务」是企业扩展项——指南的能源活动二级分类里没有这一类，但电力市场化交易的数据量和敏感度都要求它有独立归宿。这是三、四级自建权限的典型用法。

## 三、三条判据

类目树的价值不在数量，在于每一处分叉都能被一句话判定。这个项目沉淀了三条，它们不只写在标准文本里，**已经编译进引擎的分类模板，是机器实际执行的规则**。

### 判据一：A/B 域边界——描述的是电网，还是系统本身？

这是全项目最高频的争议点。自动化系统产生的数据，到底算业务数据还是系统数据？

判据是：**凡实质描述电网对象与运行的，即使产生于自动化系统也归 A 域。**

- 测点定义表、通道与转发配置——编码了电网模型与厂站结构，归 A 域生产；
- 保信系统中的保护动作信息——描述的是电网的保护行为，归 A 域；
- B 域只收平台与设施自身的数据：主机配置、账号权限、日志、性能、拓扑、漏洞、备份。

字段级验证也守住了这条边界：一张测点定义表的 5 个字段中，4 个正确进入 A 域调度运行，未被 B 域虹吸。

### 判据二：品种边界——三要素规则，而不是「以并网为界」

风光数据归风能太阳能还是归电力？行业里常用的说法是「以并网点为界」，但这个界在数据上并不清晰——一份风功率预测数据既描述风资源也服务于电网调度。

改用三要素：数据直接描述**一次能源资源、发电设备本体、场站发电生产活动**的，归风能／太阳能；用于**电网接入、输送、调度、消纳、交易、用户服务**的，归电力。

配套一条克制原则：风光分支**只建实际存在的稀疏枝**（规划测风测光、生产本体运行、科研试验），不为对称而造空枝。这也是 E02/E03 各自只有 7 个叶子的原因——省级电网企业本身不是发电主体。

### 判据三：数据仓库分层不改变分类归属

这一条是盘点过程中被迫补进标准正文的：

> 数据仓库分层（ODS/DWD/ADS/实时层）不改变数据的分类归属。数据中台内承载的业务数据按其内容归入 A 域相应类目，通过「数据来源＝数仓加工」标签标识；B 域只收描述数据的数据（元数据、血缘、质量、标准、标签、权限、脱敏策略）。

不写这一条会发生什么？盘点中确实发现**售电量汇总、供电可靠性指标、计量抄表明细、营销客户档案贴源表等 7 张业务数据表被登记在了「元数据」名下**——因为它们物理上住在数据中台里。一旦按登记位置分类，大半个营销与运检的数据会集体迁入 B 域，整棵树的统计口径随之失真。

## 四、树管归属，标签管其余

分类树只回答一个问题：这是什么数据。其余维度全部由挂在目录对象上的属性标签承担。

| 维度 | 代表属性 |
|---|---|
| 结构性（自动推导，只读） | 能源品种、能源活动、企业数据域、描述对象 |
| 组织 | 业务责任域、责任部门、来源系统、数据来源 |
| 主体与个人信息 | 数据主体、描述对象细分、个人信息属性（敏感个人信息强制标识） |
| 用途与流转 | 数据用途（含「监管报送」）、报送接收单位与频率、处理环节、公开状态 |
| 环境与合规 | 安全分区、坐标属性组、涉他行业属性组、时间跨度、主体规模 |

这个设计解决了三个具体问题。

**第一，分类的技术划分不割裂组织的管理责任。** 调度机构的数据在标准里被拆到了 A 域生产和 B 域两处，因为分类必须按数据内容走。但九大业务条线做成组织维度标签（而不是目录层级）之后，调度机构按自己的责任域标签过滤，一次就能看到完整数据视图。

**第二，监管报送数据不再单独建一套目录。** 「数据用途＝监管报送」是一个标签，报送数据仍留在原业务类目。否则同一份运行统计会在业务枝和监管枝各存一份。

**第三，「公开」不是一个等级。** 它被独立为「公开状态」属性，取值为未公开／拟公开／已依法公开／禁止公开。同理，**安全分区是处理环境，不直接决定等级**，只作为重要数据排查的线索。

坐标属性组（设施类型、电压容量等级、是否含位置、位置精度、是否可反向定位）是指南第八条的排查工具，可以直接生成「含坐标资料排查视图」。三维激光点云与高程成果因为普遍含优于 100 米精度坐标且可反向定位，被单独立为一个类目。

### 分级：双轨制，且 G4/G5 不作为类目等级

- **监管数据等级**（对外）：一般／重要／核心，依指南；
- **企业保护等级**（对内）：G1–G3 在「一般数据」内部按危害程度细分，G4/G5 由监管等级自动映射。

![图 2　分级双轨制：对外用监管三级（一般／重要／核心），对内用企业保护等级 G1–G5；G4/G5 不作为类目等级，仅由具体对象经法定核实认定后映射产生。](./images/fig-02.png)

277 个叶子的默认参考等级分布是 G1 常规 7 个、G2 内部 130 个、G3 敏感 140 个。

**G4（重要数据）和 G5（核心数据）刻意不作为类目等级**，只在具体目录对象经法定核实认定后由监管等级映射产生。这条约束是为了避免一个很现实的后果：**标准一发文就凭空产生一堆重要数据**。

配套还有两条写死的约束：仅损害企业自身权益或个人权益的，原则上不得定为重要数据，只能在一般数据内取高等级；类目等级只是新目录对象的初始建议值，不向子节点强制继承，实际以对象级定级为准。

## 五、怎么发现「树划得太粗」：两个量化指标

标准初稿完成后，把全部 2,336 张表、31,493 个字段的清单拉出来与类目树逐一对照，用两个指标找问题：

1. **每个子域平均每叶承载多少字段**
2. **一个叶跨越多少个不同来源系统**

暴露出来的问题非常集中：B 域「系统配置信息」**一个类目承载了 90 张表、跨 31 个来源系统**。打开看，里面实际是七类完全不同的东西——云平台与容器、微服务与中间件、监控告警策略、CMDB、存储与检索、视频识别，以及真正的系统参数。

这种粒度下，无论人工填报还是机器归类都无法区分。据此新增 12 个四级类目、拆分 3 处，其中两处值得单独说：

- **安全审计日志**从运行日志中独立出来。审计记录的防篡改要求、留存期限、访问授权与普通运行日志完全不同，等保与 CCRC 均单列，混在一起管必然出问题。
- **三维激光点云与高程成果**独立成类，原因见上一节的坐标条款。

细化前后的对比数据在下一节。这里先给结论：**类目数量本身不是目标，「每叶承载量」和「跨系统数」才是可以监控的健康指标。**

## 六、实测结果

### 6.1 关于测试集的说明（请先读这一段）

**文档侧的 520 篇测试集是按标准树结构生成的合成业务文档，形态贴近真实但不是客户的真实文件。** 每篇带人工标注的四级路径与等级作为标准答案。

这一点必须放在所有数字前面。合成测试集能验证标准树的内部一致性和引擎的判定能力，但**不能代表真实场景**——真实文档有扫描质量问题，有「一份文件混多个主题」的情况，有历史遗留的命名混乱。这些是合成数据造不出来的。

因此本项目给客户的第一条建议就是：**真实文档进场后先抽 50 篇做对比基线**，若与合成基线落差明显，优先排查扫描质量与混题比例，而不是先改树。

关于准确率数字应该怎么读，可以参考[《分类分级准确率 95% 是怎么算出来的：七种测试操纵手法》](/insights/accuracy-95-percent-truth)。

### 6.2 文档侧全量基线

520 篇，6 并发一次跑完，零失败、零限流降级：

![图 3　文档侧全量基线：四级精确命中 91.2%、一级大方向 97.3%、定级一致 96.2%，11 分钟跑完 520 篇，零失败。下方为十个业务域的分域成绩。](./images/fig-03.png)

| 指标 | 结果 |
|---|---|
| **四级精确命中**（全路径完全一致，最严口径） | **474 / 520 = 91.2%** |
| 三级命中 | 475 / 520 = 91.3% |
| 二级命中 | 487 / 520 = 93.7% |
| **一级大方向** | **506 / 520 = 97.3%** |
| **定级一致** | **500 / 520 = 96.2%** |
| 耗时 | 11 分钟 |
| 单篇成本 | 0.035 元 |

分业务域：

| 业务域 | 篇数 | 精确命中 | 说明 |
|---|---|---|---|
| 电网规划与投资 | 29 | 93% | |
| 电网工程建设 | 66 | 92% | |
| 电网调度运行 | 66 | 86% | 「数据本身 vs 围绕数据的活动文档」错配集中区 |
| 输变配设备运检 | 52 | 81% | 在线监测 ↔ 状态评价 ↔ 灾害防治三者边界最密 |
| 营销与客户服务 | 82 | 94% | |
| 新能源并网与消纳 | 33 | **100%** | |
| 电力市场与绿电 | 24 | 83% | |
| 数字化与网络安全 | 60 | 90% | A/B 边界执行良好 |
| 科技创新 | 26 | **96%** | 标注口径修订后大幅回升（原 73%） |
| 企业经营管理 | 82 | 95% | |

### 6.3 结构化字段侧

![图 4　结构化资产对照：167 个数据库、2,336 张表、31,493 个字段全部完成类目对照，98.2% 的字段有明确类目归宿；未被覆盖的 5 个类目均已定性并说明处置方式。](./images/fig-04.png)

**资产覆盖**：31,493 个字段落到 272 / 277 个类目上，**叶覆盖率 98.2%**。未覆盖的 5 个类目原因明确——风电与光伏资产台账（数据集缺表）、储能设施检修试验（新建待填）、电价信息（真电价表未纳入本次盘点）、安全评估测评资料（文档型，非结构化侧已覆盖）。

**准确率抽样**（按业务域分层抽取，整表提交、字段级输出）：

| 样本 | 四级精确 | 一级大方向 | 定级一致 |
|---|---|---|---|
| 43 张表 / 645 字段 | 78.0% | 96.4% | 91.9% |
| 结构细化 + 边界口径定案后 | 约 84%（**推算值**，未重跑全量） | 96.4% | 92% |

分域：A 域能源业务 83%、B 域系统运行与安全 75%（细化前仅 14%）、C 域经营管理 75%。

**为什么字段侧比文档侧低约 10 个点**：文档有完整上下文——一份保电方案通篇都在讲保电；字段只有几个字的说明，比如 `co_qty` 对应「供货数量」，只能靠整表上下文兜底。字段级分类在行业内本就比文档级困难，这个差距是结构性的，不是调优不到位。

## 七、最重要的发现：这一轮的收益是「稳」，不是「高」

结构细化前后，文档侧准确率其实略有下降：

| 指标 | 细化前 336 类目 | 细化后 356 类目 |
|---|---|---|
| 四级精确 | 92.1% | 91.2% |
| 一级大方向 | 97.9% | 97.3% |
| 定级一致 | 96.3% | 96.2% |

净减 5 篇，落在文档侧固有波动范围内。如果只看这张表，会得出「细化没用甚至有害」的结论。

但真正的变化在另一个指标上：

| | 结构细化前 | 结构细化后 |
|---|---|---|
| 同一批数据连跑两轮，判定一致率 | 86.3% | **97.0%** |

![图 5　结构化侧的准确率与判定稳定性：四级精确 78%（结构完善后约 84%）、一级大方向 96.4%、定级一致 92%，两轮判定一致率 97%。](./images/fig-05.png)

原因很直接：细化前 90 张表挤在一个类目里，模型每次都在同一堆无法区分的候选中随机挑选；拆开后每一类都有可辨识的特征词，判定固定下来。

**这个提升的意义大于任何准确率数字。** 一致率 86% 意味着同一份数据两次跑出不同结果的概率接近七分之一，此时 ±5 个点的准确率差异全落在噪声里，你无法判断一次调优是真的有效还是恰好抽到了好签。一致率到 97% 之后，±1.5 个点才开始有统计意义——**准确率这个量本身，从这一刻起才变得可信**。

这也是为什么本轮细化「冲的是字段侧」：文档天然有完整上下文，本来就不太受粗类目困扰；而字段侧的 B 域准确率从 14% 提到 75%，靠的正是同一次结构手术。

> **实践观察**：评估一套分类分级方案时，「同一批数据连跑两轮的一致率」应该是比准确率更靠前的验收项。它便宜（跑两遍就行）、无法操纵（不依赖测试集构造），而且直接决定了准确率数字有没有意义。这一项在多数 PoC 方案里都是缺席的。

## 八、低置信度是资产，不是缺陷

520 篇的置信度分布：

![图 6　置信度分层：95.4% 的文档落在 ≥0.90 区间且其中准确率 94.6%，2.1% 的低置信件自动转人工——低置信几乎精确圈出了全部难判样本。](./images/fig-06.png)

| 置信度 | 篇数 | 占比 |
|---|---|---|
| 0.95 | 196 | 37.7% |
| 0.90 | 300 | 57.7% |
| 0.85 / 0.75 | 4 | 0.8% |
| 0.70 | 8 | 1.5% |
| ≤0.60 | 12 | 2.3% |

关键在两端：

- 高置信（≥0.9）496 篇中命中 469 篇，**准确率 94.6%**；
- 低置信（<0.6）11 篇中**仅命中 1 篇**。

也就是说，**低置信几乎精确地圈出了所有难判样本**。这条对运营的意义比准确率更大：平台可以把 2% 的低置信件自动推给人工复核，其余 98% 直接采信，而不是让人工在几万条结果里大海捞针。

一个会诚实报告不确定性的引擎，比一个准确率高两个点但永远输出 0.95 的引擎更有工程价值。这也是判断一套工具是不是真 AI 的观察点之一，详见[《如何分辨真假 AI 数据分类分级：三类伪 AI 工具与七项 PoC 测试》](/insights/identify-fake-ai-classification)。

## 九、45 篇偏离里，24 篇是标注错了

全量测试的 45 篇偏离全部人工逐篇核对，分诊结果出人意料：

| 归因 | 篇数 | 说明 |
|---|---|---|
| **标注本身有误** | ~24 | 引擎判的反而是对的 |
| 引擎判据措辞需加强 | ~20 | 已通过在分叉层补写排除／导流措辞修复 |
| 标准树口径需明确 | 2 处 | 启动验收记录是否含交接电气试验；储能设施是否含用户侧接入台账 |
| 真两可 / 混题文档 | ~11 | 人判也会犹豫，明确不再调优 |

标注错误里最集中的一类共性错误值得单独提出来——**把「围绕数据的活动文档」标成了数据类目**：

- 接入规范 → 被标成量测数据
- 校核报告 → 被标成出清结果
- 处置记录 → 被标成系统日志
- 比对试验研究 → 被标成监测数据

20 条标注修订里有 14 条是这一类。「科技创新」业务域最初只有 73%，就是因为大量交接试验、成果、标准被标进了科研叶子，口径修订后回升到 96%。

还有一个更微妙的现象：三篇内容相同的交接电气试验报告，人工标注给出了三个不同答案，而引擎三次判定完全一致。**引擎的一致性反而暴露了标注的不一致。**

> **实践观察**：当测试准确率不理想时，第一动作不应该是调模型或改树，而是抽查偏离样本的标注质量。在这个项目里，如果直接按 91.2% 去调优，会有一半的力气花在把引擎往错误答案上掰。

## 十、坦率说明局限

1. **测试集是合成的。** 见 §6.1。真实文档进场后需要重新建立基线。
2. **字段侧 84% 是推算值**，基于结构细化和边界口径定案后的局部验证，未重跑全量。
3. **约 19 篇两可／顽固残留已明确收手**：混题文档、「数据 vs 活动文档」的天然灰区、低置信抖动。继续调优边际收益为负。
4. **属性标签体系目前是设计稿**。平台侧的标签字典表、打标 API、按标签过滤视图三项能力需要立项开发；过渡期属性以目录明细表列形式维护。
5. **重要／核心数据全部是候选清单**，须逐项核实认定。标准文本中一律用「候选／拟识别／待核实」表述。
6. **仍有若干口径待客户业务侧最终拍板**，包括内部检查报告与监管检查通知的归属、自有机房用能数据归属、用户侧储能口径、平台类报告的 A/B 域归属。

## 十一、给电力企业的落地建议

| 优先级 | 事项 | 说明 |
|---|---|---|
| P0 | 先做全库资产盘点，再定树的粒度 | 用「每叶承载字段数」「一叶跨来源系统数」两个指标找过粗的类目，而不是凭经验拍层级 |
| P0 | 把 A/B 域判据写成一句话并编译进执行规则 | 只写在标准文本里，机器执行不到 |
| P0 | 在标准正文里明确数仓分层不改变分类归属 | 否则数据中台会污染整棵树的统计口径 |
| P0 | 重要数据只出候选清单 | 认定权不在企业，措辞要留纪律 |
| P1 | 先测一致率，再看准确率 | 同一批数据连跑两轮，一致率不到 95% 时准确率数字没有意义 |
| P1 | 真实文档抽样 50 篇建立对比基线 | 合成基线不能替代真实场景 |
| P1 | 组织维度做成标签，不要做成目录层级 | 否则分类的技术划分会割裂组织的管理责任 |
| P2 | 建立动态维护机制 | 年度复评 + 触发式复评（设施投运、用户认定变化、指南修订） |

---

电力行业的数据分类分级和金融行业有一个根本差异：金融的监管文件把分级要求写得很细，企业的主要工作是对标；能源行业的指南给了明确的原则和识别规则，但把三、四级的建设权和责任一并交给了企业。**这意味着标准本身的质量，就是这项工作的质量。**

而标准的质量能不能被验证，取决于它是不是可执行——能不能让机器按同一套判据、在同一批数据上、稳定地跑出同一个结果。这也是这个项目里最花力气、也最值得的部分。

其他行业的对照可以参考[《数据分类分级不只是金融的题：数据安全法第 21 条与十个行业合规地图》](/insights/cross-industry-compliance-map)和[《医疗数据分类分级：临床、科研、运营三重维度与已在发生的数据交易》](/insights/healthcare-classification)。

—— 模界数智