Reasoning Core 讓程序推理資料更好用

很多團隊都想用合成資料補推理訓練，但常常卡在同一件事：資料看起來對，訓練起來卻不一定有用。這篇論文就是在處理這個落差。

Reasoning Core 用 50 個生成器與語意評分、難度控制，證明廣泛的程序化資料能強化 completion-supervised 推理訓練。

• 研究機構：arXiv 摘要未明確標註
• 核心數據：50 generators
• 突破點：廣泛程序化蒐集

這篇論文提出 Reasoning Core，一套專門給 completion-supervised reasoning training 用的程序化資料庫。它不是只做單一題型，而是把數學、邏輯、規劃、狀態追蹤、形式語言、結構化資料、遊戲、因果推理和程式碼都放進來。重點不是「有合成資料」而已，而是「怎麼把合成資料做成真的可訓練訊號」。

這篇想修的痛點是什麼

程序化生成器的優點很直觀：可以大量產生可驗證的推理題，成本也比人工標註低。對訓練推理模型來說，這很誘人。問題是，這類資料一直有個老毛病：量上得去，不代表品質跟得上。

摘要直接點出，這個領域作為 completion-supervised fine-tuning 的資料來源，受到的重視還不夠。也就是說，很多人知道可以用程序化資料，但不一定有一套成熟的方法，去確保這些題目真的在教模型想學的能力。

這裡的關鍵在 completion-supervised。它不是單純讓模型看 prompt 和 response 的配對，而是讓模型從目標完成內容本身學習。如果題目太簡單、太吵、或是跟目標能力對不齊，模型即使「看過很多題」，也可能沒有學到什麼實質東西。

Reasoning Core 要解的，就是這個「合成了很多，但訓練效果不穩」的問題。論文的立場很明確：程序化生成本身不夠，生成器、目標、評分方式都要一起設計。

Reasoning Core 到底怎麼做

Reasoning Core 的核心是 50 個 generators。每個 generator 都會產生可驗證的推理問題，而且覆蓋多種任務域。摘要列出的範圍很廣，包含數學、邏輯、規劃、狀態追蹤、形式語言、結構化資料、遊戲、因果推理與程式碼。

這代表它不是在做單一 benchmark 專用資料，而是在做一個跨任務的程序化資料庫。對訓練來說，這種設計的價值在於可以把推理能力拆成不同面向，讓模型不只練一種題型，而是接觸到更廣的推理結構。

但真正讓它和一般合成題庫拉開差距的，是附加在生成器外面的控制層。摘要提到 semantic scorers、difficulty controls 和 task evaluators。白話一點，就是系統不只負責出題，還會判斷題目有沒有意義、控制難度高低，並檢查任務渲染與評分是否正確。

這點很重要。因為在合成資料流程裡，最怕的不是「完全錯」，而是「看起來沒錯」。如果題目格式、答案目標、評分規則之間有細微不一致，模型可能會學到偏掉的訊號。Reasoning Core 的設計就是在減少這種隱性錯誤。

論文還做了 audits，而且不是只做一次。摘要寫到，他們用 model-assisted review、human adjudication 和 regression testing，並把這些檢查用在 Reasoning Core 的開發過程，也用在比較用的資料集合上。這透露出一個訊息：這篇不只是比資料量，更是在比資料工程的嚴謹度。

論文證明了什麼

作者用 matched completion-supervised protocol 來評估，並把 Reasoning Core 跟 Procedural Warmup、Reasoning Gym、SynLogic 做比較。比較範圍涵蓋四種 base-model 設定，以及多個訓練時長。

在主要的 3B 比較裡，Reasoning Core 在 DROP、LogiQA、ARC-Challenge 的平均分數最高。摘要也說，它超過了沒有使用程序化資料的基線，以及另外三套替代的程序化資料集合。

不過，這篇摘要沒有公開完整 benchmark 數字，所以我們無法只靠來源文本說它到底贏多少。能確認的是，作者聲稱效果不是只出現在單一資料集或單一模型設定，而是至少在主要 3B 設定下成立，且他們確實測了多個 base-model 設定與不同訓練長度。

另一個值得注意的結論是 task-level analysis。摘要明講，semantic validity 並不保證 training utility。這句話很有份量，因為它直接打臉一種常見直覺：只要題目語意上合理，就應該能拿來訓練。論文的觀察是，事情沒那麼簡單。

換句話說，一個生成器就算能產出「看起來正確」的題目，也不代表這些題目真的能有效推動模型學習。對資料工程來說，這是很實際的提醒。

對開發者有什麼影響

如果你在做 LLM 訓練、評測或合成資料管線，這篇的訊息其實很直接：synthetic 不等於高品質。你不能只看覆蓋率，也不能只看能不能自動生成。

對 completion-supervised 設定來說，目標完成內容本身就是訓練訊號。這表示資料設計要很在意幾件事：目標要夠精簡、難度要可調、題目渲染後還要保持和原本想訓練的解空間一致。只要其中一環歪掉，訓練效果就可能被稀釋。

這篇論文也給出一個很實務的工作流方向。若團隊自己做合成推理資料，至少要考慮 semantic scoring、difficulty controls，還有對生成、渲染、目標和評分之間的 mismatch 做 audit。摘要甚至明說，他們在審核過程中找到了細微的不一致，這代表這類 bug 真的會藏在流程裡。

對產品團隊來說，這也意味著程序化資料不是「丟進去就會變強」的外掛。它更像一套需要持續校準的資料系統。你要管的不只是題目數量，還有題目的可學性。

限制與還沒回答的問題

這篇摘要的方向很清楚，但它也留了不少空白。最直接的就是：沒有公開完整 benchmark 數字、沒有每個任務的細項差距，也沒有說明到底是哪一類 generator 對提升貢獻最大。

我們也不知道這些 audits 的成本有多高，維護 50 個 generators 會不會很吃工程資源，或者這套設計在實務上是不是容易擴充。這些都會影響它能不能變成可重用的訓練配方。

另一個問題是可轉移性。摘要能確認的是，作者在主要 3B 設定下看到 DROP、LogiQA、ARC-Challenge 的優勢，也說測了多個 base-model 設定與訓練時長。但它沒有告訴我們，這套程序化設計原則是否同樣適用於其他模型大小、其他推理 benchmark，甚至非推理任務。

所以這篇比較像是把方向立住：程序化推理資料要有效，重點不只是「有沒有生成」，而是「有沒有被設計成真的能學」。

結論

Reasoning Core 不是單純擴大合成資料庫，而是把程序化推理資料做成更適合 completion-supervised training 的形狀。它靠的是廣泛任務覆蓋、語意評分、難度控制和嚴格審核，而不是只靠資料量堆上去。

對開發者來說，這篇最實際的提醒是：做推理資料時，先問自己資料有沒有「可訓練性」，再問它有沒有「可生成性」。前者如果沒處理好，後者再漂亮也只是看起來很忙。

如果你在做合成資料管線，這篇提供的不是一個神奇公式，而是一個更務實的標準：有效的程序化資料，得同時顧到語意、難度、目標與評分一致性。

• 廣泛的程序化資料，能在 completion-supervised 推理訓練中勝過較窄的合成集合。
• 語意正確不等於訓練有效，目標設計和難度控制同樣重要。
• 對生成、渲染、目標與評分做 audit，能抓出合成管線裡的隱性錯誤。