AutoGen თუ CrewAI: მეტი token უკეთეს პასუხს არ ნიშნავს

თუ სამუშაო აგენტების როლებად იყოფა და მისი ეტაპების მდგომარეობა მკაფიოდ უნდა მართოთ, CrewAI კარგი საწყისი არჩევანია: CrewAI-ის დოკუმენტაცია Crews-ს აგენტების თანამშრომლობისთვის, Flows-ს კი პროცესის, მდგომარეობისა და გაგრძელების სამართავად აღწერს. თუ შეტყობინებების მოძრაობისა და აგენტების ურთიერთქმედების უფრო უშუალო კონტროლი გჭირდებათ, AutoGen-ის AgentChat-ისა და Core-ის აღწერა სხვა გზას აჩვენებს: მზა გუნდური სქემები მაღალ დონეზე და მოვლენებზე დაფუძნებული პროგრამირება Core-ში.

ხარჯით არჩევისას პასუხის სისწორე ცალკე შეაფასეთ. AgentRace-ის AlpacaEval-ის MoA ცდაში, სამი მუშა აგენტის პირობებში AutoGen-ის კონფიგურაციას საშუალოდ 3 537 ტოკენი და 36,85 წამი დასჭირდა, CrewAI-ის კონფიგურაციას კი 14 732 ტოკენი და 64 წამი. კვლევის სხვა ამოცანებში ტოკენების რაოდენობასა და სისწორეს შორის ძლიერი კავშირი არ გამოვლენილა. ეს მაჩვენებლები კონკრეტულ სამუშაო სქემებს ეხება; მათგან ნებისმიერი CrewAI Flow-ის ან AutoGen გუნდის ფასის გამოთვლა შეუძლებელია.

ორკესტრაცია: ვინ განსაზღვრავს შემდეგ ნაბიჯს

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

AutoGen-ის AgentChat საწყისად გამზადებულ აგენტებსა და გუნდურ სქემებს იძლევა. Core უფრო დაბალი დონის არჩევანია, როცა აპლიკაციას თავად უნდა განსაზღვროს, ვინ იღებს შეტყობინებას და რა მოვლენაზე რეაგირებს. ეს განსხვავება განსაკუთრებით ჩანს ისეთ პროცესში, სადაც აგენტის პასუხმა შეიძლება სამუშაო სხვა მონაწილეს გადასცეს ან შესრულება შეწყვიტოს. ამასთან, AutoGen-შიც შეიძლება წინასწარ გაწერილი გუნდური გზა, ხოლო CrewAI-შიც შეიძლება განშტოებული Flow; არჩევანი მხოლოდ „როლები თუ მოქნილობა“ არ არის.

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

მდგომარეობა და მოდელისთვის გაგზავნილი ისტორია

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

AutoGen-ის მდგომარეობის მართვის ინსტრუქცია აჩვენებს, როგორ ინახება და აღდგება აგენტისა თუ გუნდის მდგომარეობა save_state() და load_state() მეთოდებით. აგენტის შემთხვევაში შენახული მდგომარეობა მოდელის კონტექსტსაც მოიცავს; გუნდის მდგომარეობა მისი მონაწილეების მდგომარეობას აერთიანებს. აპლიკაციამ მაინც უნდა განსაზღვროს, როდის შეინახოს ეს მონაცემები, სად განათავსოს ისინი და რომელი მდგომარეობა აღადგინოს ახალი მოთხოვნისას.

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

რას ზომავს AgentRace-ის სხვაობა

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

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

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

რა ზრდის ხარჯს პრაქტიკაში

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

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

დანერგვა და მცირე საცდელი შედარება

AutoGen-ის მოდულურობა დაყენებაშიც ჩანს: ინსტალაციის ინსტრუქცია Core პაკეტს მოდელის კლიენტის ცალკე გაფართოებისგან გამოყოფს და მოდელის მიერ გენერირებული კოდის შესასრულებლად Docker executor-ს არჩევით კომპონენტად ასახელებს. ეს განცალკევება მოდელთან კავშირსა და შესრულების გარემოზე კონტროლს იძლევა, თუმცა შესაბამისი კომპონენტების გამართვაც გუნდს ეკისრება. CrewAI-ში ძირითადი საპროექტო გადაწყვეტილება ხშირად ისაა, სად დასრულდეს Crew-ის თანამშრომლობა და სად დაიწყოს Flow-ის განსაზღვრული ნაბიჯი.

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

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

ასევე წაიკითხეთ:

• ChatGPT თუ Perplexity: კვლევაში მეტი წყარო ყოველთვის უკეთეს პასუხს არ ნიშნავს
• CrewAI თუ AutoGen: აგენტების როლები თუ საუბრის მოქნილი მარშრუტი
• AI მცირე ბიზნესს დროს უზოგავს, მაგრამ 86%-ს მეტი დახმარება სჭირდება