ჩვენ შევქმენით Rocket Money (პირადი ფინანსების აპლიკაცია, რომელიც ადრე Truebill-ის სახელით იყო ცნობილი) იმ მიზნით, რომ დავხმარებოდით მომხმარებლებს გაეუმჯობესებინათ მათი ფინანსური მდგომარეობა. მომხმარებლები თავიანთ საბანკო ანგარიშებს უკავშირებენ აპლიკაციას, რომელიც შემდეგ ახარისხებს და კატეგორიზაციას უკეთებს მათ ტრანზაქციებს, განმეორებადი შაბლონების იდენტიფიცირებით კი, აწვდის კონსოლიდირებულ, ყოვლისმომცველ ხედვას მათი პირადი ფინანსური ცხოვრების შესახებ. ტრანზაქციის დამუშავების კრიტიკული ეტაპია ცნობილი გამყიდველებისა და სერვისების აღმოჩენა, რომელთაგან ზოგიერთი Rocket Money-ს შეუძლია გააუქმოს და მოლაპარაკება აწარმოოს ღირებულებაზე წევრებისთვის. ეს აღმოჩენა იწყება მოკლე, ხშირად შემოკლებული და გაურკვევლად ფორმატირებული ტრანზაქციის სტრიქონების კლასებად გარდაქმნით, რომელთა გამოყენებაც შეგვიძლია პროდუქტის გამოცდილების გასამდიდრებლად. თავდაპირველად, ჩვენ ამოვიღეთ ბრენდები და პროდუქტები ტრანზაქციებიდან რეგულარულ გამოსახულებებზე (regex) დაფუძნებული ნორმალიზატორების გამოყენებით. ესენი გამოიყენებოდა მზარდი სირთულის მქონე გადაწყვეტილების ცხრილთან ერთად, რომელიც სტრიქონებს შესაბამის ბრენდებთან აკავშირებდა. ეს სისტემა ეფექტური აღმოჩნდა კომპანიის პირველი ოთხი წლის განმავლობაში, როდესაც კლასები დაკავშირებული იყო მხოლოდ იმ პროდუქტებთან, რომლებსაც გაუქმებისა და მოლაპარაკებებისთვის ვუჭერდით მხარს. თუმცა, ჩვენი მომხმარებელთა ბაზის ზრდასთან ერთად, გამოწერის ეკონომიკამ ბუმი განიცადა და ჩვენი პროდუქტის ფარგლები გაიზარდა, ამიტომ საჭირო გახდა ახალი კლასების ტემპს მივყოლოდით, თანამიმდევრულად გვეკეთებინა regex-ების ოპტიმიზაცია და თავიდან აგვეცილებინა კონფლიქტები და გადაფარვები. ამ პრობლემის გადასაჭრელად, ჩვენ გამოვიკვლიეთ მანქანური სწავლების (ML) სხვადასხვა ტრადიციული გადაწყვეტა, მათ შორის „სიტყვათა ტომრის“ (bag of words) მოდელი, თითო კლასზე გათვლილი არქიტექტურით. ამ სისტემას გაუჭირდა შენარჩუნება და მუშაობა და საბოლოოდ მისი გამოყენება შეწყდა. ჩვენ გადავწყვიტეთ სუფთა ფურცლიდან დაგვეწყო, შევკრიბეთ როგორც ახალი გუნდი, ასევე ჩამოვაყალიბეთ ახალი მანდატი. ჩვენი პირველი ამოცანა იყო სავარჯიშო მონაცემების დაგროვება და შიდა სისტემის ნულიდან აშენება. ჩვენ გამოვიყენეთ Retool მარკირების რიგების, ოქროს სტანდარტის ვალიდაციის მონაცემთა ნაკრებების და გადახრის აღმოჩენის მონიტორინგის ხელსაწყოების შესაქმნელად. ჩვენ გამოვიკვლიეთ მოდელის სხვადასხვა ტოპოლოგია, მაგრამ საბოლოოდ ავირჩიეთ BERT-ის ოჯახის მოდელები ჩვენი ტექსტის კლასიფიკაციის პრობლემის გადასაჭრელად. საწყისი მოდელის ტესტირებისა და შეფასების დიდი ნაწილი ოფლაინ რეჟიმში ჩატარდა ჩვენს GCP საცავში. აქ ჩვენ შევიმუშავეთ და ავაშენეთ ტელემეტრია და სისტემა, რომელსაც ვიყენებდით 4000-ზე მეტი კლასის მქონე მოდელის მუშაობის გასაზომად. ჩვენს სფეროში უამრავი უნიკალური გამოწვევაა, მათ შორის ვაჭრების, გადამამუშავებელი/გადახდის კომპანიების მიერ შემოტანილი ენტროპია, ინსტიტუციური განსხვავებები და მომხმარებლის ქცევის ცვლილებები. მოდელის მუშაობის ეფექტური შეტყობინებების სისტემის და რეალისტური საორიენტაციო მონაცემთა ნაკრებების შემუშავება და აგება მუდმივ გამოწვევად რჩება. კიდევ ერთი მნიშვნელოვანი დაბრკოლება არის ჩვენი სისტემისთვის კლასების ოპტიმალური რაოდენობის განსაზღვრა — თითოეული კლასი შექმნისა და შენარჩუნების მნიშვნელოვან ძალისხმევას მოითხოვს. ამიტომ, ჩვენ უნდა გავითვალისწინოთ მისი ღირებულება მომხმარებლებისა და ჩვენი ბიზნესისთვის. როდესაც მოდელი კარგად მუშაობდა ოფლაინ ტესტირებაში და გვყავდა ML ინჟინრების მცირე გუნდი, ახალი გამოწვევის წინაშე აღმოვჩნდით: ამ მოდელის უწყვეტი ინტეგრაცია ჩვენს საწარმოო კონვეიერში. არსებული regex სისტემა თვეში 100 მილიონზე მეტ ტრანზაქციას ამუშავებდა მაღალი, „აწყვეტილი“ დატვირთვით, ამიტომ გადამწყვეტი იყო გვქონოდა მაღალი ხელმისაწვდომობის სისტემა, რომელსაც შეეძლო დინამიურად მასშტაბირება დატვირთვის მიხედვით და კონვეიერში დაბალი საერთო შეყოვნების შენარჩუნება, ასევე სისტემა, რომელიც გამოთვლითი ოპტიმიზაციით იყო გამორჩეული იმ მოდელებისთვის, რომლებსაც ვემსახურებოდით. როგორც იმ დროს პატარა სტარტაპმა, გადავწყვიტეთ შეგვეძინა, ნაცვლად აგვეგო, მოდელის სერვისის მიწოდების გადაწყვეტა. იმ მომენტში, ჩვენ არ გვქონდა შიდა „model ops“ ექსპერტიზა და გვჭირდებოდა ჩვენი ML ინჟინრების ენერგია მიგვემართა პროდუქტში მოდელების მუშაობის გაუმჯობესებაზე. ამის გათვალისწინებით, ჩვენ დავიწყეთ გადაწყვეტის ძებნა. თავდაპირველად, ჩვენ გამოვცადეთ ხელით შექმნილი, შიდა მოდელის ჰოსტინგის გადაწყვეტა, რომელსაც პროტოტიპირებისთვის ვიყენებდით, შევადგარეთ იგი AWS Sagemaker-სა და Hugging Face-ის ახალ მოდელის ჰოსტინგის Inference API-სთან. იმის გათვალისწინებით, რომ GCP-ს ვიყენებთ მონაცემთა შესანახად და Google Vertex Pipelines-ს მოდელების მოსამზადებლად, მოდელების AWS Sagemaker-ზე ექსპორტი მოუხერხებელი და შეცდომებისადმი მიდრეკილი იყო. საბედნიეროდ, Hugging Face-ის დაყენება სწრაფი და მარტივი იყო და მან ერთ კვირაში ტრაფიკის მცირე ნაწილის დამუშავება შეძლო. Hugging Face-მა უბრალოდ იმუშავა დაწყებისთანავე და ამ შემცირებულმა ხახუნმა ამ გზით სიარულისკენ გვიბიძგა. სამთვიანი ვრცელი შეფასების პერიოდის შემდეგ, ჩვენ Hugging Face ავირჩიეთ ჩვენი მოდელების განსათავსებლად. ამ დროის განმავლობაში, ჩვენ თანდათან გავზარდეთ ტრანზაქციების მოცულობა მათ ჰოსტინგზე განთავსებულ მოდელებზე და ჩავატარეთ მრავალი სიმულირებული დატვირთვის ტესტი ჩვენი ყველაზე ცუდი სცენარის მოცულობებზე დაყრდნობით. ამ პროცესმა საშუალება მოგვცა დაგვეხვეწა ჩვენი სისტემა და გვეკონტროლებინა მუშაობა, რამაც საბოლოოდ მოგვცა დარწმუნებულობა inference API-ის უნარში, გაუმკლავდეს ჩვენი ტრანზაქციების გამდიდრების დატვირთვებს. ტექნიკური შესაძლებლობების გარდა, ჩვენ ასევე მჭიდრო ურთიერთობა დავამყარეთ Hugging Face-ის გუნდთან. აღმოვაჩინეთ, რომ ისინი იყვნენ არა მხოლოდ სერვისის პროვაიდერები, არამედ პარტნიორები, რომლებიც ინვესტირებულნი იყვნენ ჩვენს მიზნებსა და შედეგებში. ჩვენი თანამშრომლობის დასაწყისში შევქმენით საერთო Slack არხი, რომელიც ფასდაუდებელი აღმოჩნდა. განსაკუთრებით შთაბეჭდილება მოახდინა მათმა სწრაფმა რეაგირებამ პრობლემებზე და პროაქტიულმა მიდგომამ მათ გადასაჭრელად.