Asana: GPT‑6.1 Sol-ით ტესტებში 76-ჯერ ნაკლები ხარჯი

Codex-ში GPT‑6 Astra-ს მიერ ჩატარებული ექსპერიმენტებით Asana-მ GPT‑6.1 Sol-ზე ბრაუზერის აგენტის სამუშაო პროცესი ისე დახვეწა, რომ ის 76-ჯერ იაფი და 5-ჯერ სწრაფი გახდა.

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

Asana-ში StackAI-ის ტექნიკურმა დირექტორმა, დოქტორმა ფრენკ იდალგომ, ბრაუზერის აგენტის დაჩქარება და მისი მუშაობის გაიაფება დაისახა მიზნად. მან Codex-ში GPT‑6 Astra-ს აგენტის შესწავლა, გაუმჯობესებების გამოცდა და შედეგების შედარება დაავალა. მისი შეფასებით, საქმეს, რომელსაც ხელით ერთი-ორი თვე დასჭირდებოდა, დაახლოებით ერთი კვირა დასჭირდა.

Asana-ს კვლევაში, რომელიც 144 გაშვებას მოიცავდა⁠(იხსნება ახალ ფანჯარაში), გამოსცადეს GPT‑6.1 Sol და სამი სხვა მოწინავე მოდელი, რომლებსაც აქ A, B და C მოდელებს ვუწოდებთ. GPT‑6.1 Sol-ზე ოპტიმიზებულ პროცესში მოდელის სავარაუდო ხარჯი საშუალოდ $0.47 იყო, შესრულების დრო კი — დაახლოებით ოთხი წუთი თითო გაშვებაზე. ეს 76-ჯერ იაფი და 5-ჯერ სწრაფი იყო, ვიდრე რეალურ სამუშაო გარემოში მოდელ B-ზე თავდაპირველი კონფიგურაცია.

საქმის დასაჩქარებლად იდალგომ Codex-ში GPT‑6 Astra-ს ჯერ კოდური ბაზის სტრუქტურის შესწავლა და იმის ახსნა სთხოვა, თუ როგორ ქმნიდა აგენტი მოდელისთვის თითოეულ მოთხოვნას. GPT‑6 Astra-მ აღმოაჩინა, რომ აგენტი ქეშში ინახავდა უცვლელ ინსტრუქციებსა და ხელსაწყოების განსაზღვრებებს, მაგრამ არა გვერდებიდან მოგროვილი ტექსტისა და ეკრანის ანაბეჭდების მზარდ ისტორიას. ამიტომ ყოველი მოთხოვნა ამ ისტორიას სრული ფასით ხელახლა აგზავნიდა.

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

იდალგომ GPT‑6 Astra-ს შემოთავაზებული შესწორებები განიხილა და გამოსაცდელად სამი შეარჩია:

• აგენტის ბრაუზერში მუშაობის ისტორიის ქეშირებაც

• შესანახი ტექსტის მოცულობის გაზრდა

• ეკრანის ანაბეჭდების ჯგუფურად წაშლა, ნაცვლად ყოველ ნაბიჯზე წაშლისა

GPT‑6 Astra-მ მოკლე ტესტებით დაიწყო, რათა დაედგინა, რომელი ცვლადები იყო მნიშვნელოვანი. კოდი კონტროლირებადი ექსპერიმენტებისთვის არ იყო შექმნილი, ამიტომ შემდეგ მისი რეფაქტორინგი ჩაატარა: ერთ ფრონტენდსა და ბექენდს მრავალი პროცესის პარალელურად გაშვება შეეძლო, თითოეულს — საკუთარი პარამეტრებით.

