問題與動機:不是 LLM 不會推理,而是資料層讓它做不到

工業資產管理會產生大量結構化資料:sensor telemetry、work order、failure mode 分析、設備層級結構、維護排程。近年大家想用 LLM agent 來自動回答維運問題、預測故障、建議維護動作。

IBM 的 AssetOpsBench(KDD 2026)是第一個系統性評估這類 agent 的 benchmark。它以真實 data center 的 4 台 chiller、2 台 AHU 為背景,提供四個專業 domain agent(IoT telemetry、failure mode/symptom reasoning FMSR、time-series foundation model TSFM、work order WO)與一個全域 orchestrator,並比較兩種 LLM 協調範式:

• Agent-As-Tool:ReAct 式的 supervisor,把 domain agent 當工具來選用。
• Plan-Execute:Planner-Reviewer 把問題拆成 DAG,在共享記憶體上執行。

關鍵發現是:最強模型 gpt-4.1 在 Agent-As-Tool 下也只達到約 65% 的 Task Completion,Plan-Execute 反而掉到約 38%,沒有任何模型超過 70%。所有設定的資料存取都是透過工具讀取 document store(CouchDB、YAML、CSV)。

本文作者觀察到一個關鍵點:這些失敗大多不是推理失敗,而是資料存取失敗——幻覺出的設備識別碼、跨文件數錯事件數量、無法 traverse 設備依賴關係、捏造 sensor 讀數。這些其實是「叫 LLM 去做 counting / joining / traversing」這類本該由結構化查詢引擎確定性處理的工作。

由此提出中心假設:對結構化的維運領域而言,資料模型才是主要瓶頸。導入 knowledge graph 作為資料層,應該能在「任何 LLM 介入程度」下都提升準確率。注意:本文實驗用的是 benchmark v1 release 的 139 個場景(KDD 版本共 141),全文「139 scenarios」指的就是這個快照。

核心框架:把 Knowledge Graph 當成「Grounding Substrate」,依問題 route

本文最重要的概念定位是:typed knowledge graph 不是一個能回答一切的 oracle,而是一個 grounding substrate(接地基底)。有些問題可以直接查圖、有些需要圖演算法、有些則需要資料中根本沒有的知識,因此作者用一個 router 把每個問題導向「最適合回答它的層」。

這個定位很關鍵,因為它讓「deterministic 99%」是一個誠實的天花板——它只是「graph-answerable queries 的上限」,而不是宣稱圖能答一切。GAK 與外部推論路徑負責補上剩下的部分。

作者也特別強調:本文與 AssetOpsBench 的研究問題是正交(orthogonal)的。IBM 比較的是「LLM orchestration 範式」,在固定資料層上沒有模型過 70%;本文則固定 orchestration(用 Agent-As-Tool 風格),改變「工具背後的資料層」,顯示這個軸把同樣 65% baseline 拉到 82–83%(NLQ)與 99%(deterministic)。兩個軸可以疊加。

Knowledge Graph 的建構:8 步 ETL 與 schema 設計

作者把 AssetOpsBench 的資料源透過 8 步 ETL pipeline 轉成 typed graph,最終約有 1,360 個 node(14 種 label)、約 2,500 條 edge(21 種 relationship type)。

四個資料源的轉換:

1. EAMLite(企業資產管理):提供設備層級。建立 1 個 Site、4 個 Location(Mechanical / Electrical / HVAC / Utility)、11 個 Equipment node(CWC04xxx 識別的 chiller),用 contains_location、contains_equipment 連結。Equipment node 帶 ISA-95 level 分類與 ISO 14224 asset class 屬性。
2. CouchDB JSON:sensor metadata。建立 110 個 Sensor node(每台 chiller 10 個),帶 type/unit/range,透過 has_sensor 連到 Equipment。
3. FMSR YAML:定義 12 種 failure mode(如 "Compressor Overheating"、"Refrigerant Leak")。每個成為 FailureMode node,並用 Sentence-BERT 生成 384 維 embedding,放進 HNSW 向量索引做相似度檢索;monitors edge 連 sensor 到它能偵測的 failure mode。
4. Event CSV:6,256 筆統一事件(work order / alert / anomaly)帶 ISO timestamp。建立 Event node 透過 for_equipment 連 Equipment,支援時間查詢與事件 counting。

