ეს განვიხილეთ ჩვენს მეგობრებთან Dottxt-დან, რომლებსაც გაუჩნდათ იდეა – რა მოხდებოდა, თუ არსებობდა გზა, რათა გაგვეზარდა თანმიმდევრულობა მოთხოვნის (prompt) ფორმატებს შორის? მოდით, ჩავუღრმავდეთ! სულ უფრო ნათელი ხდება, რომ დიდი ენობრივი მოდელების (LLM) საორიენტაციო შესრულება მჭიდროდ, და გარკვეულწილად გასაკვირადაც, დამოკიდებულია თავად მოთხოვნის ფორმატზე, მიუხედავად იმისა, რომ წლების განმავლობაში შემოღებულ იქნა მრავალი მეთოდი მოთხოვნასთან დაკავშირებული ვარიაციის შესამცირებლად. მაგალითად, როდესაც მოდელებს ვაფასებთ „few-shot“ რეჟიმში, ჩვენ ვაწვდით ფორმატის მაგალითებს მოდელს, რათა აიძულოს კონკრეტული შაბლონის დაცვა გამოსავალში; როდესაც შევადარებთ სავარაუდო პასუხების ლოგარითმულ ალბათობას თავისუფალი ფორმის გენერაციის ნაცვლად, ვცდილობთ შევზღუდოთ პასუხების სივრცე. „Leaderboards and Evals“ გუნდმა ამის დემონსტრირება მოახდინა ცნობილი ამოცანის, MMLU-ის, 8 განსხვავებული მოთხოვნის ფორმატის განხილვით (ამოცანის 4 ქვეჯგუფი იქნა შესწავლილი). ეს მოთხოვნის ვარიაციები მიეწოდა 5 სხვადასხვა მოდელს (შერჩეული იმიტომ, რომ ისინი იმ დროისთვის SOTA იყვნენ თავიანთი ზომისთვის და მოიცავდნენ ტოკენიზაციისა და ენების მრავალფეროვნებას). ქულები გამოითვალა ლოგარითმული ალბათობის შეფასების გამოყენებით, სადაც ყველაზე სავარაუდო პასუხი სწორად ითვლებოდა, რაც მრავალარჩევანი ამოცანებისთვის კლასიკური მეტრიკაა. მოდით, უფრო დეტალურად განვიხილოთ სხვადასხვა ფორმატი, MMLU-ის global_facts ქვეჯგუფის პირველი შეკითხვის გამოყენებით. მოთხოვნები შეიცავს მხოლოდ შეკითხვას, ან რაიმე ტეგებს, რათა მიუთითებდეს, რომ საქმე გვაქვს კითხვა-პასუხის ფორმატთან, და შესაძლოა, არჩევანის ვარიანტებსაც მოთხოვნაში. ყველა შემთხვევაში, შეფასებები ადარებს მხოლოდ შესაძლო არჩევანის ლოგარითმულ ალბათობას. ყველა ეს ფორმატი გვხვდება შეფასების ლიტერატურაში და თითქმის იგივე რაოდენობის ინფორმაციას უნდა შეიცავდეს თითოეულ რიგში. თუმცა, ქვემოთ ხედავთ შესრულების ფართო ვარიაციას ამ თეორიულად ზედაპირული ცვლილებების მიხედვით! თითოეული მოდელის შესრულება დაახლოებით 10 ქულით იცვლება, ყველაზე ექსტრემალური მაგალითის, Qwen1.5-7B-ის გარდა, რომლის სიზუსტე მე-7 მოთხოვნის ვარიაციით (ძირითადად ტოკენიზატორის პრობლემის გამო) 22.9%-მდე დაეცა, მაშინ როცა არსებითად იგივე ინფორმაციით მან 51.2%-მდე სიზუსტე აჩვენა სხვა მოთხოვნით. იზოლირებულად, ქულის ცვლილება აუცილებლად დიდი პრობლემა არ არის, სანამ რეიტინგი თანმიმდევრულია. თუმცა, როგორც შემდეგ დიაგრამაზე ვხედავთ, რეიტინგზე გავლენას ახდენს ეს ცვლილებები: არცერთი მოდელი არ ინარჩუნებს თანმიმდევრულ რეიტინგს სხვადასხვა მოთხოვნაში, მიუხედავად იმისა, რომ ერთადერთი განსხვავება მათ ფორმატშია და არა თავად ინფორმაციაში. ეს ნიშნავს, რომ თუ Gemma-7b-ის ავტორებს სურდათ ეჩვენებინათ, რომ მათი მოდელი Mistral-7B-v0.1-ზე უკეთესი იყო, მათ შეეძლოთ ამის გაკეთება უბრალოდ სწორი მოთხოვნის არჩევით. ვინაიდან თითქმის არავინ აცხადებს მათი შეფასების ზუსტ პარამეტრებს, ისტორიულად ასეც ხდებოდა მოდელების ანგარიშებში, სადაც ავტორები ირჩევდნენ თავიანთი მოდელისთვის ყველაზე ხელსაყრელი პარამეტრების მოხსენებას (ამიტომაც ზოგიერთ ნაშრომში იხილავთ „few-shot“ მეთოდის უცნაურ მაჩვენებლებს). თუმცა, ეს არ არის მოდელის ქულებში ვარიაციის ერთადერთი წყარო. გაფართოებულ ექსპერიმენტებში, ჩვენ შევადარეთ ერთი და იგივე მოდელების შეფასება, ერთი და იგივე მოთხოვნის ფორმატებით, ზუსტად იგივე „few-shot“ ნიმუშების გამოყენებით, რომლებიც განსხვავებულად იყო არეული მოთხოვნამდე (მაგალითად, A/B/C/D/E მოთხოვნა C/D/A/B/E მოთხოვნის წინააღმდეგ). შემდეგი სურათი გვიჩვენებს მოდელის ქულების დელტას ამ ორ „few-shot“ თანმიმდევრობას შორის: ჩვენ ვაკვირდებით 3 ქულამდე სხვაობას შესრულებაში იგივე მოდელ/მოთხოვნის კომბინაციისთვის! თუ გვინდა, რომ სწორად შევაფასოთ და შევადაროთ სხვადასხვა მოდელები, გვჭირდება გზა ამ გამოწვევის დასაძლევად. სკლარის და სხვების ნაშრომი „ენობრივი მოდელების მგრძნობელობის რაოდენობრივი შეფასება ყალბი მახასიათებლების მიმართ მოთხოვნის დიზაინში“ ასევე კარგ მიმოხილვას იძლევა ამ საკითხის შესახებ, და ავტორები წარმოადგენენ FormatSpread-ს, პროგრამულ ინსტრუმენტს, რომელიც აფასებს თითოეულ მოდელს ფორმატების მრავალი სხვადასხვა ვარიაციით, შემდეგ კი ითვლის ამ მოდელის შესრულების ვარიაციას. ასეთი გადაწყვეტილებები საშუალებას გვაძლევს უფრო მეტი ნდობით განვსაზღვროთ, რომელი მოდელებია სხვებზე უკეთესი, მაგრამ მათ მაღალი გამოთვლითი ხარჯები ახლავს თან. მიუხედავად იმისა, რომ FormatSpread შესანიშნავი მცდელობაა ლიდერთა დაფების უფრო სამართლიანი და პატიოსანი გახადოს, ის რაც ჩვენ ნამდვილად გვინდა LLM-ების პრაქტიკულ მომხმარებლებს, არის მოთხოვნის თანმიმდევრულობა. ანუ, გვსურს ვიპოვოთ რაიმე გზა მოთხოვნებს შორის ამ ვარიაციის შესამცირებლად. .txt-ზე ჩვენ ვამახვილებთ ყურადღებას სტრუქტურირებული გენერაციის გაუმჯობესებასა და უკეთ გაგებაზე, რაც გულისხმობს, რომ მოდელის გამოსავალი შეზღუდულია კონკრეტული სტრუქტურის დასაცავად. ჩვენი ბიბლიოთეკა, Outlines, საშუალებას გვაძლევს მოვახდინოთ LLM-ის გამოსავლის სტრუქტურირება რეგულარული გამოსახულების ან კონტექსტისგან თავისუფალი გრამატიკის განსაზღვრით (მაგალითებს ქვემოთ მოვიყვანთ). სტრუქტურირებული გენერაციის ჩვენი საწყისი გამოყენების შემთხვევა იყო LLM-ებთან პროგრამული ურთიერთქმედების გამარტივება, JSON ფორმატით ზუსტი პასუხების უზრუნველყოფით. თუმცა, ჩვენ მუდმივად გვაოცებდა სტრუქტურირებული გენერაციის სხვა სარგებელი, რომელიც აღმოვაჩინეთ. ადრეულ კვლევებში, რომლებიც სტრუქტურირებული გენერაციის უპირატესობებს იკვლევდნენ, ჩვენ ვაჩვენეთ, რომ სტრუქტურირებული გენერაცია თანმიმდევრულად აუმჯობესებს ბენჩმარკის შესრულებას, და საინტერესო „edge case“ აღმოვაჩინეთ JSON სტრუქტურირებული მოთხოვნების კვლევისას. უმეტეს შემთხვევაში, მოთხოვნის