Dlaczego Twoje AI potrafi kliknąć guzik na screenshotcie, ale nie w prawdziwej przeglądarce

Prosty eksperyment, który powinien cię zaniepokoić

Zróbmy szybki test. Weź dowolny nowoczesny model GUI, skieruj go na znaną stronę internetową i zmień zoom przeglądarki na 70%. Układ się nie zmienia. Guziki są w tych samych miejscach. Cała zawartość jest identyczna – tylko mniejsza.

Model najprawdopodobniej się pogubi.

To nie jest przypadek brzegowy. To wgląd w fundamentalną rozbieżność między tym, co mierzą benchmarki AI, a tym, co produkcyjne AI faktycznie musi robić. Ta luka ma znaczenie – niezależnie od tego, czy budujesz asystenta przeglądania z AI, autonomiczny web scraper, czy kolejna generację agentów komputerowych.

Iluzja benchmarków

Przyjrzyjmy się, co te liczby tak naprawdę oznaczają. Współczesne modele GUI osiągają teraz ponad 90% dokładności na benchmarkach takich jak ScreenSpot-v2. Dla dewelopera evaluującego opcje to łatwa liczba do interpretacji jako „ten problem jest rozwiązany, percepcja nie jest już wąskim gardłem".

Problem tkwi w tym, czego te liczby nie pokazują.

ScreenSpot-v2, podobnie jak większość benchmarków GUI, testuje modele na zamrożonych screenshotach. Ta sama strona, wyrenderowana tak samo, za każdym razem. Prawdziwe strony tak nie działają. Użytkownicy przybliżają i oddalają widok. Zespoły wdrażają redesigny. Tryb ciemny zmienia relacje kolorów. Różne przeglądarki renderują ten sam CSS trochę inaczej.

Model nie nauczył się radzić sobie ze zmiennością – nauczył się rozpoznawać konkretne screenshoty. Te wysokie wyniki benchmarkowe mierzą zdolność zapamiętywania, nie prawdziwe rozumienie wizualne.

Badacze stojący za GUI-Perturbed (z Fig, Inc.) postanowili dokładnie量化, ile tej wydajności z benchmarków przetrwa kontakt ze zwykłą zmiennością. Ich podejście: systematycznie zaburzaj sceny wizualne w kontrolowany sposób i mierz spadek dokładności. To, co znaleźli, powinno zaniepokoić każdego, kto buduje produkcyjne systemy do obsługi komputera.

Problem potrójnego wyrównania

Zanim przejdziemy do wyników, porozmawiajmy o tym, co GUI grounding faktycznie wymaga. Kiedy model widzi screenshot i polecenie typu „kliknij przycisk wyślij", muszą jednocześnie zdarzyć się trzy różne rodzaje wyrównania:

Wyrównanie wizualne brzmi dokładnie tak, jak się wydaje – dopasowanie wzorców pikseli do elementów interfejsu. Przycisk ma określony kształt, kolor i rozmiar, które model musi rozpoznać.

Wyrównanie funkcjonalne oznacza zrozumienie, co element faktycznie robi. Pole tekstowe wygląda inaczej niż etykieta wyświetlacza, a klikalny przycisk różni się od statycznej ikony, nawet jeśli dzielą cechy wizualne.

Wyrównanie geometryczne rozwiązuje relacje przestrzenne. „Przycisk nad paskiem wyszukiwania" lub „pole formularza na prawo od etykiety" wymaga zrozumienia, gdzie rzeczy znajdują się względem siebie, nie tylko jak wyglądają.

Oto niekomfortowa część: większość benchmarków wrzuca wszystkie trzy do jednego worka. Kiedy model zdobywa 85%, nie ma sposobu, żeby dowiedzieć się, czy opanował wszystkie trzy, czy może perfekcyjnie sobie radzi z wizualnym, podczas gdy zupełnie zgaduje z geometrią. To ma znaczenie, bo tryby awarii są różne, i naprawy тоже.

Gdzie modele faktycznie się łamią

Metodologia GUI-Perturbed testuje każdą oś wyrównania niezależnie. Wyniki pokazują hierarchię kruchości:

1. Instrukcje przestrzenne są katastrofalnie słabe

To jest ten duży problem. Kiedy instrukcje zmieniają się z „kliknij przycisk wyślij" na „kliknij przycisk nad formularzem kontaktowym", dokładność spada o 27 do 56 punktów w zależności od modelu. Spadek o 27 punktów jest niepokojący. Spadek o 56 punktów dyskwalifikuje z jakiegokolwiek zastosowania produkcyjnego.

Model potrafi zidentyfikować konkretny przycisk, gdy jest nazwany bezpośrednio. Poproś go o rozumowanie o tym, gdzie ten przycisk znajduje się w przestrzeni, a wydajność się załamuje.

To szczególnie problematyczne, bo naturalne instrukcje językowe często zawierają odniesienia przestrzenne. „Przewiń w dół i kliknij formularz" lub „wybierz opcję pod nagłówkiem" to intuicyjne sposoby, jak ludzie opisują zadania. One psują obecne modele niemal natychmiast.

2. Zaburzenia wizualne bolą mocno

