Pamięć konwersacji i zarządzanie stanem sesji w n8n: jak budować chatboty AI z kontekstem wieloetapowym

Dlaczego pamięć konwersacji decyduje o użyteczności chatbota

Bez pamięci rozmowa z modelem LLM w n8n to zbiór niezależnych zapytań. Użytkownik podaje imię w pierwszej wiadomości, a w trzeciej bot już go nie zna. Pyta o adres, choć został podany dwie wiadomości wcześniej. Takie doświadczenie szybko zniechęca. Pamięć konwersacji pozwala przekazywać historię jako kontekst do kolejnych wywołań modelu, dzięki czemu automatyzacja prowadzi spójny, wieloetapowy dialog.

Gdzie przechowywać stan sesji w n8n

Wbudowana pamięć w n8n działa w ramach jednego wykonania workflowu. Jeśli przepływ uruchamia się przez webhook za każdym razem, gdy użytkownik wysyła wiadomość, dane z poprzednich wywołań nie są automatycznie dostępne. Rozwiązaniem jest zewnętrzna baza danych.

Postgres lub MySQL — używam standardowych węzłów Postgres lub MySQL do zapisu i odczytu historii. Tworzę tabelę z kolumnami: session_id, user_id, role (user/assistant), content, timestamp. Przed wywołaniem modelu pobieram ostatnie N wiadomości dla danego session_id, sortując po czasie malejąco.

Redis — gdy potrzebuję bardzo szybkiego dostępu do aktywnych sesji, wybieram węzeł Redis. Nadaję klucz w formacie chat_session:{session_id} i przechowuję serializowaną tablicę wiadomości. Redis sprawdza się przy dużej liczbie równoległych rozmów, ale wymaga polityki TTL, aby nie gromadzić martwych sesji.

Static Data i pliki — tymczasowe rozwiązania. Dane w Static Data giną po zakończeniu wykonania, a zapisywanie historii do pliku CSV lub JSON w filesystemie szybko staje się wąskim gardłem przy wielu użytkownikach. Używam ich wyłącznie w prototypach.

Wzorzec przepływu: odczyt, dołączenie kontekstu, zapis odpowiedzi

Mój standardowy workflow dla chatbota z pamięcią składa się z pięciu kroków:

1. Webhook lub trigger — przyjmuje wiadomość użytkownika i identyfikator sesji.
2. Odczyt historii — węzeł Postgres/Redis pobiera istniejące wiadomości dla danego session_id.
3. Przygotowanie tablicy messages — węzeł Code lub Set formatuje dane do struktury wymaganej przez API modelu, np. [{role: "user", content: "..."}, ...].
4. Wywołanie LLM — węzeł OpenAI Chat Model lub inny node LLM otrzymuje system prompt plus pełną historię jako messages.
5. Zapis odpowiedzi — nowa wiadomość asystenta trafia do bazy z tym samym session_id, a następnie zwracam ją użytkownikowi.

Ten wzorzec gwarantuje, że każde wywołanie modelu zawiera aktualny kontekst rozmowy.

Formatowanie historii dla różnych modeli LLM

Nie wszystkie modele przyjmują historię w tym samym formacie.

OpenAI GPT — wymaga tablicy obiektów z polami role i content. System prompt umieszczam jako pierwszy element z role: "system", a następnie dołączam historię z role: "user" i role: "assistant".

Claude (Anthropic) — w starszych wersjach API wymaga konkatenacji tekstu z oznaczeniami \n\nHuman: i \n\nAssistant:. W nowszych wersjach Messages API stosuje strukturę podobną do OpenAI, ale bez roli system w tablicy (system prompt przekazuje się w osobnym polu). Sprawdzam dokumentację konkretnego endpointu, zanim zbuduję payload.

Modele lokalne przez Ollama / LM Studio — często akceptują format OpenAI-compatible, ale nie zawsze obsługują system prompts poprawnie. Testuję formatowanie w izolowanym węźle przed podłączeniem do produkcyjnego przepływu.

Zasada, której przestrzegam: nigdy nie wysyłam surowego tekstu z konkatenacją typu "User: ... Assistant: ..." do modelu, który oczekuje struktury JSON, bo to zwiększa ryzyko błędów parsowania po stronie API.

Ograniczanie długości kontekstu i priorytetyzacja wiadomości

Każdy model ma limit tokenów. Jeśli historia rozmowy jest za długa, przekraczam okno kontekstowe i otrzymuję błąd lub obciętą odpowiedź.

Sliding window — ustalam maksymalną liczbę par user-assistant (np. 10 ostatnich). W zapytaniu SQL używam LIMIT 20 (10 par), a starsze wiadomości pomijam. To proste, ale tracę wcześniejszy kontekst.

