Ein eigenes LLM-Evaluations-Framework mit n8n bauen

Wer schon einmal eine Anwendung auf Basis generativer KI gebaut hat, kennt das Gefühl: Eine kleine Änderung am Prompt, ein Modellwechsel oder eine winzige Anpassung an einem Node verwandelt einen einwandfrei laufenden Workflow in ein unberechenbares Durcheinander. Anders als deterministischer Code bringen KI-Ausgaben ein Element von reizvollem — und zugleich frustrierendem — Chaos mit.

Genau deshalb kann man sich beim Ausrollen von KI nicht auf Bauchgefühl verlassen. Man braucht einen eigenen, wiederholbaren Testmechanismus: ein LLM-Evaluations-Framework.

Warum ein Evaluations-Framework?

Ein Evaluations-Framework verschiebt die Entwicklung vom Raten hin zu konkreten, messbaren Belegen. Warum das zählt:

Sicher ausrollen — Regressionen und Randfälle finden, bevor deine Nutzer sie finden.
Änderungen objektiv bewerten — wissen, ob eine Prompt-Anpassung die Ergebnisse wirklich verbessert oder nur den Schreibstil geändert hat.
Schneller experimentieren — radikale Änderungen in einer sicheren Sandbox testen, ohne die Produktion zu berühren.
Modellentscheidungen datenbasiert treffen — neue Modellversionen zügig auf Kosten, Tempo und Genauigkeit für genau deine Aufgabe vergleichen.

Warum n8n dafür?

n8n behandelt Evaluation als fortlaufende, in den Workflow eingebaute Praxis statt als einmaligen Benchmark. Die wichtigsten Vorteile:

Umsetzung auf der visuellen Fläche — keine eigenen Python-Skripte, keine externe Infrastruktur. Nodes ziehen, ablegen, verbinden.
Eigener Evaluationspfad — die Testlogik bleibt vollständig von den Produktions-Triggern getrennt.
Anpassbare Metriken — Korrektheit der Ausgabe, Sicherheit, Treffsicherheit bei Tool-Aufrufen, Tokenzahl, Laufzeit und mehr.

Zentrale Evaluationsmethoden

1. LLM-as-a-Judge

Der Goldstandard für offene Aufgaben wie Zusammenfassen oder kreatives Schreiben. Ein sehr leistungsfähiges Modell (etwa Claude Sonnet oder GPT-4) bewertet die Ausgabe eines kleineren Zielmodells. In n8n konfigurierst du das direkt im Evaluation-Node mit den eingebauten Metriken:

Korrektheit (KI-basiert) — bewertet auf einer Skala von 1–5, ob die Bedeutung der Antwort zur Referenz passt.
Nützlichkeit (KI-basiert) — bewertet auf 1–5, ob die Antwort die Frage tatsächlich adressiert.
Eigene Metriken — definiere eigene Kriterien, etwa „Hat die KI einen förmlichen Ton gehalten?".

2. RAG- und Agenten-Workflows bewerten

Wenn dein Workflow Retrieval-Augmented Generation oder Tool-Aufrufe nutzt, musst du das gesamte System bewerten. Die Metrik Tools Used prüft, ob der Agent das richtige Werkzeug ausgelöst hat, während Korrektheit (KI-basiert) bestätigt, dass der abgerufene Inhalt zur Referenz passt.

3. Quantitative und deterministische Metriken

Sie liefern eindeutige Datenpunkte als Ergänzung zu qualitativen Einschätzungen:

Tokenzahl — Kosten über die Zeit verfolgen.
Laufzeit — den Einfluss der Latenz auf die Nutzung im Blick behalten.
Kategorisierung — liefert 1 bei Treffer, 0 bei Fehlgriff. Ideal für Klassifikationsaufgaben.
Stringähnlichkeit — findet kleine Formatfehler, ohne semantisch richtige Antworten abzustrafen.