Eksperyment z zoomem nie jest odosobnionym przypadkiem. Zmiana zoomu przeglądarki na 70% obniża dokładność o 2 do 6 punktów we wszystkich trzech testowanych modelach. To nie jest katastrofalne, ale zastanów się, co to implikuje: model nauczył się rozpoznawać elementy w jednej konkretnej skali, a zmiany skali psują tę kalibrację.

Prawdziwi użytkownicy przybliżają. Różne monitory mają różne domyślne ustawienia DPI. Aplikacje webowe renderują się w różnych fizycznych rozmiarach w zależności od urządzenia. To są codzienne sytuacje, nie warunki adversarialne.

Bardziej niepokojąca implikacja dotyczy tego, czego to wszystko uczy nas o tym, jak modele się uczą. Nie budują reprezentacji niezmienniczych względem skali tak jak ludzie – zapamiętują wygląd w rozdzielczościach z czasu treningu.

3. Chain-of-thought ma swoje kompromisy

Dodanie kroku rozumowania przed działaniem pomaga przy trudnych zadaniach relacyjnych, ale faktycznie pogarsza wydajność przy łatwych, bezpośrednich. Model musi wiedzieć, kiedy myśleć, a kiedy po prostu działać.

To tworzy praktyczny problem wdrożeniowy. Nie możesz po prostu włączyć chain-of-thought wszędzie; potrzebujesz albo routera, który decyduje, kiedy myśleć, albo modelu, który jest naprawdę dobry w obu trybach. Obecne modele zdają się nadmiernie analizować proste zadania.

Co tak naprawdę daje post-training

Oto najbardziej przygnębiające odkrycie: bardziej wyspecjalizowany post-training GUI nie rozwiązuje żadnego z tych problemów.

Trzy testowane modele dzielą ten sam bazowy checkpoint, ale przeszły przez różną ilość fine-tuningu specyficznego dla GUI. Dodatkowe treningi podniosły wyniki na benchmarkach ze statycznymi scenami. Nie poprawiły odporności na zaburzenia wizualne, rozumowanie przestrzenne ani czułość na zoom.

To oznacza, że zyski benchmarkowe z post-treningu mogą być częściowo iluzoryczne – modele stają się lepsze w dystrybucji testowej, nie w samym zadaniu. Dopasowują się do benchmarku precyzyjniej, nie budując uogólnialnych zdolności.

Dla zespołów evaluujących modele lub budujących na nich, to jest kluczowe rozróżnienie. „Osiąga 92% na ScreenSpot-v2" mówi ci, że model potrafi rozpoznawać elementy GUI na screenshotach. Nie mówi nic o tym, czy poradzi sobie ze zmiennością prawdziwego przeglądania sieci.

Implikacje dla budowniczych

Jeśli budujesz aplikacje na szczycie agentów komputerowych, kilka rzeczy wynika z tych badań:

Twoje środowisko produkcyjne będzie trudniejsze niż środowisko ewaluacyjne. Jeśli testujesz na ustalonej liście stron, nie mierzysz tego, jak system będzie działał w produkcji. Rozważ włączenie testowania z zaburzeniami do swojego pipeline'u ewaluacyjnego – próbuj swoich zadań przy różnych poziomach zoomu, z wariacjami CSS, na stronach po redesignu.

Obsługa instrukcji przestrzennych wymaga specjalnej uwagi. Jeśli twoja aplikacja używa naturalnych instrukcji językowych zawierających odniesienia przestrzenne, obecne modele ogólnego przeznaczenia będą się zmagać. Może to oznaczać ograniczenie formatów instrukcji, dodanie fallback path z przewidywaniem konkretnych koordynatów lub użycie wyspecjalizowanych modeli dla podzadań wymagających rozumowania przestrzennego.

Monitoruj pod kątem awarii po redesignach. Kiedy docelowe strony zmieniają swoje układy, dokładność twojego agenta może nagle spaść – nie dlatego, że model się pogorszył, ale dlatego, że napotkał konfigurację wizualną, której wcześniej nie widział. Rozważ cachowanie strategii lokalizacji elementów i monitorowanie dryfu.

Droga przed nami

To badanie nie oznacza, że agenci komputerowi są bezużyteczni. Oznacza, że branża potrzebuje lepszych sposobów mierzenia tego, co faktycznie ma znaczenie: odporności, nie wydajności benchmarkowej.

Dobra wiadomość jest taka, że problemy są teraz widoczne i mierzalne. Metodologia GUI-Perturbed daje sposób na testowanie modeli pod kątem konkretnych osi. Jeśli budujesz lub kupujesz te systemy, żądaj wyników ewaluacji odporności na zaburzenia, nie tylko statycznych wyników benchmarkowych.

Potrójny problem wyrównania – wizualne, funkcjonalne i geometryczne rozumienie działające razem – jest realny. Da się go rozwiązać. I jego rozwiązanie odblokuje następną generację niezawodnych agentów AI, którzy faktycznie działają w chaotycznym, zmiennym świecie, w którym żyją twoi użytkownicy.

Na razie traktuj te ponad 90% wyniki benchmarkowe jako punkt wyjścia, nie linię mety. Twoi użytkownicy podziękują ci, kiedy ich asystent AI bez problemu obsłuży przybliżoną przeglądarkę.