Obsługa błędów i ponawianie zapytań do API LLM w n8n: jak budować odporne automatyzacje AI

Projektując automatyzacje AI w n8n, często skupiam się na logice biznesowej i inżynierii promptów, jednak w środowisku produkcyjnym to obsługa błędów decyduje o żywotności systemu. API modeli językowych (LLM) zwraca błędy z różnych powodów – od limitów zapytań po awarie dostawcy. Jeśli przepływ w n8n nie przewiduje takiej sytuacji, cała automatyzacja po prostu się zatrzymuje. Wdrażam mechanizmy ponawiania (retry) i trasy awaryjne (fallback), aby przepływy AI działały niezawodnie nawet przy chwilowej niedostępności API.

Dlaczego zapytania do API LLM zawodzą

Zanim zbudujesz logikę naprawczą, musisz zrozumieć, co dokładnie może pójść nie tak. W przepływach n8n korzystających z OpenAI, Anthropic czy lokalnych modeli, najczęstsze problemy to:

• Błąd 429 (Rate Limit): Przekroczenie limitu żądań na minutę (RPM) lub tokenów na minutę (TPM). Występuje, gdy uruchamiasz równolegle wiele gałęzi przepływu lub gdy model przetwarza długie odpowiedzi.
• Błędy 5xx (Server Error): Dostawca API ma chwilowe problemy z infrastrukturą (502 Bad Gateway, 503 Service Unavailable).
• Błąd 400 (Context Length Exceeded): Wysyłany prompt wraz z historią przekracza okno kontekstowe modelu. To błąd logiczny, którego nie naprawi ponowienie – wymaga obcięcia danych wejściowych.
• Timeout: Złożone zadania (np. generowanie kodu) trwają dłużej niż domyślny limit czasu węzła HTTP Request lub dedykowanego konektora w n8n.

Wbudowane mechanizmy ponawiania w n8n

Najprostszą formą zabezpieczenia jest konfiguracja samego węzła. W ustawieniach każdego węzła w n8n (np. OpenAI, HTTP Request) znajduje się sekcja Settings.

1. Włącz Retry On Fail.
2. Ustaw Max Retries (zazwyczaj od 2 do 4 prób dla błędów 5xx i 429).
3. Zdefiniuj Wait Between Retries – w przypadku API LLM unikam agresywnego ponawiania. Ustawiam co najmniej 1000 ms lub więcej, aby dać dostawcy czas na zresetowanie limitu.

Wbudowany mechanizm ma jednak wady: ponawia zapytanie przy każdym błędzie, w tym przy błędach 400 (np. przekroczony kontekst), co jest bezcelowe i marnuje tokeny. Dlatego w zaawansowanych przepływach buduję logikę warunkową.

Selektywne ponawianie zapytań z użyciem węzła IF

Aby ponawiać tylko błędy infrastrukturalne, muszę przechwycić błąd i podjąć decyzję na podstawie kodu HTTP.

1. W ustawieniach węzła LLM włącz opcję Continue On Fail. Dzięki temu przepływ nie zostanie przerwany, a błąd trafi do danych wyjściowych węzła.
2. Dodaj węzeł IF po węźle LLM.
3. Sprawdzam, czy odpowiedź zawiera błąd: {{ $json.error !== undefined }}.
4. Dodaję drugi warunek sprawdzający kod statusu: {{ $json.error.status === 429 || $json.error.status === 503 }}.
5. Dla gałęzi True dodaję węzeł Wait (np. 5 sekund) i łączę go z powrotem do węzła LLM, tworząc pętlę.
6. Dla gałęzi False (np. błąd 400) kieruję przepływ do węzła zgłaszającego krytyczny błąd lub logującego problem.

Ważne ograniczenie: Pętle w n8n mogą wykonać się tylko określoną liczbę razy dla danego wykonania. Upewnij się, że logika pętli ma twardy limit iteracji (np. za pomocą zmiennej licznika w węźle Set/Code), aby uniknąć nieskończonego zapętlenia.

Trasy awaryjne (Fallback) dla modeli LLM

Gdy API głównego modelu (np. GPT-4) całkowicie przestaje odpowiadać, przepływ powinien przełączyć się na model zapasowy (np. GPT-3.5-turbo lub Claude Haiku). Projektuję to za pomocą węzła Switch lub zagnieżdżonych węzłów IF.

