Warum Minima existieren
Eine schlechte Belohnungs-Serie kann eine Prioritätsquelle verhungern lassen
ANDREA's Bandit wählt Fokus-Hebel nach UCB1-Rang aus. UCB-Rang hängt von mean_reward(k) ab, was von beobachteten Verlust-Verbesserungen abhängt. Eine Serie hochsverlustiger Dokumente aus einer Prioritätsquelle (sagen wir dictionary) kann mean_reward(k) herunterziehen. Nun rangiert dictionary niedrig, erhält wenige Fokus-Züge, & sein mean_reward(k) kann sich nicht erholen (keine Züge = keine frischen Beobachtungen).
Gleiches Risiko gilt für jede Quelle, die ANDREA's Trainings-Designer unabhängig vom kurzfristigen Belohnungssignal im Mix haben will.
Böden als Mindestgewichte
Die Trainingskonfiguration von ANDREA legt pro Quelle einen Boden fest: ein Mindestabtastgewicht, das die Quelle erhält, unabhängig davon, was die UCB-Ausgabe sagt. Böden reichen von 0.0 bis 1.0. Beispiele:
hermes3-general floor = 0.8 (priorisiertes konversationelles Source)
chat floor = 0.8
dictionary floor = 0.7 (Gerüst für faktenbasiertes Abrufen)
gutenberg floor = 0.7 (Prosa-Kohärenz)
synthetischer-Chat floor = 0.0 (kein Floor; Bandit entscheidet frei)
Wie Floors angewendet werden
Nachdem UCB1 die Arms rangiert hat & Dice Control Fokus-Sets zusammenstellt, erhält jede Quelle ein vorläufiges Gewicht. Dann läuft die Floor-Enforcement:
final_weight_k = max(tentative_weight_k, floor_k)
Falls der Bandit dem hermes3-general ein Gewicht von 0.3 zuweist, aber dessen Floor 0.8 beträgt, gewinnt der Floor: finales Gewicht = 0.8. Die Stimme des Banditen wird nur nach oben überschrieben; sie wird nie nach unten überschrieben.
Unterschiedliche Konfigurationen, unterschiedliche Floors
ANDREA liefert mehrere Trainingskonfigurationen: chatbot, tool-caller, bash-commander. Jede Konfiguration setzt unterschiedliche Floors für ihre Prioritätsquellen. Chatbot setzt hermes3-general & chat hoch. Tool-caller setzt repo-docstrings höher. Bash-commander setzt repo-commits höher. Gleicher Algorithmus, unterschiedliche Prioritäten.
Einen Floor anwenden
Das Memorisierungsrisiko
Kleine Quellen werden memorisiert
Die Datenquellen von ANDREA variieren stark in der Größe. synthetic-chat hat ungefähr 1.400 Dokumente. gutenberg hat 500.000+. Wenn der Bandit gleichmäßig zieht, erschöpft sich synthetic-chat schnell: Nach 1.400 Zügen wurde jedes Dokument mindestens einmal gesehen. Ziehe 2.800 Mal & jedes Dokument wurde im Durchschnitt mindestens zweimal gesehen.
Wiederholte Exposition gegenüber einem kleinen Set von Dokumenten führt zu Memorization: das Modell hört auf, generalisierbare Muster zu lernen & fängt an, spezifische Token-Sequenzen aus den Trainingsdaten zu rezitieren. Memorization ist aus zwei Gründen schlecht: (1) es verschwendet Kapazität an Auswendiglernen statt Generalisierung, & (2) es kann Trainingsdaten durch Generation leaken.
Epochen als Proxy für die Memorierung
Definiere eine Epoch über die Quelle k als einen vollständigen Durchgang durch alle Dokumente von k:
epochs_k = floor(lifetime_pulls_k / n_docs_k)
Falls synthetic-chat (n_docs=1400) 2.800 Mal gezogen wurde, epochs = floor(2800/1400) = 2: die Quelle wurde zweimal vollständig durchgesehen. Falls gutenberg (n_docs=500.000) 100.000 Mal gezogen wurde, epochs = floor(100000/500000) = 0: noch kein vollständiger Durchgang.
Die 1/(1+epochs)-Strafe
Wenn lifetime_pulls / n_docs > 1.0, wendet ANDREA eine multiplikative Strafe an:
penalty = 1 / (1 + epochs)
final_weight = bandit_weight * penalty
Kurve:
| Epochen | Strafe | Gewichtsreduktion |
|---|---|---|
| 0 | 1.000 | keine |
| 1 | 0.500 | halb |
| 2 | 0.333 | ein Drittel |
| 3 | 0.250 | ein Viertel |
| 5 | 0.167 | ein Sechstel |
| 10 | 0.091 | ein elftel |
Die Strafe wächst mit jedem abgeschlossenen Durchgang. Nach vielen Epochen nähert sich das Gewicht der Quelle null an & der Bandit legt sie natürlich ruhend.
Warum Lifetime Pulls über Neustarts hinweg bestehen bleiben
ANDREA's Trainingläufe umfassen Tage. Abstürze passieren. Server werden neu gestartet. Konfigurationen werden angepasst & das Training wird von einem Checkpoint fortgesetzt. Lifetime pulls bestehen über all diese Ereignisse hinweg: Der Proxy schreibt Pull-Zähler kontinuierlich auf die Festplatte.
Falls pulls bei jedem Neustart zurückgesetzt würden, könnte eine kleine Quelle effektiv bei jeder Training-Neustartung auf Epoche 0 zurückgesetzt werden. Die Strafe würde sich nie ansammeln, & die Memorization würde unabhängig davon fortfahren. Das Beibehalten von lifetime pulls macht die Strafe zu einer realen, monoton wachsenden Einschränkung.
Epoch-Strafe berechnen
Abschluss des Bandit-Curriculum-Stacks
Was Sie haben
Floors garantieren minimale Abtastung für Prioritätsquellen: final_weight = max(bandit_weight, floor_k). Epoch-Strafen begrenzen Memorization bei kleinen Quellen: Wenn lifetime_pulls/n_docs > 1, wird das Gewicht mit 1/(1+epochs) multipliziert. Lifetime-Pulls persistieren über Restarts hinweg, sodass die Strafe zu einer monotonen Einschränkung wird, nicht zu einem zurücksetzbaren Zähler.
Der vollständige Pipeline
Alle vier ANDREA-Bandit-Aktivitäten (76-79) zusammenfügen:
1. Aktivität 76 (UCB1). Jeder Schritt berechnet UCB(k) = mean_reward(k) + 0.5 * sqrt(ln(N)/n_k). Argmax wählt einen Arm aus.
2. Aktivität 77 (Würfelphasen). Phasengrenzen (alle 7 bis 42 Schritte) würfeln für die Anzahl der Fokus-Arme. Zuerst zufällige Arme, UCB füllt den Rest. 25-33 % der Phasen laufen vollständig zufällig.
3. Aktivität 78 (Belohnungs-Zuschreibung). CUDA meldet Verlust; EMA pro Quelle verfolgt die Historie; Belohnung = max(0, EMA - Verlust) * 1000. Skalierte Belohnung speist mean_reward(k).
4. Aktivität 79 (Böden & Epochen, diese Lektion). Nach UCB-Ausgabe heben Böden priorisierte Quellen; Epochen-Strafen gewichten memorisierte Quellen ab. Lebenslange Züge persistieren.
Zusammen: ein Bandit, der sich anpasst (UCB1), zuverlässig erkundet (Würfelphasen), ehrliche Belohnungssignale erhält (1000x-Skalierung), Trainingsdesign-Prioritäten respektiert (Böden) & Memorization vermeidet (Epoch-Strafe).
Referenz
ANDREA-Whitepaper, Abschnitte 3.5 & 3.6.