Je dôležité dôkladne zvážiť, ako a kde sa vo vašom agentnom systéme prijímajú rozhodnutia.
Prenesenie väčšieho počtu rozhodnutí na LLM môže systému umožniť zvládať širšiu škálu úloh, no potenciálne na úkor rýchlosti, spoľahlivosti a odolnosti.
Ak je to možné, snažte sa čo najväčšiu časť rozhodovacieho procesu presunúť z LLM do explicitného softvérového kódu. Platí to najmä pre rizikové a produkčné pracovné postupy.
Pri navrhovaní agentného systému založeného na LLM je jedným z najdôležitejších rozhodnutí to, do akej miery bude rozhodovanie súčasťou modelu LLM a do akej miery explicitného softvéru.
Pre lepšie pochopenie si túto voľbu môžeme predstaviť ako spektrum medzi týmito prístupmi:
Architektúry založené na smerovači explicitne definujú poradie a logiku v kóde, čím pri úlohách z úzko vymedzenej oblasti zaisťujú testovateľnosť, predvídateľnosť a odolnosť (nazývajú sa aj „agenti pracovných postupov“).
Orchestrátorové agenty využívajú veľké jazykové modely (LLM), ktoré pomocou pokynov v prirodzenom jazyku dynamicky rozhodujú o priebehu úloh. Sú ideálne na otvorené interakcie, pri ktorých preddefinovaná logika nestačí alebo ju nemožno vytvoriť.
Pri rizikových produkčných pracovných postupoch zvyčajne odporúčame využívať viac prvkov založených na smerovači a orchestrátory vyhradiť pre aplikácie, ktoré vyžadujú flexibilné, všeobecne zamerané konverzácie.
Architektúry založené na smerovači
Agentné systémy so smerovačom:
Explicitne definujú rozhodovací tok prostredníctvom kódu alebo softvéru a pomocou LLM určujú, ktorou cestou má softvér pokračovať.
Viac sa podobajú tradičným softvérovým systémom, pretože majú jasné a predvídateľné cesty vedúce ku konzistentnejším výsledkom.
Sú ideálne na úlohy, ktoré možno presne vymedziť.
Nasleduje zjednodušený príklad agenta leteckého chatbota na rezervácie, ktorý využíva „prístup so smerovačom“. LLM pomáha zaradiť zámer otázky do jednej z troch možností, no napokon je to náš softvér, ktorý tento zámer priradí k šablónovej textovej odpovedi. Keďže je LLM výrazne obmedzený, používateľ sa stretne s konzistentnejším správaním.
Orchestrátorové architektúry
Na rozdiel od systémov so smerovačom orchestrátorové agentné systémy:
Definujú logické toky pomocou pokynov v prirodzenom jazyku namiesto softvéru. Poznámka: prirodzený jazyk je v porovnaní s programovacím jazykom vo svojej podstate nejednoznačný a flexibilný (čo je pozitívna aj negatívna vlastnosť, ako si ukážeme neskôr). Tento prístup označujeme ako „zámer namiesto inštrukcie“.
Môžu ponúknuť viacero možností spracovania, pričom LLM určuje poradie a spôsob vykonania.
Môžu dynamicky vytvárať nové logické cesty, ktoré je náročné explicitne definovať v softvéri.
Táto nejednoznačnosť môže viesť k nekonzistentným výstupom, no keď všetko funguje, výsledok môže pôsobiť až „magicky“.
Nasledujúci príklad uplatňuje orchestrátorový prístup na rovnaký zjednodušený problém leteckej spoločnosti. Namiesto toho, aby o vhodnej odpovedi rozhodoval softvér, sa rozhodovanie prenesie do vrstvy LLM. Ide o multiagentný systém, v ktorom „hlavný“ orchestrátorový agent posúdi požiadavku používateľa a odovzdá ju agentovi navrhnutému špeciálne na zmenu letov, ktorý napokon používateľovi poskytne odpoveď.
V tomto príklade plní vrstva LLM úlohu klasifikátora, smerovača aj autora odpovede. V príklade so smerovačom plnila iba úlohu klasifikátora (o zvyšok sa postaral softvér).
Ak je to možné, odporúčame používať prístupy založené na smerovači, pretože ponúkajú tieto výhody:
Rýchlosť a efektívnosť: Lokálne výpočty sú rýchlejšie než orchestrátory závislé od externých rozhraní API. Spracovať logiku „IF/ELSE“ v Pythone je navyše oveľa lacnejšie než platiť poskytovateľovi LLM za jej spracovanie modelom so 400 miliardami parametrov.
Testovateľnosť a predvídateľnosť: Vďaka zaužívaným softvérovým postupom sa podstatne jednoduchšie ladia, testujú a udržiavajú.
Transparentnosť a spoľahlivosť: Menšie rozdiely v správaní zjednodušujú riešenie problémov. Väčšia časť toku aplikácie je navyše vyjadrená v transparentnom softvéri so správou verzií, a nie v netransparentných a neinterpretovateľných váhach LLM.
Nevýhodou prístupov so smerovačom je ich možná strnulosť a nepružnosť, pre ktoré môžu mať ťažkosti s otvorenejšími problémami. Chatbot, ktorý vždy odpovedá úplne rovnako, môže na používateľov pôsobiť nudne alebo stagnujúco.
Orchestrátorové návrhy ponúkajú výkonné možnosti:
Plánovanie: Dokážu dynamicky plánovať odpovede.
Výber nástroja alebo odovzdanie agentovi: Vyberú vhodné nástroje alebo delegujú úlohy agentom.
Iteratívne kombinovanie výstupov: Tvorivo opakujú a kombinujú výstupy.
Určenie dokončenia: Rozhodnú, kedy už bolo zhromaždených dosť informácií na dokončenie odpovede.
Rámce ako Pydantic-AI alebo Agents SDK od OpenAI umožňujú implementovať orchestráciu jednoducho a rýchlo. Vďaka tomu sa výborne hodí na ukážky alebo overenie konceptu.
Tento prístup má tieto nevýhody:
Nemáme žiadnu záruku, že plánovacie kroky LLM a následné akcie budú správne alebo vhodné. Rovnaký problém má aj systém so smerovačom, no keďže je viac obmedzený, jeho správanie je predvídateľnejšie.
Pri jednoduchých, jasne vymedzených úlohách pravdepodobne nepotrebujeme všetky možnosti multiagentného systému. Napríklad v našom príklade leteckého agenta zrejme existuje len obmedzený počet typov požiadaviek, ktoré chcú používatelia podpory leteckej spoločnosti skutočne riešiť.
Keďže LLM obsahuje viac logiky, je oveľa náchylnejší na jailbreak alebo zneužitie útočníkmi.
Rozhodovanie sa abstrahuje do LLM, čo sťažuje pochopenie systému (hoci monitorovacie nástroje ako Langfuse či Braintrust môžu čiastočne pomôcť).
Poznámka pre čitateľa: hoci sa možnosti modelov rýchlo menia, nasledujúce odporúčania sa v blízkej budúcnosti pravdepodobne nezmenia.
Určte rozsah problému.
Dokážete požadovanú rozhodovaciu logiku jednoducho znázorniť diagramom?
Je pre vás zlyhanie alebo neočakávané správanie aplikácie neprijateľné?
Odpoveď „áno“ na ktorúkoľvek z týchto otázok naznačuje, že vhodnejšie budú prvky smerovača.
Ak je to možné, odporúčame používať prístup so smerovačom dovtedy, kým postačuje. Vo všeobecnosti platí, že ak možno časť systému vyjadriť kódom, treba ju v kóde aj vytvoriť (teda nepoužívať LLM nadmerne, keď nie sú potrebné).
Keď tento prístup dosiahne svoje hranice, niektoré výhody otvoreného orchestrátora možno napodobniť obmedzeným spôsobom. Napríklad:
Výber nástroja alebo odovzdanie agentovi: Možno ho jednoducho implementovať pomocou podmieneného vetvenia alebo klasifikátorov LLM.
Určenie dokončenia: Jednoduché klasifikátory LLM môžu pred odoslaním odpovede používateľovi skontrolovať jej úplnosť.
„Plánovanie“ a „iteratívne kombinovanie výstupov“ sa však v strnulom systéme so smerovačom nepochybne dosahujú oveľa ťažšie. Ak teda úloha tieto možnosti vyžaduje (čo určí klasifikátor LLM alebo iná logika), odporúčame v systéme vytvoriť menej obmedzenú orchestrátorovú vetvu.
Voľba medzi architektúrou so smerovačom a orchestrátorovou architektúrou by mala zohľadňovať mieru vymedzenia, zložitosť a spôsob interakcie vašej aplikácie. Prístupy založené na smerovači v súčasnosti ponúkajú pri jasne vymedzených úlohách spoľahlivosť, efektívnosť a jednoduché testovanie. Orchestrátory poskytujú väčšiu flexibilitu pri širších konverzačných interakciách.
S ďalším rozvojom LLM sa môže rovnováha medzi týmito prístupmi meniť. Pri produkčnej záťaži uprednostňujeme architektúry založené na smerovači alebo hybridné architektúry. Orchestrátory si vyhradzujeme na otvorené problémy, ktoré vyžadujú dynamickú interakciu podobnú komunikácii s človekom.