Der LLM-Evals-Stack: So messen Sie Ihr KI-Feature wirklich

Die Fähigkeit, für die niemand ausgebildet wurde

Jedes Team liefert LLM-Features aus. Fast kein Team hat eine echte Möglichkeit zu wissen, ob diese Features gut sind.

Die Kohorte AI Evals For Engineers & PMs von Hamel Husain und Shreya Shankar hat mehr als 2.000 Praktiker ausgebildet, darunter Ingenieure und PMs von OpenAI und Anthropic. Der Grund, warum sie ausgebucht war, ist nicht Theorie. Es ist, dass die Leute, die dieses Zeug bauen, gemerkt haben, dass ihr QA-Prozess hieß: „Bitten Sie den Prompt-Engineer, 30 Outputs zu lesen und dem Bauchgefühl zu vertrauen."

Hamel nennt das eine „Vibes-Eval". Es ist die vorherrschende Praxis, und es ist der Grund, warum so viele KI-Features ausgeliefert werden, sich gut demoen lassen und dann leise verfallen. Im Podcast von Lenny's Newsletter argumentierten Hamel und Shreya, dass Evals heute die hebelwirksamste Fähigkeit in der KI-Produktarbeit sind, wichtiger als Prompt-Handwerk, wichtiger als die Wahl des richtigen Modells. Der Grund ist strukturell. Wenn Sie Qualität nicht messen können, können Sie sie auch nicht verbessern.

Die meisten Teams wissen das. Sie tun es trotzdem nicht. Warum? Weil Evals nach Infrastrukturarbeit aussehen, sie haben keinen klaren Verantwortlichen, und die erste Version fühlt sich immer schlechter an als das Lesen von Outputs von Hand. Der Trick ist, zu erkennen, dass „Outputs von Hand lesen" die Eval ist. Die Disziplin besteht darin, es einmal zu tun, aufzuschreiben, was Sie gesehen haben, und es nie wieder auf dieselbe Weise zu tun.

Dieser Beitrag ist das Playbook. Er ist absichtlich tool-unabhängig. Sie können diesen Stack mit Inspect AI vom UK AI Safety Institute, Phoenix von Arize, Promptfoo, Langfuse, dem OpenAI Evals framework, Anthropics Eval-Tooling oder einem Stapel Python-Skripte und einem Google Sheet betreiben. Die Methodik trägt das Gewicht.

Warum „Sieht gut aus" bei Skalierung nicht mehr funktioniert

Wenn Sie zum ersten Mal ein LLM-Feature ausliefern, ist „sieht gut aus" eine vernünftige Messlatte. Sie haben den Prompt geschrieben, zehn Eingaben getestet, die Outputs sehen vernünftig aus, Sie drücken auf Deploy.

Beim zweiten Mal stecken Sie in Schwierigkeiten.

LLM-Outputs sind per Design nicht-deterministisch. Temperatur 0 reduziert die Varianz, eliminiert sie aber nicht. Derselbe Prompt mit demselben Modell kann zwischen Läufen leicht unterschiedliche Antworten erzeugen und zwischen Modellversionen erst recht. Dazu kommen die Dinge, die sich unter Ihnen ändern:

Modell-Drift. Anbieter aktualisieren Modelle mit demselben Namen. GPT-4o heute ist nicht GPT-4o von vor drei Monaten. Derselbe String in Ihrer Konfiguration, anderes Verhalten. Sie bekommen keine Benachrichtigung.
Verteilungs-Shift. Die Eingaben, die echte Nutzer senden, sind nicht die Eingaben, mit denen Sie getestet haben. Kürzere Prompts, andere Sprachen, seltsame Formatierungen, Anhänge. Der lange Schwanz ist dort, wo Evals am wichtigsten sind.
Prompt-Entropie. Jedes Mal, wenn jemand den System-Prompt bearbeitet, um die Beschwerde eines Nutzers zu beheben, riskieren Sie, drei andere Anwendungsfälle zu brechen, von denen Sie vergessen haben, dass es sie gibt. Ohne Evals ist das unsichtbar, bis Support-Tickets in die Höhe schnellen.
Retrieval-Drift. Wenn Sie RAG verwenden, ändert sich Ihr Index ständig. Der Retrieval-Anteil Ihrer Pipeline verschlechtert sich still und leise.

