Agent-Controlled Forgetting: agenty AI uczą się zapominać

Nowe badanie opublikowane na arXiv proponuje mechanizm „zapominania kontrolowanego przez agenta” – metodę, która pozwala agentom AI korzystającym z narzędzi samodzielnie decydować, które fragmenty historii rozmowy można tymczasowo usunąć z kontekstu, zachowując jednocześnie możliwość ich pełnego przywrócenia. Autor pracy, Jan-Peter Franke, opisuje podejście jako odpowiedź na problem, który dotyka praktycznie każdego agenta wykorzystującego narzędzia programistyczne: wyniki zwracane przez narzędzia (logi, dane debugowania, odpowiedzi API) często zawierają znacznie więcej treści, niż jest faktycznie potrzebne do dalszej pracy modelu.

Kluczowe wnioski

• Agent sam wybiera wcześniej zaobserwowane wyniki narzędzi i zastępuje je krótką notatką w tym samym miejscu, a oryginalną treść zachowuje w odzyskiwalnym archiwum.
• W testowym scenariuszu debugowania OpenTelemetry metoda zakończyła pracę z 231 951 tokenami promptu (według danych dostawcy) wobec 912 492 tokenów przy zachowaniu pełnej historii – to 50% mniej skumulowanych tokenów wejściowych.
• Szacowany koszt zapytań API spadł z około 4,38 dolara do 1,28–1,44 dolara w tym samym scenariuszu.
• Metoda z zapominaniem wymagała jednak więcej zapytań i trwała o 17% dłużej niż wariant z pełną historią.
• W innym, kontrastowym przypadku rozwoju aplikacji metoda nie przyniosła żadnych oszczędności kontekstu ani kosztów, a wcześniejsza kontynuacja zadania wykazała niższą jakość ocenianą manualnie, mimo zredukowanego kontekstu.

Jak działa mechanizm odwracalnego zapominania

Istota proponowanego podejścia polega na tym, że model wykonujący zadanie (acting model) ma kontrolę nad tym, co pozostaje w jego aktywnym kontekście. Gdy agent uzna, że dany wynik narzędzia – na przykład długi log diagnostyczny czy obszerna odpowiedź API – nie jest już potrzebny w pełnej formie, może go zastąpić krótką notatką umieszczoną w tym samym miejscu w historii rozmowy. Oryginalna, pełna treść nie jest jednak trwale usuwana – trafia do archiwum, z którego może zostać odzyskana w razie potrzeby.

Rozwiązanie zaimplementowano jako harness w Pythonie, który udostępnia operacje wsadowej archiwizacji oraz wyraźnego, jawnego odzyskiwania danych. Co istotne, mechanizm nie wymaga dedykowanego treningu modelu na potrzeby konkretnego zadania – działa na bazie istniejących modeli. Autor podkreśla też, że system chroni instrukcje użytkownika i wiadomości asystenta przed operacjami archiwizacji – te elementy pozostają zawsze w pełnej, niezmienionej formie, co ma zapobiegać utracie kluczowego kontekstu zadania.

Podejście to nawiązuje do szerszego trendu prac nad architekturami agentowymi radzącymi sobie z narastającym kontekstem w długotrwałych zadaniach, gdzie ograniczenia okna kontekstowego i koszty tokenów stają się praktyczną barierą dla zastosowań w firmach.

Wyniki eksperymentów: duże oszczędności, ale nie zawsze

Badanie opiera się na kilku studiach przypadków. Pierwszy, kluczowy test to eksploracyjne zadanie debugowania systemu OpenTelemetry, po którym nastąpiło niezwiązane z nim zadanie implementacyjne. W tym scenariuszu różnica w zużyciu tokenów między metodą z zapominaniem a zachowaniem pełnej historii była dramatyczna: 231 951 tokenów promptu zgłoszonych przez dostawcę usługi wobec 912 492 tokenów – czyli redukcja o połowę skumulowanych tokenów wejściowych. Przełożyło się to na realne oszczędności finansowe: szacowany koszt API spadł z około 4,38 dolara do przedziału 1,28–1,44 dolara.

Oba warianty – z zapominaniem i z pełną historią – przeszły dwuprzypadkowy, podstawowy test behawioralny (primary behavioral oracle), który służył jako główne kryterium oceny poprawności działania agenta. Jednak żaden z wariantów nie spełnił w pełni dodatkowej, pogłębionej ewaluacji uzupełniającej (follow-up evaluation). Co ciekawe, metoda z zapominaniem, choć tańsza i mniej obciążająca kontekst, wykonała więcej zapytań do modelu i zajęła o 17% więcej czasu niż podejście tradycyjne.

Drugi, kontrastowy przypadek dotyczył rozwoju aplikacji (application-development) i dał zupełnie inny obraz – metoda nie przyniosła tu żadnych oszczędności kontekstu czy kosztów. Ponadto wcześniejsza kontynuacja tego zadania wykazała niższą jakość wyników, oceniana manualnie, pomimo zredukowanego rozmiaru kontekstu. Te rozbieżne wyniki prowadzą autora do wniosku, że efektywność metody silnie zależy od charakteru obciążenia (workload dependence) – w zadaniach generujących dużo „szumu” w postaci rozbudowanych, rzadko potrzebnych w całości wyników narzędzi (jak debugowanie systemów telemetrycznych), zapominanie przynosi wymierne korzyści. W zadaniach o innej strukturze, jak tworzenie aplikacji, korzyści mogą nie wystąpić wcale.

Znaczenie dla rozwoju agentów AI

Praca Franke'a wpisuje się w rosnącą liczbę badań nad zarządzaniem kontekstem w długotrwałych zadaniach agentowych, gdzie koszty tokenów i ograniczenia okna kontekstowego stają się praktyczną przeszkodą w skalowaniu rozwiązań opartych na dużych modelach językowych. Zaletą zaprezentowanego podejścia jest to, że nie wymaga specjalistycznego treningu – można je zastosować do istniejących modeli jako warstwę pośredniczącą zarządzającą kontekstem.

Jednocześnie wyniki jasno pokazują, że nie jest to rozwiązanie uniwersalne. Zwiększona liczba zapytań i wydłużony czas wykonania w jednym ze scenariuszy, a także brak korzyści lub nawet spadek jakości w innym przypadku, wskazują, że decyzja o wdrożeniu takiego mechanizmu powinna uwzględniać specyfikę konkretnego obciążenia roboczego. Autor sam określa zależność od charakteru zadania (workload dependence) jako kluczowe zagadnienie do dalszych badań nad odwracalnym zarządzaniem kontekstem w agentach AI.

Badanie to stanowi istotny głos w dyskusji o tym, jak projektować agentów AI zdolnych do efektywnego, długotrwałego działania bez nadmiernego obciążania kosztownego okna kontekstowego – problem, który nabiera na znaczeniu wraz z rozwojem agentów AI stosowanych w firmach do coraz bardziej złożonych, wieloetapowych zadań.

---

Praca pokazuje, że kontrolowane przez agenta, odwracalne zapominanie może przynieść znaczące oszczędności kosztów i tokenów w zadaniach generujących dużo zaszumionych danych z narzędzi, ale jego skuteczność silnie zależy od charakteru konkretnego zadania.