Od kilku tygodni obserwuję, że Paperclip potrafi zużyć mój tygodniowy limit tokenów w jeden dzień. Problemem nie jest samo duże zużycie. Gdyby prowadziło do proporcjonalnych, widocznych zmian w aplikacjach, można byłoby uznać je za koszt wykonanej pracy. Tymczasem znaczna część aktywności krążyła wokół samorozwoju systemu i tworzenia dokumentacji, podczas gdy projekty, których ta praca miała dotyczyć, zmieniały się znacznie wolniej.

Ustawiłem więc zatrzymanie Paperclipa przy 75% limitu. Pozostała część ma chronić inne zastosowania Codexa, ponieważ Paperclip nie jest jedynym obszarem mojej pracy. To prosty bezpiecznik, ale ujawnia ważniejszy problem: tokeny nie są abstrakcyjną liczbą widoczną gdzieś w panelu. Są wspólnym budżetem operacyjnym, o który konkurują zadania, projekty i agenci.

Wolę mówić o inteligencji obliczeniowej niż o inteligencji sztucznej. Nie jest to wyłącznie preferencja stylistyczna. Dobra definicja powinna możliwie wiernie opisywać rzeczywistość. Słowo „sztuczna” może sugerować coś nierzeczywistego, pozornego albo gorszego od inteligencji człowieka. „Obliczeniowa” wskazuje natomiast na mechanizm: algorytmy, matematykę i wykonywanie obliczeń. Nie wymaga przy tym założenia, że ludzka inteligencja jest jedyną prawdziwą albo najwyższą formą rozwiązywania problemów.

Dobrym przykładem ograniczeń takiego antropocentrycznego spojrzenia jest Physarum polycephalum. W eksperymencie punkty pokarmu rozmieszczono w miejscach odpowiadających 20 dużym obszarom miejskim USA. Jednokomórkowy śluzowiec połączył je siecią, która w uproszczonym grafie odtworzyła 36 z 41 połączeń amerykańskiego systemu autostrad międzystanowych (Adamatzky i Ilachinski, 2012). Nie oznacza to, że śluzowiec posiada ludzką osobowość ani że zaprojektował idealne autostrady. Pokazuje jednak, że użyteczne obliczenie i optymalizacja sieci nie są wyłączną własnością ludzkiego umysłu.

W tej perspektywie ograniczenie tokenów przypomina ograniczenie czasu człowieka, przepustowości zespołu albo dostępnej mocy obliczeniowej. Nie mówi jeszcze, ile wartości powstanie. Określa natomiast, ile pracy system może spróbować wykonać, zanim utraci zdolność do realizowania kolejnych zadań.

Zużycie zasobu nie jest dowodem rezultatu

Nie istnieje jedna poprawna liczba tokenów przypisana do każdego zadania. Napisanie krótkiego wiersza i przygotowanie arkusza zestawiającego koszty z przychodami wymagają innego nakładu. Dlatego nie da się uczciwie ocenić systemu samym stosunkiem tokenów do liczby wygenerowanych plików, odpowiedzi albo zadań.

Punktem wyjścia musi być problem. Agent powinien otrzymać cel, kontekst i opis rezultatu, który po wykonaniu będzie użyteczny dla człowieka albo następnego agenta. Dopiero wtedy można pytać, czy koszt był uzasadniony. Artefakt nie staje się wartością tylko dlatego, że wymagał długiego rozumowania. Dokumentacja jest potrzebna, jeśli odblokowuje pracę. Jeśli zastępuje zmianę, którą miała umożliwić, zużywa budżet bez zamknięcia zadania.

Paperclip pozostawia dziś dwie możliwe diagnozy. Być może dostępna pula jest zbyt mała dla skali powierzonych projektów. Być może problemem jest organizacja pracy: zbyt szerokie zadania, źle przydzielony kontekst, powtarzanie działań albo kryteria akceptacji premiujące łatwo widoczną dokumentację. Możliwe również, że oba ograniczenia działają jednocześnie. Sam fakt wyczerpania limitu nie pozwala ich rozdzielić.

Większy pakiet nie naprawi źle określonego problemu. Pozwoli jedynie dłużej wykonywać pracę w ten sam sposób. Z drugiej strony zbyt mały budżet może przerwać poprawnie zaplanowaną sekwencję, zanim jej części zostaną połączone w rezultat. Dlatego limit trzeba analizować razem z konstrukcją zadania, a nie jako osobną przeszkodę techniczną.

Najmniejszy wystarczający kontekst

Drugim ograniczonym zasobem jest kontekst. Agent potrzebuje informacji, aby zrozumieć problem, zależności i warunki odbioru. Gdy dostanie ich za mało, musi zgadywać albo zatrzyma się na lokalnej poprawce nieuwzględniającej reszty systemu. Gdy dostanie wszystko, co kiedykolwiek zapisano o projekcie, informacje potrzebne w danym kroku mogą zniknąć w szumie.

Moja robocza zasada brzmi paradoksalnie: agent powinien dostać maksymalną ilość potrzebnych danych, która jest jednocześnie ich minimalną wystarczającą ilością. Nie chodzi o oszczędzanie każdego tokena. Chodzi o adekwatność. Kontekst ma zawierać wszystko, bez czego konkretny krok nie może zostać wykonany poprawnie, i nie zawierać treści, które nie pomagają podjąć bieżącej decyzji ani działania.

