Iluzja benchmarków

Wyobraź sobie taką sytuację: Twój agent AI przechodzi przez interfejs webowy bez najmniejszego problemu podczas demo. Klika we właściwe przyciski, wypełnia formularze, realizuje zadania z precyzją godną superbohatera. A potem użytkownik zmienia zoom w przeglądarce na 110% i nagle model zaczyna klikać w złe elementy — albo po prostu się poddaje.

To nie jest hipotetyczny przypadek brzegowy. To systemowy problem, który ukrywa się na widoku.

Modele osiągające 90%+ na standardowych benchmarkach mierzą tak naprawdę jedną konkretną rzecz: szczytową wydajność w starannie dobranych, kontrolowanych warunkach. Są oceniane na podstawie ustawionych zrzutów ekranu z ustalonymi instrukcjami — dokładnie taki scenariusz, na który zostały wytrenowane. Ale środowiska produkcyjne tak nie działają. Strony zmieniają motywy. Użytkownicy mają różne poziomy zoomu. Tryb ciemny odwraca relacje kolorów. Ludzie opisują ten sam przycisk na dziesiątki różnych sposobów.

Model, który zdobywa 90% na benchmarku, może osiągnąć 40% w momencie, gdy zmieni się jakakolwiek zmienna.

Lekcja z robotyki

I tutaj robi się ciekawie. Środowisko robotyczne borykało się z podobnym problemem kilka lat temu. Trenowanie robotów w symulacji działało świetnie — dopóki nie trafiły do prawdziwego świata, gdzie cienie padały inaczej, powierzchnie miały nieoczekiwane tekstury, a oświetlenie zmieniało się w ciągu dnia.

Ich rozwiązaniem była randomizacja domenowa. Zamiast trenować na jednym symulowanym środowisku, roboty były wystawiane na tysiące wariantów: losowe tekstury, kąty oświetlenia, kolory obiektów, pozycje kamer. Cel polegał na zmuszeniu polityki do nauki cech, które naprawdę mają znaczenie — relacji strukturalnych, właściwości funkcjonalnych — zamiast zapamiętywania powierzchownych skrótów.

Zasada jest elegancka: jeśli podczas treningu widziałeś czerwony kubek, niebieski kubek i przezroczysty kubek, masz większą szansę rozpoznać nieznany kubek w prawdziwym świecie niż ktoś, kto widział tylko jeden konkretny kubek.

Przenoszenie na modele GUI

Analogia do agentów GUI jest uderzająca. Współczesne modele bazują elementy na prymitywach wizualnych — kształt, pozycja, kolor — zamiast na semantyce funkcjonalnej. Biały prostokąt w górnej części ekranu klasyfikowany jest jako „pole tekstowe" niezależnie od tego, czy jest to pole wyszukiwania, pasek formuł czy pole URL. Model nauczył się korelacji, które działają w określonych środowiskach, ale nie przekładają się na inne sytuacje.

Problem polega na tym, że środowiska GUI nie oferują programistycznej kontroli, jaką mają symulatory robotyki. Nie można łatwo dostosować parametrów wizualnych aplikacji desktopowej ani zmienić sposobu renderowania strony internetowej.

Jedno obiecujące podejście wykorzystuje archiwa MHTML — kompletne migawki wyrenderowanych stron internetowych, które można modyfikować na poziomie strukturalnym. Poprzez systematyczne zmienianie takich elementów jak poziomy zoomu, schematy kolorów i konfiguracje układu, badacze mogą tworzyć zbiory danych ewaluacyjnych, które naprawdę testują odporność.

Dlaczego to ma znaczenie dla Twoich wdrożeń

Dla developerów budujących automatyzację opartą na AI, te badania ujawniają krytyczną lukę w sposobie myślenia o ewaluacji modeli. Benchmarki dają pewność co do szczytowej wydajności. Tymczasem naprawdę potrzebujemy pewności co do krzywych degradacji — jak elegancko spada wydajność, gdy warunki odbiegają od rozkładu treningowego?

Kiedy wdrażasz agenta AI sterującego GUI, nie wdrażasz go do kontrolowanego laboratorium. Wdrażasz go do chaotycznego, zmiennego świata, gdzie użytkownicy mają różne przeglądarki, różne ustawienia, różne sposoby opisywania tego, czego chcą.

Modele, które wygrają w produkcji, niekoniecznie będą tymi z najwyższymi wynikami benchmarków. Będą to te, które utrzymują wydajność w najszerszym zakresie rzeczywistych warunków.

Droga do przodu

To nadal wczesne badania, ale implikacje są znaczące. Frameworki ewaluacyjne muszą włączyć zasady randomizacji domenowej. Pipeline'y treningowe powinny wystawiać modele na kontrolowane warianty podczas rozwoju. A strategie wdrożeniowe powinny uwzględniać lukę między wydajnością na benchmarkach a odpornością w rzeczywistym świecie.

Przerwa między demo a produkcją nie jest ograniczeniem obecnych modeli — to artefakt pomiarowy. Mierzyliśmy złą rzecz. Randomizacja domenowa oferuje ścieżkę do ewaluacji, która naprawdę przewiduje zachowanie w produkcji.

Do tego czasu: caveat emptor, kiedy pojawiają się te wyniki benchmarków.