Perché Esistono le Soglie
Una Brutta Striscia di Ricompense Può Affamare una Fonte Prioritaria
Il bandit di ANDREA seleziona braccia di focus in base al rank UCB1. Il rank UCB dipende da mean_reward(k), che dipende dai miglioramenti di loss osservati. Una striscia di documenti ad alta loss da una fonte prioritaria (diciamo dictionary) può trascinare mean_reward(k) verso il basso. Ora dictionary ha un rank basso, riceve poche estrazioni di focus, & il suo mean_reward(k) non può recuperare (nessuna estrazione = nessuna osservazione fresca).
Lo stesso rischio si applica a qualsiasi fonte che il designer di training di ANDREA vuole nel mix indipendentemente dal segnale di ricompensa a breve termine.
I Floor come Pesi Minimi
La configurazione di addestramento di ANDREA specifica un floor per sorgente: un peso di campionamento minimo che la sorgente riceve indipendentemente da ciò che dice l'output UCB. I floor vanno da 0.0 a 1.0. Esempi:
hermes3-general floor = 0.8 (sorgente prioritaria conversazionale)
chat floor = 0.8
dictionary floor = 0.7 (impalcatura per richiamo fattuale)
gutenberg floor = 0.7 (coerenza prosaica)
chat sintetico floor = 0.0 (nessun floor; il bandit decide liberamente)
Come si Applicano i Floor
Dopo che UCB1 classifica le braccia e dice control assembla insiemi di focus, ogni sorgente riceve un peso provvisorio. Poi parte l'applicazione del floor:
final_weight_k = max(tentative_weight_k, floor_k)
Se il bandit ha assegnato un peso di 0.3 a hermes3-general ma il suo floor è 0.8, vince il floor: peso finale = 0.8. La voce del bandit viene sovrascritta solo verso l'alto; non viene mai sovrascritta verso il basso.
Configurazioni Diverse, Floor Diversi
ANDREA fornisce diverse configurazioni di addestramento: chatbot, tool-caller, bash-commander. Ogni configurazione imposta floor diversi per le sue fonti di priorità. La configurazione chatbot posiziona i floor di hermes3-general & chat alti. Tool-caller posiziona repo-docstrings più in alto. Bash-commander posiziona repo-commits più in alto. Stesso algoritmo, priorità diverse.
Applica un Floor
Il Rischio di Memorizzazione
Le Fonti Piccole Vengono Memorizzate
Le fonti di dati di ANDREA variano enormemente in dimensione. synthetic-chat ha circa 1.400 documenti. gutenberg ne ha oltre 500.000. Se il bandit tira in modo uniforme, synthetic-chat esaurisce rapidamente il suo pool di documenti: dopo 1.400 tirate, ogni documento è stato visto almeno una volta. Tira 2.800 volte & ogni documento è stato visto almeno due volte in media.
L'esposizione ripetuta a un piccolo set di documenti porta a memorizzazione: il modello smette di imparare pattern generalizzabili & inizia a recitare sequenze di token specifici dai dati di training. La memorizzazione è negativa per due ragioni: (1) spreca capacità sul richiamo mnemonico invece della generalizzazione, & (2) può far trapelare i dati di training attraverso la generazione.
Gli Epoch come Proxy di Memorizzazione
Definisci un epoch su una sorgente k come un passaggio completo attraverso tutti i documenti di k:
epochs_k = floor(lifetime_pulls_k / n_docs_k)
Se synthetic-chat (n_docs=1400) è stato estratto 2.800 volte, epochs = floor(2800/1400) = 2: la sorgente è stata vista due volte completamente. Se gutenberg (n_docs=500.000) è stato estratto 100.000 volte, epochs = floor(100000/500000) = 0: non ancora un passaggio completo.
La Penalità 1/(1+epochs)
Quando lifetime_pulls / n_docs > 1.0, ANDREA applica una penalità moltiplicativa:
penalty = 1 / (1 + epochs)
final_weight = bandit_weight * penalty
Curva:
| epoche | penalità | riduzione peso |
|---|---|---|
| 0 | 1.000 | nessuna |
| 1 | 0.500 | metà |
| 2 | 0.333 | un terzo |
| 3 | 0.250 | un quarto |
| 5 | 0.167 | un sesto |
| 10 | 0.091 | un undicesimo |
La penalità cresce con ogni passaggio completato. Dopo molte epoche, il peso della sorgente si avvicina a zero & il bandit la riposa naturalmente.
Perché le Trazioni a Vita Persistono tra i Riavvii
Le esecuzioni di addestramento di ANDREA durano giorni. Si verificano crash. I server si riavviano. Le configurazioni vengono modificate & l'addestramento riprende da un checkpoint. Le trazioni a vita persistono attraverso tutti questi eventi: il proxy scrive i conteggi delle trazioni su disco continuamente.
Se le trazioni si resettassero a ogni riavvio, una sorgente piccola potrebbe resettarsi efficacemente all'epoca 0 ogni volta che l'addestramento riparte. La penalità non si accumulerebbe mai, & la memorizzazione procederebbe comunque. Persistendo le trazioni a vita, la penalità diventa un vincolo reale, in crescita monotona.
Calcola una Penalità di Epoch
Chiusura dello Stack del Curriculum Bandit
Cosa Hai
I floor garantiscono un campionamento minimo per le sorgenti prioritarie: final_weight = max(bandit_weight, floor_k). Le penalità di epoch limitano la memorizzazione sulle sorgenti piccole: quando lifetime_pulls/n_docs > 1, il peso viene moltiplicato per 1/(1+epochs). Le estrazioni lifetime persistono attraverso i riavvii, quindi la penalità diventa un vincolo monotono, non un contatore resettabile.
Il Pipeline Completo
Mettendo insieme tutte e quattro le attività bandit ANDREA (76-79):
1. Attività 76 (UCB1). Ogni passo calcola UCB(k) = mean_reward(k) + 0.5 * sqrt(ln(N)/n_k). Argmax seleziona un braccio.
2. Attività 77 (fasi dei dadi). Confini di fase (ogni 7 a 42 passi) lanciano dadi per il conteggio dei bracci focali. Bracci casuali prima, UCB riempie il resto. 25-33% delle fasi girano completamente casuali.
3. Attività 78 (attribuzione delle ricompense). CUDA riporta la loss; EMA per fonte traccia la storia; reward = max(0, EMA - loss) * 1000. Ricompensa scalata alimenta mean_reward(k).
4. Attività 79 (piani & epoche, questa lezione). Dopo l'output UCB, i piani sollevano le fonti prioritarie; penalità epoche riducono il peso delle fonti memorizzate. Tiri lifetime persistono.
Insieme: un bandit che si adatta (UCB1), esplora in modo affidabile (fasi dei dadi), ottiene segnali di ricompensa onesti (scaling 1000x), rispetta le priorità del design di training (floor), & evita la memorizzazione (penalità epoca).
Riferimento
ANDREA whitepaper, sezioni 3.5 & 3.6.