n8n + AI: 5 wzorców architektury (RAG, klasyfikacja, ekstrakcja, routing, człowiek w pętli) 

W n8n z modelem językowym powtarzają się pięć wzorców budowania przepływów: wyszukiwanie odpowiedzi w Twojej własnej dokumentacji (RAG), klasyfikacja dokumentu, wyciąganie z niego konkretnych pól, kierowanie zapytania do właściwej gałęzi oraz zatwierdzanie przez człowieka przed wykonaniem. Każdy z nich rozwiązuje inny problem, ma inne węzły w n8n i inne ryzyko. W praktyce nie buduje się wszystkich naraz - zaczyna się od dwóch, a reszta dochodzi wtedy, kiedy pojawi się realna kolejka zadań.

Zanim wzorce: agent, łańcuch i węzeł

Zacznijmy od słów, które mieszają się w rozmowach, a w n8n oznaczają trzy różne rzeczy. Węzeł to pojedynczy krok na obrazku przepływu - pobranie pliku, wywołanie API, zapytanie do modelu. Łańcuch (chain) to szereg węzłów wykonanych po kolei, bez decyzji w trakcie. Agent to węzeł, który sam decyduje, które narzędzia użyć i w jakiej kolejności, iterując aż do odpowiedzi.

Jeśli dopiero zaczynasz, warto najpierw przeczytać czym jest n8n i dlaczego firmy automatyzują właśnie w nim - bo wzorce poniżej mają sens dopiero wtedy, kiedy wiesz, czym jest przepływ.

Różnica jest techniczna, ale ma realny skutek przy wdrożeniu. Dokumentacja bloga n8n opisuje to wprost: agenty używają promptów wielokrokowych, czyli łańcuchów specjalizowanych promptów (rozumowanie, wybór narzędzia), czego nie da się osiągnąć pojedynczym zapytaniem. Agent daje większą elastyczność i znacznie większe ryzyko, że pójdzie nie tam, gdzie chciałeś. Moja praktyka wygląda tak: zaczynam od łańcucha, dopiero kiedy łańcuch przestaje się mieścić w logice - przesiadam na agenta.

Warto wiedzieć, że sekcja „Build and manage agents" w dokumentacji n8n jest oznaczona jako Preview, a funkcja Assistant w chwili pisania tego tekstu też. To nie znaczy, że nie da się na tym polegać, ale warto wiedzieć, że API tych części może się jeszcze zmieniać.

Wzorzec 1 - RAG: model odpowiada z Twojej dokumentacji

RAG (Retrieval-Augmented Generation, czyli generowanie z odzyskanym kontekstem) rozwiązuje najczęstszy problem firm: model językowy nie zna Twoich cenników, umów i procedur. Zamiast uczyć go na nowo, dokładasz do zapytania fragmenty Twoich dokumentów. W n8n proces ma cztery etapy: import danych, podzielenie ich na fragmenty i zapisanie z wektorami, zapytanie do modelu z dołączonym kontekstem, odpowiedź.

Wektor, czyli embedding, to liczbowy odcisk sensu fragmentu tekstu. Dwa fragmenty o podobnym znaczeniu mają wektory blisko siebie, nawet jeśli nie mają wspólnych słów - i to pozwala znaleźć „regulację urlopową", gdy pytasz o wolne. Same wektory trzymane są w bazie wektorowej, a nie w zwykłej bazie z kolumnami.

W n8n do tego służy węzeł Vector Store, który ma dwie różne akcje: dodanie dokumentów do bazy oraz pobranie rankingu dokumentów pasujących do zapytania. Do obu podłącza się dwa węzły pomocnicze - Embeddings, który zamienia tekst na wektor, oraz Data Loader, który dostarcza treść do zapisania. Rozdzielenie tych ról ma praktyczny skutek: ten sam węzeł osadzeń obsługuje zarówno zapis, jak i odczyt, więc zmiana modelu osadzeń wymaga przebudowania obu stron.

n8n obsługuje Pinecone, Qdrant, Supabase, Weaviate, Milvus, Zep, MongoDB Atlas i Postgres z rozszerzeniem PGVector. Przy lokalnym Qdrant w Dockerze nie potrzebujesz nawet klucza API - wystarczy adres usługi, a panel administracyjny siedzi pod adresem panelu Qdrant. W przykładzie użyto modelu osadzeń o 1024 wymiarach wektora, a sama baza zwraca dokumenty rankingowane: wynik podobieństwa 1.0 oznacza trafienie dokładne, 0.0 zwraca de facto wszystko.

