სურათებით მძიმე აგენტის ციკლების მეხსიერებაში დატევა

წარმოებაში აგენტის ერთმა ციკლმა 952 მბ-ზე მეხსიერება ამოწურა, როცა ექვს კატალოგის სკანს აჭრიდა პროდუქტებს და თავის ნაჭრებს აკვირდებოდა. ერთი გაჟონვა არ ყოფილა, არამედ სამი. მოდელის ყოველი გამოძახება ციკლის სურათებს სრული ზომით კვლავ აგზავნიდა; მოდელის გამოსაძახებლად გამოყენებული ბიბლიოთეკა ყოველ მოთხოვნას ციკლის დასრულებამდე ცოცხლად ინახავდა; ხოლო აგენტის framework-ის ტრეისინგი ყოველი გამოძახების შეყვანებს, სურათებით ერთად, მთელი ციკლის განმავლობაში ინახავდა. სამივე გამოვასწორეთ: სურათები გაგზავნამდე მცირდება და თითოეული გამოძახების სურათები მაშინვე თავისუფლდება, როგორც კი გამოძახება დასრულდება.

როგორ ხედავს აგენტი სურათებს

Mythex-ზე აშენებისას აგენტი მუშაობს თქვენი პროექტის ღრუბლოვან sandbox-ში. მას შეუძლია სურათების ყურება: თქვენ მიერ მიმაგრებული სკრინშოტი, მაკეტი, ფაილი პროექტში ან სურათი, რომელიც მან თავად შექმნა, და ეს სურათები მოდელს საუბართან ერთად მიეწოდება.

ციკლი ის ყველაფერია, რასაც აგენტი აკეთებს ერთ თქვენს შეტყობინებაზე საპასუხოდ. ციკლში აგენტი მოდელს მრავალჯერ უძახის: ფიქრობს, უშვებს ინსტრუმენტს, უყურებს შედეგს და ისევ ფიქრობს. ყოველი ასეთი გამოძახება აგზავნის საუბარს ამ მომენტამდე, მათ შორის ციკლის სურათებს, რომლებიც ტექსტად (base64, რაც დაახლოებით მესამედით ზრდის) იწერება.

ციკლი, რომელიც ჩამოინგრა, გონივრულად მუშაობდა. მან ექვსი კატალოგის სკანი აიღო, დაახლოებით 2.4 მბ-იანი თითო, აჭრა ცალკეული პროდუქტები და კვლავ კითხულობდა თავის ნაჭრებს შესამოწმებლად. ეს მრავალი მოდელის გამოძახებაა, თითოეული რამდენიმე დიდ სურათს ატარებს.

მიზეზი 1: ყოველი გამოძახება სრული ზომის სურათებს კვლავ აგზავნიდა

მოდელის ყოველი გამოძახება მოთხოვნის სხეულს თავიდან ქმნიდა ციკლის სურათებით სრული ზომით — დაახლოებით 20 მბ base64 ყოველ გამოძახებაზე. სხეული აგენტის მეხსიერებაში ერთ სტრიქონად აწყობდა, ასე რომ ყოველი გამოძახება კიდევ დაახლოებით 20 მბ-ს ანაწილებდა.

სრული ზომით გაგზავნას არაფერი არ მოჰქონდა. მოდელი თავად ამცირებს სურათებს დაახლოებით 1,300 პიქსელამდე გრძელ მხარეზე, ამიტომ ზედმეტი პიქსელები მხოლოდ მეხსიერებას და ატვირთვის დროს ამატებდა.

გამოსწორება: ერთხელ დავამცირეთ, პატარა გავგზავნეთ

• 400 KB-ზე მეტი სურათები, გაგზავნამდე, JPEG-ად გარდაიქმნება, რომელიც გრძელ მხარეზე მაქსიმუმ 1,568 პიქსელია. პატარა სურათები ისე მიდის, როგორც არის.
• გარდაქმნა იყენებს ImageMagick-ს, რომელიც ყოველ Mythex sandbox-შია, და მუშაობს ფაილზე ერთხელ. ციკლი, რომელიც იმავე სკანებს ყოველ გამოძახებაზე უყურებს, დამცირებულ ასლს იყენებს ხელახლა. ქეში გასაღებდება ფაილის გზით, ზომითა და ცვლილების დროით, ასე რომ, შეცვლილი ფაილი ხელახლა გარდაიქმნება, და მას თავისი ზომის ზღვარი აქვს, რომ თავად მეხსიერება არ აავსოს.
• ერთი მოდელის გამოძახების სურათების ბიუჯეტი 16 მბ-დან 6 მბ-მდე დაეცა.

განმეორებული იგივე ექვსი სკანი ახლა ყოველ გამოძახებაზე 4.4 მბ-ს ჯდება, 19.7 მბ-ის ნაცვლად.

მიზეზი 2: მოდელის კლიენტი მოთხოვნას არასდროს უშვებდა

მოთხოვნის ზომა მხოლოდ ნაწილი იყო. მეხსიერება ასევე იზრდებოდა გამოძახება-გამოძახებაზე. ჩვენს staging გარემოში იგივე ტიპის ციკლი 369 მბ ცოცხალ მეხსიერებას ინახავდა, მაშინაც კი, როცა სრული garbage collection გაეშვა, ანუ იმ წერტილში, სადაც ყველაფერი, რაც მიუწვდომელია, უკვე გათავისუფლებულია. ჰიფის სემპლინგმა მთელი ზრდა იმ ნაწილში მოათავსა, რომელიც მოდელის კლიენტ ბიბლიოთეკაში მოთხოვნის სხეულებს აკოდირებს.

