अपने एनोटेशन पर LLM को फ़ाइन-ट्यून करना

v2.14.0 में नया

यह ट्यूटोरियल Potato अध्ययन के इकट्ठा किए उत्तरों पर चार प्रकार के भाषा मॉडल प्रशिक्षित करता है। llm-sft ट्रेनर LLM को लिखे गए उत्तरों या सुधारे गए एजेंट ट्रेस पर फ़ाइन-ट्यून करता है, llm-dpo LLM को pairwise चुनावों पर ट्यून करता है, reward-model तुलनाओं पर एक स्केलर रिवॉर्ड मॉडल फ़िट करता है, और prm-reward चरण रेटिंग पर एक प्रोसेस रिवॉर्ड मॉडल फ़िट करता है। पेज उन टीमों के लिए लिखा गया है जो Potato में पहले से प्राथमिकता या ट्रेस डेटा इकट्ठा करती हैं और डेटा को अलग प्रशिक्षण स्क्रिप्ट में निर्यात किए बिना उन लेबलों से पहला मॉडल चाहती हैं। हर अनुभाग उस स्कीम का नाम बताता है जो डेटा बनाती है, Potato के वैलिडेटर से पास होने वाला config देता है, बदलने लायक पैरामीटर सूचीबद्ध करता है, और बताता है कि होल्ड-आउट स्कोर क्या मापता है और भविष्यवाणियाँ प्री-लेबल के रूप में एनोटेटरों के पास जाती हैं या नहीं। मॉडल प्रशिक्षण का अवलोकन Training पेज को समझाता है, और अपना पहला मॉडल प्रशिक्षित करें एक ऐसे क्लासिफ़ायर के साथ पूरा चक्र चलाता है जिसे GPU नहीं चाहिए।

एनोटेशन स्कीम के अनुसार ट्रेनर

इस पेज का हर ट्रेनर एक रन में एक एनोटेशन स्कीम से सीखता है, और Training पेज किसी स्कीम के लिए केवल वही ट्रेनर देता है जो उस स्कीम को सीख सकते हैं। नीचे की तालिका हर ट्रेनर की सीखने वाली स्कीम सूचीबद्ध करती है:

शुरू करने से पहले

Potato के प्रशिक्षण एक्स्ट्रा चारों ट्रेनरों के लिए PyTorch, Transformers और PEFT इंस्टॉल करते हैं:

pip install "potato-annotation[train-llm]"
pip install "potato-annotation[train-text]"

पहला एक्स्ट्रा llm-sft और llm-dpo को कवर करता है, और दूसरा reward-model और prm-reward को। pip install "potato-annotation[train]" सभी प्रशिक्षण एक्स्ट्रा एक साथ इंस्टॉल करता है। जिस ट्रेनर के पैकेज गायब हैं वह Training पेज पर "not installed" के रूप में सूचीबद्ध होता है, साथ में पैकेज इंस्टॉल करने की कमांड।

हर ट्रेनर train स्प्लिट में 20 से कम आइटम होने पर फ़िट करने से मना कर देता है (min_instances पैरामीटर)। डिफ़ॉल्ट स्प्लिट लेबल किए गए आइटम का 70% train में, 15% val में और 15% test में रखता है, इसलिए पहले रन से पहले लगभग 30 लेबल किए गए आइटम की योजना बनाएँ। val और test आइटम प्रशिक्षण से बाहर रखे जाते हैं और मॉडल को स्कोर करते हैं।

llm-sft और llm-dpo Qwen/Qwen2.5-0.5B-Instruct से शुरू करते हैं, reward-model distilbert/distilroberta-base से, और prm-reward answerdotai/ModernBERT-base से। LLM ट्रेनर GPU पर चलने के लिए बनाए गए हैं। जब Potato चलाने वाली मशीन में GPU नहीं है, तब रिमोट प्रशिक्षण रन को ssh से किसी GPU सर्वर या SLURM क्लस्टर पर भेजता है।

ऐसा अध्ययन जो प्राथमिकताएँ और पुनर्लेखन इकट्ठा करता है

