მნიშვნელოვანია, ყურადღებით განსაზღვროთ, როგორ და სად მიიღება გადაწყვეტილებები თქვენს აგენტურ სისტემაში.
თუ მეტ გადაწყვეტილებას LLM-ს მიანდობთ, სისტემამ შესაძლოა მეტი ტიპის ამოცანის განზოგადება შეძლოს, თუმცა სიჩქარის, საიმედოობისა და მდგრადობის შესაძლო გაუარესების ხარჯზე.
შეძლებისდაგვარად, ეცადეთ გადაწყვეტილების მიღების პროცესი მაქსიმალურად გადაიტანოთ LLM-იდან ცალსახად გაწერილ პროგრამულ კოდში. ეს განსაკუთრებით მნიშვნელოვანია მაღალი რისკის მქონე და/ან საწარმოო სამუშაო პროცესებისთვის.
LLM-ზე დაფუძნებული აგენტური სისტემის შექმნისას ერთ-ერთი უმნიშვნელოვანესი არჩევანია, გადაწყვეტილების მიღების რა ნაწილი უნდა მოიცვას LLM მოდელმა და რა ნაწილი — ცალსახად გაწერილმა პროგრამულმა უზრუნველყოფამ.
ამ არჩევანის უკეთ გასაგებად, ის შეგვიძლია შემდეგ მიდგომებს შორის არსებულ სპექტრად წარმოვიდგინოთ:
როუტერზე დაფუძნებული არქიტექტურები მოქმედებათა თანმიმდევრობასა და ლოგიკას კოდში ცალსახად განსაზღვრავს, რაც ვიწრო სფეროს ამოცანებისთვის ტესტირებადობას, პროგნოზირებადობასა და მდგრადობას უზრუნველყოფს (მათ ასევე „სამუშაო პროცესის აგენტებს“ უწოდებენ).
ორკესტრატორი აგენტები დიდ ენობრივ მოდელებს (LLM-ებს) ეყრდნობა, რათა ბუნებრივ ენაზე დაწერილი მოთხოვნების საფუძველზე დინამიკურად განსაზღვროს ამოცანების შესრულების მიმდინარეობა. ეს მიდგომა იდეალურია ღია ტიპის ინტერაქციებისთვის, როცა წინასწარ გაწერილი ლოგიკა არასაკმარისი ან შეუძლებელია.
მაღალი რისკის მქონე საწარმოო სამუშაო პროცესებისთვის, როგორც წესი, მეტ როუტერულ ფუნქციას გირჩევთ, ორკესტრატორები კი უმჯობესია გამოიყენოთ აპლიკაციებში, რომლებსაც მოქნილი, ზოგადი დანიშნულების საუბრები სჭირდება.
როუტერზე დაფუძნებული არქიტექტურები
როუტერული აგენტური სისტემები:
გადაწყვეტილების მიღების პროცესს კოდით/პროგრამული უზრუნველყოფით ცალსახად განსაზღვრავს, ხოლო LLM-ს იმის დასადგენად იყენებს, თუ რომელი მარშრუტი უნდა აირჩიოს პროგრამამ.
უფრო ჰგავს ტრადიციულ პროგრამულ სისტემებს, რადგან აქვს მკაფიო და პროგნოზირებადი გზები, რომლებიც უფრო თანმიმდევრულ შედეგებს იძლევა.
იდეალურია მკაცრად განსაზღვრადი ამოცანებისთვის.
ქვემოთ მოცემულია ავიაბილეთების დაჯავშნის ჩატბოტ-აგენტის მარტივი მაგალითი, რომელიც „როუტერის მიდგომას“ იყენებს. LLM გვეხმარება შეკითხვის განზრახვის კლასიფიცირებაში სამი შესაძლო ვარიანტიდან, თუმცა საბოლოოდ სწორედ ჩვენი პროგრამული უზრუნველყოფა აკავშირებს ამ განზრახვას პასუხის შაბლონურ ტექსტთან. რადგან LLM მკაცრად შეზღუდულია, მომხმარებელი უფრო თანმიმდევრულ ქცევას მიიღებს.
ორკესტრატორული არქიტექტურები
როუტერული სისტემისგან განსხვავებით, ორკესტრატორული აგენტური სისტემები:
ლოგიკურ პროცესებს პროგრამული უზრუნველყოფის ნაცვლად ბუნებრივ ენაზე დაწერილი მოთხოვნებით განსაზღვრავს. შენიშვნა: პროგრამირების ენასთან შედარებით, ბუნებრივი ენა არსებითად ორაზროვანი და მოქნილია (როგორც მოგვიანებით განვიხილავთ, ეს თვისება დადებითიცაა და უარყოფითიც). ამას ვუწოდებთ „განზრახვას ინსტრუქციის ნაცვლად“.
შეუძლია დამუშავების რამდენიმე ვარიანტის შეთავაზება, შესრულების თანმიმდევრობასა და მეთოდს კი LLM განსაზღვრავს.
შეუძლია დინამიკურად შექმნას ახალი ლოგიკური გზები, რომელთა პროგრამულ უზრუნველყოფაში ცალსახად გაწერა რთულია.
ამ ორაზროვნებამ შეიძლება არათანმიმდევრული შედეგები გამოიწვიოს, თუმცა წარმატების შემთხვევაში ეფექტი „ჯადოსნურია“.
შემდეგ მაგალითში იმავე მარტივ ავიაკომპანიის ამოცანას ორკესტრატორის მიდგომა აქვს მორგებული. იმის ნაცვლად, რომ შესაბამისი პასუხი პროგრამულმა უზრუნველყოფამ განსაზღვროს, გადაწყვეტილების მიღება LLM-ის შრეს გადაეცემა. აქ გვაქვს მრავალაგენტიანი სისტემა, რომელშიც „მთავარი“ ორკესტრატორი აგენტი მომხმარებლის მოთხოვნას ახარისხებს და გადასცემს ფრენის შეცვლაზე სპეციალიზებულ აგენტს, რომელიც საბოლოოდ მომხმარებელს პასუხობს.
ამ მაგალითში LLM-ის შრე კლასიფიკატორის, როუტერისა და პასუხის ავტორის როლებს ასრულებს. როუტერის მაგალითში ის მხოლოდ კლასიფიკატორის როლს ასრულებდა, დანარჩენს კი პროგრამული უზრუნველყოფა უზრუნველყოფდა.
სადაც შესაძლებელია, გირჩევთ როუტერზე დაფუძნებული მიდგომის გამოყენებას, რადგან მას შემდეგი უპირატესობები აქვს:
სიჩქარე და ეფექტიანობა: ლოკალური გამოთვლები გაცილებით სწრაფია, ვიდრე გარე API-ზე დამოკიდებული ორკესტრატორები. გარდა ამისა, თქვენი „IF/ELSE“ ლოგიკის python-ში დამუშავება გაცილებით იაფია, ვიდრე LLM-ის მომწოდებლისთვის თანხის გადახდა, რათა მან ეს 400-მილიარდპარამეტრიანი მოდელით დაამუშაოს.
ტესტირებადობა და პროგნოზირებადობა: დამკვიდრებული პროგრამული პრაქტიკის გამოყენებით გამართვა, ტესტირება და მოვლა მნიშვნელოვნად მარტივია.
გამჭვირვალობა და საიმედოობა: ქცევის ნაკლები ცვალებადობა პრობლემების აღმოფხვრას ამარტივებს. აპლიკაციის მუშაობის უფრო დიდი ნაწილიც გამოიხატება გამჭვირვალე, ვერსიების კონტროლს დაქვემდებარებულ პროგრამულ უზრუნველყოფაში და არა LLM-ის გაუმჭვირვალე, ძნელად გასაგებ წონებში.
როუტერული მიდგომების ნაკლია მათი შესაძლო ხისტი და მოუქნელი ბუნება, რის გამოც ღია ტიპის პრობლემებთან გამკლავება უჭირთ. ჩატბოტი, რომელიც ყოველთვის ზუსტად ერთსა და იმავე პასუხებს იძლევა, მომხმარებლებს შეიძლება მოსაწყენად ან ერთფეროვნად მოეჩვენოთ.
ორკესტრატორულ დიზაინებს მძლავრი შესაძლებლობები აქვს:
დაგეგმვა: შეუძლია პასუხების დინამიკურად დაგეგმვა.
ხელსაწყოს შერჩევა/აგენტისთვის გადაცემა: შესაბამისი ხელსაწყოების შერჩევა ან ამოცანების აგენტებისთვის დელეგირება.
შედეგების იტერაციული გაერთიანება: შედეგების განმეორებით დამუშავება და შემოქმედებითად გაერთიანება.
დასრულების განსაზღვრა: იმის დადგენა, როდის შეგროვდა საკმარისი ინფორმაცია საბოლოო პასუხის მოსამზადებლად.
Pydantic-AI-ის ან OpenAI-ის Agents SDK-ის მსგავსი ფრეიმვორქები ორკესტრაციის დანერგვას მარტივსა და სწრაფს ხდის. ამიტომ ეს მიდგომა შესანიშნავია დემონსტრაციებისა და კონცეფციის დასადასტურებელი პროტოტიპებისთვის.
ამ მიდგომის ნაკლოვანებებია:
არ გვაქვს გარანტია, რომ LLM-ის დაგეგმვის ეტაპები და შემდგომი მოქმედებები სწორი ან შესაბამისი იქნება. იგივე პრობლემა როუტერულ სისტემასაც აქვს, თუმცა მეტი შეზღუდვის გამო მისი ქცევა უფრო პროგნოზირებადია.
მარტივი, მკაფიოდ განსაზღვრული ამოცანებისთვის მრავალაგენტიანი სისტემის სრული შესაძლებლობები, სავარაუდოდ, არ გვჭირდება. მაგალითად, ჩვენი ავიაკომპანიის აგენტის შემთხვევაში, ავიაკომპანიის მხარდაჭერის სისტემასთან ურთიერთობისას მომხმარებელს, სავარაუდოდ, მხოლოდ რამდენიმე ტიპის მოთხოვნა ექნება.
რადგან მეტი ლოგიკაა მოქცეული LLM-ში, ბოროტმოქმედებს გაცილებით ადვილად შეუძლიათ მწარმოებლის შეზღუდვების მოხსნა ან სისტემის ბოროტად გამოყენება.
ის გადაწყვეტილების მიღებას LLM-ში მალავს და ამით სისტემის გაგებას ართულებს, თუმცა Langfuse-ის ან Braintrust-ის მსგავსი მონიტორინგის ხელსაწყოები შესაძლოა ნაწილობრივ დაგეხმაროთ.
შენიშვნა მკითხველისთვის: მიუხედავად იმისა, რომ მოდელების შესაძლებლობები სწრაფად იცვლება, ქვემოთ მოცემული მიდგომები უახლოეს მომავალში, სავარაუდოდ, არ შეიცვლება.
განსაზღვრეთ თქვენი პრობლემის ფარგლები.
შეგიძლიათ სასურველი გადაწყვეტილების ლოგიკა მარტივად გამოსახოთ დიაგრამაზე?
თქვენს აპლიკაციაში დაუშვებელია შეცდომა ან მოულოდნელი ქცევა?
ზემოთ ჩამოთვლილთაგან რომელიმეზე პასუხი „დიახ“ მიანიშნებს, რომ როუტერული ფუნქციები უკეთესი არჩევანია.
სადაც შესაძლებელია, გირჩევთ, როუტერული მიდგომები მათი შესაძლებლობების ამოწურვამდე გამოიყენოთ. ზოგადი პრინციპია: თუ თქვენი სისტემის რომელიმე ნაწილი შეიძლება კოდით გამოიხატოს, კოდითვე აღწერეთ, ანუ საჭიროების გარეშე LLM-ებს ზედმეტად ნუ გამოიყენებთ.
როდესაც ამ მიდგომების შესაძლებლობები ამოიწურება, ორკესტრატორის ღია ტიპის ზოგიერთი უპირატესობის შეზღუდულად გამეორება შეიძლება. მაგალითად:
ხელსაწყოს შერჩევა/აგენტისთვის გადაცემა: მარტივად ხორციელდება პირობითი განშტოებებით ან LLM კლასიფიკატორებით.
დასრულების განსაზღვრა: მარტივ LLM კლასიფიკატორებს შეუძლია შეამოწმოს პასუხის სისრულე მომხმარებლისთვის მის დაბრუნებამდე.
თუმცა „დაგეგმვისა“ და „შედეგების იტერაციული გაერთიანების“ მიღწევა ხისტ როუტერულ სისტემაში უდავოდ ბევრად რთულია. ამიტომ, როცა ამოცანა მათ მოითხოვს — რასაც LLM კლასიფიკატორი ან სხვა ლოგიკა განსაზღვრავს — გირჩევთ, სისტემაში შექმნათ ნაკლებად შეზღუდული ორკესტრატორული განშტოება.
როუტერულ და ორკესტრატორულ არქიტექტურებს შორის არჩევანი უნდა შეესაბამებოდეს თქვენი აპლიკაციის სიცხადეს, სირთულესა და ინტერაქციის სტილს. მკაფიოდ განსაზღვრული ამოცანებისთვის როუტერზე დაფუძნებული მიდგომები ამჟამად საიმედოობას, ეფექტიანობასა და ტესტირების სიმარტივეს უზრუნველყოფს. ორკესტრატორები უფრო მოქნილია ფართო და სასაუბრო ინტერაქციებისთვის.
LLM-ების განვითარებასთან ერთად ამ მიდგომებს შორის ბალანსი შესაძლოა შეიცვალოს. საწარმოო დატვირთვებისთვის უპირატესობას როუტერულ ან ჰიბრიდულ არქიტექტურებს ვანიჭებთ, ორკესტრატორებს კი ვინახავთ ღია ტიპის პრობლემებისთვის, რომლებიც დინამიკურ, ადამიანისმაგვარ ინტერაქციას მოითხოვს.