Amikor a benchmarkered nem azt méri, amit gondolsz

Van egy egyszerű kísérlet, amit bárki elvégezhet. Fogj egy csúcskategóriás GUI agensmodellt, mutasd meg neki egy ismerős weboldalt, majd állítsd a böngésző zoomját 70%-ra. A felület pontosan ugyanúgy néz ki – csak kisebb. A gombok ugyanott vannak.

A modell valószínűleg elbukik.

És ez nem valami ritka edge case. Ez egy ablak arra a alapvető törésvonalra, ami a benchmarkok és a valóság között húzódik. Ha AI-alapú böngészési asszisztenst, autonóm web scrapert vagy számítógép-használó agenseket építesz, ez a szakadék létfontosságú lehet a munkád szempontjából.

A benchmark illúziója

Nézzük meg, mit jelentenek ezek a százalékok a gyakorlatban. A modern GUI modellek 90%+ accuracy-t érnek el olyan benchmarkokon, mint a ScreenSpot-v2. Első ránézésre ez azt sugallja: a probléma megoldva, a perceptuális rész nem akadály többé.

Csakhogy ezek a számok nem azt mérik, ami számít.

A ScreenSpot-v2 és hasonló benchmarkok befagyasztott képernyőképeket használnak. Ugyanaz az oldal, ugyanúgy renderelve, minden alkalommal. De a valós web nem így működik. A felhasználók zoomolnak. A csapatok újradesignolnak. A dark mode megváltoztatja a színviszonyokat. Különböző böngészők ugyanazt a CSS-t eltérően jelenítik meg.

A modell nem arra tanult, hogy kezelje a változatosságot – arra tanult, hogy felismerjen konkrét képernyőképeket. Azok a magas benchmark pontszámok valójában memorizálási kapacitást mérnek, nem valódi vizuális megértést.

A GUI-Perturbed kutatói (a Fig, Inc.-től) épp ezt akarták kvantifikálni. A módszerük: szisztematikusan zavarták a vizuális jeleneteket kontrollált módon, és mérték az accuracy csökkenését. Az eredmények kellemetlen meglepetést okozhatnak bárkinek, aki élesben használ computer-use rendszereket.

A hármas illesztési probléma

Mielőtt az eredményekbe mélyednénk, beszéljük meg, mit is jelent pontosan a GUI grounding. Amikor egy modell lát egy képernyőképet és egy parancsot – mondjuk "kattints a beküldő gombra" – három különböző típusú illesztésnek kell egyszerre megtörténnie:

Vizuális illesztés pont azt jelenti, amit a neve sugall: pixelminták megfeleltetése felületi elemeknek. A gombnak sajátos alakja, színe és mérete van, amit a modellnek fel kell ismernie.

Funkcionális illesztés azt jelenti, hogy megérti, mit csinál az adott elem. Egy beviteli mező máshogy néz ki, mint egy címke, és egy kattintható gomb különbözik egy statikus ikontól – még ha vizuálisan van is átfedés köztük.

Geometriai illesztés a térbeli viszonyokat oldja meg. "A gomb a keresősáv felett" vagy "a mező a címke jobb oldalán" – itt arról van szó, hol vannak dolgok egymáshoz képest, nem csak az, hogy néznek ki.

És itt jön a kellemetlen rész: a legtöbb benchmark összemossa mind a hármat. Amikor egy modell 85%-ot üt, nem tudod meg, mindhárom területen brillírozott-e, vagy a vizuális részen nagyot alkotott, miközben geometriából csak tippelt. Pedig a hibaüzemmódok különböznek – és a javítások is.

Hol törnek meg a modellek

A GUI-Perturbed módszertan minden illesztési tengelyt önállóan stressz-tesztel. Az eredmények egyértelmű hierarchiát mutatnak:

1. Térbeli utasítások – katasztrofálisan gyengék

Ez a legnagyobb probléma. Amikor az utasítás "kattints a beküldő gombra" helyett "kattints a contact űrlap feletti gombra" lesz, az accuracy 27 és 56 pont között esik vissza – modelltől függően. 27 pont már aggasztó. 56 pont pedig kizárja bármilyen éles használatból.

A modell képes azonosítani egy konkrét gombot, ha megnevezed. De kérd meg, hogy gondolkodjon a térbeli pozíciójáról – és összeomlik a teljesítménye.

Ez azért különösen problémás, mert a természetes nyelvű utasítások gyakran tartalmaznak térbeli hivatkozásokat. "Görgess le és kattints az űrlapra" vagy "válaszd ki a fejléc alatti opciót" – ezek intuitív módjai annak, ahogy emberek leírják a feladatokat. És a jelenlegi modellek szó szerint azonnal elbuknak rajtuk.

2. Vizuális perturbációk keményen ütnek