依賴拓撲(dependency topology):作者在原始資料之外額外加上設備依賴層——depends_on(熱/電依賴,如 AHU 依賴 chiller 供冷)、shares_system_with(共享基礎設施,如同一冷卻迴路上的 chiller)。這層讓 cascade analysis 與 criticality ranking 成為可能,而這正是 flat document 模型完全做不到的。

實作平台:使用 Samyama——一個 embedded graph database,支援 OpenCypher 查詢、HNSW 向量索引、以及 PageRank、NSGA-II 多目標最佳化等圖演算法庫。Python SDK 讓圖能在 in-process 建立,不需外部 server。

四種架構與「Inverted LLM Pattern」

本文評估四種架構,差別在於 LLM 介入程度,但場景固定、只改資料層。

Architecture A:Tool-Augmented LLM(AssetOpsBench baseline)

LLM 一手包辦五件事:intent parsing、tool selection、argument crafting、data interpretation、answer synthesis;資料源是沒有 typed schema 的 document store。這就是 Agent-As-Tool baseline,GPT-4 在 139 場景上達 65%。

Architecture B:LLM 生成 Query(NLQ + Graph)

核心是反轉 LLM 的角色:不要它「對原始資料推理」(廣泛問題),而是要它「給定 typed schema 寫一條 Cypher」(狹窄問題)。後者就是 code generation——LLM 的強項。圖引擎接手 traversal、counting、aggregation、relationship reasoning 等確定性工作。NLQ pipeline 會提供 schema(node label、edge type、property 名稱與範例值)與 few-shot Cypher 範例;若執行失敗會把錯誤訊息回饋重試一次,最後 LLM 從結構化結果合成自然語言答案。

Architecture C:Deterministic Handlers(無 LLM)

用 keyword routing 把 question pattern 對應到事先寫好的 Cypher。完全不用 LLM,是「我們把答案寫好了」的軟體工程方案。它展示的是「有了對的資料模型,已知 query pattern 能達到的天花板」——所以 99% 應讀作「graph-answerable queries 的上限」,而非「圖能答一切」。

Architecture D:Generation-Augmented Knowledge(GAK)

許多場景刻意設計成答案不在資料中(例如問一個圖裡根本沒有的 electric motor 的 failure mode),benchmark 自己標 deterministic:false。GAK 的做法是:lookup miss 時,LLM agent 生成 Cypher CREATE 把缺失的實體與其 failure mode 物化進圖,now-complete 的 subgraph 再確定性地回答。這是 RAG 的反向:不是把文字檢索進 LLM context,而是讓 LLM 把結構化事實寫進圖。

GAK 之所以「誠實」而非「把模型輸出洗白成資料」,靠兩個性質:(1) provenance:每個物化 node 都標 source:"LLM-derived",可稽核、與資料衍生事實分離,也證明圖建構過程從沒讀過答案 key;(2) semantic caching:enrichment 每個知識缺口只跑一次,後續同類問題命中物化 subgraph、降回 Architecture B/C,LLM 成本只付一次。真正的學習型推論(如 time-series forecasting)不在 GAK 範圍,交給外部模型,圖只負責 grounding。

Inverted LLM Pattern(關鍵洞見)

連結 A 與 B 的核心是「inverted LLM usage」:A 問的是「LLM,從這份資料回答這個問題」(要 count、correlate、traverse——LLM 一貫弱項);B 問的是「LLM,給你 schema,寫一條 Cypher」(從規格做 code generation——LLM 一貫強項)。同一顆 LLM,問題範圍對準它的強項,就有大幅進步。作者主張這可推廣到任何有 typed schema 的結構化領域:schema-aware query generation 勝過 free-form data reasoning。

實驗結果:三層比較、re-scoring 與 GAK

139 場景的三層結果(Table 3)

關鍵論證:GPT-4、GPT-4o、gpt-4.1 三代模型的 NLQ 結果幾乎一致(82–83%),代表這 ~17 個百分點的提升來自 knowledge graph,而非模型升級。

分類別表現(Table 4,deterministic vs. NLQ GPT-4o)

Deterministic 在 IoT/FMSR/TSFM/Multi 都 100%,WO 為 94%;NLQ 多數類別 85–93%,但 Multi-agent 只有 40%(8/20)。原因是 20 個中有 12 個需要執行 TSFM pipeline(time-series forecasting、anomaly detection),這無法用 Cypher 表達——是結構性限制,不是查資料的問題。Deterministic 唯二失敗(ID 411、424)是 work order bundling 的 response-format mismatch,不是知識缺口。

