技术摘要：知识图谱作为基于大语言模型的工业资产运营缺失的数据层

问题陈述

当前用于工业资产运营的大语言模型（LLM）代理在处理扁平文档存储（如 CouchDB、YAML、CSV）进行推理时，表现出有限的准确性。AssetOpsBench 基准测试（Patel 等人，2026）表明，即使是 GPT-4 和 GPT-4.1 等领先模型，在 139 个工业维护场景中，任务完成率最高也仅为约 65%。该研究指出，失败往往并非由于缺乏推理能力，而是“数据访问失败”。具体而言，LLM 难以处理结构化查询引擎可确定性处理的操作，例如：

• 跨多个非结构化文档计数事件。
• 在没有显式链接的情况下关联来自不同源的数据。
• 遍历隐式的设备依赖关系。
• 避免幻觉出设备标识符或传感器读数。

本文的核心假设是：对于结构化运营领域，工具背后的数据模型是主要瓶颈，而非 LLM 编排范式。

方法论

作者使用相同的 139 个 AssetOpsBench 场景评估了三种不同的架构，仅改变数据层和 LLM 的角色：

1. 架构 A（基线 - 工具增强型 LLM）：

   • 机制： LLM 解析意图、选择工具、构建参数、从文档存储检索原始数据、解释结果并综合答案。
   • 数据层： 扁平文档存储（CouchDB、YAML、CSV）。
   • LLM 角色： 执行所有推理、数据遍历和聚合。

2. 架构 B（自然语言查询 + 图）：

   • 机制： LLM 被限制为基于类型化模式生成结构化的 Cypher 查询。图引擎确定性执行查询，LLM 根据结构化结果综合最终答案。
   • 数据层： 一个包含 781 个节点、955 条边和 16 种关系类型的类型化知识图谱（KG）（在完整流程中扩展为 1,360 个节点和 2,500 条边）。
   • LLM 角色： 代码生成（自然语言到 Cypher）。

3. 架构 C（确定性处理器）：

   • 机制： 预编码的处理器直接将问题模式匹配到 Cypher 查询。
   • 数据层： 相同的知识图谱。
   • LLM 角色： 无。

知识图谱构建：
作者构建了一个 ETL 管道，将 AssetOpsBench 数据源转换为图模式，包含 14 个节点标签（例如 Site、Equipment、Sensor、FailureMode）和 21 种边类型（例如 contains_equipment、monitors、depends_on）。该图谱包括：

• 具有 ISA-95 和 ISO 14224 分类的设备层级。
• 链接到设备的传感器元数据。
• 具有 384 维 Sentence-BERT 嵌入的故障模式，用于向量相似度搜索。
• 具备时间功能的事件日志。
• 建模热/电依赖关系和共享基础设施的依赖拓扑。

实现使用了 Samyama，这是一个嵌入式图数据库，支持 OpenCypher、HNSW 向量索引和图算法（PageRank、NSGA-II）。

关键结果

139 个场景的性能表现

研究表明，即使保持 LLM 模型不变，仅改变数据层也能带来显著的性能提升：

• 架构 A（基线）： 通过率为 65%（91/139），与 AssetOpsBench 排行榜上限持平。
• 架构 B（自然语言查询 + 图）： 使用 GPT-4、GPT-4o 和 GPT-4.1 时，通过率为 82–83%（114–116/139）。这代表在使用相同模型系列的情况下，相比基线提高了约 17 个百分点。
• 架构 C（确定性）： 通过率为 99%（137/139）。两次失败归因于工单捆绑中的响应格式不匹配，而非知识缺口。

扩展评估（467 个场景）

当在扩展的 AssetOpsBench HuggingFace 发布版（涵盖 6 个领域的 467 个场景）上进行评估时：

• 确定性处理器： 实现了 100% 的通过率（467/467），平均得分为 0.848。
• 图原生能力： 作者引入了 40 个新场景，要求多跳依赖、向量相似度和 PageRank 关键性分析。在这些场景中，知识图谱方法实现了 100% 的通过率，平均得分为 0.927，而无需图谱的 GPT-4o 基线分别为 85% 和 0.602。

延迟与成本

• 延迟： 确定性图查询平均为 63 毫秒，而基于 LLM 的架构为 5–11 秒。
• 成本： 对于每天 10,000 次查询，完全由 LLM 驱动的架构成本为 300–500 美元，而确定性图查询在初始 ETL 后成本为 0 美元。

意义与主张

本文提出，在结构化运营领域，数据层是主要瓶颈，其作为性能提升的杠杆比 LLM 编排范式（代理即工具 vs. 计划 - 执行）更为显著。

作者引入了 “倒置 LLM 使用” 的概念：

• 系统不再要求 LLM 对原始数据进行推理（这是一项广泛且易出错的任务），而是要求 LLM 从类型化模式中生成结构化查询（这是一项狭窄的代码生成任务，LLM 在此方面表现出色）。
• 随后，图引擎处理“困难”部分：遍历、计数、连接和算法执行。
• 这种关注点的分离使系统能够在已知查询模式上实现近乎完美的准确性，同时保留自然语言接口处理新颖查询的灵活性。

本文结论认为，对于结构化工业数据，知识图谱充当了原始数据与基于 LLM 的推理之间必不可少的集成层。结果表明，对于任何结构化领域，感知模式的查询生成优于自由形式的数据推理，且确定性处理器可实现已知运营模式的近乎完美的可靠性。

局限性与注意事项

作者明确指出了若干局限性：

• 清洁数据假设： 基准测试使用的是清洁的结构化数据。现实世界的工业环境涉及噪声传感器、扫描的 PDF 和不一致的命名，这需要 LLM 在数据摄入层（实体提取和解析）发挥作用，而不仅仅是在查询层。
• 确定性 vs. 自主性： 架构 C 的 99% 成功率反映的是预编码解决方案，而非自主代理独立找出答案的能力。
• 结构性限制： 需要机器学习推理的场景（例如时间序列预测、剩余使用寿命预测）无法仅通过查询存储的数据来解决；它们需要外部分析模型。
• 非确定性： 自然语言查询的结果依赖于随机 LLM 生成；跨多个种子的方差表征留待未来工作。