გრძელი აგენტის ციკლების დატევა კონტექსტის ფანჯარაში

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

რამდენიმე ტერმინი ჯერ

• ტოკენები არის ნაწილები, რომლებსაც მოდელი კითხულობს. ლიმიტები და ფასები მათში ითვლება და არა სიმბოლოებში ან სიტყვებში.
• კონტექსტის ფანჯარა არის ყველაზე მეტი, რაც მოდელს ერთ მოთხოვნაში წაკითხვა შეუძლია. ჩვენ ასევე ვაყენებთ საკუთარ, უფრო დაბალ ბიუჯეტს თითო მოთხოვნაზე, რომ ღირებულება და სიჩქარე გონივრული დარჩეს.
• ინსტრუმენტის შედეგები არის ის, რასაც აგენტი თავისი ინსტრუმენტებისგან უბრუნდება: წაკითხული ფაილის შიგთავსი, ნაბრძანები ბრძანების გამოტანა. გრძელ სამუშაოში სწორედ ისინი შეადგენენ გაგზავნილის უმეტეს ნაწილს.
• ქვე-აგენტი არის დამხმარე, რომელსაც მთავარი აგენტი ავტონომიური ამოცანისთვის ქმნის, მაგალითად „შეამოწმე ეს თავები შენიშვნებთან“. ის ერთ ინსტრუქციას იღებს და შემდეგ მრავალი ინსტრუმენტის გამოძახებით მუშაობს დამოუკიდებლად.

პრობლემა 1: ქვე-აგენტები მოდელს უარის თქმამდე იზრდებოდნენ

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

ქვე-აგენტს ზუსტად ერთი მომხმარებლის შეტყობინება აქვს: მისი ინსტრუქცია. ჭრის ადგილი არ არსებობდა. ამიტომ ის ყოველ ნაბიჯზე მთელ თავის ისტორიას აგზავნიდა, და ყოველ ჯერზე იზრდებოდა, სანამ მოთხოვნა არ გახდებოდა იმაზე დიდი, რასაც მოდელი საერთოდ იღებს — დაახლოებით მილიონი ტოკენი. ტესტში 8 ასეთი ქვე-აგენტიდან ყველა 8 უარყოფილი იყო.

გამოსწორება: ჯერ ძველი ინსტრუმენტის შედეგების გასუფთავება

მოთხოვნები ახლა სამ ნაბიჯად ეტევა ბიუჯეტში, თითოეული მხოლოდ მაშინ, თუ წინა საკმარისი არ აღმოჩნდა:

1. გაასუფთავეთ ყველაზე ძველი ინსტრუმენტის შედეგები. მათი შიგთავსი მოკლე შენიშვნით იცვლება: შედეგი გასუფთავდა, რათა საუბარი მოდელის კონტექსტში დარჩეს, და აგენტს შეუძლია ინსტრუმენტი ხელახლა გამოიძახოს, თუ სჭირდება. ერთი საათის წინ წაკითხული ფაილი ხშირად ყველაზე დიდი და ყველაზე ნაკლებად სასარგებლო რამაა მოთხოვნაში, ფაილი კი ისევ ხელმისაწვდომია ხელახლა წასაკითხად. უახლესი შედეგები მთლიანად რჩება.
2. შეინარჩუნეთ მთლიანი მომხმარებლის ბრუნები. როგორც ადრე: პირველი შეტყობინება, შენიშვნა და ყველაზე ახალი მთლიანი ბრუნები, რომლებიც ეტევა.
3. შეინარჩუნეთ მთლიანი ინსტრუმენტის რაუნდები. ერთ გრძელ ბრუნში — ერთადერთი სახეობა, რომელიც ქვე-აგენტს აქვს — შეინახეთ პირველი შეტყობინება, შენიშვნა და ყველაზე ახალი მთლიანი რაუნდები „გამოიძახე ინსტრუმენტი, მიიღე შედეგი“.

ეს მხოლოდ იმას ცვლის, რა იგზავნება. აგენტის შენახული ისტორია ყველაფერს ინახავს. იმავე ტესტში 8-დან 0 უარყოფილი იყო და ყველა 8 დასრულდა.