Przykładowy przepływ dzieli się na dwa. Pierwszy jest wsadowy i służy do zasilenia bazy: pobranie dokumentów ze źródła, węzeł Limit ograniczający liczbę pozycji (w testach wystarczą trzy), Split Out rozbijający listę na pojedyncze dokumenty, następnie Vector Store z akcją dodania do bazy, podłączony do węzła Embeddings i węzła Data Loader. W opisywanym przykładzie model osadzeń pochodzi z Ollamy i daje wektor o 1024 wymiarach, a sama kolekcja w Qdrant ustawiona jest na tę samą liczbę wymiarów - to muszą się zgadzać, inaczej baza odrzuci dane.

Drugi przepływ odpowiada na pytania. Wyzwalacz czatu przejmuje treść pytania, ten sam węzeł Vector Store pobiera ranking dokumentów, a węzeł osadzeń podłącza się ponownie, żeby zapytanie też zostało przetłumaczone na wektor. Liczbę zwracanych fragmentów ustawia się wprost w węźle bazy. Jeśli stawiasz to na Qdrant w Dockerze, panel administracyjny siedzi pod adresem panelu bazy, a sam n8n łączy się z nią po adresie usługi - bez klucza API, dopóki nie włączysz uwierzytelniania.

Co warto wiedzieć, zanim się w to wpakujesz. Sam n8n ostrzega, że RAG ogranicza halucynacje i poprawia trafność odpowiedzi, ale nie eliminuje wszystkich błędów. Standardowy RAG jest dokładny, lecz mało elastyczny - dlatego w bibliotece szablonów pojawia się wariant agentowy, w którym model sam decyduje, czy i kiedy sięgnąć do bazy. Druga sprawa to pliki: surowy PDF albo DOCX wrzucony do przepływu trafia do bazy jako dane binarne, a nie jako tekst, więc najpierw potrzebujesz konwersji. Przykład z Qdrant pokazuje, jak to zrobić w praktyce.

Warto też wiedzieć, że RAG jest tańszy od przemodelowywania modelu, gdy dochodzi nowa treść - faktycznie wystarczy podmienić zawartość bazy, zamiast uczyć model od nowa. Jeśli Twój proces jest właśnie taki, warto zacząć od niego.

Wzorzec 2 - klasyfikacja: jedno wejście, wiele wyjść

Klasyfikacja odpowiada na pytanie: co to jest i dokąd ma trafić? Nie wyciągamy jeszcze żadnych danych - najpierw ustalamy, z jakim typem dokumentu mamy do czynienia, i podejmujemy decyzję.

Tutaj muszę być uczciwy o jakości materiału. n8n nie prowadzi osobnej dokumentacji tego wzorca, a to, co krąży w internecie na ten temat, bywa pisane pod wyszukiwarkę i nie trzyma się faktów. To, co da się potwierdzić, to obecność wzorca w praktyce - w bibliotece szablonów n8n widziałem między innymi automatyzację rozwiązywania spraw obsługi klienta z klasyfikatorem tekstu, automatyczne sortowanie poczty w Outlook, organizowanie wiadomości w Gmailu na podstawie treści oraz system HR z klasyfikacją. Mechanizmem routingu jest węzeł Switch, który po rozpoznaniu typu przekierowuje dokument do właściwej gałęzi.

Miejsce tego wzorca w architekturze jest jednak jasne i to jest właśnie jego wartość. Klasyfikacja tanio porządkuje ruch wejściowy, a ekstrakcja działa dopiero potem, wiejąc, że wie, czego szukać. Przy dużej kolejce faktur to oznacza, że model dostaje do przeczytania tylko dokumenty właściwego typu.

Najczęstszy wdrożeniowy wariant to sortowanie przychodzącej poczty, więc jeśli zaczynasz od tego wzorca, automatyczne przetwarzanie maili pokazuje, jak wygląda ono w praktyce.

Gdzie warto postawić granicę między „zrobić samodzielnie" a „sprawdzić człowiek"? Tu nie ma domyślnych progów w n8n - to Ty je ustawiasz i to Ty je testujesz na własnych dokumentach, najlepiej na kilkudziesięciu oznaczonych egzemplarzach. Nie podawam tu konkretnych procentów, bo żaden z nich nie pochodzi z n8n. Praktyczna zasada jest taka: klasyfikacja, po której wynik wygląda wiarygodnie, idzie dalej automatycznie; reszta czeka na Ciebie. I to jest już wzorzec piąty, o którym niżej.

