Чому існують підлоги
Погана серія винагород може голодувати пріоритетне джерело
Бандит ANDREA обирає фокусні руки за рангом UCB1. Ранг UCB залежить від mean_reward(k), який залежить від спостережуваних покращень втрат. Серія документів з високими втратами від пріоритетного джерела (скажімо dictionary) може затягнути mean_reward(k) вниз. Тепер dictionary має низький ранг, отримує мало фокусних витягувань, & його mean_reward(k) не може відновитися (немає витягувань = немає свіжих спостережень).
Такий самий ризик стосується будь-якого джерела, яке дизайнер навчання ANDREA хоче в суміші незалежно від короткострокового сигналу винагороди.
Підлоги як мінімальні ваги
Конфігурація тренування ANDREA вказує підлогу для кожного джерела: мінімальну вагу вибірки, яку джерело отримує незалежно від того, що каже вивід UCB. Підлоги варіюються від 0.0 до 1.0. Приклади:
hermes3-general підлога = 0.8 (пріоритетне розмовне джерело)
chat підлога = 0.8
dictionary підлога = 0.7 (каркас для фактичного відтворення)
gutenberg підлога = 0.7 (згуртованість прози)
синтетичний-чат floor = 0.0 (без підлоги; бандит вирішує вільно)
Як застосовуються підлоги
Після того, як UCB1 ранжує руки & dice control формує фокусні набори, кожен джерело отримує попередню вагу. Потім запускається примусове застосування підлог:
final_weight_k = max(tentative_weight_k, floor_k)
Якщо бандит призначив вагу 0.3 для hermes3-general, але його підлога 0.8, то підлога перемагає: остаточна вага = 0.8. Голос бандита перезаписується тільки вгору; він ніколи не перезаписується вниз.
Різні конфігурації, різні підлоги
ANDREA постачає кілька конфігурацій тренування: chatbot, tool-caller, bash-commander. Кожна конфігурація встановлює різні підлоги для своїх пріоритетних джерел. Chatbot піднімає підлоги hermes3-general & chat високо. Tool-caller піднімає repo-docstrings ще вище. Bash-commander піднімає repo-commits ще вище. Той самий алгоритм, різні пріоритети.
Застосувати підлогу
Ризик запам'ятовування
Маленькі джерела запам'ятовуються
Джерела даних ANDREA сильно відрізняються за розміром. synthetic-chat має приблизно 1,400 документів. gutenberg має 500,000+. Якщо бандит тягне рівномірно, synthetic-chat швидко вичерпає пул документів: після 1,400 тягнень кожен документ буде побачений принаймні раз. Тягніть 2,800 разів & кожен документ буде побачений принаймні двічі в середньому.
Повторна експозиція до малого набору документів призводить до запам'ятовування: модель припиняє вивчати узагальнені патерни & починає відтворювати конкретні послідовності токенів з тренувальних даних. Запам'ятовування погане з двох причин: (1) воно витрачає ємність на зубрежку замість узагальнення, & (2) воно може витікати тренувальні дані через генерацію.
Епохи як проксі для запам'ятовування
Визначимо епоху над джерелом k як один повний прохід через всі документи k:
epochs_k = floor(lifetime_pulls_k / n_docs_k)
Якщо synthetic-chat (n_docs=1400) було витягнуто 2,800 разів, epochs = floor(2800/1400) = 2: джерело було переглянуто двічі. Якщо gutenberg (n_docs=500,000) було витягнуто 100,000 разів, epochs = floor(100000/500000) = 0: ще не повний прохід.
Штраф 1/(1+epochs)
Коли lifetime_pulls / n_docs > 1.0, ANDREA застосовує мультиплікативний штраф:
penalty = 1 / (1 + epochs)
final_weight = bandit_weight * penalty
Крива:
| епохи | штраф | зменшення ваги |
|---|---|---|
| 0 | 1.000 | немає |
| 1 | 0.500 | половина |
| 2 | 0.333 | одна третина |
| 3 | 0.250 | одна чверть |
| 5 | 0.167 | одна шоста |
| 10 | 0.091 | одна одинадцята |
Штраф зростає з кожним завершеним проходом. Після багатьох епох вага джерела наближається до нуля & бандит природно відпочиває його.
Чому Lifetime Pulls Зберігаються Під Час Перезапусків
Тренувальні запуски ANDREA тривають дні. Створюються збої. Сервери перезавантажуються. Конфігурації налаштовуються & тренування відновлюється з чекпоінту. Lifetime pulls зберігаються під час всіх цих подій: проксі постійно записує лічильники витягувань на диск.
Якщо витягування скидаються при кожному перезапуску, маленьке джерело могло б ефективно скидатися до епохи 0 щоразу, коли тренування перезапускається. Штраф ніколи б не накопичувався, & меморизація відбувалася б незалежно. Збереження lifetime pulls робить штраф реальним, монотонно зростаючим обмеженням.
Обчислити Штраф Епохи
Завершення Стеку Куррикулуму Бандита
Що Ви Маєте
Підлоги гарантують мінімальне вибіркове охоплення для пріоритетних джерел: final_weight = max(bandit_weight, floor_k). Штрафи епох обмежують запам'ятовування на малих джерелах: коли lifetime_pulls/n_docs > 1, вага множиться на 1/(1+epochs). Загальні запити зберігаються між перезапусками, тому штраф стає монотонним обмеженням, а не скидним лічильником.
Повний конвеєр
Об’єднання всіх чотирьох активностей бандита ANDREA (76-79):
1. Активність 76 (UCB1). Кожен крок обчислює UCB(k) = mean_reward(k) + 0.5 * sqrt(ln(N)/n_k). Argmax вибирає руку.
2. Активність 77 (фази кубиків). Межі фаз (кожні 7 до 42 кроки) кидають кубик для кількості фокусних рук. Спочатку випадкові руки, UCB заповнює решту. 25-33% фаз працюють повністю випадково.
3. Активність 78 (приписування винагороди). CUDA повідомляє втрату; EMA на джерело відстежує історію; винагорода = max(0, EMA - loss) * 1000. Масштабована винагорода надходить до mean_reward(k).
4. Активність 79 (мінімуми & епохи, цей урок). Після виходу UCB мінімуми піднімають пріоритетні джерела; штрафи епох знецінюють запам’ятані джерела. Довічні витягування зберігаються.
Разом: бандит, що адаптується (UCB1), надійно досліджує (dice phases), отримує чесні сигнали винагороди (1000x scaling), поважає пріоритети дизайну тренування (floors) та уникає запам'ятовування (epoch penalty).
Посилання
ANDREA whitepaper, розділи 3.5 та 3.6.