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

un

invité
1 / ?
retour aux leçons

Pourquoi les Seuils Existent

Une Mauvaise Série de Récompenses Peut Affamer une Source Prioritaire

Le bandit d'ANDREA sélectionne les bras de focus par rang UCB1. Le rang UCB dépend de mean_reward(k), qui dépend des améliorations de perte observées. Une série de documents à haute perte d'une source prioritaire (disons dictionary) peut faire baisser mean_reward(k). Maintenant dictionary a un rang bas, reçoit peu de tirages de focus, & son mean_reward(k) ne peut pas se rétablir (pas de tirages = pas d'observations fraîches).


Le même risque s'applique à toute source que le concepteur d'entraînement d'ANDREA veut inclure dans le mélange, indépendamment du signal de récompense à court terme.


Les planchers comme poids minimaux

La configuration d'entraînement d'ANDREA spécifie un plancher par source : un poids d'échantillonnage minimum que la source reçoit quoi que dise la sortie UCB. Les planchers vont de 0.0 à 1.0. Exemples :


hermes3-general plancher = 0.8 (source prioritaire conversationnelle)

chat plancher = 0.8

dictionary plancher = 0.7 (échafaudage pour rappel factuel)

gutenberg plancher = 0.7 (cohérence en prose)

chat synthétique floor = 0.0 (pas de floor ; le bandit décide librement)


Comment les Floors s'appliquent

Après que UCB1 a classé les bras & que dice control a assemblé les focus sets, chaque source reçoit un poids provisoire. Puis l'application des floors s'exécute :


final_weight_k = max(tentative_weight_k, floor_k)


Si le bandit a assigné un poids de 0.3 à hermes3-general mais que son floor est de 0.8, le floor l'emporte : poids final = 0.8. La voix du bandit est seulement surclassée vers le haut ; elle n'est jamais surclassée vers le bas.


Floors & Epoch Penalty Layout


Différentes Configs, Différents Planchers

ANDREA propose plusieurs configurations d'entraînement : chatbot, tool-caller, bash-commander. Chaque config définit des planchers différents pour ses sources prioritaires. La config chatbot place hermes3-general & chat en haut. Tool-caller place repo-docstrings plus haut. Bash-commander place repo-commits plus haut. Même algorithme, priorités différentes.

Appliquer un Plancher

Après UCB1 + contrôle de dé, le bandit assigne ces poids provisoires : hermes3-general 0.30, dictionary 0.55, gutenberg 0.85, synthetic-chat 0.40. Les planchers sont : hermes3-general 0.80, dictionary 0.70, gutenberg 0.70, synthetic-chat 0.00. Calculez le poids final pour chaque source après application des planchers. Puis expliquez en une phrase quelle source a vu son poids relevé le plus.

Le Risque de Mémorisation

Les Petites Sources Sont Mémorisées

Les sources de données d'ANDREA varient énormément en taille. synthetic-chat compte environ 1 400 documents. gutenberg en a plus de 500 000. Si le bandit tire uniformément, synthetic-chat épuise rapidement son pool de documents : après 1 400 tirages, chaque document a été vu au moins une fois. Tirez 2 800 fois & chaque document a été vu au moins deux fois en moyenne.


Une exposition répétée à un petit ensemble de documents mène à la memorization : le modèle arrête d'apprendre des patterns généralisables & commence à réciter des séquences de tokens spécifiques des données d'entraînement. La mémorisation est mauvaise pour deux raisons : (1) elle gaspille de la capacité sur un rappel par cœur au lieu de la généralisation, & (2) elle peut faire fuiter les données d'entraînement via la génération.


Les Époques Comme Proxy de Mémorisation

Définir une époque sur la source k comme un passage complet à travers tous les documents de k :


epochs_k = floor(lifetime_pulls_k / n_docs_k)


Si synthetic-chat (n_docs=1400) a été tiré 2 800 fois, epochs = floor(2800/1400) = 2 : la source a été vue deux fois en entier. Si gutenberg (n_docs=500 000) a été tiré 100 000 fois, epochs = floor(100000/500000) = 0 : pas encore un passage complet.


La pénalité 1/(1+epochs)

Lorsque lifetime_pulls / n_docs > 1.0, ANDREA applique une pénalité multiplicative :


penalty = 1 / (1 + epochs)


final_weight = bandit_weight * penalty


Courbe :


époquespénalitéréduction de poids
01.000aucune
10.500moitié
20.333un tiers
30.250un quart
50.167un sixième
100.091un onzième

La pénalité augmente avec chaque passage terminé. Après de nombreuses époques, le poids de la source approche zéro & le bandit la met naturellement au repos.


Pourquoi les tirages à vie persistent à travers les redémarrages

Les entraînements d'ANDREA s'étendent sur des jours. Des crashes se produisent. Les serveurs redémarrent. Les configurations sont ajustées & l'entraînement reprend à partir d'un point de contrôle. Les tirages à vie persistent à travers tous ces événements : le proxy écrit les comptes de tirages sur disque en continu.


Si les tirages se réinitialisent à chaque redémarrage, une petite source pourrait effectivement se réinitialiser à l'époque 0 à chaque reprise d'entraînement. La pénalité ne s'accumulerait jamais, & la mémorisation se poursuivrait quoi qu'il arrive. Persister les tirages à vie rend la pénalité une contrainte réelle, croissant de manière monotone.

Calculer une Pénalité d'Époque

La source `synthetic-chat` a n_docs = 1 400. Après 4 200 tirages à vie, calculez (a) le nombre d'époques, (b) la pénalité 1/(1+époques), (c) le poids final si le poids bandit est de 1.0. Puis pour `gutenberg` avec n_docs = 500 000 & 100 000 tirages à vie, calculez (d) lifetime_pulls/n_docs, & (e) si la pénalité s'applique (oui ou non, avec raison).

Clôture de la Pile de Curriculum Bandit

Ce Que Vous Avez

Les planchers garantissent un échantillonnage minimum pour les sources prioritaires : final_weight = max(bandit_weight, floor_k). Les pénalités d'époque limitent la mémorisation sur les petites sources : quand lifetime_pulls/n_docs > 1, le poids est multiplié par 1/(1+époques). Les tirages à vie persistent à travers les redémarrages donc la pénalité devient une contrainte monotone, pas un compteur réinitialisable.


Le Pipeline Complet

Mettre ensemble les quatre activités de bandit ANDREA (76-79) :


1. Activité 76 (UCB1). Chaque étape calcule UCB(k) = mean_reward(k) + 0.5 * sqrt(ln(N)/n_k). Argmax choisit un bras.

2. Activité 77 (phases de dés). Les limites de phase (tous les 7 à 42 pas) lancent des dés pour le nombre de bras focalisés. Bras aléatoires d'abord, UCB remplit le reste. 25-33% des phases tournent complètement au hasard.

3. Activité 78 (attribution de récompense). CUDA rapporte la perte ; EMA par source suit l'historique ; reward = max(0, EMA - loss) * 1000. Récompense mise à l'échelle alimente mean_reward(k).

4. Activité 79 (planchers & époques, cette leçon). Après la sortie UCB, les planchers élèvent les sources prioritaires ; les pénalités d'époque réduisent le poids des sources mémorisées. Les tirages à vie persistent.


Ensemble : un bandit qui s'adapte (UCB1), explore de manière fiable (phases de dés), obtient des signaux de récompense honnêtes (mise à l'échelle 1000x), respecte les priorités de la conception d'entraînement (planchers), & évite la mémorisation (pénalité d'époque).


Référence

ANDREA whitepaper, sections 3.5 & 3.6.