Research/·5 min read·OraCore Editors

LongCoT:測長鏈推理,不只看答案

LongCoT 用 2,500 題測試模型能否在長鏈、互相依賴的推理步驟中保持一致。GPT 5.2 與 Gemini 3 Pro 仍低於 10%。

Share LinkedIn
LongCoT:測長鏈推理,不只看答案

多數模型評測,最後都在看同一件事:答案對不對。LongCoT: Benchmarking Long-Horizon Chain-of-Thought Reasoning 想問的更難。模型能不能在一長串彼此依賴的推理步驟裡,還維持住思路,不中途走偏?

這不是學術上的小題大作。只要是代理人、長流程自動化、或需要逐步規劃的工作,一個前面的小失誤,就可能一路滾成最後的大錯。LongCoT 的核心,就是把這種「長鏈推理」單獨拉出來量測。

這篇論文要解的痛點是什麼

作者先指出一個現實:現在的語言模型越來越常被放進複雜任務裡,不再只是回答單題。這時候,成功不只看某一步做得漂不漂亮,而是看模型能不能記住前文、維持計畫、在很長的推理路徑中不偏航。

LongCoT:測長鏈推理,不只看答案

但傳統評測常常抓不到這件事。模型可能在短題、單步題、或資訊很集中的問題上表現不錯,卻在需要很多互相牽動步驟的任務裡失手。LongCoT 想補的,就是這個落差。

作者的設計思路也很直接:如果每個單一步驟本身都還算可解,那最後失敗時,比較能歸因到「長距離推理能力不夠」,而不是模型連局部子題都不會。換句話說,LongCoT 想分清楚兩件事:模型是「會解題」,還是「能一路把計畫做完」。

LongCoT 到底怎麼設計

LongCoT 是一個可擴充的 benchmark,收錄 2,500 題專家設計的問題。題目涵蓋化學、數學、電腦科學、西洋棋和邏輯。這個範圍很重要,因為它不是只測單一領域的技巧,而是想讓長鏈推理這件事本身,成為主要壓力來源。

每題都有短輸入,也都有可驗證的答案。但真正難的地方,不在於 prompt 有多長,而在於解題過程裡,模型得穿過一張由互相依賴步驟組成的圖。這些推理鏈可以拉到數萬到數十萬個 reasoning tokens 的尺度。也就是說,挑戰不是「看到很多字」,而是「在很長的依賴關係中還能保持正確方向」。

對開發者來說,這個設計很有辨識度。它刻意把測試焦點放在 long-horizon chain-of-thought,而不是泛泛地測知識量、語料記憶,或單純的模式配對。這讓它更像一個針對長流程任務的壓力測試。

因為每一步本身都不是特別難,所以這份 benchmark 不是在問模型能不能做算術、能不能做基礎推理,而是在問:當你已經做對好幾步之後,你還能不能繼續做對下一步,並且一路維持到最後。

論文實際證明了什麼

摘要給出的結果很直接,也很刺眼:在論文公開時,表現最好的模型在 LongCoT 上都還不到 10% 準確率。GPT 5.2 是 9.8%,Gemini 3 Pro 是 6.1%。

LongCoT:測長鏈推理,不只看答案

這些數字傳達的訊息很明確:前沿模型和真正的長距離推理之間,還有很大的落差。論文主張的重點不是模型完全不會解題,而是它們沒辦法穩定地把推理維持在長時間、長依賴的結構裡。

不過,這份摘要沒有公開完整 benchmark 細節。像是各領域分數、不同題型的表現差異、或更細的消融分析,這裡都看不到。所以我們能確定的是 top-line 結果;但要進一步判斷哪一類任務最難、哪種錯誤模式最常見,還需要看論文全文。

即便如此,LongCoT 的價值還是很清楚。它提供了一個比較嚴格的量測框架,讓研究者可以追蹤前沿模型到底是在短題變強,還是真的在長鏈推理上也有進步。

對開發者有什麼影響

如果你在做 agent、copilot,或任何要跨很多步驟完成的工作流,LongCoT 很像一個提醒:所謂「模型很會推理」,其實不是單一能力。模型可以在局部子問題上看起來很穩,卻在長流程任務中失去一致性。

這會直接影響產品設計。評測不能只放單輪問答,或幾個短推理題就結束。真正要上線的系統,最好也包含長距離依賴測試,看看模型會不會在中途漂移、漏掉前文約束、或把原本的計畫做歪。

也因此,就算是前沿模型,很多情境下還是得靠 orchestration、檢查機制、retrieval、以及逐步驗證來補強。LongCoT 不是在說模型沒用,而是在提醒工程師:如果任務很長,單靠一次性生成答案,風險還是很高。

  • 評估長流程 agent 時,別只看最終答案。
  • 短題表現好,不代表長鏈推理也可靠。
  • 長任務的失敗,常常不是語法錯,而是思路漂移、依賴漏接、或計畫斷掉。
  • 如果能驗證中間步驟,就不要只做 final-answer-only 評測。

這篇研究的限制與未解問題

這篇論文的摘要把 benchmark 的方向講得很清楚,但也留下不少實作層面的問題。像是這些互相依賴步驟到底怎麼建出來、不同領域的難度怎麼平衡、以及 benchmark 對記憶或表面捷徑有多抗性,摘要都沒有交代。

另外,雖然摘要有給出兩個模型的 top-line 分數,但沒有更多完整 benchmark 細節。也就是說,單靠這份來源,我們還不能判斷不同模型家族誰進步比較快,也不能知道某些題型是不是特別容易讓模型崩掉。

但這不影響 LongCoT 的核心意義。它不是又一個只看對錯的題庫,而是試著把「長距離、深依賴、持續一致性」這件事量化。這對現在越來越多要跑長流程的 AI 系統來說,很實用。

如果這個 benchmark 之後能被更廣泛使用,它可能會成為一個很有參考價值的尺。不是拿來問模型「有沒有答對一次」,而是問:當路很長、依賴很深、前面一個小錯就可能污染後面全部結果時,這個模型還能不能把思路守住。

對開發者來說,這篇論文最大的提醒,不是某個新演算法,而是新的評估視角。你要問的問題,可能不只是「模型會不會解題」,而是「模型能不能在長鏈推理裡,持續做對下一步」。