Dlaczego Istnieją Dolne Granice
Zła Seria Nagrody Może Zagłodzić Priorytetowe Źródło
Bandyt ANDREA wybiera ramiona fokusów według rankingu UCB1. Ranking UCB zależy od mean_reward(k), który zależy od obserwowanych ulepszeń straty. Seria dokumentów o wysokiej stracie z priorytetowego źródła (powiedzmy dictionary) może pociągnąć mean_reward(k) w dół. Teraz dictionary ma niski ranking, dostaje mało ciągnięć fokusów, & jego mean_reward(k) nie może się odzyskać (brak ciągnięć = brak świeżych obserwacji).
To samo ryzyko dotyczy każdego źródła, które projektant treningu ANDREA chce w miksie niezależnie od krótkoterminowego sygnału nagrody.
Podłogi jako minimalne wagi
Konfiguracja treningowa ANDREA określa podłogę na źródło: minimalną wagę próbkowania, którą źródło otrzymuje niezależnie od tego, co mówi wyjście UCB. Podłogi wahają się od 0.0 do 1.0. Przykłady:
hermes3-general podłoga = 0.8 (priorytetowe źródło konwersacyjne)
chat podłoga = 0.8
dictionary podłoga = 0.7 (rusztowanie do faktycznego przypominania)
gutenberg podłoga = 0.7 (spójność prozy)
synthetic-chat floor = 0.0 (brak dolnej granicy; bandyta decyduje swobodnie)
Jak stosowane są dolne granice
Po tym, jak UCB1 uszereguje ramiona, a dice control złoży zestawy fokusowe, każde źródło otrzymuje wstępną wagę. Następnie uruchamiane jest egzekwowanie dolnej granicy:
final_weight_k = max(tentative_weight_k, floor_k)
Jeśli bandyta przypisał wagę 0.3 do hermes3-general, ale jego dolna granica wynosi 0.8, wygrywa dolna granica: ostateczna waga = 0.8. Głos bandyty jest nadpisywany tylko w górę; nigdy w dół.
[BLOCK_TYPE SECTION/STEP]
__BLOCK_N__
<translated content>
Różne Konfiguracje, Różne Piętra
ANDREA dostarcza kilka konfiguracji treningowych: chatbot, tool-caller, bash-commander. Każda konfiguracja ustawia różne piętra dla swoich priorytetowych źródeł. Konfiguracja chatbot ustawia wysokie piętra dla hermes3-general & chat. Tool-caller ustawia wyższe piętro dla repo-docstrings. Bash-commander ustawia wyższe piętro dla repo-commits. Ten sam algorytm, różne priorytety.
Zastosuj Piętro
Ryzyko zapamiętywania
Małe źródła są zapamiętywane
Źródła danych ANDREA różnią się wielkością w ogromnym stopniu. synthetic-chat ma około 1,400 dokumentów. gutenberg ma 500,000+. Jeśli bandyta ciągnie równomiernie, synthetic-chat szybko wyczerpuje pulę dokumentów: po 1,400 pociągnięciach każdy dokument został widziany co najmniej raz. Pociągnij 2,800 razy & każdy dokument został widziany co najmniej dwa razy średnio.
Powtarzająca się ekspozycja na mały zestaw dokumentów prowadzi do zapamiętywania: model przestaje uczyć się uogólnialnych wzorców & zaczyna recytować konkretne sekwencje tokenów z danych treningowych. Zapamiętywanie jest złe z dwóch powodów: (1) marnuje pojemność na mechaniczne odtwarzanie zamiast uogólniania, & (2) może wyciekać dane treningowe poprzez generację.
Epoki jako przybliżenie memorizacji
Zdefiniuj epokę nad źródłem k jako jedno pełne przejście przez wszystkie dokumenty k:
epochs_k = floor(lifetime_pulls_k / n_docs_k)
Jeśli synthetic-chat (n_docs=1400) zostało pobrane 2800 razy, epochs = floor(2800/1400) = 2: źródło zostało widziane dwa razy w całości. Jeśli gutenberg (n_docs=500000) zostało pobrane 100000 razy, epochs = floor(100000/500000) = 0: jeszcze nie pełne przejście.
Kara 1/(1+epochs)
Gdy lifetime_pulls / n_docs > 1.0, ANDREA stosuje multiplikatywną karę:
penalty = 1 / (1 + epochs)
final_weight = bandit_weight * penalty
Krzywa:
| epoki | kara | redukcja wagi |
|---|---|---|
| 0 | 1.000 | brak |
| 1 | 0.500 | połowa |
| 2 | 0.333 | jedna trzecia |
| 3 | 0.250 | jedna czwarta |
| 5 | 0.167 | jedna szósta |
| 10 | 0.091 | jedna jedenasta |
Kara rośnie z każdym ukończonym przejściem. Po wielu epokach waga źródła zbliża się do zera & bandyta naturalnie ją odpoczywa.
Dlaczego Lifetime Pulls są zachowywane podczas restartów
Trening ANDREA trwa dniami. Dochodzi do awarii. Serwery restartują. Konfiguracje są modyfikowane & trening wznawiany z punktu kontrolnego. Lifetime pulls są zachowywane podczas wszystkich tych zdarzeń: proxy zapisuje liczniki pociągnięć na dysk w sposób ciągły.
Jeśli pulls resetowałyby się przy każdym restarcie, małe źródło mogłoby efektywnie resetować się do epoki 0 za każdym razem, gdy trening restartuje. Kara nigdy by się nie akumulowała, & memoryzacja postępowałaby niezależnie. Zachowywanie lifetime pulls czyni karę rzeczywistym, monotonicznie rosnącym ograniczeniem.
Oblicz Karę Epoki
Zakończenie Stosu Curriculums Bandytów
Co Masz
Floors gwarantują minimalne próbkowanie dla źródeł priorytetowych: final_weight = max(bandit_weight, floor_k). Kary epok ograniczają zapamiętywanie w małych źródłach: gdy lifetime_pulls/n_docs > 1, waga jest mnożona przez 1/(1+epochs). Lifetime pulls utrzymują się przez restarty, więc kara staje się monotonicznym ograniczeniem, a nie resetowalnym licznikiem.
Pełny Potok
Połączenie wszystkich czterech aktywności bandyty ANDREA (76-79):
1. Aktywność 76 (UCB1). Każdy krok oblicza UCB(k) = mean_reward(k) + 0.5 * sqrt(ln(N)/n_k). Argmax wybiera ramię.
2. Aktywność 77 (fazy kości). Granice faz (co 7 do 42 kroków) rzucają kośćmi na liczbę ramion w fokusie. Najpierw losowe ramiona, UCB wypełnia resztę. 25-33% faz działa w pełni losowo.
3. Aktywność 78 (przypisanie nagród). CUDA raportuje stratę; EMA na źródło śledzi historię; nagroda = max(0, EMA - strata) * 1000. Skalowana nagroda zasila mean_reward(k).
4. Aktywność 79 (podłogi & epoki, ta lekcja). Po wyjściu UCB, podłogi podnoszą priorytetowe źródła; kary epok obniżają wagę źródeł zapamiętanych. Dożywotnie ciągnięcia persistują.
Razem: bandyta, który się dostosowuje (UCB1), eksploruje niezawodnie (fazy kości), otrzymuje uczciwe sygnały nagród (skalowanie 1000x), szanuje priorytety projektowania treningu (podłogi) i unika zapamiętywania (kara epoki).
Referencja
Whitepaper ANDREA, sekcje 3.5 i 3.6.