Objazdy AI, za które nie powinniście płacić

Nie chodzi o to, że czołowe firmy AI nie próbowałyby przechylić szali na swoją korzyść przy sprzedaży tokenów, gdyby mogły sobie na to pozwolić — w końcu Anthropic w czerwcu wprowadził faktyczną podwyżkę cen o 30%; DeepSeek w sierpniu podniósł ceny API, a OpenAI niechętnie wycofało się z obniżki średniego limitu tokenów pod koniec września. Wyraźnie widać więc trend w kierunku oszczędności.

Ta myśl rzeczywiście często powraca, gdy agent AI zużywa cały dzienny limit tokenów w ciągu 45 minut, generując kod, który niekoniecznie jest powodem do chwały, a potem każe ci wrócić za 3–4 godziny. W tak frustrującej chwili trudno nie zastanawiać się, czy część mechanizmów składających się na ten proces nie działa na korzyść dostawców. W końcu to dobry sposób, by skłonić nas do dopłaty za specjalny pakiet tokenów — a nawet do włączenia „automatycznego doładowania”.

Cóż, jeśli rzeczywiście tak jest, to w obecnym okresie czołowe firmy mogą całkiem wiarygodnie zasłaniać się tym, że nie do końca rozumiemy, jak wykorzystywane są tokeny w zadaniach realizowanych przez agentów, w różnych modelach i środowiskach. One też tego nie rozumieją. Poza mechanizmami inicjowania płatności (które działają nadzwyczaj sprawnie) wszystko jest na etapie przedalfa i nadal stanowi przedmiot badań z samej czołówki, mimo powszechnej komodytyzacji produktu.

Ograniczanie marnotrawstwa

To, że agenci AI marnują tokeny (a tym samym twoje pieniądze), gdy rozumują w przepływach pracy z udziałem agentów, jest już dobrze udokumentowane: dokładnie rok temu pisałem o nowych badaniach pokazujących, w jakim stopniu modele AI zdolne do rozumowania mają skłonność do zużywania tokenów na „rozwlekłe wywody”; na początku tego roku pisałem o kolejnych badaniach, według których rozumowanie łańcuchowe może być „czysto dekoracyjne”; a w zeszłym tygodniu Nils Bunge, dyrektor ds. produktu w Tsuga, w artykule eksperckim opublikowanym tutaj, stwierdził:

„Zespół zużywający dwa razy więcej tokenów niekoniecznie tworzy dwa razy większą wartość. Może wykonywać trudniejsze zadania, korzystać z niepotrzebnie potężnego modelu albo polegać na agencie, który wielokrotnie ponawia nieudane próby”.

Mniej znany jest sposób, w jaki tokeny są marnowane na niepotrzebne zadania lub procesy. Właśnie temu zagadnieniu poświęcono nowy artykuł naukowy, który dziś ponownie zwrócił moją uwagę na ten temat.

Ten nowy artykuł, zatytułowany Jak agenci AI marnują twoje pieniądze?, jest efektem współpracy amerykańskich środowisk akademickich* i przedstawia ujednolicone ramy pozwalające określić, ile tokenów rzeczywiście marnują procesy z udziałem agentów. W przypadku modeli o zamkniętym kodzie źródłowym metodologia „cienia” łączy się z oficjalnymi statystykami i wskaźnikami dostawców, by zapewnić równie szczegółowy obraz tego, co działo się z tokenami, gdy AI rozumowała i podejmowała działania:

Nowa metoda pomiaru marnowanych tokenów AI. Zapisuje się rozumowanie, działania i koszty każdego agenta, a następnie analizuje je pod kątem powtórzeń, niepotrzebnych zapytań i możliwych do uniknięcia objazdów. Zidentyfikowane straty są eliminowane, a następnie ponownie sprawdza się, czy agent potrafi wykonać pierwotne zadanie. Źródło

Jak pokazano powyżej, agent może pracować normalnie, a komunikacja z dostawcą AI jest przechwytywana i zapisywana — w tym przypadki rozumowania, korzystania z narzędzi, zużycie tokenów i koszty. Zapisane dane są następnie analizowane przez sędziów opartych na dużych modelach językowych (LLM), którzy oddzielają użyteczną pracę od powtórzeń, niepotrzebnych wyszukiwań i objazdów. Następnie usuwa się podejrzewane straty, oblicza oszczędność tokenów i wznawia pracę agenta, by sprawdzić, czy nadal potrafi skutecznie wykonać zadanie.

