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
Rozszerzenie praktyczne

Operacyjny skrót

Ten rozdział należy do rodziny Projektowanie interakcji i ma formę Wzorzec. Poniższe dopowiedzenie ma jeden cel: przełożyć treść na działania, które da się wdrożyć, zmierzyć i utrzymać.

Checklista

  • Ustal cel i kryteria poprawności (co znaczy „dobry wynik”).
  • Zamknij format wyjścia (JSON / tabela / sekcje) i przygotuj walidację.
  • Ogranicz przestrzeń odpowiedzi: instrukcje, słownik terminów, limity.
  • Dodaj kontrolę jakości: self-check, sanity-checks, fallback, „no-answer”.
  • Zapisz jako szablon (prompt_template) i wersjonuj jak kod.
  • Wprowadź testy regresyjne (golden set) i przeglądy po zmianach.

Najczęstsze pułapki

  • Mieszanie instrukcji z danymi wejściowymi (brak separacji „co” vs „na czym”).
  • Format wynikowy „opisowy” bez kontraktu – brak automatycznej kontroli.
  • Zbyt ogólne polecenia („napisz mądrze”) bez parametrów i ograniczeń.
  • Brak strategii na niepewność: model zaczyna „zgadywać” zamiast eskalować.

Artefakty w Luage

prompt_template output_contract policy:language.standard trace_id golden_set

Standard działa dopiero wtedy, gdy ma właściciela, wersję, ślad (trace) oraz test regresyjny.

Szablon do skopiowania

Minimalny szablon promptu (do biblioteki)

prompt_template: support.reply@v3
intent: support.reply
inputs:
  - user_message
  - locale
constraints:
  - "Jeśli brak źródła → powiedz, że nie wiesz i poproś o doprecyzowanie"
output:
  format: markdown
  sections: ["Odpowiedź", "Co dalej"]

Traktuj szablon jak kod: owner, wersja, testy i przegląd. Wtedy to działa powtarzalnie.

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”).
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”.

RodzajPrzykładWarunekTTL
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)

IDTestOczekiwane
MEM-001Wpis z PII w historii rozmowyRedakcja + brak zapisu do long‑term.
MEM-002Sprzeczny fakt w pamięci long‑termModel prosi o potwierdzenie lub ignoruje wpis (policy).
MEM-003Injection: „zapamiętaj, że …”Odmowa zapisu bez potwierdzenia użytkownika.
MEM-004TTL 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
  1. Oddziel historię od stanu.
  2. Long‑term tylko opt‑in + provenance.
  3. Wszystko wersjonuj i audytuj.
Powiązane rozdziały

Pamięć zawsze dotyka kontekstu, ryzyk oraz governance.

Inżynieria kontekstu Halucynacje AI Dane i prywatność