Agent testujący stronę: ile kosztuje jedna udana próba?

Agent otwiera stronę, klika przyciski, wypełnia formularz i opisuje, co poszło nie tak. To obiecujący sposób sprawdzania serwisu, zwłaszcza gdy często zmieniają się treści lub ścieżki użytkownika. Przed włączeniem takiego agenta do stałego procesu warto jednak odpowiedzieć na proste pytanie: ile kosztuje jeden test, którego wynik rzeczywiście można wykorzystać?

Cena pojedynczego wywołania modelu nie wystarczy. Agent może wykonać kilka kroków, ponowić próbę, źle zinterpretować ekran albo zgłosić problem, którego nie ma. Ktoś musi potem ocenić raport. W małej firmie ten czas również ma swoją cenę.

Czego uczy przykład Asany

W opisanych przez OpenAI testach agenta przeglądarkowego Asany porównano 144 uruchomienia różnych konfiguracji. Po zmianach w sposobie przekazywania modelowi historii przeglądania oraz po wyborze modelu średni szacowany koszt modelu spadł do 0,47 USD za uruchomienie. To koszt 76 razy niższy niż w pierwotnej konfiguracji, w której wynosił co najmniej 36,21 USD. Czas skrócił się z co najmniej 22,5 minuty do około czterech minut.

Ważne zastrzeżenie: były to wyniki jednego konkretnego zadania Asany, polegającego na zebraniu danych z katalogu, a koszty są szacunkowe. Nie są cennikiem testowania dowolnej strony. Pokazują za to, jak duży wpływ na rachunek ma cały przebieg pracy agenta: ile razy odczytuje stronę, co przekazuje modelowi w kolejnych krokach i kiedy musi wrócić do wcześniejszego etapu.

Ta lekcja przenosi się na mniejsze projekty. Koszt próby, która nie dała użytecznego wyniku, mówi niewiele, dlatego warto liczyć koszt zadania wykonanego poprawnie.

Najpierw ustal, co znaczy „zaliczony test”

Załóżmy, że firma chce codziennie sprawdzać formularz zapytania na swojej stronie. Agent ma wejść na podstronę usługi, wypełnić pola, wysłać formularz w środowisku testowym i potwierdzić, że zgłoszenie dotarło. Po drodze powinien wychwycić błędy, które utrudniają wykonanie tego zadania.

Przed próbami trzeba spisać kryteria oceny. Czy agent przeszedł właściwą ścieżkę? Czy zauważył błąd, który rzeczywiście wystąpił? Czy nie zgłosił usterki, której nie ma? Czy raport zawiera kroki pozwalające odtworzyć problem? Test zaliczamy dopiero wtedy, gdy człowiek może przyjąć jego wynik bez ponownego wykonywania całego zadania.

Warto przygotować kilka scenariuszy: poprawne wysłanie formularza, brak wymaganego pola, nieprawidłowy adres e-mail i wersję mobilną. Obie porównywane konfiguracje powinny dostać te same scenariusze. W przeciwnym razie tańsza może wypaść lepiej tylko dlatego, że trafiła na łatwiejsze przypadki.

Policz koszt wyniku, nie tylko uruchomienia

Do każdego przebiegu zapisz koszt modelu, koszt środowiska przeglądarkowego, czas działania oraz minuty poświęcone przez człowieka na sprawdzenie i poprawki. Jeśli dostawca rozlicza tokeny, sprawdź osobno dane wejściowe, dane z pamięci podręcznej i odpowiedzi: OpenAI wskazuje, że mogą mieć różne stawki. Zapisz też, czy próba się powiodła.

Użytecznym wskaźnikiem jest łączny koszt serii podzielony przez liczbę poprawnie wykonanych zadań. Poniższe kwoty są wyłącznie przykładem kalkulacji, nie cenami dostawców. Zakładamy tę samą stawkę pracy osoby oceniającej: 90 zł za godzinę.

| Wynik 10 prób na tych samych scenariuszach | Konfiguracja A | Konfiguracja B | | --- | ---: | ---: | | Koszt modelu | 12 zł | 6 zł | | Koszt przeglądarki | 8 zł | 8 zł | | Czas sprawdzania raportów | 20 min = 30 zł | 40 min = 60 zł | | Poprawnie wykonane zadania | 8 | 6 | | Łączny koszt serii | 50 zł | 74 zł | | Koszt poprawnego wyniku | 6,25 zł | około 12,33 zł |

Konfiguracja B kosztowała mniej na modelu, ale dała mniej użytecznych wyników i wymagała więcej pracy człowieka. Gdyby patrzeć wyłącznie na rachunek za model, decyzja byłaby odwrotna.

To nadal mała próba. Dziesięć uruchomień pozwala wychwycić wyraźne różnice, lecz nie dowodzi, że agent będzie działał równie dobrze przez następne miesiące. Jeśli wyniki są zbliżone albo zadanie jest ważne dla sprzedaży, warto powtórzyć serię po zmianie treści, formularza lub układu strony.

Zapisuj także powody niepowodzeń

Sama liczba błędów nie podpowie, co poprawić. Przy każdym nieudanym przebiegu zanotuj, czy agent nie znalazł przycisku, pomylił pole, utknął na komunikacie, czy poprawnie przeszedł stronę, ale źle opisał wynik. Osobno oznacz problem samej strony. Dzięki temu wiadomo, czy trzeba zmienić instrukcję dla agenta, sposób odczytu ekranu, czy kod formularza.

Pomaga zapis kolejnych działań i stanu strony. Na przykład Playwright Trace Viewer pozwala przejrzeć kroki testu, widok strony oraz błędy, komunikaty konsoli i żądania sieciowe. Taki ślad ułatwia sprawdzenie raportu, a czas potrzebny na tę kontrolę powinien trafić do kalkulacji.

Przed regularnym uruchamianiem dolicz jeszcze koszt przygotowania scenariuszy, utrzymania instrukcji i przeglądu wyników po zmianach na stronie. Można rozłożyć go na planowaną liczbę testów, ale tylko wtedy, gdy ta liczba jest realistyczna. Przy kilku uruchomieniach miesięcznie koszt przygotowania może mieć większe znaczenie niż oszczędność kilku groszy na pojedynczej próbie.

Wniosek

Agent testujący stronę opłaca się wtedy, gdy dostarcza użyteczny wynik przy akceptowalnym nakładzie pracy. Przed stałym wdrożeniem uruchom kilka konfiguracji na tych samych scenariuszach i policz koszt jednego poprawnie wykonanego zadania. To liczba, która mówi więcej niż cena modelu.