LLM 會算，但不一定照步驟做

這篇研究在測 LLM 能不能照步驟執行指令，而不是只看最後答案對不對。

很多 LLM 評測都盯著 final answer。這很方便，但也可能遮住一個更基礎的問題：模型看起來會解題，卻沒有真的照著流程做。When LLMs Stop Following Steps: A Diagnostic Study of Procedural Execution in Language Models 就是直接抓這個落差，檢查模型能不能把簡單的算術程序按原樣跑完。

這篇論文真正關心的，不是「模型會不會算」，而是「模型有沒有照做」。這個差別很重要。只要工作流程依賴固定步驟、狀態更新、或中間值傳遞，模型一旦跳步、提早收尾、或自己多加操作，最後答案就可能錯得很安靜。

這篇在補哪個洞

作者鎖定的是常見 benchmark 的盲點。最後答案正確，只能證明結果對；不能證明過程有被忠實執行。對開發者來說，這個差異很現實，因為很多 LLM 應用本來就是程序型任務：先解析輸入，再更新變數，接著依序套規則，最後輸出結果。

在這種情境下，模型就算偶爾靠捷徑答對，也不代表可靠。它可能在短流程表現正常，但一旦步驟變長、需要保留中間值、或輸出必須反映完整操作順序，就開始失真。這篇研究就是要把這個風險量化出來。

論文使用的是一個診斷型 benchmark。任務本身刻意保持簡單：模型拿到一個分步的算術演算法，再加上兩個數字輸入，最後要回傳算出的結果。難點不在數學，而在程序長度變長，以及步驟之間有前後依賴。

方法怎麼做，白話版

這個 benchmark 的設計重點，是把「忠實執行指令」和「猜對答案」拆開。它不是要測廣泛推理能力，而是要看模型能不能按指定演算法逐步跑。這樣一來，研究者比較容易看出模型是在追蹤流程，還是在偷懶猜結果。

有兩個設計很關鍵。第一，算術本身很簡單，所以不是在考高難度計算。第二，程序會越來越長，而且某些步驟要回頭依賴前面算出的中間值。這就形成一個控制良好的壓力測試：流程一拉長，模型還能不能維持一致的執行軌跡。

這篇研究總共評估 14 個模型、55 個 datasets。原始摘要沒有提供更多 benchmark 細節，所以沒有其他數字可以再延伸。不過，這樣的設定已經足夠看出一個趨勢：程序越長，模型越容易失去忠實度。

• 輸入：分步算術演算法與兩個數值
• 任務：回傳最後計算結果
• 壓力來源：更長的流程、前後依賴的中間值
• 規模：14 個模型、55 個 datasets

結果到底說了什麼

最直接的結果，是 first-answer accuracy 隨著程序變長而大幅下滑。跨 14 個模型與 55 個 datasets，平均 first-answer accuracy 從 5-step procedures 的 61%，掉到 95-step procedures 的 20%。對一個算術本身不難的任務來說，這個落差很大。

這代表問題不只是「題目太難」。模型更像是在維持執行軌跡時失手了。也就是說，短流程時看起來還行，步驟一多、依賴一深，可靠度就明顯下降。

作者也分析了 generation-level 的失敗模式，讓結果比單一正確率更有畫面。文中提到幾種反覆出現的模式：missing answers、premature answers、self-correction after an initial error、under-executed traces，以及 hallucinated extra steps。這些都不是小瑕疵，而是模型明顯偏離原始程序的訊號。

摘要沒有提供更細的 benchmark 分項，也沒有更完整的表格數字。換句話說，這是一篇診斷研究，不是那種把各種系統性能一口氣攤開的全面評測。

對開發者有什麼影響

如果你把 LLM 放進需要精準步驟順序的流程，這篇研究是個警訊。模型可能在推理型 benchmark 看起來很強，但一旦要求它忠實執行程序，表現就不一定穩。這包含結構化資料轉換、規則式工作流、多步驟計算，或任何需要保留中間狀態的 prompt。

對工程團隊來說，重點不是不用 LLM，而是不要把「答案看起來對」和「真的照程序做」混為一談。只檢查最後輸出，很容易漏掉提早結束、跳過步驟、或自己補出不存在操作的情況。這些錯誤一旦進到自動化流程，成本可能不低。

這篇研究也有它的限制。它測的是算術程序，所以是受控的診斷情境，不是完整的真實世界工作流。摘要沒有主張更大範圍的產品部署結果，也沒有提供超出上述 aggregate accuracy 與失敗類型以外的 benchmark 細節。所以它最適合被讀成一個具體弱點的證據，而不是對 LLM 推理能力的總結判決。

但核心訊息很清楚：最後答案正確，不代表過程有被忠實執行。只要你的應用在乎流程一致性，就不能只看單次生成結果。這篇研究提供了一個很直接的理由，去做更多 guardrails。

實務上，最值得做的事，是直接測 step fidelity。只要 prompt 或 workflow 裡有順序，就不要假設模型有照著走，除非你真的驗過。這篇研究顯示，流程一拉長，可靠度會掉得很快，即使底層任務本身簡單到讓人以為很安全。

換句話說，LLM 不只是會不會答對的問題，還有會不會老實照做的問題。對想把它接進產品的人來說，這篇論文提醒得很實際：如果流程不能錯，光靠一個生成結果通常不夠。