Miért buknak el a frontier AI-ügynökök a valódi mérnöki munkán?

Jelentősen magasabbra került a mérce

A korábban Frontier-Bench néven futó Terminal-Bench 3.0 azt vizsgálja, mire képesek az AI-ügynökök valós számítógépes munkafolyamatokban. A teszt 74 hiteles, ellenőrizhető feladatot tartalmaz hét területen. A Snorkel AI a benchmark minőségbiztosításának kialakításában, a kategóriák felépítésében, a teljes tesztelésben és a javításokban is részt vett, továbbá több, valós rendszerek hibakeresését és gépi tanulási infrastruktúrát érintő feladatot készített.

A vállalat szerint a Terminal-Bench 2.1 már telítődőben volt, a vezető ügynökök 84 százalékos eredményt is elértek rajta. A Terminal-Bench 3.0-n ezzel szemben a legjobb modell, Claude Opus 5, 43,5 százalékot teljesített. A Snorkel AI két feladattal szemlélteti, milyen típusú mérnöki döntéseket próbál mérni az új kiadás.

Az első feladatban a tünet javítása nem elég

A session-window-debug egy adatfolyam-feldolgozó rendszert modellez. A rendszer időbélyeges eseményeket csoportosít munkamenetekbe, az inaktivitási időszakok alapján összesítést készít, majd eltávolítja a régi állapotokat. Az ügynök három tünetet kap: a későn érkező események miatt eltűnnek a nemrég aktív munkamenetek, az összevonások eredménye nincs összhangban az eseménytörténettel, illetve leáll a kimenet, ha az adatforrások eltérő sebességgel termelik az eseményeket. A feladat megoldására két óra áll rendelkezésre.

A hibák az eseményidő, a vízjel előrehaladása, az állapot törlése és az összevonási logika kölcsönhatásában jelennek meg. Egyenként minden kódrészlet ésszerűnek és dokumentáltnak tűnhet, a helyes működés azonban csak hosszabb eseménysorozatok alapján látható. A Snorkel AI által vizsgált próbálkozásokban az ügynökök gyakran megtaláltak egy hibát, majd túl korán befejezettnek nyilvánították a feladatot. A javítás sokszor csak a legkönnyebben reprodukálható tünetet tüntette el, miközben a rendszer teljes viselkedése eltért a tervben rögzített szerződéstől.

A feladat ellenőrzője eseményfolyamokat játszik vissza, és a kimenetet a dokumentált működéssel veti össze. Ezért a megoldást nem lehet pusztán kódbeli minták alapján megkerülni. A Snorkel AI szerint a feladat egy tapasztalt szakembertől is egy koncentrált munkanapot igényelhet.

A monitor hibája könnyen összekeverhető a zajjal

Az embedding-drift-monitor egy olyan gépi tanulási megfigyelőrendszert modellez, amely a beérkező beágyazási ablakokat hasonlítja össze egy referencia-alappal. Ehhez KS, PSI és MMD statisztikai teszteket használ, a riasztásokat pedig egy késleltető, úgynevezett debouncing rétegen keresztül küldi tovább. Az ügynök több .npy fájlt kap, köztük stabil beágyazásokat, egyértelmű eltolódást és nullvektoros szélső eseteket. A feladat szerint a monitort teljes egészében meg kell javítani, nem csak a riasztási réteget.

A rendszer hibái csendben jelentkeznek. Egy hibás monitor is számot és logikai értéket ad vissza, ezért nincs összeomlás vagy veremnyom, amely megmutatná a probléma helyét. A tünetek között szerepelhet, hogy stabil forgalom indít riasztást, a valódi eltolódás észrevétlen marad, illetve a riasztási állapot nem követi az adatokat.

A javításhoz egyszerre kell érteni a NumPy és a SciPy numerikus konvencióit, a kernelalapú kétmintás teszteket, az ablakolás működését, a kalibrációt és az állapotgépes riasztáskezelést. A kód kommentárjai ráadásul gyakran valós, általánosságban helyes megfontolásokkal indokolják a hibás viselkedést. A Snorkel AI szerint az ügynökök rendszerint az egyetlen függvényhívással ellenőrizhető hibákat javítják, majd megállnak, miközben a teljes rendszer több ablakon át jelentkező problémái megmaradnak.

A két példa alapján a Terminal-Bench 3.0 olyan helyzeteket céloz, ahol a sikerhez nem elég egy látható tünet megszüntetése. A felhasználói és mérnöki munkában ez azt jelenti, hogy az ügynöknek a teljes működési szerződést kell megőriznie, és a javítást hosszabb, valószerű folyamatokon is ellenőriznie kell.