De ce AI-ul tău clachează când un utilizator face asta în browser

De ce AI-ul tău clachează când un utilizator face asta în browser

Iun 25, 2026 ai agents computer use models gui grounding machine learning benchmarks web automation vibe hosting ai development

De ce agentele AI pentru interfețe grafice eșuează când le dai zoom out

Un experiment simplu care spune multe

Încearcă asta chiar acum. Ia un agent GUI de ultimă generație, îndreaptă-l spre un site pe care îl cunoști bine, și micșorează zoom-ul browserului la 70%. Totul arată la fel. Layout-ul nu s-a schimbat. Butoanele sunt tot acolo. Textul e doar... mai mic.

Modelul va eșua.

Nu e un caz limită. E o privire înăuntrul unei probleme fundamentale: ce măsoară benchmark-urile AI și ce are nevoie să facă un AI în producție sunt două lucruri complet diferite. Și înțelegerea acestui gol contează enorm—fie că construiești un asistent de navigare bazat pe AI, un scraper web autonom sau următoarea generație de agenți computer-use.

Iluzia Benchmark-urilor

Să clarificăm ce înseamnă de fapt numerele acelea. Modelele GUI moderne ating acum 90%+ acuratețe pe benchmark-uri precum ScreenSpot-v2. Pentru un developer care evaluează opțiuni, e tentant să citești asta ca „problema e rezolvată, percepția nu mai e blocajul."

Problema e ce nu captează aceste numere.

ScreenSpot-v2, ca majoritatea benchmark-urilor GUI, testează modelele pe screenshot-uri înghețate. Același page, randat la fel, de fiecare dată. Site-urile reale nu funcționează așa. Utilizatorii dau zoom în și în afară. Echipele livrează redesign-uri. Dark mode schimbă relațiile de culoare. Browsere diferite randă CSS-ul ușor diferit.

Modelul nu a învățat să gestioneze variația—a învățat să recunoască screenshot-uri specifice. Scorurile mari de benchmark măsoară capacitate de memorare, nu înțelegere vizuală genuină.

Cercetătorii din spatele GUI-Perturbed (de la Fig, Inc.) au vrut să cuantifice exact cât din performanța de benchmark supraviețuiește contactului cu variația ordinară. Abordarea lor: perturbă sistematic scenele vizuale pe axe controlate și măsoară scăderea acurateții. Ce au găsit ar trebui să-i facă pe oricine construiește sisteme computer-use în producție să se simtă inconfortabil.

Cele Trei Alinieri care Trebuie să Funcționeze Simultane

Înainte de rezultate, să vorbim despre ce necesită de fapt GUI grounding. Când un model vede un screenshot și o comandă precum „dă click pe butonul de submit," trei tipuri diferite de aliniere trebuie să se întâmple simultan:

Alinierea vizuală e ceea ce sună—a potrivi tipare de pixeli cu elemente de interfață. Butonul are o formă, culoare și dimensiune particulară pe care modelul trebuie să o recunoască.

Alinierea funcțională înseamnă să înțelegi ce face elementul de fapt. Un câmp de input arată diferit de o etichetă de afișare, și un buton clickable diferă de o iconiță statică, chiar dacă au trăsături vizuale comune.

Alinierea geometrică rezolvă relațiile spațiale. „Butonul de deasupra barei de căutare" sau „câmpul de formă din dreapta etichetei" necesită să înțelegi unde sunt lucrurile în raport unele cu altele, nu doar cum arată.

Partea inconfortabilă: majoritatea benchmark-urilor amestecă toate trei laolaltă. Când un model scorează 85%, nu ai cum să știi dacă a nimerit toate trei sau a excelat la vizual și a ghicit complet la geometrie. Contează pentru că modurile de eșec sunt diferite, și la fel și soluțiile.

Unde Se Sparg De Fapt Modelele

Metodologia GUI-Perturbed testează fiecare axă de aliniere independent. Rezultatele dezvăluie o ierarhie a fragilității:

1. Instrucțiunile Spațiale sunt Dezastruos de Slabe

Asta e cea mare. Când instrucțiunile se schimbă de la „dă click pe butonul de submit" la „dă click pe butonul de deasupra formularului de contact," acurateța scade între 27 și 56 de puncte în funcție de model. O scădere de 27 de puncte e îngrijorătoare. Una de 56 de puncte e disqualificatorie pentru orice folosire în producție.

Modelul poate identifica un buton specific când e numit direct. Cere-i să raționeze despre poziția acelui buton în spațiu, și performanța se prăbușește.

Asta e problematic în special pentru că instrucțiunile în limbaj natural adesea includ referințe spațiale. „Dă scroll down și click pe formă" sau „selectează opțiunea de sub header" sunt moduri intuitive prin care oamenii descriu sarcini. Sparg modelele curente aproape imediat.

2. Perturbările Vizuale Afectează Puternic