Wzorzec 3 - ekstrakcja: wyciągnij pola z dokumentu

Ekstrakcja zamienia tekst w dane strukturalne - daty, nazwiska, adresy, kwoty. W praktyce najczęściej chodzi o faktury, CV i formularze, bo tam wynik ma konkretnego odbiorcę: arkusz, system księgowy, baza.

Przepływ wygląda tak: plik trafia do przepływu, węzeł Switch sprawdza typ MIME i kieruje każdą ścieżkę inną drogą (PDF na jedną, DOCX na inną), węzeł HTTP Request wykonuje konwersję do tekstu, a węzeł Code dopisuje właściwe rozszerzenie do nazwy pliku, żeby dalsze węzły wiedziały, co mają z nim zrobić. Do zapytania do modelu dokładasz listę pól, których oczekujesz. W bibliotece szablonów n8n są gotowce w tym kształcie: procesor i walidator faktur z OCR-em, wyciąganie danych z faktury z maila do arkusza oraz parser faktur PDF.

Jeśli to ma być Twoje pierwsze zastosowanie, faktury są najlepiej udokumentowanym przypadkiem - cztery ścieżki automatyzacji faktur porównuje skan z OCR, API i KSeF, wraz z kosztem każdej.

Tu pojawia się pierwszy realny rachunek, nawet zanim doliczysz model. Osadzenia, czyli wektory, są naliczane dla każdego dokumentu, który wrzucasz do bazy, i przy dużej kolekcji ten koszt potrafi urosnąć niezauważalnie. Źródła, które opisują ten przepływ, zalecają dwa proste ruchy: przetwarzanie wsadowe zamiast pojedynczych plików oraz selektywne indeksowanie, czyli wysyłanie do bazy tylko tego, czego faktycznie będziesz potem szukał. Nie indeksuj wszystkiego, bo „może się przyda".

Druga sprawa to jakość odczytu. OCR na skanach bywa mylny, a dokumenty w języku polskim potrafią dawać nierówne wyniki przy formularzach o nietypowym układzie. Treść formatowana - tabele, wykresy, złożone układy - traci przy konwersji swoją strukturę. I trzecia, najczęściej pomijana: taki przepływ wysyła treść dokumentu na zewnątrz, do zewnętrznych usług, więc warto mieć to na liście przy rozmowie o danych firmowych.

Wzorzec 4 - routing: wybierz gałąź, zanim zaczniesz pracę

Routing odpowiada na pytanie: którą drogą i którym narzędziem pójść? To wzorzec, który w praktyce oszczędza najwięcej, bo decyzja zapada przed ciężką pracą, a nie po niej.

Najprostsza wersja jest statyczna: węzeł Switch rozgałęzia przepływ po rozpoznanym typie pliku, poMime, po obecności konkretnego pola, po języku. Do tego dokłada się węzły If, Merge i Edit Fields, żeby każda gałąź dostała ten sam format danych. To jest routing bez AI i w wielu przypadkach w zupełności wystarczy.

Trudniejsza wersja jest dynamiczna: decyzję podejmuje model. W bibliotece szablonów widziałem wariant z samodzielnie postawioną Ollamą i dynamicznym routerem modeli, orchestratora, który dobiera model do typu wejścia, oraz chatbot z długoterminową pamięcią i dynamicznym kierowaniem do narzędzi. To działa, ale kosztuje więcej niż Switch - i tu warto znać dwie przestrogi z bloga n8n. Po pierwsze, wieloetapowi agenci w praktyce zawodzą: cytowane tam badanie mówi wprost, że często nie kończą zadań niezawodnie. Po drugie, model, który sam decyduje, sam decyduje, że zapytanie jest trudne, więc warto mu skrócić pole wyboru, zamiast dawać dwadzieścia narzędzi do wyboru.

Jest jeszcze wersja pośrednia, bardzo przydatna w firmach z danymi: zamiast wsypywać surowe dane do kontekstu modelu, dajesz mu dostęp do bazy i każesz mu pisać zapytania SQL. W n8n powstaje wtedy agent SQL działający na lokalnym pliku SQLite, bez podłączania zewnętrznych źródeł. Autorzy jednego z takich przykładów ostrzegają wprost przed przeciążaniem okna kontekstu surowymi danymi i radzą przekazać agentowi schemat bazy, żeby nie tracił zasobów na każdym zapytaniu od nowa.