पहला config हर ग्राहक-सहायता प्रॉम्प्ट के बारे में दो प्रश्न पूछता है। एनोटेटर दो उत्तरों में से बेहतर उत्तर चुनते हैं और वह उत्तर लिखते हैं जो एक एनोटेटर असिस्टेंट से चाहेगा। चुनाव llm-dpo और reward-model को प्रशिक्षित करता है, और लिखा गया उत्तर llm-sft को। data/answers.jsonl की हर पंक्ति में एक प्रॉम्प्ट और दो उत्तर हैं:

{"id": "q001", "prompt": "How do I reset my router to factory settings?", "responses": ["Hold the reset button on the back for 10 seconds until the lights blink, then wait two minutes for the router to restart.", "Routers can be reset. Check the manual."]}

config प्रॉम्प्ट को आइटम के टेक्स्ट के रूप में और दोनों उत्तरों को कार्ड A और B के रूप में दिखाता है:

annotation_task_name: "Support answers: preferences and rewrites"
task_dir: .
data_files:
  - data/answers.jsonl
item_properties:
  id_key: id
  text_key: prompt
output_annotation_dir: annotation_output
user_config:
  allow_all_users: true
 
annotation_schemes:
  - annotation_type: pairwise
    name: preferred
    description: "Which response answers the question better?"
    mode: binary
    items_key: responses
    allow_tie: true
    tie_label: "No preference"
 
  - annotation_type: text
    name: rewrite
    description: "Write the answer you would want the assistant to give."
    multiline: true
    rows: 4
 
model_training:
  enabled: true
  writeback:
    schemas: [preferred]
    min_confidence: 0.7

text_key: prompt दो बार मायने रखता है, क्योंकि प्रॉम्प्ट वही है जिसे एनोटेटर पढ़ते हैं और जिसे llm-sft प्रश्न के बाद रखता है। items_key: responses उस सूची का नाम देता है जिससे pairwise कार्ड बनते हैं, डेटा के क्रम में, इसलिए A पहला उत्तर है। writeback.schemas में केवल preferred है, इसलिए एनोटेटर मॉडल का चुनाव देखते हैं, जनरेट किया गया पुनर्लेखन नहीं। प्री-लेबल एनोटेटरों को प्रभावित करते हैं, इसलिए rewrite को सूची में तभी जोड़ें जब llm-sft रन का होल्ड-आउट स्कोर मॉडल का टेक्स्ट दिखाने का समर्थन करे। min_confidence: 0.7 उन भविष्यवाणियों को पेज से बाहर रखता है जिनके बारे में मॉडल कम निश्चित है, जबकि भविष्यवाणियाँ फिर भी सहेजी जाती हैं। सर्वर शुरू करने से पहले config को Potato के वैलिडेटर से जाँचें:

python -m potato.validate_cli config.yaml --strict

Potato शुरू करें, कम से कम 30 प्रॉम्प्ट पर लेबल लगाएँ, और एडमिन के रूप में /admin/training खोलें। नीचे के रन config की admin_api_key को $KEY में रखकर API से भी शुरू किए जा सकते हैं।

llm-sft से सुपरवाइज़्ड फ़ाइन-ट्यूनिंग

llm-sft हर लेबल किए गए आइटम को एक प्रशिक्षण उदाहरण में बदलता है। प्रॉम्प्ट स्कीम का description (वह प्रश्न जो एनोटेटरों ने देखा) और उसके बाद आइटम का टेक्स्ट है, और लक्ष्य वह उत्तर है जो एनोटेटर ने लिखा। लॉस केवल उत्तर के टोकन को कवर करता है, इसलिए मॉडल उत्तर देना सीखता है, प्रॉम्प्ट दोहराना नहीं। डिफ़ॉल्ट रूप से हर वज़न के बजाय एक LoRA एडेप्टर प्रशिक्षित होता है।

Training पेज पर llm-sft और rewrite स्कीम चुनें और Train now पर क्लिक करें, या वही रन API से शुरू करें:

curl -X POST -H "X-API-Key: $KEY" -H "Content-Type: application/json" \
  http://localhost:8000/admin/training/api/runs \
  -d '{"trainer": "llm-sft", "schemas": ["rewrite"], "params": {"max_new_tokens": 256}}'

अधिकतर रन केवल इस तालिका के पैरामीटर बदलते हैं:

रन सबसे कम val लॉस वाला चेकपॉइंट रखता है। चूँकि रन ने चेकपॉइंट val पर चुना, होल्ड-आउट स्कोर test से पढ़ा जाता है। स्कोर token F1 है, यानी जनरेट किए और लिखे गए उत्तर के बीच शब्दों का ओवरलैप, क्रम की परवाह किए बिना, और exact match स्कोर के बगल में रिपोर्ट होता है। Token F1 उस उत्तर को भी श्रेय देता है जो सही शब्द गलत जगहों पर इस्तेमाल करता है, इसलिए दोनों मीट्रिक साथ पढ़ें।

मॉडल हर val और test आइटम के लिए ग्रीडी तरीके से एक उत्तर जनरेट करता है। writeback.include_unlabeled: true के साथ मॉडल उन आइटम का भी उत्तर देता है जिन पर किसी ने लेबल नहीं लगाया। भविष्यवाणी का विश्वास उन टोकन की औसत प्रायिकता है जो मॉडल ने जनरेट किए, और मॉडल समीक्षा कतार उसी विश्वास से क्रमित होती है। rewrite के writeback.schemas में होने पर, एनोटेटर के आइटम खोलते ही जनरेट किया उत्तर टेक्स्ट बॉक्स में भर जाता है।

फ्री टेक्स्ट प्रति आइटम कई एनोटेटरों के लिए कमज़ोर बैठता है। aggregation सेटिंग कई उत्तरों को एक में बदलती है, उत्तरों की शब्द-दर-शब्द तुलना करके, और दो लिखे गए उत्तर शायद ही कभी शब्द-दर-शब्द मेल खाते हैं। text स्कीम पर llm-sft के लिए, प्रति आइटम एक लेखक शब्द-दर-शब्द तुलना से बचाता है।

llm-dpo से प्राथमिकता ट्यूनिंग

Direct Preference Optimization (DPO) एक LLM को पसंदीदा उत्तर की संभावना को दूसरे उत्तर के सापेक्ष बढ़ाना सिखाता है, जिसे शुरुआती मॉडल की एक फ़्रीज़ की गई संदर्भ प्रति के विरुद्ध मापा जाता है। llm-dpo A या B उत्तर वाले हर आइटम से एक उदाहरण बनाता है। प्रॉम्प्ट आइटम का prompt फ़ील्ड है, या question, instruction, query, input और context में से वह पहला जो आइटम में है। टाई विकल्प वाले आइटम छोड़ दिए जाते हैं, क्योंकि टाई किसी उत्तर को बेहतर नहीं ठहराता।

llm-dpo और preferred स्कीम चुनें, या ऊपर वाला ही अनुरोध "trainer": "llm-dpo" और "schemas": ["preferred"] के साथ भेजें। डिफ़ॉल्ट LoRA एडेप्टर के साथ संदर्भ मॉडल वही मॉडल है जिसका एडेप्टर बंद है, इसलिए मेमोरी में दूसरी प्रति नहीं रखी जाती। lora: false हर वज़न को प्रशिक्षित करता है और संदर्भ के रूप में एक फ़्रीज़ की गई प्रति रखता है, और वह प्रति मेमोरी को दोगुना कर देती है।

रन val पर सबसे कम DPO लॉस वाला चेकपॉइंट रखता है, और रन का लॉग बताता है कि val पर मॉडल कितनी बार एनोटेटरों के चुनाव को वरीयता देता है। होल्ड-आउट स्कोर test पर accuracy है, उन आइटम पर जिनका उत्तर टाई नहीं था, और accuracy के बगल में macro-F1 है। भविष्यवाणी वह उत्तर है जिसे प्रशिक्षित मॉडल वरीयता देता है, और उस वरीयता की प्रायिकता विश्वास है। प्री-लेबल के रूप में, एनोटेटर के आइटम खोलते ही पसंदीदा उत्तर का कार्ड चुना हुआ दिखता है। स्कीम पर randomize_order होने पर, चयन उत्तर के साथ वहाँ जाता है जहाँ एनोटेटर को वह उत्तर दिखता है। सहेजा गया एडेप्टर भी एक पॉलिसी है और PEFT से लोड करने पर टेक्स्ट जनरेट करता है। प्राथमिकता डेटा इकट्ठा करने की पृष्ठभूमि के लिए RLHF और प्राथमिकता डेटा इकट्ठा करना और युग्मवार तुलना देखें।

