Az ügynökalapú rendszer tervezésekor fontos alaposan átgondolni, hogyan és hol születnek a döntések.
Ha több döntést bízunk az LLM-re, a rendszer többféle feladatra lehet általánosítható, de ez a sebesség, a megbízhatóság és a robusztusság rovására mehet.
Ahol lehetséges, a döntéshozatali folyamat minél nagyobb részét emeljük ki az LLM-ből, és valósítsuk meg explicit programkódban. Ez különösen igaz a magas kockázatú és az éles környezetben futó munkafolyamatokra.
Egy LLM-alapú ügynökrendszer tervezésekor az egyik legfontosabb döntés, hogy a döntéshozatal mekkora részét bízzuk egy LLM-modellre, és mennyit valósítsunk meg explicit szoftverben.
A könnyebb megértés érdekében ezt a választást a következő megközelítések közötti spektrumként képzelhetjük el:
A routeralapú architektúrák a sorrendet és a logikát explicit módon, kódban határozzák meg, így jól tesztelhető, kiszámítható és robusztus működést biztosítanak a szűk területre korlátozódó feladatoknál. Ezeket „munkafolyamat-ügynököknek” is nevezik.
Az orchestrator ügynökök nagy nyelvi modellekre (LLM-ekre) támaszkodva, természetes nyelvű promptok alapján dinamikusan határozzák meg a feladatok menetét. Ideálisak a nyitott végű interakciókhoz, amelyeknél az előre meghatározott logika elégtelen vagy kivitelezhetetlen.
A magas kockázatú, éles környezetben futó munkafolyamatokhoz általában több routeralapú funkció használatát javasoljuk; az orchestratorokat érdemes a rugalmas, általános célú párbeszédet igénylő alkalmazásokra fenntartani.
Routeralapú architektúrák
A routeralapú ügynökrendszerek:
A döntéshozatal menetét explicit módon, kódban vagy szoftverben határozzák meg, az LLM pedig eldönti, melyik útvonalat kövesse a szoftver.
Közelebb állnak a hagyományos szoftverrendszerekhez, mivel egyértelmű és kiszámítható útvonalakkal következetesebb eredményeket biztosítanak.
Ideálisak a szigorúan meghatározható feladatokhoz.
A következő egyszerű példa egy routeres megközelítést alkalmazó repülőjegy-foglalási chatbotügynököt mutat be. Az LLM három lehetséges kategória egyikébe sorolja a kérdés szándékát, végül azonban a szoftverünk rendeli hozzá ehhez a megfelelő sablonválaszt. Mivel az LLM működése erősen korlátozott, a felhasználó következetesebb viselkedést tapasztal.
Orchestrator architektúrák
A routeres rendszerekkel szemben az orchestratoralapú ügynökrendszerek:
A logikai folyamatokat szoftver helyett természetes nyelvű promptokkal határozzák meg. Megjegyzés: a programozási nyelvekkel szemben a természetes nyelv eredendően kétértelmű és rugalmas. Ez egyszerre előny és hátrány, ahogy azt később bemutatjuk. Ezt úgy fogalmazzuk meg: „szándék az utasítás helyett”.
Több feldolgozási lehetőséget kínálhatnak, amelyek végrehajtási sorrendjét és módszerét az LLM határozza meg.
Dinamikusan hozhatnak létre olyan új logikai útvonalakat, amelyeket nehéz lenne explicit módon szoftverben meghatározni.
Ez a kétértelműség következetlen kimenetekhez vezethet, de amikor jól működik, szinte „varázslatosnak” tűnhet.
A következő példa ugyanerre az egyszerű légitársasági problémára alkalmazza az orchestratoros megközelítést. Ahelyett, hogy a megfelelő válaszról a szoftver döntene, a döntéshozatalt az LLM-rétegre bízzuk. Ebben a többügynökös rendszerben egy „vezető” orchestrator ügynök osztályozza a felhasználói kérést, majd átadja azt egy kifejezetten járatmódosításra tervezett ügynöknek, amely végül válaszol a felhasználónak.
Ebben a példában az LLM-réteg egyszerre tölti be az osztályozó, a router és a válaszíró szerepét. A routeres példában csak az osztályozó szerepét töltötte be, a többit a szoftver kezelte.
Ahol lehetséges, routeralapú megközelítést javaslunk, mert az a következő előnyöket kínálja:
Sebesség és hatékonyság: A helyi számítások gyorsabbak a külső API-kra támaszkodó orchestratoroknál. Az „IF/ELSE” logikát Pythonban feldolgozni is sokkal olcsóbb, mint kifizetni egy LLM-szolgáltatónak, hogy átfuttassa a 400 milliárd paraméteres modelljén.
Tesztelhetőség és kiszámíthatóság: A bevett szoftverfejlesztési gyakorlatokkal lényegesen egyszerűbb a hibakeresés, a tesztelés és a karbantartás.
Átláthatóság és megbízhatóság: A viselkedés kisebb változatossága megkönnyíti a hibaelhárítást. Az alkalmazás működésének nagyobb része jelenik meg átlátható, verziókövetett szoftverben, nem pedig egy LLM átláthatatlan, értelmezhetetlen súlyaiban.
A routeres megközelítés hátránya, hogy merev és rugalmatlan lehet, illetve nehezen kezelheti a nyitottabb problémákat. A felhasználók unalmasnak vagy egyhangúnak tarthatják azt a chatbotot, amely mindig pontosan ugyanazokat a válaszokat adja.
Az orchestratoralapú megoldások sokoldalú képességekkel rendelkeznek:
Tervezés: Dinamikusan megtervezhetik a válaszokat.
Eszközválasztás és feladatátadás ügynökök között: Kiválaszthatják a megfelelő eszközöket, vagy más ügynökökre bízhatják a feladatokat.
A kimenetek iteratív kombinálása: Kreatívan finomíthatják és újrakombinálhatják a kimeneteket.
A befejezettség megállapítása: Eldönthetik, mikor gyűlt össze elegendő információ a válasz véglegesítéséhez.
A Pydantic-AI-hoz vagy az OpenAI Agents SDK-jához hasonló keretrendszerekkel az orchestráció egyszerűen és gyorsan megvalósítható. Ezért kiválóan alkalmas bemutatókhoz és megvalósíthatósági prototípusokhoz.
A megközelítés hátrányai a következők:
Semmi sem garantálja, hogy az LLM tervezési lépései és az azokat követő műveletek helyesek vagy megfelelőek lesznek. A routeres rendszernek ugyanez a problémája, de a szigorúbb korlátozások miatt kiszámíthatóbb a viselkedése.
Egyszerű, jól meghatározott feladatokhoz valószínűleg nincs szükség egy többügynökös rendszer minden képességére. A légitársasági ügynökről szóló példánkban egy légitársaság ügyfélszolgálati rendszerének felhasználói valószínűleg csak korlátozott számú kéréstípussal fordulnak a rendszerhez.
Mivel több logika található az LLM-ben, a rosszindulatú szereplők sokkal könnyebben hajthatnak végre jailbreakeket vagy használhatják ki a rendszert.
A döntéshozatalt az LLM-be rejti, így nehezebbé teszi a rendszer megértését, bár az olyan megfigyelőeszközök, mint a Langfuse vagy a Braintrust, részben segíthetnek ezen.
Megjegyzés az olvasónak: bár a modellek képességei gyorsan fejlődnek, az alábbiak valószínűleg nem változnak a közeljövőben.
Határozza meg a probléma hatókörét.
Könnyen ábrázolható diagramon a kívánt döntési logika?
Elfogadhatatlan a meghibásodás vagy a váratlan viselkedés az alkalmazásban?
Ha a fenti kérdések bármelyikére „igen” a válasz, valószínűleg a routeralapú funkciók a megfelelőbbek.
Ahol és ameddig lehetséges, routeres megközelítést javaslunk. Általános elvként: ha a rendszer valamely része kódban is kifejezhető, akkor valósítsuk meg kódban, vagyis ne használjunk szükségtelenül LLM-eket.
Amikor elérjük e megoldások korlátait, az orchestratorok nyitott működésének egyes előnyei korlátozott formában is megvalósíthatók. Például:
Eszközválasztás és feladatátadás ügynökök között: Feltételes elágazásokkal vagy LLM-osztályozókkal könnyen megvalósítható.
A befejezettség megállapítása: Egyszerű LLM-osztályozók ellenőrizhetik a válasz teljességét, mielőtt azt visszaadnánk a felhasználónak.
A „tervezés” és „a kimenetek iteratív kombinálása” azonban kétségtelenül sokkal nehezebben valósítható meg egy merev routeres rendszerben. Ha tehát egy feladat megköveteli ezeket – amit egy LLM-osztályozó vagy más logika állapít meg –, egy kevésbé korlátozott orchestratorág létrehozását javasoljuk a rendszerben.
A router- és orchestrator architektúrák közötti választásnak tükröznie kell az alkalmazás egyértelműségét, összetettségét és interakciós stílusát. A routeralapú megközelítések jelenleg megbízhatóságot, hatékonyságot és könnyű tesztelhetőséget kínálnak a világosan meghatározott feladatokhoz. Az orchestratorok nagyobb rugalmasságot kínálnak a szélesebb körű, párbeszédalapú interakciókhoz.
Az LLM-ek további fejlődésével változhat a két megközelítés közötti egyensúly. Éles környezetben futó munkafolyamatokhoz inkább routeralapú vagy hibrid architektúrákat választunk, az orchestratorokat pedig a dinamikus, emberi jellegű interakciót igénylő, nyitott végű problémákra tartjuk fenn.