Die versteckte Abgabe ist die Zeit Ihres Teams. Jede Änderung wird zu einem halben Tag, an dem sich jemand durch Prompts klickt. Jedes Modell-Update wird zu einer „Lass mich ein paar prüfen"-Übung, die eine Woche dauert. Jede Eskalation wird zu einer einmaligen Untersuchung, weil niemand beantworten kann: „Ist das eine Regression, oder war es bei Anfragen wie dieser schon immer kaputt?"

Echte Evals machen diese Fragen billig zu beantworten. Die Kosten fallen im Voraus an. Die Einsparungen wachsen kumulativ.

Die Anatomie eines LLM-Eval-Stacks

Es gibt fünf Schichten. Sie bauen aufeinander auf. Eine Schicht zu überspringen bedeutet, dass die darüberliegenden Rauschen bewerten.

Schicht	Zweck	Tool-Beispiele	Fallstricke
1. Traces	Jede Eingabe, Ausgabe, jeden Tool-Call, Retrieval-Satz, Latenz und Kosten aus Produktionsläufen erfassen	Langfuse, Phoenix, OpenTelemetry exporters	Zu aggressives Sampling; fehlende Tool-Call-Payloads; PII in Logs
2. Fehleranalyse	50 bis 100 echte Traces mit Open Coding bearbeiten, Fehlerarten clustern, eine Fehler-Taxonomie aufbauen	Notion, Airtable, eine CSV	Diesen Schritt überspringen; eine Person macht es allein ohne Kalibrierung
3. Golden Dataset	50 bis 100 handgelabelte Beispiele, die jeden Fehlermodus und den Happy Path abdecken	Inspect AI dataset format, JSONL, Ihr eigenes Schema	Nur synthetische Daten; keine Abdeckung der in Schritt 2 gefundenen Fehlerarten
4. LLM-as-Judge	Ein Bewertungsmodell mit einer Rubrik, validiert gegen menschliche Labels auf >=85 % Übereinstimmung	OpenAI Evals, Promptfoo, Inspect AI, custom	Einen nie validierten Judge verwenden; Single-Judge-Scoring; Rubrik-Drift
5. CI-Integration	Die Eval bei jedem PR laufen lassen, Merges bei Regression blockieren, bei Verschlechterung alarmieren	GitHub Actions, GitLab CI, custom runners	Zu langsamer Lauf; keine Kostenobergrenze; Preisspitzen beim Judge-Modell

Die Reihenfolge zählt. Sie können kein Golden Dataset aufbauen, ohne zuerst herauszufinden, welche Fehlerarten existieren (Fehleranalyse), und Sie können keine Fehleranalyse ohne Traces machen. Sie können keinen Judge ohne ein gelabeltes Golden Set validieren. Sie können die Pipeline nicht in CI laufen lassen, bis der Judge tatsächlich vertrauenswürdig ist.

Aakash Guptas schrittweise Aufarbeitung des Hamel/Shreya-Curriculums geht dasselbe Skelett mit leicht unterschiedlicher Benennung durch, und es ist das Naheliegendste, was es in diesem Feld an einer Konsensform gibt. Wir gehen Schicht für Schicht durch.

Schritt 1: Traces erfassen

Ein Trace ist die vollständige Aufzeichnung einer LLM-Interaktion. Nicht nur Eingabe und Ausgabe, sondern alles, was das System dazwischen getan hat.

Ein nützlicher Trace enthält:

Die vollständige Nachrichtenhistorie (System-Prompt, User-Turns, Assistant-Turns)
Den Modellnamen und die Version, genau so wie aufgerufen
Alle Tool-Calls, ihre Argumente und ihre Antworten
Für RAG: die Retrieval-Abfrage, die zurückgegebenen Dokumente, die Scores, die tatsächlich im finalen Prompt verwendeten Dokumente
Token-Zahlen, nach Phasen aufgeschlüsselte Latenz und Kosten in Dollar
Eine Request-ID, die Sie zur User-Session zurück joinen können
Alle Feedback-Signale (Daumen hoch, Copy-Klick, Regenerate, abgebrochen)

Das Prinzip: Der Trace ist die Quelle der Wahrheit. Wenn Sie nicht allein aus dem Trace genau rekonstruieren können, was das Modell gesehen und getan hat, ist Ihre Eval ein Folgeprodukt von Vermutungen.