W testach badacze ustalili, że marnowano około 18% tokenów wyjściowych agentów. W ponad 45% zadań jeden agent marnował więcej tokenów, niż inny potrzebował, by pomyślnie wykonać to samo zadanie. Badacze ustalili ponadto, że usunięcie 41–46% niepotrzebnego rozumowania miało bardzo niewielki wpływ na wydajność, co sugeruje, że można osiągnąć znaczne oszczędności bez istotnego pogorszenia wyników.

W artykule napisano:

„W zebranych trajektoriach około 18% tokenów wyjściowych uznano za zmarnowane”.

„Co uderzające, w ponad 45% zadań zmarnowane tokeny wyjściowe jednego agenta przewyższają łączną liczbę tokenów wyjściowych innego agenta, który pomyślnie wykonał to samo zadanie”.

Ponadto badanie wykazało, że agenci marnowali najwięcej zasobów, gdy poruszali się po nieznanych narzędziach i stosowali podejścia, które ostatecznie nie prowadziły do celu. Ustalono też, że zwiększanie nakładu pracy na rozumowanie nie przynosi konsekwentnej poprawy: przy maksymalnym poziomie Kimi-K3 generował 6,6 razy więcej tokenów przeznaczonych na rozumowanie niż przy niskim poziomie, co nie gwarantowało lepszych wyników.

Wyniki testów pokazujące, jak Kimi-K3 radzi sobie przy czterech poziomach wysiłku wkładanego w rozumowanie w ramach pięciu testów porównawczych. Większy wysiłek wkładany w rozumowanie nie poprawiał konsekwentnie odsetka sukcesów, a maksymalny wysiłek czasami przynosił gorsze wyniki niż niższe ustawienia.

Analogia jest taka: zamiast prowadzić mocny samochód, którego możliwości nigdy nie wykorzystuje się w pełni, podczas tych sesji agent działa jak kierowca auta, które rozpędza się do maksymalnej prędkości, na jaką pozwalają jego możliwości, przy każdej podróży — nawet gdy nie przynosi to żadnych korzyści, a mimo to może mieć negatywne konsekwencje.

W artykule zbadano również, jak różne środowiska agentów przyczyniają się do marnowania tokenów. Ustalono, że ten sam model AI, Kimi-K3, mógł wygenerować ponad cztery razy więcej tekstu rozumowania przy identycznych zadaniach — zależnie od użytego środowiska — niekoniecznie osiągając lepsze wyniki.

Część strat wynikała z podstawowych usterek oprogramowania: ustalono, że OpenCode, Kimi Code CLI i OpenClaw wielokrotnie uruchamiały zadania w niewłaściwym środowisku Pythona, co powodowało błędy i kosztowne pod względem tokenów ponowne próby. Kimi Code CLI pozwalało też AI żądać limitów czasu, które samo oprogramowanie odrzucało, wymuszając kolejne kosztowne próby.

Wbrew intuicji środowiska oferujące więcej narzędzi niekoniecznie marnowały więcej zasobów, a niektóre powtarzające się nieefektywności zdawały się wynikać z samych modeli, niezależnie od tego, które środowisko nimi sterowało.

‘[Several]Pozornie oczywiste właściwości środowiska nie wyjaśniają w sposób konsekwentny zaobserwowanych różnic w marnowaniu zasobów. Na przykład, jak pokazano [below], środowiska udostępniające więcej narzędzi niekoniecznie marnują więcej zasobów. OpenClaw udostępnia znacznie więcej narzędzi niż pozostałe środowiska, a mimo to marnuje zasoby tylko w umiarkowanym stopniu. Co więcej, nie każde marnotrawstwo zależy od środowiska.

‘[Below right]pokazuje, że w teście SWE-bench Verified Kimi-K3 powtarzalnie zbacza z właściwej drogi: zapisuje rozwiązanie, które uważa za pierwotną poprawkę w projekcie, a później z niego rezygnuje. ‘

Wyniki testów porównujących liczbę zmarnowanych tokenów w różnych środowiskach agentów AI. Po lewej: oferowanie większej liczby narzędzi nie musi zwiększać strat. Po prawej: Kimi-K3 wielokrotnie podejmuje próbę wprowadzenia rzekomej pierwotnej poprawki w oprogramowaniu, a następnie z niej rezygnuje — niezależnie od środowiska — ale rzadko robi to przy innym typie zadania.

Jako sposób na ograniczenie strat autorzy proponują, by środowiska agentów rozpoznawały sytuacje, w których ograniczenia środowiska uniemożliwiają dalsze postępy, jasno informowały model AI o tych ograniczeniach i zatrzymywały działanie zamiast pozwalać, by kolejne nieudane próby zużywały więcej tokenów. Proponują również wykorzystanie pomiarów zmarnowanych tokenów do ulepszania trenowania modeli, strategii rozumowania i projektowania środowisk.

