KI-Qualität messen und verbessern

KI-Qualität messen und verbessern

0:00 „Der Lauf war erfolgreich." Diesen Satz haben wir in diesem Seminar schon mehrfach auseinandergenommen, aber bei KI-Workflows bekommt er eine neue Qualität. Denn hier sagt er wirklich fast nichts: Alle Bausteine haben geantwortet, die Struktur stimmte — ob die Antwort inhaltlich richtig war, weiß davon niemand. Dieses Modul zeigt, wie man das ändert.

0:21 n8n bringt dafür eine eingebaute Evaluationsfunktion mit, und sie ist erstaunlich handfest: Sie legen einen Datensatz an, lassen ihn durchlaufen und bekommen Zahlen. Daraus lassen sich Entscheidungen begründen statt behaupten.

KI-Qualität messen und verbessern

0:35 Willkommen am fünften Tag. Heute geht es um Messen und um Kontrolle. Wir beginnen mit der Evaluation von KI-Workflows — der Frage, wie man Qualität in Zahlen fasst. Danach folgen MCP und Coding Agents, also die Verbindung von n8n zu KI-Assistenten. Und zum Abschluss des Tages die Sicherheit. Alle drei Module haben eines gemeinsam: Sie handeln davon, wie man die Kontrolle behält, wenn ein System Dinge selbst entscheidet.

Warum ein grüner Lauf nichts beweist

1:03 Fangen wir mit der Ausgangslage an. Die Ausführung meldet Technik, nicht Fachlichkeit — und bei probabilistischen Antworten ist der Abstand zwischen beidem größer als irgendwo sonst. Evaluation in n8n heißt, Beispiele eines Testdatensatzes durch den Workflow laufen zu lassen und die Ergebnisse festzuhalten — einzeln vergleichbar und über Läufe hinweg.

1:24 Der Datensatz liegt dabei in einer Data Table oder in einem Google Sheet. Das ist eine bewusst niedrigschwellige Entscheidung: Sie brauchen kein Testframework, Sie brauchen eine Tabelle. Und bei der Data Table schließt sich ein Kreis — im sechsten Modul hatten wir die Anwendungsfälle aufgezählt, und Auswertungsdaten für KI-Workflows war einer davon.

1:44 Genau hier werden sie gebraucht. Vier Punkte, und die ersten beiden sind das, was Sie bekommen. Alle Bausteine haben ohne Ausnahme geantwortet. Die Struktur der Ausgabe entsprach dem Schema — das ist immerhin etwas, dafür haben wir gestern den Output Parser eingesetzt. Aber über den Inhalt der Antwort sagt beides nichts.

2:04 Ob „Dringlichkeit: hoch" richtig war, weiß der Workflow nicht; er weiß nur, dass dort ein zulässiger Wert steht. Und daraus folgt der vierte Punkt: Erst der Vergleich mit einer Referenzantwort macht daraus eine Aussage. Sie brauchen also jemanden, der weiß, was richtig gewesen wäre. Drei Spalten und eine Haltung. Eine Spalte für die Eingabe des Workflows.

2:26 Optional eine für die erwartete, richtige Ausgabe — optional heißt hier: Ohne sie können Sie nur nebeneinanderlegen, nicht bewerten; nehmen Sie sie also. Eine Spalte für die tatsächliche Ausgabe, die der Lauf füllt. Und dann der vierte Punkt, der die Sache lebendig hält: Fälle aus dem Betrieb, sobald der Betrieb Grenzfälle zutage fördert. Ein Evaluationsdatensatz ist kein einmaliges Werk.

2:50 Er wächst mit jedem Fall, bei dem jemand sagt „das hätte anders sein müssen". Der erste Punkt ist der naheliegendste Fehler: Der Datensatz enthält nur Fälle, die schon beim Bauen funktioniert haben — dann messen Sie Ihre eigenen Beispiele. Der zweite macht das Messen unmöglich: Es gibt keine Referenzantwort, und verglichen wird gegen ein Gefühl.

