Fehleranalyse zuerst

Eine einzige Tätigkeit trennt zuverlässig zwei Arten von Teams. Die einen machen ihr KI-Produkt besser, die anderen treten auf der Stelle. Diese Tätigkeit ist keine Technik. Sie besteht darin, sich hinzusetzen und zu lesen, was Ihr System echten Nutzern tatsächlich geliefert hat.

Hamel Husain und Shreya Shankar haben diesen Prozess mehr als 2.000 Fachleuten aus über 500 Unternehmen beigebracht. Sie sagen es klar: Fehleranalyse ist die wichtigste Tätigkeit bei Evals. Erst sie sagt Ihnen, welche Evals Sie überhaupt schreiben sollten. Ihr Erfahrungswert: 60–80 % der Entwicklungszeit an einem LLM-Produkt gehen in Fehleranalyse und Evaluation. Nicht als eigene Phase, sondern als Kern der Arbeit.

Diese Zahl klingt beim ersten Lesen falsch. Das ändert sich, sobald Sie die Alternative betrachten: Prompt-Änderungen raten und ausliefern. Ein großer Teil davon ist unbezahlte Nacharbeit.

Warum das zuerst kommen muss

Ein Eval ist eine Frage, die Sie immer wieder stellen. Wer sie schreibt, bevor er seine Fehlermodi kennt, rät die Frage. Die Rateversuche sind vorhersehbar und vorhersehbar falsch. Teams greifen zu Flüssigkeit, Hilfsbereitschaft, Tonfall und einem „Qualitäts“-Wert von 1 bis 5. Monate später entdecken sie das eigentliche Problem: Die Suche hat nie Dokumente aus den letzten 30 Tagen gefunden.

Es gibt noch einen tieferen Grund. Er hat einen Namen.

Befund: Kriteriendrift. Shankar et al. (UIST 2024) haben eine Zwickmühle in der LLM-Evaluation dokumentiert. Um Ausgaben zu bewerten, müssen Sie Ihre Kriterien aufschreiben. Aber erst beim Bewerten entdecken Sie, was Ihre Kriterien sind. Manche Kriterien hängen von den konkreten Ausgaben ab, die Sie gesehen haben. Sie lassen sich vorab gar nicht festlegen. Das ist der formale Grund, warum eine Rubric vor dem Lesen der Daten weniger wert ist als eine danach.

Die Reihenfolge ist also keine Geschmacksfrage. Wer die Rubric zuerst schreibt, versucht etwas, das laut Forschung nicht gut gelingen kann.

Die Schleife

1. Traces vor einen Menschen bringen

Ein Trace ist die vollständige Aufzeichnung einer Interaktion: Eingabe, gefundener Kontext, Tool-Aufrufe, Zwischenschritte, endgültige Ausgabe und genug Metadaten, um den Ablauf nachzuvollziehen. Nicht nur die letzte Antwort.

Ziehen Sie eine Stichprobe aus echtem Verkehr, wenn Sie ihn haben. Wenn nicht, erzeugen Sie ein strukturiertes synthetisches Set. Datensatz-Design zeigt, wie das geht, ohne sich selbst zu täuschen.

Beginnen Sie mit 50–100 Traces. Diese Zahl nennen Husain und Shankar. Sie reicht meist, um die häufigsten Fehlermodi zu finden.

2. Offenes Kodieren

Lesen Sie jeden Trace. Schreiben Sie eine kurze Notiz in Freitext: Was ist falsch? Keine Kategorie, sondern ein Satz in Ihren eigenen Worten. Ist an einem Trace nichts falsch, schreiben Sie auch das hin. Ab und zu notieren Sie einen Satz dazu, warum die Antwort gut war. Aus diesen Sätzen werden später die Positivbeispiele Ihrer Labelrichtlinie. Ohne sie lernt ein Judge nur, Fehler zu finden.

Zwei Regeln zählen mehr, als sie aussehen:

• Notieren Sie den ersten Fehler, den Sie sehen. Weitere nur, wenn sie keine Folge des ersten sind. Spätere Probleme sind oft nur Folgen des ersten. Wer alle erfasst, bläht die Zahl der Folgen auf und verdeckt die Ursache. Ein zweiter Fehler ohne Zusammenhang mit dem ersten ist aber keine Folge. Beispiel: Der Preis ist falsch, und die zweite Frage bleibt unbeantwortet. Notieren Sie ihn und markieren Sie ihn als zweitrangig. Die Rangliste zählt die erstrangigen Fehler. Die zweitrangigen zeigen Ihnen, welche Klassen Sie sonst unterschätzen.
• Verwenden Sie keine vorgegebene Kategorienliste. Der ganze Sinn liegt darin, Kategorien zu entdecken, die Sie nicht aufgeschrieben hätten.

Umstritten: Husain und Shankar fassen die erste Regel strenger: ersten Fehler notieren, Trace schließen. Das ist einfacher und schützt vor dem Doppelzählen von Folgen. Der Preis: Fehlerklassen, die typischerweise neben einer anderen auftreten, landen in der Rangliste systematisch zu tief. Im durchgerechneten Beispiel wäre „übergeht die zweite Frage“ deshalb fast gestrichen worden. Die zweistufige Notiz ist unsere Abwägung, keine Regel aus der Quelle.

Vier Notizen aus einer Durchsicht. So geschrieben, wie Sie sie tatsächlich schreiben würden: grob, konkret, noch ohne Kategorien.

#0142  Nannte 50 € Gebühr. Auf der verlinkten Richtlinienseite steht 0 € für Plus-Mitglieder.
#0147  Nutzer fragte auf Deutsch, Antwort kam auf Englisch. Inhalt war in Ordnung.
#0151  Sagte „ich habe das storniert", rief das Storno-Werkzeug aber nie auf. Nichts passiert.
#0158  Zitierte die Rückgaberichtlinie bei einer Frage zur Lieferung. Komplett falsches Dokument.

Achten Sie darauf, wie unspektakulär das ist. Genau so soll es sein. Der Wert steckt in der Konkretheit. „Nannte 50 €, Richtlinie sagt 0 €“ ist eine Notiz, mit der Sie arbeiten können. „Halluzination“ ist keine.

3. Axiales Kodieren

Gruppieren Sie die Freitext-Notizen zu einer Fehlertaxonomie. Das ist eine Menge klar getrennter, benannter Fehlermodi. Dieser Schritt verwandelt Lesen in Wissen. Und es ist der Schritt, den viele überspringen.

Ein LLM ist hier wirklich nützlich. Fügen Sie die Notizen ein, bitten Sie um eine Gruppierung, und korrigieren Sie sie dann. Die Kategorien entscheiden Sie. Das mühsame Sortieren übernimmt das Modell.

Eine brauchbare Taxonomie hat Kategorien, auf die eine Korrektur zielen kann. „Schlechte Antwort“ ist keine Kategorie. „Zitiert ein Dokument, das die Aussage nicht enthält“ schon.

4. Zählen

Zählen Sie die Traces pro Kategorie. Das ist der eigentliche Zweck der Übung. Aus „das Modell halluziniert manchmal“ wird eine Rangliste.

Wir führen die vier Notizen von oben weiter. Nach 100 durchgesehenen und gruppierten Traces:

Zwei Dinge lesen Sie an dieser Tabelle ab. Beide sind der Zweck der ganzen Übung.

Erstens der Nenner. 42 von 100 Traces sind durchgefallen. Die Prozentzahlen sind aber Anteile an den Fehlern, nicht am gesamten Verkehr. „31 % Zitationsfehler“ heißt 13 Traces von 100, nicht 31. Diese Verwechslung ist der häufigste Grund, warum Zahlen aus der Fehleranalyse im Standup falsch wiedergegeben werden.

Zweitens die Rangfolge. Sie ist meist nicht die, die das Team erwartet hat. Antworten in der falschen Sprache lösen laute Beschwerden aus und fühlen sich wie das Hauptproblem an. Hier stehen sie auf Platz vier. Zitationsfehler lösen keine einzige Beschwerde aus, denn der Nutzer kann sie nicht erkennen. Sie stehen auf Platz eins.

Diese Umkehrung ist normal. Deshalb ist Zählen besser als Erinnern.

5. Bei Sättigung aufhören

