Evaluierung: die Qualität messbar machen

Evaluierung

0:00 Wenn Sie aus diesem Seminar ein einziges Modul mitnehmen, dann dieses. Nicht, weil es das anspruchsvollste wäre — technisch ist es das einfachste. Sondern weil es über die Lebensdauer Ihres Features entscheidet. Alles, was wir bisher gebaut haben, lässt sich verschlechtern, ohne dass jemand es merkt. Eine Prompt-Änderung, ein neues Modell, ein Nachtrag im Handbuch — und die Qualität sinkt still. Am Ende dieses Moduls haben Sie eine Zahl, die das sichtbar macht.

0:28 Und, fast noch wichtiger: eine Liste der Fälle, die schlechter geworden sind.

Warum Projekte genau hier stehenbleiben

0:34 Fangen wir mit einem Verlauf an, den Sie vielleicht wiedererkennen. Er ist so verbreitet, dass man ihn fast als Naturgesetz beschreiben könnte, und er endet immer gleich: Das Feature erstarrt, weil sich niemand mehr traut, etwas zu ändern. Ich erzähle ihn hier ausführlich, weil das Verständnis dieses Mechanismus die halbe Motivation für alles ist, was in diesem Modul folgt.

0:55 Das Feature geht in Betrieb. Jemand meldet eine schlechte Antwort, jemand ändert den Prompt, die Antwort wird besser — alle sind zufrieden. Zwei Wochen später dasselbe Spiel mit einer anderen Frage, und niemand weiß, ob die erste Verbesserung noch hält. Nach einigen Runden traut sich niemand mehr, den Prompt anzufassen. Das Feature erstarrt.

1:15 Und das ist der eigentliche Schaden: nicht die einzelne schlechte Antwort, sondern der Zustand, in dem niemand mehr etwas verbessern will, weil niemand die Folgen abschätzen kann. Ich möchte betonen, dass dieser Zustand nicht durch Nachlässigkeit entsteht. Die Teams, die ich so erlebt habe, waren durchweg sorgfältig — ihnen fehlte schlicht eine Messgröße.

1:36 Ohne Datensatz ist jede Änderung eine Vermutung, und mit Vermutungen wird man vorsichtig; Vorsicht friert das Feature ein. Verschlechterungen fallen zudem erst nach Wochen auf, wenn sich niemand mehr erinnert, was sich geändert hat. Der Aufwand für die Messung ist einmalig. Der Aufwand für das Raten ist dauerhaft.

Der Goldstandard-Datensatz

1:55 Also bauen wir die fehlende Messgröße. Sie beginnt mit einer Sammlung von Fällen — und mit einer Entscheidung darüber, woher diese Fälle stammen. Das klingt nach einer Fleißaufgabe und ist in Wahrheit die inhaltlich anspruchsvollste Arbeit des ganzen Projekts, denn hier legen Sie schriftlich fest, was Ihr Feature eigentlich leisten soll.

2:13 Wir schauen uns an, wie ein guter Fall aussieht. Ein Fall besteht aus der Frage einer Werkstatt, der Baureihe, dem Handbuchstück mit der Antwort, den Angaben, die vorkommen müssen, und den Angaben, die keinesfalls vorkommen dürfen. Diese letzte Zeile wird gern vergessen und ist oft die aufschlussreichste. Wichtig ist die Herkunft: Die Fälle stammen aus echten Anrufen, nicht aus der Fantasie.

2:36 Am Schreibtisch erdachte Fragen sind zu glatt, zu vollständig, zu höflich — und treffen die tatsächliche Sprache der Werkstätten nicht. Fünfzig gepflegte Fälle sind mehr wert als fünfhundert erzeugte. Die Mischung entscheidet darüber, was Sie überhaupt messen können. Einfache Fälle sichern die Grundfunktion. Schwierige machen Grenzen sichtbar.

2:57 Fälle ohne Antwort im Bestand prüfen die Verweigerung — ohne sie wissen Sie nie, ob Ihr System schweigen kann. Fälle mit Widerspruch prüfen den Umgang mit Konflikten; da begegnet uns die Sattelklemme aus Modul sechs wieder. Und Fälle mit Teilenummern prüfen die Wortlautsuche aus Modul fünf. Sie sehen: Der Datensatz ist nicht nur eine Prüfung des Modells, sondern der ganzen Kette.

Was gemessen wird

3:20 Nicht alles an einer Antwort lässt sich mit einer Zahl erfassen, deshalb trennen wir nach Ebenen. Und wir fangen absichtlich beim Billigsten an: bei den Prüfungen, die ohne Modell auskommen. Das ist kein Geiz, sondern Methode — ein erheblicher Teil der Fehler wird schon dort gefunden, und was übrig bleibt, ist überschaubar genug für die aufwendige Bewertung.

