AI nie pamięta. Ekosystem wokół niego już może.

Tłumaczysz AI kontekst projektu, architekturę, preferencje. Godzina wyjaśniania - model rozumie, trafia w punkt. Następnego dnia otwierasz ten sam czat i zaczynasz od zera. Dla modelu to pierwszy raz.

Kontekst to nie pamięć

Okno kontekstowe działa jak tablica. Pojemna - dziś do dwóch milionów tokenów - ale kasowana po każdej sesji. Zamknij rozmowę, a tablica jest czysta.

Co jeśli reguły projektu, Twoje poprawki, kluczowe decyzje architektoniczne mają przetrwać wyczyszczenie? Tu kończy się kontekst, a zaczyna pamięć. Pamięć nie jest cechą modelu - to element architektury systemu, który go otacza.

Typy trwałej pamięci

Pamięć w ekosystemie AI to nie jedna technologia. Trzy główne sposoby implementacji, każde z innymi kompromisami.

Typ Pamięci	Mechanizm	Zalety	Wady	Przykłady
Pliki tekstowe	Zapis w formacie Markdown, JSON, etc.	- Pełna kontrola - Prostota - Wersjonowanie (np. Git) - Zaskakująco skuteczne (74% accuracy w benchmarku Letta)	- Wymaga ręcznego parsowania - Wolne przy dużej skali	Claude Code (`CLAUDE.md`), Cursor (`.cursor/rules`), Windsurf
Baza wektorowa (RAG)	Embeddingi + similarity search	- Skalowalność - Szybkie wyszukiwanie semantyczne	- Brak rozumienia temporalnego - “Zapisane ≠ znalezione”	Mem0, LangChain, LlamaIndex
Graf wiedzy	Encje i relacje między nimi	- Rozumowanie wieloskokowe (multi-hop) - Obsługa czasu	- Wysoki koszt budowy ontologii - Trudne utrzymanie	Zep/Graphiti, Neo4j

Pliki tekstowe

Punkt wejścia. Zero konfiguracji - plik markdown na dysku, ładowany na start sesji. Sprawdzają się tam, gdzie pamięć zmienia się rzadko i jest zarządzana ręcznie: reguły projektu, konwencje kodu, preferencje użytkownika. Narzędzia do kodowania (Claude Code, Cursor, Copilot) wybrały właśnie tę drogę. 74% accuracy w benchmarku Letta pokazuje, że prostota nie oznacza słabości. Ograniczenie pojawia się przy skali - gdy plików jest kilkadziesiąt, znalezienie właściwego bez wyszukiwania semantycznego staje się problemem.

Baza wektorowa (RAG)

Rozwiązuje problem skali. Dokumenty zamienione na embeddingi można przeszukiwać po znaczeniu, nie po nazwie pliku. Typowe zastosowanie: bazy wiedzy, customer support, asystenci z dostępem do dokumentacji. Wymaga więcej nakładu pracy niż pliki - przejście oznacza zbudowanie pipeline’u embeddingów, jednorazowy koszt, ale nie trywialny. Główna pułapka: similarity search znajduje dokumenty “podobne”, nie “potrzebne”. Wysoki score podobieństwa nie gwarantuje, że model użyje znalezionego fragmentu.

Graf wiedzy

Pasuje tam, gdzie relacje między faktami są ważniejsze niż same fakty. Jeśli system musi odpowiedzieć na pytanie “kto pracował nad projektem X, który zależał od decyzji Y podjętej w Q3” - vector store tego nie ogarnie, graf tak. Zastosowania: domeny regulacyjne, prawne, medyczne, złożone systemy z wieloma zależnościami. Koszt wejścia jest najwyższy ze wszystkich typów - projektowanie ontologii wymaga eksperta domenowego i znacznie więcej pracy niż pozostałe podejścia. Migracja z prostszych typów jest trudna, bo wymaga zdefiniowania typów encji i relacji od zera.

Podejście hybrydowe

Produkcyjne systemy rzadko ograniczają się do jednego typu. Mem0 łączy bazę wektorową z grafową w jednym systemie. Zep łączy graf temporalny z warstwą epizodyczną. Wzorzec jest ten sam - każdy typ pokrywa inną słabość pozostałych.

Nie oznacza to, że warto zaczynać od hybrydy. Na starcie wystarczą pliki tekstowe. Dopiero gdy system zaczyna obsługiwać więcej kontekstów - kodowanie, pisanie, zarządzanie projektami - pojawia się potrzeba lepszej separacji i jednocześnie przepływu wiedzy między nimi. Pamięć najlepiej rozbudowywać wtedy, gdy wiadomo co konkretnie system zapomina.

