測試時外掛讓弱模型升級

以前要靠重訓練把弱模型變強，現在強模型可直接在測試時替它搭外掛，且不改任何參數。

• 研究機構：arXiv 摘要未明確標註
• 核心數據：平均表現從 0.49 升到 0.91
• 突破點：強模型迭代建構測試時外掛

這篇論文在問一個很實際的問題：如果模型已經部署了，還能不能不重訓練，就讓它在測試時變得更可靠？作者的答案是可以，而且做法不是改權重，而是讓更強的模型去替弱模型設計一層「harness」包在外面。

這個方向很像把能力轉移，從「訓練時搬進模型裡」改成「推論時搬到系統外層」。對開發者來說，差別很大。因為重訓練通常要資料、時間、算力，還會牽動部署流程；但如果只是調整推論流程，很多場景會更快、更便宜，也比較容易在既有系統上落地。

這篇論文要解什麼痛點

傳統的能力轉移，通常發生在訓練階段。大模型當老師，小模型當學生，透過 teacher forcing 或 on-policy distillation 之類的方法，把能力塞進學生模型裡。問題是，這些方法都要更新目標模型的參數。

作者想處理的痛點很直接：如果模型已經訓練完、甚至已經上線，還有沒有辦法繼續幫它補強？尤其是在不能動權重的前提下，能不能只靠測試時的系統設計，把弱模型的輸出拉穩？

這也是為什麼這篇不是在談新的訓練法，而是在談 inference-time harness。作者把一部分原本要靠模型自己完成的工作，搬到模型外面處理。這個外層結構可以幫忙約束輸出、路由輸入，或把不穩定的推理步驟交給 deterministic code。

方法到底怎麼做

論文把這招稱為 strong-to-weak scaffolding。概念上，就是由一個更強的 builder model，替一個較弱的 target model 建立測試時外掛，然後再反覆迭代修正。

摘要裡提到的流程是：builder model 會用 5% 的資料當 validation set 來調整 harness，之後再把調好的版本拿去完整 test set 上評估。整個過程中，target model 完全不更新參數。也就是說，模型本體是 frozen 的，變的是外部包裝。

這裡的 harness 不是單純的 prompt，也不是一般的 adapter。從摘要能看出的特徵是，它可以包含 deterministic code、benchmark-specific routing，以及嚴格的 answer-format enforcement。白話一點，就是外層系統幫弱模型把容易出錯的部分先收掉，讓它在受控條件下作答。

作者還提到，這個 harness 是 iterative refinement 出來的，不是一次寫好就結束。強模型會一輪一輪修，直到外掛在驗證集上表現更穩。這種設計的重點，不是讓弱模型「想得更多」，而是讓整個推論流程「更不容易亂掉」。

論文實際證明了什麼

摘要給出的主結果很明確：平均 target-model performance 從 0.49 提升到 0.91。這是很大的差距，而且是在不更新 target model 參數的情況下達成的。

作者也試著拆解這個提升到底從哪裡來。摘要指出，主要增益來自把不穩定的模型推理卸載到 deterministic code、加入 benchmark-specific routing，以及強制更嚴格的輸出格式。換句話說，提升不是主要來自讓模型自己多想幾步，或多抽樣幾次，而是來自外層結構把流程管住。

另外，摘要還提到三個趨勢。第一，builder model 的 reasoning effort 越高，harness 品質就越好，而且是單調改善。第二，平台效應相對小，沒有 builder model 本身能力那麼關鍵。第三，越弱的 target model，得到的收益越大。

最後這點很重要。因為它暗示這種方法最適合的，可能不是已經很強的模型，而是那些你想低成本部署、但又希望它不要太不穩的弱模型。對實務來說，這正是很多產品團隊會碰到的情境。

對開發者有什麼影響

這篇論文最大的啟發，是它把優化重心從訓練搬到推論。以前大家習慣問的是：怎麼訓練出更強的模型？現在作者提出另一個問題：怎麼設計更好的外層系統，讓同一個模型現在就表現得更好？

這對開發者很有用，因為很多場景下，模型本體未必能常常重訓練，但推論流程可以改。你可以把驗證、路由、格式檢查、甚至部分脆弱推理，放到 harness 裡處理。這樣一來，可靠性提升不一定要靠改權重。

它也補了一個 distillation 之外的想像。過去我們常把大模型幫小模型，理解成「把答案或梯度教進去」。這篇則顯示，強模型也能把某種「推理結構」轉移出去，讓弱模型在外掛保護下更穩定地工作。

不過，這不代表所有系統都能直接套用。摘要沒有提供 runtime cost、latency 影響，也沒有說 harness 需要多少人工設計。對實務團隊來說，這些都是落地時一定會問的問題，但摘要沒有公開完整 benchmark 細節，所以無法從這份 raw 資料判斷代價。

限制與未解問題

先說最明顯的限制：摘要沒有列出四個 Theory-of-Mind benchmark 的名稱，也沒有提供逐項分數。這表示我們只能知道整體趨勢，不知道每個任務上的表現差異。

第二個限制是範圍。這篇只明確說自己做在 Theory-of-Mind benchmarks 上，摘要沒有宣稱更廣泛的跨領域泛化。因此，現在還不能直接把結果外推到所有任務類型。

第三個限制是依賴 builder model。摘要雖然說 builder 的 reasoning effort 越高，harness 越好，但這也代表方法的上限，仍然受限於 builder 本身的能力。換句話說，外掛不是憑空生出能力，而是把更強模型的結構化能力，轉成對弱模型有用的推論流程。

最後，摘要也沒有說明平台效應為什麼相對小。這代表跨模型家族、跨部署環境的可移植性，還需要更多資料才能判斷。對工程實作來說，這些細節會影響你能不能把這套方法複製到自己的 stack。

結語

這篇論文證明了一件事：不改模型權重，也能靠強模型在測試時替弱模型搭出有效外掛，讓表現大幅提升。

如果你在做 AI 系統，這個結果的意思很直接。除了訓練、微調、蒸餾之外，推論層本身也可以是能力提升的主戰場。尤其當你手上的模型已經固定、又想提高穩定性時，harness 可能是值得研究的工程方向。

但它目前仍是個有明確邊界的方法。摘要能證明它在特定 benchmark 上有效，卻還沒有給出完整的成本、延遲與泛化證據。對開發者來說，這很像一個很強的原型：方向值得注意，但落地前還要補很多工程答案。

• 能力轉移不一定要發生在訓練階段。
• 外層 harness 能把部分不穩定推理移出模型本體。
• 摘要只證明特定 benchmark 上有效，成本與泛化仍待補齊。