Vzory návrhu systému agentů

Agenti GenAI kombinují inteligenci modelů GenAI s nástroji pro načítání dat, externí akce a další funkce. Tato stránka vás provede návrhem agenta:

• Konkrétní příklad vybudování agentního systému znázorňuje, jak se orchestruje tok volání modelu a nástroje dohromady.
• Vzory návrhu pro systémy agentů tvoří kontinuum složitosti a samostatnosti– od deterministických řetězců prostřednictvím systémů s jedním agentem, které mohou provádět dynamická rozhodnutí až po architektury s více agenty, které koordinuje více specializovaných agentů.
• Praktická část rady poskytuje rady ohledně výběru správného návrhu a vývoje agentů, testování a přechodu na produkční prostředí.

Agenti se silně spoléhají na nástroje pro shromažďování informací a provádění externích akcí. Další informace o nástrojích najdete v tématu Nástroje.

Příklad systému agentů

V případě konkrétního příkladu systému agentů zvažte agenta Call Center GenAI, který komunikuje se zákazníkem:

Zákazník odešle žádost: "Můžete mi pomoct vrátit poslední objednávku?"

1. Důvod a plán: Vzhledem k záměru dotazu agent "plans": "Look up the user's recent order and check our return policy" (Vyhledat poslední objednávku uživatele a zkontrolovat naši zásadu vrácení).
2. Vyhledání informací (data intelligence): Agent se dotazuje v databázi objednávek, aby získal příslušnou objednávku a odkazuje na směrnicový dokument.
3. Důvod: Agent zkontroluje, jestli se tato objednávka vejde do návratového okna.
   • Volitelný zásah člověka: Agent zkontroluje další pravidlo: Pokud položka spadá do určité kategorie nebo je mimo normální návratové okno, postoupit člověku.
4. akce: Agent aktivuje proces vrácení a vygeneruje expediční štítek.
5. Důvod: Agent vygeneruje odpověď pro zákazníka.

Agent AI odpoví zákazníkovi: "Hotovo! Tady je expediční štítek..."

Tyto kroky jsou samozřejmostí v kontextu call centra pro člověka. V kontextu systému agenta LLM "uvažuje," přičemž systém využívá specializované nástroje nebo zdroje dat k doplnění podrobností.

Úrovně složitosti: Od LLM po systémy agentů

Aplikace GenAI můžou používat celou řadu systémů, od jednoduchých volání LLM až po komplexní systémy s více agenty. Při vytváření jakékoli aplikace využívající AI začněte jednoduše. Představte si složitější chování agentů, když je skutečně potřebujete pro lepší flexibilitu nebo rozhodování řízená modelem. Deterministické řetězce nabízejí předvídatelné toky založené na pravidlech pro dobře definované úlohy. Více agentní přístupy nabízejí větší flexibilitu a potenciál, ale vyžadují vyšší složitost a přinášejí potenciální latenci.

Návrhový vzor	Kdy použít	Výhody	Nevýhody
LLM + prompt	Obecná otázka a odpověď Rychlý prototyp krátkodobého použití	Velmi jednoduché Snadné vytvoření	Minimální přizpůsobení
deterministický řetězec	Dobře definované úkoly Statické kanály, jako je základní RAG Není třeba se rozhodovat za běhu	Stručně Snadné auditování	Neohebný Vyžaduje úpravy kódu pro přizpůsobení.
Systém s jedním agentem	Střední až složité dotazy ve stejné doméně Některá dynamická rozhodnutí bez režie více specializovaných agentů	Flexibilní Jednodušší než více agentů Dobré "výchozí"	Méně předvídatelné Je třeba se chránit před opakovanými nebo nesprávnými voláními nástrojů
systému s více agenty	Velké nebo mezioborové domény Několik "expertních" agentů s odlišnými kontexty logiky nebo konverzace	Vysoce modulární Škálování na velké domény	Složité na orchestraci Trasování a ladění je obtížnější

Vlastní agenti jsou nezávislí na těchto vzorech návrhu, takže můžete začít jednoduše a vyvíjet směrem k vyšší úrovni automatizace a autonomii s rostoucími požadavky na aplikace.