3:40 Lesen Sie die Tabelle von oben nach unten als Kostenkurve. Die Trefferquote des Retrievals braucht kein Modell. Ob Pflichtangaben vorkommen und verbotene fehlen, ist ein Textvergleich. Die Verweigerung steht als Feld im Schema. Die Belege lassen sich gegen die Fundstelle prüfen. Erst ganz unten, bei Verständlichkeit und Vollständigkeit, brauchen Sie eine aufwendige Bewertung.

4:02 Der Zweck dieser Reihenfolge ist nicht Sparsamkeit um ihrer selbst willen — ein erheblicher Anteil der Fehler wird schon von den billigen Prüfungen gefunden.

Das Modell als Prüfer

4:12 Für den Rest bietet es sich an, ein Modell urteilen zu lassen. Das funktioniert brauchbar, und es hat drei gut dokumentierte Schwächen, die man kennen muss, bevor man den Zahlen glaubt. Wir gehen sie durch und klären danach, mit welchen fünf Schritten aus einem Orakel ein Messinstrument wird — das entscheidende ist der Vergleich mit menschlichen Urteilen.

4:32 Die ersten drei Punkte sind gut dokumentierte Verzerrungen: Prüfer bevorzugen längere Antworten, sie bevorzugen den eigenen Stil — besonders, wenn Prüfer und Erzeuger dasselbe Modell sind —, und ihre Urteile schwanken ohne klare Kriterien. Der vierte Punkt ist der, den ich Ihnen ans Herz lege: Ein Prüfer, dessen Übereinstimmung mit menschlichen Urteilen nie gemessen wurde, misst nichts Bekanntes.

4:55 Er liefert eine Zahl, die beruhigt. Was sie bedeutet, weiß niemand. Fünf Schritte, die den Prüfer von einem Orakel zu einem Messinstrument machen. Kriterien schriftlich vorgeben, nicht als Gefühl. Je Kriterium ein Beispiel für gut und eines für schlecht — das wirkt stärker als jede Erklärung. Erzeuger und Prüfer nicht dasselbe Modell sein lassen.

5:16 Dann der entscheidende Schritt: eine Stichprobe von Menschen bewerten lassen und mit dem Prüfer vergleichen. Und die Übereinstimmung dokumentieren und regelmäßig nachmessen — denn sie kann sich mit jedem Modellwechsel verändern.

Regressionen erkennen

5:30 Jetzt zu dem Teil, der aus Zahlen erst einen praktischen Nutzen macht: dem Vergleich zwischen zwei Läufen. Sie werden sehen, dass die interessante Größe nicht die Gesamtquote ist — die kann gleich bleiben, während sich unter ihr zehn Verbesserungen und zehn Verschlechterungen gegenseitig aufheben. Interessant ist die Liste der Fälle, die schlechter geworden sind.

5:50 Jeder Lauf wird mit Prompt-Version, Modell, Retrieval-Einstellungen und Datum festgehalten und gegen den vorigen gestellt. Und jetzt kommt der Punkt, der viele überrascht: Die interessante Größe ist nicht die Gesamtquote, sondern die Liste der Fälle, die vorher richtig und jetzt falsch sind. Eine unveränderte Gesamtquote kann bedeuten, dass zehn Fälle besser und zehn schlechter geworden sind. Wer nur auf die Prozentzahl schaut, sieht in diesem Fall — nichts.

6:15 Und genau dort verstecken sich die Rückschritte. Vier Dinge, und das vierte ist mir das liebste: Der Vergleich macht Mut. Solange Sie nicht wissen, was eine Änderung anrichtet, arbeiten Sie mit angezogener Handbremse. Sobald der Schaden sichtbar wird, dürfen Sie wieder mutig sein — Sie sehen ja sofort, ob es geklappt hat.

6:34 Dazu kommen die anderen drei: Sie sehen, was kaputtgegangen ist, Sie können Verbesserungen belegen statt behaupten, und Sie können auf eine frühere Prompt-Fassung zurück, weil Sie wissen, welche das war.

Evaluierung in der Pipeline

6:46 Und jetzt der Schritt, der über Erfolg und Misserfolg entscheidet, weil er über die Gewohnheit entscheidet: Was nicht automatisch läuft, wird nicht ausgeführt. Der Evaluierungslauf gehört deshalb in dieselbe Pipeline wie Ihre Tests — mit zwei Besonderheiten, die man einplanen muss. Er kostet Geld, und sein Ergebnis ist keine einfache Ja-Nein-Antwort.