Praktyczna wskazówka z tego samego źródła: modelom dużym przypisuj zadania z dużym kontekstem, a do prostszych używaj mniejszych - jedna z recenzji zwraca uwagę, że w realnym użyciu duże okno kontekstowe sprawdza się przy zaledwie kilku stronach tekstu, mimo że deklarowany limit jest wielokrotnie większy. Praktyczne porównanie modeli pod kątem automatyzacji masz w osobnym tekście o tym, który wybrać do n8n.

Wzorzec 5 - człowiek w pętli: zatwierdzenie przed działaniem

To jest wzorzec, który decyduje o tym, czy cała reszta wjedzie na produkcję, czy zostanie w środowisku testowym. Chodzi o węzeł, który prosi człowieka o zgodę, zanim cokolwiek się stanie.

Konfiguracja w n8n wygląda następująco: otwierasz panel narzędzi w węźle agenta, w sekcji human review wybierasz kanał, a następnie dodajesz narzędzia, które mają wymagać zatwierdzenia. Do wyboru jest dziewięć kanałów - czat w n8n, Slack, Discord, Telegram, Microsoft Teams, Gmail, WhatsApp Business Cloud, Google Chat i Microsoft Outlook. Czyli jeśli Twoja Firma siedzi na Slacku albo w poczcie, zatwierdzenie przychodzi tam, gdzie i tak pracujesz, bez przeskakiwania do osobnego panelu.

Co dokładnie widzi osoba zatwierdzająca? Nazwę narzędzia oraz parametry, które model zaproponował. W instrukcji jest gotowy przykład komunikatu, który wstawiasz do promptu: informuje, że model chce użyć konkretnego narzędzia z konkretnymi parametrami, i wypisuje je w czytelnej formie. W praktyce to jest różnica między zatwierdzeniem, o którym da się decydować, a kliknięciem w ciemno.

Po zatwierdzeniu narzędzie wykonuje się z parametrami, które podał model. Po odrzuceniu akcja nie wykonuje się wcale i przepływ idzie dalej bez niej. Warto znać dwie rzeczy, które łatwo pominąć. Po pierwsze, instrukcja podkreśla, że kroki konfiguracji narzędzi i samego zatwierdzenia musisz opisać w system prompcie - inaczej model nie wie, że ten krok w ogóle istnieje. Po drugie, funkcja współpracuje z mechanizmem, w którym model sam podpowiada parametry narzędzia.

Są jeszcze dwie uwagi z dokumentacji, obie praktyczne. Jedna dotyczy zagnieżdżania: jeśli agent używa agenta, kroki zatwierdzenia w podagencie też wymagają poprawnego skonfigurowania - inaczej pętla przerwie się w miejscu, którego nie widzisz. Druga jest ogólna, ale trafnie oddaje realia: określenie „inteligencja" w kontekście AI jest trochę na wyrost, dlatego człowiek w pętli to nie ograniczenie, tylko zabezpieczenie.

Ile to kosztuje: co mówi cennik n8n

Tu muszę rozdzielić dwie rzeczy, bo mieszanie ich prowadzi do błędnych wyliczeń. n8n rozlicza wykonania przepływów - czyli liczbę uruchomień, niezależnie od tego, ile kroków się w środku wykona. I tu liczba jest przyjemna: płacisz za całe wykonanie, a nie za każdy krok osobno.

Plan	Cena miesięcznie (rocznie)	Wykonania	Uwagi
Starter	20 EUR	2,5 tys.	nieznana liczba kroków w wykonaniu
Pro	50 EUR	10 tys.	-
Business	667 EUR	40 tys.	tylko we własnej instalacji
Enterprise	według zamówienia	według zamówienia	ponad 200 równoległych wykonań

To są liczby z oficjalnego cennika n8n, podane w wariancie płatności rocznej, który daje 17 procent oszczędności. Po przeliczeniu na rok wychodzi 240 EUR za Startera, 600 EUR za Pro i 8004 EUR za Businessa. Próbę bezpłatną daje tysiąc wykonań, pięć równoległych wykonań i 180 sekund limitu na jedno wykonanie, na 14 dni. Nadgodziny w planie Business kosztują 4000 EUR za paczkę dodatkowych 300 tys. wykonań. Dane w chmurze n8n trzymane są na serwerach we Frankfurcie, w Unii Europejskiej.