Kto zarządza pamięcią

Wybór rodzaju pamięci to dopiero połowa decyzji, drugą częścią jest to, kto nią zarządza. Odpowiedź nie jest zero-jedynkowa - wymaga postawienia granicy: jak dużą odpowiedzialność za utrzymanie pamięci bierzesz na siebie, a na ile dajesz wolną rękę AI.

Pierwsza skrajność - użytkownik sam dodaje, edytuje i usuwa każdy element. Pełna kontrola, zero niespodzianek. Problem: system z założenia ma uczyć się sam. Jeśli jedynym źródłem wiedzy jest ręczna edycja, pamięć rośnie wolno i zależy od dyscypliny jednej osoby. Pewne elementy - reguły projektu, kluczowe zasady - mogą być zastrzeżone do edycji przez użytkownika. Ale cały system nie może opierać się tylko na tym.

Druga skrajność - AI ma pełną autonomię. Obserwuje, zapisuje i decyduje, co jest ważne. Problem odwrotny: szum. Bez nadzoru system gromadzi duplikaty, zapisuje nieistotne fakty i błędnie ocenia, co warto zapamiętać. Im dłużej działa bez weryfikacji, tym bardziej jakość odzyskiwania informacji spada pod ciężarem nieistotnych danych.

Pomiędzy tymi biegunami jest podejście hybrydowe - podział pamięci na dwie strefy. Jedna, kontrolowana wyłącznie przez AI, gdzie system obserwuje interakcje, odnotowuje wzorce i gromadzi wstępne obserwacje. Druga, kontrolowana przez użytkownika i wspierana przez AI, zawiera zweryfikowaną wiedzę, zatwierdzone wzorce i ustalone reguły. Obserwacje AI trafiają do zweryfikowanej części dopiero po osiągnięciu progu pewności - gdy powtórzą się w kilku sesjach, zostaną potwierdzone przez użytkownika a także nie będą sprzeczne z istniejącą wiedzą.

”Zapamiętywanie” to nie “uczenie się”

Żaden z dostępnych komercyjnie produktów nie oferuje prawdziwego uczenia się - nie zmienia modelu w odpowiedzi na interakcje. Wszystkie opisane typy pamięci działają tak samo: zapisują dane na zewnątrz i ładują je do kontekstu modelu przy każdym zapytaniu. To trwały zapis ładowany do kontekstu (persistent context), nie uczenie.

Jednak z perspektywy użytkownika granica się zaciera. Skill napisany raz, skorygowany trzy razy, zwalidowany na dwudziestu sesjach - z perspektywy użytkownika system “nauczył się” procedury. Z perspektywy modelu - dostał lepszy prompt. To nie model się uczy - uczy się ekosystem wokół niego. Orkiestracja bez pamięci powtarza te same błędy co sesję - pamięć daje jej ciągłość.

Nowe problemy

Pamięć nie jest darmowym ulepszeniem. Podobnie jak hooki, które rejestrują zdarzenia bez warstwy interpretującej je później, pamięć otwiera nową powierzchnię ataku i wprowadza problemy, których nie było w systemach bezstanowych.

Staleness: Zmienił się stack technologiczny, zmienił się pracodawca, zmieniły się zasady projektu - ale w pamięci wciąż siedzi stara wersja. Stary fakt ma wysoki score podobieństwa, więc system sięga po niego zamiast po aktualny.
Zatrucie: Złośliwa strona internetowa może wstrzyknąć instrukcje do długoterminowej pamięci AI (atak SpAIware), tworząc trwały backdoor. W ataku PoisonedRAG wystarczyło 5 zatrutych dokumentów na 2,7 miliona w bazie, by osiągnąć ponad 90% skuteczności.
Retrieval gap: Generator ignoruje od 47% do 67% dokumentów, które retriever uznał za najbardziej trafne. Stored ≠ found ≠ used.

Pliki na dysku, wektory w bazie, grafy relacji - to mechanizmy zapamiętywania. Ich obecność zdecydowanie zwiększa możliwości ekosystemu AI. Ale samo zapamiętanie czegoś nie gwarantuje jeszcze sukcesu. Najważniejsze jest to, czy właściwe informacje trafiają do kontekstu - a te, które już nie powinny tam być, znikają.

W newsletterze rozwijam tego rodzaju tematy głębiej. Zapisz się.