Beim Sampling ist der Trade-off Volumen gegen Kosten. Loggen Sie für ein Produkt mit hohem Traffic 100 % der Traces, behalten Sie aber vollständige Payloads nur für eine Stichprobe (5 bis 10 %), der Rest wird auf Metadaten reduziert. Loggen Sie 100 % der Fehler-Traces (Tool-Call-Fehler, Timeouts, Retrievals mit niedriger Konfidenz, negatives Feedback). Das ist Ihre Goldmine.

Zu PII: Traces werden Nutzerdaten enthalten. Wenden Sie dieselben Redaktions- und Aufbewahrungsregeln an, die Sie für jedes andere Produktions-Log verwenden. Die meisten Teams hashen User-IDs, entfernen E-Mails und rotieren Logs nach einem 30- bis 90-Tage-Plan.

Wenn Sie Ihr eigenes bauen, schreiben Sie einen kleinen Wrapper um Ihr LLM-SDK, der strukturiertes JSON an Ihre Logging-Pipeline sendet. Das Format zählt weniger als die Disziplin, immer zu loggen.

Schritt 2: Fehleranalyse (Open Coding)

Das ist der Schritt, den alle überspringen, und es ist der Schritt, der alles andere zum Laufen bringt.

Shreya Shankars Forschung übernimmt eine Technik aus der qualitativen Forschung namens Open Coding. Sie setzen sich mit 50 bis 100 echten Traces hin. Sie lesen sie. Sie kommentieren, was falsch (oder richtig) ist. Sie geben keine Kategorien im Voraus vor. Sie lassen die Kategorien aus den Daten entstehen.

Konkret:

Ziehen Sie 100 Traces aus der Produktion. Mischen Sie Zufallsstichproben mit Traces, die durch negatives Feedback, Fehler oder hohe Latenz markiert sind.
Öffnen Sie eine Tabelle. Spalten: Trace-ID, Eingabezusammenfassung, Ausgabezusammenfassung, Problem (Freitext), Schweregrad (1 bis 3), Tags (zunächst leer).
Schreiben Sie für jeden Trace in einfacher Sprache, was falsch ist. Nicht „schlechte Ausgabe". Spezifisch: „halluzinierte einen Funktionsnamen, der im Code des Nutzers nicht existiert" oder „antwortete in der falschen Sprache" oder „lehnte eine harmlose Anfrage ab".
Nach 20 bis 30 Traces tauchen dieselben Probleme immer wieder auf. Beginnen Sie, sie zu taggen. Zwei-Wort-Tags sind in Ordnung.
Gruppieren Sie nach allen 100 die Tags. Sie werden typischerweise mit 5 bis 15 unterschiedlichen Fehlerarten plus „sieht okay aus" enden.

Das ist Ihre Fehler-Taxonomie. Hamel beschreibt das in seinen Field Notes on LLM Evals als den Moment, in dem vage Bedenken zu testbaren Aussagen werden. „Der Bot halluziniert manchmal" wird zu „Der Bot halluziniert Funktionsnamen in 8 % der Code-bezogenen Anfragen, besonders wenn Variablennamen ungewöhnlich sind." Dafür kann man eine Eval schreiben.

Ein zweites Augenpaar zählt. Lassen Sie jemand anderen dieselben 30 Traces unabhängig kodieren. Wo Sie sich uneinig sind, ist die Taxonomie unscharf und muss geschärft werden. Das ist derselbe Inter-Annotator-Agreement-Check, den Sie später auf den LLM-Judge anwenden werden.

Schritt 3: Ein Golden Dataset aufbauen

Ein Golden Dataset ist eine feste Menge von Eingaben, erwarteten Verhaltensweisen und Labels, gegen die Ihre Pipeline ausgewertet wird. Stellen Sie es sich als Ihre Regressionstest-Suite für ein LLM vor.

Größe: 50 bis 100 Beispiele sind ein echter Startpunkt. Nicht 10 (zu rauschig). Nicht 1.000 (zu teuer, zu langsam). Erweitern Sie es, wenn Sie neue Fehlerarten finden, aber die erste Version sollte klein genug sein, dass ein Mensch an einem Nachmittag jedes Beispiel lesen kann.

Abdeckung: jede Fehlerart aus der Fehleranalyse braucht mindestens 5 bis 10 Beispiele. Plus 20 bis 30 Happy-Path-Beispiele. Plus ein paar Edge Cases (sehr lang, sehr kurz, nicht-Englisch, adversariell). Der arXiv-Aufsatz Constructing Domain-Specific Evaluation Sets for LLM-as-a-judge ist zur Abdeckungsstrategie lesenswert.

