Routing zapytań do modeli LLM w n8n: jak klasyfikować intencje i dobierać modele AI

Projektując zaawansowane automatyzacje AI, często opieram się na pojedynczym, najmocniejszym modelu LLM do obsługi wszystkich zadań. To najprostsze podejście, ale kosztowne i nieefektywne. Routing zapytań pozwala mi kierować proste pytania do szybkich i tanich modeli, a skomplikowane analizy do potężnych, droższych systemów. W n8n wdrażam ten mechanizm za pomocą wstępnej klasyfikacji intencji i węzła Switch, co daje pełną kontrolę nad wydatkami na API i jakością odpowiedzi.

Dlaczego routing modeli LLM w n8n ma znaczenie

W przepływach, które obsługują różnorodne żądania – od prostych pytań o status zamówienia po generowanie złożonych raportów finansowych – użycie jednego modelu (np. GPT-4o) do każdego zapytania generuje niepotrzebne koszty i wydłuża czas odpowiedzi. Proste interakcje nie wymagają takiego samego kontekstu i mocy obliczeniowej jak zadania analityczne. Routing rozwiązuje ten problem, dynamicznie dobierając model do zidentyfikowanej kategorii zadania. Zamiast płacić za najdroższy model za każdym razem, płacę za niego tylko wtedy, gdy jest to niezbędne.

Klasyfikacja intencji jako fundament routingu

Zanim zapytanie trafi do docelowego modelu, muszę wiedzieć, czego dotyczy. W n8n realizuję to poprzez węzeł klasyfikujący – wywołuję tani i szybki model LLM (np. GPT-4o-mini lub Claude 3 Haiku) z promptem zwracającym jedynie kategorię intencji. Koszt takiego wstępnego wywołania jest marginalny w porównaniu do oszczędności na głównych modelach.

Jak zbudować klasyfikator w n8n

1. Węzeł AI Chain lub HTTP Request: Wysyłam oryginalny tekst użytkownika do taniego modelu. Używam niskich wartości max_tokens, ponieważ oczekuję tylko krótkiej etykiety.
2. Prompt systemowy: Definiuję sztywne reguły zwracania odpowiedzi, np. w formacie JSON {"intent": "faq" | "analysis" | "code" | "other"}. Wymuszam to, stosując techniki opisane we wcześniejszych artykułach o JSON mode i walidacji schematu. Prompt musi jasno określać dostępne kategorie i zabraniać modelowi dodawania własnych. Przykładowy prompt systemowy dla klasyfikatora może wyglądać tak: „Jesteś klasyfikatorem intencji. Przeczytaj wiadomość użytkownika i przypisz jej jedną z kategorii: faq, code, analysis, other. Zwróć wynik wyłącznie w formacie JSON z kluczem intent, np. {"intent": "faq"}." Taki prompt minimalizuje ryzyko halucynacji i skraca czas odpowiedzi.
3. Walidacja: Sprawdzam, czy odpowiedź z klasyfikatora zawiera oczekiwany klucz i wartość z predefiniowanej listy. Jeśli model zwróci nieznaną intencję lub uszkodzony JSON, kieruję zapytanie do domyślnej, bezpiecznej ścieżki.

Projektowanie przepływu routingu w n8n

Po uzyskaniu intencji przepływ musi podjąć decyzję o dalszej drodze. W n8n używam do tego węzła Switch, który pozwala na rozgałęzienie logiki na wiele równoległych ścieżek.

Switch node vs. wyrażenia warunkowe

Węzeł Switch jest czytelniejszy przy wielu ścieżkach routingu. Konfiguruję go tak, aby analizował wyjście z klasyfikatora (np. {{$json.intent}}). W opcjach węzła ustawiam tryb 'Route to matching output'. Dodaję cztery reguły:

• Reguła 1 (faq): Kieruje do węzła z tanim modelem i bazą wiedzy RAG. Odpowiedzi na pytania z bazy wiedzy rzadko wymagają zaawansowanego wnioskowania.
• Reguła 2 (code): Kieruje do modelu wyspecjalizowanego w programowaniu (np. Claude 3.5 Sonnet). Tu jakość kodu jest ważniejsza niż koszt.
• Reguła 3 (analysis): Kieruje do modelu analitycznego (np. GPT-4o), który ma większe możliwości wnioskowania logicznego.
• Fallback: Ścieżka domyślna dla niejasnych intencji, korzystająca z modelu o zbalansowanych parametrach, aby uniknąć katastrofalnych błędów w odpowiedzi. Przechwytuje ona wszystko inne, w tym 'other' i błędy parsowania.

Każda reguła prowadzi do osobnego węzła AI Chain z innym modelem i innym promptem systemowym.

Routing na podstawie długości kontekstu

Oprócz intencji, routing często opieram na długości tekstu wejściowego. Jeśli dokument przekracza okno kontekstowe tańszego modelu, nie ma sensu wysyłać go tam i obsługiwać błędu. W n8n, przed klasyfikatorem, dodaję węzeł sprawdzający liczbę znaków lub tokenów (np. używając prostego wyrażenia {{$json.text.length}}). Jeśli tekst jest krótki, idzie do modelu szybkiego. Jeśli długi, od razu trafia do modelu z dużym oknem kontekstowym, omijając zbędne kroki.

Kiedy kierować zadania do różnych modeli

Decyzję o podziale opieram na analizie procesu biznesowego. Tworzę przepływy z podziałem ról, gdy:

• Koszty API rosną z powodu dużej liczby prostych zapytań, które mogą obsłużyć modele z niższej półki cenowej.
• Różne zadania wymagają zupełnie innych silników (np. jeden model świetnie generuje kod, inny lepiej analizuje dokumenty prawne).
• Potrzebuję zachować niskie opóźnienia (latency) dla prostych interakcji czatowych, a opóźnienia modeli ciężkich są akceptowalne tylko dla zadań w tle.

Testowanie logiki routingu

Błędy w klasyfikacji mogą prowadzić do sytuacji, w której trudne zadanie trafia do słabego modelu, generując bezużyteczne odpowiedzi. Dlatego testuję routing na zestawie przykładowych zapytań. W n8n korzystam z węzła Manual Trigger, do którego podpinam tablicę testowych wiadomości. Następnie sprawdzam, czy każda z nich trafiła do odpowiedniego wyjścia w węźle Switch. Jeśli model często myli intencje, modyfikuję prompt klasyfikatora lub dodaję nowe przykłady do jego instrukcji.

Checklist wdrożenia routingu LLM

Przed uruchomieniem zróżnicowanego przepływu sprawdzam:

• Czy lista intencji jest wyczerpująca i wzajemnie się wyklucza?
• Czy prompt klasyfikatora wymusza konkretny format odpowiedzi (np. JSON)?
• Czy węzeł Switch posiada ścieżkę fallback na wypadek błędnej klasyfikacji?
• Czy modele przypisane do każdej intencji mają odpowiednio ustawione parametry (temperatura, max tokens)?
• Czy zaimplementowałem monitoring kosztów, aby zweryfikować oszczędności po wdrożeniu routingu?
• Czy przepływ prawidłowo obsługuje błędy z każdego z modeli docelowych, stosując ponawianie zapytań?

Gdy przepływy AI stają się złożone, optymalizacja kosztów i doboru modeli bywa wyzwaniem. Pomagam projektować i wdrażać architektury automatyzacji w n8n, dopasowując rozwiązania do specyfiki procesów firmy.