फ्लोर्स क्यों मौजूद हैं
एक खराब रिवार्ड स्ट्रीक प्राथमिकता स्रोत को भूखा रख सकती है
ANDREA का बैंडिट UCB1 रैंक से फोकस आर्म्स चुनता है। UCB रैंक mean_reward(k) पर निर्भर करता है, जो देखे गए लॉस सुधारों पर निर्भर करता है। प्राथमिकता स्रोत (मान लीजिए dictionary) से उच्च-लॉस दस्तावेज़ों की एक स्ट्रीक mean_reward(k) को नीचे खींच सकती है। अब dictionary कम रैंक करता है, कम फोकस खींचने पाता है, & इसका mean_reward(k) ठीक नहीं हो सकता (कोई खींचना = कोई नई अवलोकन नहीं)।
एक ही जोखिम ANDREA के ट्रेनिंग डिज़ाइनर द्वारा मिश्रण में चाहे गए किसी भी स्रोत पर लागू होता है, अल्पकालिक रिवार्ड सिग्नल की परवाह किए बिना।
फ्लोर न्यूनतम वजन के रूप में
ANDREA का प्रशिक्षण कॉन्फ़िग प्रत्येक स्रोत के लिए एक फ्लोर निर्दिष्ट करता है: एक न्यूनतम सैंपलिंग वजन जो 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 खींचने के बाद, हर दस्तावेज़ कम से कम एक बार देखा गया होता है। 2,800 बार खींचें & औसतन हर दस्तावेज़ कम से कम दो बार देखा गया होता है।
एक छोटे सेट के दस्तावेज़ों की बार-बार एक्सपोजर स्मरणीकरण की ओर ले जाती है: मॉडल सामान्यीकृत पैटर्न सीखना बंद कर देता है & ट्रेनिंग डेटा से विशिष्ट टोकन अनुक्रमों का पाठ करना शुरू कर देता है। स्मरणीकरण दो कारणों से बुरा है: (1) यह सामान्यीकरण के बजाय रटने पर क्षमता बर्बाद करता है, & (2) यह जेनरेशन के माध्यम से ट्रेनिंग डेटा लीक कर सकता है।
Epochs को Memorization Proxy के रूप में
सोर्स k पर एक epoch को 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
वक्र: Curve:
| epochs | penalty | weight reduction |
|---|---|---|
| 0 | 1.000 | कोई नहीं |
| 1 | 0.500 | आधा |
| 2 | 0.333 | एक तिहाई |
| 3 | 0.250 | एक चौथाई |
| 5 | 0.167 | एक छठा |
| 10 | 0.091 | एक ग्यारहवां |
दंड प्रत्येक पूर्ण पास के साथ बढ़ता है। कई epochs के बाद, स्रोत का वजन शून्य के करीब पहुंच जाता है & बैंडिट इसे स्वाभाविक रूप से आराम दे देता है।
क्यों Lifetime Pulls रीस्टार्ट्स के पार बने रहते हैं
ANDREA के प्रशिक्षण रन दिनों तक चलते हैं। क्रैश हो जाते हैं। सर्वर रीबूट होते हैं। कॉन्फ़िगरेशन को ट्वीक किया जाता है & प्रशिक्षण चेकपॉइंट से फिर शुरू होता है। Lifetime pulls इन सभी घटनाओं के पार बने रहते हैं: प्रॉक्सी पुल काउंट्स को लगातार डिस्क पर लिखता है।
यदि प्रत्येक रीस्टार्ट पर pulls रीसेट हो जाते, तो एक छोटा स्रोत हर बार प्रशिक्षण रीस्टार्ट होने पर प्रभावी रूप से epoch 0 पर रीसेट हो सकता था। दंड कभी संचित नहीं होता, & memorization बिना रुके आगे बढ़ता रहता। 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 restarts के पार बने रहते हैं इसलिए penalty एक monotone constraint बन जाती है, न कि resettable counter।
पूर्ण पाइपलाइन
चारों ANDREA बैंडिट गतिविधियों (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 आउटपुट के बाद, फ्लोर्स प्राथमिकता स्रोतों को ऊपर उठाते हैं; एपोक दंड memorized स्रोतों का वजन कम करते हैं। जीवनकाल पुल्स बने रहते हैं।
साथ में: एक बैंडिट जो अनुकूलित होता है (UCB1), विश्वसनीय रूप से अन्वेषण करता है (dice phases), ईमानदार पुरस्कार संकेत प्राप्त करता है (1000x scaling), प्रशिक्षण-डिज़ाइन प्राथमिकताओं का सम्मान करता है (floors), और स्मृतिकरण से बचता है (epoch penalty)।
संदर्भ
ANDREA whitepaper, sections 3.5 & 3.6.