Obsługa błędów i retry w przepływach AI w n8n: jak budować niezawodne automatyzacje z fallbackami

Przepływ AI w n8n bez obsługi błędów przerywa się przy pierwszym timeoutie API lub nieprawidłowej odpowiedzi modelu. Projektuję automatyzacje tak, aby każdy krytyczny węzeł miał zdefiniowaną ścieżkę awaryjną: retry z backoffiem, dedykowaną gałąź błędu lub fallback na inny model.

Gdzie przepływy AI tracą stabilność

Najczęstsze awarie nie wynikają z błędów w logice biznesowej, lecz z niestabilności zewnętrznych usług i nieprzewidywalnego zachowania modeli. W mojej pracy naprawiam regularnie przepływy, które przerywają się z powodu:

• Timeoutów API dostawców takich jak OpenAI czy Anthropic przy szczytowym obciążeniu serwerów.
• Odmowy przetworzenia promptu przez politykę bezpieczeństwa modelu, zwłaszcza gdy dane wejściowe zawierają nietypowe znaki lub długie cytaty.
• Błędów parsowania, gdy LLM zwróci JSON z komentarzem, markdownowym blokiem kodu lub dodatkowym tekstem poza strukturą.
• Pustych odpowiedzi lub odpowiedzi w nieoczekiwanym języku, gdy okno kontekstu zostanie przepełnione lub prompt jest nieprecyzyjny.
• Utraconego połączenia z lokalnym modelem w Ollamie lub LM Studio przy niestabilnej sieci lokalnej.

Znajomość tych punktów pozwala budować obronę na właściwym etapie, zamiast reagować na awarie ex post.

Retry z backoff – pierwsza linia obrony

W n8n każdy węzeł, w tym węzły AI i HTTP Request, posiada zakładkę Settings. Tam włączam opcję Retry On Fail z następującą konfiguracją:

• Liczba prób: 3.
• Czas oczekiwania między próbami: 1000 ms jako wartość początkowa.
• Strategia: Exponential Backoff – wybieram wykładniczy wzrost opóźnienia, ponieważ API LLM często zwraca błędy 502/503 przejściowe przy szczytowym obciążeniu.

Retry rozwiązuje większość problemów związanych z chwilową niedostępnością usługi, ale stosuję go selektywnie. Nie włączam automatycznego retry dla błędów autoryzacji (401) ani błędnych parametrów (400), ponieważ te nie znikną po ponownej próbie. W takich przypadkach natychmiast kieruję przepływ do gałęzi błędu, aby nie marnować tokenów i nie opóźniać diagnostyki.

Gałęzie błędów i izolowanie awarii

Domyślnie błąd w jednym węźle zatrzymuje cały workflow. W automatyzacjach AI, gdzie przetwarzam partie danych, jest to niedopuszczalne. W ustawieniach węzła wybieram opcję On Error → Continue (using error output). To tworzy drugie wyjście z obiektem błędu, który mogę dalej przetworzyć.

Przykład praktyczny: W przepływie tagującym 200 zgłoszeń klientów węzeł OpenAI może odmówić przetworzenia jednego z nich. Zamiast przerywać przepływ, gałąź błędu zapisuje ID zgłoszenia i treść błędu do osobnej tabeli (np. w Google Sheets lub bazie PostgreSQL). Główna pętla kontynuuje pracę z pozostałymi rekordami. Po zakończeniu widzę listę elementów do ręcznej weryfikacji, a nie niekompletny wynik.

Decyzja, czy przepływ ma się zatrzymać, czy kontynuować, zależy od kontekstu biznesowego. Dla procesu generowania umowy dla klienta wybieram zatrzymanie i alert. Dla masowego tagowania treści wybieram kontynuację z oznaczeniem błędnych rekordów.

Fallbacki między modelami i dostawcami

Gdy główny model (np. GPT-4) zawodzi z powodu timeoutu lub limitu zapytań, przepływ może automatycznie przełączyć się na model zapasowy. Implementuję to za pomocą węzła IF umieszczonego bezpośrednio po węźle LLM.

Scenariusz: Węzeł OpenAI zwraca błąd lub pusty wynik. Węzeł IF sprawdza, czy istnieje pole choices[0].message.content. Jeśli nie, przepływ przechodzi do gałęzi false, gdzie uruchamiam drugi węzeł LLM – zazwyczaj z lżejszym modelem, takim jak GPT-3.5-turbo lub Claude Haiku, albo z lokalnym modelem przez Ollamę.

Kluczowe ograniczenie: model fallback musi obsługiwać ten sam format promptu i zwracać dane w strukturze zgodnej z kolejnymi węzłami. Jeśli główny model wymaga specyficznego system promptu, a fallback go nie rozumie, parsowanie w kolejnym kroku się wysypie. Dlatego przed wdrożeniem fallbacku testuję oba modele z identycznym payloadem.

Walidacja odpowiedzi jako mechanizm obronny

Nawet gdy API zwróci odpowiedź HTTP 200, zawartość może być bezwartościowa. LLM może pominąć wymagane pole, zwrócić tekst zamiast JSON lub wygenerować wartość spoza dozwolonej listy.

Przed przekazaniem danych do systemu docelowego (CRM, baza danych, panel klienta) umieszczam węzeł Code lub Set z regułami walidacji:

1. Czy odpowiedź zawiera wszystkie wymagane klucze?
2. Czy wartości mieszczą się w zdefiniowanych zakresach lub enumeracjach?
3. Czy typ danych jest zgodny z oczekiwaniami (string, number, boolean)?

Jeśli walidacja nie przejdzie, przepływ nie kontynuuje przetwarzania, tylko kieruje rekord do kolejki ręcznej lub ponawia zapytanie z poprawionym promptem. To eliminuje ryzyko wprowadzenia śmieciowych danych do systemów produkcyjnych.

Lista kontrolna niezawodnego przepływu AI

Przy wdrażaniu lub audycie automatyzacji AI w n8n sprawdzam następujące elementy:

1. Retry z backoff: Każdy węzeł zewnętrznego API ma włączone co najmniej 2 próby z opóźnieniem wykładniczym.
2. Gałąź błędu: Krytyczne węzły posiadają skonfigurowane wyjście błędu z zapisem do logu i opcjonalnym alertem (e-mail, Slack, webhook).
3. Kontynuacja przy batchu: Przepływy wsadowe mają włączoną kontynuację przy błędzie z oznaczeniem rekordów do ponownego przetworzenia.
4. Walidacja struktury: Odpowiedź LLM jest weryfikowana pod kątem obecności wymaganych pól przed zapisem do bazy.
5. Fallback modelu: Procesy o wysokiej dostępności mają zdefiniowany model zapasowy z przetestowanym formatem promptu.
6. Timeouty dostosowane do środowiska: Lokalne modele (Ollama, LM Studio) otrzymują dłuższy timeout niż API chmurowe.
7. Test awaryjny: Raz na kwartał symuluję awarię (np. celowo uszkadzam klucz API), aby zweryfikować, czy gałęzie błędów i alerty działają zgodnie z projektem.

Jeśli Twoje przepływy AI w n8n zatrzymują się na pierwszym błędzie API lub zwracają nieprzewidywalne wyniki, pomogę zaprojektować architekturę z retry, fallbackami i walidacją odpowiedzi. Tworzę dedykowane automatyzacje, które działają niezawodnie również wtedy, gdy infrastruktura zewnętrzna odmawia posłuszeństwa.