მე არ ვარ დაინტერესებული, რომ LLM-ებმა გადაჭრან დიდი პრობლემები, პირიქით. მინდა, რომ მათ შეასრულონ რუტინული სამუშაო, და თუ პირველივე ცდაზე ვერ შეძლებენ სწორად შესრულებას, მოკლე ინგლისური წინადადება საკმარისი უნდა იყოს მის გამოსასწორებლად. მოკლედ, მინდა ასისტენტი, როგორც ძველ სამეცნიერო-ფანტასტიკურ ფილმებში არსებული კომპიუტერები, ოღონდ „ბოდიში დეივ, მეშინია, ამას ვერ გავაკეთებ“ ნაწილის გარეშე 😅. ეს ნაშრომი იკვლევს ასეთ ხელსაწყოს კოდირებისთვის. თუ არ გავითვალისწინებთ შემოქმედებითი სათაურის პრეტენზიას (არა, AI ჯერ არ ამარცხებს Kaggle-ის გრანდმასტერებს), ნაშრომის ავტორებმა ხელით დაყვეს Kaggle-ის სხვადასხვა პრობლემა მიკრო-ამოცანებად, LLM-ს შეაქმნევინეს მათთვის კოდი და იმეორებდნენ პროცესს მანამ, სანამ ერთეული ტესტები არ ჩაივლიდა. მაგალითად, გამოსახულების კლასიფიკაციის პრობლემისას, მიკრო-ამოცანა შეიძლება იყოს: „შეარჩიეთ შეყვანის მონაცემების ფორმატი და გადააკეთეთ ის CSV ფორმატში, სვეტებით 'id', 'image_filename' და 'class'“. მე მომწონს ეს მიდგომა, რადგან ასე მინდა ვიმუშაო ჩემს პროექტებზე AI-სთან მომავალში. AI-ს შევაქმნევინო კოდის მოსაწყენი ნაწილები, როგორიცაა მონაცემების გადაფორმატება, რათა მე კონცენტრირება მოვახდინო საინტერესო ნაწილებზე: პრობლემის სწორად ჩამოყალიბებაზე და იმ ნაბიჯების შემუშავებაზე, რომლებიც გადაწყვეტამდე მიგვიყვანს. მაგრამ ამ ინტერაქტიულ კოდირების ასისტენტს უნდა შეეძლოს ინგლისურ ენაზე უკუკავშირის მოსმენა და შეცდომების გამოსწორება მის კოდში. LLM-ის უნარით, ინფორმაცია გამოიტანოს ცოდნიდან და კონტექსტიდან, ეს შეიძლება იყოს ძალიან ეფექტური კომპიუტერული ინტერფეისი. მაგრამ თუ LLM-ის უცნაურობები, როგორიცაა ჰალუცინაციები ან ფორმალური ლოგიკის ნაკლებობა, ხელს შეუშლის, შესაძლოა, „ხელოვნური სისულელე“ მივიღოთ, ვიდრე AI. ამიტომ გადავწყვიტე მცირე ტესტის ჩატარება დღევანდელ LLM-ებთან. ზედმეტად გამარტივებული ტესტი, რათა მენახა, რამდენად ეფექტურად ასწორებენ LLM-ები თავიანთ შეცდომებს, როდესაც მათზე მიუთითებ. აქ მოცემულია სცენარი: სისტემის მოთხოვნა: თქვენ ხართ დამხმარე ხმოვანი ასისტენტი მობილურ მოწყობილობაზე. თქვენი სამუშაოა მომხმარებლის მოთხოვნების თარგმნა API ზარებად ამ Python API-ის გამოყენებით: შეგიძლიათ გამოიყენოთ 30 წუთი, როგორც ნაგულისხმევი ხანგრძლივობა ახალი მოვლენებისთვის. უპასუხეთ ყველა მოთხოვნას ერთი ხაზის შესრულებადი კოდით. სულ ეს არის. ძალიან მარტივია, მაგრამ შეუძლიათ თუ არა LLM-ებს ამის მართვა? და როდესაც შეცდომას დაუშვებენ, შეგიძლიათ უბრალოდ უთხრათ, რა არის ეს და ელოდოთ გამოსწორებას? ამის შესამოწმებლად მჭირდებოდა გარემო, რათა ერთდროულად სწრაფად მემუშავა მრავალ ჩეთბოტთან; აი, როგორ მოვაწყე ის. ამ სცენარით ექსპერიმენტის ჩასატარებლად, მინდოდა ერთდროულად ორი საუბრის ჩატარება, სხვადასხვა LLM-თან, და ერთი მხარის შეჩერება, სანამ მეორეს ვთხოვდი შეცდომის გამოსწორებას მის გამოსავალში. აი, როგორ გამოიყურება ის. ის აგებულია Gradio-თი Spaces-ზე და იყენებს Keras-ს, JAX-ს და TPUs-ს. რამდენიმე შენიშვნა იმის შესახებ, თუ როგორ აშენდა ეს, სანამ დავუბრუნდებით LLM-ებთან საუბრის სერიოზულ საკითხს. მათი სწრაფი ინფერენციისა და დიდი მეხსიერებისთვის. TPU v5e 2x4-ს აქვს 8 ბირთვი და 16 GB ოპერატიული მეხსიერება თითო ბირთვზე, ჯამში 128 GB მეხსიერება. ამდენი მეხსიერებით, ჩვენ შეგვიძლია ერთდროულად ჩავტვირთოთ მრავალი LLM, იმ პირობით, რომ მათ დავანაწილებთ (shard) ყველა ბირთვზე, და თავისუფლად გადავერთვებით მათ შორის UI-ში. ამ ექსპერიმენტში, მე შევძელი ხუთი დაახლოებით 8 მილიარდი პარამეტრის მოდელის (კიდევ ერთი OOM-ს გამოიწვევდა) და სამი დაახლოებით 2 მილიარდი პარამეტრის მოდელის ჩატვირთვა, ჯამში 7 LLM ერთდროულად მეხსიერებაში, bfloat16 ფორმატში. JAX არის სასურველი ML გარემო TPUs-ისთვის, მისი მძლავრი XLA კომპაილერის წყალობით. Keras, რომელიც ახლა მშობლიურად მუშაობს JAX-ზე (ასევე PyTorch-სა და TensorFlow-ზე), არის ჩემი საყვარელი მოდელირების გარემო და მას აქვს წინასწარ გაწვრთნილი LLM-ების კარგი არჩევანი მის და-ბიბლიოთეკაში KerasHub-ში. მას შეუძლია Hugging Face-დან არჩეული არაკერას ჩექპოინტების ჩატვირთვაც კი, რაც სასარგებლო იქნება შედარებისთვის. ამის შესახებ ადრე აქ დავწერე: Llama 3.2 Keras-ში. Keras-ს იმიტომაც ვიყენებ, რომ მას აქვს მოდელის პარალელიზმისთვის ყველაზე მოსახერხებელი API. აქ მინდოდა რაც შეიძლება მეტი მოდელის ჩატვირთვა TPU მეხსიერებაში ერთდროულად. ამისთვის, მოდელი უნდა დაიშალოს (shard) ყველა 8 TPU ბირთვის მეხსიერებაზე. საბედნიეროდ, მათი უმეტესობა ნაგულისხმევი განლაგების რუკით მოდის, რომელიც ზუსტად ამას აკეთებს. მაგალითად: სრული ჩატვირთვის კოდისთვის და მოდელის პარალელიზმის შესახებ დამატებითი ინფორმაციისთვის, იხილეთ ჩემი წინა პოსტი აქ. იმ პოსტში ასევე ნახავთ კოდის ნაწილს, რომელიც ვიზუალურად აჩვენებს ფაქტობრივად გამოყენებულ შარდინგს მოდელის ჩატვირთვის შემდეგ. ძალიან სასარგებლოა დებაგინგისთვის. და დიახ, დებაგინგი და რამდენიმე განლაგების რუკის კორექტირება აუცილებელი იყო. ამ ექსპერიმენტისთვის, მე ავირჩიე 10 მილიარდ პარამეტრზე ნაკლები LLM-ები, ძირითადად მათი პრაქტიკულობის გამო, რადგან ბევრი მათგანის ერთდროულად ჩატვირთვა შეიძლებოდა. მაგრამ ასევე, ექსპერიმენტი საკმაოდ მარტივ რამეს ამოწმებს და უნდა იყოს ამ უფრო მცირე მოდელების მიღწევადობის ფარგლებში. ყველა მოდელი ინსტრუქციებზეა მორგებული (instruction-tuned), რათა დიალოგი შესაძლებელი იყოს. მათი ჩეთის შაბლონები შეგიძლიათ ნახოთ დემოს იმპლემენტაციაში. თავისუფლად შეგიძლიათ დააკოპიროთ და ჩასვათ კოდი თქვენი Keras ჩეთბოტის საჭიროებებისთვის. მოდელები არის Gemma, Llama3, Mistral და Vicuna ოჯახებიდან. იხილეთ შედეგების ცხრილები ქვემოთ.