A Google AQuA ügynöke a produkciós AI-agentek hibáit keresi

A sikeres technikai futás még nem jelent jó választ

A Google Developers Blog október 8-i bejegyzése szerint egy agent akkor is működőképesnek látszhat, ha minden HTTP 200-as választ ad, betartja a késleltetési keretet, és egyik eszközhívása sem jelez hibát. Ettől még rögzítheti például a 3A ülőhelyet megerősítettként anélkül, hogy ellenőrizné, szabad-e, vagy vegán utazónak ajánlhat florentini steaket.

A Google tapasztalata szerint az agent fejlesztésének első szakasza viszonylag gyorsan teljesíthető. Egy értékelési adatkészlet, egy kódoló agent, valamint a futtatásból, osztályozásból, javításból és összehasonlításból álló szoros fejlesztési ciklus napok alatt eljuttathatja a rendszert az előre ismert tesztesetek kezeléséig. A produkciós indulás után azonban a minőség görbéje ellaposodhat vagy romolhat.

Ennek oka, hogy a felhasználói forgalom idővel eltérhet a kezdeti értékelési adatkészlettől. Közben a modell, a tesztelési keretrendszer, az eszközök vagy a készségek módosítása úgy is megváltoztathatja a beszélgetések minőségét és a feladatok sikerességét, hogy az infrastruktúra-ellenőrzések továbbra is hibátlannak mutatják a rendszert.

Öt lépésben vizsgálja a produkciós munkameneteket

Az AQuA, vagyis Ambient Quality Agent a Google Cloud-projektben, az agent mellett fut. Ütemezetten, minden telepítés után vagy igény szerint vizsgálja a Cloud Trace, a Cloud Logging vagy a BigQuery adataiból származó munkameneteket. A nyers átiratok, a forráskód pillanatképei és a BigQuery-táblák a projekt határain belül maradnak. Az AQuA nem módosítja az agentet, és nem vesz részt a kérések kiszolgálásában.

Egy futás legfeljebb 1000, véletlenszerűen kiválasztott friss munkamenetet dolgoz fel. Ezután kilenc szempont alapján ellenőrzi őket, köztük az eljárást, az eszközök és argumentumok használatát, a megalapozottságot és a feladat teljesítését. Sikertelenség esetén strukturált tényleges és elvárt eredményt rögzít.

A rendszer ezeket a megállapításokat közös hibamechanizmus szerint csoportosítja, majd egy külön modell legfeljebb három teljes átirat alapján ellenőrzi az egyes hibacsoportokat. A bizonyítékokkal alá nem támasztott csoportokat elveti. A megmaradó problémákat a BigQuery-ben újként, visszatérőként vagy 14 napos észlelési hiány után automatikusan megoldottként követi.

A fejlesztők a goal.md fájlban egyszerű angol nyelvű célt adhatnak meg a vizsgálat irányításához, míg az eval_config.yaml fájlban meghatározott Python-mutatók a sikerességi arányok trendjeit mérhetik. Alapértelmezés szerint az AQuA munkamenetenként egy modellhívással értékel. Opcionálisan a Gemini platform kezelt AutoRaters értékelői is használhatók.

A hibát a kódhoz vagy a munkamenet egy lépéséhez köti

Ha egy megállapítás további vizsgálatot érdemel, a fejlesztő a vezérlőpultról vagy az agents-cli aqua run paranccsal indíthat gyökérok-elemzést. Az AQuA a hibás munkameneteket a telepítéskor rögzített, változtathatatlan forráskód-pillanatképpel veti össze.

Ha a probléma a projekt kódjában van, a rendszer a fájl elérési útját és a kapcsolódó sorokat is megadja, majd a pillanatképhez kötött módosítási javaslatot készít. Ha a hiba külső függőségből, átadásból vagy lekért adatból származik, ezt a munkamenet megfelelő lépéséhez rendeli, kódmódosítás javaslata nélkül. A Google szerint az AQuA önállóan nem alkalmaz változtatást, és nem nyit pull requestet.

A bemutatóban szereplő travel-concierge több alügynökön keresztül kezeli az utazástervezést, és a munkamenet állapotában tárolja az út adatait. Az AQuA célja, hogy a produkciós forgalomból diagnosztizált, kódhoz köthető megállapításokat és archivált hibás átiratokat adjon vissza a fejlesztési ciklusnak. A Google az eszközt nyíltan elérhető, saját projektekben futtatható és tovább alakítható építőelemekként mutatta be.