Další informace o teorii systémů agentů najdete v blogových příspěvcích od zakladatelů Databricks:

• AI agentní systémy: Modulární inženýrství pro spolehlivé podnikové aplikace AI
• přechod z modelů na složené systémy AI

LLM a výzva

Nejjednodušší návrh má samostatný model LLM nebo jiný model GenAI, který reaguje na výzvy na základě znalostí z rozsáhlé trénovací datové sady. Tento návrh je vhodný pro jednoduché nebo obecné dotazy, ale často se odpojí od skutečných obchodních dat. Chování můžete přizpůsobit zadáním výzvy systému s vlastními pokyny nebo vloženými daty.

deterministický řetězec (pevně zakódované kroky)

Deterministické řetězce rozšiřují modely GenAI voláním nástrojů, ale vývojář definuje, které nástroje nebo modely se volají, v jakém pořadí a s jakými parametry. LLM nerozhoduje o tom, které nástroje se mají použít nebo v jakém pořadí. Systém se řídí předdefinovaným pracovním postupem nebo řetězem pro všechny požadavky, takže je vysoce předvídatelný.

Například řetězec deterministické načítání rozšířené generace (RAG) může vždy:

1. Načtení výsledků nejvyšších k z vektorového indexu za účelem vyhledání kontextu relevantního pro požadavek uživatele
2. Rozšíření výzvy zkombinováním požadavku uživatele s načteným kontextem
3. Vygenerujte odpověď odesláním rozšířené výzvy do LLM.

Kdy použít:

• Pro dobře definované úkoly s předvídatelnými pracovními postupy.
• Pokud jsou hlavní prioritou konzistence a auditování.
• Pokud chcete minimalizovat latenci tím, že se vyhnete několika voláním LLM pro rozhodování o orchestraci.

Výhody:

• Nejvyšší předvídatelnost a auditovatelnost
• Obvykle nižší latence (méně volání LLM pro orchestraci).
• Jednodušší testování a ověření.

Aspekty:

• Omezená flexibilita pro zpracování různorodých nebo neočekávaných požadavků.
• Může se stát složitým a obtížně udržovatelným s rostoucími větvemi logiky.
• Může vyžadovat významný refaktoring pro rozšíření možností.

Systém s jedním agentem

Systém s jedním agentem má LLM, který orchestruje jeden koordinovaný tok logiky. LLM adaptivně rozhoduje, které nástroje použít, kdy uskutečňovat více volání LLM a kdy se zastavit. Tento přístup podporuje dynamická rozhodnutí s podporou kontextu.

Systém s jedním agentem může:

1. Přijměte požadavky, jako jsou dotazy uživatelů a jakýkoli relevantní kontext, jako je historie konverzací.
2. Přemýšlet o tom, jak nejlépe reagovat, a případně rozhodnout, zda volat nástroje pro externí data nebo akce.
3. V případě potřeby iterujte, opakovaně volejte LLM nebo nástroje, dokud nedosáhnete cíle nebo není splněna určitá podmínka, například příjem platných dat nebo řešení chyby.
4. Integrujte výstupy nástrojů do konverzace.
5. Vrátí soudržnou odpověď jako výstup.

Agent helpdesku se například může přizpůsobit následujícím způsobem:

• Pokud se uživatel zeptá na jednoduchou otázku ("Co je naše zásada vrácení?"), může agent odpovědět přímo ze znalostí LLM.
• Pokud chce uživatel stav objednávky, může agent zavolat funkci lookup_order(customer_id, order_id). Pokud tento nástroj odpoví neplatným číslem objednávky, může agent zkusit znovu nebo vyzvat uživatele, aby zadal správné ID, a pokračovat, dokud nebude moct poskytnout konečnou odpověď.

Kdy použít:

• Očekáváte různé dotazy uživatelů, ale stále v rámci soudržné domény nebo oblasti produktu.
• Některé dotazy nebo podmínky mohou zaručovat použití nástrojů, jako je například rozhodnutí o načtení zákaznických dat.
• Chcete větší flexibilitu než deterministický řetězec, ale nevyžadujete samostatné specializované agenty pro různé úlohy.

