Waarom Vloeren Bestaan
Een Slechte Beloningsreeks Kan een Prioriteitsbron Uithongeren
ANDREA's bandit kiest focusarmen op basis van UCB1-rang. UCB-rang hangt af van mean_reward(k), wat afhangt van waargenomen verliesverbeteringen. Een reeks documenten met hoog verlies van een prioriteitsbron (zeg dictionary) kan mean_reward(k) omlaag trekken. Nu rangschikt dictionary laag, krijgt het weinig focus-trekkingen, & zijn mean_reward(k) kan niet herstellen (geen trekkingen = geen verse observaties).
Zelfde risico geldt voor elke bron die ANDREA's trainingsontwerper in de mix wil ongeacht kortetermijn-beloningsignaal.
Vloeren als Minimumgewichten
De trainingsconfiguratie van ANDREA specificeert een vloer per bron: een minimum samplinggewicht dat de bron ontvangt ongeacht wat de UCB-output zegt. Vloeren lopen van 0.0 tot 1.0. Voorbeelden:
hermes3-general vloer = 0.8 (prioriteit conversationele bron)
chat vloer = 0.8
dictionary vloer = 0.7 (feitelijke recall-steiger)
gutenberg vloer = 0.7 (proza-coherentie)
synthetic-chat vloer = 0.0 (geen vloer; bandit beslist vrij)
Hoe Vloeren Worden Toegepast
Nadat UCB1 armen rangschikt & dice control focussets samenstelt, krijgt elke bron een voorlopig gewicht. Dan voert vloerhandhaving uit:
final_weight_k = max(tentative_weight_k, floor_k)
Als de bandit gewicht 0.3 toekent aan hermes3-general maar de vloer is 0.8, wint de vloer: eindgewicht = 0.8. De stem van de bandit wordt alleen omhoog overschreven; hij wordt nooit omlaag overschreven.
Verschillende Configs, Verschillende Floors
ANDREA levert verschillende trainingsconfiguraties: chatbot, tool-caller, bash-commander. Elke config stelt verschillende floors in voor zijn prioriteitsbronnen. Chatbot floors hermes3-general & chat hoog. Tool-caller floors repo-docstrings hoger. Bash-commander floors repo-commits hoger. Zelfde algoritme, verschillende prioriteiten.
Pas een Floor Toe
Het Memorisatie Risico
Kleine Bronnen Worden Gememoriseerd
De databronnen van ANDREA variëren wild in grootte. synthetic-chat heeft ongeveer 1.400 documenten. gutenberg heeft 500.000+. Als de bandit gelijkmatig trekt, raakt synthetic-chat zijn documentpool snel uitgeput: na 1.400 pulls is elk document minstens één keer gezien. Trek 2.800 keer & elk document is minstens twee keer gezien in gemiddeld.
Herhaalde blootstelling aan een klein aantal documenten leidt tot memorization: het model stopt met het leren van generaliseerbare patronen & begint specifieke tokenreeksen uit de trainingsdata op te dreunen. Memorization is slecht om twee redenen: (1) het verspilt capaciteit aan het uit het hoofd leren in plaats van generalisatie, & (2) het kan trainingsdata lekken door generatie.
Epochs Als een Proxy voor Memorization
Definieer een epoch over bron k als één volledige doorgang door alle documenten van k:
epochs_k = floor(lifetime_pulls_k / n_docs_k)
Als synthetic-chat (n_docs=1400) 2.800 keer is getrokken, epochs = floor(2800/1400) = 2: de bron is twee keer volledig gezien. Als gutenberg (n_docs=500.000) 100.000 keer is getrokken, epochs = floor(100000/500000) = 0: nog geen volledige doorgang.
De 1/(1+epochs) Penalty
Wanneer lifetime_pulls / n_docs > 1.0, past ANDREA een multiplicatieve penalty toe:
penalty = 1 / (1 + epochs)
final_weight = bandit_weight * penalty
Curve:
| epochs | straf | gewichtsreductie |
|---|---|---|
| 0 | 1.000 | geen |
| 1 | 0.500 | helft |
| 2 | 0.333 | een derde |
| 3 | 0.250 | een kwart |
| 5 | 0.167 | een zesde |
| 10 | 0.091 | een elfde |
De straf groeit met elke voltooide doorgang. Na vele epochs nadert het gewicht van de bron nul & de bandit rust het natuurlijk uit.
Waarom Lifetime Pulls Blijven Bestaan Bij Herstarts
De trainingruns van ANDREA duren dagen. Crashes gebeuren. Servers herstarten. Configuraties worden aangepast & training hervat vanaf een checkpoint. Lifetime pulls blijven bestaan over al deze gebeurtenissen heen: de proxy schrijft pull-tellingen continu naar schijf.
Als pulls bij elke herstart worden gereset, zou een kleine bron effectief elke keer naar epoch 0 kunnen terugkeren bij een herstart van de training. De straf zou nooit accumuleren, & memorisatie zou ongehinderd doorgaan. Het behouden van lifetime pulls maakt de straf een echte, monotone-groeiende beperking.
Bereken een Epoch Penalty
Afsluiting van de Bandit Curriculum Stack
Wat Je Hebt
Floors garanderen minimale sampling voor prioriteitsbronnen: final_weight = max(bandit_weight, floor_k). Epoch penalties beperken memorisatie op kleine bronnen: wanneer lifetime_pulls/n_docs > 1, wordt het gewicht vermenigvuldigd met 1/(1+epochs). Lifetime pulls blijven bestaan over herstarts heen, zodat de penalty een monotone beperking wordt, geen resetbare teller.
De Volledige Pipeline
Alle vier de ANDREA bandit-activiteiten (76-79) samenvoegen:
1. Activiteit 76 (UCB1). Elke stap berekent UCB(k) = mean_reward(k) + 0.5 * sqrt(ln(N)/n_k). Argmax kiest een arm.
2. Activiteit 77 (dobbelsteenfasen). Fasegrenzen (elke 7 tot 42 stappen) rollen dobbelstenen voor het aantal focusarmen. Willekeurige armen eerst, UCB vult de rest. 25-33% van de fasen verloopt volledig willekeurig.
3. Activiteit 78 (beloningsattributie). CUDA rapporteert verlies; per-bron EMA volgt geschiedenis; beloning = max(0, EMA - verlies) * 1000. Geschaalde beloning voedt mean_reward(k).
4. Activiteit 79 (vloeren & epochs, deze les). Na UCB-uitvoer tillen vloeren prioriteitsbronnen op; epoch-straffen verlagen het gewicht van gememoriseerde bronnen. Levenslange pulls blijven behouden.
Samen: een bandit die zich aanpast (UCB1), betrouwbaar verkent (dobbelsteenfasen), eerlijke beloningsignalen krijgt (1000x schaling), trainingsontwerp-prioriteiten respecteert (vloeren), & memorisatie vermijdt (epoch-straf).
Referentie
ANDREA whitepaper, secties 3.5 & 3.6.