📍 真實場景
阿凱,一人接案的機器學習工程師,專門幫小公司微調客製化小模型
他正在幫一家客服新創,把一個小型開源模型微調成能處理多輪疑難雜症的客服助理
😖 卡住的地方：每接一個新案子,他都要重新手寫一份強化學習訓練設定:獎勵怎麼給分、驗證規則怎麼寫、GPU排程怎麼安排——這些前置工程吃掉他一半的接案時間,而且每次都是從零開始,經驗完全無法累積、複製到下一個案子
💡 這堂課會告訴他:已經有人做出一個『會寫訓練設定的AI』,而且是用同一套強化學習,去訓練這個AI寫設定的能力。看完你會懂,這個雙層架構為什麼值得抄作業,以及它到底解決了什麼真實的工程痛點
🧭 這到底是什麼（白話版）
這篇文章的作者做了一件聽起來有點腦筋急轉彎的事:他訓練了一個AI,而這個AI的工作是——訓練其他的AI。他用的方法是 RL（強化學習）讓AI透過不斷嘗試、根據結果好壞拿到獎勵或懲罰,自己調整行為,而不是靠人工標好答案去模仿的一種訓練方式,讓一個代理型AI學會怎麼幫小模型寫訓練任務,而且這個代理的『駕照』不是整組重練——是用 LoRA只在一個已經訓練好的大模型上,外掛一小塊可以調整的參數,用很少的算力就能微調出新行為的技巧 微調出來的。
整個系統其實是兩層迴圈疊在一起。外層迴圈訓練的是『代理』本身(一個叫Qwen3.6-35B-A3B的模型),內層迴圈訓練的是代理寫出來、實際拿去用的『小模型』(Qwen3-0.6B或1.7B)。外層用的算法核心是 policy gradient（政策梯度）直接根據『這個決定帶來多少獎勵』去調整AI做出這個決定的機率高低,獎勵越高,AI以後越容易做出類似的決定,具體實作是 GRPO一種強化學習算法,把同一批不同的嘗試互相比較高下,表現比平均好的嘗試會被強化,比平均差的會被壓低,不需要另外訓練一個評分模型(Group Relative Policy Optimization的縮寫);內層則是代理寫出的實際訓練設定,用同一套GRPO邏輯,但跑在完全不同的訓練框架、不同的GPU資源池上。
一個『回合』是怎麼跑的?系統先給代理一份任務說明(例如『教一個小模型解決多跳人物查詢』),代理透過讀寫檔案的工具在一個獨立沙盒工作區裡動工,還可以先查一下這個小模型『完全沒訓練過』時的分數,當作等一下比較進步幅度的起點。寫完之後代理要提交任務,系統會先跑一次驗證探測,沒過的話代理有次數上限的機會修正重試;驗證過關的任務才會被排進GPU資源池,真的跑一次訓練,訓練完的小模型會在隱藏的評測集上打分。
最關鍵的是怎麼把『這個代理這次做得好不好』變成一個數字獎勵——這就是 reward shaping（獎勵塑形）把一個模糊、複雜的目標拆解、換算成一套明確的加權評分公式,讓強化學習的訓練訊號有清楚的方向感,而不是好與不好兩極化 的實際案例。文章公布的做法是把『驗證有沒有一次就過』跟『訓練出來的小模型贏過 基準線（baseline）還沒訓練過的原始模型,在同一份評測上的分數,拿來當作『進步了多少』的比較基準 多少』這兩件事加權相加,算出這一回合代理該拿到多少獎勵,再把這個獎勵送回外層迴圈去更新代理的政策。
🎯 為什麼值得你花時間
省下的不是算力,是「摸索期」自己微調過小模型的人都知道,最耗時的往往不是等GPU跑完,而是不斷試錯:獎勵函式怎麼給分、驗證規則怎麼寫才不會漏洞百出。這個實驗示範了這段『摸索期』本身也能被自動化、被學習,而不是每個新案子都要工程師肉身重新試錯一次。
強化學習可以拿來訓練「寫訓練任務的能力」,不只是訓模型本身大多數人對RL的印象停留在『訓練出一個會下棋、會回答問題的模型』。這篇文章示範了RL可以再往上疊一層——訓練一個AI學會怎麼幫別的AI寫出有效的訓練任務,這種『對訓練本身做強化學習』的思路,是這幾年AI自動化很重要的一個方向。
連失敗都公開,這在業界非常罕見作者把每一次前導實驗的失敗記錄都寫成retro公開出來,而不是只秀成功的最終版本。對正在自學RL工程的人來說,這些『當初哪裡出錯』的紀錄,往往比成功案例本身更有教學價值。
🔍 程式碼漫遊（點有 ● 的行看白話講解）
這段簡化過的Python對照著原文公布的獎勵公式,把驗證分數跟訓練成效分數,加權組合成代理最終拿到的獎勵。
●def episode_reward(attempt_number, validated, uplift_score):
💬 這個函式對應文章講的『回合獎勵』計算——代理每寫完一次訓練任務就算一回合
● if not validated:
💬 檢查這次提交最後有沒有通過驗證探測
● validation_score = 0.0
💬 文章說:從沒通過驗證,這部分直接算0分
● else:
💬 通過驗證的情況,分數不是固定的1分
● validation_score = max(0.0, 1.0 - 0.2 * (attempt_number - 1))
💬 第一次就過給滿分1.0,之後每多試一次扣一點,這就是reward shaping的實際做法——不是非0即1,而是給一個漸進的訊號,鼓勵代理一次寫對
● uplift = uplift_score
💬 這裡對應內層迴圈訓練完的小模型,贏過基準線的幅度
● reward = 0.35 * validation_score + 0.60 * uplift
💬 文章公布的實際權重是0.35 / 0.60 / 0.05——這裡示範前兩項,第三項原文段落被截斷沒交代細節,不硬編
● return reward
💬 這個總分就是外層迴圈拿去做policy gradient更新的訊號,回饋給訓練代理
🧠 工程思維透鏡（資深工程師看到的是什麼）
🔭 為什麼要用強化學習訓練『寫訓練任務的代理』,而不是直接叫一個聊天模型照著範本生成設定就好?
如果只是照範本生成,代理學到的是『長得像對的格式』,不是『訓練出來真的有效』。RL的關鍵差異是獎勵訊號直接來自下游結果——這個訓練任務讓小模型真的進步了多少,而不是格式對不對。代價是這個回饋迴圈非常昂貴:每次都要真的排一次GPU訓練才知道好不好,所以作者才要在驗證探測這一關先擋掉明顯無效的嘗試,省下真正燒錢的訓練次數。這是『訓練訊號的真實性』跟『訓練成本』之間的權衡,資深工程師看到這種設計,會先問:回饋是不是來自真實結果、而不是代理的自我描述。
🔭 驗證分數為什麼要設計成『第一次過滿分,之後遞減』,而不是單純的『通過1分、沒通過0分』?
二元評分很容易被鑽漏洞——代理只要瘋狂重試到矇對一次,一樣拿滿分,學不到『把設定一次寫對』這個更值錢的能力。用遞減設計等於是在做reward shaping:把一個粗糙的目標(有沒有通過),細分成一個帶方向感的曲線,同時鼓勵通過、又鼓勵少試幾次。這也呼應了作者控管成本的現實——每一次重試的驗證探測都要占用系統資源,遞減設計等於是把『效率』也編碼進獎勵裡,而不是事後另外訂規則去限制重試次數。
🔭 外層跟內層用兩套完全不同的訓練框架、跑在不同的資源池上,這個切割對工程上有什麼好處?
把『訓練代理的政策』跟『訓練實際的小模型』徹底拆成兩套獨立堆疊,代理端的LoRA更新出錯,不會弄壞正在跑的小模型訓練工作,反過來也一樣——這是用架構上的隔離,換取兩邊都能各自重試、各自除錯,不必互相等待或互相拖累。這跟一般團隊常見的做法很像:把『決定要做什麼』的角色跟『實際去執行』的角色分開,兩邊各自有自己的一套流程跟責任邊界。對正在自己一人接案、身兼多角的工程師來說,這個案例其實在提醒一件事:就算資源有限,把『決策層』跟『執行層』的關注點刻意分開,仍然是值得優先投資的架構決定,而不是等規模變大了才補做。
📝 隨堂考（點選答案，立即回饋）
Q1. 這篇文章裡,「外層迴圈」訓練的對象是誰?
✅ 外層迴圈訓練的是代理本身,用LoRA微調Qwen3.6-35B-A3B;小模型是內層迴圈訓練的對象。
Q2. 代理提交訓練任務時,如果驗證探測沒過會怎樣?
✅ 文章明確說驗證分數是『第一次過滿分,之後每多一次嘗試就decaying,從沒通過則是0分』,而且重試有次數上限,不是無限次。
Q3. 為什麼作者要讓外層跟內層,分別使用兩套完全不同的訓練框架跟GPU資源池?
✅ 外層是用政策梯度更新代理這個LoRA policy,內層是拿代理寫出的設定去真的訓練一個小模型,兩者訓練對象跟資源需求不同,所以用兩套獨立堆疊,互不影響。
Q4. 這個實驗測出來的回合獎勵,在54個訓練步驟內大約成長到多少的高峰?
✅ 文章寫明獎勵從約0.0成長到約0.63的高峰,而且能遷移到代理沒訓練過的任務類型上。