フロアが存在する理由
悪い報酬連鎖が優先ソースを飢えさせる
ANDREAのバンディットはUCB1ランクでフォーカスアームを選択します。UCBランクはmean_reward(k)に依存し、それは観測された損失改善に依存します。優先ソース（例：dictionary）からの高損失ドキュメントの連鎖はmean_reward(k)を引き下げます。今dictionaryのランクが低くなり、フォーカスプルが少なくなり、そのmean_reward(k)は回復できません（プルなし = 新鮮な観測なし）。
同じリスクは、ANDREAのトレーニングデザイナーが短期報酬シグナルに関わらず混ぜたいと思う任意のソースに適用されます。
フロアとしての最小重み
ANDREAのトレーニング設定では、ソースごとにfloor（フロア）が指定されています。これは、UCBの出力に関係なくソースが受け取る最小サンプリング重みです。フロアは0.0から1.0の範囲です。例：
hermes3-general floor = 0.8 (優先会話ソース)
chat floor = 0.8
dictionary floor = 0.7 (事実想起の足場)
gutenberg floor = 0.7 (散文の一貫性)
synthetic-chat floor = 0.0 (フロアなし; バンディットが自由に決定)
フロアの適用方法
UCB1がアームをランク付けし、dice controlがフォーカスセットを組み立てた後、各ソースに暫定的な重みが割り当てられます。その後、フロア強制が実行されます：
final_weight_k = max(tentative_weight_k, floor_k)
バンディットがhermes3-generalに重み0.3を割り当てたが、そのフロアが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回のプル後、すべてのドキュメントが少なくとも1回見られています。2,800回プルすると、平均してすべてのドキュメントが少なくとも2回見られています。
少数のドキュメントへの繰り返しの露出は記憶化を引き起こします：モデルは一般化可能なパターンを学習するのをやめ、トレーニングデータからの特定のトークンシーケンスを暗唱し始めます。記憶化は2つの理由で悪影響です：(1) 一般化ではなく暗記に容量を浪費し、(2) 生成を通じてトレーニングデータを漏洩させる可能性があります。
エポックを記憶化の代理として
ソース k に対するエポックを、k のすべてのドキュメントを通る1回の完全なパスとして定義します：
epochs_k = floor(lifetime_pulls_k / n_docs_k)
synthetic-chat (n_docs=1400) が2,800回引き出された場合、epochs = floor(2800/1400) = 2：ソースが2回通しで見たことになります。gutenberg (n_docs=500,000) が100,000回引き出された場合、epochs = floor(100000/500000) = 0：まだ1回の完全なパスに達していません。
1/(1+epochs) ペナルティ
lifetime_pulls / n_docs > 1.0 の場合、ANDREA は乗算ペナルティを適用します：
penalty = 1 / (1 + epochs)
final_weight = bandit_weight * penalty
曲線： Curve:
| epochs | penalty | weight reduction |
|---|---|---|
| 0 | 1.000 | なし |
| 1 | 0.500 | 半分 |
| 2 | 0.333 | 3分の1 |
| 3 | 0.250 | 4分の1 |
| 5 | 0.167 | 6分の1 |
| 10 | 0.091 | 十一分の一 |
ペナルティは各完了したパスごとに増加します。多くのエポック後、ソースの重みはゼロに近づき、バンディットは自然にそれを休ませます。
なぜ生涯プルが再起動時にも持続するのか
ANDREAのトレーニング実行は数日間に及びます。クラッシュが発生します。サーバーが再起動します。設定が調整され、チェックポイントからトレーニングが再開されます。生涯プルはこれらのすべてのイベントにわたって持続します：プロキシはプル数を継続的にディスクに書き込みます。
プルが各再起動時にリセットされる場合、小さなソースはトレーニング再起動のたびに効果的にエポック0にリセットされる可能性があります。ペナルティは蓄積されず、記憶化は進行します。生涯プルを保持することで、ペナルティは実際の単調増加制約となります。
エポックペナルティを計算する
Bandit Curriculum Stackの締めくくり
あなたが学んだこと
フロアは優先ソースの最小サンプリングを保証：final_weight = max(bandit_weight, floor_k)。エポックペナルティは小規模ソースのmemorizationを制限：lifetime_pulls/n_docs > 1 の場合、ウェイトに1/(1+epochs)を乗算。生涯プルは再起動をまたいで持続するため、ペナルティはリセット可能なカウンタではなく単調制約となる。
完全なパイプライン
4つのANDREAバンディット活動（76-79）をすべて組み合わせる：
1. Activity 76 (UCB1). 各ステップで UCB(k) = mean_reward(k) + 0.5 * sqrt(ln(N)/n_k) を計算。Argmax でアームを選択。
2. Activity 77 (dice phases). フェーズ境界（7〜42ステップごと）でダイスを振ってフォーカスアーム数を決定。最初にランダムアーム、残りをUCBで埋める。25-33%のフェーズが完全にランダム。
3. Activity 78 (reward attribution). CUDA が損失を報告；ソースごとのEMAが履歴を追跡；reward = max(0, EMA - loss) * 1000。スケーリングされた報酬が mean_reward(k) に供給。
4. Activity 79 (floors & epochs, this lesson). UCB出力後、フロアが優先ソースの優先度を上げる；エポックペナルティが記憶されたソースの重みを下げる。一生涯のプルは持続。
全体として：適応するバンディット（UCB1）、確実に探索する（dice phases）、正直な報酬信号を得る（1000x scaling）、トレーニング設計の優先事項を尊重する（floors）、および記憶化を避ける（epoch penalty）。
参考文献
ANDREA whitepaper、セクション 3.5 & 3.6。