მსურდა შემექმნა მიკროსერვისი, რომელიც ავტომატურად აღმოაჩენდა, Discord-ში დატოვებული მომხმარებლის შეფასება პოზიტიური იყო თუ ნეგატიური. ეს საშუალებას მომცემდა, შესაბამისად მოვქცეულიყავი კომენტარს და გამეუმჯობესებინა მომხმარებლის გამოცდილება. მაგალითად, თუ შეფასება ნეგატიური იყო, შემეძლო შემექმნა ფუნქცია, რომელიც დაუკავშირდებოდა მომხმარებელს, ბოდიშს მოუხდიდა მომსახურების უხარისხობისთვის და აცნობებდა, რომ ჩვენი მხარდაჭერის გუნდი მას რაც შეიძლება მალე დაუკავშირდებოდა დახმარებისა და პრობლემის მოსაგვარებლად. იმის გათვალისწინებით, რომ თვეში 2,000-ზე მეტ მოთხოვნას არ ვგეგმავდი, არანაირი შესრულების შეზღუდვა არ დამეწესებინა დროისა და მასშტაბურობის თვალსაზრისით. თავიდან ცოტა დაბნეული ვიყავი, როდესაც .h5 ფაილი გადმოვწერე. მეგონა, ის თავსებადი იქნებოდა tensorflow.keras.models.load_model-თან, მაგრამ ასე არ აღმოჩნდა. რამდენიმე წუთიანი კვლევის შემდეგ მივხვდი, რომ ფაილი იყო წონების საგუშაგო წერტილი (weights checkpoint) და არა Keras მოდელი. ამის შემდეგ, ვცადე Hugging Face-ის მიერ შემოთავაზებული API და უფრო მეტი წავიკითხე მათ მიერ შემოთავაზებულ „ფაიფლაინის“ (pipeline) ფუნქციაზე. რადგან API-ისა და „ფაიფლაინის“ შედეგები შესანიშნავი იყო, გადავწყვიტე, რომ მოდელის გაშვება ჩემს სერვერზე „ფაიფლაინის“ მეშვეობით შემეძლო. ქვემოთ მოცემულია ოფიციალური მაგალითი Transformers-ის GitHub გვერდიდან. GCP (Google Cloud Platform) შევარჩიე, რადგან ეს არის ღრუბლოვანი გარემო, რომელსაც ვიყენებ ჩემს პირად ორგანიზაციაში. უკვე ვიცოდი, რომ შემეძლო გამომეყენებინა API სერვისი, როგორიცაა Flask, Transformers მოდელის გასაშვებად. Google Cloud AI დოკუმენტაციაში მოვძებნე და ვიპოვე სერვისი Tensorflow მოდელების განსათავსებლად, სახელწოდებით AI-Platform Prediction. ასევე ვიპოვე App Engine და Cloud Run, მაგრამ App Engine-ის მეხსიერების მოხმარების გამო ვღელავდი და Docker-თან არც თუ ისე კარგად ვიყავი ნაცნობი. რადგან მოდელი არ იყო „სუფთა TensorFlow“ შენახული მოდელი, არამედ „ჩექპოინტი“ (checkpoint), და ვერ მოვახერხე მისი „სუფთა TensorFlow მოდელად“ გადაქცევა, მივხვდი, რომ ამ გვერდზე მოცემული მაგალითი არ იმუშავებდა. შემდეგ დავინახე, რომ შემეძლო დამეწერა მორგებული კოდი, რაც საშუალებას მომცემდა, ჩამეტვირთა „ფაიფლაინი“ მოდელის მართვის ნაცვლად, რაც უფრო მარტივი ჩანდა. ასევე გავიგე, რომ შემეძლო განმესაზღვრა წინარე-პროგნოზირების (pre-prediction) და შემდგომი-პროგნოზირების (post-prediction) მოქმედება, რაც მომავალში შეიძლება გამოსადეგი ყოფილიყო მონაცემების წინარე ან შემდგომი დამუშავებისთვის მომხმარებლის საჭიროებების შესაბამისად. მივყევი Google-ის სახელმძღვანელოს, მაგრამ პრობლემას წავაწყდი, რადგან სერვისი ჯერ კიდევ ბეტა ფაზაშია და ყველაფერი სტაბილური არ არის. ეს საკითხი დეტალურად არის აღწერილი აქ. გადავედი Google-ის App Engine-ზე, რადგან ეს არის სერვისი, რომელთანაც ნაცნობი ვარ, მაგრამ TensorFlow-ის ინსტალაციის პრობლემას წავაწყდი სისტემის დამოკიდებულების ფაილის არარსებობის გამო. შემდეგ ვცადე PyTorch-ით, რომელიც F4_1G ინსტანციასთან მუშაობდა, მაგრამ მას არ შეეძლო ერთსა და იმავე ინსტანციაზე 2-ზე მეტი მოთხოვნის დამუშავება, რაც შესრულების თვალსაზრისით არც თუ ისე კარგია. ბოლოს, გადავედი Cloud Run-ზე Docker იმეიჯით. მივყევი ამ სახელმძღვანელოს, რათა გამეგო, როგორ მუშაობს. Cloud Run-ში შემეძლო უფრო მეტი მეხსიერებისა და მეტი vCPU-ის კონფიგურაცია PyTorch-ით პროგნოზირების შესასრულებლად. Tensorflow-ზე უარი ვთქვი, რადგან PyTorch მოდელს უფრო სწრაფად ტვირთავს. საბოლოო გადაწყვეტა ოთხი განსხვავებული კომპონენტისგან შედგება: main.py ფაილის შინაარსი ნამდვილად მარტივია. იდეაა, მივიღოთ GET მოთხოვნა, რომელიც ორ ველს შეიცავს. პირველი - მიმოხილვა, რომელიც უნდა გაანალიზდეს, მეორე - API გასაღები სერვისის „დასაცავად“. მეორე პარამეტრი არჩევითია, მე ის გამოვიყენე Cloud Run-ის oAuth2-ის დაყენების თავიდან ასაცილებლად. ამ არგუმენტების მოწოდების შემდეგ, ჩვენ ვტვირთავთ „ფაიფლაინს“, რომელიც აგებულია ზემოთ მოცემული მოდელის distilbert-base-uncased-finetuned-sst-2-english საფუძველზე. საბოლოოდ, საუკეთესო შესატყვისი უბრუნდება კლიენტს. შემდეგ მოცემულია Dockerfile, რომელიც გამოყენებული იქნება სერვისის Docker იმეიჯის შესაქმნელად. ჩვენ ვაზუსტებთ, რომ ჩვენი სერვისი მუშაობს python:3.7-ით, ასევე გვჭირდება ჩვენი მოთხოვნების ინსტალაცია. შემდეგ ვიყენებთ gunicorn-ს ჩვენი პროცესის დასამუშავებლად პორტ 5000-ზე. მნიშვნელოვანია აღინიშნოს არგუმენტები --workers 1 --threads 1, რაც ნიშნავს, რომ მსურს ჩემი აპლიკაცია მხოლოდ ერთ ვორკერზე (= 1 პროცესი) ერთ ნაკადთან ერთად შევასრულო. ეს იმიტომ, რომ არ მსურს ერთდროულად 2 ინსტანცია იყოს გაშვებული, რადგან ამან შესაძლოა გაზარდოს ხარჯები. ერთ-ერთი მინუსი ის არის, რომ დამუშავებას მეტი დრო დასჭირდება, თუ სერვისი ერთდროულად მიიღებს ორ მოთხოვნას. ამის შემდეგ, ნაკადების რაოდენობა ერთამდე შევზღუდე მოდელის „ფაიფლაინში“ ჩასატვირთად საჭირო მეხსიერების მოხმარების გამო. 4 ნაკადის გამოყენების შემთხვევაში, შესაძლოა მხოლოდ 4 Gb / 4 = 1 Gb მქონოდა სრული პროცესის შესასრულებლად, რაც არ არის საკმარისი და გამოიწვევდა მეხსიერების შეცდომას. და ბოლოს, requirement.txt ფაილი. პირველ რიგში, დაგჭირდებათ რამდენიმე მოთხოვნის დაკმაყოფილება, როგორიცაა Google Cloud-ზე პროექტის ქონა, ბილინგის ჩართვა და gcloud cli-ის ინსტალაცია. მეტი დეტალის ნახვა შეგიძლიათ Google-ის სახელმძღვანელოში - Before you begin. მეორე, ჩვენ უნდა ავაგოთ Docker იმეიჯი და გავუშვათ (deploy) Cloud Run-ზე სწორი პროექტის შერჩევით (შეცვალეთ PROJECT-ID) და დავაყენოთ ინსტანციის სახელი, მაგალითად ai-customer-review. განთავსების შესახებ მეტი ინფორმაცია შეგიძლიათ იპოვოთ Google-ის სახელმძღვანელოში - Deploying to. რამდენიმე წუთის შემდეგ, ასევე დაგჭირდებათ თქვენი Cloud Run ინსტანციისთვის გამოყოფილი მეხსიერების გაზრდა 256 MB-დან 4 GB-მდე.