Mit n8n Evaluations machst du deine KI-Workflows messbar, bevor sie live gehen. Du baust ein Dataset mit Ground Truth, lässt deinen Workflow dagegen laufen und siehst im Dashboard, ob sich Prompts, Modelle oder OCR-Setups wirklich verbessern. Statt Änderungen im Blindflug zu deployen.
Was erwartet euch?
Einleitung: Warum du Evaluations brauchst
Kennst du das Gefühl? Du hast stundenlang an deinem KI-Workflow in n8n gebastelt, alles scheint perfekt zu laufen und dann beschwert sich die Fachabteilung, dass Rechnungen im falschen Ordner landen oder dein RAG-System plötzlich Unsinn ausgibt. Das Problem: Du merkst erst, dass etwas schiefläuft, wenn der Schaden schon angerichtet ist. Und mal ehrlich, wie oft hast du schon einen Prompt „verbessert“, nur um später festzustellen, dass die Qualität eigentlich schlechter geworden ist? Ohne objektive Messungen tappst du im Dunkeln. Jede Änderung am Workflow ist ein Glücksspiel. Und wenn die Fehlerquote steigt, merkst du es oft erst Wochen später, wenn sich der Ärger bei den Nutzern aufgestaut hat. Die gute Nachricht: Mit n8n Evaluations bekommst du ein Testing-Framework, das deine KI-Ergebnisse automatisch gegen definierte Musterlösungen prüft. Du siehst sofort, ob dein Workflow besser oder schlechter wird, bevor du ihn live schaltest. In diesem Guide zeige ich dir Schritt für Schritt, wie du n8n Evaluations für Rechnungsklassifizierung, RAG-Systeme und OCR-Extraktion nutzt. Inklusive Praxisbeispiel, Dashboard-Auswertung und den Metriken, die wirklich funktionieren.Was sind n8n Evaluations und warum brauchst du sie?
n8n Evaluations ist ein integriertes Testing-Framework für KI-Workflows. Es funktioniert nach einem simplen Prinzip:- Du erstellst ein Test-Dataset mit Beispieleingaben und den erwarteten Ergebnissen (Ground Truth).
- Du lässt deinen Workflow gegen dieses Dataset laufen.
- n8n vergleicht die KI-Ausgabe mit deiner Musterlösung und berechnet einen Score.
- Du siehst im Dashboard, ob dein Workflow gut oder schlecht performed.
💡 Sidenote: n8n Evaluations ist kein Ersatz für Live-Monitoring, sondern ein Pre-Deployment-Test. Du testest Änderungen, bevor sie produktiv gehen.
Für welche Use Cases eignen sich n8n Evaluations?
Evaluations sind besonders wertvoll, wenn du:- Dokumente klassifizierst (Rechnung vs. Lieferschein vs. Angebot)
- RAG-Systeme betreibst (z.B. Techniker-Handbücher oder Wissensdatenbanken)
- Daten aus PDFs extrahierst (Produktinformationen, Rechnungsdaten, Formulare)
- LLM-Prompts optimierst und die Auswirkungen messen willst
- Verschiedene KI-Modelle vergleichst (GPT-4 vs. Claude vs. Llama)
- OCR-Lösungen testest (mit/ohne Vorverarbeitung)
Stärken und Schwächen von n8n Evaluations
✅ Stärken
Nahtlose Integration: Deine Test-Sets laufen direkt im bestehenden Workflow. Du musst keine Daten exportieren und keine externe Testing-Pipeline aufbauen – alles bleibt in deiner vertrauten n8n-Umgebung. Flexible Metriken: n8n bietet Standard-Metriken wie Accuracy und String Similarity – aber das Beste ist: Du kannst eigene Metriken bauen, zum Beispiel mit einem zusätzlichen LLM als „Prüfer“. Ideal für A/B-Tests: Du willst wissen, ob dein neuer Prompt besser ist? Ob ein anderes Modell einen Vorteil bringt? Oder ob OCR-Vorverarbeitung einen Unterschied macht? Mit Evaluations siehst du das auf einen Blick. Visuelles Dashboard: Die Qualitätsentwicklung deiner Workflows wird über mehrere Testläufe hinweg visualisiert. Du siehst sofort, welcher Run besser war – inkl. Token-Verbrauch für die Kostenkontrolle.⚠️ Schwächen
Manuelle Arbeit nötig: Testfälle und Metriken fallen nicht vom Himmel. Du musst sie selbst definieren: 10–20 Beispiele pro Use Case manuell erstellen und pflegen. String Similarity ist (meist) nutzlos: Diese Standard-Metrik vergleicht Zeichenketten. KI formuliert aber jedes Mal etwas anders. Selbst wenn der Inhalt perfekt ist, bekommst du schlechte Scores.⚠️ Wichtig: Verlass dich nicht auf String Similarity, wenn dein Use Case Freitext erzeugt. Gerade bei RAG-Systemen und offenen Antworten ist diese Metrik oft irreführend.
Praxis-Beispiel 1: Rechnungsklassifizierung & Routing
Starten wir mit dem einfachsten Use Case: Du willst Dokumente automatisch in die richtige Kategorie sortieren.Das Szenario
Eine Firma bekommt täglich E-Mails mit Anhängen: Rechnungen, Lieferscheine, Angebote, Produktanfragen. Ein KI-Workflow soll diese automatisch klassifizieren und ins richtige Postfach routen. Die Herausforderung: Wie stellst du sicher, dass keine Rechnung im Spam landet oder ein Lieferschein als Rechnung verbucht wird?Die Lösung: Correctness-Metrik
Für Klassifizierung ist die Correctness-Metrik ideal. Sie misst binär:- Hat die KI das richtige Label erkannt? ✅ Score = 1.0
- Hat die KI falsch klassifiziert? ❌ Score = 0.0
| Input | Expected Category |
|---|---|
| „Hiermit senden wir Ihnen Rechnung Nr. 2024-001…“ | rechnung |
| „Anbei erhalten Sie den Lieferschein für Ihre Bestellung…“ | lieferschein |
| „Wir interessieren uns für Ihr Produkt XY…“ | produktanfrage |
- Gesamtgenauigkeit – z.B. 95 % korrekt klassifiziert
- Fehlerhafte Fälle – welche Test-Cases fehlschlagen
- Trend – wird es besser oder schlechter?
💡 Pro-Tipp: Starte mit ca. 10 Beispielen. Wenn du Fehler findest, füge genau diese Problemfälle zu deinem Dataset hinzu. So wird dein Test mit der Zeit immer robuster.
Praxis-Beispiel 2: RAG-System für Techniker-Handbücher
Jetzt wird’s interessanter. RAG-Systeme (Retrieval-Augmented Generation) geben freie Antworten zurück. Keine festen Labels, sondern Fließtext.Das Szenario
Deine Firma hat alle Techniker-Handbücher in einem RAG-System gespeichert. Techniker stellen Fragen wie: „Wie starte ich Gerät XY neu?“. Die KI soll antworten – mit den Schritten aus dem Handbuch. Die Herausforderung: Die Antwort muss inhaltlich korrekt sein, aber die KI formuliert jedes Mal anders. String Similarity versagt hier komplett.Die Lösung: Key-Facts-Metrik mit LLM als Prüfer
Du baust eine Custom-Metrik, die nicht die Formulierung vergleicht, sondern die kritischen Fakten prüft. So funktioniert’s:- Die KI generiert eine Antwort.
- Ein zweites LLM (z.B. GPT-4) prüft: „Enthält die Antwort die Schritte ‘Strom aus’, ‘3 Sek. warten’, ‘Neustart’?“.
- Das Prüfer-LLM gibt einen Score zurück: 1.0 (alle Facts enthalten) bis 0.0 (kritische Infos fehlen).
Prüfe, ob die folgende Antwort alle kritischen Schritte enthält:
- Strom ausschalten
- 3 Sekunden warten
- Gerät neu starten
Antwort: {{ $json.actual_output }}
Gib einen Score zwischen 0.0 und 1.0 zurück.
1.0 = alle Schritte vorhanden
0.0 = kritische Schritte fehlen
Diese Methode ist deutlich aussagekräftiger als String-Vergleiche. Du misst nicht die Formulierung, sondern den Informationsgehalt.
💡 Kostenfaktor: Ja, du rufst pro Test-Case ein zweites LLM auf. Aber die Kosten sind minimal im Vergleich zum Schaden, den fehlerhafte Antworten anrichten können.
Praxis-Beispiel 3: Datenextraktion aus Produkt-PDFs (OCR-Vergleich)
Der komplexeste Use Case: Du willst strukturierte Daten aus PDFs extrahieren – und verschiedene Ansätze vergleichen.Das Szenario
Deine Firma bekommt Produktdatenblätter als PDF. Du willst automatisch extrahieren:- Produktname
- Artikelnummer
- Preis
- Technische Spezifikationen (Liste)
Die Lösung: Field-basierte Accuracy
Du baust eine Metrik, die zwischen verschiedenen Datentypen unterscheidet:- Harte Daten (Exact Match): Artikelnummer, Preis – müssen 100 % stimmen.
- Listen (Vollständigkeit): alle relevanten Spezifikationspunkte müssen enthalten sein.
- Soft Match: Produktname – kleine Abweichungen sind tolerierbar.
| Test-Run | Modell | OCR | Field Accuracy |
|---|---|---|---|
| #1 | GPT-4 | Nein | 82 % |
| #2 | GPT-4 | Ja (Tesseract) | 94 % |
| #3 | Claude 3.5 | Ja (Tesseract) | 91 % |
⚠️ Wichtig: Teste explizit auch mit schlechter Scan-Qualität. Dein Modell muss im echten Leben funktionieren, nicht nur bei perfekten PDFs.
Step-by-Step: So baust du eine Evaluation in n8n
Genug Theorie. Jetzt bauen wir gemeinsam eine Evaluation – am Beispiel einer E-Mail-Klassifizierung.Schritt 1: Dataset erstellen
Du brauchst eine Tabelle mit Test-Daten. Das geht entweder in Google Sheets oder als n8n Datatable.
input– der E-Mail-Text, den die KI klassifizieren sollexpected_category– die korrekte Kategorie (Ground Truth)expected_output– optional die erwartete Antwortactual_category– wird später vom Workflow gefülltactual_output– wird später vom Workflow gefüllt
💡 Zeitspar-Tipp: Nutze echte E-Mails aus deinem Posteingang. Sie sind deutlich realistischer als ausgedachte Beispiele.
Schritt 2: Evaluation-Trigger einbauen
Öffne deinen bestehenden Workflow und füge einen „On evaluation start“-Trigger hinzu.
- lädt Zeile für Zeile aus deinem Dataset,
- schickt jede Input-Zeile durch deinen Workflow,
- läuft parallel zu deinem normalen Start-Trigger (z.B. „On incoming email“).
Schritt 3: Daten normalisieren (wichtig!)
Deine KI sollte im Test- und Live-Betrieb möglichst dieselbe Datenstruktur erhalten. Beispiel-Code für einen JavaScript-Node:// Normalize Mail oder Testing Data
const isEvaluation = $input.item.json.source === 'evaluation';
if (isEvaluation) {
// Daten kommen aus dem Test-Dataset
return {
emailText: $input.item.json.input,
expectedCategory: $input.item.json.expected_category
};
} else {
// Daten kommen von einer echten E-Mail
return {
emailText: $input.item.json.body,
expectedCategory: null
};
}
So stellst du sicher, dass deine KI immer denselben Schlüssel emailText nutzt – egal, ob die Daten aus dem Dataset oder aus dem Live-System kommen.
Schritt 4: Check-if-Evaluating Node (optional, aber empfohlen)
Du willst nicht, dass dein Testlauf echte E-Mails verschickt oder externe APIs aufruft. Baue einen IF-Node ein und prüfe, ob du im Evaluationsmodus bist:Condition: {{ $execution.mode }} === 'evaluation'
True-Branch: gehe direkt zur Metrik-Messung
False-Branch: führe die normalen Actions aus (E-Mail senden, Outlook-Update, etc.)
So bleiben deine Tests isoliert und verursachen keine unerwünschten Änderungen in Zielsystemen.
Schritt 5: Metrik-Nodes einbauen
Am Ende deines Workflows fügst du die Metrik-Nodes ein. Für Klassifizierung:- AI Evaluation-Node hinzufügen,
- Metrik „Correctness“ wählen,
actual_categorymitexpected_categoryvergleichen.
- zweiten LLM-Node als Prüfer einbauen,
- Prompt schreiben, der die Antwort bewertet,
- Score (0.0–1.0) zurückgeben und als Custom-Metrik speichern.
Schritt 6: Testlauf starten
Gehe in n8n zum Evaluations-Tab deines Workflows und klicke auf „Run Evaluation“. n8n läuft jetzt durch alle Zeilen deines Datasets und sammelt die Scores. Nach dem Durchlauf siehst du:- aggregierte Scores pro Metrik,
- einzelne Test-Cases mit Pass/Fail-Status,
- Token-Verbrauch und geschätzte Kosten.
💡 Best Practice: Mach einen Baseline-Run, bevor du Änderungen am Workflow vornimmst. So weißt du, ob du dich verbesserst oder verschlechterst.
Das Evaluation Dashboard: Dein KI-Qualitäts-Cockpit
Das Dashboard ist deine zentrale Oberfläche für das Management und Controlling der KI-Qualität.
Was zeigt das Dashboard?
1. Score-Verlauf:
Eine Linie pro Metrik. Du siehst sofort, ob Run #5 besser war als Run #4.
Beispiel: Die Categorization-Accuracy steigt von 0,75 (Run #1) auf 1,0 (Run #4) – dein optimierter Prompt klassifiziert jetzt perfekt.
2. Token-Verbrauch:
Das Dashboard zeigt promptTokens und totalTokens pro Run. Du erkennst sofort, wenn eine Prompt-Änderung die Kosten explodieren lässt.
3. Fehlerhafte Test-Cases:
Markierungen zeigen, welche Inputs fehlschlagen. So kannst du gezielt nachbessern.
Mini-Beispiel aus der Praxis
| Run | Änderung | Categorization Score | String Similarity | Tokens |
|---|---|---|---|---|
| #1 | Baseline (Standard-Prompt) | 0,75 | 0,42 | 12.500 |
| #2 | Prompt mit Beispielen erweitert | 0,85 | 0,38 | 18.200 |
| #3 | Few-Shot Learning hinzugefügt | 0,95 | 0,41 | 20.100 |
| #4 | Kategorien klarer definiert | 1,0 | 0,39 | 19.800 |
Die Erkenntnis:
- Die Klassifizierung ist ab Run #4 perfekt (Score 1,0).
- String Similarity bleibt niedrig – ein guter Beleg dafür, dass diese Metrik für Freitext wenig taugt.
- Der Token-Verbrauch ist gestiegen, aber vertretbar für die bessere Qualität.
⚠️ Achtung: Verlasse dich nie allein auf eine Metrik. Kombiniere z.B. Correctness + Custom Key Facts für ein vollständigeres Bild.
Die richtige Metrik wählen
Die Wahl der passenden Metriken entscheidet darüber, ob deine Evaluation wirklich aussagekräftig ist. Statt viel Fließtext hier eine kompakte Übersicht:
| Metrik | Gut für | Weniger geeignet für |
|---|---|---|
| Correctness / Exact Match |
|
|
| String Similarity (eher vorsichtig nutzen) |
|
|
| Custom LLM-basierte Metriken |
|
|
| Field-basierte Accuracy |
|
|
💡 Faustregel: Je strukturierter der Output, desto einfacher die Metrik. Je offener die Antwort, desto eher brauchst du eine LLM-basierte Prüfung.
Häufige Fehler und wie du sie vermeidest
❌ Fehler 1: Zu wenig Test-Cases
„Ich teste mal mit 3 Beispielen.“
Nein. 3 Beispiele sagen dir nichts über die echte Performance. Ziel: mindestens 10, besser 20–30 realistische Fälle.
❌ Fehler 2: Nur „Happy Path“ testen
Dein Dataset sollte auch schwierige Fälle enthalten:
- mehrdeutige Inputs,
- schlechte Scan-Qualität,
- Tippfehler,
- unvollständige Informationen.
❌ Fehler 3: Blind auf String Similarity vertrauen
Ein niedriger Similarity-Score bedeutet nicht automatisch schlechte Inhalte. Schau dir die echten Antworten an – häufig sind sie fachlich korrekt, nur anders formuliert.
❌ Fehler 4: Dataset nicht pflegen
Dein Dataset ist lebendig. Immer wenn du neue Fehler in der Praxis findest, füge sie als Test-Cases hinzu.
❌ Fehler 5: Keine Baseline dokumentieren
Ohne Baseline weißt du später nicht mehr, ob deine letzte Änderung wirklich eine Verbesserung war.
⚠️ Pro-Tipp: Versioniere deine Datasets. Wenn du Zeilen hinzufügst oder änderst, speichere vorher eine Kopie. So kannst du Runs besser vergleichen.
Von der Messung zur Optimierung
Evaluation ist kein Einmal-Event, sondern ein kontinuierlicher Verbesserungszyklus:
Der Optimization Loop:
- Baseline Run: Status quo messen.
- Hypothese bilden: „Wenn ich X ändere, wird Y besser.“
- Änderung durchführen: Prompt, Modell oder Parameter anpassen.
- Evaluation Run: gleichen Test-Datensatz erneut durchlaufen lassen.
- Vergleichen: sind die Scores besser oder schlechter?
- Entscheiden: Änderung behalten oder verwerfen.
- Repeat: zurück zu Schritt 2.
Typische Optimierungshebel:
- Bei schlechtem Categorization-Score: Kategorien klarer definieren, Few-Shot-Beispiele ergänzen, mehr Kontext liefern.
- Bei schlechter Extraction-Accuracy: OCR-Vorverarbeitung testen, anderes Modell ausprobieren, Output-Format strenger definieren (z.B. JSON).
- Bei niedrigen Key-Facts-Scores: RAG-Chunking anpassen, mehr relevante Chunks abrufen, Reranking einbauen.
💡 Wichtig: Ändere pro Run möglichst nur eine Variable. Sonst weißt du nicht, welche Änderung welchen Effekt hatte.
Token-Kosten im Griff behalten
Evaluation kostet Geld – schließlich rufst du dein LLM mehrfach auf. Mit ein paar einfachen Regeln bleiben die Kosten überschaubar.
💰 Kostenfalle 1: Zu große Test-Datasets
Du brauchst keine 1.000 Test-Cases. 20–30 gut gewählte Beispiele sind oft völlig ausreichend.
💰 Kostenfalle 2: Zu lange Prompts
Das Dashboard zeigt dir promptTokens. Wenn der Wert explodiert, ist dein System-Prompt zu lang.
Optimierung:
- Few-Shot-Beispiele reduzieren,
- Kontext straffen,
- nur wirklich notwendige Infos behalten.
💰 Kostenfalle 3: Teure Modelle für die Metrik
Für die Custom-Metrik (LLM als Prüfer) brauchst du nicht zwingend das teuerste Modell.
Trick: Nutze z.B. ein starkes Modell für den Haupt-Workflow, aber ein günstigeres Modell für die Metrik-Berechnung.
💰 Grobe Kostenbeispiele
| Setup | Test-Cases | Kosten pro Run (ca.) |
|---|---|---|
| Klassifizierung (nur Correctness) | 20 | ~0,20 € |
| RAG mit Custom-Metrik | 20 | ~0,80 € |
| PDF-Extraktion + Field Accuracy | 20 | ~1,50 € |
💡 ROI-Rechnung: Wenn ein Evaluation-Run dich 1 € kostet und verhindert, dass 100 Rechnungen falsch geroutet werden, hast du den ROI nach dem ersten vermiedenen Fehler wieder drin.
Integration in deinen Development-Workflow
Evaluation sollte kein „Nice-to-have“ am Ende sein, sondern fester Bestandteil deines Entwicklungsprozesses.
Wann solltest du evaluieren?
Vor jedem Deployment:
Änderst du einen Prompt? Evaluation. Wechselst du das Modell? Evaluation. Keine Ausnahmen.
Regelmäßige Quality-Checks:
Auch wenn du nichts änderst – Modelle entwickeln sich weiter. Teste z.B. alle 4–6 Wochen.
Nach Nutzerfeedback:
Wenn sich jemand über falsche Outputs beschwert, füge den Fall zu deinem Dataset hinzu und re-evaluiere.
Evaluation als Teil der CI/CD-Pipeline
Für größere Teams bietet sich an, n8n Evaluations in die CI/CD-Pipeline zu integrieren.
Beispiel-Prozess:
- Developer ändert einen Workflow in der Dev-Umgebung.
- Automatisiert wird eine Evaluation angestoßen.
- Fallen die Scores unter einen Schwellwert, wird das Deployment blockiert.
- Wenn alles passt, gibt es grünes Licht für Staging und Produktion.
💡 n8n-Tipp: Du kannst n8n-Workflows per API triggern und so Evaluations-Runs automatisch nach jedem Git-Commit starten.
Fazit
Ohne Evaluation fliegst du blind. Mit n8n Evaluations hast du die Kontrolle.
Du siehst:
- ob dein Workflow gut oder schlecht performt,
- welche Änderungen echte Verbesserungen bringen,
- wo deine KI noch Schwächen hat,
- ob ein neues Modell seinen Aufpreis wirklich wert ist.
Und das Beste: Evaluations ist direkt in n8n integriert. Keine zusätzliche Software, kein kompliziertes Setup.
Deine nächsten Schritte:
- Identifiziere deinen kritischsten KI-Workflow (wo kosten Fehler am meisten?).
- Erstelle ein Test-Dataset mit 10–20 realistischen Beispielen.
- Bau die Evaluation-Nodes in deinen Workflow ein.
- Mach einen Baseline-Run und dokumentiere den Ist-Zustand.
- Optimiere iterativ – und miss jede Änderung mit n8n Evaluations.
Weiterführende Ressourcen
Wenn du noch tiefer in n8n und Automatisierung einsteigen möchtest, helfen dir diese Ressourcen weiter:
- Kostenlose Zapier Alternative 2025: Warum n8n oft die bessere Wahl ist – und wie du migrierst.
- Top 5 Automatisierungstools für Unternehmen 2025 im Vergleich: n8n vs. Zapier vs. Make vs. Power Automate.
- n8n Templates kostenlos: Fertige Workflows zum sofort Loslegen.
Viel Erfolg beim Evaluieren – und beim produktiven Einsatz von n8n Evaluations in deinen Projekten! 🚀
German 
English