AI agenti: Co skutečně dokážou a kde jsou jejich limity
Kolem umělé inteligence a specificky velkých jazykových modelů (LLM) panuje obrovské nadšení. Diskuse o tom, jak se přední AI společnosti liší od předchozích generací firem, však často probíhají na tak abstraktní úrovni, že hraničí s bezvýznamností. Je to podobné jako tvrdit, že by vaše společnost mohla být mnohem lepší, kdyby pouze přijala více softwaru - technicky to je pravda, ale není to nijak užitečné tvrzení.
Tento přístup se pokouší stručně shrnout, jak AI agenti fungují, aplikovat tento souhrn na několik reálných případů použití a obecně argumentovat, že agenti jsou násobkem kvality vašeho softwaru a systémového designu. Pokud je váš software nebo systémy špatně navržené, agenti způsobí pouze škodu.
Jak fungují AI agenti: Čtyři klíčové schopnosti
1. Vyhodnocování kontextového okna pomocí LLM
V jádru je použití LLM voláním API, které obsahuje prompt (výzvu). Například můžete zavolat Anthropic's /v1/message s promptem: "Jak bych měl ve své společnosti přijmout LLM?" Tento prompt se používá k vyplnění kontextového okna LLM, které podmiňuje model ke generování určitých typů odpovědí.
Prompt engineering nebo také context engineering (kontextové inženýrství), je rozhodování o tom, co vložit do kontextového okna, abyste nejlépe generovali odpovědi, které hledáte. Například In-Context Learning (ICL) je jednou z forem kontextového inženýrství, kde před položením otázky poskytnete řadu podobných příkladů.
2. Navrhování nástrojů a obohacování kontextu
LLM sám o sobě ve skutečnosti nástroj nevolá. Existuje pětistupňový proces volání nástrojů:
- Návrhář programu musí definovat sadu nástrojů, které LLM může navrhovat
- Každé API volání LLM zahrnuje tyto nástroje jako možnosti
- Odpověď z API je buď generovaný text, nebo doporučení zavolat konkrétní nástroj s konkrétními parametry
- Program rozhoduje, zda a jak požadované použití nástroje splnit
- Pokud se program rozhodne nástroj zavolat, vyvolá ho a zavolá LLM API s výstupem nástroje
3. Řízení toku použití nástrojů
Agenti řídí tok použití nástrojů prostřednictvím pravidel nebo statistické analýzy:
Řízení toku prostřednictvím pravidel:
- Může povolit použití daného nástroje pouze jednou v daném pracovním postupu
- Může vyžadovat lidské schválení parametrů nad určitou hodnotu (například refundace nad 100 dolarů)
- Může spustit generovaný Python program a vrátit výstup pro analýzu datové sady
- Může aplikovat systém oprávnění na použití nástrojů
Řízení toku prostřednictvím statistik:
- Pokud je velikost refundace vyšší než 99 % ostatních refundací, může eskalovat k člověku
- Pokud uživatel použil nástroj více než 99 % ostatních uživatelů, může odmítnout použití po zbytek dne
4. Agenti jako softwarové programy
Agenti mohou dělat vše, co dokáže software pro vytváření lepších kontextových oken. To zahrnuje:
- Vytváření obecného kontextu pro přidání do kontextového okna
- Iniciování pracovního postupu založeného na příchozím ticketu
- Pravidelné iniciování pracovních postupů v určitém čase
Praktický příklad 1: Agent zákaznické podpory
Typický proces zákaznické podpory má několik úrovní agentů, kteří řeší stále složitější problémy zákazníků. Cílem je nejprve převzít nejjednodušší úroveň s cílem postupně postupovat na vyšší úrovně.
Přístup by mohl být:
- Povolit ticketům (nebo chat podpory) tok do AI agenta
- Poskytnout agentovi různé nástroje pro podporu získávání informací o uživateli, eskalaci na další úroveň podpory, refundaci nákupu, uzavření uživatelského účtu
- Zahrnout pokyny pro zákaznickou podporu do kontextového okna
- Pravidla řízení toku zajišťující, že všechny hovory eskalují k člověku, pokud nejsou vyřešeny v určitém časovém období
Důležité je, že i když převedete "zákaznickou podporu na AI agenty", stále máte:
- Úroveň lidských agentů řešících nejsložitější hovory
- Lidi kontrolující periodické statistiky výkonu
- Lidi provádějící kontrolu kvality interakcí AI agent-zákazník
Praktický příklad 2: Třídění příchozích hlášení chyb
Když je ve vaší společnosti nahlášen incident nebo když obdržíte hlášení chyby, prvním problémem dne je určit, jak závažný může být problém.
Proces by mohl fungovat takto:
- Směrovat všechny vytvořené incidenty a všechny vytvořené tickety k tomuto agentovi k přezkoumání
- Zpřístupnit agentovi nástroje pro otevření incidentu, získání aktuálních incidentů, získání nedávno vytvořených ticketů, získání produkčních metrik
- Redundantní poskytovatelé LLM pro kritické pracovní postupy - pokud není API poskytovatele LLM dostupné, zkusí třikrát za deset sekund, pak se uchýlí k použití druhého poskytovatele modelu (například Anthropic první, pokud není dostupný, zkusí OpenAI)
- Sloučení duplikátů a posouzení dopadu
- Navržení příčiny a aplikace známých bezpečných feature flagů
Limity a důležité pozorování
Je důležité si uvědomit, že agenti nemohou vyřešit všechny problémy. Nemohou urychlit obnovení databáze rychleji, než podporuje šířka pásma sítě. Přístup k textovému posouzení nevytváří chybějící nástroje. Ani textové posouzení nevyřeší přístupová oprávnění nebo nenutí neexistující dokumenty k existenci.
Agenti jsou násobičem kvality vašeho systémového designu - dobře provedené agenti vás mohou učinit výrazně efektivnějšími. Špatně provedené jen více rozšíří vaše problémy.
LLM a agenti jsou mocné mechanismy, které skutečně změní způsob, jakým jsou produkty navrženy a jak fungují. Celá generace tvůrců softwaru a vedoucích pracovníků společností se právě učí, jak tyto nástroje fungují.
Software není kouzlo - software je velmi logický. To, čeho však software dokáže dosáhnout, je kouzelné, pokud ho používáme efektivně. Kombinace agentů, skvělého systémového designu a skvělého softwarového designu je to, co agentům umožní skutečně zazářit.
