LLM 會看地圖，卻撐不住長度

LLM 真的有學會推理，還是只是剛好吃到熟悉題型？這篇 Generalization in LLM Problem Solving: The Case of the Shortest Path 用一個很乾淨的合成最短路徑環境，來拆解這個問題。作者不是只看模型會不會解題一次，而是把「換一張沒看過的地圖」和「把題目拉長」分開測，想知道模型到底是在泛化，還是在某個範圍內碰巧表現好。

這個切法很重要。因為現實裡，LLM 的表現常常混著很多因素：訓練資料看了多少、是監督式學習還是強化學習、推理時有沒有額外技巧。這些東西都可能把結果撐起來，也可能把真正的能力遮住。這篇論文的價值，就是把變因壓到最少，讓大家比較清楚看到模型到底在哪裡會過關，在哪裡會崩。

它想解的痛點是什麼

這篇研究在問的，不是「LLM 能不能解一題」。那種問題太容易被表面成績誤導。真正麻煩的是：模型有沒有學到一套可以重複使用的方法，遇到新輸入時還能維持住？如果只是對訓練中看過的型態反應很好，那其實不算真的泛化。

作者選的是經典的 sequential optimization 任務，也就是最短路徑規劃。這類任務很適合拿來做研究，因為規則清楚、環境可控，而且可以把不同型態的泛化拆開看。對開發者來說，這比拿一個大而雜的 benchmark 來得有用，因為你知道模型失敗時，問題比較可能出在哪一層。

更白話一點說，這篇論文不是在問「模型聰不聰明」，而是在問「模型學到的是可重用流程，還是只是在熟悉範圍內看起來很會」。

方法怎麼做，才看得出差別

研究用的是合成地圖與最短路徑任務。因為環境是自己設計的，作者可以精準控制訓練分佈，再把測試拆成兩個互相獨立的方向來看。

• Spatial transfer：模型能不能處理訓練時沒看過的新地圖。
• Length scaling：模型能不能處理比訓練時更長的路徑，也就是更長的推理鏈。

這個拆法很有意義。很多模型看起來「會泛化」，其實只是對某些版型很熟。換到新地圖，它可能還行；但只要路徑變長、步驟變多，內部推理就開始不穩。反過來也一樣，有些模型能維持一定的步驟邏輯，卻一遇到陌生布局就卡住。把這兩件事分開，才知道失敗到底是出在資料分佈，還是出在長鏈推理本身。

作者也把整條訓練與推理流程一起看。他們觀察資料覆蓋度、強化學習，以及推理時的 scaling 各自會怎麼影響結果。這讓文章不只是描述模型好不好，而是更像在找：到底是哪一段流程決定了能力上限。

論文實際證明了什麼

這篇摘要最清楚的結論，是結果呈現明顯分裂。模型在 spatial transfer 上表現不錯，代表它們能把學到的東西搬到沒看過的地圖上。可是當問題長度增加時，模型就會失手，而且這種失敗是穩定出現的。

作者把這個問題歸因於 recursive instability，也就是遞迴式推理在更長的步驟中會變得不穩。這代表模型不是完全不會想，而是當它需要持續維持一連串中間狀態時，流程會慢慢失真。換句話說，能跨地圖，不代表能撐長度。這兩種能力不是同一件事。

這裡還有一個很實用的發現：資料覆蓋度會設定能力邊界，強化學習可以讓訓練更穩，但不會把這個邊界往外推。推理時的 scaling 也能幫忙，但救不了和長度 scaling 有關的失敗模式。摘要裡沒有公開完整 benchmark 數字，所以這些判斷在目前提供的材料中是定性的，不是數值型結論。

對工程端來說，這個訊息很直接：訓練更久、decode 更聰明，不一定等於模型真的能處理更長的決策鏈。你可能只是把原本能做的題目做得更穩，卻沒有改變它能處理的問題尺度。

對開發者的實際影響

如果你在做 LLM 代理、路徑規劃、搜尋、排程，或任何多步驟決策系統，這篇研究會提醒你一件事：模型在相似輸入上表現好，不代表它能扛更難的版本。很多 production 問題不是「模型完全不會」，而是「模型在長一點、複雜一點的情境下就開始失真」。

這篇論文的合成環境雖然不是現實世界，但它提供了一個很重要的診斷框架。你要先分清楚，失敗是因為分佈轉移、訓練覆蓋不足，還是推理鏈條一拉長就壞掉。這三種狀況對應的解法很可能完全不同。

另外，這篇也不是在幫強化學習背書。它的結果比較像在說：RL 可以讓訓練過程更穩，但不保證你拿到的是更高的問題解決上限。對算力有限的團隊來說，這很重要，因為你要知道該把資源花在什麼地方。只是把模型調得更順，未必能換來你真正要的長程泛化。

限制與還沒回答的問題

這篇研究最大的優點，也是它的限制，就是控制得很乾淨。合成最短路徑環境讓因果關係比較好看清楚，但它終究不是實際的軟體流程、代理式工作流，或開放式推理任務。它告訴我們的是某一類可組合的 sequential optimization 問題，不是所有 LLM 任務的總結論。

另外，根據目前提供的摘要資料，沒有看到模型名稱、完整 benchmark 數字或更細的實驗設定。所以我們可以很有把握地說方向，但還不能從這份 raw 資料直接推到效應量有多大。這也代表讀者在解讀時要保留一點空間，不要把定性結果誤當成全面結論。

不過，這篇文章還是把一個常見的錯覺拆開了：模型在一個維度上泛化，不代表它在另一個維度也行。你不能只測「有沒有看過類似例子」，還要測「問題拉長後會不會崩」。對很多實作團隊來說，這比單看 held-out examples 更接近真實風險。

如果你正在評估 LLM 是否適合拿來做規劃或多步驟推理，這篇研究的建議其實很簡單：泛化測試要分面向做。看它能不能換地圖，也要看它能不能撐長度。少了其中一個，你很可能會高估模型真正能上線的能力。