გასუფთავება პაკეტებად, რომ ქეში იმუშავოს

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

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

უარყოფები ახლა ამბობენ, რატომ

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

პრობლემა 2: აგენტი „ადგილის დასაზოგად“ ჩერდებოდა

ქვე-აგენტმა, რომელსაც 40 გრძელი თავის წაკითხვა სთხოვეს, 2-ის შემდეგ შეწყვიტა, იმის თქმით, რომ ადგილის დაზოგვა სურდა. მას დაახლოებით 100,000 ტოკენი ჰქონდა გამოყენებული 400,000-იანი ბიუჯეტიდან.

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

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

პრობლემა 3: ტოკენების დათვლა ისე, თითქოს ყველაფერი ინგლისური იყო

ტოკენებს ვაფასებდით tokenizer-ის გაშვების გარეშე, როგორც სიმბოლოებს, გაყოფილს ოთხზე. ეს ინგლისურისთვის გონივრული ეგრეთ წოდებული წესია. სხვა დამწერლობებისთვის არა: რუსული დაახლოებით 2.2 სიმბოლოს უდრის ერთ ტოკენს, ხოლო ჩინური ან იაპონური დაახლოებით ერთს.

ამიტომ ქვე-აგენტმა, რომელიც რუსულ თავებს კითხულობდა, დაახლოებით 640,000 ტოკენიანი მოთხოვნა გაგზავნა, მაშინ როცა ჩვენი შეფასება 400,000-იანი ბიუჯეტის ქვემოთ იყო. შეფასება ისევე შეიძლებოდა მოთხოვნა მოდელის მკაცრ ლიმიტზე გაეშვა.

შეფასება ახლა დამწერლობის მიხედვით ითვლის: ჩვეულებრივი ASCII ოთხ სიმბოლოზე ერთ ტოკენად, ჩინური, იაპონური და კორეული ერთ სიმბოლოზე, ხოლო დანარჩენი — კირილიცა, ბერძნული, არაბული, აქცენტიანი ასოები, ემოჯი — ორზე. ის მიზნად ისახავს მაღალ შეცდომას. ერთ რუსულ თავზე ახლა 43,423 ტოკენს ვაფასებთ, მაშინ როცა გაზომვით დაახლოებით 44,600 იყო; ადრე ის 25,023-ს ამბობდა. შეტყობინება ერთხელ დაწერის შემდეგ არ იცვლება, ამიტომ მისი შეფასება ერთხელ ითვლება და მეხსიერებაში რჩება, და არა ყოველ ნაბიჯზე.

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

• შეამცირეთ იქ, სადაც ზომა რეალურად არის. აგენტის სამუშაოში ეს ინსტრუმენტის შედეგებია და არა მომხმარებლის შეტყობინებები.
• უთხარით აგენტს მის საკუთარ დამცავ ბადეებზე. წინააღმდეგ შემთხვევაში ის დაგეგმავს ლიმიტების გარშემო, რომლებიც აღარ მოქმედებს.
• „სიმბოლოები ÷ 4“ ინგლისური დაშვებაა. ყველაფერი, რაც მრავალენოვანი მომხმარებლებისთვის ტოკენებს ითვლის, უნდა ითვლიდეს დამწერლობის მიხედვით ან იყენებდეს რეალურ tokenizer-ს.
• იზრუნეთ ქეშზე. მოთხოვნა, რომელიც ყოველ გამოძახებაზე დასაწყისში იცვლება, უფრო ძვირია და უფრო ნელი.

თუ თქვენს აპში AI ფუნქციებს აშენებთ, ჩვენი გიდები რა არის LLM და როგორ გამოვიყენოთ LLM API-ები კონტექსტის ფანჯრებსა და ტოკენებს თავიდანვე ფარავს. მეტი იმაზე, როგორ მუშაობენ ქვე-აგენტები Mythex-ში, ქვე-აგენტების დოკუმენტაციაშია.