7:07 Fünf Punkte. Eine schnelle Teilmenge bei jeder Änderung an Prompt, Schema oder Retrieval. Der vollständige Lauf vor der Auslieferung und nächtlich. Und dann die Grenze, über die man diskutieren wird: Setzen Sie sie auf den zuletzt erreichten Stand, nicht auf Perfektion. Besser werden darf durch, schlechter werden nicht — das ist eine Regel, die jeder versteht und die niemanden ausbremst.

7:30 Das Ergebnis gehört als Bericht abgelegt, nicht nur als grün oder rot. Und weisen Sie die Kosten je Lauf aus, damit der Umfang eine bewusste Entscheidung bleibt. Vier Wege, wie eine Evaluierung wieder einschläft. Den Lauf nur von Hand starten — nach drei Wochen erinnert sich niemand mehr daran. Einen Datensatz aufbauen, den niemand pflegt.

7:50 Bei rotem Lauf die Grenze senken, statt die Ursache zu suchen — das ist der stille Tod jeder Qualitätsmessung, und er passiert immer unter Termindruck. Und die Kosten des Laufs nicht zu kennen, sodass ihn irgendwann jemand heimlich abschaltet, weil die Rechnung auffällt.

Rückmeldung aus dem Betrieb

8:07 Der Goldstandard bildet ab, was Sie vorher wussten. Was Sie nicht wussten, kommt aus dem Betrieb — und dafür muss das Feature von Anfang an so gebaut sein, dass es sich beobachten lässt. Dieser Kreislauf ist der Unterschied zwischen einem Feature, das über Monate besser wird, und einem, das über Monate schlechter wird, ohne dass es jemand bemerkt.

8:27 Vier Schritte, die den Unterschied machen zwischen einem Feature, das über Monate besser wird, und einem, das über Monate schlechter wird. Rückmeldung an der Antwort einsammeln, mit Grund. Frage, Fundstellen, Prompt-Version und Antwort protokollieren, damit sich der Fall rekonstruieren lässt. Aus einer schlechten Antwort mit einem Klick einen Testfall machen — das ist die Stelle, an der der Kreislauf sich schließt.

8:51 Und Fristen festlegen: Das sind Kundenanfragen, also personenbezogene Daten. Die Frage klärt man besser vorher als nach der ersten Auskunftsanfrage.

Der Fall, der rot bleiben darf

9:01 Zum Abschluss ein Muster, das sich bewährt hat und das auf den ersten Blick wie ein Eingeständnis aussieht: Ein Fall im Datensatz bleibt absichtlich rot. Er wird nicht repariert, sondern dokumentiert. Was das über die Qualität Ihrer Messung aussagt, ist erstaunlich viel — und es ist dasselbe Muster, das im Playwright-Begleitprojekt dieses Hauses einen eingebauten Fehler festhält.

9:23 Bei Talwerk bleibt eine Frage absichtlich rot: das Anzugsdrehmoment der Sattelklemme der Baureihe von 2021. Handbuch und Nachtrag nennen zwei Werte, und das Feature wählt einen aus, statt den Widerspruch zu benennen. Wir reparieren das nicht. Wir dokumentieren es. Das fühlt sich falsch an — man möchte doch, dass alles grün ist.

9:43 Aber genau dieser eine rote Punkt sagt mehr über die Qualität Ihrer Messung aus als die neunundvierzig grünen daneben. Vier Dinge belegt er. Die Evaluierung misst tatsächlich und leuchtet nicht nur grün — ein Testsatz ohne einen einzigen roten Fall ist meistens zu einfach. Die Grenze des Systems ist bekannt statt vermutet, und man kann sie einer Nutzerin erklären. Der eigentliche Fehler sitzt im Korpus, nicht im Prompt.

10:09 Und wer ihn wegpromptet, verdeckt eine Lücke im Bestand, statt sie zu schließen. Wenn Sie also in Ihrem eigenen Projekt einen solchen Fall finden — lassen Sie ihn stehen und schreiben Sie daneben, warum. Damit sind Sie dran, und das ist die wichtigste Übung dieses Seminars. Erfassen Sie zwanzig Fälle, lassen Sie den Lauf durchlaufen und weisen Sie Trefferquote, Pflichtangaben, Verweigerungen und Belegprüfung getrennt aus.

10:34 Vergleichen Sie dann zwei Prompt-Fassungen und lassen Sie sich die Rückschritte einzeln anzeigen — nicht nur die Summe. Achten Sie darauf, dass mindestens ein Fall ohne Antwort im Bestand dabei ist und der Widerspruchsfall ebenfalls. Im letzten Modul kümmern wir uns dann darum, was das Ganze im Betrieb kostet.