reward-model से रिवॉर्ड मॉडल

रिवॉर्ड मॉडल किसी उत्तर को एक संख्या में बदलता है, RLHF के लिए, best-of-n सैंपलिंग के लिए, या नए आउटपुट को रैंक करने के लिए। reward-model एक आउटपुट वाला ट्रांसफ़ॉर्मर प्रशिक्षित करता है ताकि जिस उत्तर को एनोटेटरों ने पसंद किया उसे ऊँचा स्कोर मिले। लॉस Bradley–Terry लॉस है, -log sigmoid(r_winner - r_loser), यानी InstructGPT का रिवॉर्ड-मॉडलिंग लॉस। ऊपर की preferred स्कीम config बदले बिना reward-model को प्रशिक्षित करती है। हर तुलनात्मक स्कीम एक अलग प्रशिक्षण संकेत देती है:

जब आइटम में प्रॉम्प्ट फ़ील्ड होता है, तब हर रिवॉर्ड प्रॉम्प्ट दिए जाने पर उत्तर का होता है। रैंकिंग के विकल्प स्कीम के लेबल हैं, और हर एक को आइटम के टेक्स्ट के साथ स्कोर किया जाता है। सर्वर BWS टपल bws_config से बनाता है, इसलिए सर्वर के अपने डेटा से किए गए रन के पास टपल होते हैं, और डेटा फ़ाइलों में टपल नहीं चाहिए।

भविष्यवाणियाँ स्कीम के अपने प्रश्न का उत्तर देती हैं, इसलिए भविष्यवाणियाँ किसी भी अन्य स्कीम की तरह स्कोर और राइट-बैक होती हैं। प्री-लेबल binary चुनाव के लिए चुना हुआ कार्ड है, scale के लिए स्लाइडर की स्थिति, ranking के लिए सूची का क्रम, और BWS के लिए चुने गए सबसे अच्छे और सबसे खराब। हर भविष्यवाणी वे rewards भी सहेजती है जिनसे वह निकली। केवल रिवॉर्ड के बीच के अंतर का अर्थ है। Pairwise और Best-Worst Scaling डेटा इकट्ठा करने के तुलनात्मक प्रारूपों की तुलना करता है।

ऐसा अध्ययन जो चरण रेटिंग और सुधार इकट्ठा करता है

दूसरा config एजेंट ट्रेस पर काम करता है। एनोटेटर ट्रेस के हर चरण को रेट करते हैं और फिर गलत चरण सुधारते हैं। चरण रेटिंग prm-reward को प्रशिक्षित करती हैं, और सुधार llm-sft या llm-dpo को। data/traces.jsonl की हर पंक्ति में कार्य, एजेंट के चरण और अंतिम उत्तर हैं:

{"id": "traj_001", "task_description": "Find the current weather in San Francisco and report the temperature.", "steps": [{"thought": "I should look up the current weather.", "action": "web_search(queyr='San Francisco weather')"}, {"thought": "Open the first result.", "action": "open_url(results[0])"}, {"thought": "Read the temperature from the page.", "action": "extract_text('.temp')"}], "final_answer": "It is sunny."}

ट्रेनर कार्य को आइटम के task_description, task या text फ़ील्ड से इसी क्रम में पढ़ते हैं:

annotation_task_name: "Agent traces: step ratings and corrections"
task_dir: .
data_files:
  - data/traces.jsonl
item_properties:
  id_key: id
  text_key: task_description
output_annotation_dir: annotation_output
user_config:
  allow_all_users: true
 
annotation_schemes:
  - annotation_type: process_reward
    name: step_quality
    description: "Rate each step of the agent's trace"
    steps_key: steps
    step_text_key: action
    mode: per_step
    allow_neutral: true
    ai_prelabel: true
 
  - annotation_type: trajectory_edit
    name: corrected_trace
    description: "Fix the wrong steps, then correct the final answer"
    steps_key: steps
    step_text_key: action
    editable_fields: [action]
    show_diff: true
    edit_final_answer: true
    final_answer_key: final_answer
 
