Sie haben eine Eval-Suite erstellt. Sie besteht. Sie stellen die Änderung bereit. Unmittelbar danach melden Nutzer Regressionen, die Ihre Evals nicht erkannt haben.
Dies ist eines der häufigsten – und entmutigendsten – Muster beim produktiven Einsatz von LLMs: Eval-Suites sehen überzeugend aus, übersehen aber relevante Regressionen. Sie erzeugen falsche Sicherheit. Das Team vertraut ihnen, liefert qualitätsmindernde Änderungen aus und entdeckt das Problem erst durch Nutzerbeschwerden.
Eval-Suites zu erstellen, die tatsächlich Regressionen erkennen, ist schwieriger, als es aussieht. Die Grundlagen (Datensatz, erwartete Ausgaben, Bewertung) sind einfach. Die Herausforderung liegt darin, zuverlässige Signale zu erzeugen.
Dieser Artikel fasst zusammen, was wir über belastbare Eval-Suites für Teams gelernt haben, die produktive KI-Qualität ernst nehmen.
Was gute Evals leisten
Eine gute Eval-Suite liefert bei der Ausführung einer Kandidatenänderung mit hoher Sicherheit eine Antwort auf die Frage: „Ist diese Änderung besser, schlechter oder gleichwertig mit der aktuellen Version?“
Die entscheidenden Merkmale:
- Erkennt Regressionen. Wenn die Qualität auf realen Mustern sinkt, sinkt auch der Eval-Score.
- Erkennt Verbesserungen. Wenn die Qualität steigt, spiegelt sich das im Score wider (nicht nur bei ausgewählten Fällen).
- Stabil ohne materielle Änderungen. Wenn sich nichts Wesentliches geändert hat, bleibt der Score konsistent.
- Vertrauenswürdig für Entscheidungen. Entscheidungen, die auf Eval-Scores basieren, korrelieren mit tatsächlichen Nutzererlebnissen.
Jeder dieser Punkte ist schwieriger, als er klingt.
Das Datensatzproblem
Ihr Eval ist nur so gut wie Ihr Datensatz. Die meisten fehlgeschlagenen Eval-Suites scheitern hier.
Häufige Datensatzfehler
Fehler 1: Handverlesene einfache Fälle. Der Datensatz entstand, als das System funktionierte – häufig durch den Engineer, der es entwickelt hatte. Ausgewählt wurden leicht verständliche Beispiele für jedes Verhalten. Der reale Produktivverkehr ist unordentlicher: Schwierige, mehrdeutige und seltene Randfälle verursachen die meisten Fehler, sind im Datensatz aber unterrepräsentiert.
Fehler 2: Veralteter Datensatz. Der Datensatz wurde vor sechs Monaten erstellt. Seitdem haben sich das Nutzerverhalten, die Feature-Bereiche und die Produktfunktionen verändert. Der Datensatz testet eine veraltete Realität.
Fehler 3: Keine Abdeckung regressionsanfälliger Bereiche. Das Eval deckt den Happy Path gründlich ab, prüft aber nicht die Grenzen, an denen Regressionen tatsächlich auftreten.
Fehler 4: Kontamination des Datensatzes. Eval-Beispiele erscheinen zugleich im Prompt oder in den Fine-Tuning-Daten. Das Modell „erinnert“ sich an sie. Dadurch werden Testergebnisse künstlich erhöht, während die reale Leistung schlechter ist.
Fehler 5: Unausgewogene Verteilung. 80 % des Datensatzes bestehen aus einem Eingabetyp; nur 5 % bilden den Long Tail ab. Eine Regression im Long Tail verändert den Gesamtscore kaum, obwohl sie real ist.
Einen starken Datensatz erstellen
Einige Prinzipien, die starke Datensätze erzeugen:
Aus realem Produktivverkehr gewinnen. Die besten Beispiele sind echte Nutzereingaben, aus denen personenbezogene Daten entfernt wurden. Sie enthalten genau die Unordnung, die Ihr System bewältigen muss.
Ein praktischer Workflow:
- Erfassen Sie unter angemessenen Datenschutzkontrollen eine Stichprobe produktiver Aufrufe.
- Kennzeichnen Sie die erwarteten Ausgaben manuell oder zunächst per LLM und anschließend mit menschlicher Prüfung.
- Fügen Sie den Fall in den Eval-Datensatz ein.
- Aktualisieren Sie den Datensatz regelmäßig (monatlich ist ein guter Rhythmus).
Vielfältige Fehlermodi einbeziehen. Nehmen Sie gezielt Fälle auf, die im Produktivbetrieb bereits fehlgeschlagen sind. Sie werden zu Regressionstests: Nach jeder Fehlerbehebung kommt der auslösende Fall in den Datensatz, damit der Fehler nicht zurückkehrt.
Datensatz stratifizieren. Kategorisieren Sie Fälle (leicht/mittel/schwer, nach Thema, Nutzerart, Länge). Stellen Sie sicher, dass jede Kategorie eine sinnvolle Abdeckung hat. Verfolgen Sie Scores pro Kategorie, nicht nur insgesamt.
Schwierigkeitsgrade mischen. Nutzen Sie einige einfache Fälle, um katastrophale Regressionen zu erkennen, überwiegend mittlere Fälle aus dem realen Verkehr und einige schwierige Randfälle. Ein ausschließlich schwieriger Datensatz schwankt bei kleinen Änderungen stark; ein ausschließlich einfacher reagiert kaum auf reale Regressionen.
Angemessene Größe wählen. Bei zu wenigen Fällen sind die Statistiken verrauscht; bei zu vielen werden die Läufe langsam und teuer. Typische Größen:
- Klassifizierung: 200–500 Fälle.
- Generierung: 50–200 Fälle.
- Komplexe Agentenflüsse: 20–50 Fälle.
Sie können immer mit kleineren Größen beginnen und sich dann weiterentwickeln.
Konsequent aktualisieren. Prüfen Sie den Datensatz monatlich. Ergänzen Sie neue Fehlermodi, entfernen Sie veraltete Fälle und aktualisieren Sie erwartete Ausgaben, wenn sich das gewünschte Verhalten geändert hat.
Das Metrikproblem
Was Sie messen, bestimmt, wonach Sie optimieren. Die Auswahl schlechter Metriken ist der zweithäufigste Eval-Fehler.
Häufige Metrikfehler
Fehler 1: Einzelne Zahlen verbergen Probleme. Eine Gesamtgenauigkeit von 90 % kann verbergen, dass eine wichtige Kategorie von 95 % auf 70 % gefallen ist, während andere sich verbessert haben. Der Durchschnitt sieht gut aus.
Lösung: Aufschlüsselung pro Kategorie. Immer.
Fehler 2: Die Metrik misst das Falsche. Eine „Richtigkeits“-Metrik für Kundensupportantworten kann übersehen, dass die Antwort zwar richtig, aber unhöflich ist. Die Metrik erfasst nicht den Ton.
Lösung: Mehrdimensionale Bewertung. Richtigkeit + Ton + Länge + Format getrennt.
Fehler 3: Unempfindlich gegenüber dem Schweregrad. Eine falsche Antwort wird gleich bewertet, unabhängig davon, ob es sich um einen unbedeutenden Fehler oder eine gefährliche Halluzination handelt.
Lösung: Gewichtete Bewertung. Schwere Fehler zählen mehr. Einige Fehler zählen als 0 (Sicherheitsverstöße); einige als -1 (katastrophale Fehler, schlimmer als nichts).
Fehler 4: Bimodale Empfindlichkeit. Der Score geht entweder von 100 % auf 99 % (unwahrnehmbar) oder von 100 % auf 50 % (katastrophal). Feine Regressionen werden nicht sichtbar.
Lösung: Graduierte Bewertung. Jede Ausgabe wird auf einer kontinuierlichen Skala (1–5 oder 0–1) bewertet, nicht binär.
Fehler 5: Aggregation über Nutzergruppen hinweg. Der Durchschnitt aller Nutzer verschleiert, dass die Leistung bei einer 10-%-Untergruppe stark eingebrochen ist.
Lösung: Aufschlüsselung nach relevanten Segmenten wie Nutzertarif, Abfragetyp und Sprache.
Starke Metriken erstellen
Mehrdimensional. Jede Ausgabe erhält getrennte Scores für Richtigkeit, Tonalität, Format, Sicherheit, Länge und weitere relevante Aspekte.
Gewichtet. Einige Dimensionen zählen mehr als andere. Gewichten Sie sie in jeder zusammengesetzten Metrik.
Kalibrierte Schweregrade. Unterscheiden Sie innerhalb einer Dimension zwischen geringfügigen und schwerwiegenden Fehlern. Eine sachlich falsche Antwort ist gravierender als eine leicht abweichende.
Metriken je Kategorie. Berichten Sie Scores nach relevanten Segmenten: leicht, mittel und schwer, je Thema sowie je Nutzertyp.
Trend über die Zeit. Ein einzelner Score ist nicht nützlich; ein Trend ist es. Zeichnen Sie Scores über die Zeit auf. Erkennen Sie Drift.
Nutzerorientiert. Die Metriken sollten mit dem korrelieren, was Nutzer tatsächlich wichtig finden. Wenn Nutzer über Unhöflichkeit klagen, messen Sie Unhöflichkeit. Wenn Nutzer über Länge klagen, messen Sie Länge.
Das Judge-Problem
Wenn Sie LLM-as-a-Judge einsetzen – ein LLM bewertet die Ausgabe eines anderen –, ist dieses Judge-Modell Ihr Bewertungsmechanismus. Ist es verzerrt oder falsch, sind Ihre Evals wertlos.
Häufige Judge-Fehler
Fehler 1: Längenbias. LLM-Judges neigen dazu, längere Antworten zu bevorzugen. Sie bewerten eine längere Antwort höher, auch wenn sie überladen ist.
Fehler 2: Formatbias. Judges bevorzugen strukturierte Ausgaben (Aufzählungen, Überschriften) gegenüber Prosa, unabhängig davon, was für die Aufgabe besser ist.
Fehler 3: Selbstpräferenz. Stammt das Judge-Modell aus derselben Familie wie das bewertete Modell, bewertet es Ausgaben der eigenen Familie tendenziell besser.
Fehler 4: Gefälligkeit. Judges übernehmen die vorgegebene Rahmung. Die Aussage „Die vorherige Version war schlecht; bewerten Sie die neue“ führt zu künstlich erhöhten Scores für die neue Version.
Fehler 5: Fehlende Verankerung. Judges bewerten nach Eindrücken statt anhand konkreter Kriterien. Derselbe Prompt erhält in verschiedenen Durchläufen unterschiedliche Bewertungen.
Starke Judges erstellen
Mit Menschen kalibrieren. Lassen Sie eine Stichprobe der Judge-Bewertungen von Menschen erneut bewerten. Bei Abweichungen verfeinern Sie den Judge-Prompt oder akzeptieren, dass diese Dimension menschliche Prüfung erfordert.
Ein anderes Judge-Modell verwenden. Nutzen Sie nach Möglichkeit ein Modell aus einer anderen Familie als das bewertete System. Dies reduziert Selbstpräferenz.
Seien Sie explizit bezüglich Kriterien. Der Judge-Prompt sollte genau beschreiben, was gut und schlecht aussieht, mit Beispielen. Vage Kriterien führen zu vagen Bewertungen.
Suggestive Formulierungen vermeiden. Sagen Sie dem Judge nicht: „Bewerten Sie dies auf einer Skala, auf der die meisten Ausgaben gut sind.“ Verankern Sie die Bewertung an konkreten Verhaltensweisen.
Verankerte Bewertungsrubriken. Definieren Sie für jede Stufe Beispiele: „Score 5: sachlich korrekt, konkret, gut strukturiert. Score 4: überwiegend korrekt, möglicherweise fehlt ein Detail. Score 3: …“ Mit solchen Ankern bleibt der Judge konsistent; ohne sie driftet er.
Erzwingen Sie strukturierte Ausgaben. Der Judge erzeugt strukturierte Scores (pro Dimension mit Begründung), nicht freie Texte. Einfacher zu aggregieren und zu prüfen.
Ein starker Judge-Prompt sieht so aus:
You are evaluating an AI assistant's response.
User query: {query}
Assistant response: {response}
Score on the following dimensions, on a scale of 1-5:
1. Factual accuracy: Are all claims correct? (5 = all correct, 4 = mostly correct with minor issues, 3 = some incorrect, 2 = many incorrect, 1 = mostly wrong)
2. Relevance: Does the response address the user's actual question? (5 = perfectly addresses, 1 = doesn't address)
3. Completeness: Does the response contain enough information? (5 = complete, 1 = severely incomplete)
4. Tone: Is the response appropriately professional? (5 = perfect tone, 1 = inappropriate)
For each score, provide:
- The score
- A one-sentence specific reason
- The specific text in the response that supports your score
Output JSON: {"accuracy": {"score": N, "reason": "...", "evidence": "..."}, ...}
Führen Sie den Judge auf einem von Menschen bewerteten Kalibrierungsdatensatz aus. Passen Sie ihn an, bis seine Bewertungen innerhalb einer akzeptablen Toleranz mit den menschlichen Urteilen übereinstimmen.
Eval-Suites für die Produktion entwerfen
Einige Muster, die in der Produktion funktionieren:
Suite 1: Die Regressionssuite
Eine definierte Menge von 200–500 Testfällen, die das System vor jeder Bereitstellung bestehen muss. Sie wird aus realen Fehlern, Randfällen und bekannten guten Mustern kuratiert und ändert sich selten.
Dies ist Ihre „darf nicht brechen“-Suite. Jeder Pull Request führt sie in der CI aus; bei einer Regression wird der Merge blockiert.
Suite 2: Der Smoke-Test
Eine kleine Untergruppe (10–30 Fälle), die häufig ausgeführt wird. Schnelle Rückmeldung während der Entwicklung. Erkennt katastrophale Regressionen sofort.
Integration: Pre-Commit-Hook oder schneller Smoke-Test vor dem Haupt-Eval.
Suite 3: Die Discovery-Suite
Ein größerer, vielfältigerer Datensatz mit Tausenden aus realem Produktivverkehr gewonnenen Fällen. Er läuft seltener, beispielsweise wöchentlich, und sucht nach Mustern, die kleinere Suiten übersehen könnten.
Integration: Geplanter Job. Ergebnisse werden in wöchentlichen Qualitätssitzungen besprochen.
Suite 4: Die Online-Suite
Eine Stichprobe aus realer Produktion, bewertet automatisch (LLM-Judge) oder über Nutzersignale. Erkennt Drift, den Offline-Evals verfehlen.
Integration: Kontinuierlich, dashboardbasiert.
Suite 5: Die User-Flow-Suite
End-to-End-Tests, die vollständige Nutzerabläufe statt einzelner LLM-Aufrufe prüfen. Sie eignen sich für Agentensysteme und mehrstufige Workflows.
Integration: Vor Deployment großer Änderungen.
Ein reifes Produktionssystem hat alle fünf. Beginnen Sie mit der Regressionssuite; fügen Sie andere hinzu, wenn die Kapazität wächst.
Kosten- und Zeitdisziplin
Evals kosten Geld (LLM-Aufrufe) und Zeit (Ausführung, Prüfung).
Ein Eval mit 500 Fällen und einem Spitzenmodell als Judge kann €5–20 je Lauf kosten. Bei 10 Pull Requests pro Tag entstehen €50–200 täglich. Das ist handhabbar, aber relevant.
Strategien:
Smoke-Test im Pull Request, vollständige Suite beim Merge. Das spart Kosten bei Pull Requests, die nicht zusammengeführt werden.
Ergebnisse zwischenspeichern. Wenn weder der Prompt noch das Modell geändert wurde, müssen Sie nichts erneut ausführen. Zwischenspeichern nach (prompt_version, model, dataset_version).
Wo möglich günstigere Judges verwenden. Ein günstigeres, gut kalibriertes Judge-Modell ist häufig ausreichend.
Parallelisieren. Eval-Läufe lassen sich nahezu vollständig parallel ausführen. Nutzen Sie Parallelität.
Stichprobe statt vollständigem Lauf. Prüfen Sie bei Routineänderungen 50 Fälle aus einem Datensatz mit 500 Fällen; führen Sie die vollständige Suite bei wichtigen Änderungen aus.
Das Zeitbudget lautet meist: „Wie lange kann ein Pull Request warten?“ Ziel ist ein vollständiger Eval-Lauf in weniger als 15 Minuten. Danach wechseln Engineers den Kontext und verlieren Produktivität.
Betriebsmuster
Einige Praktiken, die reife Eval-Programme unterscheiden:
Muster 1: Durch Evals gesperrte Deployments
Produktiv-Deployments von Änderungen mit Einfluss auf das LLM werden durch Eval-Ergebnisse gesperrt. Fällt der Score unter den Schwellenwert, wird die Bereitstellung blockiert und ein Engineer untersucht die Ursache.
Der Schwellenwert ist üblicherweise relativ: „Der Score muss innerhalb von 2 % der Baseline liegen.“ Das toleriert Messrauschen, erkennt aber wesentliche Regressionen.
Muster 2: Untersuchung bei Score-Veränderungen
Jede bedeutende Score-Veränderung (aufwärts oder abwärts) wird untersucht. Score stieg? Warum? Haben wir uns verbessert, oder wurde der Test leichter? Score sank? Wo genau? Ist die Regression auf einen Slice beschränkt?
Reagieren Sie auf aggregierte Veränderungen weder euphorisch noch panisch; untersuchen Sie die Ursache.
Muster 3: Kontinuierliche Datensatzpflege
Der Datensatz ist kein einmaliges Projekt, sondern wird fortlaufend gepflegt:
- Nutzer klagt über eine Antwort → fügen Sie sie als Regressionstest hinzu.
- Neues Feature wird veröffentlicht → fügen Sie Fälle, die es abdecken, hinzu.
- Modellverhalten überrascht jemanden → wenn es ein echter Fehlschlag ist, fügen Sie es hinzu.
- Nicht mehr relevante Fälle → außer Betrieb nehmen.
Eine monatliche Prüfungssitzung funktioniert gut. Der Datensatz wird als lebendiges Asset behandelt.
Muster 4: Diff-basierte Prüfung
Bei der Prüfung eines Eval-Ergebnisses konzentrieren Sie sich auf Diffs von der Baseline:
- Fälle, bei denen die neue Version höher als Baseline bewertet wurde (Verbesserungen).
- Fälle, bei denen die neue Version niedriger bewertet wurde (Regressionen).
- Fälle, bei denen der Score gleich blieb (kein Signal).
Der Diff ist das Signal. Die lineare Prüfung von 500 Fällen ist unpraktisch; die Prüfung von 30 Diffs ist machbar.
Muster 5: Menschliche Prüfung von Judge-Unterschieden
Prüfen Sie regelmäßig, beispielsweise wöchentlich, Stichproben von Fällen, denen der Judge niedrige und hohe Scores gegeben hat. Die menschliche Prüfung beantwortet: Stimmen Sie dem Judge zu?
Unterschiede zeigen:
- Judge-Voreingenommenheit (kalibrieren Sie den Judge-Prompt).
- Echte Qualitätsschwächen (beheben Sie das System).
- Datensatzprobleme (der erwartete Output des Falls ist falsch).
So halten Sie die Judge-Qualität über die Zeit aufrecht.
Muster 6: Quartalsweise Eval-Prüfung
Eine quartalsweise Retrospektive über das Eval-Programm selbst:
- Welche echten Regressionen hat die Eval-Suite in diesem Quartal erkannt?
- Welche echten Regressionen hat sie verfehlt?
- Welche Fehlalarme hat sie erzeugt?
- Welche Lücken in der Abdeckung kennen wir?
- Wie gut deckt der Datensatz das aktuelle Verhalten im Produktivbetrieb ab?
Das ist Meta-Evaluation: die Bewertung der Evaluation. Ohne sie verliert das Eval-Programm an Qualität.
Ein vollständiges Beispiel: Eval für den Kundensupport
Zur Veranschaulichung folgt ein produktionsreifes Eval-Setup für ein KI-Kundensupportsystem.
Ziel: Sicherstellen, dass die Antworten der KI auf Kundenanfragen korrekt, hilfreich, markenkonform und sicher sind.
Datensätze:
-
Regressionssuite (300 Fälle):
- 50 einfache Fälle (klare Richtlinien, einfache Antworten).
- 100 mittlere Fälle (typische Komplexität).
- 100 schwierige Fälle (unklar, sensibel, mehrfach).
- 50 bekannte Fehlfälle (vorherige Regressionsszenarien).
-
Discovery-Suite (1000 Fälle): Monatlich aus realem Produktivverkehr gezogen und von personenbezogenen Daten bereinigt.
-
Adversarial-Suite (50 Fälle): Speziell entworfene Prompts, die versuchen, Informationen zu extrahieren, Rückerstattungen in nicht berechtigten Fällen zu erlangen oder die KI zu manipulieren.
Metriken:
Für jeden Fall bewertet der Judge:
- Faktenkorrektheit (1–5)
- Richtlinienkonformität (1–5)
- Tonangemessenheit (1–5)
- Vollständigkeit (1–5)
- Angemessenheit der Länge (1–5)
- Sicherheit (binär: bestanden/nicht bestanden)
Judges:
- Primärer Judge: Claude (ein anderer Anbieter als das getestete GPT-System; dies reduziert den Selbstpräferenz-Bias derselben Modellfamilie).
- Anhand von 100 Referenzfällen mit einem menschlichen Prüfer kalibriert.
- Vierteljährliche Neukalibrierung.
Aggregation:
- Durchschnittlicher Score je Dimension und Segment (Tickettyp, Kundentarif, Sprache).
- Passrate bei Sicherheit (muss 100 % sein).
- Gewichteter Score je Fall (für Diffs).
Betriebsabläufe:
- Smoke-Test (30 Fälle) bei jedem Pull Request.
- Vollständige Regressionssuite (300 Fälle) bei PR-Merge.
- Discovery-Suite (1000 Fälle) wöchentlich.
- Adversarial-Suite (50 Fälle) vor jeder Prompt- oder Modelländerung.
- Online-Stichprobe von 1 % des Produktivverkehrs, in Echtzeit bewertet.
Prüfung:
- Monatliche Sitzung: Prüfung von Eval-Trends, neuen Fehlmodi, Datensatzaktualisierungen.
- Vierteljährliche Sitzung: Meta-Eval, Judge-Kalibrierung und Datensatzprüfung.
Ergebnisse (aus realen Deployments ähnlicher Systeme):
- Rund 3 Regressionen pro Monat, die ohne Evals ausgeliefert worden wären.
- Rund 1 Fehlalarm pro Monat (das Eval meldet eine Regression, die tatsächlich unproblematisch ist).
- Drift wird innerhalb von Tagen erkannt, nicht Wochen/Monaten.
- Vertrauen in das Deployment von Prompt- und Modelländerungen gestiegen.
So sehen produktionsreife Evals aus: kein schnelles Wochenendprojekt, sondern eine fortlaufende Investition mit echtem ROI.
Häufige Fallen
Einige Muster, die wir häufig sehen:
Fallstrick 1: Eval erstellen, nachdem das Produkt geliefert wurde. „Wir fügen Evals später hinzu.“ Später kommt nie. Erstellen Sie sie von Tag 1 an.
Fallstrick 2: Verantwortung bei einer Einzelperson. Eine Person erstellt das Eval, niemand sonst pflegt es. Verlässt sie das Team, verfällt das Eval. Verteilen Sie die Verantwortung.
Fallstrick 3: Eval als statisch behandeln. Einmal erstellt, nie aktualisiert. Wird nutzlos, wenn das Produkt sich entwickelt. Behandeln Sie die Eval als lebendiges Asset.
Fallstrick 4: Eval-Scores blind vertrauen. Das Eval meldet eine Verbesserung, also stellen Sie die Änderung bereit. Ohne menschliche Stichproben liefern Sie möglicherweise Ergebnisse aus, die das Eval hoch bewertet, Nutzer aber ablehnen. Kombinieren Sie Evals bei wichtigen Änderungen mit menschlicher Prüfung.
Fallstrick 5: Optimieren auf den Eval. Prompts speziell anpassen, um gut auf dem Eval zu abschneiden. Der Eval verbessert sich; die Realität nicht. Achten Sie darauf — wenn Eval-Verbesserungen nicht durch Produktverbesserungen begleitet werden, optimieren Sie auf den Test.
Fallstrick 6: Infrastrukturkosten ignorieren. Evals im großen Maßstab sind teuer (LLM-Aufrufe summieren sich). Ohne Kostenverfolgung entdecken Sie es am Ende des Monats.
Fallstrick 7: Keine klaren Pass/Fail-Kriterien. „Der Score ging von 4,2 auf 4,0 — ist das eine Regression?“ Definieren Sie Schwellenwerte im Voraus. Halten Sie sich an sie.
Fallstrick 8: Die Eval-Suite bindet die gesamte Testkapazität. Aufwendige Evals entstehen, während grundlegende Korrektheitstests fehlen. Evals prüfen Qualitätsdrift; nicht jeder Test ist ein Eval.
Der kulturelle Teil
Der schwierigste Teil der Produktions-Evals ist kulturell. Ingenieure und Produktleute müssen:
- Den Evals genug vertrauen, um Deployments durch sie sperren zu lassen. Andernfalls sind Evals nur Theater.
- Den Evals genug misstrauen, um Veränderungen zu untersuchen. Blindes Vertrauen führt zur Optimierung auf den Test.
- In die Datensatzpflege als laufende Arbeit investieren. Nicht ein Einmalprojekt.
- Akzeptieren, dass Evals menschliches Urteilsvermögen nicht ersetzen. Sie reduzieren lediglich den Umfang der menschlichen Prüfung.
- Erkennen, wenn eine Eval-Suite nicht funktioniert. Wenn reale Regressionen unentdeckt bleiben, liegt das Problem bei der Eval-Suite und nicht beim Nutzer, der sie meldet.
Teams mit dieser Kultur deployen schneller und zuverlässiger. Teams ohne diese Kultur finden sich schließlich entweder übermäßig auf fehlerhafte Evals angewiesen oder gelähmt durch deren Abwesenheit.
Der Takeaway
Eval-Suites erstellen, die tatsächlich Regressionen erkennen, ist schwieriger, als es aussieht, aber machbar.
Die Schlüssel:
- Realistische, diverse Datensätze, die aus der Produktionsrealität stammen.
- Mehrdimensionale, segmentbezogene Metriken, die dem Nutzererlebnis entsprechen.
- Kalibrierte Judges, die Sie tatsächlich gegen menschliche Urteile geprüft haben.
- Mehrere Eval-Suites für unterschiedliche Zwecke (Regression, Smoke, Discovery, Online, End-to-End).
- Betriebsdisziplin: durch Evals gesperrte Deployments, fortlaufende Datensatzpflege und Untersuchung von Veränderungen.
- Kulturelle Verpflichtung, die Evals über die Zeit zu nutzen und zu verbessern.
Gut umgesetzt werden Evals zum wertvollsten Teil der Infrastruktur Ihres KI-Stacks. Mit ihnen stellen Sie Änderungen schnell bereit und bewahren zugleich die Qualität. Ohne sie fliegen Sie blind.
Erstellen Sie die Evals. Vertrauen Sie auf die Evals. Verbessern Sie die Evals. So wird die Qualität von KI-Systemen in der Produktion aufrechterhalten.
