Është e rëndësishme të shqyrtoni me kujdes se si dhe ku merren vendimet në sistemin tuaj me agjentë.
Delegimi i më shumë vendimeve te një LLM mund t'i mundësojë sistemit të përgjithësohet për më shumë detyra, por mund të cenojë shpejtësinë, besueshmërinë dhe qëndrueshmërinë.
Kur është e mundur, përpiquni ta zhvendosni sa më shumë procesin e vendimmarrjes nga LLM-ja në kod të qartë softuerik. Kjo vlen veçanërisht për flukset e punës me rrezik të lartë dhe/ose në prodhim.
Kur projektoni një sistem me agjentë të bazuar në LLM, një nga zgjedhjet më të rëndësishme është sa vendimmarrje do të përfshihet në një model LLM dhe sa në softuer të qartë.
Për ta kuptuar më mirë, mund ta shohim këtë zgjedhje si një spektër mes qasjeve të mëposhtme:
Arkitekturat e bazuara në ruter e përcaktojnë shprehimisht në kod rendin dhe logjikën, duke siguruar testueshmëri, parashikueshmëri dhe qëndrueshmëri për detyra në fusha të ngushta (quhen edhe “agjentë të flukseve të punës”).
Agjentët orkestrues mbështeten te modelet e mëdha gjuhësore (LLM) për të vendosur në mënyrë dinamike rrjedhën e detyrave përmes udhëzimeve në gjuhë natyrore. Ata janë idealë për ndërveprime të hapura, ku logjika e paracaktuar është e pamjaftueshme ose e pamundur.
Për flukset e punës me rrezik të lartë dhe në prodhim, zakonisht rekomandojmë më shumë veçori të bazuara në ruter, ndërsa orkestruesit duhen ruajtur për aplikacione që kërkojnë biseda fleksibël dhe për përdorim të përgjithshëm.
Arkitekturat e bazuara në ruter
Sistemet me agjentë dhe ruter:
E përcaktojnë shprehimisht rrjedhën e vendimmarrjes përmes kodit/softuerit dhe përdorin një LLM për të përcaktuar rrugën që ndjek softueri.
Janë më pranë sistemeve tradicionale softuerike, pasi kanë rrugë të qarta dhe të parashikueshme që japin rezultate më të njëtrajtshme.
Janë ideale për detyra që mund të përkufizohen rreptësisht.
Më poshtë paraqitet një shembull i thjeshtuar i një agjenti për rezervime me chatbot të një kompanie ajrore, i cili përdor “qasjen me ruter”. Edhe pse LLM-ja na ndihmon ta klasifikojmë synimin e pyetjes mes tri zgjedhjeve të mundshme, në fund është softueri ynë ai që e lidh këtë synim me një përgjigje tekstuale model. Meqë LLM-ja është shumë e kufizuar, përdoruesi do të përjetojë sjellje më të njëtrajtshme.
Arkitekturat me orkestrues
Ndryshe nga sistemi me ruter, sistemet me agjentë orkestrues:
I përcaktojnë rrjedhat logjike përmes udhëzimeve në gjuhë natyrore, jo përmes softuerit. Shënim: krahasuar me një gjuhë programimi, gjuha natyrore është në thelb e dykuptimtë dhe fleksibël (tipare njëkohësisht pozitive dhe negative, siç do të diskutojmë më tej). Këtë e quajmë “synim në vend të udhëzimit”.
Mund të ofrojnë disa mundësi përpunimi, ndërsa LLM-ja përcakton rendin dhe metodën e ekzekutimit.
Mund të krijojnë në mënyrë dinamike rrugë të reja logjike, të cilat është e vështirë të përcaktohen shprehimisht në softuer.
Kjo dykuptimësi mund të sjellë rezultate jo të njëtrajtshme, por kur funksionon, mund të duket “magjike”.
Shembulli i mëposhtëm zbaton një qasje me orkestrues për të njëjtin problem të thjeshtuar të kompanisë ajrore. Në vend që softueri të vendosë se cila përgjigje është e përshtatshme, vendimmarrja i delegohet shtresës LLM. Këtu kemi një sistem me shumë agjentë, ku një agjent orkestrues “kryesor” e klasifikon kërkesën e përdoruesit dhe ia kalon një agjenti të projektuar posaçërisht për ndryshimin e fluturimeve, i cili në fund i jep përgjigjen përdoruesit.
Në këtë shembull, shtresa LLM luan rolin e klasifikuesit, ruterit dhe hartuesit të përgjigjes. Në shembullin me ruter, ajo luante vetëm rolin e klasifikuesit (ndërsa softueri merrej me pjesën tjetër).
Kur është e mundur, rekomandojmë qasjet e bazuara në ruter, sepse ofrojnë përparësitë e mëposhtme:
Shpejtësia dhe efikasiteti: Përllogaritjet lokale ofrojnë shpejtësi më të lartë se orkestruesit që varen nga API-të e jashtme. Është gjithashtu shumë më lirë ta përpunoni logjikën “IF/ELSE” në Python, sesa të paguani një ofrues LLM-je për ta kaluar atë nëpër modelin e vet me 400 miliardë parametra.
Testueshmëria dhe parashikueshmëria: Është dukshëm më e lehtë të diagnostikohet, testohet dhe mirëmbahet përmes praktikave të konsoliduara softuerike.
Transparenca dhe besueshmëria: Ndryshueshmëria më e ulët e sjelljes e thjeshton zgjidhjen e problemeve. Një pjesë më e madhe e rrjedhës së aplikacionit shprehet gjithashtu në softuer transparent dhe nën kontroll versionesh, në vend të peshave të paqarta e të pakuptueshme të një LLM-je.
Mangësitë e qasjeve me ruter janë ngurtësia, mungesa e fleksibilitetit dhe vështirësia për të trajtuar probleme më të hapura. Një chatbot që jep gjithmonë saktësisht të njëjtat përgjigje mund t'u duket përdoruesve i mërzitshëm ose i pandryshueshëm.
Projektimet me orkestrues kanë aftësi të fuqishme:
Planifikimi: Mund t'i planifikojnë përgjigjet në mënyrë dinamike.
Përzgjedhja e mjeteve/Kalimi te një agjent tjetër: Përzgjedhin mjetet e përshtatshme ose ua delegojnë detyrat agjentëve.
Kombinimi përsëritës i rezultateve: I përpunojnë dhe i rikombinojnë rezultatet në mënyrë krijuese.
Përcaktimi i përfundimit: Përcaktojnë kur është mbledhur informacion i mjaftueshëm për ta përfunduar një përgjigje.
Përdorimi i kornizave si Pydantic-AI ose Agents SDK i OpenAI e bën orkestrimin të drejtpërdrejtë dhe të shpejtë për t'u zbatuar. Kjo e bën një zgjidhje të shkëlqyer për demonstrime ose prova koncepti.
Mangësitë e kësaj qasjeje janë:
Nuk kemi asnjë garanci se hapat e planifikimit të LLM-së dhe veprimet pasuese do të jenë të sakta ose të përshtatshme. Sistemi me ruter ka të njëjtin problem, por duke qenë më i kufizuar, sjellja e tij është më e parashikueshme.
Për detyra të thjeshta dhe të mirëpërcaktuara, nuk ka gjasa të na nevojiten të gjitha aftësitë e një sistemi me shumë agjentë. Për shembull, në rastin e agjentit të kompanisë ajrore, ka gjasa të ekzistojë vetëm një numër i kufizuar llojesh kërkesash që dikush dëshiron t'i kryejë përmes sistemit të mbështetjes së kompanisë.
Meqë LLM-ja përmban më shumë logjikë, aktorët keqdashës mund t'ia heqin kufizimet mbrojtëse ose ta shfrytëzojnë shumë më lehtë.
Kjo e abstragon vendimmarrjen brenda LLM-së dhe, si rrjedhojë, e bën sistemin më të vështirë për t'u kuptuar (ndonëse mjete monitorimi si Langfuse ose Braintrust mund të ndihmojnë pjesërisht).
Shënim për lexuesin: ndonëse aftësitë e modeleve po ndryshojnë me shpejtësi, pikat e mëposhtme nuk pritet të ndryshojnë së shpejti.
Përcaktoni fushëveprimin e problemit tuaj.
A mund ta paraqitni lehtësisht në një diagram logjikën e dëshiruar të vendimmarrjes?
A është i papranueshëm dështimi ose sjellja e papritur në aplikacionin tuaj?
Përgjigjja “po” ndaj njërës prej pyetjeve më sipër tregon se veçoritë me ruter do të ishin më të përshtatshme.
Kur është e mundur, rekomandojmë përdorimin e qasjeve me ruter për aq sa e lejojnë. Si parim i përgjithshëm, nëse një pjesë e sistemit mund të shprehet në kod, shpreheni në kod (pra, mos i përdorni tepër LLM-të kur nuk nevojiten).
Kur këto qasje arrijnë kufijtë e tyre, disa nga përparësitë e hapura të orkestruesit mund të riprodhohen në mënyrë të kufizuar. Për shembull:
Përzgjedhja e mjeteve/Kalimi te një agjent tjetër: Zbatohet lehtësisht përmes degëzimit me kushte ose klasifikuesve LLM.
Përcaktimi i përfundimit: Klasifikues të thjeshtë LLM mund ta kontrollojnë plotësinë e përgjigjes para se ajo t'i kthehet përdoruesit.
Megjithatë, “Planifikimi” dhe “Kombinimi përsëritës i rezultateve” janë pa dyshim shumë më të vështira për t'u realizuar në një sistem të ngurtë me ruter. Prandaj, kur një detyrë i kërkon këto (siç përcaktohet nga një klasifikues LLM ose një logjikë tjetër), sugjerojmë të krijoni në sistem një degë me orkestrues më pak të kufizuar.
Zgjedhja juaj mes arkitekturave me ruter dhe atyre me orkestrues duhet të pasqyrojë qartësinë, kompleksitetin dhe stilin e ndërveprimit të aplikacionit. Qasjet e bazuara në ruter ofrojnë aktualisht besueshmëri, efikasitet dhe testim të lehtë për detyra të mirëpërcaktuara. Orkestruesit ofrojnë më shumë fleksibilitet për ndërveprime më të gjera dhe bashkëbiseduese.
Ndërsa LLM-të vazhdojnë të përparojnë, ekuilibri mes këtyre qasjeve mund të ndryshojë. Për ngarkesat e punës në prodhim, priremi nga arkitekturat e bazuara në ruter ose ato hibride, ndërsa orkestruesit i ruajmë për probleme të hapura që kërkojnë ndërveprim dinamik dhe të ngjashëm me atë njerëzor.