Badanie „Lost in the Middle” pokazało, że w zadaniach wykorzystujących długi kontekst skuteczność modeli zależała od położenia istotnej informacji i często spadała, gdy znajdowała się ona pośrodku wejścia (Liu i in., 2024). To nie dowodzi, że każdy długi prompt jest zły. Pokazuje jednak, że przyjęcie informacji przez model nie jest tym samym co jej równie skuteczne wykorzystanie.

Podobną różnicę ujawnił benchmark RULER. Autorzy przetestowali 17 modeli reklamowanych jako obsługujące co najmniej 32 tysiące tokenów; prawie wszystkie traciły skuteczność wraz ze wzrostem długości i złożoności, a połowa utrzymała przyjęty poziom wyniku przy 32 tysiącach tokenów (Hsieh i in., 2024). Deklarowane okno jest więc technicznym sufitem wejścia, a nie gwarancją użytecznego rozumowania na całej jego długości.

To koryguje intuicję, że dostępne okno warto domyślnie wypełniać. Wypełnienie go danymi ma sens tylko wtedy, gdy dane są potrzebne do zadania i zostały ułożone tak, aby agent mógł odnaleźć zależności. Pusta przestrzeń w kontekście nie jest straconą mocą. Czasem jest ochroną przed informacją, która konkuruje o uwagę z właściwym problemem.

Zadanie musi mieścić się w przepustowości wykonawcy

Jeżeli poprawne wykonanie zadania wymaga większego kontekstu, system ma dwie rozsądne możliwości. Może dołożyć konkretną brakującą informację albo podzielić problem na mniejsze, zależne kroki. Podział nie polega na produkowaniu dowolnie małych zadań. Każdy krok potrzebuje wejścia, oczekiwanego wyniku i kryterium odbioru, a jego rezultat musi nadawać się do użycia w następnym kroku.

Przegląd badań nad planowaniem agentów LLM wymienia dekompozycję zadań jako jeden z głównych mechanizmów planowania obok wyboru planu, pamięci, refleksji i zewnętrznych modułów. Jednocześnie wskazuje otwarte problemy związane z planowaniem i wykonaniem (Huang i in., 2024). Sam podział nie gwarantuje sukcesu. Może wytworzyć części poprawne lokalnie, które po połączeniu nie rozwiązują pierwotnego problemu.

W planowaniu własnej pracy stosuję prostą heurystykę: rzeczy zajmujących mniej niż około pięciu minut nie planuję, tylko wykonuję; zadania przekraczające około 25 minut staram się dzielić, aby utrzymać skupienie. Nie jest to przelicznik czasu człowieka na tokeny agenta. Analogia dotyczy granulacji. Zadanie musi być wystarczająco duże, aby jego rezultat miał znaczenie, ale wystarczająco małe, aby wykonawca był w stanie objąć potrzebne zależności.

W systemie agentowym krok powinien kończyć się kontrolowanym wynikiem pośrednim. Jeżeli agent przeanalizował wymagania, wynikiem nie może być tylko informacja, że analiza się odbyła. Powinien przekazać uporządkowane wymagania użyteczne dla planisty. Jeżeli programista zmienił funkcję, wynik powinien obejmować kod oraz dowód, że właściwe przepływy nadal działają. Dzięki temu następny agent nie musi odtwarzać całego wcześniejszego kontekstu i ponownie płacić za tę samą pracę.

Budżet powinien chronić dostarczenie wartości

Próg 75% jest obecnie ręcznym ograniczeniem, nie uniwersalną receptą. W innym systemie właściwa rezerwa może być większa albo mniejsza. Istotna jest funkcja tej granicy: żaden autonomiczny proces nie powinien bez kontroli przejąć całego wspólnego zasobu i zablokować pracy o wyższym priorytecie.

Przed uruchomieniem większej sekwencji warto więc znać dostępny budżet, minimalny rezultat i warunek zatrzymania. Po każdym większym kroku system powinien umieć odpowiedzieć, co zmieniło się w rzeczywistości, jaki wynik przekazuje dalej i czy kontynuowanie nadal ma większą wartość niż zachowanie zasobu dla innego zadania. Gdy zbliża się do limitu, powinien najpierw zabezpieczyć stan i dowody, a dopiero potem ograniczyć zakres albo zatrzymać pracę.

Nie chodzi o to, aby każdy agent zużywał jak najmniej tokenów. Taka optymalizacja mogłaby premiować płytkie odpowiedzi i pomijanie zależności. Celem jest adekwatne zużycie: tyle rozumowania i kontekstu, ile wymaga poprawne dostarczenie uzgodnionego rezultatu, bez finansowania niekończącej się aktywności, która nie przybliża systemu do zakończenia.

Limit pakietu może być realnie zbyt mały. Zanim jednak uznam go za jedyną przyczynę, chcę zobaczyć, że system potrafi chronić budżet, dobierać kontekst do kroku, dzielić pracę bez gubienia całości i odróżniać rezultat od śladu aktywności. Dopiero wtedy większa pula tokenów stanie się większą przepustowością. Bez tych mechanizmów może być jedynie większym zbiornikiem, który Paperclip opróżni w ten sam sposób.

Bibliografia

✦Buduję systemy dla większej autonomii.