model_training:
  enabled: true
  writeback:
    schemas: [step_quality]
    include_unlabeled: true

allow_neutral: true के साथ mode: per_step वे तीन रेटिंग देता है जो prm-reward सीखता है। ai_prelabel: true स्कीम पर "AI pre-label steps" बटन रखता है, और प्रशिक्षित रेटिंग उसी बटन के ज़रिए दिखती हैं। writeback.schemas में केवल step_quality है। वहाँ corrected_trace सूचीबद्ध करने पर सर्वर शुरू नहीं होता, और वैलिडेटर कारण बताता है:

model_training.writeback.schemas names 'corrected_trace', a trajectory_edit scheme, which has no prelabel display: its predictions are stored and scored but annotators would never see them. Leave it out of writeback.schemas.

llm-sft और llm-dpo से ट्रेस की मरम्मत

trajectory_edit का उत्तर ट्रेस की एक जोड़ी है, यानी एजेंट के मूल चरण और एनोटेटर के सुधारों के बाद के चरण। SFT/DPO के लिए ट्रेजेक्टरी संपादन संपादक को समझाता है, और ट्रेजेक्टरी संपादन वाला पोस्ट बताता है कि जोड़ियाँ प्रशिक्षण डेटा कैसे बनती हैं। दोनों ट्रेनर उन ट्रेस को छोड़ देते हैं जिन्हें किसी ने संपादित नहीं किया।

• llm-sft कार्य और मूल चरणों को प्रॉम्प्ट और सुधारे गए चरणों को लक्ष्य के रूप में लेता है, इसलिए मॉडल ट्रेस की मरम्मत करना सीखता है। हर चरण Step N के बाद चरण के फ़ील्ड (action: ..., thought: ...) के रूप में लिखा जाता है, और स्कीम में final_answer_key होने पर अंतिम उत्तर आख़िरी चरण के बाद आता है।
• llm-dpo कार्य को प्रॉम्प्ट, सुधारे गए चरणों को पसंदीदा उत्तर, और मूल चरणों को दूसरा उत्तर मानता है। भविष्यवाणी बताती है कि मॉडल सुधार (A) को वरीयता देता है या मूल (B) को, और वह केवल उन होल्ड-आउट ट्रेस के लिए बनती है जिनमें सुधार है।

दोनों रन closer_to_correction को होल्ड-आउट स्कोर के रूप में रिपोर्ट करते हैं। llm-dpo के लिए स्कोर उन होल्ड-आउट ट्रेस का अनुपात है जहाँ मॉडल सुधार को वरीयता देता है। llm-sft के लिए स्कोर उन ट्रेस का अनुपात है जहाँ token F1 के अनुसार लिखे गए चरण मूल की तुलना में सुधार के अधिक निकट हैं, और सुधार के विरुद्ध token_f1 स्कोर के बगल में रिपोर्ट होता है।

trajectory_edit रन की भविष्यवाणियाँ सहेजी और स्कोर की जाती हैं, और एनोटेटर उन्हें कभी नहीं देखते। संपादक हमेशा एजेंट के मूल ट्रेस से शुरू होता है, इसलिए पेज पर पूर्वानुमानित पुनर्लेखन दिखाने की जगह नहीं है। भविष्यवाणियाँ रन के पेज से, या रन की डायरेक्टरी में artifacts/predictions.jsonl से पढ़ें।

prm-reward से चरण रेटिंग

प्रोसेस रिवॉर्ड मॉडल केवल अंतिम उत्तर के बजाय ट्रेस के चरणों को रेट करता है, जैसा PRM800K में है। prm-reward पूरे ट्रेस को एक इनपुट के रूप में ट्रांसफ़ॉर्मर एनकोडर में देता है, यानी कार्य के बाद Step 1, Step 2 और इसी तरह आगे। एनकोडर हर चरण के आख़िरी टोकन पर तीन-तरफ़ा रेटिंग सीखता है, इसलिए हर रेटिंग उस चरण से पहले के चरणों को देखकर बनती है। जिन चरणों को किसी ने रेट नहीं किया वे लॉस से बाहर रहते हैं। डिफ़ॉल्ट मॉडल answerdotai/ModernBERT-base को उसके 8,192-टोकन संदर्भ के कारण चुना गया था।

