电力系统故障处置是一个多源异构数据实时交汇的典型场景，“设备故障智能定位与诊断”“配电网智能运行管理”在国家层面已明确列为“人工智能+电网”的典型应用场景。尽管2025年全国供电可靠率已提升至99.948%，用户平均停电时间降至2.25小时/户，但单次故障的处置仍高度依赖调度员逐条查阅告警、人工比对拓扑与规程，对于为什么跳闸、该按什么规程处置、影响范围如何、抢修资源怎么调配”——仍缺乏一体化的智能体方案。本项目的立项，旨在构建一个具备自主感知、并行分析、智能决策能力的电力设备健康管理智能体，解决告警洪峰下人工响应滞后、多源数据割裂、处置方案缺乏规程依据的痛点，以RAG检索规程、图数据库查拓扑、时序库匹配波形、LLM综合推理的技术组合，切入电网故障诊断，提供一套较规范的解决方案。
板块一：物联网实时告警接入、板块二：气象API接入、板块三：SCADA/PMU数据接入、板块四：故障推理模块、板块五：工具层、板块六：输出
先将二进制/JSON告警报文录入并解析为线路ID、跳闸时间、保护动作信号等结构化字段。主要功能体现在工具层上，共分为5.1 图数据库拓扑查询、5.2 时序数据库历史波形、5.3 知识库规程文档，实现历史波形匹配，基于设备节点的抢修调度方案，规程文档建议检索。最终将告警、天气、波形三类数据聚合为统一的“故障上下文”对象交由llm进行推理输出结果。
主要负责并实现了板块一的模拟、板块四、五和六。
由于缺少硬件支持，告警的数据并非来自真实的 IEC 61850 设备。实际工作方式是：当收到告警时，根据告警中的线路 ID、故障时间、故障相别等字段，用代码硬编码生成一段故障波形，然后转成 COMTRADE 格式并写入时序数据库。并且也是因为这一点，对于真实对接的设备，给出的结构化数据可能会比模拟的更详细，甚至可能包括发出告警设备的经纬度，因此气象api接入未被接入（伏羲气象api的调用需要经纬度）
主要技术栈：包括kafka信息队列、Neo4j、postgres、TimescaleDB、qdrant向量数据库、rag重排序。
亮点（如图2）：主要体现在rag的优化策略，通过三次迭代最终选用qdrant、重排序弃用了对关键词匹配和语义匹配加权的混合检索，并且通过引入栈，在文档切片的时候通过读取将章、节等入栈作为正文的上下文并在进入新章时清空重新入栈。难点则体现在真实可用的iec61850服务端的运行以及相关硬件。
评论