ხელოვნური ინტელექტი (ხი) სულ უფრო ხშირად გამოიყენება კრიტიკულად მნიშვნელოვან ინფრასტრუქტურაში, როგორიცაა ეროვნული ელექტრო ქსელები და ავტომატიზებული სასაწყობო გამოთვლები პანდემიების დროს სუპერმარკეტებში. თუმცა, ჩნდება კითხვები, შეესაბამება თუ არა ინდუსტრიის სიმწიფე მისი მზარდი დანერგვის მასშტაბებს. უდავოა, რომ მანქანური სწავლების (მს) საფუძველზე შექმნილი აპლიკაციები IT-ის ყველა კუთხეში აღწევს. მაგრამ რას ნიშნავს ეს კომპანიებისა და ორგანიზაციებისთვის? როგორ ავაშენოთ მყარი მანქანური სწავლების სამუშაო პროცესები? უნდა დავიქირაოთ 100 მონაცემთა მეცნიერი? თუ 100 DevOps ინჟინერი? ტრანსფორმერები მს-სთვის ზოგადი დანიშნულების არქიტექტურად იქცა. არა მხოლოდ ბუნებრივი ენის დამუშავებისთვის, არამედ მეტყველებისთვის, კომპიუტერული მხედველობისთვის ან თუნდაც ცილის სტრუქტურის პროგნოზირებისთვის. ძველმა სპეციალისტებმა მწარე გამოცდილებით ისწავლეს, რომ IT-ში არ არსებობს პანაცეა. მიუხედავად ამისა, ტრანსფორმერების არქიტექტურა ნამდვილად ძალიან ეფექტურია მანქანური სწავლების მრავალფეროვან ამოცანებზე. მაგრამ როგორ შევძლოთ ყველამ ფეხი ავუწყოთ მანქანური სწავლების ინოვაციების თავბრუდამხვევ ტემპს? ნამდვილად გვჭირდება ექსპერტული უნარები ამ უახლესი მოდელების გამოსაყენებლად? თუ არსებობს უფრო მოკლე გზა ნაკლებ დროში ბიზნეს ღირებულების შესაქმნელად? აი, რას ვფიქრობ მე. მანქანური სწავლება ყველგანაა, ან სულ მცირე, ცდილობს იყოს. რამდენიმე წლის წინ, Forbes-მა დაწერა: „პროგრამულმა უზრუნველყოფამ მსოფლიო შეჭამა, ახლა კი ხი ჭამს პროგრამულ უზრუნველყოფას“, მაგრამ რას ნიშნავს ეს სინამდვილეში? თუ ეს იმას ნიშნავს, რომ მანქანური სწავლების მოდელებმა უნდა ჩაანაცვლონ ათასობით ხაზი გაქვავებული ძველი კოდისა, მაშინ მე ამას სრულად ვუჭერ მხარს. მოკვდით, ბოროტო ბიზნეს წესებო, მოკვდით! ახლა, ნიშნავს თუ არა ეს იმას, რომ მანქანური სწავლება რეალურად ჩაანაცვლებს პროგრამულ ინჟინერიას? ახლა ნამდვილად ბევრი ფანტაზირება მიდის ხი-ს მიერ გენერირებულ კოდზე, და ზოგიერთი ტექნიკა ნამდვილად საინტერესოა, მაგალითად, შეცდომების და შესრულების პრობლემების აღმოჩენა. თუმცა, დეველოპერების მოშორებაზე ფიქრიც კი არ ღირს; სამაგიეროდ, უნდა ვიმუშაოთ რაც შეიძლება მეტი მათგანის გაძლიერებაზე, რათა მანქანური სწავლება გახდეს უბრალოდ კიდევ ერთი მოსაწყენი IT დატვირთვა (და მოსაწყენი ტექნოლოგია მშვენიერია). სხვა სიტყვებით რომ ვთქვათ, ის, რაც ნამდვილად გვჭირდება, არის ის, რომ პროგრამულმა უზრუნველყოფამ შეჭამოს მანქანური სწავლება! წლების განმავლობაში ვამტკიცებდი, რომ ათწლეულების მანძილზე დაგროვილი საუკეთესო პრაქტიკები პროგრამული ინჟინერიისთვის ასევე გამოიყენება მონაცემთა მეცნიერებასა და მანქანურ სწავლებაში: ვერსიონირება, ხელახალი გამოყენებადობა, ტესტირება, ავტომატიზაცია, გაშვება (deployment), მონიტორინგი, შესრულება, ოპტიმიზაცია და ა.შ. გარკვეული პერიოდი მარტოსულად ვგრძნობდი თავს, შემდეგ კი Google-ის კავალერია მოულოდნელად გამოჩნდა: „აკეთეთ მანქანური სწავლება ისე, როგორც დიდებული ინჟინერი, რომელიც ხართ, და არა ისე, როგორც დიდებული მანქანური სწავლების ექსპერტი, რომელიც არ ხართ.“ – მანქანური სწავლების წესები, Google. ბორბლის ხელახლა გამოგონებაც არ არის საჭირო. DevOps მოძრაობამ ეს პრობლემები 10 წელზე მეტი ხნის წინ გადაჭრა. ახლა მონაცემთა მეცნიერებისა და მანქანური სწავლების საზოგადოებამ დაუყოვნებლივ უნდა მიიღოს და მოარგოს ეს გამოცდილი ინსტრუმენტები და პროცესები. ეს არის ერთადერთი გზა, რომლითაც ოდესმე შევძლებთ მყარი, მასშტაბირებადი და განმეორებადი მანქანური სწავლების სისტემების აგებას პროდუქციაში. თუ MLOps-ის დარქმევა ეხმარება, კარგია: კიდევ ერთ მოდას (buzzword) არ ვიკამათებ. ნამდვილად დროა, შევწყვიტოთ კონცეფციის დამტკიცებები (proof of concepts) და „ქვიშის ყუთის“ (sandbox) A/B ტესტები მნიშვნელოვან მიღწევებად განვიხილოთ. ისინი მხოლოდ მცირე საფეხურია პროდუქციისკენ, რაც ერთადერთი ადგილია, სადაც ვარაუდები და ბიზნეს გავლენა შეიძლება დადასტურდეს. ყველა მონაცემთა მეცნიერი და მანქანური სწავლების ინჟინერი უნდა იყოს შეპყრობილი მათი მოდელების პროდუქციაში გაშვებით, რაც შეიძლება სწრაფად და ხშირად. კარგი საპროდუქციო მოდელი ყოველთვის სჯობს დიდებულ „ქვიშის ყუთის“ მოდელს. 2021 წელია. IT ინფრასტრუქტურა აღარ უნდა იყოს შემაფერხებელი. პროგრამულმა უზრუნველყოფამ ის დიდი ხნის წინ გადაყლაპა, ღრუბლოვანი API-ებით, ინფრასტრუქტურა-როგორც-კოდი-ით, Kubeflow-ით და ა.შ. აბსტრაგირება მოახდინა. დიახ, ლოკალურადაც კი. იგივე სწრაფად ხდება მანქანური სწავლების ინფრასტრუქტურისთვისაც. Kaggle-ის გამოკითხვის თანახმად, რესპონდენტთა 75% იყენებს ღრუბლოვან სერვისებს, ხოლო 45%-ზე მეტი – საწარმოს ML პლატფორმას, სადაც Amazon SageMaker, Databricks და Azure ML Studio იკავებენ სამ წამყვან პოზიციას. MLOps-ის, პროგრამულად განსაზღვრული ინფრასტრუქტურისა და პლატფორმების წყალობით, არასოდეს ყოფილა ასე ადვილი ამ შესანიშნავი იდეების „ქვიშის ყუთიდან“ გამოტანა და პროდუქციაში გადატანა. ჩემს თავდაპირველ შეკითხვაზე პასუხად, თითქმის დარწმუნებული ვარ, რომ თქვენ გჭირდებათ მეტი ML-ში მცოდნე პროგრამული უზრუნველყოფის და DevOps ინჟინერი, და არა მეტი მონაცემთა მეცნიერი. მაგრამ გულის სიღრმეში, თქვენ ეს იცოდით, არა? ახლა კი, მოდით, ვისაუბროთ ტრანსფორმერებზე. AI-ის მდგომარეობის ანგარიში ამბობს: „ტრანსფორმერის არქიტექტურა მნიშვნელოვნად გასცდა ბუნებრივი ენის დამუშავებას და ხდება ზოგადი დანიშნულების არქიტექტურა მს-სთვის.“ მაგალითად, ბოლო მოდელებმა, როგორიცაა Google-ის Vision Transformer (კონვოლუციის გარეშე ტრანსფორმერის არქიტექტურა) და CoAtNet (რომელიც აერთიანებს ტრანსფორმერებსა და კონვოლუციას), დააწესეს ახალი ეტალონები ImageNet-ზე გამოსახულების კლასიფიკაციისთვის, ამასთან, საჭიროებენ ნაკლებ გამომთვლელ რესურსებს ტრენინგისთვის. ტრანსფორმერები ასევე ძალიან კარგად მუშაობენ აუდიოზე (მაგალითად, მეტყველების ამოცნობაზე), ისევე როგორც წერტილოვან ღრუბლებზე (point clouds), ტექნიკაზე, რომელიც გამოიყენება 3D გარემოების მოდელირებისთვის, როგორიცაა ავტონომიური მართვის სცენები. Kaggle-ის გამოკითხვა ასახავს ტრანსფორმერების ამ აღზევებას. მათი გამოყენება წლიდან წლამდე იზრდება, მაშინ როდესაც RNN-ები, CNN-ები და გრადიენტული ბუსტინგი...