A teraz rzecz, której nie znajdziesz w tym cenniku, a która najczęściej psuje budżet: liczby wykonań nie obejmują kosztu modelu językowego. n8n jest automatyzacją, model rozlicza się osobno, na koncie dostawcy API. Aktualnych cen tokeni nie podaję, bo zmieniają się częściej niż jakikolwiek artykuł na ten temat i zmyślona stawka jest tutaj najgorsza możliwa odpowiedź. Ten koszt policzę z Tobą przy konkretnym przepływie, znając liczbę uruchomień i długość wejścia.

Warto też odróżnić kredyty asystenta od kredytów modelu. Cennik wymienia kredyty asystenta (1600 miesięcznie w Starterze, do 9600 w Pro), ale to funkcja interfejsu, oznaczona jako Preview, i nie są to pieniądze, którymi zapłacisz za zapytania do modelu.

Jeśli rozważasz własną instalację zamiast chmury: wersja Community jest dostępna bez opłat abonamentowych, aktywacja licencji odpytuje serwer licencyjny raz dziennie, a telemetria jest domyślnie włączona i da się ją wyłączyć. Plan Business działa tylko we własnej instalacji, więc to nie jest alternatywa dla chmury, tylko inny model.

Jeśli nadal nie wiesz, czy n8n to właściwe miejsce dla Twojego procesu, porównanie n8n, Make i Zapier rozbija różnice w modelu rozliczeń, która właśnie tu ma znaczenie.

Co się psuje najczęściej

Zestaw rzeczy, które wracają przy wdrożeniach, a które warto mieć na liście kontrolnej:

• RAG zmniejsza liczbę halucynacji, ale ich nie likwiduje. Jeśli w bazie jest błędny dokument, model jest wiernie błędny.
• Surowe PDF i DOCX trafiają do bazy jako dane binarne, nie tekst. Bez konwersji RAG szuka w śmieciach.
• Pliki powyżej 25 MB mogą przekroczyć limit czasu wykonania.
• Tabele, wykresy i złożone układy tracą strukturę przy konwersji do tekstu.
• Osadzenia naliczane dla każdego dokumentu rosną wraz z biblioteką. Wsadowo i selektywnie.
• Wieloetapowi agenci zawodzą. Im więcej decyzji podejmuje model sam, tym trudniej o powtarzalny wynik.
• Agent z bazą danych potrafi przeciążyć okno kontekstu surowym materiałem. Podaj mu schemat.
• Kroki zatwierdzania trzeba opisać w system prompcie, inaczej pętla jest martwa.
• Klucze API trzymaj w magazynie poświadczeń n8n, a nie w treści przepływu.

Od czego zacząć we własnym procesie

Kolejność, która sprawdza się najczęściej, wynika z kosztu wdrożenia, nie z popularności. Zacznij od ekstrakcji albo klasyfikacji, bo oba wzorce dają efekt zmierzalny w godzinach: dokładna liczba poprawnie rozpoznanych dokumentów. Potem dołóż routing, żeby przepływ przestał ciągnąć każdy przypadek tą samą drogą. RAG wchodzi wtedy, gdy masz realną bazę dokumentów, do których ludzie pytają - wcześniej to koszt bez owoców. Człowiek w pętli dodajesz w dniu, w którym pierwszy przepływ zrobi coś, czego nie chcesz zrobić automatycznie.

Jest jeden przypadek, w którym nie warto budować żadnego z tych wzorców: pojedyncze zadanie, powtarzane kilka razy w miesiącu, gdzie ręczne zrobienie zajmuje mniej czasu niż napisanie i utrzymanie przepływu. Automatyzacja ma sens tam, gdzie powtarzalna robota zjada godziny co tydzień - i wtedy warto zacząć od mapowania procesów, żeby nie budować pięciu wzorców wokół zadania, które nie istnieje.

Jeśli chcesz przejść to krok po kroku na jednym konkretnym procesie, a nie na teorii, zacznij od pierwszej automatyzacji w n8n, a wątek modeli i ich kosztów rozwinięty jest w tekście o wyborze modelu do n8n.

Napisz do mnie, jeśli masz proces, w którym nie wiesz, który z tych pięciu wzorców pasuje. Odpowiadam zwykle tego samego dnia.