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