लंबे ट्रेस अपने आख़िरी चरण खो देते हैं। max_length टोकन से लंबा ट्रेस अंत से काट दिया जाता है, और कट के बाद के चरणों पर न प्रशिक्षण होता है न रेटिंग। रन का लॉग खोए चरण गिनता है। जब max_length मॉडल की क्षमता से अधिक होता है, तब रन चेतावनी के साथ max_length को मॉडल की सीमा तक घटा देता है, और अधिकतर BERT-श्रेणी के एनकोडर के लिए वह सीमा 512 टोकन है। जब रन का लॉग खोए चरण रिपोर्ट करे, तब max_length बढ़ाएँ और ऐसा मॉडल चुनें जिसका संदर्भ लंबे ट्रेस को समेट सके।

होल्ड-आउट स्कोर step_macro_f1 है, यानी हर रेट किए गए चरण पर तीनों रेटिंग का macro-F1। अधिकतर ट्रेस के अधिकतर चरण सही होते हैं, इसलिए accuracy उस मॉडल को बढ़ा-चढ़ाकर दिखाती जो कभी "गलत" नहीं कहता। रन step_accuracy और first_error_accuracy भी रिपोर्ट करता है, यानी उन ट्रेस का अनुपात जहाँ मॉडल का पहला गलत चरण वही है जो एनोटेटरों का पहला गलत चरण है।

भविष्यवाणी max_length में समाने वाले हर चरण को रेट करती है, हर रेटिंग की प्रायिकता उस रेटिंग का विश्वास होती है और सबसे कम विश्वास वाला चरण ट्रेस का विश्वास। स्कीम के writeback.schemas में होने और ai_prelabel: true के साथ, "AI pre-label steps" बटन प्रशिक्षित रेटिंग एनोटेटर के सत्यापन के लिए देता है। जिस आइटम के पास प्रशिक्षित रेटिंग हैं, उसके लिए ai_support के अंतर्गत कॉन्फ़िगर किया LLM जज नहीं बुलाया जाता। प्रोसेस रिवॉर्ड एनोटेशन स्कीम को समझाता है, और प्रोसेस रिवॉर्ड मॉडल की गाइड डेटा को।

बड़े मॉडल को QLoRA से फ़िट करना

QLoRA बेस मॉडल के वज़न 4 बिट में लोड करता है और उनके ऊपर एक LoRA एडेप्टर प्रशिक्षित करता है। llm-sft, llm-dpo, hf-text-classification, vlm-sft और reward-model lora: {quantize: 4bit} लेते हैं, और prm-reward मॉडल लोड करने से पहले यह सेटिंग अस्वीकार कर देता है। मेमोरी की योजना उस "Peak GPU memory" पंक्ति से बनाएँ जो हर ट्रांसफ़ॉर्मर रन अंत में लॉग करता है। कॉन्फ़िगरेशन संदर्भ का QLoRA अनुभाग बताता है कि बेस वज़न कैसे लोड होते हैं और 8-बिट विकल्प क्या है।

llm-sft के लिए QLoRA को डिफ़ॉल्ट बनाने के लिए ऊपर के config में यह ब्लॉक जोड़ें:

model_training:
  enabled: true
  trainer_params:
    llm-sft:
      model_name: Qwen/Qwen2.5-7B-Instruct
      lora: {quantize: 4bit}
      gradient_checkpointing: true

QLoRA को CUDA GPU और उस मशीन के CUDA के लिए bitsandbytes बिल्ड चाहिए, जो pip install bitsandbytes से इंस्टॉल होता है। चालू GPU या बिल्ड के बिना, रन मॉडल लोड करने से पहले वैलिडेशन पर रुक जाता है।

रन को Hugging Face Hub पर प्रकाशित करना

जिस सफल रन का मॉडल Potato सर्वर पर है, उसके रन के पेज पर Publish to the Hugging Face Hub होता है। पुश मॉडल और रन से लिखा गया README.md मॉडल कार्ड अपलोड करता है, जिसमें ट्रेनर, बेस मॉडल और एडेप्टर, स्कीम और लेबल, स्प्लिट के आकार, होल्ड-आउट स्कोर और स्कोर किस पर मापा गया, और रन तथा बंडल के ID हैं। LoRA रन ने केवल एडेप्टर सहेजा, इसलिए Hub रिपॉज़िटरी में एडेप्टर है, और कार्ड उस बेस मॉडल का नाम देता है जिस पर एडेप्टर लोड करना है।