A zoom-kísérlet nem kivétel. A böngésző zoom 70%-ra állítása 2-6 pont accuracy csökkenést okoz minden vizsgált modellnél. Ez önmagában nem katasztrofális, de gondolj bele, mit jelent: a modell egy bizonyos méretaránynál tanulta felismerni az elemeket, és a méretváltozás elbonyolítja ezt a kalibrációt.

A valós felhasználók zoomolnak. A különböző monitorok eltérő alapértelmezett DPI beállításokkal rendelkeznek. A webalkalmazások más fizikai méretben renderelődnek különböző eszközökön. Ezek mindennapi események, nem adversary körülmények.

A még aggasztóbb következtetés: a modellek nem úgy tanulnak, mint az emberek. Nem skála-invariáns reprezentációkat építenek – a betanításkori felbontáson való megjelenést memorizálják.

3. A chain-of-thought reasoning kompromisszumokkal jár

Ha a cselekvés előtt egy gondolkodási lépést adsz hozzá, az segít a nehéz relációs feladatokon – de valójában ront a könnyű, direkt feladatok teljesítményén. A modellnek tudnia kellene, mikor gondolkodjon és mikor cselekedjen egyszerűen.

Ez gyakorlati deployment problémát okoz. Nem kapcsolhatod be mindenhol a chain-of-thought-ot; vagy egy router kell, ami eldönti, mikor gondolkodjon a modell, vagy egy olyan modell, ami mindkét módban jó. A jelenlegi modellek túlagyalják az egyszerű feladatokat.

Mit ad valójában a post-training

Itt a legnyugtalanítóbb eredmény: a GUI-specifikus post-training nem oldja meg egyik problémát sem.

A három vizsgált modell ugyanazt az alap checkpointot használja, de különböző mértékű GUI-specific fine-tuning-on esett át. A plusz training felverte a fix-scene benchmark eredményeket. De nem javította a robusztusságot vizuális perturbációkkal, térbeli érveléssel vagy zoom-érzékenységgel szemben.

Ez azt jelenti, hogy a post-training-ből származó benchmark nyereségek részben illúziók. A modellek jobban teljesítenek a teszteloszláson, nem az alapfeladaton. Pontosabban illeszkednek a benchmarkhoz anélkül, hogy általánosítható képességeket építenének.

Ha modelleket értékelsz ki vagy építesz rájuk, ez kritikus különbség. Az "eléri a 92%-ot a ScreenSpot-v2-n" azt jelenti, hogy a modell felismeri GUI elemeket képernyőképeken. De nem jelenti azt, hogy kezeli a valós web böngészés variabilitását.

Mit jelent mindez az építőknek?

Ha computer-use agensekre építesz alkalmazásokat, néhány dolog következik ebből a kutatásból:

Az éles környezeted nehezebb lesz, mint az értékelési környezeted. Ha fix oldalkészlettel tesztelsz, nem azt mérd, hogyan fog működni a rendszer élesben. Érdemes perturbation tesztelést építeni az értékelési folyamatodba – próbáld ki a feladatokat különböző zoom szinteken, CSS variációkkal, újradesignolt oldalakon.

A térbeli utasítások kezelése külön figyelmet igényel. Ha az alkalmazásod természetes nyelvű utasításokat használ térbeli hivatkozásokkal, a jelenlegi általános modellek küzdeni fognak. Ez jelentheti az utasításformátumok korlátozását, explicit koordináta-predikciós fallback utak hozzáadását, vagy specializált modellek használatát a térbeli érvelés alfeladataihoz.

Figyelj a redesign törésekre. Amikor a célweboldalak megváltoztatják az elrendezésüket, az agensed accuracy-je hirtelen eshet – nem azért, mert a modell romlott, hanem azért, mert egy vizuális konfigurációval találkozott, amit korábban nem látott. Érdemes elemelrendezési stratégiákat cacholni és driftet monitorozni.

A továbbvezető út

Ez a kutatás nem jelenti azt, hogy a computer-use agensek használhatatlanok. Azt jelenti, hogy a szakmának jobb módszerekre van szüksége arra, ami tényleg számít: robusztusságra, nem benchmark teljesítményre.

A jó hír az, hogy a problémák most láthatók és mérhetők. A GUI-Perturbed módszertan lehetőséget ad arra, hogy a modelleket specifikus tengelyek mentén stressz-teszteljük. Ha építesz vagy vásárolsz ilyen rendszereket, követeld meg a perturbáció-rezisztens értékelési eredményeket – ne csak a statikus benchmark pontszámokat.

A hármas illesztési probléma – a vizuális, funkcionális és geometriai megértés együttműködése – valós. Megoldható. És megoldása fogja lehetővé tenni a következő generációs, megbízható AI agenseket, akik tényleg működnek a kaotikus, változékony világban, ahol a felhasználóid élnek.

Egyelőre kezeld azokat a 90%+ benchmark eredményeket kiindulópontként, nem célállomásként. A felhasználóid hálásak lesznek, amikor az AI asszisztensük gond nélkül kezeli a lekicsinyített böngészőt.