工业运维智能体的准确率上不去，问题往往不在模型，而在数据层。一篇基于 AssetOpsBench 基准的研究把同一个 GPT-4、同一批工业维护场景放在两种数据模型上对比，结论相当直接：把扁平文档换成带类型的知识图谱，任务完成率可以从 65% 提升到 99%。
先看清失败：不是推理错了，是取数错了
AssetOpsBench 是 KDD 2026 发布的工业资产运维基准，包含专家编写的维护场景，数据来自真实数据中心的冷水机组与空气处理机组，以 CouchDB 的 JSON 文档、YAML 配置和 CSV 事件表组织，提供物联网遥测、故障模式与症状推理、时序基础模型查询、工单管理等专用智能体。在该基准上，GPT-4 采用 Agent-As-Tool 范式只能做到 65%（91/139），榜单上最强的 gpt-4.1 也停在约 65%，没有任何模型超过 70%。
作者逐条检查失败案例后发现，多数不是推理失败，而是数据访问失败：编造设备编号、跨文档数错事件、无法遍历设备之间的依赖关系、虚构传感器读数。这些恰恰是结构化查询引擎能确定性完成的工作，却被交给了语言模型去做计数、连接和遍历。
做法：让大模型写查询，让图去执行
研究团队用一条 8 步 ETL 流水线，把四类数据源转成一张带类型的知识图谱：从企业资产管理数据生成站点、位置、设备三层结构，设备节点带 ISA-95 层级分类与 ISO 14224 资产类别属性；从传感器元数据生成传感器节点并按 has_sensor 关联设备；从故障模式定义生成故障模式节点，用 Sentence-BERT 生成 384 维嵌入并建 HNSW 向量索引，再用 monitors 边连接能监测该故障的传感器；事件与工单则成为时间维度上的节点。最终形成 781 个节点、955 条边、16 类关系的图。
关键在于”反向使用大模型”：不让模型直接在原始数据上推理，而是让它依据带类型的模式（schema）生成 OpenCypher 查询，由图引擎确定性执行。同一模型下，这种”自然语言转查询”的做法比在文档上自由推理高出约 17 个百分点。
三层对比：65%、82%、99%
在同一批 139 个场景上，三种架构的结果分层清晰：确定性图处理器（不含大模型）达到 99%（137/139）；大模型生成 Cypher 查询达到 82%—83%；而原始的文档检索加工具调用基线仍是 65%。换句话说，数据层是独立于编排范式的更大杠杆——基准榜单只在固定数据层上比较编排方式，效果差异远小于换数据模型。
作者还补充了 40 个”图原生”场景，专门测试扁平文档结构上难以实现的能力：多跳依赖分析、向量相似检索、基于 PageRank 的关键性排序、级联影响分析、维护优化与时序模式。在扩展后的 HuggingFace 版本（467 个场景、6 个领域、26 类设备）上，确定性图处理器达到 100%（467/467），平均得分 0.848。
对工业知识工程的启示
第一，知识图谱的价值不只是”给大模型补充上下文”。把图当作检索层（Graph RAG）只是第一步，把图当作执行层、让模型只负责把自然语言翻译成结构化查询，才能绕开上下文窗口的瓶颈，并获得精确的聚合结果。第二，成本结构会变：按每次查询 0.03—0.05 美元计，每天一万次查询的纯大模型方案约需 300—500 美元，而确定性图查询在 ETL 完成后几乎不产生推理成本。第三，本体设计仍是前置工作——设备层级、监测关系、故障模式这些类型与边，必须在建图时想清楚。
对制造企业而言，这条路径的落地顺序应该是：先把设备、传感器、故障模式、工单整理成有类型的图，再把高频、规则明确的查询固化为确定性处理器，最后才把长尾的自然语言问句交给大模型生成查询。
资料来源：Knowledge Graphs as the Missing Data Layer for LLM-Based Industrial Asset Operations — arXiv（2026）。本文为技术要点整理/编译，非原文全文。