Pamięć konwersacji w n8n: zapisywanie historii chatu i kontekst w automatyzacjach AI

Pojedyncze zapytanie do API LLM zwraca odpowiedź wyłącznie na podstawie treści przesłanej w bieżącym żądaniu. Jeśli budujesz w n8n chatbota wsparcia klienta lub asystenta do zbierania zapytań, model bez historii nie wie, co działo się dwie wiadomości wcześniej. Pamięć konwersacji to mechanizm zapisywania kolejnych tur rozmowy i dołączania ich do kolejnych zapytań jako kontekst. Bez tego nie da się zbudować wieloetapowej automatyzacji, która pozwala użytkownikowi doprecyzować wcześniejsze pytanie. W Qualix wdrażamy takie rozwiązania dla firm z Bytomia, Śląska i całej Polski.

Dlaczego przepływy bez pamięci nie sprawdzają się w dialogu

W automatyzacjach opartych na jednym promocie każde zapytanie jest niezależne. Użytkownik musi powtarzać informacje, a model nie może nawiązać do wcześniejszych ustaleń. Próba wciskania całej hipotetycznej historii do statycznego szablonu promptu kończy się albo przekroczeniem limitu tokenów, albo generowaniem ogólnych odpowiedzi pozbawionych kontekstu. Dlatego wdrażam osobny magazyn historii, który dynamicznie buduje okno kontekstowe przed każdym wywołaniem modelu.

Jak technicznie zbudować pamięć sesji w n8n

n8n w wersji cloud i self-hosted nie oferuje gotowego bloczku „pamięć konwersacji” w rozumieniu natywnego magazynu historii chatu. Muszę zbudować tę logikę samodzielnie. Najprostszą metodą, którą stosuję w wdrożeniach, jest zapisywanie kolejnych wiadomości w zewnętrznej bazie danych, a następnie pobieranie ich przed każdym wywołaniem węzła LLM.

Identyfikacja sesji

Każda rozmowa musi mieć unikalny identyfikator sessionId. Tworzę go na podstawie ID użytkownika z zewnętrznego systemu – na przykład z Telegrama, Slacka, identyfikatora sesji z czatu na stronie lub adresu e-mail. Przy pierwszym kontakcie, gdy nie mam jeszcze identyfikatora, generuję UUID i zwracam go do frontendu lub zapisuję w polu ukrytym formularza. Bez stabilnego sessionId nie jestem w stanie rozdzielić konwersacji różnych osób i pobierać właściwego kontekstu.

Struktura zapisu w bazie danych

Zapisuję historię w bazie relacyjnej – najczęściej PostgreSQL lub MySQL, choć w prostych prototypach wystarczy SQLite lub nawet Google Sheets. Każdy rekord zawiera:

• session_id – klucz do filtrowania,
• role – user albo assistant,
• content – treść wiadomości,
• timestamp – chronologiczne sortowanie.

Unikam zapisu całej historii jako jednego JSON-a w jednym polu, ponieważ przy dużej liczbie sesji taka struktura utrudnia filtrowanie i czyszczenie starych rekordów.

Pobieranie i sortowanie kontekstu

Przed węzłem wywołującym model LLM (np. OpenAI Chat Model lub HTTP Request do lokalnego Ollama) umieszczam węzeł bazy danych. Zapytanie SQL pobiera ostatnie N wiadomości dla konkretnego sessionId, sortuje je rosnąco według czasu i zwraca jako kolekcję obiektów. To zabezpiecza przed sytuacją, w której do modelu trafiają wiadomości w losowej kolejności.

Formatowanie historii dla API LLM

API takie jak OpenAI, Anthropic czy lokalne Ollama w trybie chat oczekują listy wiadomości z określonymi rolami: system, user, assistant. W n8n używam węzła Set lub Code, aby przekształcić wiersze z bazy w tablicę messages.

Przykład struktury, którą przekazuję do modelu:

[
  {"role": "system", "content": "Jesteś asystentem firmy usługowej z Bytomia. Odpowiadaj zwięźle po polsku."},
  {"role": "user", "content": "Czy projektujecie strony dla branży gastronomicznej?"},
  {"role": "assistant", "content": "Tak, tworzę strony dla lokali gastronomicznych, w tym z systemem rezerwacji i menu online."},
  {"role": "user", "content": "Ile trwa taka realizacja?"}
]

Dzięki temu model rozumie, że pytanie o realizację dotyczy strony dla branży gastronomicznej, a nie ogólnej usługi. Nie muszę powtarzać kontekstu w każdym zapytaniu – historia robi to za mnie.

Ograniczanie okna kontekstowego i rotacja historii

Każdy model ma twardy limit tokenów. Jeśli historia rozmowy będzie rosła w nieskończoność, przekroczę ten limit i otrzymam błąd API lub obciętą odpowiedź. Stosuję dwa sprawdzone rozwiązania.

Sliding window – pobieram stałą liczbę ostatnich tur, na przykład 5 par user-assistant (10 wiadomości). To gwarantuje przewidywalne zużycie tokenów i stabilny koszt wywołania.

Podsumowanie zamiast pełnej historii – przy długich sesjach generuję w osobnym kroku podsumowanie wcześniejszej części rozmowy. Następnie zastępuję stare wpisy tym podsumowaniem, zachowując kluczowe fakty, takie jak branża klienta, zakres usługi czy preferowana lokalizacja. Pozwala to utrzymać ciągłość dialogu bez rozdmuchiwania kontekstu.

Przykład: chatbot wsparcia klienta z pamięcią w n8n

Ostatnio budowałem przepływ, w którym chatbot na stronie firmy usługowej odpowiadał na pytania o ofertę i zbierał dane kontaktowe. Przepływ wyglądał następująco:

1. Webhook odbierał wiadomość z frontendu wraz z sessionId.
2. Węzeł PostgreSQL pobierał ostatnie 6 wiadomości dla tego identyfikatora.
3. Węzeł Code łączył prompt systemowy z historią w poprawnym formacie JSON.
4. HTTP Request wysyłał przygotowaną tablicę do API OpenAI.
5. Odpowiedź asystenta była zapisywana do bazy jako nowy rekord z rolą assistant.
6. Treść wracała do czatu na stronie.

Efekt? Użytkownik mógł napisać: „A czy mogę do tej wyceny dodać opiekę techniczną?” – i bot rozumiał, o którą wycenę chodzi, bo widział wcześniejszą rozmowę. Bez pamięci musiałby opisywać całe zapotrzebowanie od nowa.

Checklist przed wdrożeniem na produkcję

Przed uruchomieniem przepływu z pamięcią konwersacji weryfikuję następujące kwestie:

• sessionId jest stabilny dla tego samego użytkownika i nie zmienia się przy odświeżeniu strony bez wyraźnej potrzeby.
• Zapytanie SQL pobiera wiadomości wyłącznie dla bieżącej sesji i sortuje je chronologicznie.
• Liczba zwracanych wiadomości nie przekracza 70–80% limitu kontekstu użytego modelu.
• Zdefiniowałem politykę retencji danych – historia nie jest przechowywana w nieskończoność.
• Przepływ obsługuje błąd niedostępności bazy (fallback do zapytania bez historii lub komunikat techniczny).
• Przetestowałem scenariusz pierwszej wiadomości, gdy baza zwraca pusty wynik.

Jeśli planujesz wdrożyć w firmie asystenta AI z prawdziwą pamięcią rozmowy, pomogę zaprojektować architekturę przepływu w n8n – od wyboru bazy danych i formatowania kontekstu, po ograniczanie zużycia tokenów i testowanie scenariuszy brzegowych. Skontaktuj się, aby omówić szczegóły techniczne wdrożenia.