აქამდე, Hub-ზე ძიება ამ ინტერფეისის მეშვეობით საკმაოდ რთული იყო და მომხმარებელს მრავალი ასპექტის „უბრალოდ ცოდნა“ და მიჩვევა უწევდა. ამ სტატიაში განვიხილავთ `huggingface_hub`-ში დამატებულ რამდენიმე საინტერესო ახალ ფუნქციას, რომლებიც ამ ბარიერს ამცირებს და მომხმარებლებს მეგობრულ API-ს სთავაზობს სასურველი მოდელებისა და მონაცემთა ნაკრებების მოსაძებნად, ისე რომ არ დასჭირდეთ Jupyter-ის ან Python-ის ინტერფეისების დატოვება. სანამ დავიწყებთ, თუ თქვენს სისტემაში არ გაქვთ `huggingface_hub` ბიბლიოთეკის უახლესი ვერსია, გთხოვთ, გაუშვით შემდეგი უჯრა (cell): პირველ რიგში, წარმოვიდგინოთ თქვენი სცენარი. გსურთ იპოვოთ Hugging Face Hub-ზე განთავსებული ყველა მოდელი ტექსტის კლასიფიკაციისთვის, რომლებიც GLUE მონაცემთა ნაკრებზე იყო გაწვრთნილი და თავსებადია PyTorch-თან. შეგიძლიათ უბრალოდ გახსნათ https://huggingface.co/models და გამოიყენოთ იქ არსებული ვიჯეტები. თუმცა, ეს მოითხოვს თქვენი IDE-ს დატოვებას და შედეგების დათვალიერებას, რაც რამდენიმე ღილაკზე დაჭერას გულისხმობს სასურველი ინფორმაციის მისაღებად. რა მოხდება, თუ ამ პრობლემის გადაჭრა შესაძლებელი იქნება თქვენი IDE-ს დატოვების გარეშე? პროგრამული ინტერფეისის საშუალებით, ასევე ადვილი იქნება ამის ინტეგრირება Hub-ის შესასწავლად განკუთვნილ სამუშაო პროცესებში. სწორედ აქ შემოდის `huggingface_hub`. ბიბლიოთეკასთან ნაცნობი პირებისთვის, შესაძლოა უკვე იცოდეთ, რომ ასეთი ტიპის მოდელების ძიება შესაძლებელია. თუმცა, სწორი მოთხოვნის მიღება ცდისა და შეცდომის მტკივნეული პროცესია. შეგვიძლია თუ არა ამის გამარტივება? მოდით, გავარკვიოთ! პირველ რიგში, იმპორტს გავაკეთებთ `HfApi`-ის, რომელიც არის კლასი, რომელიც გვეხმარება Hugging Face-ის ბექენდ ჰოსტინგთან ურთიერთობაში. მისი მეშვეობით შეგვიძლია მოდელებთან, მონაცემთა ნაკრებებთან და სხვა ელემენტებთან ურთიერთქმედება. ამასთან ერთად, იმპორტს გავაკეთებთ რამდენიმე დამხმარე კლასის: `ModelFilter` და `ModelSearchArguments`. ეს ორი კლასი დაგვეხმარება ზემოთ მოცემული პრობლემის გადაწყვეტაში. `ModelSearchArguments` კლასი არის namespace-ის მსგავსი, რომელიც შეიცავს ყველა მოქმედ პარამეტრს, რომლითაც შეგვიძლია ძიება! მოდით, გადავხედოთ: ჩვენ შეგვიძლია დავინახოთ მრავალი ატრიბუტი, რომლებიც ხელმისაწვდომია (მოგვიანებით უფრო მეტს გავიგებთ, როგორ მუშაობს ეს ჯადოქრობა). თუკი გვინდოდა იმის კატეგორიზაცია, თუ რა გვინდოდა, სავარაუდოდ, შეგვეძლო მათი დაყოფა შემდეგნაირად: ამ დაყოფის გათვალისწინებით, ლოგიკური იქნებოდა, რომ მათ ჩვენს დეკლარირებულ `model_args`-ში ვიპოვით: თუმცა, რასაც ვიწყებთ შემჩნევას, არის აქ შესრულებული მოხერხებული შეფუთვა. `ModelSearchArguments` (და მისი დამატებითი `DatasetSearchArguments`) გააჩნია ადამიანისთვის წაკითხვადი ინტერფეისი ფორმატირებული გამომავალი მონაცემებით, რომლებიც API-ს სჭირდება, მაგალითად, როგორ უნდა მოხდეს GLUE მონაცემთა ნაკრების ძიება `dataset:glue`-ის გამოყენებით. ეს გადამწყვეტია, რადგან ამ „შპარგალკის“ გარეშე, რომლითაც გეცოდინებათ, როგორ უნდა დაიწეროს გარკვეული პარამეტრები, შეგიძლიათ მარტივად ჩავარდეთ ფრუსტრაციაში, როცა ცდილობთ მოდელების მოძიებას API-ის საშუალებით! ახლა, როცა ვიცით, რომელია სწორი პარამეტრები, შეგვიძლია მარტივად მოვძებნოთ API-ის გამოყენებით: ვნახეთ, რომ 140 შესაბამისი მოდელი იქნა ნაპოვნი, რომლებიც ჩვენს კრიტერიუმებს აკმაყოფილებდნენ! (ამ სტატიის დაწერის მომენტში). და თუ ერთ-ერთს უფრო დეტალურად დავაკვირდებით, დავინახავთ, რომ ის მართლაც სწორად გამოიყურება: ეს ცოტა უფრო წაკითხვადია და არ არის საჭირო გამოცნობა „სწორად მივუთითე თუ არა ეს პარამეტრი?“ იცოდით, რომ ამ მოდელის ინფორმაციის პროგრამულად მიღება მისი მოდელის ID-ითაც შეგიძლიათ? აი, როგორ გააკეთებთ ამას: ვნახეთ, როგორ შეგვიძლია `ModelSearchArguments`-ისა და `DatasetSearchArguments`-ის გამოყენება, რათა თავიდან ავიცილოთ გამოცნობები Hub-ზე ძიებისას, მაგრამ რა ხდება მაშინ, თუ გვაქვს ძალიან რთული, არეული მოთხოვნა? მაგალითად: მინდა მოვძებნო ყველა მოდელი, რომელიც გაწვრთნილია როგორც ტექსტის კლასიფიკაციისთვის, ასევე ნულოვანი გასროლის კლასიფიკაციისთვის, გაწვრთნილია Multi NLI და GLUE მონაცემთა ნაკრებებზე და თავსებადია როგორც PyTorch-თან, ასევე TensorFlow-თან (უფრო ზუსტი მოთხოვნა ზემოთ მოცემული მოდელის მისაღებად). ამ მოთხოვნის დასაყენებლად, გამოვიყენებთ `ModelFilter` კლასს. ის შექმნილია ასეთი ტიპის სიტუაციების მოსაგვარებლად, ასე რომ, არ დაგვჭირდება თავის ტეხა: ძალიან სწრაფად ვხედავთ, რომ ეს არის ბევრად უფრო კოორდინირებული მიდგომა API-ის საშუალებით ძიებისთვის, თქვენთვის დამატებითი თავის ტკივილის გარეშე! ძალიან მოკლედ ვისაუბრებთ ფუნდამენტურ „მაგიაზე“, რომელიც გვაძლევს ამ enum-ლექსიკონის მსგავს მონაცემთა ტიპს, `AttributeDictionary`-ს. `fastcore` ბიბლიოთეკის `AttrDict` კლასით ძლიერ შთაგონებული, ზოგადი იდეა მდგომარეობს იმაში, რომ ჩვენ ვიღებთ ჩვეულებრივ ლექსიკონს და ვაძლიერებთ მას საძიებო პროგრამირებისთვის, ლექსიკონში არსებული ყოველი გასაღებისთვის ტაბ-დასრულების (tab-completion) უზრუნველყოფით. როგორც ადრე ვნახეთ, ეს კიდევ უფრო ძლიერდება, როდესაც გვაქვს ჩადგმული ლექსიკონები, რომელთა მეშვეობითაც შეგვიძლია ძიება, მაგალითად `model_args.dataset.glue`! JavaScript-თან ნაცნობი პირებისთვის, ჩვენ ვბაძავთ, თუ როგორ მუშაობს `object` კლასი. ეს მარტივი დამხმარე კლასი უზრუნველყოფს ბევრად უფრო მომხმარებელზე ორიენტირებულ გამოცდილებას ჩადგმული მონაცემთა ტიპების შესწავლისას და იმის გაგებისას, თუ რა არის იქ, მაგალითად, API მოთხოვნის დაბრუნებული შედეგი! როგორც აღინიშნა, ჩვენ `AttrDict`-ს რამდენიმე ძირითადი გზით ვაფართოებთ: ერთი ძალიან მნიშვნელოვანი კონცეფცია, რომელიც უნდა აღინიშნოს, არის ის, რომ თუ გასაღები შეიცავს რიცხვს ან სპეციალურ სიმბოლოს, ის უნდა დაინდექსირდეს როგორც ლექსიკონი და არა როგორც ობიექტი. ამის ძალიან მოკლე მაგალითია, თუ გვაქვს `AttributeDictionary` გასაღებით `3_c`: იმედია, ახლა უკვე გაქვთ მოკლე წარმოდგენა, თუ როგორ მუშაობს ეს ახალი მიდგომა Hugging Face Hub-ზე ეფექტური ძიებისთვის.