Podsumowanie historii — gdy rozmowa przekracza 10 par, wywołuję tańszy model (np. z lokalnego endpointu lub lekkiego API) do stworzenia podsumowania dotychczasowej wymiany. Podsumowanie zastępuje starsze wiadomości w kontekście, a szczegóły z ostatnich 3 tur pozostają w pełnej formie. Dzięki temu model pamięta istotne fakty bez przesyłania całego transcriptu.

Liczba tokenów, nie znaków — węzeł Code w n8n nie ma wbudowanego tokenizera, ale mogę przybliżyć: 1 token ≈ 4 znaki w języku polskim. Dla bezpieczeństwa zakładam 1 token ≈ 3 znaki. Jeśli system prompt plus historia przekracza 75% limitu kontekstu modelu, uruchamiam mechanizm skracania.

Pamięć krótko- i długoterminowa: dwie tabele, dwa cele

W praktyce rozdzielam pamięć na dwa poziomy.

Pamięć krótkoterminowa (sesja) — tabela chat_history przechowuje bieżącą rozmowę. Służy do utrzymania płynności dialogu w obrębie jednej sesji. Czyszczę ją po 24–48 godzinach braku aktywności, jeśli nie ma potrzeby archiwizacji.

Pamięć długoterminowa (profil użytkownika) — tabela user_memory przechowuje wyekstrahowane fakty: imię, preferencje, numer klienta, wcześniejsze zgłoszenia. Przed rozpoczęciem nowej sesji pobieram te dane i wstrzykuję do system promptu jako faktograficzny kontekst. Dzięki temu użytkownik nie musi powtarzać podstawowych informacji przy każdym nowym czacie.

Ten podział pozwala budować spersonalizowane doświadczenia bez przesyłania setek wiadomości z poprzednich miesięcy.

Identyfikacja sesji i walidacja kluczy

Kluczowe jest, aby session_id był stabilny i bezpieczny. W integracjach ze Slackiem używam thread_ts jako identyfikatora wątku. W Microsoft Teams — conversation.id. W własnych widgetach na stronie — losowy UUID generowany po stronie frontendu i zapisywany w localStorage.

Zawsze waliduję format session_id przed użyciem w zapytaniu SQL. Jeśli identyfikator pochodzi z zewnętrznego źródła, sprawdzam wyrażeniem regularnym, czy składa się wyłącznie z dozwolonych znaków (alfanumerycznych i myślników). Zapobiega to atakom typu SQL injection lub przepełnieniu klucza w Redisie, szczególnie gdy przepływ jest publicznie dostępny przez webhook.

Checklist przed wdrożeniem chatbota z pamięcią

Przed uruchomieniem przepływu na produkcji weryfikuję:

• Baza danych ma indeks na kolumnie session_id — bez tego odczyt historii przy tysiącach sesji staje się powolny.
• Węzeł LLM otrzymuje historię w poprawnej kolejności chronologicznej — nie malejącej.
• System prompt zawiera instrukcję, aby model nie powtarzał całej historii w odpowiedzi, lecz odnosił się do niej kontekstowo.
• Mechanizm skracania historii jest przetestowany na najdłuższej możliwej rozmowie.
• TTL lub cron czyszczący stare sesje jest skonfigurowany, aby baza nie rosła w nieskończoność.
• Poświadczenia do bazy danych są przechowywane w Credentials n8n, a nie w kodzie węzła.

Jak unikać typowych błędów

Najczęstszy problem, który naprawiam u klientów, to zapętlenie kontekstu: bot wysyła odpowiedź, zapisuje ją w bazie, a przy kolejnym wywołaniu traktuje własną odpowiedź jako nowe zapytanie użytkownika. Rozwiązaniem jest precyzyjne rozdzielenie ról — zapisuję tylko faktyczne wiadomości użytkownika i odpowiedzi asystenta, a wyzwalacz workflowu reaguje wyłącznie na zdarzenia z zewnątrz.

Drugi błąd to mutowanie kontekstu w węźle Code bez kopiowania tablicy. W JavaScript używam JSON.parse(JSON.stringify(history)) lub spread operatora, aby modyfikacje formatowania nie wpływały na dane w pamięci workflowu przed zapisem do bazy.

Jeśli budujesz wewnętrznego asystenta AI lub chatbota dla klientów i chcesz, aby rozmowa prowadzona przez n8n była spójna między kolejnymi wiadomościami — pomogę zaprojektować architekturę pamięci, dobrać bazę danych i wdrożyć przepływ z walidacją stanu sesji. Zaczynamy od audytu istniejącego workflowu i mapy wymaganych kontekstów.