Agentní pracovní postupy, které se nezlomí: Volání nástrojů, Human-in-the-Loop a švy mezi systémy

Automatizace obchodních procesů a agent AI se prodávají jako totéž, a nejsou. Automatizace je pevný kanál: druhý krok vždy následuje po prvním stejně. Agent je smyčka, ve které model rozhoduje o tom, který krok bude následovat, na základě toho, co právě vrátilo volání nástroje. Obojí má své místo – většina z toho, co podnik skutečně potřebuje, je automatizace s jedním nebo dvěma rozhodovacími body agenta, nikoli agent, který provádí každý hovor.

Architektura pod obojím je to, co určuje, zda přežije kontakt se skutečnými daty: jak naplníte kontext modelu, jak získáte odpověď zpět ve tvaru, kterému váš kód důvěřuje, jak se model dostane do jiných systémů a kde člověk stále musí říci ano. To, na co trávím většinu projektu, je instalatérství, ne výběr modelu.

1. Kontextové inženýrství: dodávání modelu správný řez, ne všechno

Kontextové inženýrství je neoslnivou prací rozhodování o tom, co model při daném hovoru vidí – které záznamy, které předchozí odbočky, které pokyny – a co je stejně důležité, co nevidí. Vypsat celou historii zákazníka nebo celý dokument do výzvy pokaždé není důkladné; je to hluk, který odsouvá skutečnou otázku dále od pozornosti modelu a tiše zvyšuje náklady na každý hovor.

Vzor, který se drží, je blíže problému vyhledávání než problému paměti: načtěte dva nebo tři záznamy relevantní pro tento konkrétní krok, shrňte, co se stalo předtím, místo toho, abyste to doslovně přehráli, a nechte agenta požádat o další, jen když to potřebuje. Pracovní postup, který spolehlivě vytáhne správných pět řádků z deseti tisíc, překoná ten, který nacpe všech deset tisíc a doufá.

2. Strukturované výstupy a volání nástroje/funkce jsou skutečným rozhraním

Model, který odpovídá ve volném textu a je analyzován pomocí regulárního výrazu, je místem, kde tyto sestavení tiše selhávají ve výrobě. Strukturované výstupy – schéma JSON, na které je model nucen odpovědět uvnitř – a volání nástroje/funkce – model požadující konkrétní funkci se zadanými argumenty namísto popisu akce v próze – umožňují vašemu kódu důvěřovat odpovědi natolik, aby na ni mohl reagovat, aniž by člověk znovu četl každý výstup.

Schema ověřuji na cestě z modelu a znovu, než se dostane do reálného systému, protože model může produkovat syntakticky platné JSON, které je stále špatné pro dané obchodní pravidlo – záporné množství, datum v minulosti, měna, kterou účet nepodporuje. Schéma zachycuje chyby tvaru; druhá, nudná ověřovací vrstva zachycuje ty, které jsou platné JSON a stále jsou špatné.

3. Vkládání a vektorová databáze - pouze v případě, že je hledání skutečnou prací

Vložení a vektorová databáze si vydobyjí své místo, když je úkolem skutečně vyhledávat: najděte tři lístky podpory, které jsou nejblíže tomuto novému, najděte klauzuli ve smlouvě, která se nejvíce blíží této otázce. Jsou špatným nástrojem pro pevnou, malou sadu záznamů, na které již odpovídá běžný databázový dotaz – viděl jsem vektorovou databázi přišroubovanou k pracovnímu postupu, který měl jedenáct možných kategorií, kde by vyhledávací tabulka byla rychlejší, levnější a snáze se ladila.

Když je to správný nástroj, část, která skutečně potřebuje péči, není model vkládání – jde o to, co se rozdělí, jak a jak čerstvý zůstane index po změně zdrojového dokumentu. Vektorové vyhledávání přes zastaralé kusy poskytuje sebevědomou, špatnou odpověď a nic ve výstupu agenta vám neřekne, že se to stalo.

4. Human-in-the-loop a API orchestrace: kde se to skutečně zlomí

Neúspěch, který vidím nejvíce, není špatně uvažovaný model – je to šev mezi dvěma systémy: API hovor, který vyprší a agent to zopakuje dvakrát a odešle duplicitní příkaz; webhook, který se spustí před dokončením zápisu předchozího kroku; volání nástroje, které je úspěšné na straně dodavatele, ale odpověď, kterou agent obdrží, říká, že selhalo. Uspořádání hovorů přes CRM, fakturaci a e-mail znamená rozhodování o tom, co se stane při vypršení časového limitu nebo částečném selhání předtím, než k tomu dojde v produkci, nikoli po něm.

Vše, co posílá peníze, smaže záznam nebo e-maily zákazníkovi, dostane před spuštěním potvrzovací krok od člověka – ne proto, že by byl model obecně nedůvěryhodný, ale protože náklady na nesprávnou automatickou akci jsou asymetrické s cenou jednoho kliknutí navíc. Byl bych raději, kdyby někdo schvaloval dvacet správných akcí denně, než aby agent automaticky posílal jednu chybnou fakturu.

Závěr: agent je snadný 10%

Vybrat model a napsat první výzvu je skutečně ta snadná část agentského pracovního postupu. Kontext, který se vkládá, schéma, které se ověřuje, vektorové vyhledávání, které se spouští pouze tehdy, když má, logika opakování ve třech APIs a jeden krok, který člověk stále schvaluje – to je zbylých 90 %, a to je to, co rozhoduje o tom, zda automatizace bude fungovat i v úterý za šest měsíců s daty, které nikdo netestoval. Napište do formuláře proces, který chcete zautomatizovat, a já vám řeknu, kterých 10 % je agent a kterých 90 % je část, která skutečně potřebuje sestavit.