Aufnahmekriterien:

Echte Nutzereingaben statt synthetischer. Nur-synthetisch ist eine bekannte Falle: Es neigt dazu, wie Prompts auszusehen, die Ihr Team schreiben würde, nicht wie das, was Nutzer tatsächlich senden.
Jedes Beispiel hat ein gelabeltes erwartetes Ergebnis. Für offene Generierung ist das eine Rubrik (muss X, darf nicht Y, idealerweise Z), kein wörtlich erwarteter String.
Jedes Beispiel ist mit einer oder mehreren Fehlerarten getaggt.
Sensible Daten sind bereinigt.

Labeling-Rubrik: Schreiben Sie auf, wie „gut" aussieht. Für manche Aufgaben Exact-Match (wurde die richtige API aufgerufen). Für die meisten ist es eine Rubrik aus Eigenschaften: „muss mindestens ein abgerufenes Dokument zitieren", „darf nicht ablehnen", „muss in der Sprache des Nutzers sein", „darf keine Funktionsnamen erfinden". Jede Eigenschaft ist ein binärer Check.

Refresh-Kadenz: Ziehen Sie einmal pro Quartal eine frische Charge von 50 bis 100 Produktions-Traces und wiederholen Sie das Open Coding. Neue Fehlerarten werden hinzugefügt. Alte, die nicht mehr auftreten, bleiben (Sie wollen Regressionsabdeckung). Wenn sich das Modell oder der Prompt bedeutsam ändert, machen Sie einen außerplanmäßigen Refresh.

Die zu vermeidende Falle: Lassen Sie das Team, das den Prompt schreibt, nicht auch das Golden Dataset allein schreiben. Es wird sich an die Stärken des Prompts überanpassen. Lassen Sie jemanden außerhalb der täglichen Prompt-Arbeit mindestens die Hälfte der Beispiele labeln.

Schritt 4: LLM-as-Judge mit menschlicher Validierung

Für Aufgaben ohne eine einzige richtige Antwort (Zusammenfassung, Klassifikation mit unscharfen Kategorien, offene Q&A) brauchen Sie einen Weg, Outputs in Skalierung zu bewerten. Manuelles Scoring läuft nicht bei jedem PR.

LLM-as-Judge ist die Technik: Verwenden Sie einen separaten LLM-Aufruf, um die Ausgabe Ihrer Pipeline gegen die Rubrik zu bewerten. Es funktioniert. Confident AIs Analyse von LLM-as-Judge-Methoden berichtet, dass die Judge-Mensch-Übereinstimmung in 2025-2026 über mehrere Benchmarks hinweg die 85 %-Marke überschritten hat, was etwa dem Übereinstimmungsniveau entspricht, das zwei Menschen bei subjektiven Aufgaben miteinander zeigen. Es ist nicht perfekt, aber gut genug, um nützlich zu sein, wenn Sie es validieren.

Die Methodik der Reihe nach:

Schreiben Sie eine Rubrik für den Judge. Nicht „ist diese Antwort gut". Spezifisch: „Zitiert die Antwort mindestens eines der bereitgestellten Dokumente? J/N. Lehnt die Antwort ab, wenn sie das nicht sollte? J/N. Erfindet die Antwort Funktionsnamen, die nicht im Code des Nutzers sind? J/N." Binär oder Short-Likert. Judges sind schlecht bei 1-10-Skalen.
Wählen Sie ein Judge-Modell. Ein starkes Allzweckmodell (GPT-4-Klasse oder Claude Sonnet/Opus-Klasse) übertrifft kleinere Modelle in der Regel, aber für hohe Volumina an Eval-Läufen ist ein günstigerer Judge in Ordnung, wenn Sie ihn validieren.
Labeln Sie Ihr Golden Set von Hand. Zwei Menschen, unabhängig. Berechnen Sie das Inter-Annotator-Agreement (Cohens Kappa oder einfache prozentuale Übereinstimmung bei einer Binärgröße). Wenn Menschen sich nicht über 80 bis 85 % einig sind, ist Ihre Rubrik zu unscharf. Schärfen Sie sie.
Lassen Sie den Judge auf demselben Set laufen. Vergleichen Sie Judge-Labels mit menschlichen Labels. Wenn die Judge-Mensch-Übereinstimmung unter 80 % liegt, ist Ihr Rubrik-Prompt für den Judge falsch, oder das Judge-Modell ist zu schwach. Iterieren Sie am Judge-Prompt.
Liefern Sie den Judge erst aus, wenn die Übereinstimmung bei oder über 85 % liegt. Darunter automatisieren Sie Rauschen.

