Warum „fühlt sich gut an“ kein Test ist
Am Nicken vor dem Bildschirm sind drei Dinge falsch, und sie verstärken sich gegenseitig. Die Stichprobe ist winzig — bei fünf Fragen sehen ein System mit 60 % und eines mit 90 % Trefferquote identisch aus. Die Stichprobe stammt von dem, der gebaut hat, und der tippt unbewusst genau die Fragen ein, für die er das System entworfen hat. Und nichts wird festgehalten: Wenn Sie nächste Woche den Prompt ändern, haben Sie keine Möglichkeit festzustellen, ob Sie ihn verbessert oder still kaputt gemacht haben. Sie messen nicht das System. Sie messen Ihren eigenen Optimismus.
Die ehrliche Antwort ist unspektakulär und seit Jahren dieselbe: eine feste Menge echter Fälle mit bekannt richtigen Antworten, bei jeder Änderung durchlaufen lassen, auf die Zahl schauen. Niemand überspringt das, weil er noch nie davon gehört hätte. Übersprungen wird es, weil dafür ein erfahrener Mensch sich hinsetzen und für fünfzig unordentliche echte Fälle entscheiden muss, was die richtige Antwort eigentlich ist — undankbare Arbeit, die niemand eingeplant hat und die niemandem Spaß macht. Das ist das ganze Hindernis. Die Metriken sind der leichte Teil. Die Referenzantworten sind das Projekt.
Das Golden Set ist die eigentliche Arbeit
Ein Golden Set ist eine feste Sammlung echter Eingaben mit der Antwort, die Sie akzeptieren würden — vorab festgelegt. Beginnen Sie mit vierzig bis sechzig Fällen, nicht mit fünfhundert. Das irritiert alle, die es gründlich machen wollen, also die Begründung: Sie werden ein Drittel Ihres ersten Sets neu schreiben, sobald Sie sehen, was das System tatsächlich falsch macht — denn Ihre Vorstellung von einem schweren Fall und die des Systems gehen auseinander. Klein anfangen, laufen lassen, dann jeden Produktionsfehler zu einem neuen Fall machen. Nach einem halben Jahr ist das Set groß — und jede Zeile steht dort, weil wirklich etwas kaputtgegangen ist.
Nehmen Sie einen Maschinenbauer, der einen Serviceassistenten auf zwanzig Jahre Handbücher setzt, damit Techniker im Feld nicht mehr aus der Werkshalle des Kunden im Büro anrufen. Das Golden Set sind fünfzig echte Fragen, die Techniker tatsächlich gestellt haben, jede mit der Antwort, die ein erfahrener Servicetechniker als richtig abzeichnet.
Nach Ihren Fehlern auswählen, nicht nach Ihrem Traffic
Hier ist der Fehler, der selbst in Teams überlebt, die sonst alles richtig machen. Es fühlt sich sauber an, das Golden Set als repräsentative Stichprobe des echten Anfrageaufkommens zu bauen. Tun Sie es nicht. Echter Traffic ist überwiegend leicht — dasselbe Dutzend Routinefragen, das Ihr System ohnehin richtig beantwortet. Bauen Sie das Set so, sind die meisten Zeilen Fälle, die immer sitzen; Ihr Wert parkt bei 88 % und rührt sich nicht, egal was Sie ändern. Die Fälle dagegen, die die verärgerten Anrufe erzeugen, sind drei Zeilen von fünfzig und gehen in den leichten unter.
Übergewichten Sie die schweren Fälle bewusst. Beim Maschinenbauer heißt das: Fragen, deren Antwort in einer Tabelle steht statt in einem Satz. Fragen zu der Variante, die sich den Namen mit einer anderen teilt. Mehrdeutige Fragen. Und — entscheidend — Fragen, die die Handbücher schlicht nicht beantworten. Wollen Sie zusätzlich die realen Quoten schätzen, halten Sie eine zweite, kleinere repräsentative Auswahl vor. Zwei Sets, zwei Aufgaben: Das schwere Set steuert die Entwicklung, das repräsentative schätzt die Produktion. Beides in einen Mittelwert zu rühren ergibt eine Zahl, die keine der beiden Aufgaben erfüllt.
Jemand muss die richtige Antwort aufschreiben
Die richtige Antwort muss von der Person kommen, die die Arbeit heute macht — vom erfahrenen Servicetechniker, nicht vom Projektleiter und schon gar nicht von einem weiteren LLM. Rechnen Sie ehrlich: fünfzig Fälle à gut zehn Minuten sind ein Tag Ihres teuersten Mitarbeiters, plus ein zweiter Tag, wenn das Set überarbeitet wird. Diese Rechnung ist der Grund, warum Golden Sets nicht entstehen. Sie ist zugleich der günstigste Tag im Projekt — denn es ist der Tag, der verhindert, dass Sie eine selbstbewusst falsche Antwort an einen Techniker ausliefern, der neben einer stehenden Maschine steht.
Zwei Details bezahlen sich selbst. Halten Sie fest, warum eine Antwort richtig ist, nicht nur welche — nach einem halben Jahr weiß es niemand mehr, und genau diese Notiz macht das Set für andere pflegbar. Und nehmen Sie die unbeantwortbaren Fragen auf, mit der erwarteten Antwort „weiß ich nicht, bitte im Büro anrufen“. Ein Set, das nur Fragen mit Antwort enthält, vermeidet sorgfältig, den Fehlermodus zu messen, der Ihnen wirklich schadet.
Metriken, die zur Aufgabe passen
„Genauigkeit“ ist keine Metrik, solange Sie nicht sagen: Genauigkeit worin. Der sinnvolle Schritt ist, Metriken pro Aufgabe zu wählen — und mehr als eine Zahl zu akzeptieren:
Extraktion — Felder aus Rechnungen oder Auftragsbestätigungen ziehen: exakte Übereinstimmung je Feld, dazu Precision und Recall. Gewichten Sie die Felder nach Konsequenz. Eine falsche IBAN wiegt schwerer als zehn falsche Freitextbeschreibungen, und genau das verdeckt ein gemittelter Gesamtwert. Klassifikation — ein Regionalversicherer, der eingehende Schadenskorrespondenz sortiert: nehmen Sie die Konfusionsmatrix, nicht eine Genauigkeitszahl. Welche Klasse mit welcher verwechselt wird, ist der handlungsfähige Teil; „91 % genau“ sagt Ihnen nichts, woran Sie arbeiten könnten. Retrieval: Recall@k — hat es die richtige Passage überhaupt in den Kontext geschafft? Freie Textgenerierung — einen Antwortentwurf schreiben: hier gibt es keine saubere Metrik, und so zu tun als ob, ist der Punkt, an dem Teams anfangen, sich selbst zu belügen.
Die Regel darunter: eine Zahl pro Fehlermodus, der Sie interessiert — nicht eine Zahl insgesamt. Ein einzelner Gesamtwert ist ein Wert, mit dem Sie nichts anfangen können.
LLM-as-Judge: stark im Vergleich, schwach in Noten
Ein Modell Ausgaben bewerten zu lassen funktioniert — innerhalb zweier harter Grenzen. Es funktioniert im paarweisen Vergleich: Welche dieser beiden Antworten ist, gegeben diese Quellpassage, die bessere? Und es funktioniert bei engen, prüfbaren Fragen: Ist jede Sachaussage in dieser Antwort durch die Passage gedeckt — ja oder nein? Diese Groundedness-Prüfung ist ehrlich nützlich und billig im Betrieb.
Es funktioniert nicht für absolute Noten. Ein Judge, der „7,5 von 10“ ausgibt, erzeugt eine plausibel aussehende Zahl, er misst nichts; lassen Sie ihn erneut laufen, steht dort 8. Es funktioniert nicht, wenn der Judge Ausgaben seiner eigenen Modellfamilie bewertet — die bevorzugt er. Und es funktioniert nicht dort, wo dem Judge das Fachwissen fehlt: Kein Modell sagt Ihnen, ob dieses Anzugsmoment für diese Maschinenvariante stimmt. Das kann nur Ihr Techniker. Zwei praktische Gewohnheiten: Tauschen Sie die Reihenfolge von A und B und lassen Sie zweimal laufen — Positionsbias ist real, und ein Urteil, das kippt, heißt, der Judge rät. Und nehmen Sie zum Bewerten eine andere Modellfamilie als die, die geprüft wird.
Das System evaluieren, nicht das Modell
Die teuerste Gewohnheit in diesem Feld ist, nach einem größeren Modell zu greifen, wenn die Zahl schlecht ist. Fast immer ist das Modell nicht der kaputte Teil — und ein einzelner Ende-zu-Ende-Wert kann Ihnen das niemals sagen, weil er alle Stufen in eine Zahl zusammenfaltet.
Beim Maschinenbauer ist dieses Muster keine Erfindung. Wenn ein Serviceassistent schlecht abschneidet, liegt es typischerweise an einer Antwort, die in einer Tabelle stand, die der Parser zu Rauschen plattgewalzt hat. Die Lösung sind ein tabellenfähiger Parser und besseres Chunking: ein paar Tage Arbeit, keine zusätzliche Inferenz. Das Modell-Upgrade hätte monatlich mehr gekostet, dauerhaft, und nichts bewegt.
Messen Sie immer beide Sichten. Die Stufenmetriken sagen Ihnen, wo Sie arbeiten müssen; der Ende-zu-Ende-Wert sagt Ihnen, ob die Arbeit etwas gebracht hat — denn Stufen, die einzeln gut aussehen, können zusammen trotzdem schlecht sein. Keine ersetzt die andere. Und beide überstehen den Kontakt mit der Produktion nur, wenn jemand sie nach dem Start weiterlaufen lässt.
Prompts und Modelle sind Code — testen Sie sie wie Code
Ein Prompt ist Code ohne Typsystem und ohne Compiler. Ändern Sie ein Wort, und die Wirkung zieht sich durch die Ausgaben auf eine Weise, die niemand durch Lesen vorhersagt. Behandeln Sie ihn entsprechend: Prompts liegen in Git, nicht in einem Datenbankfeld, das jemand am Dienstagnachmittag editiert. Jede Änderung lässt das Golden Set laufen. Ausgaben werden gespeichert, damit Sie letzte Woche gegen diese Woche diffen können.
Der Punkt, den Teams übersehen: Pinnen Sie den Modell-Snapshot. Zeigt Ihr Code auf einen gleitenden Alias wie „latest“, kann Ihr Anbieter das Modell unter Ihnen austauschen — und das Verhalten Ihres Systems ändert sich an einem Morgen, an dem Sie gar nichts ausgeliefert haben. Das von innen zu debuggen ist zermürbend, weil jeder Instinkt sagt „schau in deinen eigenen Diff“, und da ist keiner. Nutzen Sie datierte Snapshot-Bezeichner und behandeln Sie ein Modell-Upgrade als das, was es ist: ein Deployment. Set laufen lassen, Diffs lesen, dann umstellen.
Golden Sets verderben außerdem. Ändert sich das Produkt, werden vormals richtige Antworten still falsch — und ein Set, das seit einem Jahr niemand durchgesehen hat, ist schlechter als gar keins: Es meldet grün und misst dabei das Falsche. Planen Sie eine Durchsicht ein, wann immer sich der zugrunde liegende Prozess ändert.
Wo Tippel ins Spiel kommt
Fast nichts davon ist Technik. Es ist Urteilsvermögen: welche Fälle ins Set gehören, welche Metrik zur Aufgabe passt, welche Stufe Ihnen tatsächlich die Punkte kostet. Genau das leistet der KI-Readiness-Check auf Ihren Daten — ein zeitlich begrenzter Blick zum Festpreis, der mit einer Zahl endet, mit der Sie arbeiten können, und mit einer ehrlichen Einschätzung, ob der Weg zu „gut genug“ eine Woche Chunking-Arbeit ist oder ein Problem, das die aktuelle Modellgeneration nicht löst.
Wenn Sie ein System haben, das sich gut vorführen lässt, und wissen wollen, was es wirklich leistet, bevor Sie einen Prozess darauf aufbauen — dann ist das das Gespräch. Nehmen Sie Kontakt auf.