플로어가 존재하는 이유
나쁜 보상 연속이 우선순위 소스를 굶주리게 할 수 있습니다
ANDREA의 밴디트는 UCB1 순위에 따라 포커스 팔을 선택합니다. UCB 순위는 mean_reward(k)에 의존하며, 이는 관찰된 손실 개선에 의존합니다. 우선순위 소스(예: dictionary)에서 높은 손실 문서의 연속이 mean_reward(k)를 끌어내릴 수 있습니다. 이제 dictionary 순위가 낮아져 포커스 끌림이 적어지고, mean_reward(k)가 회복될 수 없습니다 (끌림 없음 = 신선한 관찰 없음).
동일한 위험이 ANDREA의 훈련 설계자가 단기 보상 신호와 상관없이 혼합에 포함시키고자 하는 모든 소스에 적용됩니다.
최소 가중치로서의 Floors
ANDREA의 훈련 설정은 소스당 floor를 지정합니다: UCB 출력이 무엇을 말하든 소스가 받는 최소 샘플링 가중치입니다. Floors는 0.0에서 1.0까지입니다. 예시:
hermes3-general floor = 0.8 (우선 대화형 소스)
chat floor = 0.8
dictionary floor = 0.7 (사실 회상 스캐폴드)
gutenberg floor = 0.7 (산문 일관성)
합성 채팅 floor = 0.0 (floor 없음; bandit이 자유롭게 결정)
Floors가 적용되는 방식
UCB1이 팔(arms)을 순위 매기고 dice control이 focus sets를 조립한 후, 각 소스에 잠정 가중치가 부여됩니다. 그런 다음 floor 적용이 실행됩니다:
final_weight_k = max(tentative_weight_k, floor_k)
만약 bandit이 hermes3-general에 0.3의 가중치를 할당했지만 그 floor가 0.8이라면, floor가 승리합니다: 최종 가중치 = 0.8. bandit의 목소리는 위로만 무시당합니다; 아래로 무시당하지 않습니다.
다른 설정, 다른 Floors
ANDREA는 여러 훈련 설정을 제공합니다: chatbot, tool-caller, bash-commander. 각 설정은 우선순위 소스에 대해 다른 floors를 설정합니다. Chatbot은 hermes3-general & chat의 floors를 높게 설정합니다. Tool-caller는 repo-docstrings를 더 높게 설정합니다. Bash-commander는 repo-commits를 더 높게 설정합니다. 동일한 알고리즘, 다른 우선순위입니다.
Floor 적용하기
암기 위험
작은 소스가 암기됩니다
ANDREA의 데이터 소스는 크기가 매우 다양합니다. synthetic-chat은 대략 1,400개의 문서를 가지고 있습니다. gutenberg은 500,000개 이상입니다. bandit가 균등하게 뽑는다면, 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번 pull되었다면, epochs = floor(2800/1400) = 2: 소스가 두 번 전체적으로 보인 것입니다. gutenberg (n_docs=500,000)이 100,000번 pull되었다면, epochs = floor(100000/500000) = 0: 아직 전체 패스 한 번도 되지 않았습니다.
1/(1+epochs) 패널티
lifetime_pulls / n_docs > 1.0일 때, ANDREA는 곱셈 패널티를 적용합니다:
penalty = 1 / (1 + epochs)
final_weight = bandit_weight * penalty
곡선:
그래프 SVG
에포크가 증가함에 따라 패널티가 감소하는 것을 보여줍니다.
| 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 | 백분의 일 |
패널티는 완료된 각 패스마다 증가합니다. 많은 에포크 후에, 소스의 가중치가 0에 가까워지고 대역폭이 자연스럽게 이를 쉬게 합니다.
왜 Lifetime Pulls가 재시작 시에도 지속되는가
ANDREA의 훈련 실행은 며칠에 걸칩니다. 크래시가 발생합니다. 서버가 재부팅됩니다. 설정이 조정되고 체크포인트에서 훈련이 재개됩니다. Lifetime pulls는 이러한 모든 이벤트에 걸쳐 지속됩니다: 프록시는 풀 카운트를 지속적으로 디스크에 기록합니다.
각 재시작마다 풀 수가 리셋된다면, 작은 소스는 훈련 재시작 시마다 효과적으로 에포크 0으로 리셋될 수 있습니다. 패널티는 절대 누적되지 않고, 암기화는 무관하게 진행될 것입니다. Lifetime pulls를 지속함으로써 패널티는 실제로, 단조 증가하는 제약이 됩니다.
Epoch Penalty 계산
Bandit Curriculum Stack 마무리
당신이 배운 것
Floors는 우선순위 소스에 최소 샘플링을 보장합니다: final_weight = max(bandit_weight, floor_k). Epoch penalties는 작은 소스의 memorization을 제한합니다: lifetime_pulls/n_docs > 1일 때, weight에 1/(1+epochs)를 곱합니다. Lifetime pulls는 재시작 간에 지속되므로 penalty는 재설정 가능한 카운터가 아닌 단조 제약이 됩니다.
전체 파이프라인
네 개의 ANDREA bandit 활동(76-79)을 모두 함께 묶은 것:
1. 활동 76 (UCB1). 각 단계에서 UCB(k) = mean_reward(k) + 0.5 * sqrt(ln(N)/n_k)를 계산합니다. Argmax가 팔을 선택합니다.
2. 활동 77 (dice phases). 단계 7에서 42마다 위상 경계에서 주력 팔 수를 위해 주사위를 굴립니다. 먼저 랜덤 팔, UCB가 나머지를 채웁니다. 25-33%의 위상이 완전히 랜덤으로 실행됩니다.
3. 활동 78 (reward attribution). CUDA가 손실을 보고; 소스별 EMA가 기록을 추적; reward = max(0, EMA - loss) * 1000. 스케일된 보상이 mean_reward(k)에 공급됩니다.
4. 활동 79 (floors & epochs, 이 레슨). UCB 출력 후, floors가 우선순위 소스를 올리고; epoch penalties가 암기된 소스를 다운웨이트합니다. 평생 pulls가 지속됩니다.
함께: 적응하는 bandit(UCB1), 신뢰성 있게 탐색(dice phases), 정직한 보상 신호를 얻음(1000x scaling), 훈련 설계 우선순위를 존중(floors), & 암기 피함(epoch penalty).
참고 자료
ANDREA whitepaper, 섹션 3.5 & 3.6.