სურათი 1: სამი მიდგომის სიზუსტის შედარება: სტრუქტურირებული CodeAgent (ლურჯი), CodeAgent (ნარინჯისფერი) და ToolCallingAgent (ნაცრისფერი) SmolBench-ზე (GAIA, MATH, SimpleQA და Frames). შეცდომის ზოლები წარმოადგენს 95% ნდობის ინტერვალებს. ხელოვნური ინტელექტის აგენტებს სჭირდებათ მოქმედებების განხორციელება რეალურ სამყაროში – იქნება ეს API-ების გამოძახება, მონაცემთა დამუშავება თუ რთული პრობლემების გადაჭრა. თუ როგორ გამოხატავენ აგენტები ამ მოქმედებებს, განვითარდა რამდენიმე პარადიგმის გავლით: ტრადიციული JSON აგენტი: აგენტები აგენერირებენ სტრუქტურირებულ JSON-ს ხელსაწყოების გამოსაძახებლად. ეს აგენტები მოქმედებენ წინასწარ განსაზღვრული ხელსაწყოების სიიდან არჩევით და JSON-ფორმატირებული გამოძახებების გენერირებით. ხელსაწყოების გამოძახების ეს მეთოდი პოპულარული გახდა OpenAI-ის ფუნქციების გამოძახების API-ის წყალობით და მას შემდეგ ყველაზე ფართოდ გამოყენებული მეთოდია ხელსაწყოების გამოსაძახებლად. ის საიმედოა, მაგრამ შეზღუდულია: კოდის აგენტები: აგენტები იყენებენ თავიანთ თანდაყოლილ კოდირების უნარს და უშუალოდ წერენ შესრულებად Python კოდს. ეს ცვლილება, რომელიც პირველად წარმოდგენილი იყო CodeAct-ის სახელით ნაშრომში „შესრულებადი კოდის მოქმედებები იწვევს უკეთეს LLM აგენტებს“, AI აგენტებს მიანიჭა მოქნილობა, რომ ხელსაწყოების გამოძახების გარდა, დაწერონ ნებისმიერი შესრულებადი Python კოდი. ძირითადი იდეა აქ ის არის, რომ ხელსაწყოები უშუალოდ კოდიდან არის გამოძახებული, რაც ცვლადების და მდგომარეობის მართვას ბევრად უფრო საიმედოს ხდის. აგენტებს შეუძლიათ ხელსაწყოების გამოძახება ციკლებში, ფუნქციებსა და პირობით ინსტრუქციებში – არსებითად, თითოეულ მოქმედებაში ხელსაწყოს შესრულების დინამიური გრაფის გენერირებით! CodeAgent-ის გამოყენების უპირატესობები: მიუხედავად იმისა, რომ კოდის აგენტები მოქნილობას გვთავაზობენ, Markdown-დან კოდის გაანალიზება (პარსინგი) შეიძლება შეცდომების წყარო იყოს. ეს მიგვიყვანს წინადადებამდე: რატომ არ გამოვიყენოთ სტრუქტურირებული გენერაცია კოდის მოქმედებების შესაქმნელად? სტრუქტურირებული გამომავლის გამოყენებით, შეგიძლიათ აიძულოთ LLM, შექმნას მკაფიო აზრები და კოდი, როგორც JSON მონაცემთა პაკეტი: ძირითადი განსხვავება ისაა, რომ გენერაცია სავალდებულოა: ძირითადად, ახლა, იმის ნაცვლად, რომ უბრალოდ მოთხოვნა იყოს აზრების, შემდეგ კი კოდის გამოსატანად, სტრუქტურირებული გამომავლის გამოყენება აიძულებს მას დაიცვას სტრუქტურა. ეს მიდგომა სტრუქტურირებული გენერაციის საიმედოობას მატებს კოდის შესრულების მოქნილობას, რითაც მიიღწევა საუკეთესო ორივე სამყაროდან. ჩვენ შევადარეთ ეს სამი პარადიგმა მრავალ ბენჩმარკზე, მათ შორის GAIA, MATH, SimpleQA და Frames. შედეგები აჩვენებს მკაფიო ნიმუშს: კოდის მოქმედებები + სტრუქტურირებული გენერაცია თანმიმდევრულად აუმჯობესებს მუშაობას ძლიერი მოდელებისთვის. ყველაზე ძლიერ მოდელებში, სტრუქტურირებულმა მიდგომამ საშუალოდ 2-7 პროცენტული პუნქტით აჯობა ჩვეულებრივ CodeAgent მიდგომას. ჩვენი CodeAgent-ის იმპლემენტაცია smolagents-ში LLM-ის გამომავლიდან Python კოდს იღებს, რაც შეიძლება წარუმატებელი იყოს მაშინ, როდესაც: სტრუქტურირებული გენერაცია ამ პრობლემებს საიმედო JSON პარსინგით გამორიცხავს. იმის გასაგებად, თუ რატომ არის მნიშვნელოვანი სტრუქტურირებული გენერაცია, ჩვენ გავაანალიზეთ 15,724 აგენტის კვალი ჩვენს ბენჩმარკებზე. შედეგები შთამბეჭდავია: აგენტის კვალი პარსინგის შეცდომების გარეშე 21.3%-ით უფრო ხშირად წარმატებულია, ვიდრე ის, რომელსაც აქვს პარსინგის შეცდომები. ეს არ არის მხოლოდ მოხერხებულობა – პარსინგის შეცდომები იწვევს წარუმატებლობის კასკადს, რაც მნიშვნელოვნად აისახება აგენტის საერთო მუშაობაზე. როდესაც აგენტს არ შეუძლია თავისი პირველი მოქმედების შესრულება არასწორად ფორმატირებული კოდის გამო, ის ხშირად უჭირს აღდგენა, რაც იწვევს პრობლემების გადაჭრის არაოპტიმალურ გზებს. სურათი 2: პარსინგის შეცდომები პირველ ნაბიჯში ამცირებს აგენტის წარმატების მაჩვენებელს 21.3%-ით და ზრდის საშუალო ნაბიჯების რაოდენობას 3.18-დან 4.63-მდე. დამატებით: მსჯელობის იძულებითი პროცესი. სტრუქტურირებული გენერაციისა და მკაფიო აზრების გამოყენება არა მხოლოდ მოუწოდებს, არამედ აიძულებს აგენტებს, ჩამოაყალიბონ თავიანთი მსჯელობა მოქმედებამდე. ეს იწვევს: ჩვენი შედეგები ასევე ცხადყოფს შესაძლებლობების მკაფიო ზღვარს: მოდელებს სჭირდებათ საკმარისი ინსტრუქციების შესრულების უნარი და JSON-ის დაფარვა მათ წინასწარ სავარჯიშო მონაცემებში, რათა ისარგებლონ სტრუქტურირებული გენერაციით. ეს მიუთითებს იმაზე, რომ სტრუქტურირებული მიდგომები საუკეთესოდ მუშაობს: აი, რა ხდება, როდესაც პატარა მოდელი (მაგ., mistralai/Mistral-7B-Instruct-v0.3) ცდილობს სტრუქტურირებული კოდის გენერირებას – კოგნიტური დატვირთვა ზედმეტი ხდება: მოდელი აგენერირებს სინტაქსურად გატეხილ Python კოდს: `web_search(query="Eiffel Tower height")",` – შეამჩნიეთ არასწორად ფორმატირებული სტრიქონი დამატებითი ბრჭყალითა და მძიმით. ეს იწვევს დაუყოვნებლივ SyntaxError-ს და შესრულების წარუმატებლობას. ეს ასახავს „სტრუქტურის გადასახადს“: მცირე მოდელებს უჭირთ ერთდროულად JSON ფორმატირების, Python სინტაქსის და რეალური პრობლემების გადაჭრის ლოგიკის მართვა. სტრუქტურირებული გენერაციის კოგნიტურმა დატვირთვამ შეიძლება გადატვირთოს მოდელები, რომლებიც სხვა შემთხვევაში საკმაოდ კარგად იმუშავებდნენ უფრო მარტივი, Markdown-ზე დაფუძნებული კოდის გენერაციით. ✅ გამოიყენეთ სტრუქტურირებული CodeAgent-ები, როდესაც: ⚠️ განიხილეთ ალტერნატივები, როდესაც: ეს ძალიან მარტივია! უბრალოდ ჩართეთ `use_structured_outputs_internally`-ით: LLM შექმნის მსგავს რამეს: შემდეგ "კოდის" ნაწილი შესრულდება აგენტის მიერ ჩვეულებისამებრ: ეს არის სტანდარტული CodeAgent, მაგრამ ახლა მას აქვს 100% პარსინგის საიმედოობა! ეს კვლევა ვარაუდობს, რომ ჩვენ მივდივართ აგენტის არქიტექტურების უფრო დახვეწილი გაგებისკენ. საქმე მხოლოდ იმაში არ არის, „რა შეუძლია აგენტს?“ არამედ „როგორ უნდა იფიქროს აგენტმა იმაზე, რასაც აკეთებს?“ შესაძლოა, მსჯელობის პროცესის უფრო მკაფიო გახდა მოდელს ეხმარება სწორ გზაზე დარჩენაში. ან შესაძლოა, ის უბრალოდ უფრო ადვილია პარსინგისთვის. ნებისმიერ შემთხვევაში, ეს გამარჯვებაა. მაგრამ ეს მხოლოდ დასაწყისია.