DROP (Discrete Reasoning Over Paragraphs) არის შეფასება, სადაც მოდელებმა უნდა ამოიღონ შესაბამისი ინფორმაცია ინგლისურენოვანი აბზაცებიდან, სანამ მათზე დისკრეტულ მსჯელობის ნაბიჯებს შეასრულებენ (მაგალითად, ელემენტების დალაგება ან დათვლა სწორი პასუხის მისაღებად, იხილეთ ქვემოთ მოცემული ცხრილი მაგალითებისთვის). გამოყენებული მეტრიკაა ინდივიდუალური f1 და ზუსტი შესაბამისობის ქულები. ის Open LLM Leaderboard-ს სამი კვირის წინ დავამატეთ და შევნიშნეთ, რომ წინასწარ გაწვრთნილი მოდელების f1-ქულები მოულოდნელ ტენდენციას აჩვენებდა: როდესაც DROP ქულები შევადარეთ ლიდერბორდის ორიგინალურ საშუალო მაჩვენებელს (ARC, HellaSwag, TruthfulQA და MMLU), რაც მოდელის საერთო შესრულების გონივრული ინდიკატორია, ველოდით, რომ DROP ქულები მასთან კორელაციაში იქნებოდა (უკეთესი მოდელები უკეთეს შედეგს აჩვენებდნენ). თუმცა, ეს მხოლოდ მოდელების მცირე რაოდენობის შემთხვევაში მოხდა, და ყველა დანარჩენს ჰქონდა ძალიან დაბალი DROP f1-ქულა, 10-ზე ქვემოთ. ამ საოცარი ქცევის პირველი სიღრმისეული შესწავლისას, შევნიშნეთ, რომ ნორმალიზაციის ნაბიჯი შესაძლოა არ მუშაობდა ისე, როგორც განზრახული იყო: ზოგიერთ შემთხვევაში, ეს ნორმალიზაცია უგულებელყოფდა სწორ რიცხვით პასუხებს, როდესაც მათ უშუალოდ მოსდევდა სიცარიელის სიმბოლო (whitespace character), გარდა ჩვეულებრივი სიცარიელისა (მაგალითად, ახალი ხაზის სიმბოლო). განვიხილოთ მაგალითი, სადაც გენერაცია არის 10\n\nმონაკვეთი: 2011 წლის აღწერამ დააფიქსირა 1,001,360 მოსახლე, ხოლო სწორი (gold) პასუხი არის 10. ნორმალიზაცია ხდება რამდენიმე ეტაპად, როგორც გენერირებული, ასევე სწორი პასუხისთვის: თუმცა, საერთო ქულა არ გამოითვლება სტრიქონზე, არამედ სტრიქონიდან ამოღებული სიტყვების „ტომარაზე“ (bag of words – BOW), ამ შემთხვევაში {'recorded', 'population', 'passage', 'census', '2011.0', '1001360.0', '10'}, რომელიც შედარებულია სწორი პასუხის BOW-სთან, ასევე ზემოაღნიშნული წესით ნორმალიზებულთან, {10.0}. როგორც ხედავთ, ისინი არ იკვეთებიან, მიუხედავად იმისა, რომ მოდელმა სწორი შედეგი იწინასწარმეტყველა! შეჯამებით, თუ რიცხვს მოსდევს ნებისმიერი სახის სიცარიელის სიმბოლო, გარდა მარტივი სიცარიელისა, ის არ გაივლის რიცხვების ნორმალიზაციას, შესაბამისად, ვერასდროს დაემთხვევა სწორ პასუხს, თუ ისიც რიცხვია! ეს პირველი პრობლემა სავარაუდოდ მნიშვნელოვნად აფუჭებდა ქულებს, მაგრამ ცხადია, რომ ეს არ იყო ერთადერთი ფაქტორი, რომელიც იწვევდა DROP ქულების ასეთ დაბალ მაჩვენებელს. ჩვენ გადავწყვიტეთ, რომ უფრო ღრმად გამოგვეკვლია საკითხი. ჩვენი გამოკვლევების გაფართოებისას, Zeno-ს ჩვენი მეგობრები შემოგვიერთდნენ და შედეგების ბევრად უფრო დეტალური ანალიზი ჩაატარეს, განიხილეს 5 მოდელი, რომლებიც წარმოადგენდნენ იმ პრობლემებს, რაც DROP ქულებში შევნიშნეთ: falcon-180B და mistral-7B მოსალოდნელზე ნაკლებად ეფექტური იყო, Yi-34B და tigerbot-70B-ს ჰქონდათ ძალიან კარგი შესრულება DROP-ზე, რაც კორელაციაში იყო მათ საშუალო ქულებთან, ხოლო facebook/xglm-7.5B შუალედურ პოზიციას იკავებდა. თუ გსურთ, შეგიძლიათ თავად სცადოთ შედეგების ანალიზი Zeno-ს პროექტში! Zeno-ს გუნდმა კიდევ ორი უფრო შემაშფოთებელი მახასიათებელი აღმოაჩინა: ამ ეტაპზე, ჩვენ გვჯეროდა, რომ ორივე წარუმატებლობის მიზეზი ერთი და იგივე ძირეული ფაქტორი იყო: წერტილის (.) გამოყენება, როგორც „გაჩერების ტოკენი“ (stopword token) (გენერაციის დასასრულებლად). ჩვენ ვივარაუდეთ, რომ ორივე ეს პრობლემა შეიძლებოდა გამოსწორებულიყო \n-ის გამოყენებით წერტილის ნაცვლად, როგორც გენერაციის დასასრულებელი „გაჩერების სიტყვა“. ასე რომ, ჩვენ ვცადეთ! ჩვენ გამოვიკვლიეთ \n-ის გამოყენება, როგორც გენერაციის ბოლო ტოკენი ხელმისაწვდომ შედეგებზე. ჩვენ დავყავით გენერირებული პასუხი პირველ \n სიმბოლოზე, თუ ის არსებობდა, და ხელახლა გამოვთვალეთ ქულები. გაითვალისწინეთ, რომ ეს მხოლოდ სწორი შედეგის მიახლოებაა, რადგან ის არ გამოასწორებს პასუხებს, რომლებიც ნაადრევად შეწყდა წერტილზე (მაგალითად, მცოცავმძიმიანი რიცხვები) - მაგრამ ის არცერთ მოდელს არ მისცემს უსამართლო უპირატესობას, რადგან ყველა მათგანზე იმოქმედა ამ პრობლემამ. თუმცა, ეს იყო საუკეთესო, რისი გაკეთებაც შეგვეძლო მოდელების ხელახლა გაშვების გარეშე (რადგან გვინდოდა საზოგადოებისთვის ინფორმაციის რაც შეიძლება მალე მიწოდება). მიღებული შედეგები შემდეგი იყო - \n-ზე დაყოფა ძალიან კარგად კორელაციაშია სხვა ქულებთან და, შესაბამისად, საერთო შესრულებასთან. სწრაფი გაანგარიშება აჩვენებს, რომ ყველა მოდელის სრული შეფასების ხელახლა გაშვება საკმაოდ ძვირი დაჯდებოდა (მთლიან განახლებას დასჭირდა 8 წელი GPU დრო, და მისი დიდი ნაწილი DROP-მა დაიკავა), ჩვენ შევაფასეთ, რა დაჯდებოდა მხოლოდ წარუმატებელი მაგალითების ხელახლა გაშვება. 10% შემთხვევაში, სწორი პასუხი არის მცოცავმძიმიანი რიცხვი (მაგალითად, 12.25) და მოდელის პროგნოზები იწყება სწორი დასაწყისით (ჩვენი მაგალითისთვის, 12), მაგრამ წყდება წერტილზე - ეს პროგნოზები სავარაუდოდ სწორი იქნებოდა, თუ გენერაცია გაგრძელდებოდა. ჩვენ აუცილებლად უნდა გავუშვათ ისინი ხელახლა! ჩვენი შეფასება არ ითვალისწინებს გენერირებულ წინადადებებს, რომლებიც რიცხვით სრულდება და შესაძლოა შეწყვეტილი იყო (დანარჩენი გენერაციების 40%), არც ნორმალიზაციით გაფუჭებულ პროგნოზებს. სწორი შედეგების მისაღებად, ჩვენ დაგვჭირდება მაგალითების 50%-ზე მეტის ხელახლა გაშვება, რაც უზარმაზარი GPU დროს მოითხოვს! ჩვენ უნდა ვიყოთ დარწმუნებულნი, რომ იმპლემენტაცია, რომელსაც ამჯერად გავუშვებთ, სწორი იქნება. EleutherAI-ის ფანტასტიკურ გუნდთან განხილვის შემდეგ (როგორც GitHub-ზე, ასევე შიდა დონეზე), რომლებმაც გვიხელმძღვანელეს კოდის გააზრებაში და დაგვეხმარნენ ჩვენს გამოკვლევებში, ნათელი გახდა, რომ LM Eval Harness-ის იმპლემენტაცია „ოფიციალური DROP“ კოდს ძალიან მკაცრად მიჰყვება: ამ ბენჩმარკის შეფასების ახალი ვერსია უნდა შემუშავდეს!