Asana: 76× niższe koszty w testach przeglądarki z GPT‑6.1 Sol
Dzięki GPT‑6 Astra w Codex agent przeglądarkowy Asany działał w testach 76 razy taniej i 5 razy szybciej, co pozwala oferować klientom modele o większych możliwościach.
76×
Niższe szacunkowe koszty modelu w zoptymalizowanym procesie opartym na GPT-6.1 Sol
5×
Szybsze przebiegi przeglądarkowe w zoptymalizowanym procesie opartym na GPT-6.1 Sol
0,47 USD
Średni szacunkowy koszt modelu w zoptymalizowanym procesie opartym na GPT-6.1 Sol
Dzięki eksperymentom prowadzonym przez GPT‑6 Astra w Codex Asana zoptymalizowała proces pracy swojego agenta przeglądarkowego opartego na GPT‑6.1 Sol. Działa on teraz 76 razy taniej i 5 razy szybciej.
Asana pomaga klientom automatyzować pracę w aplikacjach biznesowych za pośrednictwem StackAI(otwiera nowe okno) — platformy, którą przejęła(otwiera nowe okno). Korzystając ze StackAI, klienci mogą bez pisania kodu tworzyć procesy, które przeglądają strony internetowe, wypełniają formularze i zbierają informacje. Przy skali działania Asany nawet drobne straty wydajności w tych procesach zaczynają mieć znaczenie.
Dr Frank Hidalgo, dyrektor ds. technologii StackAI w Asanie, postanowił przyspieszyć działanie agenta przeglądarkowego i obniżyć koszty jego pracy. Zlecił GPT‑6 Astra w Codex zbadanie agenta, przetestowanie usprawnień i porównanie wyników. Praca, która według jego szacunków zajęłaby ręcznie od miesiąca do dwóch, zajęła około tygodnia.
W badaniu Asany obejmującym 144 przebiegi(otwiera nowe okno) przetestowano GPT‑6.1 Sol i trzy inne pionierskie modele, nazwane tutaj Modelami A, B i C. Opracowany w ten sposób zoptymalizowany proces oparty na GPT‑6.1 Sol kosztował średnio 0,47 USD według szacunkowych kosztów modelu, a jego wykonanie trwało około czterech minut. Był więc 76 razy tańszy i 5 razy szybszy niż pierwotna konfiguracja produkcyjna oparta na Modelu B.
„Tak w praktyce wyglądają zespoły ludzi i agentów. Inżynier wyznaczył kierunek, GPT-6 Astra przeprowadził eksperymenty, a ich wyniki trafiły przez Command do środowiska produkcyjnego. To pokazuje, jak Asana umożliwia tworzenie działających zespołów ludzi i agentów”.
Aby szybko ruszyć z pracami, Hidalgo najpierw wykorzystał GPT‑6 Astra w Codex do zbadania struktury kodu i wyjaśnienia, jak agent buduje każde żądanie wysyłane do modelu. GPT‑6 Astra odkrył, że agent zapisywał w pamięci podręcznej stałe instrukcje i definicje narzędzi, ale nie gromadzoną historię tekstu stron i zrzutów ekranu. Każde żądanie ponownie przesyłało więc tę historię przy pełnej stawce.
Agent usuwał też starsze zrzuty ekranu i przycinał tekst niemal na każdym kroku. Każda taka modyfikacja zmieniała historię, więc samo zapisywanie jej w pamięci podręcznej by nie pomogło. Utrata informacji mogła zaś zmuszać agenta do ponownego odwiedzania już przeczytanych stron.
Hidalgo przeanalizował poprawki zaproponowane przez GPT‑6 Astra i wybrał trzy do przetestowania:
Objęcie pamięcią podręczną historii przeglądania agenta
Zwiększenie ilości zachowywanego tekstu
Usuwanie zrzutów ekranu partiami zamiast na każdym kroku
GPT‑6 Astra zaczął od szybkich testów, aby ustalić, które zmienne mają znaczenie. Ponieważ kod nie był przystosowany do kontrolowanych eksperymentów, model następnie go zrefaktoryzował, tak aby jeden frontend i backend mogły obsługiwać wiele procesów równolegle, każdy z własnymi ustawieniami.
Astra przeprowadził pełne badanie: dwa limity historii — 120 000 i 480 000 znaków — oraz sześć strategii pamięci podręcznej i zarządzania zrzutami ekranu. Każdą konfigurację przetestowano trzykrotnie na każdym z czterech modeli (zobacz tabelę poniżej). Najlepsza strategia pozwalała gromadzić zrzuty ekranu do liczby 20, a następnie usuwała wszystkie poza najnowszym. Dzięki temu wcześniejsza historia pozostawała niezmieniona przez dłuższe okresy między kolejnymi usunięciami. Ta strategia w połączeniu z większym limitem historii stała się podstawą zoptymalizowanego procesu. Każda konfiguracja wykonywała to samo zadanie: zebranie sześciu pól danych dla każdej z 32 książek z publicznego katalogu demonstracyjnego. Zadanie to było reprezentatywne dla procesów uruchamianych w StackAI przez część klientów Asany.
Model | Opis | Cena |
|---|---|---|
Model A | Mniejszy, tańszy model z innego pionierskiego laboratorium, udostępniony jesienią 2025 r. | Połowa ceny GPT‑6.1 Sol |
Model B | Model pierwotnie używany w środowisku produkcyjnym, z tego samego laboratorium co Model A, udostępniony latem 2026 r. | Taka sama cena jak GPT‑6.1 Sol |
Model C | Zaktualizowana wersja Modelu B, udostępniona jesienią 2026 r. | Taka sama cena jak GPT‑6.1 Sol |
GPT‑6.1 Sol | Model OpenAI |
GPT‑6 Astra uruchamiał procesy i analizował żądania, rejestry zużycia i wyniki, a osobne sesje modelu weryfikowały tę pracę. Żądania, ślady danych i wyniki każdej sesji zapisywano w Command(otwiera nowe okno), platformie Asany do dostarczania oprogramowania, aby zespół mógł później przeanalizować całe badanie. W Command ustalenia przekształcono w zgłoszenia, a następnie w pull requesty. Zmiany trafiły do środowiska produkcyjnego.
„Ręcznie zajęłoby mi to od miesiąca do dwóch. Z GPT-6 Astra w Codex zajęło to około tygodnia: przed snem wyznaczałem cel poleceniem /goal, a rano sprawdzałem wyniki”.
W przypadku Modelu B optymalizacja obniżyła szacunkowy koszt modelu z co najmniej 36,21 USD (niektóre pierwotne przebiegi osiągały limit kroków przed ukończeniem zadania) do 1,24 USD na przebieg, czyli 29-krotnie. Zoptymalizowany proces oparty na GPT‑6.1 Sol był jeszcze 2,6 razy tańszy — kosztował 0,47 USD. W zoptymalizowanym procesie każdy przebieg kończył się wykonaniem zadania i zwróceniem poprawnej odpowiedzi.
Średnie z 3 przebiegów. ≥: konfiguracja bazowa obejmuje przebiegi przerwane przez limit, więc jej średnia stanowi dolną granicę.
Dwa wskaźniki krotności po prawej odnoszą się do Modelu B po optymalizacji. Model B testowano w etapie 1, a Model C i Sol 6.1 w etapie 2 tego samego badania (linia kropkowana).
W przypadku samego GPT‑6.1 Sol, przy większym limicie historii, nowa strategia pamięci podręcznej i zarządzania zrzutami ekranu obniżyła koszt 4-krotnie: z 1,97 do 0,47 USD na przebieg. Każde wywołanie było około 3 razy tańsze, ponieważ 89% danych wejściowych pochodziło z pamięci podręcznej, przy stawce wynoszącej 5% ceny danych spoza pamięci podręcznej. Skrócił się również czas wykonania: z co najmniej 22,5 minuty w pierwotnej konfiguracji opartej na Modelu B do około czterech minut w zoptymalizowanym procesie opartym na GPT‑6.1 Sol.
Średnia z 3 przebiegów; wąsy oznaczają odchylenie standardowe. ≥: średnia obejmuje przebieg przerwany przez limit lub nieukończony, więc rzeczywista wartość jest co najmniej tak wysoka.
Słupki mają niebieską kolorystykę. Efekty użycia pamięci podręcznej należy porównywać ze słupkiem dla większego limitu historii (480 tys.).
Znaczniki przebiegów i wąsy odchylenia standardowego odtworzono w przybliżeniu z obrazu źródłowego; oryginalne wartości przebiegów i odchylenia standardowe nie były dostępne.
Średnia z 3 przebiegów; wąsy oznaczają odchylenie standardowe. ≥: średnia obejmuje przebieg przerwany przez limit lub nieukończony, więc rzeczywista wartość jest co najmniej tak wysoka.
Słupki mają niebieską kolorystykę. Efekty użycia pamięci podręcznej należy porównywać ze słupkiem dla większego limitu historii (480 tys.).
Znaczniki przebiegów i wąsy odchylenia standardowego odtworzono w przybliżeniu z obrazu źródłowego; oryginalne wartości przebiegów i odchylenia standardowe nie były dostępne.
Badanie pokazało też, jak zarządzanie historią wpływało na to, czy agent w ogóle udzieli odpowiedzi. Zwiększenie miejsca na historię przeglądania GPT‑6.1 Sol podniosło liczbę przebiegów zakończonych odpowiedzią z trzech na 18 przy mniejszym limicie historii do wszystkich 18 przy większym limicie. Każda z tych odpowiedzi była poprawna. Dla Hidalgo wartość biznesowa polega na udostępnianiu klientom szybszych modeli o większych możliwościach przy utrzymaniu kosztów operacyjnych na rozsądnym poziomie.
„Koszty ograniczały wcześniej wybór modeli, które mogliśmy oferować klientom do tych zadań. Dzięki zwiększeniu wydajności agenta możemy udostępnić klientom lepszy, szybszy model, a jednocześnie obniżyć nasze koszty operacyjne”.
Asana wdrożyła już zmiany w nawigacji przeglądarkowej w StackAI i tworzy narzędzia ułatwiające powtarzanie podobnych eksperymentów. Z czasem zespół planuje włączyć takie testy do mechanizmów oceny na platformie. Dzięki temu klienci i zespoły wewnętrzne będą mogli porównywać koszty, czas wykonania i jakość odpowiedzi podczas konfigurowania swoich agentów.
„Ograniczeniem nie jest już tempo wdrażania, lecz ludzka uwaga. Zbliżamy się do świata, w którym każdy inżynier jest menedżerem produktu kierującym flotą agentów”.
Asana wykorzystuje teraz GPT‑6 Astra w Codex do testowania funkcji produktu przed ich udostępnieniem: Astra porusza się po platformie, wypróbowuje różne dane wejściowe i zgłasza błędy specjalistom ds. kontroli jakości. Hidalgo postrzega to jako fundament nowego cyklu tworzenia oprogramowania, w którym wiele sesji agentów w chmurze testuje funkcje równolegle.
Pełne badanie jest dostępne na blogach Asana(otwiera nowe okno) i StackAI(otwiera nowe okno).