Výhody:

• Agent se může přizpůsobit novým nebo neočekávaným dotazům tak, že zvolí, které (pokud nějaké) nástroje se mají volat.
• Agent může procházet opakované volání LLM nebo vyvolání nástrojů k upřesnění výsledků bez nutnosti plně nastavit více agentů.
• Tento vzor návrhu často představuje ideální řešení pro podnikové scénáře použití – ladění je jednodušší než u systémů s více agenty, přičemž stále umožňuje dynamickou logiku a omezenou autonomii.

Aspekty:

• Ve srovnání s pevně zakódovanou sekvencí je třeba chránit před opakovanými nebo neplatnými voláními nástrojů. Nekonečné smyčky můžou nastat v jakémkoli scénáři volání nástrojů, proto nastavte počet iterací nebo časové omezení.
• Pokud vaše aplikace pokrývá zcela odlišné subdomény (finance, devops, marketing atd.), může se jeden agent stát neskladným nebo přetíženým požadavky na funkčnost.
• Stále potřebujete pečlivě navržené výzvy a omezení, aby byl agent zaměřený a relevantní.
• Agentnost je kontinuum; čím více volnosti poskytujete modelům pro řízení chování systému, tím více agentní se aplikace stává. V praxi většina produkčních systémů pečlivě omezuje autonomii agenta, aby zajistila dodržování předpisů a předvídatelnost, například vyžadováním lidského schválení rizikových akcí.

systému s více agenty

Systém s více agenty zahrnuje dva nebo více specializovaných agentů, kteří vyměňují zprávy nebo spolupracují na úlohách. Každý agent má vlastní doménu nebo znalosti úkolů, kontext a potenciálně odlišné sady nástrojů. Samostatný "koordinátor" nebo "supervizor AI" směruje žádosti příslušnému agentovi nebo rozhodne, kdy se má předat z jednoho agenta do druhého. Nadřízený může být jiný LLM nebo směrovač založený na pravidlech.

Například asistent zákazníka může mít nadřízeného, který deleguje na specializované agenty:

• Nákupní asistent: Pomáhá zákazníkům hledat produkty a poskytovat rady o výhodách a nevýhodách z recenzí
• Agent zákaznické podpory: Zpracovává zpětnou vazbu, vrácení a expedici.

Kdy použít:

• Máte odlišné oblasti problémů nebo sady dovedností, jako je programovací agent nebo finanční agent.
• Každý agent potřebuje přístup k historii konverzací nebo k zobrazení výzev specifických pro doménu.
• Máte tolik nástrojů, že je nepraktické všechny vložit do schématu jednoho agenta; každý z agentů může vlastnit podmnožinu.
• Chcete implementovat reflexi, kritiku nebo spolupráci mezi specializovanými agenty.

Výhody:

• Tento modulární přístup znamená, že každý agent může být vyvinut nebo udržován samostatnými týmy, které se specializují na úzkou doménu.
• Dokáže zvládnout rozsáhlé a složité podnikové pracovní postupy, se kterými by mohl mít jednotlivý agent problémy při jejich souhrnném řízení.
• Usnadňuje pokročilé vícekrokové nebo více perspektivní odůvodnění – například jeden agent generuje odpověď, jiný ho ověřuje.

Aspekty:

• Vyžaduje strategii směrování mezi agenty a režijní náklady na protokolování, trasování a ladění napříč několika koncovými body.
• Pokud máte mnoho dílčích agentů a nástrojů, může být obtížné rozhodnout, který agent má přístup k datům nebo rozhraním API.
• Agenti můžou nekonečně předávat úkoly mezi sebou bez vyřešení, pokud nejsou pečlivě omezeni. Rizika nekonečných smyček existují také při používání nástrojů s jedním agentem, ale systémy s více agenty přidávají další vrstvu složitosti při ladění.

Praktické rady

Pokud se váš případ použití dá vyřešit pomocí nástroje Knowledge Assistant nebo nabídky funkcí umělé inteligence , začněte s tím jednodušším způsobem.

