Tại sao Floors Tồn Tại
Một Chuỗi Phần thưởng Xấu Có Thể Làm Đói Nguồn Ưu Tiên
Bandit của ANDREA chọn các arm focus theo xếp hạng UCB1. Xếp hạng UCB phụ thuộc vào mean_reward(k), vốn phụ thuộc vào cải thiện loss quan sát được. Một chuỗi tài liệu có loss cao từ nguồn ưu tiên (ví dụ dictionary) có thể kéo mean_reward(k) xuống. Bây giờ dictionary xếp hạng thấp, nhận ít lượt kéo focus, & mean_reward(k) của nó không thể phục hồi (không kéo = không quan sát mới).
Rủi ro tương tự áp dụng cho bất kỳ nguồn nào mà nhà thiết kế đào tạo của ANDREA muốn giữ trong hỗn hợp bất kể tín hiệu phần thưởng ngắn hạn.
Các Tầng như Trọng số Tối thiểu
Cấu hình huấn luyện của ANDREA chỉ định một floor (tầng) cho mỗi nguồn: trọng số lấy mẫu tối thiểu mà nguồn nhận được bất kể đầu ra UCB nói gì. Các floor chạy từ 0.0 đến 1.0. Ví dụ:
hermes3-general floor = 0.8 (nguồn ưu tiên hội thoại)
chat floor = 0.8
dictionary floor = 0.7 (giàn giáo ôn lại sự kiện)
gutenberg floor = 0.7 (sự mạch lạc văn xuôi)
trò chuyện tổng hợp floor = 0.0 (không có floor; bandit quyết định tự do)
Cách Áp dụng Floors
Sau khi UCB1 xếp hạng các arms & dice control lắp ráp các focus sets, mỗi source nhận được một trọng số tạm thời. Sau đó floor enforcement chạy:
final_weight_k = max(tentative_weight_k, floor_k)
Nếu bandit gán trọng số 0.3 cho hermes3-general nhưng floor của nó là 0.8, thì floor thắng: trọng số cuối cùng = 0.8. Giọng của bandit chỉ bị ghi đè lên trên; nó không bao giờ bị ghi đè xuống dưới.
Các Cấu Hình Khác Nhau, Các Mức Sàn Khác Nhau
ANDREA cung cấp một số cấu hình huấn luyện: chatbot, tool-caller, bash-commander. Mỗi cấu hình đặt các mức sàn khác nhau cho các nguồn ưu tiên của nó. Cấu hình Chatbot đặt sàn cao cho hermes3-general & chat. Tool-caller đặt sàn cao hơn cho repo-docstrings. Bash-commander đặt sàn cao hơn cho repo-commits. Cùng một thuật toán, ưu tiên khác nhau.
Áp Dụng Mức Sàn
Rủi ro Thuộc lòng
Các Source Nhỏ Bị Thuộc lòng
Các nguồn dữ liệu của ANDREA có kích thước khác biệt lớn. synthetic-chat có khoảng 1.400 tài liệu. gutenberg có hơn 500.000. Nếu bandit kéo đều, synthetic-chat sẽ cạn kiệt pool tài liệu nhanh chóng: sau 1.400 lần kéo, mọi tài liệu đã được thấy ít nhất một lần. Kéo 2.800 lần & mọi tài liệu đã được thấy ít nhất hai lần trung bình.
Tiếp xúc lặp lại với một tập tài liệu nhỏ dẫn đến thuộc lòng: mô hình ngừng học các mẫu tổng quát & bắt đầu ngâm nga các chuỗi token cụ thể từ dữ liệu huấn luyện. Thuộc lòng xấu vì hai lý do: (1) lãng phí dung lượng vào việc nhớ thuộc lòng thay vì tổng quát hóa, & (2) có thể rò rỉ dữ liệu huấn luyện qua generation.
Epochs Như Một Chỉ Số Thay Thế Cho Việc Ghi Nhớ
Định nghĩa một epoch trên nguồn k là một lần duyệt đầy đủ qua tất cả các tài liệu của k:
epochs_k = floor(lifetime_pulls_k / n_docs_k)
Nếu synthetic-chat (n_docs=1400) đã được kéo 2.800 lần, epochs = floor(2800/1400) = 2: nguồn đã được xem qua hai lần. Nếu gutenberg (n_docs=500.000) đã được kéo 100.000 lần, epochs = floor(100000/500000) = 0: chưa có một lần duyệt đầy đủ.
Hình Phạt 1/(1+epochs)
Khi lifetime_pulls / n_docs > 1.0, ANDREA áp dụng một hình phạt nhân:
penalty = 1 / (1 + epochs)
final_weight = bandit_weight * penalty
Đường cong:
| epochs | penalty | weight reduction |
|---|---|---|
| 0 | 1.000 | không |
| 1 | 0.500 | một nửa |
| 2 | 0.333 | một phần ba |
| 3 | 0.250 | một phần tư |
| 5 | 0.167 | một phần sáu |
| 10 | 0.091 | một phần mười một |
Hình phạt tăng lên với mỗi lượt hoàn thành. Sau nhiều epoch, trọng số của nguồn tiếp cận zero & bandit tự nhiên nghỉ nó.
Tại sao Lifetime Pulls Duy trì Qua Các Lần Khởi động Lại
Các buổi huấn luyện của ANDREA kéo dài nhiều ngày. Máy crash xảy ra. Server khởi động lại. Cấu hình được điều chỉnh & huấn luyện tiếp tục từ checkpoint. Lifetime pulls duy trì qua tất cả các sự kiện này: proxy ghi số lượng pull liên tục vào đĩa.
Nếu pulls reset ở mỗi lần khởi động lại, một nguồn nhỏ có thể hiệu quả reset về epoch 0 mỗi khi huấn luyện khởi động lại. Hình phạt sẽ không bao giờ tích lũy, & việc ghi nhớ sẽ tiến hành bất kể. Việc duy trì lifetime pulls làm cho hình phạt trở thành một ràng buộc thực sự, tăng dần đơn điệu.
Tính toán Epoch Penalty
Kết thúc Bandit Curriculum Stack
Những gì bạn đã có
Floors đảm bảo lấy mẫu tối thiểu cho các nguồn ưu tiên: final_weight = max(bandit_weight, floor_k). Epoch penalties giới hạn việc ghi nhớ trên các nguồn nhỏ: khi lifetime_pulls/n_docs > 1, weight được nhân với 1/(1+epochs). Lifetime pulls được duy trì qua các lần khởi động lại nên penalty trở thành ràng buộc đơn điệu, không phải bộ đếm có thể reset.
Toàn bộ Quy trình
Kết hợp tất cả bốn hoạt động bandit ANDREA (76-79) lại với nhau:
1. Hoạt động 76 (UCB1). Mỗi bước tính UCB(k) = mean_reward(k) + 0.5 * sqrt(ln(N)/n_k). Argmax chọn một arm.
2. Hoạt động 77 (các giai đoạn xúc xắc). Ranh giới giai đoạn (mỗi 7 đến 42 bước) tung xúc xắc để xác định số lượng arm tập trung. Các arm ngẫu nhiên trước, UCB lấp đầy phần còn lại. 25-33% các giai đoạn chạy hoàn toàn ngẫu nhiên.
3. Hoạt động 78 (phân bổ phần thưởng). CUDA báo cáo loss; EMA theo nguồn theo dõi lịch sử; reward = max(0, EMA - loss) * 1000. Phần thưởng được mở rộng cung cấp cho mean_reward(k).
4. Hoạt động 79 (floors & epochs, bài học này). Sau đầu ra UCB, floors nâng cao các nguồn ưu tiên; epoch penalties giảm trọng số các nguồn được ghi nhớ. Số lần kéo suốt đời được duy trì.
Cùng nhau: một bandit thích nghi (UCB1), khám phá đáng tin cậy (các giai đoạn xúc xắc), nhận tín hiệu phần thưởng trung thực (tỷ lệ 1000x), tôn trọng ưu tiên thiết kế huấn luyện (sàn), & tránh học thuộc lòng (phạt epoch).
Tài liệu tham khảo
Whitepaper ANDREA, các phần 3.5 & 3.6.