კოდის გენერაციის მოდელების პერსონალიზაცია: HugCoder-ის შექმნა და თქვენი საკუთარი Copilot-ის შესაძლებლობები
მიუხედავად იმისა, რომ წინასწარ გაწვრთნილი ხელოვნური ინტელექტის მოდელები შთამბეჭდავად მუშაობენ სხვადასხვა ამოცანებში, მომავალი შესაძლებლობა მდგომარეობს კოდის გენერაციის მოდელების კონკრეტულ საჭიროებებზე მორგებაში, რაც ქმნის პერსონალიზებულ კოდირების ასისტენტებს საწარმოო მასშტაბით. ეს ბლოგ-პოსტი წარმოგიდგენთ HugCoder-ს – კოდის დიდ ენობრივ მოდელს (LLM), რომელიც დამატებით გაიწრთვნა Hugging Face-ის GitHub-ის საჯარო რეპოზიტორიებიდან შეგროვებულ კოდის შიგთავსზე. დეტალურად განვიხილავთ მონაცემთა შეგროვების,
თუმცა, მიუხედავად იმისა, რომ ეს წინასწარ გაწვრთნილი მოდელები შთამბეჭდავად მუშაობენ სხვადასხვა ამოცანებში, ჰორიზონტზე ჩანს საინტერესო შესაძლებლობა: კოდის გენერაციის მოდელის თქვენს კონკრეტულ საჭიროებებზე მორგების უნარი. წარმოიდგინეთ პერსონალიზებული კოდირების ასისტენტები, რომელთა გამოყენებაც შესაძლებელია საწარმოო მასშტაბით. ამ ბლოგ-პოსტში ვაჩვენებთ, თუ როგორ შევქმენით HugCoder 🤗 – კოდის დიდი ენობრივი მოდელი (LLM), რომელიც დამატებით გაიწრთვნა huggingface GitHub ორგანიზაციის საჯარო რეპოზიტორიებიდან მიღებულ კოდის შიგთავსზე. ჩვენ განვიხილავთ მონაცემთა შეგროვების პროცესს, ჩვენს სავარჯიშო ექსპერიმენტებს და რამდენიმე საინტერესო შედეგს. ეს მოგცემთ საშუალებას, შექმნათ საკუთარი პერსონალური copilot თქვენი საკუთრების კოდების ბაზაზე. ჩვენ ასევე შემოგთავაზებთ ამ პროექტის რამდენიმე გაფართოებას ექსპერიმენტებისთვის.
დავიწყოთ 🚀 ჩვენი სასურველი მონაცემთა ნაკრები კონცეპტუალურად მარტივია, ჩვენ ის ასე დავაკონკრეტეთ: კოდის შიგთავსის GitHub-იდან გამოთხრა მარტივია Python GitHub API-ის საშუალებით. თუმცა, რეპოზიტორიების რაოდენობისა და რეპოზიტორში არსებული კოდის ფაილების რაოდენობის მიხედვით, შესაძლებელია მარტივად შეგხვდეთ API-ის ლიმიტირების პრობლემები. ამგვარი პრობლემების თავიდან ასაცილებლად, ჩვენ გადავწყვიტეთ, ყველა საჯარო რეპოზიტორია ლოკალურად დაგვეკლონირებინა და მათი შიგთავსი API-ის ნაცვლად, ადგილობრივად ამოგვეღო. ჩვენ გამოვიყენეთ Python-ის multiprocessing მოდული ყველა რეპოს პარალელურად გადმოსაწერად, როგორც ეს გადმოწერის ამ სკრიპტშია ნაჩვენები.
რეპოზიტორია ხშირად შეიძლება შეიცავდეს არაკოდურ ფაილებს, როგორიცაა სურათები, პრეზენტაციები და სხვა აქტივები. ჩვენ არ გვაინტერესებდა მათი გამოთხრა. ჩვენ შევქმენით გაფართოებების სია მათი გასაფილტრად. Jupyter Notebook-ების გარდა სხვა კოდის ფაილების დასამუშავებლად, ჩვენ უბრალოდ გამოვიყენეთ "utf-8" კოდირება. Notebook-ებისთვის, ჩვენ მხოლოდ კოდის უჯრედები განვიხილეთ. ასევე გამოვრიცხეთ ყველა ფაილის გზა, რომელიც უშუალოდ კოდთან არ იყო დაკავშირებული. ესენია: .git, __pycache__, და xcodeproj.
ამ შიგთავსის სერიალიზაციის მეხსიერებისთვის შედარებით ხელსაყრელი შესანარჩუნებლად, ჩვენ გამოვიყენეთ chunking და feather ფორმატი. სრული იმპლემენტაციისთვის იხილეთ ეს სკრიპტი. საბოლოო მონაცემთა ნაკრები ხელმისაწვდომია Hub-ზე და ის ასე გამოიყურება: ამ ბლოგისთვის ჩვენ განვიხილეთ Hugging Face-ის ყველაზე რეიტინგული 10 საჯარო რეპოზიტორია, stargazers-ის მიხედვით. ისინი შემდეგია: ['transformers', 'pytorch-image-models', 'datasets', 'diffusers', 'peft', 'tokenizers', 'accelerate', 'text-generation-inference', 'chat-ui', 'deep-rl-class']. ეს არის კოდი, რომელიც გამოვიყენეთ ამ მონაცემთა ნაკრების გენერირებისთვის, და ეს არის მონაცემთა ნაკრები Hub-ზე. აი, როგორ გამოიყურება მისი სკრინშოტი:
პროექტის სირთულის შესამცირებლად, ჩვენ არ განვიხილეთ მონაცემთა ნაკრების დედუპლიკაცია. თუ დაინტერესებული ხართ დედუპლიკაციის ტექნიკების გამოყენებით საწარმოო აპლიკაციისთვის, ეს ბლოგ-პოსტი შესანიშნავი რესურსია ამ თემაზე კოდის LLM-ების კონტექსტში.
ამ სექციაში ვაჩვენებთ, თუ როგორ უნდა დავაზუსტოთ შემდეგი მოდელები: bigcode/starcoder (15.5B პარამეტრი), bigcode/starcoderbase-1b (1B პარამეტრი), Deci/DeciCoder-1b (1B პარამეტრი). ყველა ექსპერიმენტისთვის გამოვიყენებთ ერთ A100 40GB Colab Notebook-ს 🤗 PEFT (Parameter-Efficient Fine-Tuning) გამოყენებით. გარდა ამისა, ვაჩვენებთ, თუ როგორ უნდა სრულად დავაზუსტოთ bigcode/starcoder (15.5B პარამეტრი) მანქანაზე 8 A100 80GB GPU-ით, 🤗 Accelerate-ის FSDP ინტეგრაციის გამოყენებით. ვარჯიშის მიზანია შუა ნაწილის შევსება (FIM), რა დროსაც სავარჯიშო თანმიმდევრობის ნაწილები გადადის ბოლოში, ხოლო გადაწყობილი თანმიმდევრობა პროგნოზირდება ავტორეგრესიულად. რატომ PEFT? სრული დაზუსტება ძვირია. მოდით, რამდენიმე ციფრი განვიხილოთ პერსპექტივისთვის: მინიმალური GPU მეხსიერება, რომელიც საჭიროა სრული დაზუსტებისთვის: ვინაიდან აპარატურული მოთხოვნები უზარმაზარია, ჩვენ გამოვიყენებთ პარამეტრულად ეფექტურ დაზუსტებას QLoRA-ის გამოყენებით. წარმოგიდგენთ მინიმალურ GPU მეხსიერების მოთხოვნებს StarCoder-ის დასაზუსტებლად QLoRA-ის გამოყენებით: trainable params: 110,428,160 || all params: 15,627,884,544 || trainable%: 0.7066097761926236. ზემოთ მოცემულ გამოთვლებში, ჩვენ არ გავითვალისწინეთ შუალედური აქტივაციის შემოწმებისთვის საჭირო მეხსიერება, რომელიც მნიშვნელოვნად დიდია. ამ პრობლემის გადასაჭრელად ჩვენ გამოვიყენეთ Flash Attention V2 და Gradient Checkpointing. გთხოვთ, იხილოთ model-memory-usage, რათა მარტივად გამოთვალოთ, რამდენი vRAM არის საჭირო დიდი მოდელის მოსამზადებლად და ინფერენსისთვის 🤗 Hugging Face Hub-ზე. ჩვენ განვიხილავთ, თუ როგორ უნდა სრულად დავაზუსტოთ bigcode/starcoder (15B პარამეტრი) 8 A100 80GB GPU-ზე PyTorch Fully Sharded Data Parallel (FSDP) ტექნიკის გამოყენებით. FSDP-ის შესახებ დამატებითი ინფორმაციისთვის იხილეთ Fine-tuning Llama 2 70B using PyTorch FSDP და Accelerate Large Model Training using PyTorch Fully Sharded Data Parallel.
რესურსები: ვარჯიშის დასაწყებად ბრძანება მოცემულია run_fsdp.sh-ში. ვარჯიშის საერთო დრო იყო 9 საათი. Lambdalabs-ის მიხედვით, 8x A100 80GB GPU-ის საათობრივი ღირებულება $12.00-ია, შესაბამისად, საერთო ღირებულება $108 იქნება. ჩვენ განვიხილავთ, თუ როგორ გამოვიყენოთ QLoRA bigcode/starcoder (15B პარამეტრი) მოდელის დასაზუსტებლად ერთ A100 40GB GPU-ზე 🤗 PEFT-ის გამოყენებით. QLoRA-ისა და PEFT მეთოდების შესახებ დამატებითი ინფორმაციისთვის, გთხოვთ, იხილოთ Making LLMs even more accessible with bitsandbytes, 4-bit quantization and QLoRA და 🤗 PEFT: Parameter-Efficient Fine-Tuning of Billion-Scale Models on Low-Resource Hardware.
თეგები:
#ხელოვნური ინტელექტი
#llm
#მანქანური სწავლება
#copilot
#კოდის გენერაცია
#hugging face
#fsdp
#qlora
#peft
#github
#fine-tuning
წყარო: huggingface.co
AI-ით გადამუშავებული