IBM 3-axis rubric re-scoring(Table 5)

為了與 KDD leaderboard 直接比較,作者用 IBM 三軸 rubric(Task Completion y1 / Data Retrieval y2 / Result Verification y3)重新評分(用 gpt-4o judge 替代 llama-4-maverick judge,temperature 0.3 跑三次取平均)。結果:NLQ gpt-4.1 over graph 的 y1=0.708 勝過 IBM gpt-4.1 Agent-As-Tool 的 0.65;因為 LLM、orchestration、場景全相同,差距完全歸因於資料層。三代模型 y1 緊密落在 0.665–0.708,再次顯示資料層主導。注意 y2(Data Retrieval ≈0.48–0.51)低於 IBM 的 0.77,完全是被 TSFM 場景(retrieval 得 0,因為它們需要跑 ML inference 而非查資料)拉低。

NLQ 的 prompt 演進(Table 6)

NLQ 經過三版 prompt engineering:v1 naive(55%)→ v2 few-shot+顯式 property schema+retry(78%)→ v3 真實 property 值+anomaly schema+Cypher-first(83%)。一個鮮明例子:v1 時 FMSR 只有 30%,因為 schema introspection 回傳的是 node metadata(['id','labels','properties'])而非真實 property 名,導致 LLM 生成 fm.properties 而非 fm.name;光是修正 schema prompt 就把 FMSR 拉到 93%。結論:schema 描述的品質和底層資料模型一樣重要。

40 個 graph-native 自訂場景(Table 8、9)

作者新增 40 個需要圖結構、向量檢索或圖演算法的場景(multi-hop dependency、cross-asset correlation、failure similarity、criticality、maintenance optimization、root cause、temporal pattern)。對比 GPT-4o(無圖):

最大進步落在 failure similarity(+0.401)與 criticality analysis(+0.372)——正好是依賴 dependency edge 與向量檢索的能力,LLM 用參數知識無法複製。GPT-4o 的 6 個失敗都需要 PageRank、BFS traversal 或向量相似度,顯示一道硬性能力邊界:再多 prompt engineering 也無法讓 LLM 執行圖演算法。

擴展 467 場景(HuggingFace release,Table 10)

在完整 467 場景(6 domain、26 設備類型)上,deterministic handler 達 100% pass(467/467)、平均分 0.848。作者新增三種 node type(MonitoringRule、PHMScenario、HFScenario)與三個 handler。rule_logic 得分最高(0.949,因為閾值規則偵測是純圖運算),PHM 較低(0.787,因為 RUL 預測/fault classification 需要超出圖儲存的分析模型)。

GAK 在 88 個非確定性場景(Table 11)

在 benchmark 自己標 deterministic:false 的 88 個 failure-mode/sensor 場景上(10 種圖中不存在的設備類型),GAK:

• enriched 設備類型:10/10
• 可答性提升:0 → 100%
• 過 rubric 場景:72/88 (81.8%),平均 judge 分 0.882
• 物化 failure-mode node:201 個,全標 source:LLM-derived
• 每類型平均 enrichment 延遲:33.6 s(只在 cache miss 時付出)

81.8% 與 text-to-Cypher 在 graph-resident 資料上的 82–83% 驚人地接近,再次印證「資料層一旦被填滿就主導表現」。最弱的類型(reciprocating engine 6/10、electric motor 5/9)反映的是 one-shot enrichment 偶爾漏掉 rubric 要的特定 failure mode,而非捏造錯的——這是 conservative 的失敗模式。

分析:為何資料模型是瓶頸,以及完整 pipeline 定位

資料模型本身讓某些查詢結構性困難或不可能

• 跨文件 counting:「CWC04009 在 2019 有幾個事件?」在 document store 要 LLM 掃多份 JSON、parse 日期、aggregate,規模一大就出錯;圖上 MATCH (e:Event) WHERE e.equipment_id='CWC04009' RETURN count(e) 確定性執行。
• 關係 traversal:「哪些 sensor 監測 overheating?」在圖上是一個 edge hop (s:Sensor)-[:MONITORS]->(fm:FailureMode);document store 則要把 YAML failure 定義與 CouchDB sensor metadata 做沒有顯式連結的 cross-source join。
• 結構性不可能的操作:multi-hop cascade、向量相似度、PageRank criticality、Pareto-optimal scheduling 在 document store 上無論 LLM 多強都沒有對應實作。

