AI智能运维解决方案:让AI理解建筑对象、运行规则和权限边界,辅助运维人员判断和处置
AI智能运维不是把大模型接入平台后做问答演示。建筑运维问题往往涉及设备、空间、系统、点位、规则、权限和历史记录,只有把这些专业关系组织成可理解的知识结构,AI才能给出可靠解释。比如“冷冻泵频率异常”不仅是一个文本问题,它关联冷机负荷、水泵状态、阀门开度、供回水温差、室外温度、历史工单和控制权限。
古河AI智能运维方案以建筑本体知识为基础,结合IBMS、BIOT、BEMS、FM工单、设备台账和历史告警数据,提供自然语言查询、告警归因、影响范围判断、处置建议、报告生成和可审计执行。方案坚持人机协同:AI提供解释和建议,关键控制动作必须经过权限校验和人工确认。
图:AI智能运维解决方案总体架构。IBMS告警与BIOT时序数据进入AI能力层做归因和预警,所有处置建议经人机协同层确认执行并全程留痕。
一、适用场景
- 园区、医院、公共建筑、实验室、管廊和多项目云平台。
- 告警数量多、系统复杂、资深人员经验难复制的运维团队。
- 需要自然语言查询、告警解释、知识库沉淀和辅助决策的项目。
二、现状问题
- 告警多但原因不清,值班人员依赖经验判断。
- 设备、空间、点位和规则缺少语义关系,AI难以理解真实场景。
- 历史工单和维修经验分散,不能复用到新事件。
- 涉及设备控制时缺少权限、确认和审计机制会带来风险。
三、产品功能在方案中的作用
AI智能运维方案里的产品功能必须说清楚“AI做什么、不做什么、依据是什么、如何确认”。否则容易变成泛泛的智能问答。
- AI本体知识平台负责建立建筑、空间、系统、设备、点位、规则、权限和事件之间的语义关系。
- AI智能运维平台负责自然语言查询、告警解释、影响范围判断、相似案例检索和处置建议。
- IBMS和BIOT提供实时状态、历史曲线、告警、控制反馈和点位质量,作为AI判断依据。
- FM工单和知识库提供历史故障、维修方法、备件、复核结论和专家经验。
- 权限与审计功能负责约束AI建议和控制动作,关键动作必须人工确认。
四、建设目标
- 建立建筑本体知识,表达空间、设备、系统、点位、规则和权限关系。
- 接入实时状态、告警、工单、巡检、维保、能耗和设备台账。
- 实现自然语言查询、告警归因、影响范围判断和处置建议。
- 形成权限校验、人工确认、执行回采和审计记录闭环。
五、方案边界
AI智能运维是辅助决策和知识增强系统,不应绕过IBMS、工单和权限体系直接控制设备。对于关键设备控制,AI只能给出建议或生成待确认任务,最终执行必须由授权人员确认并保留日志。
总体架构
AI智能运维架构由知识层、数据层、推理层、交互层和执行审计层组成。知识层决定AI是否懂建筑,数据层决定判断是否可靠,审计层决定能否安全落地。
系统组合
知识底座建筑本体、设备关系、点位语义、规则阈值和预案。
运行数据IBMS、BIOT、BEMS、工单、巡检和历史告警。
AI能力自然语言查询、告警归因、相似案例、策略建议和报告生成。
安全闭环权限校验、人工确认、执行日志和效果回采。
架构层次
- 本体层:组织建筑、空间、系统、设备、点位和事件关系。
- 数据层:接入实时数据、历史曲线、告警、工单和台账。
- 推理层:进行告警解释、影响范围、相似案例和策略建议。
- 交互层:提供问答、看板、报告和移动端辅助。
- 审计层:记录建议、确认、执行和结果。
关键设计原则
- 先建设知识和数据质量,再上线AI场景。
- 先做查询和解释,再做建议和执行闭环。
- 关键动作必须人工确认,不能黑箱控制。
- AI输出应能引用数据依据和规则依据。
产品组件与部署方式
AI智能运维部署应先做知识和数据,再做交互。没有本体、规则和可信数据,AI回答越流畅越危险。
- 第一阶段建设建筑本体、设备关系、点位语义、高频告警和操作边界。
- 第二阶段接入IBMS、BIOT、BEMS、FM工单、设备台账和运维制度文档。
- 第三阶段上线查询、解释、报告和相似案例,不直接开放控制。
- 第四阶段对低风险建议进行人工确认闭环,对高风险动作保持只建议不执行。
- 持续阶段根据采纳率、误判、漏判和复盘结果维护知识库。
标准与协议依据
AI运维属于快速演进领域,但合规边界和术语口径已有可依据的文件:
- 《生成式人工智能服务管理暂行办法》(2023年施行):大模型服务提供与使用的合规边界。
- GB/T 41867-2022《信息技术 人工智能 术语》:AI能力描述的标准术语口径。
- GB/T 22239-2019《网络安全等级保护基本要求》:AI访问运行数据时的权限、审计和安全要求。
- ITIL事件管理实践:告警分级、升级和复盘流程的参考框架。
- MQTT、HTTP API:AI服务与IBMS、工单系统之间的集成接口。
古河在AI运维方案中坚持人机协同原则:AI负责解释、归因和建议,控制类动作必须保留人工确认。
接入对象与数据治理
AI智能运维需要的数据比普通报表更复杂,不只是实时点位,还包括点位含义、设备关系、空间位置、规则、预案、历史故障和人员权限。
接入对象
- IBMS设备状态、告警、控制反馈和联动记录。
- BIOT点位模型、设备关系、历史数据和质量状态。
- BEMS能耗异常、设备运行和节能策略记录。
- FM工单、巡检、维保、维修、备件和服务评价。
- 设备说明、操作手册、预案、制度和专家经验。
数据治理要求
- 为设备、点位、空间、系统和事件建立统一语义。
- 高频告警建立原因、影响、核查步骤和建议动作。
- 知识库更新要有审核和版本记录。
- AI可查询、可建议、需确认和禁止执行的边界要明确。
安全与权限
AI涉及运维建议和可能的控制动作,必须接入权限体系。任何影响设备运行的建议都应经过角色权限、风险校验和人工确认,执行结果回写并保留审计记录。
核心建设内容与业务流程
1. 建筑本体知识建设
本体知识把建筑对象和关系表达清楚,使AI知道设备属于哪个系统、点位代表什么含义、告警影响哪些区域。
- 空间、系统、设备、部件、点位和事件关系建模。
- 规则、阈值、预案和操作边界整理。
- 高频问题和历史工单知识化。
2. 运维问答与状态查询
值班人员可以用自然语言查询设备状态、告警趋势、能耗异常和工单记录。查询结果应能追溯到来源数据。
- 查询某楼层、某设备或某系统当前状态。
- 查询近一周重复告警和未闭环工单。
- 生成值班摘要和运行日报。
3. 告警归因与影响分析
告警发生后,AI结合实时状态、历史曲线、空间关系和历史工单,给出可能原因和核查路径。
- 分析告警可能原因和关联设备。
- 判断影响范围、风险等级和责任班组。
- 推荐核查步骤和相似案例。
4. 策略建议与审计执行
AI可以提出策略建议,但执行必须进入人机协同流程。
- 建议调整运行模式、巡检任务或工单处理方式。
- 关键动作人工确认后执行。
- 记录建议、确认人、执行结果和回采数据。
产品功能建设清单
AI智能运维产品功能要围绕“可解释、可追溯、可确认、可审计”建设。
1. 建筑本体建模功能
本体功能让AI理解建筑对象之间的关系,而不是只读文本。它决定AI能否把告警和真实设备、空间、系统联系起来。
- 建立建筑、楼层、房间、系统、设备、部件、点位、事件和人员角色关系。
- 维护点位含义、单位、阈值、读写属性、控制边界和关联规则。
- 支持本体版本管理、审核发布和变更影响分析。
2. 运维知识库功能
知识库应沉淀制度、手册、预案、历史工单和专家经验,并能与实时数据结合。
- 导入设备说明书、操作规程、应急预案、巡检标准和维修记录。
- 把高频告警整理成原因、影响、核查步骤、处置建议和风险提示。
- 知识更新需要审核、版本和适用范围,避免过期经验误导现场。
3. 自然语言查询功能
查询功能要返回可追溯答案,而不是泛泛回答。每个回答应能说明数据来源。
- 查询某设备当前状态、历史曲线、近期开停机、告警和工单。
- 查询某区域未闭环问题、重复告警、能耗异常和巡检情况。
- 生成值班摘要、运行日报、事件说明和设备健康摘要。
4. 告警归因与影响分析功能
告警归因要结合实时数据、历史趋势、设备关系、空间关系和历史案例。
- 对告警给出可能原因、相关点位、影响区域、风险等级和核查顺序。
- 推荐相似工单、历史处置方式、相关设备和下一步检查项。
- 输出必须标明依据,无法判断时应提示需要人工核查,而不是强行给结论。
5. 人机协同与审计功能
AI建议进入执行前必须经过权限和风险校验。平台要记录建议、确认、执行和结果。
- 区分可查询、可建议、需确认、禁止执行四类能力边界。
- 关键动作生成待确认任务,由授权人员审批后通过IBMS或工单执行。
- 记录AI建议、引用依据、确认人、执行结果、回采数据和复盘评价。
6. AI评估与安全护栏功能
AI智能运维上线后需要持续评估,不应只看回答是否通顺。平台应记录命中、采纳、驳回和误判情况,用于优化知识和规则。
- 对每次AI解释记录告警类型、引用数据、建议动作、人工反馈和最终结论。
- 对高风险系统设置回答边界,例如消防、配电、医气、电梯等只给核查建议,不直接生成控制动作。
- 对低置信度或数据不足的情况,AI应提示需要人工核查,并列出缺失数据。
7. 报告生成与知识运营功能
AI还应承担运维知识沉淀工作,把值班记录、事件复盘和月报生成变成可审核的生产流程。
- 根据告警、工单、巡检和设备状态生成值班摘要、事件说明、设备健康报告和月度复盘草稿。
- 报告内容应保留数据来源和人工修改记录,避免不可追溯的自动结论。
- 复盘后形成新的知识条目、规则优化和相似案例,进入审核发布流程。
典型闭环场景
- 告警解释:告警触发、AI归因、人工确认、工单处理、知识沉淀。
- 状态查询:自然语言提问、数据检索、来源引用、报告生成。
- 策略建议:AI建议、权限校验、人工确认、执行回采。
- 知识更新:复盘问题、更新规则、审核发布、下次复用。
验收口径与运维指标
验收口径
- 重点系统、设备、点位和高频告警知识覆盖完整。
- 自然语言查询、告警解释、影响范围和建议动作可演示。
- 权限校验、人工确认、审计日志和结果回采完整。
- 知识库更新机制和复盘流程明确。
产品功能验收用例
AI智能运维验收应避免只测试问答,要用真实告警和真实数据。
- 选择冷源、配电、能耗、门禁或环境类真实告警,验证AI能否说明原因、依据和核查路径。
- 查询某设备状态,检查回答是否引用实时值、历史曲线、告警和工单来源。
- 验证AI建议进入人工确认流程,检查权限、审批、执行日志和结果回采。
- 抽查知识库更新记录,确认高频问题有审核、版本和适用范围。
运维指标
知识覆盖率反映AI理解建筑对象的基础。
查询成功率反映自然语言查询可用性。
告警解释命中率反映归因质量。
建议采纳率反映建议是否有用。
审计完整率反映安全闭环。
验收指标建议基线
AI能力不能停留在演示效果,应当用可统计的口径验收。古河建议约定:
- 告警解释覆盖率 ≥ 80%(接入范围内的告警类型)。
- AI建议采纳情况按月统计,形成采纳率和驳回原因记录。
- 高危控制动作 100% 人工确认,AI不得直接执行。
- AI操作与问答日志 100% 留痕,可按用户和时间审计。
- 知识库按月更新,新增故障案例和预案及时入库。
AI效果指标应随运行数据积累逐季复盘,初期基线宜保守设定,避免过度承诺。
常见问题
- AI智能运维会替代值班人员吗?
- 不会。AI更适合辅助查询、解释和建议,关键动作仍由人员确认。
- 为什么需要建筑本体?
- 因为设备、点位、空间和规则有强关系,本体能让AI理解真实运维语义。
- AI运维如何验收?
- 应通过真实告警、查询、建议、确认和审计用例验收。
相关产品组件
工程案例参考
相关专题与文章