用多智能體系統增強弱推理模型

arXiv: 2605.14163 · 2026-05-13 · MIT / Tel Aviv University
Varun Sunkaraneni, Pierfrancesco Beneventano, Riccardo Neumarker, Tomaso Poggio, Tomer Galanti
「弱模型的正確答案本來就在 proposal pool 裡,問題是怎麼挑出來。」

📊 關鍵數據

方案SWE-bench Verified
GPT-5.4 nano 單獨67.0%
同模型 ×8 + critic-comparator76.4%
Gemini 3 Pro / Claude Opus 4.5 單獨~76%
Oracle best-of-8 上限79.0%

弱模型 ×8 + 驗證器 ≈ 強模型單獨。2.6% 差距來自 coverage 盲區——所有弱模型都不會解的題,換更強的 selector 也沒用。

🧠 機制拆解

元件作用限制
Proposal(生成)重複採樣放大 coverage無法自己產生 critic
Critic(驗證)外部 verification signal 篩選依賴 execution / test / proof 等可自動化驗證的信號
Comparator(比較)排名挑選最佳 proposallocal selection error 會複合成 trajectory 誤差

核心瓶頸:proposal coverage(提案多樣性),而非 selector 精度。殘餘失敗全是 coverage 盲區。

🏗️ 落地應用建議

① 多模型程式碼審查(已實作)
4 模型同步審查、≥2 共識標記的架構完全對齊論文結論。下一步:擴充模型池多樣性(不同架構/訓練資料),而非調 consensus 參數。
② 子代理任務分配策略
關鍵任務用 ≥3 個不同弱模型並行處理,取 consensus。不需每次都調用最強模型,可降 60-80% API 成本。
③ 自動化內容驗證 Pipeline
生成內容 → 多模型交叉評分 → 自動化測試(連結有效性、事實對齊官方來源)→ 僅通過的內容上線。適用於診所價格更新、衛教內容 QA。
④ 弱模型池覆蓋率監控
定期分析各模型失敗案例重疊度。若多模型同時失敗率 > 20%,代表 coverage 盲區過大,需引入異質模型。
⚠️ 關鍵限制:外部驗證信號(execution、type check、test)是必須品。純文字任務(寫作、翻譯)難以自動化驗證,coverage 增益有限。

📖 我們的筆記

這篇論文直接驗證我們的多模型審查架構。核心發現——正解已在弱模型 pool 中,瓶頸是 selection——代表我們在模型多樣性和共識機制上的投資方向正確。下一步:增加模型異質性,而非優化 selector。

回論文筆記首頁 · DKY 學習中心