ხელოვნური ინტელექტის აგენტების ევოლუცია: სტრუქტურული კოდის გენერაციის უპირატესობა

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