Häufige Fehler:

Einen einzelnen Judge-Aufruf ohne Validierung verwenden. Die Übereinstimmung könnte bei 60 % liegen. Sie würden es nie erfahren.
Dasselbe Modell zum Generieren und Bewerten verwenden. Es gibt einen bekannten Selbstpräferenz-Bias. Verwenden Sie wenn möglich eine andere Modellfamilie für den Judge.
Die Judge-Rubrik von der menschlichen Rubrik abdriften lassen. Sie müssen derselbe Prompt sein. Wenn Sie eine anpassen, neu validieren.
Einen Judge-Aufruf als Ground Truth verwenden. Für hochwichtige Evals lassen Sie den Judge mit drei unabhängigen Aufrufen laufen und nehmen das Mehrheitsvotum. Uneinigkeit zwischen Judge-Aufrufen ist selbst ein Signal.

Einmal validiert, kann der Judge in Minuten Tausende von Outputs für wenige Dollar bewerten. Das ist die Auszahlung. Sie gehen von „wir evaluieren vor jedem Release" zu „wir evaluieren bei jedem PR".

Schritt 5: In CI/CD integrieren

Der ganze Sinn dieses Stacks ist, dass niemand daran denken muss, Evals laufen zu lassen. CI tut es.

Eine praktikable Form:

Bei jedem PR, der Prompts, Modellkonfigurationen oder Pipeline-Code berührt: lassen Sie die Golden-Eval laufen. Blockieren Sie den Merge, wenn eine Metrik um mehr als einen Schwellenwert sinkt (sagen wir 3 Prozentpunkte bei Genauigkeit oder jede Regression bei einem harten Check wie „darf harmlose Anfragen nicht ablehnen").
Bei jedem Modellversions-Upgrade: lassen Sie die volle Eval auf produktionsäquivalenter Infrastruktur laufen. Vergleichen Sie nebeneinander.
Auf nächtlichem Zeitplan: lassen Sie die Eval gegen eine Stichprobe frischer Produktions-Traces laufen. Das fängt Verteilungs-Shift ab, den das statische Golden Set verpasst.
Kostenobergrenzen: deckeln Sie das Eval-Budget pro PR. Ein vernünftiger Standard ist $1 bis $5 pro Lauf. Wenn Ihre Eval mehr kostet, ziehen Sie eine Stichprobe aus dem Golden Set oder verwenden einen günstigeren Judge für PR-Zeit-Evals und den vollen Judge für Releases.

Ein Muster, das funktioniert: eine „schnelle Eval" mit 20 bis 30 Beispielen bei jedem Commit (unter 2 Minuten) und eine „volle Eval" mit 100 bis 300 Beispielen bei PR-Freigabe und auf Main. Dieselbe Pipeline, unterschiedliche Stichprobengrößen.

Reporting zählt. Der PR-Kommentar sollte die Gesamt-Bestehensrate, die Bestehensrate pro Fehlermodus, den Diff gegen Main und Links zu fehlgeschlagenen Traces zeigen. Vergraben Sie das nicht in einer Log-Datei.

Alarmieren Sie bei Baseline-Drift. Wenn die nächtliche Bestehensrate um 5 Punkte fällt und zwei Tage dort bleibt, hat sich etwas geändert (ein Modell-Update, eine Änderung am Retrieval-Index, ein nachgelagerter Dienst). Die Eval ist auch Ihre Monitoring-Schicht.

Anti-Muster, die Entwickler immer wieder ausliefern

Ein paar Muster, auf die Sie achten sollten, weil sie in echten Teams immer wieder auftauchen:

Bauchgefühl-Evals in die Produktion ausgeliefert. Ein Ingenieur überfliegt 20 Outputs, sagt „auslieferen", und das Feature geht live. Drei Wochen später kann niemand beantworten: „Ist das besser als letzte Woche?"

Scoring mit einem einzigen nicht validierten Judge. Jemand liest über LLM-as-Judge, schreibt einen einzeiligen Prompt („bewerte das von 1 bis 10") und beginnt, Entscheidungen auf den Scores zu treffen. Die Scores sind Rauschen.

Keine Fehler-Taxonomie. Das Team hat Open Coding übersprungen. Das Golden Set wurde aus dem Kopf von jemandem geschrieben. Es überpasst sich an offensichtliche Fälle und verpasst jeden interessanten Fehlermodus, den echte Nutzer treffen.

Kein Check auf menschliche Übereinstimmung. Wenn sich zwei Menschen nicht über die Labels einig sind, ist die „Übereinstimmung" des Judges mit einem von ihnen bedeutungslos.

Nur synthetische Daten. Das Golden Set wird von einem anderen LLM generiert. Sieht großartig aus. Besteht jede Eval. Die Produktion bricht, weil echte Nutzereingaben nicht wie LLM-generierte Eingaben aussehen.

Eine Zahl, die alles zusammenfasst. „Unser Eval-Score liegt bei 87 %." Worauf? Über welche Fehlerarten? Bestehensraten pro Fehlermodus sind erforderlich. Ein Aggregat verbirgt die Fehler, die wichtig sind.

Eval als nachträglicher Gedanke. Wird als vierteljährliche Übung behandelt statt als kontinuierliche Pipeline. Veraltet innerhalb eines Release-Zyklus. Niemand vertraut ihr.

Der 7-Tage-Eval-Plan für ein Team ohne Evals

Wenn Sie bei null anfangen, hier eine Woche, die Sie zu einer funktionierenden Pipeline bringt.

Tag 1: Traces erfassen. Wählen Sie ein LLM-Feature. Fügen Sie Logging hinzu, das Eingabe, Ausgabe, Tool-Calls, Retrieval-Kontext (falls vorhanden), Modellversion und eine Request-ID erfasst. Leiten Sie es dorthin, wo Ihre Logs leben. Wählen Sie noch kein Tool; eine JSONL-Datei funktioniert für Woche eins. Ziel am Ende des Tages: über 100 Traces aus der Produktion.

Tag 2: Open Coding, Runde eins. Ziehen Sie 50 Traces. Eine Person liest sie. Freitext-Annotation, was falsch oder richtig ist. Kategorisieren Sie noch nicht. Beschreiben Sie nur.

Tag 3: Open Coding, Runde zwei. Eine zweite Person macht dieselben 50. Notizen vergleichen. Bauen Sie die Fehlermodus-Taxonomie aus den Mustern. Streben Sie 5 bis 12 benannte Fehlerarten an. Schätzen Sie die grobe Häufigkeit für jede.

Tag 4: Golden Dataset v0. Nehmen Sie 50 bis 80 Beispiele, die jeden Fehlermodus plus den Happy Path abdecken. Labeln Sie jedes mit einer Rubrik: was über eine gute Antwort wahr sein muss. Speichern Sie es als JSONL oder eine Tabelle, das ist egal, aber speichern Sie es in der Versionskontrolle.

Tag 5: Den Judge bauen. Schreiben Sie einen Judge-Prompt, der jede Rubrik-Eigenschaft als Binärwert bewertet. Wählen Sie ein Judge-Modell aus einer anderen Familie als Ihr Produktionsmodell. Lassen Sie es auf dem Golden Set laufen.

Tag 6: Den Judge validieren. Lassen Sie zwei Menschen dasselbe Golden Set gegen dieselbe Rubrik labeln. Berechnen Sie Mensch-Mensch-Übereinstimmung und Judge-Mensch-Übereinstimmung. Wenn Judge-Mensch unter 80 % liegt, iterieren Sie am Judge-Prompt. Hören Sie auf, wenn Sie 85 % erreichen oder Tag sechs zu Ende geht. Wenn Sie nicht auf 85 % kommen, ist Ihre Rubrik das Problem. Schärfen Sie die binären Fragen.

Tag 7: CI verdrahten. Eine GitHub Action, die die Eval bei PRs laufen lässt, die Prompts oder Pipeline-Code berühren. Geben Sie einen Kommentar mit Bestehensrate, Aufschlüsselung pro Fehlermodus und Links zu fehlgeschlagenen Traces aus. Setzen Sie ein Budget. Setzen Sie einen Regressions-Schwellenwert.

Ende der Woche: Sie haben Traces, eine Taxonomie, ein Golden Set, einen validierten Judge und ein CI-Gate. Den ganzen Stack. Er ist klein, und das ist der Punkt. Von hier an wächst er kumulativ.

Nach Woche eins werden Sie die meiste Ihrer Eval-Zeit für drei Dinge aufwenden: das Golden Set ausbauen, die Rubrik schärfen, wenn Sie Mehrdeutigkeiten finden, und Regressionen untersuchen, die von CI gefangen wurden. Nichts davon erfordert einen weiteren großen Aufbau.

Häufig gestellte Fragen

Was ist der Unterschied zwischen einer Bauchgefühl-Eval und einer echten Eval?

Eine Bauchgefühl-Eval ist „Ich habe 20 Outputs gelesen und es sieht besser aus." Eine echte Eval hat: eine feste Eingabemenge, eine schriftliche Rubrik, einen Bewertungsmechanismus, der nicht davon abhängt, wer gerade liest, und einen Weg, zwei Läufe zu vergleichen. Der schnellste Lackmustest: Wenn Sie nicht beantworten können „wie war der Eval-Score letzte Woche und diese Woche und welche Fehlerarten haben regressiert", haben Sie keine echte Eval.

Wie groß sollte mein Golden Dataset sein?

50 bis 100 Beispiele für die erste Version. Groß genug, um jede Fehlerart mit 5 bis 10 Fällen abzudecken, klein genug, dass ein Mensch alles an einem Nachmittag lesen kann. Erweitern Sie es im Laufe der Zeit, wenn Sie neue Fehlerarten in der Produktion finden. Die meisten ausgereiften Pipelines liegen bei 200 bis 500 Beispielen; sehr wenige profitieren davon, über 1.000 hinauszugehen, es sei denn, sie evaluieren über viele verschiedene Anwendungsfälle hinweg.

Stimmt LLM-as-Judge tatsächlich mit Menschen überein?

Wenn Sie es validieren, ja. Confident AIs Forschung berichtet von einer Judge-Mensch-Übereinstimmung über 85 % auf validierten Rubriken in 2025-2026, was ungefähr dem Niveau entspricht, mit dem zwei Menschen übereinstimmen. Der Haken: Das gilt nur, wenn Sie den Judge zuerst gegen menschliche Labels kalibriert haben. Ein aus einem Tutorial kopierter, nie validierter Judge-Prompt ist nur eine Meinungsmaschine.

Brauche ich ein spezialisiertes Eval-Tool, oder kann ich mein eigenes bauen?

Für Woche eins bauen Sie Ihr eigenes. JSONL-Dateien, ein Python-Skript, eine Tabelle für Labels. Sobald Sie das ausgewachsen haben (normalerweise wenn mehrere Personen labeln müssen oder Sie ein UI zum Durchsuchen von Traces wollen), wählen Sie ein Tool. Inspect AI, Phoenix, Promptfoo, Langfuse und das OpenAI Evals framework decken alle dieselbe Grundform mit unterschiedlicher Ergonomie ab. Die Methodik ist der Burggraben, nicht das Tool.

Wann sollte ich mein Golden Dataset neu labeln?

Vierteljährlich als Baseline. Außerplanmäßig, wenn Sie Modelle wechseln, wenn Sie den Prompt bedeutsam ändern, wenn Support-Tickets mit einem neuen Fehlermodus in die Höhe schnellen oder wenn Ihre nächtliche Eval gegen frische Produktions-Traces zeigt, dass das Golden Set nicht mehr repräsentativ ist.

Schlussgedanken

Die Teams, die die nächsten zwei Jahre der KI-Produktarbeit gewinnen, sind nicht die mit den cleversten Prompts. Es sind die, die an irgendeinem Dienstag beantworten können: „Ist unser KI-Feature heute besser als letzten Monat, und in welchen Dimensionen, und für welche Nutzer." Das ist eine Eval-Frage, keine Prompt-Frage.

Die Methodik hat sich stabilisiert: Traces, Fehleranalyse, Golden Dataset, validierter Judge, CI-Loop. Fünf Schichten, jede in ein bis zwei Tagen von einem kleinen Team baubar. Die Lücke zwischen Teams, die einen Eval-Stack haben, und Teams, die keinen haben, wird schnell größer.

Wenn Sie ein LLM-Feature ausgeliefert haben und die Regressionsfrage nicht mit Zuversicht beantworten können, ist Ihre Aufgabe für Woche eins keine weitere Prompt-Anpassung. Es ist eine JSONL-Datei, fünfzig Traces und eine Tabelle mit Labels. Der Rest des Stacks fällt daraus ab. Klein anfangen, rücksichtslos validieren, die Pipeline vor dem nächsten Feature ausliefern.