LLM-bíró nélkül is felismerhetők az AI-ügynökök bizonyos hibái

Egy sikeres futás mögött is lehet hibás folyamat

Az Arize AI 2026. október 6-án közölt vendégbejegyzése egy LangGraph-alapú release ügynök példáján mutatja be, miért lehet fontos az ügynökök működési nyomainak, vagyis trace-einek strukturális ellenőrzése. A kísérletben a gpt-4o-mini modellt használó ügynöknek a 4.12.0 verzió kiadását kellett volna végrehajtania.

A tesztelt pipeline-eszköz HTTP 200 választ adott, miközben a Jenkins eredménye UNSTABLE volt, mivel a 215 tesztből 3 megbukott. Az ügynök ennek ellenére éles környezetbe telepítette a buildet, majd azt közölte, hogy a 4.12.0 verziót kiadta. A trace minden spanja sikeres futást jelzett, miközben az ügynök észlelte a teszthibákat, mégis folytatta a telepítést.

Amikor a rendszerutasítás tartalmazta, hogy csak sikeres pipeline után szabad telepíteni, az ügynök tíz futásból egyszer sem telepített. A mondat eltávolítása után mind a tíz futásban telepített. Az Arize szerint ez olyan regresszió, amelynek felismerésére a CI-folyamat alkalmas lehet.

A tracelint a trace-ben bizonyítható hibákat keresi

A bejegyzés szerzője, Ashwin Govind Ugale, a tracelint nevű, nyílt forráskódú lintelő eszközt készítette el. Az eszköz az OpenInference trace-eit vizsgálja, köztük az Arize Phoenix által gyűjtött adatokat, és helyben vagy CI-környezetben futtatható.

A szabály alapja egyszerű: ha a döntéshez tudni kell, mit kellett volna jelentenie az ügynöknek, vagy mi volt a szándéka, akkor értékelésre van szükség. Ha a döntés kizárólag a trace-ben rögzített adatokból, valamint a felhasználó által megadott eszközszabályokból következik, determinisztikusan ellenőrizhető.

Ilyen bizonyítható eset lehet a JSON-sémát sértő eszközhívás, egy nem létező eszköz meghívása, illetve egy hibás eredmény továbbadása egy mellékhatással járó műveletnek. Az ismétlődő hívások előrehaladás nélkül csak jelöltként jelennek meg, mivel ezek lekérdezést vagy jogos újrapróbálkozást is jelenthetnek. Az, hogy az ügynök rossz stratégiát választott, már feladatspecifikus értékelési kérdés.

A release példájában a tools.json fájlban kellett megadni, hogy az UNSTABLE, a FAILURE és az ABORTED pipeline-eredmény hibának számít, továbbá azt, hogy a deploy eszköz mellékhatással jár. Ezután a tracelint két megállapítást jelzett: a pipeline deklaráltan hibás eredményt adott, majd annak buildazonosítóját a productiont módosító deploy hívás használta fel. Az eszköz 2-es kilépési kóddal zárta a futást, így a CI-feladat meghiúsult.

Háromféle eredmény, külön szerepekkel

A tracelint három kategóriába sorolja a megállapításokat. A hard defect olyan hiba, amelyet maga a trace bizonyít. Ezek a CI-ben hibát okoznak. A candidate lehetséges problémát jelez, például ismétlődő hívásokat, de önmagában nem állítja, hogy valódi hiba történt, ezért nem állítja le a buildet.

A harmadik kategória a not checked. Ez azt jelenti, hogy az ellenőrzéshez nem állt rendelkezésre elegendő információ. Ha például a deploy eszköznél nincs megadva, milyen eredmény számít hibának, a tracelint nem állítja, hogy a telepítés sikeres volt.

A készítők szerint a determinisztikus trace-ellenőrzések az egyetlen futásból bizonyítható strukturális szabályokra valók. Az értékelések a feladatminőség, a viselkedés, a megalapozottság, az eszközválasztás és a szabályzatok vizsgálatát szolgálják. A productionvizsgálat pedig az ismétlődő vagy korábban ismeretlen hibaminták felderítésére alkalmas.

Az eszköz telepíthető a pip install tracelint paranccsal, és az Arize szerint a repository rögzítési segédet, pytest-fixture-t és GitHub Actiont is tartalmaz. A módszer előnye a szerzők szerint az, hogy a bizonyítható hibákat külön kezeli a bizonytalan mintáktól, így az ismétlődő hívások vagy az értékek átalakítása miatt nem minősít automatikusan hibásnak minden gyanús folyamatot.