Florence მხარს უჭერს მრავალ ამოცანას ყუთიდანვე: წარწერების გენერირება, ობიექტების ამოცნობა, OCR და სხვა. თუმცა, შესაძლოა თქვენი ამოცანა ან დომენი არ იყოს მხარდაჭერილი, ან გსურდეთ მოდელის გამოსავლის უკეთ კონტროლი თქვენი ამოცანისთვის. სწორედ მაშინ დაგჭირდებათ მოდელის დახვეწა (fine-tuning). ამ პოსტში ჩვენ ვაჩვენებთ Florence-ის DocVQA-ზე დახვეწის მაგალითს. ავტორები აცხადებენ, რომ Florence 2-ს შეუძლია ვიზუალურ კითხვა-პასუხზე (VQA) მუშაობა, მაგრამ გამოშვებული მოდელები არ მოიცავს VQA შესაძლებლობას. ვნახოთ, რისი გაკეთება შეგვიძლია! Florence-2-ის არქიტექტურა მიუხედავად იმისა, თუ რომელი კომპიუტერული ხედვის ამოცანა სრულდება, Florence-2 პრობლემას განიხილავს, როგორც თანმიმდევრობიდან-თანმიმდევრობაზე (sequence-to-sequence) ამოცანას. Florence-2 იღებს გამოსახულებას და ტექსტს შეყვანად და წარმოქმნის ტექსტს გამოსავლად. მოდელს მარტივი სტრუქტურა აქვს. ის იყენებს DaViT-ის ვიზუალურ ენკოდერს გამოსახულებების ვიზუალურ ემბედინგებად გადასაყვანად, ხოლო BERT-ს ტექსტური მითითებების (prompts) ტექსტურ და მდებარეობის ემბედინგებად გადასაყვანად. მიღებული ემბედინგები შემდეგ მუშავდება სტანდარტული ენკოდერ-დეკოდერ ტრანსფორმერის არქიტექტურით, რომელიც წარმოქმნის ტექსტურ და მდებარეობის ტოკენებს. Florence-2-ის ძალა მისი არქიტექტურიდან კი არ მოდის, არამედ იმ მასიური მონაცემთა ნაკრებიდან, რომელზეც ის წინასწარ იყო გაწვრთნილი. ავტორებმა აღნიშნეს, რომ წამყვანი კომპიუტერული ხედვის მონაცემთა ნაკრებები, როგორც წესი, შეიცავს შეზღუდულ ინფორმაციას – WIT მხოლოდ სურათი/წარწერის წყვილებს მოიცავს, SA-1B კი მხოლოდ სურათებსა და მათთან დაკავშირებულ სეგმენტაციის ნიღბებს. ამიტომ, მათ გადაწყვიტეს შეექმნათ ახალი FLD-5B მონაცემთა ნაკრები, რომელიც შეიცავდა ინფორმაციის ფართო სპექტრს თითოეული გამოსახულების შესახებ – ყუთები, ნიღბები, წარწერები და დამიწება (grounding). მონაცემთა ნაკრების შექმნის პროცესი ძირითადად ავტომატიზებული იყო. ავტორებმა გამოიყენეს მზა, კონკრეტული ამოცანებისთვის განკუთვნილი მოდელები და ჰევრისტიკისა და ხარისხის შემოწმების წესების ნაკრები მიღებული შედეგების გასაწმენდად. შედეგი იყო ახალი მონაცემთა ნაკრები, რომელიც შეიცავდა 5 მილიარდზე მეტ ანოტაციას 126 მილიონი გამოსახულებისთვის, რაც გამოყენებულ იქნა Florence-2 მოდელის წინასწარ გასაწვრთნელად. ჩვენ ექსპერიმენტები ჩავატარეთ სხვადასხვა მეთოდით VQA (ვიზუალურ კითხვა-პასუხზე) რეაგირებისთვის მოდელის ადაპტირებისთვის. ყველაზე ეფექტური მიდგომა, რომელიც ვიპოვეთ, იყო რეგიონიდან-აღწერამდე მითითება (region-to-description prompting), თუმცა ის სრულად არ შეესაბამება VQA ამოცანებს. წარწერების გენერაცია იძლევა აღწერით ინფორმაციას გამოსახულების შესახებ, მაგრამ არ იძლევა კითხვების უშუალო შეყვანის საშუალებას. ჩვენ ასევე გამოვცადეთ რამდენიმე „არამხარდაჭერილი“ მითითება, როგორიცაა „“, „“ და „“. სამწუხაროდ, ამ მცდელობებმა გამოუსადეგარი შედეგები გამოიღო. ჩვენ ვზომავთ შესრულებას ლევენშტეინის მსგავსების გამოყენებით, რაც DocVQA მონაცემთა ნაკრების სტანდარტული მეტრიკაა. დახვეწამდე, მოდელის პროგნოზებსა და ვალიდაციის მონაცემთა ნაკრების ჭეშმარიტ მნიშვნელობებს შორის მსგავსება 0 იყო, რადგან გამოსავალი არ იყო ახლოს ჭეშმარიტებასთან. ტრენინგის ნაკრებით შვიდი ეპოქის განმავლობაში დახვეწის შემდეგ, ვალიდაციის ნაკრებზე მსგავსების ქულა გაუმჯობესდა და 57.0 შეადგინა. ჩვენ შევქმენით 🤗 სივრცე დახვეწილი მოდელის დემონსტრირებისთვის. მიუხედავად იმისა, რომ მოდელი კარგად მუშაობს DocVQA-სთვის, ზოგადი დოკუმენტის გაგების კუთხით ჯერ კიდევ არის გასაუმჯობესებელი. თუმცა, ის წარმატებით ასრულებს ამოცანებს, რაც Florence-2-ის პოტენციალს აჩვენებს ქვედა დონის ამოცანებზე (downstream tasks) დახვეწისთვის. გამორჩეული VQA მოდელის შესაქმნელად, ჩვენ გირჩევთ Florence-2-ის შემდგომ დახვეწას The Cauldron-ის გამოყენებით. საჭირო კოდი უკვე განთავსებულია ჩვენს GitHub გვერდზე. მყარი მაგალითის მოსაყვანად, ქვემოთ მოცემულია ორი ინფერენციის შედეგი დახვეწამდე და დახვეწის შემდეგ. მოდელის გამოცდა აქაც შეგიძლიათ. დახვეწამდე და დახვეწის შემდეგ წინასწარი გაწვრთნისთვის, ავტორებმა გამოიყენეს 2048-იანი batch ზომა საბაზო მოდელისთვის და 3072-იანი დიდი მოდელისთვის. ისინი ასევე აღწერენ შესრულების გაუმჯობესებას დახვეწისას გაუყინავი გამოსახულების ენკოდერით, მის გაყინვასთან შედარებით. ჩვენი ექსპერიმენტები ჩავატარეთ გაცილებით დაბალი რესურსების პირობებში, რათა შეგვესწავლა, თუ რისი უნარი ექნებოდა მოდელს უფრო შეზღუდულ დახვეწის გარემოში. ჩვენ გავყინეთ ვიზუალური ენკოდერი და გამოვიყენეთ 6-იანი batch ზომა ერთ A100 GPU-ზე Colab-ში, ან 1-იანი batch ზომა T4-ზე. პარალელურად, ჩვენ ჩავატარეთ ექსპერიმენტი მეტი რესურსით, დავხვეწეთ მთელი მოდელი 64-იანი batch ზომით. ეს ტრენინგის პროცესი 70 წუთი გაგრძელდა 8 H100 GPU-ით აღჭურვილ კლასტერზე. ეს გაწვრთნილი მოდელი შეგიძლიათ იპოვოთ აქ. ყველა შემთხვევაში, ჩვენ აღმოვაჩინეთ, რომ მცირე სწავლის სიჩქარე 1e-6 სასარგებლო იყო ტრენინგისთვის. უფრო დიდი სწავლის სიჩქარით მოდელი სწრაფად გადაიტვირთება ტრენინგის ნაკრებზე (overfit). თუ გსურთ მიჰყვეთ პროცესს, ჩვენი Colab დახვეწის ნოუთბუქი შეგიძლიათ იპოვოთ აქ DocVQA მონაცემთა ნაკრების კონტროლური წერტილით. დავიწყოთ დამოკიდებულებების ინსტალაციით. ჩავტვირთოთ DocVQA მონაცემთა ნაკრები Hugging Face Hub-დან. მოდელისა და პროცესორის ჩატვირთვა შეგვიძლია AutoModelForCausalLM და AutoProcessor კლასების გამოყენებით transformers ბიბლიოთეკიდან. ჩვენ უნდა გადავცეთ trust_remote_code=True, რადგან მოდელი იყენებს საბაჟო კოდს – ის ჯერ არ არის ინტეგრირებული transformers-ში. ასევე გავყინავთ ვიზუალურ ენკოდერს, რათა დახვეწა ნაკლებად ძვირი იყოს. ახლა დავხვეწოთ მოდელი! ჩვენ ავაშენებთ PyTorch Dataset-ს, რომელშიც თითოეულ კითხვას დავუმატებთ პრეფიქსს მონაცემთა ნაკრებიდან. ახლა ავაშენებთ მონაცემთა შემგროვებელს (data collator), რომელიც აგებს საწვრთნელ batches-ს მონაცემთა ნაკრების ნიმუშებიდან და დავიწყებთ ტრენინგს. A100-ში 40GB მეხსიერებით, შეგვიძლია