百度文心團隊 11 月 9 日在技術部落格發表自動研究系統 ERNIE Evolve。依部落格描述，系統讓多個智慧代理分工推進一項研究：選定方向、提出假說、修改程式碼、執行評測、複核結果。團隊用它跑了四項公開最佳化任務，其中三項超越既有最佳成績；另外也在自家 ERNIE-5.5-Flash 的推理部署上做了三項優化。
五個角色，兩層迴圈
系統分為外層與內層。部落格的概括是：
「外層決定研究什麼，內層負責把一個方向做好。」
外層的 Director 從經驗庫與知識庫中挑選下一個要驗證的方向，並決定從哪一份程式碼起步，可以是原始程式碼、歷史最佳版本、中間版本，也可以是上游最新提交。內層的 Selector 每一輪選出一個候選版本作為起點，並寫下本輪假說，參考的除了分數，還有程式碼改動、失敗原因與歷史結果。Executor 則在隔離環境中修改程式碼。
後兩個角色負責把關。Evaluator 放在被最佳化的程式庫之外，所有智慧代理都看不到它，進步幅度超過雜訊門檻才會被接受；Reviewer 檢查改動有沒有偏離本輪方向、成績是不是鑽了評測漏洞，偏離方向的版本不能成為最佳版本，鑽漏洞的則直接作廢。自動最佳化系統最常見的毛病，是學會討好分數、程式碼本身卻沒有變好，這兩道關卡就是衝著這一點而來。
公開任務的成績
| 任務 | 原最佳 | ERNIE Evolve |
|---|---|---|
| NanoChat AutoResearch(驗證集 BPB，越低越好) | 0.8878 | 0.8763 |
| NanoGPT Speedrun Track 1(達標訓練時間) | 39.9 秒 | 38.9 秒 |
| NanoGPT Speedrun Track 3(達標訓練步數) | 2690 步 | 2590 步 |
| SOL-ExecBench(平均 SOL 分數，越高越好) | 0.827 | 0.819 |
SOL-ExecBench 沒有拿到第一，但高於 Recursive 的 0.676 與 Hyra-1.0 的 0.736。公開任務的最佳化結果放在 GitHub 的 ernie-research/ERNIE-Evolve-Results 儲存庫，ERNIE Evolve 系統本身是否開源，部落格並未提及。
推理最佳化的一筆帳
工業任務的數字更大。崑崙芯 P800 的低延遲情境，系統跑了四輪、四個研究方向，生成速度達到基準線的 623.6%，並通過全部正確性檢查。部落格提到其中一項關鍵發現：原有通訊路徑並未實際啟用 DeepEP 低延遲通訊。六倍多的提速裡，有多少來自找出這處沒生效的設定、多少來自新的最佳化方法，部落格並未拆開說明。
確定性推理那一項，吞吐量提升 33.7%，單一 token 生成時間縮短 26%，首個 token 延遲縮短 12%，確定性維持不變，前後約 3 天。GPU 極致解碼一項，系統提出 7 個方向，其中 3 個帶來提升，解碼速度提高 14.9%，精度與基準線一致。
粗算一下：吞吐量多 33.7%，同樣的請求量所需的顯示卡數約為原來的 75%(1 ÷ 1.337)。如果這項優化能整體搬到線上叢集，省下的大約是四分之一的推理算力。三項任務各花了多少 GPU 小時，部落格並未揭露，這筆帳目前只能算出收益這一側，成本這一側是空的。
部落格對難度寫得很直白：
「基準線也已包含工程師針對確定性推理做的專項優化，剩下的改進單項往往只有 1% – 2%，與測量波動相當。」
不少假說被實驗證偽，例如單次跨卡通訊已接近延遲下限，這個方向就停在那裡。
團隊在文末提到，遞迴式自我改進(RSI)的擴展必須可控、可暫停，並接受安全評估與人工監督。從已揭露的任務來看，ERNIE Evolve 目前改的是訓練腳本與推理程式碼，還沒有碰到模型本身的訓練過程。
參考來源：百度文心 ERNIE 技術部落格、ERNIE-Evolve-Results 開源儲存庫、CocoLoop；核對四項公開任務成績與 ERNIE-5.5-Flash 三項推理優化幅度。