Společnost Postman při vývoji funkce Agent Mode přišla k poznatku, že největší překážky ne spočívají v kvalitě samotného modelu nebo v návrhu promptů, jak tým původně očekával. Hlavní potíže přineslo začlenění agenta do již vyspělého produktu, který je vybudován na základě dlouholetých předpokladů o interakci uživatelů prostřednictvím rozhraní. Tato integrace vyžadovala zapojení AI do systému, který disponuje rozsáhlou plochou funkcí a specifickým prostředím pro vývojáře. Tento proces nebyl jen technickou aktualizací, ale vyžadoval hluboké pochopení toho, jak vývojáři s nástrojem skutečně pracují. Tým musel překonávat bariéry vzniklé z kombinace komplexních systémových dependencies a specifického slovníku, který je v rámci produktu standardem.
Postman při vývoji Agent Mode zjistil, že nejtěžší nebyla kvalita modelu ani návrh promptů. Hlubší potíže přineslo začlenění agenta do vyspělého produktu s mnoha lety předpokladů o práci přes rozhraní, širokou plochou funkcí a specializovanými pojmy. Právě sladění agenta s touto strukturou stávajícího produktu tak představovalo hlavní výzvu celého vývoje.
Kontext versus dostupnost nástrojů
Kontext versus dostupnost nástrojů Společnost Postman při vývoji svého agenta původně předpokládala, že hlavní překážkou v jeho fungování bude nedostatek vhodných nástrojů. V praxi se však ukázalo, že skutečným úzkým hrdlem byl kontext. Právě chybějící nebo neúplné kontextuální informace způsobovaly v reálném provozu více selhání než absence konkrétních technických schopností agenta. Tato zkušenost ukázala, že pouhé přidání nových funkcí nestačí, pokud systém nedisponuje dostatečným přehledem o situaci, ve které se nachází uživatel. Tato zkušenost s kontextem ukázala, že i když má agent k dispozici všechny potřebné technické schopnosti, bez přesného vhledu do aktuálního stavu uživatelské session jsou tyto schopnosti v praxi nevyužitelné.
Absence správných informací měla přímý dopad na efektivitu celého systému. Postman původně předpokládal, že největší překážkou budou chybějící nástroje, v praxi však víc selhání způsobil chybějící nebo neúplný kontext. Pokud byl kontext chybný nebo zcela chyběl, staly se neúčinnými i správné nástroje.
Problémy s výběrem nástrojů u LLM
Problémy s výběrem nástrojů u LLM se projevují zejména při zvětšování počtu dostupných funkcí. Testy společnosti Postman ukázaly, že počet chyb při výběru nástrojů začal růst, jakmile viditelná sada přesáhla zhruba 40 nástrojů. Agent pak mohl volat neexistující nástroje, předávat nesprávné argumenty, a to i přes platná schémata, nebo zvolit nástroj, který působil rozumně, ale v dané situaci byl špatný. Větší a novější modely toto chování zmírnily, ale neodstranily.
Kromě technických chyb v argumentech se agenti dopustili i sémantických omylů, kdy vybrali nástroj, který působil rozumně, ale v konkrétní situaci byl nevhodný. Postman pozoroval, že novější a větší modely sice tyto tendence zmírnily, ale zcela je neodstranily. To znamená, že i u pokročilejších systémů zůstává výběr správného nástroje z rozsáhlého seznamu výzvou, kterou samotné zvětšení parametrů modelu nedokázalo plně vyřešit. Problém tedy není pouze v technické správnosti volání, ale i v kontextuálním pochopení toho, který nástroj je pro daný úkol skutečně správný.
Architektonické řešení a správa kontextu
Současná architektura Postmanu vybírá nástroje podle aktuální potřeby a kontextu a izoluje jednotlivá vlákna provádění. Kořenový agent vyhledává v databázi vektorových reprezentací nástrojů a seznam více než 170 dostupných nástrojů zúží na přibližně 15 relevantních položek. Ty následně předá kontextově izolovanému sub-agentovi, takže model vidí pouze nástroje potřebné pro daný úkol.
Kromě výběru nástrojů musel Postman vyřešit problematiku s datovým modelem rozhraní. Prosté serializování stávajících dat nebyla efektivní cesta, protože tyto objekty byly původně navrženy pro přenos dat a vykreslování, nikoliv pro proces uvažování agenta. Aby byl kontext skutečně použitelný, vyvinula společnost Postman specializované handlery pro správu kontextu. Tyto nástroje každou entitu redukují a destilují pouze na ty informace, které jsou pro správné fungování agenta nezbytné. Tímto způsobem je zajištěno, že agent pracuje s relevantními daty, která jsou optimalizována pro jeho specifické potřeby. Problém spočívá v tom, že data určená pro vykreslení v UI obsahují mnoho redundantních informací nebo technických metadat, která pro uvažování AI nejsou relevantní a pouze plní kontextové okno modelu. Specializované handlery tedy fungují jako vrstva destilace, která z komplexních objektů rozhraní extrahuje pouze sémanticky významné informace. Tento proces transformace dat z formátu „pro zobrazení“ do formátu „pro uvažování“ je klíčový pro to, aby agent mohl efektivně interpretovat stav systému a správně rozhodovat o dalším postupu.
Bezpečnost dat a provozní omezení
Bezpečnost dat v režimu Agent Mode je řešena tak, že společnost Postman nastavila nulovou retenci dat pro podporované modely. To znamená, že v konfiguraci je u těchto modelů nastaven režim retence dat na hodnotu none. Je však důležité uvědomit si, že dostupnost a konkrétní chování tohoto nastavení jsou závislé na vybraném modelu. Z tohoto důvodu je u každého modelu v produkčním prostředí nezbytné provést ověření v aktuální dokumentaci služby Amazon Bedrock, která specifikuje pravidla pro ochranu a uchovávání dat.
Kromě otázek retence dat existuje i upozornění týkající se infrastruktury. Použití geografických profilů neznamená, že samotná inference probíhá uvnitř vlastního prostředí AWS společnosti Postman. Dostupnost a chování navíc závisejí na konkrétním modelu, proto je nutné každý produkční model ověřit podle aktuální dokumentace Amazon Bedrock k ochraně dat a retenci. Tato opatření jsou klíčová pro zajištění souladu s bezpečnostními standardy a ochranu citlivých dat uživatelů v cloudovém prostředí.
Zdroje
- How Postman runs Agent Mode for 40 million developers on Amazon Bedrock | Artificial Intelligence — AWS Machine Learning Blog
Článek vznikl s pomocí AI; podklady a odkazy jsou uvedeny výše.