Je důležité pečlivě zvážit, jak a kde se ve vašem agentním systému přijímají rozhodnutí.
Přenesení více rozhodnutí na LLM může systému umožnit zvládat širší škálu úloh, ovšem potenciálně na úkor rychlosti, spolehlivosti a odolnosti.
Kdykoli je to možné, snažte se co největší část rozhodovacího procesu přesunout z LLM do explicitního programového kódu. To platí zejména pro vysoce rizikové a produkční pracovní postupy.
Při návrhu agentního systému založeného na LLM je jedním z nejdůležitějších rozhodnutí, jak velkou část rozhodování svěřit modelu LLM a jak velkou část explicitnímu softwaru.
Pro lepší pochopení si tuto volbu můžeme představit jako škálu mezi následujícími přístupy:
Architektury založené na směrovači explicitně definují pořadí a logiku v kódu, což u úloh z úzce vymezené oblasti zajišťuje testovatelnost, předvídatelnost a odolnost (označují se také jako „agenti pracovních postupů“).
Orchestrační agenti využívají velké jazykové modely (LLM), které pomocí pokynů v přirozeném jazyce dynamicky určují průběh úloh. Jsou ideální pro otevřené interakce, u nichž předem definovaná logika nestačí nebo není možná.
U vysoce rizikových produkčních pracovních postupů obvykle doporučujeme více funkcí založených na směrovači a orchestrátory vyhrazujeme pro aplikace, které vyžadují flexibilní, univerzální konverzaci.
Architektury založené na směrovači
Agentní systémy se směrovačem:
Explicitně definují průběh rozhodování pomocí kódu či softwaru a pomocí LLM určují, kterou cestou má software pokračovat.
Blíží se tradičním softwarovým systémům, protože mají jasné a předvídatelné cesty vedoucí ke konzistentnějším výsledkům.
Jsou ideální pro úlohy, které lze přesně vymezit.
Následuje zjednodušený příklad agenta letecké společnosti pro rezervace přes chatbot, který využívá „přístup se směrovačem“. LLM sice pomáhá zařadit záměr dotazu do jedné ze tří kategorií, ale tento záměr nakonec mapuje na šablonu textové odpovědi náš software. Protože má LLM velmi omezený prostor, bude se systém z pohledu uživatele chovat konzistentněji.
Architektury s orchestrátorem
Na rozdíl od systémů se směrovačem agentní systémy s orchestrátorem:
Definují logický průběh pomocí pokynů v přirozeném jazyce namísto softwaru. Poznámka: Přirozený jazyk je oproti programovacímu jazyku ze své podstaty nejednoznačný a flexibilní. Jak si ukážeme později, obě vlastnosti mají své výhody i nevýhody. Tento přístup chápeme jako „záměr namísto instrukce“.
Mohou nabízet více možností zpracování, přičemž LLM určuje pořadí a způsob provedení.
Mohou dynamicky vytvářet nové logické cesty, které lze v softwaru jen obtížně explicitně definovat.
Tato nejednoznačnost může vést k nekonzistentním výstupům, ale když vše funguje, může výsledek působit až „kouzelně“.
Následující příklad uplatňuje přístup s orchestrátorem na stejný zjednodušený problém letecké společnosti. Namísto toho, aby vhodnou odpověď určoval software, se rozhodování přenáší do vrstvy LLM. Jde o systém více agentů, v němž „hlavní“ orchestrační agent předběžně vyhodnotí dotaz uživatele a předá jej agentovi určenému ke změnám letů, který nakonec uživateli poskytne odpověď.
Vrstva LLM zde plní roli klasifikátoru, směrovače i autora odpovědi. V příkladu se směrovačem plnila pouze roli klasifikátoru, zatímco o zbytek se postaral software.
Kdykoli je to možné, doporučujeme přístup založený na směrovači, protože nabízí následující výhody:
Rychlost a efektivita: Lokální výpočty jsou rychlejší než orchestrátory závislé na externích API. Je také mnohem levnější zpracovat logiku „IF/ELSE“ v Pythonu než platit poskytovateli LLM za její průchod modelem se 400 miliardami parametrů.
Testovatelnost a předvídatelnost: Díky zavedeným softwarovým postupům je výrazně snazší systém ladit, testovat a udržovat.
Transparentnost a spolehlivost: Menší proměnlivost chování usnadňuje řešení problémů. Větší část průběhu aplikace je navíc vyjádřena transparentním softwarem se správou verzí, nikoli neprůhlednými a obtížně interpretovatelnými vahami LLM.
Nevýhodou přístupů se směrovačem je jejich strnulost a nepružnost. Také si mohou hůře poradit s otevřenějšími problémy. Chatbot, který vždy odpovídá naprosto stejně, může uživatelům připadat nudný a stagnující.
Návrhy s orchestrátorem nabízejí výkonné možnosti:
Plánování: Dokážou dynamicky plánovat odpovědi.
Výběr nástrojů a předávání mezi agenty: Vybírají vhodné nástroje nebo delegují úlohy na agenty.
Iterativní kombinování výstupů: Výstupy iterativně a kreativně přepracovávají a kombinují.
Určení dokončení: Určují, kdy bylo shromážděno dost informací k dokončení odpovědi.
Frameworky jako Pydantic-AI nebo Agents SDK od OpenAI umožňují orchestraci implementovat snadno a rychle. Proto se tento přístup výborně hodí pro ukázky a ověřování konceptů.
Tento přístup má následující nevýhody:
Nemáme žádnou záruku, že plánovací kroky LLM a následné akce budou správné a vhodné. Systém se směrovačem má stejný problém, ale díky přísnějším omezením je jeho chování předvídatelnější.
U jednoduchých a přesně vymezených úloh nejspíš nepotřebujeme všechny možnosti systému s více agenty. Například v našem příkladu agenta letecké společnosti pravděpodobně existuje jen omezený počet typů požadavků, které uživatelé skutečně chtějí prostřednictvím systému zákaznické podpory vyřešit.
Protože LLM obsahuje více logiky, je mnohem náchylnější k jailbreakům a zneužití útočníky.
Rozhodování přesouvá do abstraktní vrstvy LLM, a tím znesnadňuje pochopení systému. Částečně mohou pomoci monitorovací nástroje jako Langfuse nebo Braintrust.
Poznámka pro čtenáře: Přestože se schopnosti modelů rychle mění, níže uvedená doporučení se v blízké budoucnosti pravděpodobně nezmění.
Vymezte rozsah svého problému.
Dokážete požadovanou rozhodovací logiku snadno zachytit v diagramu?
Je ve vaší aplikaci selhání nebo neočekávané chování nepřijatelné?
Odpověď „ano“ na kteroukoli z těchto otázek naznačuje, že budou vhodnější funkce založené na směrovači.
Kdykoli je to možné, doporučujeme používat přístup se směrovačem, dokud dostačuje. Obecně platí, že pokud lze část systému vyjádřit v kódu, udělejte to. LLM tedy zbytečně nepoužívejte tam, kde nejsou potřeba.
Jakmile tento přístup narazí na své limity, lze některé výhody otevřeného orchestrátoru napodobit kontrolovaným způsobem. Například:
Výběr nástrojů a předávání mezi agenty: Lze snadno implementovat pomocí podmíněného větvení nebo klasifikátorů LLM.
Určení dokončení: Jednoduché klasifikátory LLM mohou před odesláním odpovědi uživateli ověřit její úplnost.
„Plánování“ a „iterativní kombinování výstupů“ je však ve striktním systému se směrovačem nepochybně mnohem obtížnější. Pokud tedy úloha tyto funkce vyžaduje, což může určit klasifikátor LLM nebo jiná logika, doporučujeme v systému vytvořit méně omezenou větev s orchestrátorem.
Volba mezi architekturou se směrovačem a orchestrátorem by měla odpovídat míře vymezení a složitosti aplikace i způsobu interakce. Přístupy založené na směrovači v současnosti nabízejí u jasně vymezených úloh spolehlivost, efektivitu a snadné testování. Orchestrátory nabízejí větší flexibilitu pro širší konverzační interakce.
S dalším rozvojem LLM se může rovnováha mezi těmito přístupy měnit. U produkčního zatížení se přikláníme k architekturám založeným na směrovači nebo k hybridním architekturám. Orchestrátory vyhrazujeme pro otevřené problémy, které vyžadují dynamickou interakci podobnou komunikaci s člověkem.