1. Przechwytuję błąd z węzła głównego (z włączonym Continue On Fail).
2. Jeśli wystąpił błąd, przepływ trafia do węzła LLM zapasowego.
3. Aby zachować spójność, węzeł zapasowy musi otrzymać ten sam payload (prompt i zmienne kontekstowe), co węzeł główny. Używam węzła Set przed rozwidleniem, aby przygotować ustandaryzowany obiekt z danymi wejściowymi.

Taka architektura zapewnia, że automatyzacja nie zatrzyma się z powodu awarii pojedynczego dostawcy chmurowego.

Przechwytywanie błędów na poziomie instancji (Error Trigger)

W n8n istnieje specjalny węzeł Error Trigger, który uruchamia się, gdy jakikolwiek inny przepływ zakończy się niepowodzeniem. Używam go do centralnego monitorowania stabilności automatyzacji AI.

1. Tworzę nowy przepływ z węzłem Error Trigger.
2. Wyciągam z niego dane o błędnym wykonaniu: nazwę przepływu, węzeł, który zwrócił błąd, oraz sam komunikat błędu.
3. Kieruję te dane do węzła powiadomień (np. Slack, Discord lub e-mail).

Dzięki temu od razu wiem, który przepływ AI przestał działać i czy powodem był np. wyczerpany limit na koncie OpenAI, czy błąd walidacji danych wejściowych.

Ograniczanie liczby żądań (Throttling) w n8n

Zamiast reagować na błąd 429, lepiej mu zapobiegać. W przepływach przetwarzających tablice danych (np. analiza wielu e-maili jednocześnie w węźle Split In Batches) wdrażam sztuczne opóźnienia.

• Węzeł Split In Batches domyślnie stara się działać szybko. Jeśli wewnątrz partii wywołuję API LLM, na końcu pętli dodaję węzeł Wait z czasem zależnym od limitu dostawcy (np. 2 sekundy dla limitu 30 RPM).
• W n8n można również wykorzystać ustawienia Rate Limit w konfiguracji poświadczeń dla konkretnego API, jeśli korzystasz z węzła HTTP Request, ograniczając liczbę wywołań na poziomie połączenia.

Walidacja odpowiedzi jako element obsługi błędów

Błędem jest nie tylko status 500, ale też odpowiedź 200, która nie spełnia wymagań biznesowych. Model LLM może zignorować instrukcję i zwrócić zwykły tekst zamiast wymaganego JSON. W przepływach AI walidacja to też obsługa błędu.

1. Po węźle LLM dodaję węzeł sprawdzający strukturę (np. sprawdzający obecność klucza w JSON lub używający JSON Schema validation w węźle Code).
2. Jeśli struktura jest niepoprawna, przepływ wraca do węzła LLM z dopisaną instrukcją korekcyjną (np. "Poprzednia odpowiedź nie była w formacie JSON. Zwróć wynik ściśle jako obiekt JSON").
3. Ustawiam maksymalnie 2 takie próby korekcyjne, aby uniknąć pętli, w której model ciągle generuje złą odpowiedź, generując koszty.

Checklist wdrożenia stabilnego przepływu AI w n8n

Przed wdrożeniem automatyzacji AI na produkcję, weryfikuję następujące elementy:

• Czy węzły LLM mają włączoną opcję Continue On Fail?
• Czy dla błędów 429 i 5xx zaimplementowano logikę ponowienia (retry) z opóźnieniem (Wait)?
• Czy błędy 400 (np. przekroczony kontekst) są wyodrębnione i nie podlegają bezsensownemu ponowieniu?
• Czy istnieje model zapasowy (Fallback) na wypadek awarii głównego dostawcy LLM?
• Czy w pętlach przetwarzających dane zastosowano węzeł Wait lub limity w Split In Batches, aby zapobiec błędom Rate Limit?
• Czy odpowiedź modelu jest walidowana pod kątem struktury (np. JSON mode) przed przekazaniem jej do dalszych systemów?
• Czy skonfigurowano globalny Error Trigger do powiadamiania o awariach przepływów?

Stabilność automatyzacji AI to kwestia architektury, a nie przypadku. Projektując przepływy w n8n, zawsze zakładam, że API modelu językowego zawiedzie w najmniej odpowiednim momencie. Jeśli potrzebujesz zbudować lub zrefaktorować automatyzacje tak, aby były odporne na awarie i błędy limitów, mogę pomóc w zaprojektowaniu architektury z odpowiednimi zabezpieczeniami i monitorowaniem.