3:11 Der dritte ist der von eben, in seiner statischen Form: Der Datensatz wächst nie, obwohl der Betrieb täglich Beispiele liefert. Und der vierte ist ärgerlich, weil die Arbeit schon getan war: Ergebnisse werden angesehen, aber nicht festgehalten — dann kann man beim nächsten Mal nicht vergleichen.

Evaluation in Entwicklung und Betrieb

3:28 n8n bietet dafür zwei Stufen an — eine zum Bauen und eine zum Messen. Der Unterschied liegt nicht in der Technik, sondern in der Frage, die man stellt. Light Evaluations lassen die Beispiele eines Testdatensatzes einzeln durch den Workflow laufen und schreiben die Ausgaben in den Datensatz zurück. Sie sind für die Entwicklung gedacht: Man sieht die Ergebnisse nebeneinander und vergleicht sie mit den erwarteten. Das ist bewusst ein visuelles Verfahren — Sie lesen.

3:55 Für zehn oder zwanzig Fälle ist das genau richtig und oft aufschlussreicher als jede Kennzahl, weil Sie die Art der Fehler sehen. Ab hundert Fällen funktioniert das nicht mehr, und dann kommt die zweite Stufe ins Spiel. Zwei Zeilen, und die Verfügbarkeit unterscheidet sich deutlich. Light Evaluations gibt es in der Cloud auf allen Plänen und selbst gehostet ab der Registered Community — also kostenlos, wenn Sie registriert haben.

4:19 Das ist wieder ein Argument für die Registrierung aus Modul eins. Die metrische Evaluation ist anspruchsvoller: Cloud Pro oder Enterprise, selbst gehostet Enterprise. Aber lesen Sie die Fußzeile — Registered Community und Starter dürfen sie für einen einzelnen Workflow nutzen. Sie können die Funktion also ausprobieren, bevor Sie entscheiden, ob sie den Plan wert ist.

4:41 Fünf Schritte. Legen Sie den Datensatz als Data Table oder Google Sheet an. Fügen Sie den Evaluation Trigger ein — er gibt je Lauf genau eine Zeile aus. Schreiben Sie die Ausgaben des Workflows in den Datensatz zurück. Führen Sie über Evaluate all den Workflow je Zeile einmal aus. Und ergänzen Sie Metriken, sobald der Datensatz zum Ansehen zu groß wird.

5:02 Ein praktischer Tipp aus der Dokumentation steht in der Fußzeile: Setzen Sie beim Verdrahten die maximale Zeilenzahl auf eins — sonst läuft bei jedem Versuch der ganze Datensatz durch, und das dauert. Der erste Punkt ist eine Einschränkung, die man beim Entwurf kennen muss: Je Workflow ist nur eine Evaluation möglich. Wollen Sie verschiedene Teile getrennt messen, gehören sie in Sub-Workflows — noch ein Argument für die Zerlegung aus Modul sechs.

5:29 Der zweite: Der Evaluation Trigger steht neben einem zweiten Trigger, ohne dass die Zweige zusammengeführt sind. Der dritte ist ein hübsches Detailproblem: Die Chat-Ausgabe bricht, weil der Evaluation-Baustein als letzter antwortet. Und der vierte kostet Geld: Metriken laufen produktiv mit, statt hinter einer Prüfung zu stehen.

Was gemessen wird

5:49 Kommen wir zu den Metriken selbst. n8n bringt fünf mit, und alle haben eines gemeinsam: Am Ende steht eine Zahl. Das ist der Preis der Vergleichbarkeit. Fünf Metriken mit ihren Skalen, und sie zerfallen in zwei Gruppen. Correctness und Helpfulness werden von einem Modell berechnet und geben eine Note von eins bis fünf: Stimmt die Antwort sinngemäß mit der Referenz überein, und beantwortet sie überhaupt die Frage?