टोकन ब्राउज़र से बाहर रहता है। अपनी Hugging Face सेटिंग में एक write टोकन बनाएँ और Potato शुरू करने से पहले उसे सर्वर के परिवेश में रखें:

export HF_TOKEN=hf_your_write_token
potato start config.yaml

फ़ॉर्म परिवेश चर का नाम देता है, डिफ़ॉल्ट रूप से HF_TOKEN, रिपॉज़िटरी का नाम दो बार माँगता है, और Private को डिफ़ॉल्ट रूप से चुना हुआ रखता है। Hugging Face Hub पर प्रकाशित करना बताता है कि कौन-सी फ़ाइलें जाती हैं, पुश से पहले कौन-सी जाँचें होती हैं, और मॉडल कार्ड पर कौन-सा लाइसेंस है। API से वही पुश:

curl -X POST -H "X-API-Key: $KEY" -H "Content-Type: application/json" \
  http://localhost:8000/admin/training/api/runs/RUN_ID/push-to-hub \
  -d '{"repo_id": "your-org/support-dpo", "confirm_repo_id": "your-org/support-dpo", "private": true, "licence": "apache-2.0"}'

रूट कमिट के साथ 201 लौटाता है। fetch_artifacts: false के साथ रिमोट होस्ट पर छोड़ा गया मॉडल Potato सर्वर से पुश नहीं किया जा सकता, और रन का पेज बताता है कि मॉडल कहाँ है। प्रकाशित मॉडल से सक्रिय-अधिगम चक्र की ओर बढ़ने के लिए चक्र में मॉडल पर जारी रखें।

आगे पढ़ें

• मॉडल प्रशिक्षण कॉन्फ़िगरेशन: model_training की हर कुंजी, होल्ड-आउट स्कोर, राइट-बैक और रूट।
• ट्रेनर: सभी 38 ट्रेनर, कार्य के अनुसार समूहित।
• रिमोट प्रशिक्षण: ssh पर GPU सर्वर, SLURM क्लस्टर और पोलिंग एजेंट।
• एजेंट ट्रेजेक्टरी एनोटेशन: Potato में ट्रेस डेटा इकट्ठा करना।
• अपस्ट्रीम संदर्भ अनुभाग: llm-sft, llm-dpo, एजेंट ट्रेस, prm-reward, reward-model, QLoRA और Hub पर प्रकाशन।

संदर्भ

• Dettmers, T., Pagnoni, A., Holtzman, A., and Zettlemoyer, L. (2023). QLoRA: Efficient Finetuning of Quantized LLMs. arXiv:2305.14314. arxiv.org/abs/2305.14314
• Hu, E. J., Shen, Y., Wallis, P., Allen-Zhu, Z., Li, Y., Wang, S., Wang, L., and Chen, W. (2021). LoRA: Low-Rank Adaptation of Large Language Models. arXiv:2106.09685. arxiv.org/abs/2106.09685
• Lightman, H., Kosaraju, V., Burda, Y., Edwards, H., Baker, B., Lee, T., Leike, J., Schulman, J., Sutskever, I., and Cobbe, K. (2023). Let's Verify Step by Step. arXiv:2305.20050. arxiv.org/abs/2305.20050
• Ouyang, L., Wu, J., Jiang, X., Almeida, D., Wainwright, C. L., Mishkin, P., Zhang, C., Agarwal, S., Slama, K., Ray, A., Schulman, J., Hilton, J., Kelton, F., Miller, L., Simens, M., Askell, A., Welinder, P., Christiano, P., Leike, J., and Lowe, R. (2022). Training Language Models to Follow Instructions with Human Feedback. arXiv:2203.02155. arxiv.org/abs/2203.02155
• Rafailov, R., Sharma, A., Mitchell, E., Ermon, S., Manning, C. D., and Finn, C. (2023). Direct Preference Optimization: Your Language Model is Secretly a Reward Model. arXiv:2305.18290. arxiv.org/abs/2305.18290