找得到舊資料，不代表答得出現況：StateBench 測的是長文件模型的另一種能力

2026年11月4日，Allen Institute for AI（Ai2）研究團隊的 StateBench 評測整理發布，把長文件模型的「狀態追蹤」能力單獨拉出來檢驗。這個詞聽起來技術味很重，但它對應的情境其實很日常：一份合約改了三版、一張訂單被取消又重下、一位客戶的聯絡方式換過兩次，系統最後講出來的，到底是哪一個版本？

搜尋和追蹤，是兩種不同的能力

先分清楚兩件事。搜尋，是在一堆文字裡找到「曾經寫過什麼」。追蹤，是判斷這些先後出現的更新之間，誰取代了誰、誰還有效，最後還原出目前的狀態。

用生活比喻：搜尋像在聊天紀錄裡搜尋「聚餐地點」這個關鍵字，你會找到好幾則訊息；追蹤則是看完那幾則訊息後，知道聚餐最後改成哪家餐廳。前者只要找得到，後者要分得出先後和覆寫關係。

StateBench 把追蹤任務分成四層複雜度。第一層是只寫入一次的固定變數；第二層允許把變數改成新值，也就是覆寫；第三層允許依變數本身的舊值計算更新，例如「餘額加上一筆款項」；第四層則包含變數互換等一般有限狀態追蹤。每往上一層，更新之間的依賴關係就更纏繞。

研究結果值得注意：受測的預訓練模型，連第三層「依變數舊值更新」都沒有穩健解決。不過要強調，這是在合成序列上的測試結果，不能直接推論成企業知識庫的實際成效。

長文件評測已經有好幾套，StateBench 補的是哪一塊

長文件評測不是新題目，既有幾套基準各自看不同的面向。

LongBench 以 21 個資料集、6 類任務評估模型，涵蓋問答、摘要與程式補全等工作。它給的是綜合比較，能看出模型在各種長文任務上的相對表現，但無法單獨指出多次覆寫之後，模型答的目前值對不對。

Lost in the Middle 檢查的是另一個變數：答案在輸入中的位置。研究把含答案的段落移到長輸入的開頭、中段或結尾，觀察模型回答是否改變。結果顯示，多款模型在答案位於中段時表現明顯下降，長上下文模型也不例外。換句話說，文件一長，答案放在哪裡本身就會影響模型取用的成功率。

RULER 則把「大海撈針」式的檢索題擴展為 13 種任務，測了 17 個長上下文模型，包括多跳追蹤與彙整。模型在基本檢索題上接近滿分，但輸入拉長到 32K tokens 時，只有一半達到研究設定的滿意表現。這說明只用單一線索的檢索題驗收，可能高估長文件處理能力。

StateBench 補的位置很明確：前面幾套測的是找得到、放哪裡找得到、拉多長還找得到；它測的是多次更新之後，最後狀態答不答得對。

知識庫驗收為什麼容易漏掉這一塊

企業知識庫常見的驗收方式，是拿幾題「文件裡寫過什麼」來問，答對就過關。這種題目測到的是檢索，加上檢索增強生成（RAG）流程正常的話，多半不會太差。

問題出在真實文件不是靜態的。同一份規範改版、同一個專案狀態推進、同一筆客戶資料多次更新，這些內容被切成片段放進知識庫後，系統若只會「找出曾出現過的文字」，就可能拿舊版回答現況。驗收題沒有覆寫情境，這個缺口就不會被看見。

這也是長任務評測的共同課題。先前我們整理過Taste-Bench 怎麼考 AI 代理的判斷力，它把長期任務切成決策分岔來評；StateBench 對長文件做的是類似的事，把「讀完整份文件」切成一次次的更新套用。

具體可採用的驗收步驟並不複雜。先挑幾筆在文件中有多個版本的資料，例如改過的時程或換過的負責人；接著分別問「文件曾提過哪些版本」和「目前的值是什麼」兩種題目；最後比對第二種題目的答案與文件實際的最終狀態。第一種答對、第二種答錯，就代表問題出在狀態追蹤，而不是檢索。

讀分數時的三個保留

判讀 StateBench 的結果，有幾件事要放在心上。

其一，測試用的是合成序列，不是真實企業文件。合成環境能控制變數、分層歸因，但真實文件裡的實體命名、格式混雜與更新間隔，都是合成題目沒有的雜訊。

其二，論文報告的是預訓練模型的表現。實務上知識庫會搭配 RAG、分段與提示設計，這些工程手段可能補足一部分追蹤能力，也可能掩蓋模型的原始弱點，兩者要分開驗。

其三，就像Microsoft Scope 把驗收拆成可逐條打勾的條件的思路，長文件系統的驗收也該從「平均分數」走向「哪一層任務通過、哪一層沒通過」。StateBench 的分層設計正好提供這種顆粒度：知道系統卡在覆寫還是卡在依舊值更新，後續要加工程補位才知道補在哪裡。

對正在導入或評估知識庫問答系統的團隊來說，這項研究最實際的用處，是提醒驗收題單裡該有「現在是什麼狀態」這一類題目，而不只有「文件寫過什麼」。兩種題目都過關，才算同時驗了檢索與追蹤。