აგენტების უკეთესი მუშაობისკენ სწრაფვისას AI გუნდების უმეტესობა ერთსა და იმავე ბერკეტებს იყენებს: უფრო დიდ კონტექსტურ ფანჯრებს, მეტ დოკუმენტსა და უკეთეს მოთხოვნებს. ამ სტატიის თანახმად, ეს მიდგომა სრულიად მცდარია. დაკარგული კომპონენტი მეტი ინფორმაცია არ არის. ეს კონტროლია. სწორად დაპროექტებული კონტროლის შრე განასხვავებს დემოში მომუშავე აგენტს საწარმოო გარემოში მომუშავე აგენტისგან.
AI აგენტისთვის უფრო დიდი მეხსიერების, მეტი დოკუმენტის ან უფრო გრძელი კონტექსტური ფანჯრის მიცემა მას უფრო ჭკვიანს არ ხდის — მხოლოდ ანელებს და აძვირებს. რეალურ გაუმჯობესებას მაშინ იღებთ, როცა აგენტს ასწავლით, აირჩიოს რა და როდის სჭირდება, ნაცვლად იმისა, რომ ყველაფერი ერთდროულად გამოიყენოს.
საიმედოობას ციკლი უზრუნველყოფს და არა მოდელი. დემოში შთამბეჭდავ და საწარმოო გარემოში გამძლე აგენტებს AI-ის ხარისხი კი არ განასხვავებს, არამედ ის, ამოწმებს თუ არა სისტემა საკუთარ ნამუშევარს. აგენტები, რომლებიც ყოველ ეტაპზე გეგმავენ, მოქმედებენ, აკვირდებიან და ამოწმებენ, საკუთარ შეცდომებს აღმოაჩენენ, ნაცვლად იმისა, რომ თავდაჯერებულად ცდებოდნენ.
დღევანდელი AI აგენტების უმეტესობა, არსებითად, დამატებითი ნაბიჯების მქონე ჩატბოტებია — მათ არ აქვთ მექანიზმი, რომელიც განსაზღვრავს, სწორ გზაზე არიან თუ არა, როდის შეჩერდნენ ან როდის სცადონ სხვა მიდგომა. სათანადო კონტროლის შრის — წარმატების მკაფიო კრიტერიუმების, სტრუქტურირებული მდგომარეობისა და ვალიდაციის შემოწმებების — დამატება აგენტის მსგავს ობიექტს რეალურად სანდო სისტემად აქცევს.
გუშინ სადილად რა მიირთვით?
ალბათ, ყველა მოგონება თავიდან არ გაგიმეორებიათ, სანამ „გუშინ + სადილამდე“ მიხვიდოდით. პირდაპირ გამოცდილების იმ ნაწილზე გადახვედით, სადაც ეს ცნებები ინახება. ეს აგენტების შესაქმნელად სასარგებლო აზრობრივი მოდელია:
უზარმაზარი კონტექსტური ფანჯარა მეხსიერება არ არის.
მოძიებული დოკუმენტების გროვა გაგება არ არის.
გრძელი აზროვნების ჯაჭვი საიმედოობა არ არის.
ეს მხოლოდ ინგრედიენტებია. თუმცა ის, რის გამოც აგენტი აგენტად აღიქმება, იგივეა, რაც თქვენს ტვინს მთელი ცხოვრების ისტორიის უხეში ძალით გადამუშავებისგან იცავს: კონტროლი.
ბოლოდროინდელმა მიმოხილვამ — Agentic Reasoning for Large Language Models — შესანიშნავად შეაჯამა და დაასახელა ცვლილება, რომელსაც ბევრი ჩვენგანი სისტემების შექმნისას გრძნობს: მოდელის შიგნით მსჯელობიდან ინტერაქციით მსჯელობაზე გადასვლა. ეს პოსტი იმ ნაშრომის შეჯამება არ არის. ეს ცვლილების პრაქტიკული სისტემური დიზაინის ენაზე გადმოტანის მცდელობაა:
თუ აგენტებს ხელსაწყოებიანი ჩატბოტების მსგავსად შექმნით, ჩატბოტებისთვის დამახასიათებელ შეცდომებს კვლავ მიიღებთ — ოღონდ უფრო ძვირადღირებულს.
ერთხანს „მოდელის გაუმჯობესების“ ჩვენი ნაგულისხმევი გეგმა, არსებითად, ასეთი იყო: უკეთესი მოთხოვნები, აზროვნების ჯაჭვი, თვითთანმიმდევრულობა / შერჩევაზე დაფუძნებული გაუმჯობესებები და შესაძლოა გარკვეული ძიებაც.
ReAct გარდამტეხი მომენტი იყო, რადგან „აზრი → მოქმედება → დაკვირვება“ ბუნებრივ პროცესად წარმოაჩინა. მაგრამ დააკვირდით ფარულ შეზღუდვას: ამის დიდი ნაწილი კვლავ „ერთმაგალითიან ინფერენციად, ოღონდ მეტი ტოკენით“ იქცევა. მიმოხილვის ფორმულირება უფრო ზუსტია: აგენტური მსჯელობა ხაზს უსვამს ტესტირებისას ინტერაქციის მასშტაბირებას — ინფერენცია გარდაიქმნება განმეორებად პროცესად, რომლის ციკლშიც მოდელი, მეხსიერება და გარემო მუდმივად რჩება.
თუ შეგიქმნიათ ან გამოგიყენებიათ აგენტები, რომლებიც დემოში შთამბეჭდავია, რეალურ სამუშაო პროცესებში კი მყიფე, ეს თქვენთვისაა.
აღვწერ ნიმუშს, რომელიც ხშირად მინახავს და რომლის ვერსიებიც თავადაც ნამდვილად შემიქმნია:
აიღეთ კარგი სასაუბრო მოდელი
დაამატეთ რამდენიმე ხელსაწყო (ძიება, მონაცემთა ბაზის მოთხოვნა და შესაძლოა კოდის შესრულება)
დაამატეთ RAG
დაამატეთ სისტემური მოთხოვნა “you are an autonomous agent”
ყველაფერი while-ციკლში მოაქციეთ, სანამ არ შეჩერდება ან დრო არ ამოიწურება
გილოცავთ, აგენტის მსგავსი ობიექტი გაქვთ. მაგრამ ის, როგორც წესი, პროგნოზირებადი გზებით მარცხდება:
კონტექსტის გაბერვა: ყოველი დაკვირვება ემატება; მოთხოვნები არქეოლოგიურ ფენებად იქცევა.
ხელსაწყოების უმიზნო ცვლა: „არასწორი ხელსაწყო, მაგრამ თავდაჯერებულად“ შეცდომის ნაგულისხმევ სახედ იქცევა.
შეჩერების პირობების არქონა: აგრძელებს იმიტომ, რომ შეუძლია და არა იმიტომ, რომ საჭიროა.
სანდო წყაროებთან დაკავშირების დისციპლინის არქონა: ვერ ამჩნევს, რომ ცდება, თუ ამას არ აიძულებთ.
მეხსიერება = ჩატის ისტორია: რაც, არსებითად, ჟურნალების წერაა, რომელსაც სწავლას უწოდებენ.
ამიტომ „აგენტები“ დემოში ხშირად ჯადოსნურად გამოიყურებიან, საწარმოო გარემოში კი უწესრიგოდ. ამასვე ადასტურებს აგენტური სისტემების საწარმოო გარემოში დანერგვის ჩვენი გამოცდილება: როცა უკვე მოდელს კი არა, სისტემას აფასებთ, შეცდომების სახეები მოიცავს ნავიგაციას, ხელსაწყოების მართვის წესრიგს, კონტექსტის შეკვეცასა და შეფასების დიზაინს და არა მხოლოდ კითხვას: „სწორად უპასუხა თუ არა მოდელმა?“
ამიტომ ჩნდება კითხვა: როგორია მიზნობრივი აგენტი?
ნაკლებად აბსტრაქტული რომ იყოს, წარმოგიდგენთ მარტივ სამუშაო პროცესს, რომლის წარმოდგენაც ადამიანების უმეტესობას შეუძლია: “Book me a flight from London to New York next Tuesday. Arrive before 6pm. Keep it under £900. Aisle seat.”
„აგენტის მსგავსი“ გავრცელებული იმპლემენტაცია ასე გამოიყურება:
დაუყოვნებლივ მოიძიებს ავიაკომპანიებისა და მოგზაურობის წესების უამრავ დოკუმენტს, მაშინაც კი, თუ ჯერ არცერთი არ არის საჭირო.
გამოიძახებს საძიებო ხელსაწყოს, შედეგების გრძელ სიას მოთხოვნაში ჩასვამს და „ერთ-ერთს აირჩევს“.
ნაადრევად ჯავშნის, შეზღუდვების (ჩასვლის დროის / ბარგის / ადგილის / წესების) შეუმოწმებლად.
წარუმატებლობის შემთხვევაში ოდნავ განსხვავებული გზით იმეორებს ცდას, თუმცა მკაფიოდ არ ესმის, რა შეიცვალა ან რა ისწავლა.
პრობლემა ის კი არ არის, რომ მოდელს მსჯელობა არ შეუძლია, არამედ ის, რომ სისტემა სამუშაო პროცესს ვერ აკონტროლებს.
უფრო აგენტური ვერსია ამოცანას განიხილავს ინტერაქციულ პროცესად, რომელსაც მკაფიო მდგომარეობა და შემოწმებები აქვს:
დაგეგმვა: შეზღუდვების გამეორება და დაკარგული ინფორმაციის ჩამოთვლა (მაგ., „რომელ აეროპორტს ანიჭებთ უპირატესობას?“ / „ერთი გადაჯდომა მისაღებია?“).
მოქმედება: ფრენების ძიების გამოძახება სტრუქტურირებული მოთხოვნით (თარიღის დიაპაზონი, ჩასვლის დროის შეზღუდვა, ბიუჯეტი).
დაკვირვება: შედეგების შენახვა მდგომარეობის კომპაქტურ ობიექტში (5 საუკეთესო ვარიანტი ფასით/ჩასვლის დროით/გადაჯდომებით) და არა ჩასმული ტექსტის უზარმაზარ გროვად.
განახლება: მოთხოვნის დახვეწა, თუ შეზღუდვები არ სრულდება (მაგ., „საღამოს 6 საათამდე ჩასვლა ზედმეტად მკაცრი მოთხოვნაა — გავაფართოოთ დროის დიაპაზონი თუ გავზარდოთ ბიუჯეტი?“).
შემოწმება: ვალიდატორების გაშვება („ჩასვლა < 18:00“, „ფასი ≤ £900“, „წესებთან შესაბამისობა“, „ადგილის არჩევა ხელმისაწვდომია“).
შეჩერება: მხოლოდ მას შემდეგ, რაც დაჯავშნის API დადასტურებას დააბრუნებს და ყველა ვალიდატორი წარმატებით შესრულდება.
ცვლილება შეუმჩნეველი, მაგრამ გადამწყვეტია. მოძიება პირობითია და არა რეფლექსური, კონტექსტი მართვადია — მდგომარეობა სტრუქტურირებულია და არ გროვდება — ხოლო შემოწმება ციკლშია ჩართული და მომხმარებელზე არ არის დატოვებული. „ავიაბილეთის დაჯავშნა“ ჩაანაცვლეთ „შესყიდვის შეკვეთის შექმნით“, „თანხის დაბრუნებით“, „საწარმოო კონფიგურაციის შეცვლით“ ან „PR-ის გამოშვებით“ და სურათი იგივე იქნება: როგორც კი აგენტს მოქმედება შეუძლია, ციკლი მოთხოვნაზე მნიშვნელოვანი ხდება.
ზემოხსენებული მიმოხილვა აგენტურ მსჯელობას სამ შრედ აყალიბებს: საბაზისო (დაგეგმვა/ხელსაწყოების გამოყენება/ძიება), თვითგანვითარებადი (უკუკავშირი + მეხსიერება) და კოლექტიური (მრავალაგენტიანი კოორდინაცია).
თუმცა უფრო ღრმა აზრი ასეთია: მსჯელობა დაგეგმვის, გადაწყვეტილების მიღებისა და შემოწმების მაორგანიზებელ პრინციპად იქცევა და არა უბრალოდ დამაჯერებელი აზროვნების ჯაჭვის შექმნის საშუალებად. ეს აბსტრაქტულად ჟღერს, სანამ თქვენს არქიტექტურაში მომხდარ ცვლილებებს არ შეუსაბამებთ. სამი ძირითადი საკითხი უნდა გახსოვდეთ:
კარგი აგენტისთვის მოძიება „ყოველთვის შესასრულებელი“ არ უნდა იყოს. მოძიება გადაწყვეტილებაა და არა რეფლექსი.
აი, პრაქტიკული ევრისტიკა:
თუ თქვენი სისტემა ყოველ ჯერზე ასრულებს მოძიებას, თქვენ მოძიება კი არა, კონტექსტის გადასახადი შეგიქმნიათ.
რეალურ სამუშაოში ეს მუდმივად გვხვდება. საწარმოო ინციდენტის გამართვისას ყველა ჟურნალს კონტექსტში არ ყრით; მიმდინარე ჰიპოთეზის მიხედვით წყვეტთ, შემდეგ რომელი მეტრიკები ან ჟურნალები მოიძიოთ. ეს „აგენტური მოძიებაა“. აი, უფრო კონკრეტული ნიმუში:
გადაწყვიტეთ, გჭირდებათ თუ არა მოძიება
თუ დიახ: შეადგინეთ მოთხოვნა, მოიძიეთ, გადახედეთ და ამოიღეთ საჭირო ინფორმაცია
თუ მტკიცებულებები ერთმანეთს ეწინააღმდეგება: ხელახლა მოიძიეთ
მხოლოდ ამის შემდეგ შეაჯამეთ
აქვე იწყება „აგენტური RAG-ის“ განსხვავება ტრადიციული RAG-ისგან: მოძიება მსჯელობის გააზრებული ნაბიჯი ხდება და არა კონვეიერის ნაგულისხმევი ეტაპი.
როგორც კი „მოდელის“ შეფასებიდან „სისტემის“ შეფასებაზე გადადიხართ, მდგომარეობის აღრიცხვა და პროცესის მიკვლევა მნიშვნელოვანი ხდება.
ამ დროისთვის ინდუსტრიამ აგენტების სამუშაო პროცესების დაკვირვებადობის მნიშვნელობა უფრო მკაფიოდ აღიარა. მაგალითად, OpenAI-ის Agents SDK-ს ჩაშენებული მიკვლევის ფუნქცია და Traces-ის საინფორმაციო დაფა მოჰყვება. ის აგენტის გაშვებებს (გენერაციებს, ხელსაწყოების გამოძახებებს, გადაბარებებს, დამცავ მექანიზმებსა და მორგებულ მოვლენებს) აღრიცხავს, რათა მომხდარი ეტაპობრივად გამართოთ და შეამოწმოთ.
ეს უბრალოდ „კარგი დამატება“ არ არის. სწორედ ეს განასხვავებს სისტემას, რომლის გამართვაც შეგიძლიათ, სისტემისგან, რომლის შეფასებაც მხოლოდ ინტუიციით გიწევთ.
ჩემი აზრით, მიმოხილვის ყველაზე პრაქტიკული ნაწილი უკუკავშირის შესახებ მისი პირდაპირი მიდგომაა. იგი უკუკავშირს სამ რეჟიმად ყოფს: რეფლექსიური უკუკავშირი (შექმნა → კრიტიკა → გადახედვა), პარამეტრული ადაპტაცია (სწავლა დამატებითი გაწვრთნით / RL-ით) და ვალიდატორზე დაფუძნებული უკუკავშირი (განმეორება ვალიდატორის წარმატებით გავლამდე).
გუნდების უმეტესობამ ვალიდატორზე დაფუძნებული უკუკავშირით უნდა დაიწყოს, რადგან ის მოსაწყენი, მაგრამ ეფექტურია. თუ შეგიძლიათ დაწეროთ ნებისმიერი ვალიდატორი, რომელიც მოდულურ ტესტებს ატარებს, სქემას ამოწმებს, ბიზნესწესებსა და შეზღუდვებს ადგენს („X-ზე მეტი თანხა ესკალაციის გარეშე არ დაბრუნდეს“) ან ფაქტობრივ სისწორეს უზრუნველყოფს („ციტირებები სავალდებულოა“), მაშინ მოდელის არადეტერმინისტულ შედეგს რეალურად სანდო შედეგად აქცევთ.
აქ ერთ-ერთი მოულოდნელი ცვლილება მარტივია: აგენტების სამყაროში საიმედოობას ხშირად ციკლი უფრო უზრუნველყოფს, ვიდრე მოდელი.
ეს არის ციკლის უმარტივესი დისციპლინა, რომელიც, ჩემი გამოცდილებით, გაწვრთნის გარეშე საიმედოდ აუმჯობესებს ქცევას:
იმუშავეთ ეტაპებად: დაგეგმვა → მოქმედება → დაკვირვება → განახლება,
ყოველი მოქმედების შემდეგ დაკვირვება 1–3 პუნქტად შეაჯამეთ,
შეჩერდით, როცა წარმატების კრიტერიუმები დაკმაყოფილდება ან ბიუჯეტი ამოიწურება; დააბრუნეთ საუკეთესო ცნობილი შედეგი და დარჩენილი გაურკვევლობები.
მიზანი მოდელის სიტყვაუხვად ქცევა არ არის. მიზანია, სისტემა გასაგები გახდეს და ყოველ ეტაპზე „რეალობასთან შეხება“ აიძულოთ. ინჟინრებისთვის განსაკუთრებით ნაცნობი მაგალითია CI-ის ტიპის, დახურული ციკლით სანდო წყაროებთან დაკავშირება:
დაგეგმვა: ცვლილებების სიის შეთავაზება
მოქმედება: ტესტების / ლინტერის გაშვება
დაკვირვება: შეცდომების დამუშავება
განახლება: შესწორება და ხელახლა ცდა
რამდენიმე კითხვა, რომლებიც შემთხვევით შექმნილ აგენტურ დიზაინს ხშირად ამხელს:
„ჩემი აგენტი თავად წყვეტს, რა მოიძიოს, თუ მოძიებას ყოველთვის ვასრულებ?“
თუ მოძიება უპირობოა, ამის საფასურს გადაიხდით დაყოვნებით, ხარჯით, კონტექსტის განზავებითა და უხარისხო შემავალი მონაცემებიდან უხარისხო შედეგის მიღების გაზრდილი რისკით.
„შეუძლია ჩემს აგენტს შეამჩნიოს, რომ ცდება?“
თუ თქვენი აგენტის უკუკავშირის ერთადერთი სიგნალი „მომხმარებლის გაღიზიანებაა“, თქვენ RL-ს ადამიანის ტანჯვის ხარჯზე ახორციელებთ. ვალიდატორზე დაფუძნებული განმეორების ციკლი მისთვის რეალობის შესამოწმებლად ყველაზე გამართული გზაა.
„შესაძლებელია მეხსიერებაში ჩაწერა და უმჯობესდება ის დროთა განმავლობაში?“
თუ თქვენი „მეხსიერება“ მხოლოდ ჩატის ისტორიის დამატებაა, სინამდვილეში ჟურნალებს წერთ. მნიშვნელოვანია, როგორ წარმოაჩენს მიმოხილვა მეხსიერებას: ის დინამიკურად მზარდ კონტექსტად იქცევა, რომელსაც აგენტები დროთა განმავლობაში ხვეწენ და არა უბრალოდ ჩანაწერად.
ჟურნალები გეუბნებათ, რა მოხდა, მეხსიერება კი — რა უნდა გააკეთოთ შემდეგ ჯერზე. ჩატის ისტორია საუბრის ჩანაწერია. მეხსიერება განვითარებადი წესების ერთობლიობაა იმის შესახებ, თუ რისი შენარჩუნება ღირს მომავალში.
დასაწყებად გამოგადგებათ პატარა ცხრილი „მიღებული გაკვეთილები“, რომლის გასაღები ამოცანის ტიპს, ხელსაწყოსა და შეცდომის სახეს აერთიანებს, მნიშვნელობა კი აღწერს, რამ იმუშავა და რას უნდა მოერიდოთ. მიზანი იდეალური ცოდნის გრაფის შექმნა არ არის. მიზანი დაგროვებითი გაუმჯობესებაა: მეხსიერება და უკუკავშირი აგენტებს „მდგომარეობის არმქონე დამხმარეებიდან“ დროთა განმავლობაში გაუმჯობესებად სისტემებად აქცევს.
მაცდურია პრობლემისთვის მეტი აგენტის მიყენება, თუმცა ეს ხშირად კოორდინაციის ზედნადებ ხარჯს ამრავლებს. „მინიმალურად სიცოცხლისუნარიანი გუნდის“ კარგი ნიმუში:
კოორდინატორი: შლის ამოცანებად და ანაწილებს
შემსრულებელი: იძახებს ხელსაწყოებს / ახორციელებს ცვლილებებს
კრიტიკოსი/შემფასებელი: ამოწმებს სისწორეს/რისკს
მეხსიერების მცველი: იწერს/აწესრიგებს გაკვეთილებს
თუ ვერ ხსნით, რაზეა პასუხისმგებელი თითოეული აგენტი, ალბათ რამდენიმე აგენტი ჯერ არ გჭირდებათ.
თუ პარადიგმის ცვლილებას ნამდვილად ვაღიარებთ, ალბათ შევწყვეტთ მოთხოვნებში ყველაფრის ჩატენვას, წარუმატებლობის საბოლოო შედეგად მიჩნევასა და აგენტების ჩატბოტებივით შეფასებას. ამის ნაცვლად, აგენტებს ისე მივუდგებით, როგორც სინამდვილეში არიან: პროგრამულ სისტემებად, სადაც ენა მართვის შრეა, საიმედოობას კი ციკლი უზრუნველყოფს.
სხვა მოდელის დამატებამდე შეფასების კიდევ ერთი ციკლი დაამატეთ. სანამ ყველაფერს მოიძიებთ, მოძიება პირობითი გახადეთ. ათი ვალიდატორის გამოშვებამდე ერთი გამოუშვით. მეხსიერებას მოეპყარით როგორც წესების შესახებ გადაწყვეტილებებს და არა როგორც მონაცემთა ბაზას. ხოლო მრავალაგენტიან სისტემაზე გადასვლისას ორი აგენტით დაიწყეთ და არა ოცით. ეს წესები არ არის — ეს ის ნიმუშებია, რომლებმაც საწარმოო გარემოს გამოცდას გაუძლო.