მიზეზი abort listener იყო. როცა Stop-ს დააჭერთ, ციკლის abort signal ირთვება და ყოველი მოთხოვნა, რომელიც მას უსმენს, ჩერდება. ჩვენ ერთ ციკლურ signal-ს ყველა მოთხოვნაზე ვაძლევდით. კლიენტის ბიბლიოთეკა მას „abort“ listener-ს უმატებს და არასდროს შლის.

ასე ციკლის ყველა მოთხოვნა ციკლის signal-იდან მიწვდომი რჩებოდა მთელი ციკლის განმავლობაში: listener, რომელიც ინახავდა controller-ს, რომელიც ინახავდა მოთხოვნას, რომელიც ინახავდა მთელ მოთხოვნის სხეულს თავისი სურათებით.

გამოსწორება: თითო მოთხოვნას — ერთი signal

ახლა თითოეულ მოთხოვნას საკუთარი signal აქვს. ის მხოლოდ მაშინ უკავშირდება ციკლის signal-ს, როცა მოთხოვნა მიმდინარეობს — სტრიმული პასუხისთვის, ბოლო ნაწილის წაკითხვამდე — და მაშინვე გაითიშება. Stop მაინც აღწევს ნებისმიერ მიმდინარე მოთხოვნას, მაგრამ ციკლის signal ერთდროულად მხოლოდ ერთ listener-ს ინახავს.

ტესტები სამივე ნაწილს ფარავს:

• 12 გამოძახების შემდეგ ციკლის signal-ზე არცერთი listener არ რჩება. გამოსწორებამდე იყო 12.
• 8 მბ-იანი 15 მოთხოვნის დროს მეხსიერება სტაბილურად რჩება. ადრე 128 მბ-ით იზრდებოდა.
• Stop მაინც წყვეტს მოთხოვნას მის სტრიმის შუაში.

მიზეზი 3: ტრეისინგი ყოველი გამოძახების შეყვანებს ინახავდა

ჰიფის snapshot-მა მესამე მფლობელი აჩვენა: დაახლოებით 6 მბ ყოველ მოდელის გამოძახებაზე. ეს აგენტის framework-ის ივენთების სტრიმინგიდან მოდიოდა. ის ციკლში ყოველ მოდელის გამოძახებას ციკლის შვილად აღრიცხავს, შეყვანებით ერთად, ციკლის დასრულებამდე. ყოველი გამოძახების ყოველი სურათი მასთან ერთად მეხსიერებაში რჩებოდა.

გამოსწორება: სურათების გაცარიელება გამოძახების დაბრუნებისთანავე

სურათები მხოლოდ კონკრეტული მოდელის გამოძახებისთვის შედგენილ შეტყობინებებში ერთვება. ისინი საუბრის შენახულ მდგომარეობაში არასდროს ინახება. ამიტომ, როცა გამოძახება დაბრუნდება, უსაფრთხოა იმ შეტყობინებებში სურათების მონაცემების დაცარიელება. ტრეისი ინახავს გამოძახების ტექსტურ ჩანაწერს; პიქსელები იშლება.

ერთი დეტალი მნიშვნელოვანი იყო: სურათები ადგილზე უნდა გაცარიელდეს. ტრეისერს შეიძლება ერთი და იგივე სურათის მონაცემებზე რამდენიმე მიმართვით მიწვდეს შეტყობინებაზე, ასე რომ, ახალი, ცარიელი სიის ჩასმა დატოვებდა ორიგინალს, პიქსელებითურთ, მიუწვდომელს. შენახული საუბრის მდგომარეობა არასდროს იცვლება.

ტესტი აგენტის გრაფს იმავე ივენთების სტრიმინგის ქვეშ უშვებს, 4 მბ-იანი სურათით ყოველ გამოძახებაზე. გამოსწორების გარეშე მეხსიერება 16 გამოძახებაზე 77 მბ-ით გაიზარდა. მასთან ერთად ის სტაბილური რჩება.

რა ავიღეთ ამ ამბიდან

• მეხსიერების პრობლემებს ფენები აქვთ. სამი ცალკეული მიზეზი სურათებს ზედმეტ ხანს იჭერდა, და სტაბილური მეხსიერებისთვის ყველა უნდა გამოსწორებულიყო.
• ყველაფერი, რასაც ბიბლიოთეკას გადასცემ, შეიძლება შენახულ იქნას. signal-ი და ტრეისი იმ გამოძახებებზე მეტ ხანს ცოცხლობდა, რომლებსაც მიეცა. თუ მეხსიერება ყოველ გამოძახებაზე იზრდება, შეამოწმე, რა ხანგრძლივი ობიექტები ეხება გამოძახებას.
• არ გაუგზავნო იმას, რასაც მეორე მხარე ისედაც აგდებს. პიქსელები, რომლებსაც მოდელი ისედაც გამოიყენებს, ყოველ გამოძახებაზე მეხსიერებას გვიჯდებოდა.
• მეხსიერება პირდაპირ ტესტე. თითოეულ გამოსწორებას ტესტი ახლდა, რომელიც ზომავს ჰიფის ზრდას ან listener-ების რაოდენობას, ასე რომ რეგრესია რიცხვად ჩანს და არა ავარიად.

ეს აგენტიდან მეორე მეხსიერების ამბავია ცოტა ხნის განმავლობაში; პირველი იყო პროგრესის label, რომელმაც 41,000-ჯერ გააგზავნა. თუ გსურთ მეტი იმაზე, რა არის აგენტი და როგორ მუშაობს, იხილეთ ჩვენი გიდი AI აგენტების შესახებ და ჩატის დოკუმენტაცია.