Pamięć agenta AI nie jest bazą danych: co należy przechowywać, odzyskiwać i zapominać.
Dlaczego pamięć agenta stanowi problem istotności: w jaki sposób kontekst, pamięć, stan i RAG się różnią, co należy przechowywać, jak określić zakres, sprawdzić jej aktualność i przeprowadzić audyt, oraz dlaczego zapominanie jest zaletą.
Pamięć agentów AI jest zwykle przedstawiana jako funkcja, która sprawia, że stają się inteligentniejsze: pamiętają poprzednie rozmowy, preferencje użytkowników, wcześniejsze kroki w procesie pracy, to, co zadziałało ostatnio, fakty z dokumentów. Marzeniem jest agent, który wie wszystko, co kiedykolwiek widział. Wtedy właśnie zaczyna się zamieszanie, ponieważ agent nie musi pamiętać wszystkiego, a pamięć to nie to samo co przechowywanie danych.
Baza danych może przechowywać miliony rekordów, z których żaden nie musi znajdować się w pamięci agenta. Inne są pytania inżynieryjne: co powinno być zapamiętane i na jak długo? Gdzie to się znajduje, kiedy jest pobierane, kiedy jest usuwane? I czy to w ogóle jest pamięć? Patrząc w ten sposób, pamięć to raczej problem istotności niż problem przechowywania.
Dlaczego zasada „przechowywania wszystkiego” nie działa
Zastanów się nad agentem wykonywającym zadanie długoterminowe. Na pierwszym etapie dowiaduje się on o celu użytkownika, wybranym dokumencie, kilku wyekstrahowanych wartościach, wyniku użycia narzędzia, tymczasowej decyzji oraz rezultacie weryfikacji. Następnie przychodzi kolejny etap, a potem jeszcze jeden, i ilość danych stale rośnie.
Najprostszą implementacją jest przechowywanie wszystkiego: dodawanie każdej wiadomości, zapisywanie każdego wyniku narzędzia oraz przesyłanie wszystkiego przy następnym wezwaniu. To działa przez jakiś czas. Potem kontekst się rozrasta, odpowiedzi zwalniają, koszty rosną, przestarzałe informacje zaczynają wpływać na nowe decyzje, a dane, które już nie mają znaczenia, wciąż pozostają w instrukcji. W praktyce od modelu wymaga się, aby określił, które z pięćdziesięciu elementów jest teraz ważne. W tym momencie pamięć zamienia się w szum.
Cztery terminy, które są mylone
Te koncepcje rozwiązują różne problemy, a projektowanie agentów ulepsza się po ich rozdzieleniu.
Kontekst to informacje, które model musi znać w danym momencie: aktualna prośba, wybrane dowody, kilka wcześniejszych decyzji oraz wyniki użytych narzędzi. Jest on tymczasowy i służy bieżącemu kroku rozumowania.
Pamięć to dane, których system może potrzebować później, takie jak preferencje użytkownika, decyzja potwierdzona przez kogoś innego, przydatny podsumowanie lub wynik wcześniejszego zadania. Mogą one przetrwać dłużej niż pojedyncze wezwanie modelu.
Stan wskazuje, na jakim etapie znajduje się proces. Może to być status taki jak QUEUED, RUNNING, WAITING_FOR_TOOL, RETRYING lub COMPLETED, albo bardziej szczegółowe flagi, np. document_extracted = true, analysis_completed = true i report_generated = false. Stan umożliwia systemowi kontynuację pracy. Nie jest to wiedza.
RAG oznacza pobieranie wiedzy z zewnętrznych źródeł w momencie potrzeby: dokumentów, baz danych, polityk, raportów, wewnętrznych wiki, magazynów wektorowych. Te informacje już istnieją gdzie indziej. Agent nie musi ich trzymać na stałe, wystarczy je znaleźć w razie potrzeby, co to zupełnie inny problem.
Pamięć krótkoterminowa
Pamięć krótkoterminowa to zbiór informacji niezbędny do pracy. Ludzie rozwiązujący problem przechowują w głowie określone fakty i usuwają większość z nich po zakończeniu, a agenci mają taką samą potrzebę. Podczas jednego procesu pracy agent może korzystać z bieżącej prośby, wybranego dokumentu, ostatnich wyników narzędzi, obliczeń pośrednich, wcześniejszych decyzji oraz postępów w zadaniu. Wszystko to ma znaczenie teraz, ale jutro może stać się praktycznie bezwartościowe. Dobrą definicją jest najmniejszy zbiór informacji potrzebny do kontynuowania bieżącego zadania, a nie wszystko to, co wydarzyło się od jego rozpoczęcia.
Pamięć długoterminowa musi zasłużyć na swoje miejsce
Pamięć długoterminowa to to, co celowo przechowujemy, ponieważ może znów się przydać. Przykładami są określone preferencje, takie jak „wolę zwięzłe raporty”, potwierdzone decyzje biznesowe, np. „będę używać tego formatu raportowania do przyszłych analiz”, lub ustalone fakty, jak „w tym projekcie System A jest uważany za źródło prawdy”.
Standard powinien być tu wyższy. Zanim cokolwiek przechowamy, zastanówmy się, czy może to poprawić przyszłą decyzję. Jeśli nie, lepiej tego pominąć, ponieważ przechowywanie w pamięci długoterminowej wiąże się z dodatkowymi kosztami: każdy element to coś, co system może później odzyskać, w co zaufać, utrzymywać lub błędnie interpretować.
RAG to nie jest pamięć długoterminowa
Załóżmy, że w indeksie wektorowym znajduje się 20 000 dokumentów wewnętrznych, a agent może je przeszukiwać. To nie jest pamięć agenta. Dokumenty stanowią wiedzę, a RAG to sposób na jej odzyskiwanie. Agent nie powinien przechowywać wszystkich dokumentów w swojej pamięci, lecz jedynie umieć znaleźć ten właściwy. Prawidłowy przepływ jest taki: agent potrzebuje informacji, wyszukuje źródło wiedzy, odzyskuje istotne dowody i je wykorzystuje. Niewłaściwy przepływ polega na kopiowaniu całej wiedzy do pamięci. Wiedza może być ogromna, podczas gdy pamięć robocza musi pozostać mała.
Stan często jest ważniejszy niż pamięć
Znaczna część tego, co nazywa się pamięcią agenta, to w rzeczywistości stan przepływu pracy. Załóżmy, że agent zakończył wyodrębnianie dokumentu, pobieranie dowodów i ich analizę, a raport nadal nie został stworzony. Jeśli procesor zatrzyma się przed ukończeniem raportu, system musi wiedzieć, gdzie kontynuować. To właśnie jest stan. Model nie powinien musieć przypominać sobie, że krok analizy został zakończony, ponieważ aplikacja o tym wie.
Stan zadań, liczba prób ponownych, punkty kontrolne, identyfikatory zadań, zakończone kroki oraz czekające na wykonanie działania należą zazwyczaj do deterministycznego stanu aplikacji, a nie do rozmowy z modelem językowym. Dobrą zasadą jest: jeśli oprogramowanie może coś dokładnie wiedzieć, niech to dokładnie przechowuje. Model nie powinien być odpowiedzialny za pamiętanie faktów związanych z przepływem pracy.
Nie wszystko, co się wydarzyło, zasługuje na miejsce w pamięci
Załóżmy, że narzędzie zwraca payload w formacie JSON składający się z 500 linii. Czy następny krok wymaga wszystkich tych 500 linii? Prawdopodobnie wystarczy jedno lub dwa pola, takie jak account_status = ACTIVE, total_balance = 120000 lub document_found = true. Surowy wynik może zostać zachowany w dziennikach lub bazie danych, a pamięć może przechowywać tylko te elementy, które są istotne.
Rozmowy funkcjonują w ten sam sposób. Jeśli użytkownik i agent poświęcili dziesięć wiadomości na ustalenie konkretnych wymagań, zwięzła notatka w stylu „użytkownik chce raport uporządkowany według kategorii i stopnia ważności” przyniesie większą korzyść niż ponawianie całej wymiany wiadomości za każdym razem.
Co warto zapamiętać
Żadna jedna odpowiedź nie pasuje do każdego systemu, ale kilka kategorii zazwyczaj stanowi dobry wybór:
- Stabilne preferencje: format wyjścia, język, styl raportowania.
Czego unikać przechowywania
- Każdą odpowiedź modelu. Większość pośrednich rozumowań nie jest przydatna później.
- Każdy wynik narzędzia, który może być duży, przestarzały lub specyficzny dla jednego momentu.
- Tymczasowe błędy. Wczorajszy timeout nie powinien stać się jutrzejszym kontekstem.
- Nieweryfikowane założenia modelu – to największe zagrożenie. Jeśli model stwierdza, że dokument „wydaje się odnosić do firmy A”, a nikt tego nie potwierdza, przechowywanie go może przekształcić słabą domysłowość w trwały fakt, na którym później będą opierane dalsze działania.
- Dane wrażliwe, bez wyraźnego powodu ich przechowywania. Pamięć powinna mieć określony cel.
Pamięć może się mylić
To jeden z największych problemów związanych z pamięcią długoterminową. System przechowuje informację, że walutą raportowania klienta jest USD, a sześć miesięcy później preferencje się zmieniają, mimo że stara informacja nadal istnieje. Która wersja zwycięża? Pamięć potrzebuje kryterium aktualności. Niektóre fakty są ważne przez lata, inne tylko przez kilka minut, a dobry system potrafi je odróżnić.
Życiowy cykl, a nie przechowywanie i zapomnienie
Pamięć nie powinna funkcjonować według schematu przechowywania i trzymania danych na zawsze. Realistyczniejszy cykl obejmuje kroki takie jak pobieranie, weryfikacja, przechowywanie, odzyskiwanie, wykorzystanie, a następnie aktualizację, wygaśnięcie lub usunięcie. Aby to umożliwić, każda pozycja może wymagać informacji o czasie utworzenia, źródle pochodzenia, flagi potwierdzenia lub niepotwierdzenia, czasie ostatniego użycia, reguły wygaśnięcia oraz linku do nowszej wartości, która ją zastąpiła. Zapisywanie to tylko połowa pracy – druga połowa to konserwacja.
Znaczenie źródła
Załóżmy, że istnieją dwa zapisy pamięci. Jeden mówi, że preferowanym formatem jest PDF, a użytkownik potwierdził to wyraźnie wczoraj. Drugi stwierdza, że preferowanym formatem może być Excel, co model językowy wywnioskował sześć miesięcy temu. Nie powinny one mieć jednakowej wagi, dlatego idealnie byłoby, gdyby pamięć rejestrowała źródło informacji: czy pochodzi od użytkownika, została wygenerowana przez system, wywnioskowana przez model, pobraana z dokumentu, zwrócona przez narzędzie czy skopiowana z innego miejsca? Ten kontekst informuje system, w jakim stopniu może mu ufać.
Pewność siebie też ma znaczenie
"Umowa wydaje się wygasać w czerwcu" to inny rodzaj stwierdzenia niż "Data wygaśnięcia umowy: 30 czerwca 2027 r.", pochodzące z ustrukturyzowanego pola. Jedno można traktować jako bardzo wiarygodne, a drugie wymagające weryfikacji, dzięki czemu niejasne wnioski nie przekształcają się cicho w fakty. Przydatny długoterminowy zapis często zawiera coś więcej niż samą wartość – może on również obejmować source, confidence, timestamp, scope oraz status, co znacznie ułatwia późniejsze wyszukiwanie informacji.
Streszczenia to interpretacje
Streszczenia należą do najlepszych sposobów na utrzymanie małej pamięci roboczej. Zapisz „użytkownik chce zwięzłego wyjaśnienia technicznego z przykładami” zamiast całej rozmowy, lub „trzy ustalenia potwierdzone, jedno nierozwiązane” zamiast każdego kroku analizy. Problem polega na tym, że streszczenie jest interpretacją i może pominąć ważny detal. W przypadku ważnych procesów pracy łącz streszczenie z odniesieniem do oryginalnych dowodów. Streszczenie zapewnia efektywność agenta, a oryginał jest dostępny w razie konieczności weryfikacji.
Nie twórz drugiego źródła prawdy
Jeśli dane klienta znajdują się już w głównej bazie danych klientów, kopiowanie ich do długoterminowej pamięci agenta jest zazwyczaj błędem. Wkrótce obie kopie się różnią, a nikt nie wie, która jest poprawna. Lepiej traktować autorytatywny system jako źródło informacji, z którego można je pobrać w razie potrzeby, i wprowadzać uzyskany wynik do kontekstu agenta. Nie twórz duplikatów systemu rejestrowania danych bez bardzo wyraźnego powodu. Kryterium oceny jest to, czy informacje można niezawodnie pobrać z ich źródła zamiast je zapamiętywać. Jeśli tak, pobieranie może być skuteczniejsze niż przechowywanie w pamięci.
Zakres
Gdy kilku użytkowników, organizacji lub procesów pracy dzieli się jedną infrastrukturą agenta, konieczne są ograniczenia dotyczące zapotrzebowania na pamięć. Pamięć jednego użytkownika nie powinna pojawiać się w kontekście innego, jedna organizacja nie powinna pobierać danych innej, a jeden proces pracy może nie potrzebować pośrednich wyników innego. Pamięć wymaga zazwyczaj wyraźnego zakresu, takiego jak globalny, organizacyjny, użytkownika, rozmowy, procesu pracy lub zadania. Im węższy zakres, tym mniejsze ryzyko, że nieistotne informacje trafią do decyzji niewiążącej się z danym tematem.
Pobieranie pamięci to problem wyszukiwania
Z 500 przechowywanymi wspomnieniami nikt nie powinien umieszczać ich wszystkich w każdym zapytaniu. Wracamy do problemu kontekstu, więc odzyskiwanie pamięci wymaga własnego procesu: należy przyjrzeć się bieżącemu zadaniu, określić, jaki rodzaj pamięci jest istotny, przefiltrować według użytkownika, procesu pracy i struktury organizacyjnej, przeprowadzić wyszukiwanie, sklasyfikować wyniki, wybrać najważniejsze i dodać je do kontekstu roboczego. Dlatego inżynieria pamięci i kontekstu są tak ściśle powiązane – pamięć decyduje o tym, co może być dostępne później, natomiast inżynieria kontekstu określa to, co jest używane teraz.
Pisz mniej, odzyskuj lepiej
Zamiast pytać, co jeszcze można przechować, należy zastanowić się, jakie informacje mają wystarczającą wartość w przyszłości, by uzasadnić ich przechowywanie. Zamiast pytać, ile pamięci mieści się w zapytaniu, należy sprawdzić, która pamięć jest istotna dla danej decyzji. Dobra architektura pamięci powinna zazwyczaj sprawić, że agent widzi mniej informacji, ponieważ nieistotna pamięć to po prostu nieistotny kontekst.
Obserwowalność
Załóżmy, że agent udziela dziwnej odpowiedzi. Pobrany dokument wygląda poprawnie, a wezwanie narzędzia zakończyło się sukcesem, mimo to odpowiedź jest błędna, a w końcu ktoś odkrywa, że decyzję wpłynęła stara pamięć. Bez możliwości obserwacji procesu pobierania pamięci bardzo trudno jest to naprawić. Przy każdym uruchomieniu pomocne jest rejestrowanie, które pamięci zostały pobrane i dlaczego, jaka jest ich pochodzenie i wiek, potwierdzony stan, czy trafiły do ostatecznego kontekstu oraz czy wpłynęły na wynik. Dzięki temu pamięć przestaje być zachowaniem ukrytym i staje się czymś, co można sprawdzić.
Bardziej realistyczna architektura
Zamiast tego, by wszystko trafiało najpierw do pamięci, a potem do agenta, wyobraźmy sobie coś takiego: przychodzi użytkownik lub zadanie, sprawdza się stan procesu pracy, a system decyduje, jakie informacje są potrzebne. Następnie czerpie je z różnych źródeł:
- Kontekst roboczy dotyczący tego, co jest potrzebne w danej chwili, takie jak aktualna prośba, najnowszy wynik narzędzia i obecna decyzja.
- Pamięć krótkoterminowa na to, co jest potrzebne w ramach tego procesu pracy, np. podsumowanie zadania, tymczasowe ustalenia i ostatnie decyzje.
- Pamięć długoterminowa na to, co może być przydatne w przyszłych procesach pracy, np. ustalone preferencje, potwierdzone fakty lub historyczne wyniki.
- Wiedza i RAG do uzyskiwania informacji znajdujących się gdzie indziej, takich jak dokumenty, polityki, raporty i bazy danych.
- Stan aplikacji dla określania prawdy w sposób deterministyczny, np. status, punkty kontrolne, liczba prób ponownych i zakończone kroki.
Następnie należy przefiltrować, uporządkować i połączyć aktualny kontekst, aby agent mógł rozumować. Określanie tego wszystkiego po prostu jako pamięci ukrywa jego strukturę.
Pytania do zadania przed dodaniem funkcji pamięci
- Czy to pomoże w przyszłym zadaniu? Jeśli nie, nie przechowuj tego.
Odpowiedzi na te pytania zazwyczaj są ważniejsze niż wybór bazy danych pamięci.
Zapominanie to funkcja
Dobra pamięć nie oznacza zapamiętywania wszystkiego. Praktyczny agent powinien zapominać wiele rzeczy: tymczasowe szczegóły, stare wyniki działań narzędzi, niepotwierdzone założenia, przestarzałe fakty oraz rozumowanie, które już nie ma znaczenia. Większa ilość pamięci automatycznie nie czyni systemu mądrzejszym – czasami jedynie daje modelowi więcej szans na łączenie niewłaściwych informacji. W praktyce oznacza to: przechowywać tylko to, co przyniesie korzyści później, przechowywać stan procesów w prostym, deterministycznym kodzie, pobierać wiedzę z tamtego miejsca, gdzie się znajduje, pozwalać tylko istotnym informacjom trafić do promptu, odnotowywać źródło każdej z nich oraz aktualizować lub usuwać wpisy w miarę zmian faktów.
Bazy danych istnieją po to, by przechowywać dane. Pamięć agenta ma inny cel: umieszczenie odpowiednich faktów przed modelem w momencie, gdy są one potrzebne, jednocześnie zapobieganie temu, by stare informacje przekształciły się w późniejszą pewność.
Literatura pokrewna
- Praktyczne notatki: „Agentic AI” to przede wszystkim demo, a nie produkt — Szczegółowy opis Praktycznych notatek: „Agentic AI” to przede wszystkim demo, a nie produkt: umowy, sprawdzenia oraz gotowe elementy kodu dla zespołów wdrażających ten model.
- Co odkrywa agent diffing modelu: zmiany stylu przesłaniają wąskie dostosowania — Audytor typu „czarna skrzynka” porównał model bazowy z LoRA do celów finansowych: 82% testów wykazało zmiany długości i struktury, natomiast zamierzone modyfikacje dotyczące analizy negatywnych skutków pozostały niewidoczne.