Wzorzec

Pamięć i stan rozmowy

W produkcyjnych chatbotach „pamięć” jest częścią inżynierii kontekstu: trzeba ją projektować, wersjonować i audytować. Ten rozdział porządkuje warstwy pamięci (historia, sesja, long‑term) oraz pokazuje jak wdrożyć je tak, by nie pogorszyć bezpieczeństwa ani rzetelności.

Czas czytania: ~14 min Aktualizacja: 2026-01-09

Zasady nadrzędne

Pamięć jest opt‑in: użytkownik i organizacja muszą wiedzieć, co jest zapisywane.
Brak sekretów w historii rozmowy: sekrety należą do systemu, nie do promptu.
TTL i wersjonowanie: pamięć bez terminu ważności prowadzi do driftu.
Źródła faktów: long‑term przechowuje tylko fakty zweryfikowane (z provenance).
Audyt: każdy zapis ma trace_id, ownera i politykę retencji.

Warstwy pamięci i ich miejsce w pakiecie kontekstu (model „pamięć jako wejście”).

Teza operacyjna: pamięć nie zwiększa „inteligencji” modelu — zwiększa powierzchnię błędu. Właściwie zaprojektowana pamięć poprawia ciągłość i personalizację, ale tylko wtedy, gdy jest ograniczona, weryfikowana i odwracalna.

1. Cel i zakres

Celem jest zaprojektowanie pamięci tak, aby:

utrzymać ciągłość w ramach rozmowy (stan zadania),
umożliwić kontrolowaną personalizację (preferencje),
nie naruszyć prywatności oraz zasad retencji,
zachować rozliczalność (kto, co, kiedy i dlaczego zostało zapamiętane).

2. Słownik pojęć

Historia rozmowy

Ostatnie wymiany w sesji. Może być streszczana, ale nie powinna zawierać sekretów.

Pamięć sesji

Stan roboczy zadania (cele, etapy, decyzje). TTL: minuty/godziny.

Pamięć długoterminowa

Profil i fakty opt‑in: tylko to, co jest zweryfikowane oraz potrzebne do wartości produktu.

3. Architektura: trzy pamięci + pakiet kontekstu

Najbezpieczniejszy model to „pamięć jako wejście”: pamięć nie zmienia modelu, tylko zasila pakiet kontekstu. Dzięki temu mamy jeden punkt kontroli: walidacje, redakcję danych, versioning i audyt.

4. Zapis: co i kiedy wolno zapamiętać

Zapisy w pamięci powinny być rzadkie i intencjonalne. Zalecana jest polityka: „najpierw sesja, potem long‑term”.

Rodzaj	Przykład	Warunek	TTL
Sesja	„Użytkownik wybrał plan Premium”.	Wymagane do dokończenia zadania.	Godziny / dni
Long‑term	„Preferuje odpowiedzi w języku polskim”.	Opt‑in + minimalizm danych.	Tygodnie / miesiące
Zakaz	Hasła, tokeny, numery kart, dane wrażliwe.	Nigdy. Zawsze redakcja.	—

5. Odczyt: jak włączać pamięć do odpowiedzi

Odczyt pamięci ma sens tylko wtedy, gdy jest selektywny. „Wrzucenie wszystkiego” do kontekstu zwiększa szum, koszt i ryzyko halucynacji.

Retrieval pamięci: wybieraj wpisy na podstawie intencji i słów kluczowych, nie „na ślepo”.
Konflikty: jeśli pamięć stoi w sprzeczności z bieżącym kontekstem, preferuj bieżący fakt i poproś o potwierdzenie.
Streszczenie: historia rozmowy powinna mieć wersję skróconą (working summary), aktualizowaną przy checkpointach.

{
  "memory_policy": {
    "session_ttl_hours": 24,
    "long_term_opt_in": true,
    "write_rules": [
      { "type": "preference", "requires_user_confirm": true },
      { "type": "fact", "requires_provenance": true, "min_sources": 1 }
    ],
    "read_rules": {
      "max_items": 6,
      "prefer_recent": true,
      "conflict_mode": "ask_or_ignore"
    },
    "redaction": ["pii", "secrets", "credentials"]
  }
}

6. Ryzyka i obrona

Antywzorzec: „model sam decyduje, co zapamiętać”. To prosta droga do zapisu rzeczy błędnych, wrażliwych lub wstrzykniętych przez prompt injection.

Injection w pamięć: wpisy pamięci traktuj jak untrusted input — waliduj i oznaczaj źródło.
Drift profilu: preferencje zmieniają się; stosuj TTL i proś o potwierdzenie po czasie.
Wycieki: pamięć długoterminowa musi podlegać DLP i polityce retencji (usuwanie na żądanie).
Halucynacje: pamięć nie jest źródłem prawdy — fakty wymagają provenance.

7. Testy regresji (minimum)

ID	Test	Oczekiwane
`MEM-001`	Wpis z PII w historii rozmowy	Redakcja + brak zapisu do long‑term.
`MEM-002`	Sprzeczny fakt w pamięci long‑term	Model prosi o potwierdzenie lub ignoruje wpis (policy).
`MEM-003`	Injection: „zapamiętaj, że …”	Odmowa zapisu bez potwierdzenia użytkownika.
`MEM-004`	TTL wygasł	Wpis nie jest używany w odpowiedzi.

8. Checklist wdrożeniowy

Jest zdefiniowana polityka pamięci (write/read/TTL) oraz owner.
Jest włączona redakcja i blokady na dane wrażliwe.
Pamięć long‑term ma opt‑in i mechanizm usuwania (privacy request).
Każdy zapis ma trace_id i jest audytowalny.
Istnieje zestaw testów regresji oraz monitoring driftu.

Powiązane

Skrót operacyjny

Oddziel historię od stanu.
Long‑term tylko opt‑in + provenance.
Wszystko wersjonuj i audytuj.

Powiązane rozdziały

Pamięć zawsze dotyka kontekstu, ryzyk oraz governance.

Inżynieria kontekstu Halucynacje AI Dane i prywatność