為何「限制 LLM」反而有幫助

「回答這個問題」要 LLM 同時做 intent parsing、tool selection、traversal、numerical reasoning、synthesis,每步都疊加錯誤機率;「給 schema 寫 Cypher」只是自然語言→結構化查詢的翻譯任務。圖吸收掉難的部分,LLM 只留下擅長的部分——這個 separation of concerns 解釋了為何 B(同模型 ~+17pp)與 C(+34pp)都勝過 A。

完整 pipeline:LLM 屬於哪裡(§7)

作者把工業資料分三層:(1) Data Ingestion——對 90%+ 的結構化資料是純軟體工程(pandas.read_csv() → Cypher CREATE),不需 LLM;(2) Data Model——一次性架構決策,圖需要顯式 relationship typing 但換來 traversal/演算法/向量索引;(3) Query——LLM 可選,三種架構在此分歧。

對真實世界的 unstructured 資料(free-text 維護日誌、掃描 PDF、不一致欄名、sensor drift),deterministic ETL 達到極限,此時 LLM 在資料準備層提供真實價值:entity extraction、relationship detection、entity resolution、classification。由此提出完整架構:「LLMs at the edges, graph in the middle」——輸入端用 LLM 把雜亂資料結構化、中央用圖儲存乾淨 typed 資料、輸出端用 LLM 生成 Cypher。兩端 LLM 都做 generation(它的強項),圖做 data operation(它的強項)。

可擴展性與成本(Table 12)

成本不對稱很關鍵:sensor 網路每天可能上千次查詢,以每次 $0.03–0.05 計,全 LLM 架構 10K 查詢/天約 $300–500;deterministic 圖查詢 ETL 後成本為 0(NLQ 約 $30)。延遲方面 det. 63 ms、NLQ ~6 s、Arch A 5–11 s。圖還支援 real-time streaming 與 O(|E|) 的 BFS traversal。

限制、未來方向與意義

作者誠實列出的 caveats

1. Deterministic vs. autonomous:C 的 99% 是「我們把答案寫好的 pre-coded 方案」對比「autonomous agent 能否自己想出」,是不同任務,只展示資料模型天花板,並非宣稱 agent 更聰明。
2. Deterministic 範圍:99%/100% 只是 graph-answerable 的上限;對這個區別最 robust 的結果其實是不依賴任何 pre-coded 答案的同模型 NLQ lift(65%→82–83%)。
3. GAK 正確性與 provenance:LLM-derived 事實可能不完整或錯,因此全部標記;將其對照權威(如 ISO 14224)驗證後再 promote 留作未來工作。
4. LLM 非確定性:§5 的數字是 temperature 0 的單次執行,多 seed 的變異性刻劃延後處理。
5. 乾淨資料假設:AssetOpsBench 是乾淨結構化資料,真實環境更雜亂(§7.2 處理)。
6. 自訂場景定位:40 個新場景是擴充而非取代原 benchmark。
7. 不同研究問題:AssetOpsBench 評估 agent autonomy,本文評估 data model impact,兩者皆有效,結論不貶低原 benchmark。

未來方向

包括:在 FailureSensorIQ 子集(~2,667 道多選題)評估(其 typed failure-mode↔sensor↔component edge 結構天然契合);把 deterministic 與 NLQ pipeline 以 Agent-As-Tool 形式直接提交 Codabench leaderboard 做 apples-to-apples 比較;multi-seed Pass@k 變異刻劃;在 10K+ asset 多站環境評估;整合 LLM 輔助的非結構化日誌資料準備;以及對 GAK 物化事實做 provenance-aware promotion 與外部 time-series 推論路徑,完整實現 Figure 1 的 router。

為何重要

這篇論文最大的貢獻是把研究焦點從「LLM orchestration」轉向「工具背後的資料模型」,並用同一個 benchmark、同一顆 LLM、同一種 orchestration 隔離出「資料層」這個變數,證明它是比 orchestration 更大的槓桿。它也提供兩個可推廣的設計原則:inverted LLM usage(讓 LLM 只做 query 生成),以及 GAK(RAG 的反向——LLM 把結構化事實寫進圖,並全程 provenance-tag 保持可稽核)。對任何「有 typed schema 的結構化領域」想用 LLM 的工程師,這是一個務實且誠實的藍圖:LLM 在邊緣做生成,圖在中央做確定性運算,各做擅長之事。