Svarbu gerai apgalvoti, kaip ir kur jūsų agentinėje sistemoje priimami sprendimai.
Perdavus daugiau sprendimų LLM, sistema gali būti pritaikoma įvairesnėms užduotims, tačiau dėl to gali sumažėti jos sparta, patikimumas ir atsparumas.
Kai įmanoma, stenkitės kuo didesnę sprendimų priėmimo proceso dalį perkelti iš LLM į aiškiai apibrėžtą programinį kodą. Tai ypač svarbu didelės rizikos ir (arba) produkcinėms darbo eigoms.
Kuriant LLM pagrįstą agentinę sistemą, vienas svarbiausių pasirinkimų yra nuspręsti, kokia sprendimų priėmimo dalis bus patikėta LLM modeliui, o kokia – aiškiai apibrėžtai programinei įrangai.
Kad būtų lengviau suprasti, šį pasirinkimą galime laikyti spektru tarp šių metodų:
Maršruto parinktuvu grindžiamose architektūrose veiksmų seka ir logika aiškiai apibrėžiamos kode, todėl siauro profilio užduotims užtikrinamas testuojamumas, nuspėjamumas ir atsparumas (jos dar vadinamos „darbo eigos agentais“).
Orkestratoriaus agentai pasitelkia didžiuosius kalbos modelius (LLM), kad pagal natūraliosios kalbos užklausas dinamiškai nustatytų užduočių eigą. Jie puikiai tinka atviroms sąveikoms, kurioms iš anksto apibrėžtos logikos nepakanka arba jos apibrėžti neįmanoma.
Didelės rizikos produkcinėms darbo eigoms paprastai rekomenduojame naudoti daugiau maršruto parinktuvo funkcijų, o orkestratorius palikti programoms, kurioms būtini lankstūs, bendros paskirties pokalbiai.
Maršruto parinktuvu grindžiamos architektūros
Maršruto parinktuvo agentinės sistemos:
Sprendimų priėmimo eigą aiškiai apibrėžia kode ar programinėje įrangoje, o LLM naudoja tam, kad nustatytų, kurį maršrutą ši įranga turi pasirinkti.
Jos panašesnės į tradicines programines sistemas, nes turi aiškius ir nuspėjamus kelius, užtikrinančius nuoseklesnius rezultatus.
Jos idealiai tinka užduotims, kurias galima griežtai apibrėžti.
Toliau pateiktas supaprastintas oro linijų užsakymų pokalbių roboto agento, naudojančio maršruto parinktuvo metodą, pavyzdys. LLM padeda priskirti klausimo tikslą vienai iš trijų galimų kategorijų, tačiau galiausiai būtent mūsų programinė įranga susieja šį tikslą su šabloniniu tekstiniu atsakymu. Kadangi LLM taikomi griežti apribojimai, naudotojas susidurs su nuoseklesne sistemos elgsena.
Orkestratoriaus architektūros
Kitaip nei maršruto parinktuvo sistemos, orkestratoriaus agentinės sistemos:
Logines eigas apibrėžia natūraliosios kalbos užklausomis, o ne programine įranga. Pastaba: kitaip nei programavimo kalba, natūralioji kalba iš prigimties yra dviprasmiška ir lanksti (kaip aptarsime vėliau, tai turi ir privalumų, ir trūkumų). Tai vadiname „ketinimu, o ne nurodymu“.
Gali pasiūlyti kelis apdorojimo būdus, o LLM nustato jų vykdymo tvarką ir metodiką.
Gali dinamiškai kurti naujas logines eigas, kurias sunku aiškiai apibrėžti programinėje įrangoje.
Šis neapibrėžtumas gali lemti nenuoseklius rezultatus, tačiau kai sistema suveikia, tai gali atrodyti „stebuklinga“.
Toliau pateiktame pavyzdyje tai pačiai supaprastintai oro linijų užduočiai taikomas orkestratoriaus metodas. Užuot leidus programinei įrangai nuspręsti, koks atsakymas tinkamas, sprendimų priėmimas perduodamas LLM sluoksniui. Čia turime kelių agentų sistemą: pagrindinis orkestratoriaus agentas įvertina naudotojo užklausą ir perduoda ją specialiai skrydžiams keisti sukurtam agentui, kuris galiausiai pateikia atsakymą naudotojui.
Šiame pavyzdyje LLM sluoksnis atlieka klasifikatoriaus, maršruto parinktuvo ir atsakymo rengėjo vaidmenis. Maršruto parinktuvo pavyzdyje jis atliko tik klasifikatoriaus vaidmenį, o visa kita tvarkė programinė įranga.
Kai įmanoma, rekomenduojame rinktis maršruto parinktuvu grindžiamas architektūras, nes jos turi šių privalumų:
Sparta ir efektyvumas: vietiniai skaičiavimai yra spartesni nei nuo išorinių API priklausomi orkestratoriai. Be to, „IF/ELSE“ logiką daug pigiau vykdyti naudojant „Python“, nei mokėti LLM teikėjui už jos apdorojimą 400 mlrd. parametrų modeliu.
Testuojamumas ir nuspėjamumas: taikant nusistovėjusią programinės įrangos kūrimo praktiką, sistemą gerokai lengviau derinti, testuoti ir prižiūrėti.
Skaidrumas ir patikimumas: mažesni elgsenos svyravimai palengvina trikčių diagnostiką. Be to, didesnė programos eigos dalis išreiškiama skaidriu, versijų valdomu programiniu kodu, o ne neskaidriais ir sunkiai interpretuojamais LLM svoriais.
Maršruto parinktuvo metodų trūkumas tas, kad jie gali būti griežti, nelankstūs ir sunkiau susidoroti su atviresnėmis problemomis. Naudotojams gali pasirodyti, kad visada lygiai taip pat atsakantis pokalbių robotas yra nuobodus ir nekintantis.
Orkestratoriaus architektūros suteikia galingų galimybių:
Planavimas: jos gali dinamiškai planuoti atsakymus.
Įrankio pasirinkimas ar perdavimas agentui: jos parenka tinkamus įrankius arba paveda užduotis agentams.
Iteracinis rezultatų derinimas: jos gali iteratyviai ir kūrybiškai iš naujo derinti rezultatus.
Užbaigtumo nustatymas: jos nustato, kada surinkta pakankamai informacijos galutiniam atsakymui parengti.
Naudojant tokias sistemas kaip „Pydantic-AI“ arba OpenAI „Agents SDK“, orkestravimą galima įdiegti paprastai ir greitai. Todėl šis metodas puikiai tinka demonstracinėms ar koncepcijos pagrindimo versijoms.
Šio metodo trūkumai:
Nėra garantijų, kad LLM planavimo veiksmai ir paskesni veiksmai bus teisingi ar tinkami. Maršruto parinktuvo sistema susiduria su ta pačia problema, tačiau dėl griežtesnių apribojimų jos elgsena yra labiau nuspėjama.
Paprastoms ir aiškiai apibrėžtoms užduotims visų kelių agentų sistemos galimybių veikiausiai nereikia. Pavyzdžiui, mūsų oro linijų agento atveju greičiausiai yra tik ribotas skaičius užklausų tipų, kurių iš tiesų reikia su oro linijų pagalbos sistema bendraujančiam žmogui.
Kadangi daugiau logikos sutelkta LLM, piktavaliams daug lengviau apeiti tokios sistemos apribojimus arba ja pasinaudoti.
Sprendimų priėmimas paslepiamas LLM viduje, todėl sistemą tampa sunkiau suprasti (nors tokios stebėsenos priemonės kaip „Langfuse“ ar „Braintrust“ gali iš dalies padėti).
Pastaba skaitytojui: nors modelių galimybės sparčiai keičiasi, mažai tikėtina, kad artimiausiu metu pasikeis toliau pateiktos rekomendacijos.
Nustatykite savo problemos apimtį.
Ar norimą sprendimų logiką galite lengvai pavaizduoti diagramoje?
Ar jūsų programoje visiškai nepriimtinos klaidos arba netikėta elgsena?
Teigiamas atsakymas į bet kurį iš šių klausimų rodo, kad labiau tiktų maršruto parinktuvo funkcijos.
Kai įmanoma, rekomenduojame kuo plačiau taikyti maršruto parinktuvo metodus. Vadovaukitės bendru principu: jei sistemos dalį galima išreikšti kodu, taip ir padarykite, t. y. nenaudokite LLM be reikalo.
Pasiekus šių metodų ribas, kai kuriuos atviresnių orkestratorių privalumus galima atkurti labiau kontroliuojamu būdu. Pavyzdžiui:
Įrankio pasirinkimas ar perdavimas agentui: tai lengva įgyvendinti naudojant sąlygines šakas arba LLM klasifikatorius.
Užbaigtumo nustatymas: paprasti LLM klasifikatoriai gali patikrinti atsakymo išsamumą prieš pateikiant jį naudotojui.
Vis dėlto „planavimą“ ir „iteracinį rezultatų derinimą“ neabejotinai daug sunkiau įgyvendinti griežtoje maršruto parinktuvo sistemoje. Todėl, kai užduočiai reikia šių galimybių (tai nustato LLM klasifikatorius ar kita logika), siūlome sistemoje sukurti mažiau apribotą orkestratoriaus šaką.
Maršruto parinktuvo arba orkestratoriaus architektūrą turėtumėte rinktis atsižvelgdami į programos apibrėžtumą, sudėtingumą ir sąveikos pobūdį. Šiuo metu maršruto parinktuvu grindžiami metodai aiškiai apibrėžtoms užduotims užtikrina patikimumą, efektyvumą ir paprastą testavimą. Orkestratoriai yra lankstesni vykdant platesnes, pokalbiu grindžiamas sąveikas.
LLM toliau tobulėjant, šių metodų pusiausvyra gali keistis. Produkcinėms darbo apkrovoms esame linkę rinktis maršruto parinktuvu grindžiamas arba mišrias architektūras, o orkestratorius palikti atviroms problemoms, kurioms būtina dinamiška, žmogaus bendravimą primenanti sąveika.