Befund: Hören Sie auf, wenn neue Traces keine neuen Kategorien mehr liefern. Die Faustregel von Husain und Shankar: etwa 20 aufeinanderfolgende Traces ohne neuen Fehlermodus. Das absolute Minimum liegt bei rund 100 gesichteten Traces, bevor Sie dem Bild trauen.

Quelle: Husain & Shankar, LLM Evals FAQ

Das ist theoretische Sättigung, ein Begriff aus der qualitativen Forschung. Dort ist sie empirisch untersucht, nicht nur behauptet. Guest, Bunce und Johnson werteten 60 Tiefeninterviews systematisch aus. Nach zwölf Interviews tauchten keine neuen Themen mehr auf. Die Grundzüge standen schon nach sechs. Die Größenordnung der Faustregel oben ist also nicht erfunden. Sie deckt sich mit einem gemessenen Ergebnis aus einer ganz anderen Disziplin.

Quelle: Guest, Bunce & Johnson, How Many Interviews Are Enough?, Field Methods 18(1), 2006, S. 59–82 · DOI 10.1177/1525822X05279903

Das ist eine echte Abbruchregel, kein Bauchgefühl. Deshalb ist Fehleranalyse endliche Arbeit und keine unbegrenzte Verpflichtung.

Was man mit dem Ergebnis macht

Jetzt kommt der Teil, der viele überrascht: Das meiste, was Sie finden, ist kein Eval.

Ein großer Teil der gefundenen Fehler sind gewöhnliche Bugs. Ein abgeschnittenes Kontextfenster. Ein Tool, das eine Fehlermeldung zurückgibt, und das Modell hält sie für Daten. Ein Prompt, der sich selbst widerspricht. Die beheben Sie. Dafür brauchen Sie keine Kennzahl.

Bauen Sie einen automatischen Grader nur für Fehler, die nach der offensichtlichen Korrektur bestehen bleiben. Und nur, wenn Sie wiederholt daran arbeiten werden. Die Kostenstaffel ist steil:

Ein LLM-Judge ist ein echtes Stück Technik mit echter Wartungslast. Bauen Sie keinen für einen Fehlermodus, den Sie zweimal gesehen haben.

Wer liest

Für die meisten kleinen und mittleren Teams gilt: Ernennen Sie einen Fachexperten zur entscheidenden Instanz. Husain nennt ihn den „wohlwollenden Diktator“. Eine Person setzt den Maßstab. Andere beraten. Streit über Labels frisst keine Meetings mehr. Mehrere Annotatoren sind gerechtfertigt, wenn Sie wirklich mehrere Fachgebiete oder Kulturkreise bedienen. Nicht als Fairness-Geste aus Gewohnheit.

Wer auch immer liest: Senken Sie die Reibung. Ein einziger Bildschirm mit Eingabe, Trace und zwei Knöpfen bringt das Zehnfache an Durchsicht gegenüber einer Tabelle plus Log-Viewer. Ein eigener Viewer gehört zu den lohnendsten internen Werkzeugen, die ein LLM-Team bauen kann. Meist ist er an einem Nachmittag fertig.

Am Leben halten

Fehleranalyse ist keine Phase. Der Verkehr verschiebt sich. Nutzer lernen, das Produkt anders zu verwenden. Und Sie liefern Änderungen aus.

• Alle 2–4 Wochen: 100+ frische Traces sichten und die Taxonomie neu aufstellen. Kategorien kommen und gehen.
• Wöchentlich, dazwischen: 10–20 Traces überfliegen, mit Schwerpunkt auf Ausreißern: auffällige Latenz, Wiederholungen, von Nutzern gemeldete Antworten.

Das ist Arbeit auf Ebene C. Und diese Ebene versagt still. Nichts geht kaputt, wenn ein Team aufhört, Traces anzusehen. Die Dashboards zeigen weiter Zahlen. Die Zahlen bedeuten nur nichts mehr.

Häufiger Fehler: Von „wir haben Fehler gefunden“ direkt zu „wir brauchen für jeden einen Judge“ springen. Die meisten Fehler sind Bugs. Die meisten übrigen fängt eine code-basierte Prüfung besser. Der Judge ist für das, was wirklich Lesen und Deuten von Text erfordert.