Experimentul cu zoom nu e o excepție. Schimbarea zoom-ului browserului la 70% scade acurateța cu 2 până la 6 puncte la toate cele trei modele testate. Nu e catastrofal, dar gândește-te la ce implică: modelul a învățat să recunoască elemente la o scară particulară, iar schimbările de scară sparg acea calibrare.

Utilizatorii reali dau zoom. Monitoare diferite au setări DPI implicite diferite. Aplicațiile web se randă la dimensiuni fizice diferite în funcție de dispozitiv. Acestea sunt ocurrențe de zi cu zi, nu condiții adverse.

Implicația mai deranjantă e ce ne spune asta despre cum învață modelele. Nu construiesc reprezentări invariante la scară așa cum fac oamenii—memorizează aspectul la rezoluțiile din timpul antrenamentului.

3. Raționamentul Chain-of-Thought Are Trade-off-uri

Adăugarea unui pas de raționament înainte de acțiune ajută la sarcinile relaționale grele, dar de fapt afectează performanța la cele simple și directe. Modelul trebuie să știe când să gândească și când să acționeze doar.

Asta creează o problemă practică de deployment. Nu poți să activezi chain-of-thought peste tot; ai nevoie fie de un router care decide când să gândească, fie de un model care e genuin bun la ambele moduri. Modelele curente par să se supra-gândească la sarcinile simple.

Ce Îți Cumperi De Fapt cu Post-Training

Asta e cea mai sobră descoperire: mai mult post-training specializat pe GUI nu rezolvă niciuna dintre aceste probleme.

Cele trei modele testate au același checkpoint de bază, dar au trecut prin cantități diferite de fine-tuning specific GUI. Antrenamentul suplimentar a crescut scorurile de benchmark pe scene fixe. Nu a îmbunătățit robustețea la perturbări vizuale, raționament spațial sau sensibilitate la zoom.

Asta înseamnă că câștigurile de benchmark din post-training pot fi parțial iluzorii—modelele devin mai bune la distribuția de test, nu la sarcina de bază. Se potrivesc benchmark-ului mai precis fără să construiască abilități generalizabile.

Pentru echipele care evaluează modele sau construiesc pe ele, asta e o distincție critică. „Obține 92% pe ScreenSpot-v2" îți spune că modelul poate recunoaște elemente GUI în screenshot-uri. Nu-ți spune nimic despre dacă poate gestiona variabilitatea navigării web reale.

Ce Înseamnă Asta pentru Cei Care Construiesc

Dacă construiești aplicații pe agenți computer-use, câteva lucruri rezultă din această cercetare:

Mediul tău de producție va fi mai greu decât cel de evaluare. Dacă testezi pe un set fix de pagini, nu măsori cum va performa sistemul în producție. Ia în considerare să adaugi testing cu perturbări în pipeline-ul tău de evaluare—încearcă sarcinile la diferite niveluri de zoom, cu variații CSS, pe pagini cu redesign.

Gestionarea instrucțiunilor spațiale necesită atenție specială. Dacă aplicația ta folosește instrucțiuni în limbaj natural care includ referințe spațiale, modelele general-purpose curente vor avea probleme. Asta ar putea însemna să constrângi formatele de instrucțiuni, să adaugi căi de fallback cu predicție explicită de coordonate, sau să folosești modele specializate pentru sub-sarcini de raționament spațial.

Monitorizează pentru întreruperi cauzate de redesign. Când site-urile țintă își schimbă layout-ul, acurateța agentului tău poate scădea brusc—nu pentru că modelul a devenit mai slab, ci pentru că a întâlnit o configurație vizuală pe care nu o mai văzuse. Ia în considerare să cache-uiești strategiile de localizare a elementelor și să monitorizezi drift-ul.

Drumul înainte

Această cercetare nu înseamnă că agenții computer-use sunt inutili. Înseamnă că domeniul are nevoie de modalități mai bune să măsoare ce contează cu adevărat: robustețea, nu performanța de benchmark.

Veștile bune sunt că problemele sunt acum vizibile și măsurabile. Metodologia GUI-Perturbed oferă o cale să testezi modelele dincolo de limitări pe axe specifice. Dacă construiești sau cumperi aceste sisteme, cere să vezi rezultate de evaluare rezistente la perturbări, nu doar scoruri de benchmark static.

Problema celor trei alinieri—înțelegere vizuală, funcțională și geometrică care lucrează împreună—e reală. E abordabilă. Și rezolvarea ei va debloca următoarea generație de agenți AI de încredere care funcționează cu adevărat în lumea messy și variabilă în care trăiesc utilizatorii tăi.

Pentru acum, tratează acele scoruri de benchmark de 90%+ ca punct de plecare, nu ca linie de finish. Utilizatorii tăi îți vor mulțumi când asistentul lor AI gestionează fără probleme un browser cu zoom out.

Read in other languages:

RU BG EL CS UZ TR SV FI PT PL NB NL HU IT FR ES DE DA ZH-HANS EN