最近在想一個問題：為什麼小模型（3B、7B 這個規模）在數學和程式題上越來越能打，但只要問到需要廣泛背景知識的問題，就立刻原形畢露？

這個問題困擾我一陣子了，直到最近整理了一些研究資料，我才覺得自己稍微想清楚了一點。

Reasoning 和 Knowledge Coverage 是兩回事

我們習慣把「模型能力」當作一個整體評估，但嚴格來說，這裡面至少有兩個非常不同的東西在運作。

第一個是 reasoning，也就是推理能力。給你一道數學題、一段程式碼、一個邏輯謎題，你能不能一步一步推導出正確答案。這種能力有個特性：它在某種意義上是可以「壓縮」的。推理的過程有結構，有可學習的模式，如果你用對了訓練方式，理論上不需要巨大的參數量就能學會相當強的推理鏈。

第二個是 knowledge coverage，也就是你「知道多少東西」。這個東西就很不一樣了。世界上的知識是廣度上無限的，你必須在訓練時把夠多的事實、概念、領域知識都塞進參數裡，才有辦法回答各種問題。這個東西，目前沒有什麼好的方法可以「壓縮」，你就是需要廣泛的參數覆蓋。

這個拆分方式對我來說是一個視角轉換。過去看到小模型在某些 benchmark 上追平大模型，我的第一反應是「是不是資料品質問題」或「是不是訓練 trick」，但現在我會先問：這個 benchmark 考的是 reasoning 還是 knowledge？

Verifiable Reasoning 為什麼適合小模型

有一類問題我稱它為 verifiable reasoning，也就是「答案可以被驗證的推理任務」。數學題有正確答案，程式碼能跑不能跑一目了然，邏輯謎題有固定解法。這類問題的特性是：你不需要記住大量世界知識，你需要的是沿著正確路徑一步一步往前走的能力。

在這種設定下，小模型的劣勢確實可以被大幅縮小。如果訓練資料夠乾淨、curriculum 設計得好，讓模型從簡單到難地學習推理鏈，加上強化學習的回饋讓它學會什麼樣的推理步驟是「對的」，再用 self-distillation 不斷精煉自己的推理品質，這套流程是有機會把 3B 這個規模的模型推到相當高的推理上限的。

但關鍵字是「推理上限」，而不是「整體能力上限」。一旦題目需要對特定領域有背景知識，比如你要解一道物理題但不知道某個定律，或者你要回答一個歷史問題但訓練資料裡沒有，再強的推理能力都救不了你。

這對小模型設計和部署意味著什麼

如果上面的框架是對的，那我覺得它對實務上怎麼使用小模型有幾個直接的啟發。

首先，小模型的最佳應用場景可能是「reasoning-heavy、knowledge-light」的任務。程式碼生成、數學計算、結構化推論、邏輯驗證，這些都很適合。你不需要一個巨大的模型來做 code review，你需要的是一個推理鏈夠穩的模型。

其次，任務路由（task routing）這個概念會越來越重要。不是所有問題都送給同一個大模型，而是先判斷這個任務的性質，推理型的就路由給訓練過 reasoning 的小模型，知識型的就去查 RAG 或送給大模型。這樣的架構在成本和效果之間可能有更好的 tradeoff。

第三，便宜的推理引擎是可行的，但要定義好「便宜」指的是什麼。如果你的任務是可驗證的推理，一個訓練良好的小模型可能比大模型更快、更便宜、也更準。但如果你的任務需要廣泛知識，直接用小模型反而可能是錯誤的節省。

我還沒想清楚的部分

坦白說，這個框架我自己也還有一些疑問。

「reasoning 可以壓縮，knowledge 不行」這個論斷並不是絕對的。某些形式的知識其實也有結構，有沒有辦法用更聰明的方式讓小模型存取外部知識，同時又保留推理能力？RAG 是一種嘗試，但它的問題是需要正確的 retrieval，而 retrieval 又需要一定的背景知識來判斷什麼是相關的。

還有一個問題是，我們現在說的 reasoning 能力，到底有多少是真正的「推理」，有多少其實還是在記憶訓練資料裡出現過的推理模式？這個問題在 verifiable reasoning 的場景下比較難察覺，因為答案是對的，但不代表模型真的在「推理」。

這兩個問題我覺得都值得繼續追，也可能影響這個框架的適用範圍。

不過就目前來說，「把 reasoning 和 knowledge 拆開來想」這個角度，對我理解小模型的極限在哪裡、適合做什麼、怎麼設計系統架構，確實有幫助。分享出來，看有沒有人有不同的想法。