AssetOpsBench 给出的数字很扎眼：139 个真实工业运维场景，GPT-4 在“智能体即工具”模式下只完成 65%，换成计划—执行模式掉到 38%，当时没有任何模型超过 70%。多数人把这当成模型能力问题，这篇论文却去查失败案例，发现大量错误不是推理错，而是取数错：设备编号编造、跨文档计数错、设备依赖走不通、传感器读数瞎编。
把文档仓换成类型化图谱
作者把基准的四类数据源做成一张图：EAMLite 提供设备层级，CouchDB 的传感器元数据、FMSR 的故障模式 YAML、事件 CSV 统一进图。直接用基准数据构出的图有 12,647 个节点、9 种标签、12,662 条边、5 种关系（包含位置、包含设备、配有传感器、属于设备、监测）；再叠加设备依赖拓扑和扩展场景的类型，得到 14 标签、21 边类型的完整模式。故障模式节点用 Sentence-BERT 生成 384 维向量，建 HNSW 索引；设备之间加 depends_on 和 shares_system_with 边，才能做级联分析和关键度排序。
四种架构，一条路由
架构 A 是原基准：LLM 自己解析意图、选工具、取数、解释、作答，数据层是平的文档。架构 B 把 LLM 的角色收窄成“写查询”：给它图模式（标签、边类型、属性名和示例值）和少量 Cypher 示例，让它生成查询，由图引擎确定性地执行遍历、计数、聚合，失败时把报错回喂重试一次。架构 C 干脆不用 LLM，用预写处理器把问题模式映射到 Cypher，代表“数据模型对了之后的天花板”。架构 D 处理“答案根本不在数据里”的场景：查询落空时，智能体生成 Cypher CREATE 语句，把缺失的实体和故障模式写成带 provenance 标签的节点，物化后再由查询确定回答。
结果：65%、83%、99%
同一批 139 个场景，同一个 GPT-4，只换数据层，通过率从 65% 升到 82%–83%；换成 GPT-4o 或 gpt-4.1，结果几乎不变，说明提升来自图而不是模型换代。确定性处理器达到 99%，但作者自己拆台：139 个答案里只有 86 个真由图查询产出，53 个是靠领域知识兜底，所以 99% 是“图可回答”的上限，不是智能体自主性的证明。
更有说服力的是 88 个基准自己标为“非确定性”的故障模式场景，覆盖十种图里没有的设备类型。GAK 把可回答的设备类型从零提到 100%，按基准评分标准答对 81.8%，物化的 201 个节点全部带 source:LLM-derived 标签，可与真实数据区分、可审计。另加 40 个图原生场景，故障相似度提升 0.401、关键度分析提升 0.372；而在 467 个场景的扩展集上，扩展图谱的通过率 100%、平均分 0.848。
论文留了几个诚实的口子：时序预测类场景仍然答不了（多智能体场景里 12/20 需要跑 TSFM 流水线，NLQ 只有 40%）；提示词里的模式描述写错一次，FMSR 场景只有 30%，原因是 schema 自省返回了节点元数据而不是真实属性名，只改提示词就升到 93%——模型不是不行，是规格给错了。一句话总结：结构化域里，数据层比编排范式更决定成败，而 LLM 最该干的活是“按模式写查询”，不是“凭记忆算数”。
资料来源：Knowledge Graphs as the Missing Data Layer for LLM-Based Industrial Asset Operations — arXiv（2026-05）。本文为技术要点整理/编译，非原文全文。