რატომ არსებობს ფუძეები
ცუდი ჯილდოს სტრიქონი შეუძლია გამოკვებოს პრიორიტეტული წყარო
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 (მხედველობის თანმიმდევრულობა)
სინთეტიკური-ჩატი ფლორი = 0.0 (არაა ფლორი; ბანდიტი თავისუფლად გადაწყვეტს)
როგორ მუშაობს ფლორები
UCB1-ის მიერ იარაღების რანჟირების შემდეგ და dice control-ის მიერ ფოკუს ნაკრების შეკრების შემდეგ, თითოეული წყარო იღებს საწყის წონას. შემდეგ ფლორის გამოყენება მუშაობს:
final_weight_k = max(tentative_weight_k, floor_k)
თუ ბანდიტმა hermes3-general-ს მიანიჭა წონა 0.3, მაგრამ მისი ფლორი 0.8-ია, ფლორი იმარჯვებს: საბოლოო წონა = 0.8. ბანდიტის ხმა მხოლოდ ზევით იგებს გადაწერას; ის არასდროს იგებს გადაწერას ქვევით.
[BLOCK_TYPE CONTENT source_floors/floors_overview]
სხვადასხვა კონფიგურაციები, სხვადასხვა ფლორები
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 | ერთი მეათხედი |
შუალედი იზრდება ყოველ დასრულებულ გამოტანასთან ერთად. მრავალი ეპოქის შემდეგ, წყაროს წონა ნულთან ახლოს მიუახლოვდება & ბანდიტი ბუნებრივად დაისვენებს მას.
რატომ რჩება სიცოცხლის ხანის გაყვანები ხელახლა გაშვებებს შორის
ANDREA-ს ტრენინგის გაშვებები დღეებს მოიცავს. კრაშები ხდება. სერვერები გადატვირთება. კონფიგურაციები კორექტირდება & ტრენინგი გრძელდება შემოწმების წერტილიდან. სიცოცხლის ხანის გაყვანები რჩება ყველა ამ მოვლენის შორის: პროქსი უწერს გაყვანის რიცხვებს დისკზე უწყვეტად.
თუ გაყვანები ნულდება ყოველ ხელახლა გაშვებაზე, მცირე წყარომ შეძლო ეფექტურად ნულის ეპოქამდე დაბრუნება ყოველ ხელახლა გაშვებისას. შუალედი არასდროს დაგროვდებოდა, & მემორიზაცია გაგრძელდებოდა მიუხედავად. სიცოცხლის ხანის გაყვანების შენახვა შუალედს რეალურ, მონოტონულად მზარდ შეზღუდვად აქცევს.
გამოთვალეთ ეპოქის შუალედი
ბანდიტის კურიკულუმის სტეკის დახურვა
რა გაქვთ
Floors უზრუნველყოფს მინიმალურ შეწოვას პრიორიტეტული წყაროებისთვის: 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 იუწყება loss-ზე; წყაროს მიხედვით 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.