Pokud potřebujete vytvořit vlastní systém agentů, pak Azure Databricks a Custom Agents jsou nezávislé na tom, který vzor zvolíte, a usnadňuje vývoj vzorů návrhu při růstu vaší aplikace. Zvažte následující osvědčené postupy pro vývoj stabilních a udržovatelných systémů agentů:

1. Začít jednoduché: Pokud potřebujete jenom jednoduchý řetěz, deterministický řetězec se rychle sestaví.
2. Postupné přidávání složitosti: Když potřebujete dynamičtější dotazy nebo flexibilní zdroje dat, přejděte do systému s jedním agentem pomocí volání nástrojů. Pokud máte jasně odlišné domény nebo úkoly, více kontextů konverzací nebo velkou sadu nástrojů, zvažte systém s více agenty.
3. Kombinování vzorů: V praxi mnoho systémů agentů z reálného světa kombinuje vzory. Například většinou deterministický řetězec může mít jeden krok, ve kterém LLM může dynamicky volat určitá rozhraní API v případě potřeby.

Pokyny pro vývoj

• Výzvy a nástroje
  • Udržujte výzvy jasné a minimální, abyste se vyhnuli protichůdným instrukcím, rušivým informacím a omezte halucinace.
  • Poskytněte pouze nástroje a kontext, které agent vyžaduje, a ne nevázanou sadu rozhraní API nebo velký irelevantní kontext. Během návrhu vyberte svůj přístup k nástrojům .
• Protokolování a monitorování systému
  • Implementujte podrobné protokolování pro každou žádost uživatele, plán agenta a volání nástroje pomocí trasování MLflow.
  • Bezpečně ukládejte protokoly a mějte na paměti identifikovatelné osobní údaje (PII) v datech konverzací. Zvažte klasifikaci dat pro automatizaci.

Pokyny k testování a iteraci

• Vyhodnocení
  • Použijte MLflow vyhodnocení a monitorování produkce k definování metrik pro vývoj a produkci.
  • Shromážděte od odborníků a uživatelů zpětnou vazbu a zajistěte, aby vaše metriky automatizovaného vyhodnocení byly dobře kalibrované.
• Zpracování chyb a záložní logika
  • Naplánujte selhání nástrojů nebo LLM. Vypršení časového limitu, nesprávných odpovědí nebo prázdných výsledků může přerušit pracovní postup. Zahrnout strategie opakování, záložní logiku nebo jednodušší záložní řetěz při selhání pokročilých funkcí.
• Iterativní vylepšení
  • Počítejte s tím, že v průběhu času upřesníte výzvy a logiku agenta. Provádějte změny verzí svých promptů pomocí registru promptů MLflow. Správa verzí zjednoduší operace a umožní vrácení zpět a porovnání.
  • Při shromažďování vyhodnocovacích dat a definování metrik zvažte více automatizovaných metod optimalizace, jako je optimalizace výzvy MLflow.

Pokyny pro produkční prostředí

• Aktualizace modelů a pevné přiřazení verzí
  • Chování LLM se může změnit, když poskytovatelé aktualizují modely na pozadí. Pomocí připnutí verzí a častých regresních testů zajistěte, aby logika agenta zůstala robustní a stabilní.
• Latence a optimalizace nákladů
  • Každé další volání LLM nebo nástroje zvyšuje využití tokenu a dobu odezvy. Pokud je to možné, zkombinujte kroky nebo opakované dotazy do mezipaměti, abyste zachovali výkon a správu nákladů.
• Zabezpečení a sandbox
  • Pokud váš agent může aktualizovat záznamy nebo spustit kód, izolujte tyto akce nebo vynucujte lidské schválení, pokud je to potřeba. To je důležité v podnikových nebo regulovaných prostředích, aby nedocházelo k neúmyslným škodám. Funkce katalogu Unity poskytují spouštění v izolovaném prostoru (sandbox) pro produkční prostředí.
  • Další pokyny k možnostem nástrojů najdete v nástrojích agenta AI .

Podle těchto pokynů můžete zmírnit řadu nejběžnějších způsobů selhání, jako jsou chybná volání nástrojů, posun výkonu LLM nebo neočekávané špičky nákladů, a vytváříte spolehlivější škálovatelné systémy agentů.