圖結構編碼

如果圖（graph）無所不在——社交網路、知識圖譜、分子結構、程式碼依賴——那 LLM 能不能看懂圖？

Google Research 在 ICLR 2024 的這篇論文試圖回答這個問題。他們設計了一個 benchmark（GraphQA），系統性地測試了不同圖編碼方法、不同任務、不同圖結構對 LLM 表現的影響。結果很明確：編碼方式可以讓準確率差到 60% 以上。

核心問題：LLM 不會讀圖

LLM 的訓練資料是文字。圖是節點＋邊的結構化資料。要讓 LLM 推理圖，你得先把圖「翻譯」成文字。

但怎麼翻？節點用數字編號還是用名字？邊用箭頭表示還是用自然語言描述？這些選擇會影響 LLM 的表現嗎？

答案：影響非常大。

GraphQA：一個專門考 LLM 圖推理能力的 benchmark

Google 設計了 GraphQA，涵蓋：

  • 多種圖生成演算法：Erdős-Rényi、Scale-Free、Barabási-Albert、Stochastic Block Model，以及簡單結構（路徑、完全圖、星形圖）
  • 多種基礎任務：邊是否存在、節點/邊的數量、找出相鄰節點、檢查是否有循環
  • 多種 prompting 策略：zero-shot、few-shot、Chain-of-Thought、Zero-CoT、BAG（Build A Graph）

三種編碼維度，排列組合測試

節點編碼（node encoding）

節點用什麼來表示？

  • 整數（0, 1, 2…）
  • 常見名字（Alice, Bob…）
  • 字母（A, B, C…）

邊編碼（edge encoding）

關係用什麼來描述？

  • 括號表示法（(0,1)）
  • 自然語言（「互為朋友」）
  • 符號箭頭（0→1）

這些維度組合起來產生了多種編碼函數。

三個核心發現

發現一：編碼方式影響巨大

在所有基本任務上，LLM 的表現跟隨機猜差不多——除非你選對了編碼。

其中「incident encoding」（以節點為中心列出所有相鄰邊）在大多數任務上表現最好。不同編碼之間的準確率差距可以達到 60% 以上。

發現二：模型越大通常越好，但不是線性的

用 PaLM 2 的 XXS、XS、S、L 四個尺寸測試：

  • 大部分任務上，越大越好
  • 但「邊是否存在」這個任務，模型大小幾乎不影響表現
  • 即使最大的 L 模型，在「循環檢測」上仍然輸給簡單的 baseline

發現三：圖的形狀本身就是變因

同樣的任務，在不同形狀的圖上表現差很多。例如：

  • 循環檢測：在密集連接圖上表現好（循環到處都是），在路徑圖上表現差（路徑圖從來沒有循環）
  • 有趣的是，給幾個混合範例（有循環＋沒循環）當 few-shot 可以幫助模型適應

實務意義

這篇論文沒有提出新模型架構，但它回答了一個很實務的問題：如果你要用 LLM 處理圖資料，怎麼把圖餵給它？

答案：用 incident encoding，給 few-shot 範例，注意圖結構的特性（密集 vs 稀疏會影響表現）。

城武觀點

1. 這是一篇「基礎建設」等級的論文

沒有 fancy 的新架構，沒有 SOTA 分數碾壓。但它做的事情和「Is GPT-3 a Good Reasoner?」或「Lost in the Middle」一樣：建立一個系統性的評估框架，讓後續研究有基準可循。

GraphQA 的價值不在結果，在於它讓「LLM 圖推理」這個次領域有了一套共通的測試方法。

2. 60% 的編碼差距是一個警訊

如果你把圖隨便轉成文字丟給 LLM，你的模型可能比隨機猜還差。但換一種編碼方式，準確率可以跳 60%。

這說明了 LLM 對輸入格式極度敏感——同樣的資訊，不同的呈現方式會觸發完全不同的推理路徑。這不只是圖的問題，這是所有結構化資料的共同問題。

3. 2024 年的 PaLM 2 已經是古代史了

這篇用的是 PaLM 2。如果用今天的模型（Claude Opus、Gemini 3.5）重跑 GraphQA，結果會差多少？模型變聰明瞭，但「編碼方式影響巨大」這個命題恐怕不會變——因為 LLM 的輸入格式敏感性是架構層的問題，不是能力層的問題。

城武的未解檔案——60% 的差距提醒我們：AI 不是看不懂圖，是你沒用對方法讓它看懂。