6:14 String Similarity, Categorization und Tools Used sind rechnerisch: zeichenweise Nähe, exakte Übereinstimmung, und ob überhaupt Werkzeuge benutzt wurden. Für eine Klassifizierung mit fester Liste ist Categorization das richtige Maß — null oder eins, keine Diskussion. Und die Fußzeile ist wichtig: Die modellbasierten Metriken sind selbst nicht rauschfrei.

6:35 Vier Punkte. Metriken sind in n8n immer Zahlen, berechnet im Workflow selbst — das heißt, Sie können alles messen, was Sie rechnen können. Über die Funktion Set Metrics mit Custom Metrics übergeben Sie eigene Werte. Für RAG lohnt ein eigenes Maß für die Güte der gefundenen Dokumente — genau die Trennung zwischen Retrieval- und Antwortqualität aus dem letzten Modul, jetzt messbar gemacht.

6:59 Und viertens: Kosten, Tokenverbrauch und Antwortzeit sind ebenfalls messbare Größen. Vergessen Sie die nicht. Eine Variante, die einen Punkt besser trifft und dreimal so teuer ist, ist keine Verbesserung. Der erste Punkt ist eine verbreitete Versuchung: Gemessen wird, was leicht zu messen ist, nicht was fachlich zählt. Der zweite ist eine fehlende Festlegung: Correctness von vier gilt als bestanden, ohne dass jemand die Schwelle begründet hat — warum vier und nicht drei?

7:27 Das ist eine fachliche Entscheidung und gehört dokumentiert. Der dritte ist der Kostenpunkt: Die Metrikberechnung läuft produktiv mit, statt hinter einer Prüfung zu stehen; n8n bietet dafür eine eigene Operation an. Und der vierte ist ein Methodenfehler: Ein einzelner Durchlauf gilt als Ergebnis, obwohl die Werte schwanken.

Verbessern statt raten

7:46 Zum Abschluss die Methodik. Denn Zahlen zu haben ist eine Sache — aus ihnen die richtigen Schlüsse zu ziehen eine andere. Und dabei gibt es zwei Fallstricke, die fast jeden erwischen. Der erste Fallstrick ist das Rauschen. Metriken schwanken zwischen Läufen desselben Workflows — nicht weil etwas kaputt ist, sondern weil sowohl der Workflow als auch die modellbasierten Metriken eine natürliche Streuung haben.

8:11 Wenn Ihre Variante also um zwei Prozentpunkte besser ist, kann das Zufall sein. Die Gegenmaßnahme ist erfreulich einfach: Nehmen Sie Zeilen mehrfach in den Datensatz auf. Jede Eingabe läuft dann mehrmals, und die Schwankung glättet sich. Das kostet Geld und Zeit — aber weniger als eine falsche Entscheidung, die ein Jahr hält.

8:31 Fünf Schritte, und der zweite ist der Fallstrick Nummer zwei. Messen Sie den Ausgangsstand und halten Sie das Ergebnis fest. Ändern Sie dann genau eine Sache — Prompt oder Modell, nicht beides. Wer zwei Dinge gleichzeitig ändert, weiß hinterher nicht, welches gewirkt hat; das ist die älteste Regel des Experimentierens und wird trotzdem ständig gebrochen.

8:51 Lassen Sie dieselbe Evaluation erneut laufen. Sehen Sie sich die Abweichung je Metrik an und gehen Sie in die Einzelfälle hinein. Und entscheiden Sie mit den Zahlen als Begründung. Über Return intermediate steps lässt sich übrigens prüfen, ob der Agent überhaupt ein Werkzeug benutzt hat. Vier Punkte, und sie setzen die Zahlen ins Verhältnis. Bei risikoreichen Entscheidungen ersetzt keine Zahl die fachliche Prüfung.

