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