Két rejtett hibát talált az Alyx működésében az Arize Signal
Két rejtett újrapróbálkozási hurkot talált az Arize saját, élesben működő Alyx AI-ügynökében a Signal nevű elemzőeszköz. A hibák nem összeomlásként jelentkeztek, hanem ismétlődő eszközhasználatként és elakadt állapotátmenetként.
- A Signal két rejtett újrapróbálkozási hurkot talált az Alyx éles futásaiban.
- Az egyik hiba egy már teljesült todo állapot ismételt frissítését okozta.
- Egy üres dataset_id mező miatt az Alyx 43-szor hívta meg a get_datasets eszközt.
- Az egyik érintett futás 227 másodpercig tartott, és a gyökérnyom állapota OK maradt.
- Az Arize szerint a javítások kicsik voltak, a hibák feltárása jelentette a nagyobb munkát.
A hagyományos monitorozás nem jelezte a problémát
Az Arize augusztus 27-i beszámolója szerint a Signal az Arize AX beépített, kezelt ügynöke, amely éles környezetben futó nyomkövetéseket vizsgál. Az ismétlődő viselkedéseket csoportosítja, rangsorolt problémákat készít belőlük, majd bizonyítékokkal, becsült hatással és javasolt következő lépéssel egészíti ki a vizsgálatokat.
Az Arize ezt a saját, Arize AX-be épített AI-mérnöki ügynökén, az Alyxon próbálta ki. Egy 30 napos időszak alatt a Signal 34 problémát azonosított az Alyx éles nyomkövetéseiben. Ezek közül kettő olyan viselkedési hibának bizonyult, amely első ránézésre szabályos ügynöktevékenységnek tűnt.
Az egyik érintett futás 227 másodpercig tartott, 192 nyomot generált, és ugyanazt az eszközt 43 alkalommal hívta meg. A gyökérnyom állapota közben továbbra is OK maradt. Az Arize szerint a problémák kijavításához végül kis kódmódosításokra volt szükség, a nehézséget a viselkedési minta megtalálása és rekonstruálása jelentette.
Egy már teljesült feladatállapot ismétlődött
Az Alyx többlépcsős munkákat kezel feladatlistával. A feladatok például pending, completed vagy blocked állapotban lehetnek, az ügynök pedig a todo_update eszközzel módosítja ezeket.
Az egyik nyomkövetésben az Alyx a finish() meghívásával próbálta lezárni a munkát, de a terv még blokkolt feladatot tartalmazott. Ezután frissíteni próbálta a blokkolt feladatot. Mivel az állapot már eleve blocked volt, az ismételt todo_update hívás javítható hibát adott vissza ahelyett, hogy sikeres, változást nem okozó műveletként erősítette volna meg az állapotot.
A válasz bekerült a modell kontextusába, ezért az Alyx úgy értelmezte, hogy a művelet sikertelen volt, és újra megpróbálta ugyanazt a módosítást. Időnként a todo_update és a finish() között váltott, miközben egyik művelet sem változtatott az állapoton. A futás végül addig ismétlődött, amíg a streamet meg nem szakították.
A javítás szerint ha a kért állapot megegyezik a jelenlegi állapottal, a todo_update sikeres eredményként adja vissza az aktuális feladatlistát. A csapat ehhez regressziós tesztet is készített. A valóban érvénytelen esetek, például a hiányzó feladatlista vagy az ismeretlen feladatazonosító hibát továbbra is jeleznek.
Üres azonosító miatt 43-szor futott le ugyanaz a hívás
A második hiba a get_datasets eszközt érintette. Ha a dataset_id mező hiányzik, az eszköz az aktuális tér adatkészleteit listázza. Ha az azonosító meg van adva, a kiválasztott adatkészlet előnézetét készíti el.
Az Alyx listázni akarta az elérhető adatkészleteket, a produkciós kérésben azonban az opcionális dataset_id mező üres szöveget tartalmazott. A típusos eszközfelületen ez továbbra is megadott értéknek számított, ezért az ellenőrzés érvénytelen adatkészlet-azonosítóként kezelte. A hibaüzenet azt javasolta, hogy az ügynök a get_datasets segítségével szerezze be az azonosítót, vagyis ugyanahhoz az eszközhöz küldte vissza.
Az egyik érintett futásban 192 nyom, 227 másodperc futási idő, 50 vezérlőiteráció és 43 ismételt get_datasets hívás szerepelt. A javítás az üres szövegek normalizálását a közös eszközfelületre helyezte át. Azok az opcionális mezők, amelyek a None értéket engedélyezik, az üres szöveget None-ra alakítják, mielőtt az eszköz saját ellenőrzése lefutna. A hozzá tartozó teszt azt ellenőrzi, hogy a produkciós kérés listázási módba kerül.
A Signal a nyomkövetésből vizsgálható hibát készít
Az Arize szerint egy mérnöknek kézi vizsgálat során először észre kell vennie, hogy egy hosszú futásban kevés érdemi előrelépés történt, majd rekonstruálnia kell a modell döntéseit és az eszközválaszokat. Ezután azt is meg kell állapítania, hogy a minta más nyomkövetésekben megjelenik-e, és melyik kódhatár felelős érte.
A Signal ezeket a lépéseket a mérnöki hibakeresés előtt részben elvégzi: összekapcsolja a hasonló nyomokat, leírja az ismétlődő viselkedést, és bizonyítékokat csomagol egy áttekinthető vizsgálatba. A csapat az eredmény alapján módosíthat promptot, kódot, konfigurációt, eszközsémát vagy értékelést, majd a produkciós kérést regressziós tesztté alakíthatja.
Az Arize példája azt mutatja, hogy az ügynökök működésének megfigyelése önmagában nem mindig deríti fel, közeledik-e a rendszer a kívánt eredményhez. A nyomkövetések rögzítik a végrehajtott lépéseket, a viselkedéselemzés pedig az ismétlődő, elakadt minták feltárásában segít.
