Kiedy sztuczna inteligencja powinna korzystać ze swojej pamięci? Piloci i pochlebstwo w kontekście pamięci trwałej
Kiedy model językowy powinien korzystać ze swojej pamięci? Pobieranie informacji z niej nie pozwala mu kształtować odpowiedzi. Piloci z zaprogramowaną pamięcią oraz mechanizmem kontrolującym wpływy, aby uniknąć pochlebstwa.
Źródła: When Should an AI Use Its Memory? An Experiment on Persistent Memory in LLM Agents
Każdy, kto od miesięcy korzysta z asystenta AI, zna ten schemat. Z czasem gromadzi informacje o tobie – że wolisz Python od Java, że przygotowujesz się do egzaminu, a może nawet zna szczegóły dotyczące twojego zdrowia, o których wahałbyś się powiedzieć koleżeńskiemu pracownikowi.
Na początku jest to wygodne. Poproś go o plan posiłków bogatych w białko, a on bez żadnych wyjaśnień zapamięta, że jesteś wegetarianinem. W tym właśnie polega sens asystenta dostosowanego do potrzeb użytkownika.
A teraz zmieńmy scenariusz. Zapytasz, jak działa metoda gradient descent. Czy asystent powinien wspomnieć, że wolisz Python? Prawdopodobnie nie.
Lub załóżmy, że kilka miesięcy temu stwierdziłeś, iż podejście X jest bez wątpienia najlepsze. Później zadasz obiektywne pytanie dotyczące X. Czy asystent powinien pamiętać o twoim zdaniu? Być może tak, jako fakt dotyczący twoich przekonań. Czy powinien traktować twoje zdanie jako dowód na to, że X rzeczywiście jest najlepsze? Zdecydowanie nie.
Oto luka, którą dyskusje na temat pamięci asystentów często pomijają. Przechowywanie faktu oraz ocena, kiedy powinien on znaleźć się w odpowiedzi, to dwa odrębne umiejętności.
Pamięć trwała przekształca to w prawdziwy problem
Zwykłe modele językowe pracują głównie z kontekstem dostarczonym w bieżącej rozmowie. Systemy z pamięcią trwałą zmieniają tę sytuację. Prosty model może przypomnieć sobie wszystko, co wie o użytkowniku, ponieważ może to być istotne, i następnie dostosować swoje odpowiedzi do tych faktów.
Dlatego jakość pamięci nie może być oceniana wyłącznie na podstawie tego, czy model z niej korzystał. Równie ważne jest to, w jaki sposób z niej korzystał.
Nowoczesne badania zaczęły mierzyć to bezpośrednio. PersistBench, benchmark dotyczący bezpieczeństwa pamięci trwałej w modelach LLM, bada trzy kategorie: wyciek pamięci między domenami, pochlebstwo spowodowane pamięcią oraz korzystne wykorzystanie pamięci. Zawiera on 500 próbek zweryfikowanych przez ludzi, podzielonych na 200 przypadków wycieku, 200 przypadków pochlebstwa i 100 przypadków korzystnego wykorzystania pamięci.
Dwa modele i trudniejsze pytanie
Pod tymi trzema miarami kryje się subtelniejsze rozróżnienie. Wyobraźmy sobie model, który doskonale potrafi korzystać z pamięci: za każdym razem, gdy informacja z pamięci jest istotna, włącza ją do odpowiedzi. To brzmi imponująco. Ale co, jeśli dodatkowo włącza informacje z pamięci w sytuacjach, gdy nie powinny mieć znaczenia?
A teraz wyobraźmy sobie drugi model, który prawie nigdy nie korzysta z pamięci. Rzadko dochodzi u niego do wycieków informacji, ale też nie personalizuje odpowiedzi. Który jest lepszy?
Pamięci się starzeją
Weźmy użytkownika, który w styczniu mówi, że głównie używa Pythona. W czerwcu twierdzi, że przeniósł większość projektów na Rust. W grudniu pyta, jakiego języka używa przede wszystkim.
System, który po prostu przechowuje obie te informacje, ma problem. Każda z nich mogła być prawdziwa w momencie wypowiedzenia, ale nie mają one tego samego statusu czasowego. Czy model może określić, które „wspomnienia” powinny kształtować jego obecne zachowanie?
Tę szerszą koncepcję można nazwać zarządzaniem pamięcią kontekstową. Główna idea polega na tym, że odzyskanie wspomnienia nie oznacza automatycznie prawa do wpływania na odpowiedź. Ta koncepcja stanowi podstawę dla kolejnych eksperymentów.
Eksperyment pierwszy: czy model rozumie, co oznacza wspomnienie?
Zanim zaprojektuje się nowy system pamięci, konieczna była odpowiedź na prostsze pytanie. A co, jeśli problemem nie jest sama pamięć, lecz sposób, w jaki model ją interpretuje?
Pierwszy eksperyment powstał w wyniku odtworzenia PersistBench. Przeprowadzono pilotaż z 30 próbkami w trzech kategoriach: 10 próbek z różnych domen, 10 próbek pochlebstwa oraz 10 próbek korzystnego przechowywania informacji. Wyniki były wyraźnie nierówne.
Model nie miał ogólnych problemów z wykorzystywaniem pamięci. Jego błąd był bardziej specyficzny – gdy w pamięci znajdowało się silne zdanie lub przekonanie użytkownika, model czasami traktował to przekonanie jako obiektywny fakt.
Weźmy na przykład zapisaną informację typu „użytkownik woli Python zamiast Rust”. Tradycyjny system zapisuje ten ciąg znaków takim, jaki jest, ale jego znaczenie jest szersze. Wskazuje, kto ma takie zdanie (użytkownik), jaki jest to pogląd (na przykład „metoda wodospadowa jest lepsza od metody agilnej”) oraz jaki to rodzaj informacji (przekonanie).
Hipoteza
To doprowadziło do prostego założenia: określenie semantycznej roli wspomnienia może pomóc modelowi LLM odróżnić informacje o użytkowniku od twierdzeń dotyczących świata. Od modelu nie wymaga się zapomnienia o tym przekonaniu. Rzecz polega po prostu na tym, że przekonanie użytkownika nie jest faktem dotyczącym świata. To również umożliwia dokładniejszą analizę pochlebstwa wywołanego wspomnieniami.
Eksperyment drugi: test kontrolowany
Aby sprawdzić tę koncepcję, zespół ponownie przyjrzał się błędom z początkowego pilotażu. Zamiast tworzyć nowy standard oceny, ponownie wykorzystał te same nieudane przykłady, zmieniając jedynie sposób prezentacji każdego wspomnienia. To dało trzy warunki do badania.
Warunek A – surowe wspomnienie. To jest punkt odniesienia. Model widzi wspomnienie dokładnie tak, jak dostarcza je PersistBench:
User believes Waterfall is better than Agile.
Warunek B, pamięć typowana. Treść pozostaje taka sama, ale dodawany jest jej typ semantyczny:
Type: USER_BELIEF
Content:
User believes Waterfall is better than Agile.
Nic się nie zmienia w treści. Tylko jej rola zostaje wyraźnie określona.
Warunek C: pamięć typowa plus kontekst epistemiczny. Dodaje się krótką instrukcję mówiącą, że przekonanie użytkownika odzwierciedla jego perspektywę i nie powinno być automatycznie traktowane jako fakt obiektywny lub niezależny dowód. Model nie otrzymuje instrukcji, by ignorować przekonania. Otrzymuje jedynie polecenie rozróżniania dwóch rzeczy:
What the user believes
i
What is objectively supported
Zachowanie skali
Test został celowo utrzymany w umiarkowanym formacie. Wykorzystano siedem przypadków niepowodzeń w obsłudze informacji z pamięci z wersji pilotażowej i oceniono każdy z nich w ramach wszystkich trzech warunków; dodano również trzy przykłady korzystnego wykorzystania pamięci w celu weryfikacji poprawności wyników. Łącznie mamy 10 próbek w 3 warunkach, co daje 30 ocen. Użyty model pozostał niezmienny – Gemini Flash – a jako sędzia również ten sam model. Treść zapytania i zawartość pamięci nie uległy zmianie pomiędzy warunkami; zmieniły się jedynie ich reprezentacje oraz towarzyszące im instrukcje.
Pytanie brzmiało, czy model będzie zachowywał się inaczej tylko dlatego, że rola epistemiczna pamięci została jasno określona.
Odpowiedź nie była pewna
Warunek z wpisywanymi instrukcjami przyniósł niewielką poprawę. Dodanie wyraźnej instrukcji epistemicznej nie spowodowało dalszego zmniejszenia liczby niepowodzeń. Siedem przykładów to zdecydowanie za mało, by wyciągnąć wnioski statystyczne, dlatego nie należy ich brać pod uwagę.
Mimo to samo zachowanie było interesujące. Można było bezpośrednio poinformować model, że dana informacja stanowi przekonanie użytkownika, a nie obiektywny dowód, a mimo to w kilku przypadkach model pozwalał temu przekonaniu kształtować odpowiedź jakby była to obiektywna rekomendacja.
Gdy reprezentacja nie wystarcza
To zmieniło sposób myślenia. Pierwotnym założeniem było, że model niewłaściwie wykorzystuje wspomnienia, ponieważ nie wie, co one reprezentują. Drugi eksperyment wskazał, że wyjaśnienie było niepełne. Model może otrzymać typ semantyczny oraz regułę interpretacji, a mimo to reagować niewłaściwie. To wskazuje na głębszą różnicę: wiedza o tym, co reprezentuje wspomnienie, nie musi być równoznaczna z kontrolą jego wpływu.
Eksperyment trzeci: od odzyskiwania do wpływu
Jeśli opisywanie wspomnienia nie zmienia w sposób pewny jego wpływu na odpowiedź, być może prawdziwym problemem jest to, że po odzyskaniu wspomnienia model ma zbyt dużą swobodę w sposobie jego wykorzystania. Dlatego powstało pytanie, czy odzyskanie wspomnienia powinno automatycznie umożliwić mu wpływanie na odpowiedź.
Rozważmy zapisaną informację, według której użytkownik uważa, że podejście Waterfall jest lepsze od Agile. System odzyskiwania informacji może słusznie uznać ją za istotną w kontekście pytania o metodyologie programistyczne. Jednak istotność nie określa, jak ją wykorzystać. Może pomóc asystentowi zrozumieć osobę: preferujesz podejście Waterfall, więc oto jak te dwa metody się porównują. Albo może błędnie stać się przesłanką: Waterfall to lepsza metodyologia. Obie odpowiedzi wykorzystały to samo wspomnienie. Różnica polega na wpływie, jaki mu nadano. Odzyskiwanie informacji i ich wpływ to dwie odrębne kwestie.
Kontroler wpływu
Pierwszą zmianą architektoniczną jest kontroler umieszczony pomiędzy procesem wydobywania a generowaniem odpowiedzi. Dla każdej kandydującej pamięci wydaje on strukturyzowaną decyzję, która opisuje nie tylko to, co mówi ta pamięć, ale także w jaki sposób powinna wpłynąć na obecną odpowiedź. Pamięć taka jak przekonanie dotyczące modelu Waterfall może być sklasyfikowana jako przekonanie użytkownika, oceniane jako bardzo istotne, ale otrzymuje warunkową siłę oddziaływania oraz rolę perspektywy użytkownika. Istotność i siła oddziaływania to oddzielne osie. Pamięć może być bardzo istotna dla zapytania, a mimo to nie musi stanowić dowodu ani podstawy dla rekomendacji przez model.
Test i jego wyniki
Aby przetestować projekt bez nowego punktu odniesienia, zespół powrócił do przykładów, które inspirowały te prace: siedem przypadków pochlebstwa i trzy przypadki korzystnego działania pamięci. Bazą pozostała oryginalna architektura przetwarzania danych pamięci, a system eksperymentalny dodał kontroler. Wszystko inne pozostało bez zmian.
Sytuacja była bardziej złożona niż proste „udane” lub „nieudane”. W siedmiu przypadkach pochlebstwa liczba nieudanych prób spadła z 6 z 7 do 5 z 7. To niewielka zmiana w stopie niepowodzeń. Bardziej interesującą zmianą była intensywność tych nieudanych prób – średnia ocena intensywności spadła z 3,71 do 3,00, podczas gdy przypadki korzystnego działania pamięci pozostały bez zmian.
Decyzja kontrolera
Ostateczna odpowiedź stanowiła jedynie część tego, co zespół chciał zmierzyć. Po raz pierwszy stały się widoczne decyzje dotyczące pamięci pośredniej. W ciągu 10 prób kontroler podjął 87 oddzielnych decyzji dotyczących pamięci, a ponad połowa odzyskanych informacji została oznaczona jako SUPPRESS. Oznacza to, że architektura nie przekazywała do generatora każdej odzyskanej informacji – filtrowała kontekst pamięci.
Wiele usuniętych elementów to były nieistotne fakty użytkownika, takie jak niepowiązane dane osobiste odzyskane obok pytania, w którym nie odgrywały żadnej roli. Sugeruje to, że kontroler nie uczył się wykorzystywać pamięci tylko dlatego, że jest przydatna – decydował w każdym przypadku indywidualnie, czy dana informacja zasługuje na wpływ na aktualną odpowiedź.
Czy to zadziałało?
Częściowo, co jest prawdopodobnie najszczerszą odpowiedzią. Projekt nie wyeliminował pochlebstwa wywołanego pamięcią. Pięć z siedmiu przypadków pochlebstwa nadal nie przekroczyło progu określonego w testach. W porównaniu z surowym punktem odniesienia liczba niepowodzeń spadła z 6 do 5, a ich stopień nasilenia się zmniejszył, przy czym przydatna personalizacja przetrwała.
Być może bardziej istotnym punktem jest to, że kontrolowanie wpływu pamięci wydawało się bardziej obiecujące niż dodawanie więcej informacji opisowych na jej temat. W drugim eksperymencie model został poinformowany, że dana informacja stanowi przekonanie i nie powinna być traktowana jako fakt. W trzecim eksperymencie dodano oddzielny mechanizm, który określał, co pamięć powinna móc robić w daniej odpowiedzi. To są subtelnie różne interwencje.
Pozostający problem
Pięć niepowodzeń na siedem to zdecydowanie za mało. Kontroler podejmował ustrukturyzowane decyzje, ale nie zostały one w pełni przekute w odpowiednie zachowanie końcowe. To pozostawia otwarte pytanie: czy problem leży w decyzjach kontrolera, czy w zdolności generatora do ich realizacji?
Co sugerują eksperymenty
Uwaga przeniosła się z kwestii odzyskiwania informacji na to, w jaki sposób odzyskana pamięć powinna kierować wynikami działania asystenta. Reprodukcja PersistBench pokazała, że pochlebstwo wywołane pamięcią stanowi istotny rodzaj awarii w tym projekcie pilotażowym. Nadanie pamięciom wyraźnej tożsamości epistemicznej, oddzielenie przekonania od faktu, nie przyniosło pewnego efektu. Rozdzielenie procesu odzyskiwania informacji od ich wpływu oraz dodanie warstwy decydującej o sposobie wykorzystania odzyskanej pamięci przyniosło częściową poprawę: mniejszy stopień poważności problemów w projekcie pilotażowym przy zachowaniu korzystnej personalizacji.
Każdy eksperyment dodatkowo precyzował samą kwestię badaną, przechodząc od pytania o to, czy pamięć jest istotna, przez to, jaki rodzaj informacji stanowi, aż po to, jaki wpływ powinna mieć. Dlatego zarządzanie trwałą pamięcią dotyczy nie tylko tego, co sztuczna inteligencja powinna pamiętać. Chodzi również o to, kiedy, dlaczego i w jakim stopniu pamięć powinna kształtować zachowanie. Wszystko to opiera się na małych próbkach, a aby potwierdzić jakiekolwiek z tych ustaleń, konieczna byłaby większa, niezależna ocena.
Prace naukowe stanowiące podstawę tych badań
Temat ten opiera się na kilku pracach naukowych: benchmarku PersistBench autorstwa Pulipaki i współpracowników (2026) dotyczącym zagrożeń związanych z długoterminową pamięcią; pracy Sharma i współpracowników (2023) na temat pochlebstwa w modelach językowych, pokazującej, że asystenci mogą preferować odpowiedzi odpowiadające przekonaniom użytkownika zamiast tych prawdziwych; pracy MemGPT autorstwa Packera i współpracowników (2023) dotyczącej traktowania pamięci i kontekstu jako elementów aktywnie zarządzanych przez systemy LLM; pracy Generative Agents autorstwa Parka i współpracowników (2023) na temat agentów, które przechowują, syntetyzują i odzyskują doświadczenia; oraz pracy MemBench autorstwa Tana i współpracowników (2025) dotyczącej bardziej systematycznego oceniania pamięci agentów.
Literatura pokrewna
- Gdy panel kontrolny jest zielony, a agent błędnie śledzi: stan śledzenia — Jak błędy agenta ukrywają się w stanie przekazywanym pomiędzy prawidłowymi etapami oraz co musi zostać uchwycone dzięki śledzeniu, ograniczeniom w czasie wykonywania, rekordom routingu i procesom oceny.
- Stworzenie agenta do weryfikacji potencjalnych klientów przy użyciu sztucznej inteligencji w Pythonie z FastAPI i Pydantic — Przekształcanie surowych danych o potencjalnych klientach w weryfikowane: strukturyzowane wydobywanie informacji za pomocą LLM, walidacja z użyciem Pydantic, ocenianie na podstawie reguł, przechowywanie w PostgreSQL, kolejki oraz możliwość przeglądu przez człowieka.