English· Español· Deutsch· Nederlands· Français· 日本語· ქართული· 繁體中文· 简体中文· Português· Русский· العربية· हिन्दी· Italiano· 한국어· Polski· Svenska· Türkçe· Українська· Tiếng Việt· Bahasa Indonesia

un

guest
1 / ?
back to lessons

為什麼需要底限

糟糕的獎勵連勝可能使優先來源饑餓

ANDREA 的 bandit 根據 UCB1 排序選擇焦點手臂。UCB 排序取決於 mean_reward(k),而 mean_reward(k) 取決於觀察到的損失改善。來自優先來源(例如 dictionary)的一連串高損失文件可能會拉低 mean_reward(k)。現在 dictionary 排序低下,獲得少量焦點拉取,& 其 mean_reward(k) 無法恢復(無拉取 = 無新觀察)。


相同的風險適用於 ANDREA 的訓練設計師無論短期獎勵訊號如何都希望包含在混合中的任何來源。


樓層作為最小權重

ANDREA 的訓練配置為每個來源指定一個 floor:無論 UCB 輸出說什麼,來源獲得的最小採樣權重。樓層範圍從 0.0 到 1.0。範例:


hermes3-general floor = 0.8 (優先對話來源)

chat floor = 0.8

dictionary floor = 0.7 (事實回憶支架)

gutenberg floor = 0.7 (散文連貫性)

synthetic-chat floor = 0.0 (無下限;bandit 自由決定)


下限如何應用

在 UCB1 對 arms 進行排序且 dice control 組裝焦點集合後,每個 source 會得到一個暫定權重。然後執行下限強制:


final_weight_k = max(tentative_weight_k, floor_k)


如果 bandit 對 hermes3-general 分配了 0.3 的權重,但其下限為 0.8,則下限勝出:最終權重 = 0.8。bandit 的聲音僅會被向上覆蓋;永遠不會被向下覆蓋。


Floors & Epoch Penalty Layout


不同的配置,不同的 Floor

ANDREA 提供了多種訓練配置:chatbot、tool-caller、bash-commander。每種配置為其優先來源設定不同的 floor。Chatbot 將 hermes3-general & chat 的 floor 設高。Tool-caller 將 repo-docstrings 的 floor 設得更高。Bash-commander 將 repo-commits 的 floor 設得更高。相同的演算法,不同的優先順序。

套用 Floor

在 UCB1 + dice control 之後,bandit 分配了這些暫定權重:hermes3-general 0.30, dictionary 0.55, gutenberg 0.85, synthetic-chat 0.40。Floor 是:hermes3-general 0.80, dictionary 0.70, gutenberg 0.70, synthetic-chat 0.00。計算每個來源在套用 floor 後的最終權重。然後用一句話解釋哪個來源的權重被提升最多。

記憶化風險

微小來源會被記憶化

ANDREA 的資料來源大小差異極大。synthetic-chat 大約有 1,400 個文件。gutenberg 有 500,000+ 個。如果 bandit 平均拉取,synthetic-chat 很快就會耗盡其文件池:1,400 次拉取後,每個文件至少被看過一次。拉取 2,800 次後,每個文件平均至少被看過兩次。


反覆接觸一小組文件會導致 memorization:模型停止學習可泛化模式,並開始背誦訓練資料中的特定 token 序列。記憶化有兩個壞處:(1) 浪費容量在死記硬背而非泛化,及 (2) 可能透過生成洩漏訓練資料。


將 Epochs 視為記憶代理

定義來源 k 的一個 epoch 為完整遍歷 k 的所有文件一次:


epochs_k = floor(lifetime_pulls_k / n_docs_k)


如果 synthetic-chat (n_docs=1400) 已被拉取 2,800 次,epochs = floor(2800/1400) = 2:該來源已被完整看過兩次。如果 gutenberg (n_docs=500,000) 已被拉取 100,000 次,epochs = floor(100000/500000) = 0:尚未完成一次完整遍歷。


1/(1+epochs) 懲罰

lifetime_pulls / n_docs > 1.0 時,ANDREA 會套用乘法懲罰:


penalty = 1 / (1 + epochs)


final_weight = bandit_weight * penalty


曲線:


訓練輪次懲罰值權重減少
01.000
10.500一半
20.333三分之一
30.250四分之一
50.167六分之一
100.091一十一分之一

懲罰隨著每個完成的遍次而增長。在許多 epoch 之後,來源的權重趨近於零,且 bandit 自然地會讓它休息。


為什麼終身拉取次數會在重啟時持續存在

ANDREA 的訓練運行橫跨數天。崩潰會發生。伺服器重啟。配置會被調整,且訓練從檢查點恢復。終身拉取次數會持續存在於所有這些事件中:代理會持續將拉取計數寫入磁碟。


如果每次重啟時拉取次數重置,一個小來源就能有效地每次訓練重啟時重置為 epoch 0。懲罰永遠不會累積,且記憶化會無視地進行。持續終身拉取次數使懲罰成為一個真實的、單調增長的約束。

計算一個 Epoch 懲罰

來源 `synthetic-chat` 有 n_docs = 1,400。在 4,200 次終身拉取後,計算 (a) epoch 數量,(b) 懲罰 1/(1+epochs),(c) 如果 bandit weight 是 1.0 的最終權重。然後對於 `gutenberg` 有 n_docs = 500,000 & 100,000 次終身拉取,計算 (d) lifetime_pulls/n_docs,& (e) 懲罰是否適用(是或否,並說明理由)。

結束 Bandit Curriculum Stack

你已經學會的

Floors 保證優先來源的最小抽樣:final_weight = max(bandit_weight, floor_k)。Epoch 懲罰限制小來源的記憶化:當 lifetime_pulls/n_docs > 1 時,權重乘以 1/(1+epochs)。終身拉取在重啟間持續,因此懲罰成為單調約束,而不是可重置的計數器。


完整的管線

將所有四個 ANDREA 匪徒活動(76-79)整合在一起:


1. 活動 76 (UCB1)。 每一步計算 UCB(k) = mean_reward(k) + 0.5 * sqrt(ln(N)/n_k)。Argmax 選擇一個臂。

2. 活動 77 (骰子階段)。 階段邊界(每 7 到 42 步)擲骰子決定焦點臂數量。先隨機臂,UCB 填充其餘。25-33% 的階段完全隨機運行。

3. 活動 78 (獎勵歸因)。 CUDA 報告損失;每個來源的 EMA 追蹤歷史;獎勵 = max(0, EMA - loss) * 1000。縮放後的獎勵輸入 mean_reward(k)。

4. 活動 79 (底線 & 時期,本課)。 UCB 輸出後,底線提升優先來源;時期懲罰降低記憶來源的權重。終身拉動次數持續存在。


總結:一個能夠適應的 bandit(UCB1)、可靠探索(dice phases)、獲得誠實獎勵信號(1000x scaling)、尊重訓練設計優先級(floors),並避免記憶化(epoch penalty)的 bandit。


參考資料

ANDREA whitepaper,第 3.5 與 3.6 節。