9:16 Die Schwelle, ab der etwas gilt, ist eine fachliche Festlegung — die Metrik liefert den Wert, nicht das Urteil. Schlechte Fälle sind einzeln zu lesen, nicht nur zu zählen; im Einzelfall sehen Sie das Muster, das der Durchschnitt verbirgt. Und ein Modellwechsel des Anbieters ist ein Anlass zum erneuten Messen. Das passiert übrigens auch ohne Ihr Zutun: Anbieter aktualisieren ihre Modelle, und Ihre Ergebnisse ändern sich, ohne dass Sie etwas angefasst haben.

9:43 Der erste Punkt ist ein Methodenfehler mit Tradition: Der Prompt wird verbessert, bis die Zahlen steigen — auf demselben Datensatz. Das ist Überanpassung, und sie fällt erst in Produktion auf. Der zweite ist der Verlust an Erkenntnis: Die Fälle, an denen es scheitert, werden nie einzeln angesehen. Der dritte ist der Doppeländerungsfehler von eben.

10:03 Und der vierte ist eine Betriebsblindheit, die sich einschleicht: Nach dem Anbieter-Update wird nicht erneut gemessen — dabei wäre genau das der Moment.

Übung

10:13 Jetzt messen Sie selbst. Und zwar an dem Schritt, den Sie gestern gebaut haben — mit zwei Varianten, die beide plausibel klingen, aber unterschiedlich gut sein werden. Der Klassifizierungsschritt aus Modul zwölf ordnet Meldungen eine Dringlichkeit zu. Für dreißig echte Meldungen von Kesselwerk liegt die richtige Einstufung vor — das ist Ihr Referenzmaterial, und es stammt von Menschen, die den Betrieb kennen.

10:37 Zu vergleichen sind zwei Varianten: ein präziserer Prompt und ein kleineres, günstigeres Modell. Diese Gegenüberstellung ist bewusst gewählt, denn sie ist der Alltagsfall: Man möchte wissen, ob das billigere Modell reicht — und das kann man nicht diskutieren, das muss man messen. Das Lernziel: eine Änderung an einem KI-Schritt an Zahlen belegen statt an Eindrücken.

10:58 Erfolgreich sind Sie, wenn beide Varianten am selben Datensatz gemessen sind, die Wahl mit Metrik, Kosten und Antwortzeit begründet ist und die Schwankung durch Wiederholung berücksichtigt wurde. Alle drei Teile zählen — insbesondere der letzte, denn ohne ihn vergleichen Sie möglicherweise Rauschen. Wer früh fertig ist, ergänzt eine eigene Metrik für die Trefferquote bei Notdienstfällen.

11:19 Das ist fachlich der interessanteste Wert: Ein Fehler bei einem Notdienst wiegt schwerer als zehn bei Routineaufträgen. Siebzig Minuten, fünf Schritte. Legen Sie den Datensatz mit Eingabe, Referenzeinstufung und Ausgabespalte an. Verdrahten Sie den Evaluation Trigger und schreiben Sie die Ausgabe zurück. Setzen Sie Categorization und Correctness als Metriken — die eine exakt, die andere sinngemäß.

11:43 Messen Sie beide Varianten und lassen Sie die Zeilen dabei mehrfach durchlaufen. Und öffnen Sie zum Schluss die fünf schlechtesten Fälle einzeln und benennen Sie die Ursache. Dieser letzte Schritt liefert Ihnen mehr Erkenntnis als der gesamte Zahlenvergleich davor — er sagt Ihnen, woran es liegt. Vier Fallen. Erstens, und das macht die ganze Messung wertlos: Die Referenzeinstufung entsteht aus der Ausgabe des ersten Laufs.

12:09 Dann messen Sie, wie gut sich der Workflow selbst reproduziert. Zweitens: Gemessen wird einmal, und die Differenz liegt im Rauschen. Drittens: Die günstigere Variante gewinnt, ohne dass jemand die Notdienstfälle gesondert betrachtet hat — der Durchschnitt kann stimmen, während genau die kritischen Fälle schlechter werden.

12:28 Und viertens ein handwerklicher Fehler: Die Metrik wird gesetzt, aber der Datensatz hat keine Referenzspalte. Dann läuft alles durch und misst nichts.