Astra-მ სრული კვლევა ჩაატარა: ისტორიისთვის 120 000 და 480 000 სიმბოლოს ლიმიტები და ქეშირებისა და ეკრანის ანაბეჭდების მართვის ექვსი სტრატეგია ოთხივე მოდელზე სამ-სამჯერ გამოცადა (იხილეთ ცხრილი ქვემოთ). საუკეთესო სტრატეგია ეკრანის ანაბეჭდებს 20-მდე აგროვებდა, შემდეგ კი მხოლოდ უახლესს ტოვებდა. ასე წაშლებს შორის ძველი ისტორია უფრო დიდხანს რჩებოდა უცვლელი. ისტორიის გაზრდილ ლიმიტთან ერთად სწორედ ეს იქცა ოპტიმიზებულ სამუშაო პროცესად. ყველა კონფიგურაცია ერთ დავალებას ასრულებდა: საჯარო სადემონსტრაციო კატალოგიდან 32 წიგნისთვის ექვს-ექვსი ველის მონაცემებს აგროვებდა. ეს ასახავდა სამუშაოს, რომელსაც Asana-ს ზოგი მომხმარებელი StackAI-ში ასრულებს.

GPT‑6 Astra-მ პროცესები გაუშვა და მოთხოვნები, მოხმარების ჩანაწერები და შედეგები შეისწავლა; ნამუშევარი მოდელის ცალკეულ სესიებში გადამოწმდა. ყოველი სესიის მოთხოვნები, მონაცემთა კვალი და შედეგები Asana-ს პროგრამული უზრუნველყოფის მიწოდების პლატფორმა Command⁠(იხსნება ახალ ფანჯარაში)-ში აღირიცხა, რათა გუნდს მოგვიანებით მთელი კვლევის გადახედვა შეძლებოდა. Command-ში მიგნებები ჯერ დავალებებად, შემდეგ კოდის შერწყმის მოთხოვნებად იქცა, ცვლილებები კი რეალურ სამუშაო გარემოში დაინერგა.

მოდელ B-ზე ოპტიმიზაციამ თითო გაშვების სავარაუდო ხარჯი სულ მცირე $36.21-დან $1.24-მდე, ანუ 29-ჯერ შეამცირა (ზოგი თავდაპირველი გაშვება დასრულებამდე აღწევდა ნაბიჯების ლიმიტს). GPT‑6.1 Sol-ზე ოპტიმიზებული პროცესი კიდევ 2.6-ჯერ იაფი იყო — $0.47. ოპტიმიზებული პროცესის ყოველი გაშვება დავალებას ასრულებდა და სწორ პასუხს აბრუნებდა.

მხოლოდ GPT‑6.1 Sol-ის შემთხვევაში, ისტორიის გაზრდილი ლიმიტით, ქეშირებისა და ეკრანის ანაბეჭდების ახალმა სტრატეგიამ თითო გაშვების ხარჯი 4-ჯერ — $1.97-დან $0.47-მდე შეამცირა. თითოეული გამოძახება დაახლოებით 3-ჯერ გაიაფდა, რადგან შეყვანილი მონაცემების 89% ქეშიდან მოდიოდა და არაქეშირებული მონაცემების ფასის 5% ჯდებოდა. შესრულებაც დაჩქარდა: მოდელ B-ზე თავდაპირველ კონფიგურაციას სულ მცირე 22.5 წუთი სჭირდებოდა, GPT‑6.1 Sol-ზე ოპტიმიზებულ პროცესს კი — დაახლოებით ოთხი წუთი.

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

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

Asana ახლა Codex-ში GPT‑6 Astra-ს პროდუქტის ფუნქციების გამოშვებამდე ტესტირებისთვის იყენებს: Astra პლატფორმაზე გადაადგილდება, სხვადასხვა მონაცემს ცდის და ხარვეზებს ხარისხის კონტროლის სპეციალისტებს ატყობინებს. იდალგოსთვის ეს პროგრამული უზრუნველყოფის განვითარების ახალი სასიცოცხლო ციკლის საფუძველია, სადაც ღრუბლოვან გარემოში აგენტის მრავალი სესია ფუნქციებს პარალელურად ამოწმებს.

სრული კვლევა ხელმისაწვდომია Asana⁠(იხსნება ახალ ფანჯარაში)-სა და StackAI⁠(იხსნება ახალ ფანჯარაში)-ის ბლოგებზე.