4. Sicherheits- und Richtlinienprüfung mit Guardrails

Mit dem Guardrails-Node validierst du Ein- und Ausgaben in Echtzeit — auf Toxizität, personenbezogene Daten oder eigene Inhaltsrichtlinien — und leitest Fehlfälle an Ausweich-Agenten oder eine menschliche Prüfung weiter.

Eine Sentiment-Analyse Schritt für Schritt bewerten

Um es konkret zu machen: So baust du ein Evaluations-Framework für einen Workflow, der eingehende E-Mails als positiv, neutral oder negativ einordnet.

Schritt 1: Referenzdaten mit Data Tables anlegen

Nutze die Data-Table-Funktion von n8n für deinen Testdatensatz. Ziele auf kniffelige Randfälle:

Ärger über den Wettbewerber — negative Sprache, aber positive Absicht (der Kunde will zu dir wechseln).
Sarkasmus — „Ich war begeistert, dass meine Pipeline sechs Stunden eingefroren war."
Gemischte Signale — ein kleines Lob, vergraben in einer großen Beschwerde.

Deine Tabelle braucht eine Spalte expected (Referenz) und eine Spalte result (wird bei Evaluationsläufen gefüllt).

Schritt 2: Den Evaluations-Workflow bauen

Hole alle Datensätze aus der Tabelle, iteriere darüber und gib jeden an deinen Sentiment-Analyse-Node. Mit einem Check-if-Evaluating-Node teilst du den Workflow in zwei Pfade:

Evaluationspfad — Ausgaben zurück in die Tabelle schreiben, Metriken berechnen.
Produktionspfad — E-Mails wie gewohnt an das passende Vertriebsteam leiten.

Das verhindert „Testverschmutzung", etwa dass dein Vertriebsteam versehentlich 50 Testfälle per Mail bekommt.

Schritt 3: Metriken berechnen

Nimm im Evaluation-Node die Option Set Metrics und wähle die eingebaute Metrik Categorization. Sie liefert 1 bei korrekter Klassifikation und 0 bei Abweichung — genau das, was du zur Genauigkeitsverfolgung brauchst.

💡 Precision, Recall und F1-Score lassen sich über Custom Metrics berechnen.

Schritt 4: Laufen lassen und vergleichen

Starte Evaluationen von der Fläche aus oder nutze den Evaluations-Tab für eine grafische Darstellung der Metriken über die Zeit. In einem echten Test mit drei Gemini-Modellen über 10 kniffelige Fälle:

Modell	Genauigkeit	Laufzeit
Gemini 3 Pro	100 %	~30 Sekunden
Gemini 2.5 Flash	100 %	~1,6 Sekunden
Gemini 2.5 Flash Lite	100 %	~650 ms

Alle drei bestanden — aber Flash Lite war 46-mal schneller als Pro. Genau das leistet ein Evaluations-Framework: Entscheidungen auf Basis von Daten statt Annahmen.

Bewährte Vorgehensweisen

Trenne Evaluation immer von der Produktionslogik mit dem Check-if-Evaluating-Node.
Pflege einen „Golden Dataset" mit echten Randfällen und vergangenen Fehlschlägen.
Kombiniere qualitative und quantitative Metriken — Tempo allein erzählt nicht die ganze Geschichte.
Isoliere eine Variable nach der anderen — wechsle nicht Modell und Prompt gleichzeitig.
Prüfe deinen LLM-Judge regelmäßig — er ist nicht unfehlbar, und sein System-Prompt braucht vielleicht Feinschliff.

Zum Abschluss

Mit einem Evaluations-Framework direkt in n8n wechselst du vom Raten zum Wissen. Du findest Regressionen, bevor sie produktiv werden, quantifizierst die Wirkung jeder Prompt-Änderung und vergleichst Modelle objektiv nach Kosten und Leistung.

Fang klein an, bau deinen ersten Testdatensatz — und viel Freude beim Automatisieren!