Metoda

Aby odtworzyć działania agenta AI, badacze śledzili każdą wymianę między modelem a sterującym nim oprogramowaniem, rejestrując tok rozumowania, odpowiedzi, żądania użycia narzędzi i koszty tokenów. Szczegółowość tych danych zależała od dostawcy: Kimi-K3 ujawnia cały proces rozumowania, Gemini 3.1 Pro — tylko jego podsumowania, a Claude nie ujawnia go wcale.

Wyniki działania każdego narzędzia przekazywano z powrotem agentowi, dzięki czemu badacze mogli śledzić cały proces aż do jego zakończenia lub osiągnięcia limitu działania.

Cztery przykłady sposobów, w jakie agenci AI zużywają tokeny. Powtarzanie znanych informacji, wykonywanie identycznych wyszukiwań i dodawanie zbędnych przeprosin zalicza się do strat, natomiast nieudane wyszukiwanie niekoniecznie oznacza marnotrawstwo — agent mógł mieć dobry powód, by je przeprowadzić.

Żądania agentów kierowano przez serwer proxy, aby śledzić ich aktywność; wymagało to jedynie niewielkich zmian w kodzie, a każde żądanie oznaczano informacją o teście porównawczym, uruchomieniu, zadaniu i próbie (z wyjątkiem OpenClaw, które nie obsługuje takich oznaczeń — w tym przypadku dla każdego testu używano osobnego serwera proxy opartego na LiteLLM).

Czterej gracze

W badaniu wyróżniono cztery powtarzające się wzorce marnowania tokenów: Powtarzanie (ponowne podawanie znanych informacji); Duplikowanie pobierania (ponawianie niepotrzebnych żądań użycia narzędzi); Wypełniacze (dodawanie nieistotnego tekstu); oraz Objazd (podejmowanie pozornie sensownych, lecz ostatecznie bezproduktywnych działań).

Każdą zarejestrowaną sesję oceniał model LLM-as-a-Judge (LLMaJ**), któremu przekazano pierwotne zadanie, pełny zapis sesji oraz kryteria pozwalające rozpoznać wszystkie cztery wzorce marnotrawstwa. Podejrzane fragmenty oznaczano i usuwano, a następnie ponownie liczono pozostałe tokeny, aby obliczyć odsetek zmarnowanych tokenów i związany z nimi koszt. Wyniki sprawdzono później za pomocą tokenizerów lub narzędzi zliczających poszczególnych dostawców oraz porównano z raportowanym przez nich zużyciem tokenów wyjściowych (odnotowano jedynie drobne różnice formatowania).

Testy

W badaniu przetestowano modele Kimi-K3, Gemini 3.1 Pro, GPT-5.6 Terra, GPT-6 Astra, Claude Sonnet 5 i Claude Fable 5.1 na testach porównawczych τ²-bench (obsługa klienta linii lotniczych i sklepów detalicznych), SWE-bench Verified (inżynieria oprogramowania), Claw-Eval oraz MCP-Atlas (korzystanie z narzędzi ogólnego przeznaczenia).

Dodatkowo Kimi-K3 przetestowano przy różnych poziomach wysiłku wnioskowania, a także porównano pięć środowisk agentów: OpenCode, OpenClaw, OpenHands, Hermes i Kimi Code CLI. Te ostatnie porównania posłużyły do oceny wpływu modeli, zadań, wysiłku wnioskowania i konstrukcji środowiska na marnotrawstwo tokenów (w kolejnych testach usuwano też podejrzane zbędne treści, by sprawdzić, jak wpływa to na wydajność).

Aby ustalić, ile pieniędzy marnował każdy model, porównano koszt niepotrzebnego tekstu i wywołań narzędzi z całkowitym kosztem generowania odpowiedzi, a następnie uśredniono wyniki z czterech testów porównawczych. Wewnętrzny proces wnioskowania oceniono osobno w przypadku Kimi-K3 — jedynego modelu, który ujawniał pełny przebieg swojego rozumowania:

Wyniki testów porównujące koszty zmarnowanych tokenów wyjściowych w sześciu modelach AI, uśrednione na podstawie czterech testów porównawczych. Po lewej: ogólny poziom marnotrawstwa, z osobno przedstawionym wewnętrznym procesem wnioskowania Kimi-K3. Po prawej: poziom marnotrawstwa w zadaniach zakończonych powodzeniem i niepowodzeniem; zadania nieudane na ogół wiązały się z większym marnotrawstwem.

Jak pokazano powyżej, za zmarnowane uznano od 11% do 24,9% kwoty wydanej na generowanie odpowiedzi i korzystanie z narzędzi. Najlepiej wypadł GPT-6 Astra, a najgorzej Claude Sonnet 5. W przypadku Kimi-K3 marnowała się mniej więcej co szósta tokenowa jednostka zużywana na odpowiedzi i korzystanie z narzędzi, a podczas wewnętrznego procesu wnioskowania — ponad co czwarta.

Ogólnie więcej marnotrawstwa odnotowano w zadaniach zakończonych niepowodzeniem, choć w przypadku procesu wnioskowania Kimi-K3 było odwrotnie. Nie znaleziono też wyraźnych dowodów na to, że zużywanie większej liczby tokenów na niepotrzebne działania zwiększało szanse na sukces.

W kolejnym teście podjęto próbę ograniczenia liczby zmarnowanych tokenów, gdy AI nadal pracowała: na każdym etapie sędzia AI** usuwał powtórzone informacje i bezcelowy tekst z procesu wnioskowania modelu, zanim pozwolono mu kontynuować zadanie:

Wyniki testów pokazujące, jak usuwanie niepotrzebnych treści z procesu wnioskowania AI wpływało na odsetek zadań zakończonych powodzeniem w dwóch testach porównawczych. Usunięcie 41–46% treści z procesu wnioskowania miało niewielki wpływ na skuteczność, natomiast usunięcie wszystkich tych treści prowadziło do znacznie większej liczby niepowodzeń.

W teście SWE-bench Verified usunięto 41% treści z procesu wnioskowania, nie obniżając skuteczności; odsetek zadań zakończonych powodzeniem nieznacznie wzrósł — z 89% do 89,5%. W teście MCP-Atlas usunięto 46% tych treści, a skuteczność spadła tylko nieznacznie — z 65% do 62,3%.

Innymi słowy, niemal połowę procesu wnioskowania można było odrzucić, gdy AI pracowała, nie osłabiając poważnie jej zdolności do wykonania zadania.

Na koniec^† Kimi-K3 przetestowano na identycznych zadaniach w różnych środowiskach agentów. Jak pokazano poniżej, ilość generowanych treści związanych z wnioskowaniem różniła się ponad czterokrotnie, ale nie wiązało się to z żadną konsekwentną poprawą skuteczności:

Wyniki testów porównujące zużycie tokenów przez Kimi-K3 w różnych środowiskach agentów na dwóch testach porównawczych. Wewnętrzny proces wnioskowania oznaczono na niebiesko, a odpowiedzi i wywołania narzędzi — na pomarańczowo. W zadaniach programistycznych środowisko Mini-SWE wygenerowało ponad czterokrotnie więcej treści związanych z wnioskowaniem niż Hermes.

Część marnotrawstwa wynikała z podstawowych błędów oprogramowania. OpenCode, Kimi Code CLI i OpenClaw uruchamiały testy programistyczne w niewłaściwym środowisku Pythona, co powodowało błędy i ponowne próby.

Wnioski

To tylko krótkie omówienie artykułu, którego obszerność i skrupulatna metodologia mogą zachęcić do uważniejszej lektury.

Temat przywiódł mi na myśl coś, co często sobie uświadamiam: ogromną przepaść między tym, co my i czołowi dostawcy faktycznie wiemy o tych procesach, a gotowością firm do pakowania produktu tak, jakby przez ostatnie trzy miesiące przechodził kontrolę w narzędziu do statycznej analizy kodu i zdał ją celująco.

W obecnej sytuacji, przynajmniej na razie, za złe rezultaty możemy obwiniać wyłącznie siebie, ponieważ kupujemy produkt, o którym niemal wszyscy wiemy, że jest wysoce eksperymentalny i nieprzewidywalny.

* Przy wyraźnie zadeklarowanym równym wkładzie University of Illinois Urbana-Champaign, Northeastern University, University of California (Los Angeles) oraz niezależnego badacza.

* O ile mogę stwierdzić, w artykule nie wskazano, którego modelu użyto.

^† Na potrzeby tego artykułu, a nie pracy, która jest dłuższa, niż zwykle jestem w stanie omówić, i zawiera więcej testów oraz szczegółów, niż możemy uwzględnić tutaj. Więcej informacji można znaleźć w podlinkowanym powyżej źródłowym pliku PDF.

Opublikowano po raz pierwszy w piątek, 6 listopada 2026 r.