Fehleranalyse für LLM-Anwendungen: erst die Traces lesen, dann Evals schreiben

Warum generische Kennzahlen täuschen

Viele Teams mit einem KI-Produkt im Pilotbetrieb protokollieren längst jeden Aufruf, haben aber keine Definition dessen, was bei ihrem Produkt als Fehler gilt. Fertige Scores für Hilfsbereitschaft oder Ähnlichkeit wirken wie eine Abkürzung, aber niemand hat sie an echten Fehlern geprüft. Husain und Shankar warnen, dass generische Evaluierungen Zeit kosten und falsche Sicherheit erzeugen, wenn man sie als Qualitätsmaß verwendet, und der Evaluierungsleitfaden von OpenAI führt zu allgemeine Metriken wie BLEU unter den Anti-Patterns.

Ein Support-Assistent kann bei der Relevanz gut abschneiden und dabei eine Rückgabefrist nennen, die sich im letzten Monat geändert hat. Die Fehleranalyse ersetzt die Vermutung durch Beobachtung: Sie lesen echte Traces, schreiben in einfachen Worten auf, was schiefging, gruppieren die Notizen zu Fehlertypen und zählen sie. Husain und Shankar beschreiben die Methode als aus der qualitativen Forschung übernommen, wo die beiden Schritte Open Coding und Axial Coding heißen. Das Engineering-Team von Anthropic ergänzt, dass Sie ohne das Lesen von Transkripten und Bewertungen aus vielen Durchläufen nicht wissen, ob Ihre Bewertungslogik funktioniert.

Wie viele Traces und wer sie liest

Husain und Shankar empfehlen, mindestens 100 Traces zu prüfen und weiterzulesen, solange Sie noch dazulernen. Ihre Abbruchregel ist wichtiger als die Zahl: Hören Sie auf, wenn neue Traces keine neuen Fehlertypen mehr zeigen und die bestehenden nicht mehr verändern. In der qualitativen Forschung heißt dieser Punkt theoretische Sättigung.

Ihre Seite zur Fehleranalyse nennt eine zweite Zahl. Schlägt ein KI-Agent Labels vor, annotieren Sie zuerst mindestens 30 Traces selbst, bevor Sie seine Vorschläge ansehen, innerhalb eines Pools von rund 100 unterschiedlichen Traces. Rund 100 Traces bis zur Sättigung sind die Analyse, 30 sind das Minimum, das ein Mensch von Hand bewertet, bevor ein Agent mithilft.

Ziehen Sie aktuelle Traces über alle Kanäle, Sprachen und wichtigen Anliegen. Wenn Sie von Nutzern markierte Traces hinzunehmen, weisen Sie diese getrennt aus, damit sie die Fehlerquoten nicht verzerren.

Husain und Shankar sind eindeutig: Lesen sollte eine Fachperson, etwa die Leitung des Kundenservice oder die Sachbearbeiterin, deren Arbeit das System nachbildet. Ein Engineer allein entdeckt fehlerhaftes JSON und übersieht eine falsche Erstattungsregel. Traces aus der Produktion enthalten oft personenbezogene Daten, klären Sie die Pseudonymisierung also vor der Sitzung.

Ein Label und eine Notiz pro Trace

Für jeden Trace hält die Fachperson bestanden oder nicht bestanden fest und bei einem Fehler ein oder zwei Sätze in eigenen Worten. Husain und Shankar beobachten, dass Annotierende auf Bewertungsskalen zur Mitte tendieren, um schwierigen Entscheidungen auszuweichen, und empfehlen binäre Labels, um zu verstehen, wie ein schlechtes Ergebnis aussieht. Auch OpenAI empfiehlt Pass/Fail, wenn ein Modell bewertet.

Notieren Sie in langen Traces von Agenten oder Pipelines nur den ersten Fehler in der Kette. Frühe Fehler ziehen spätere nach sich, wie Husain und Shankar betonen: Wer einen frühen falschen Tool-Aufruf behebt, beseitigt oft auch die verworrene Antwort am Ende. Eine brauchbare Notiz ist so konkret, dass eine andere Person dasselbe Problem wiederfindet:

• Hat aus dem Betreff Bestellung 4812 statt 4821 übernommen, das Lieferdatum gehört also zu einer fremden Bestellung
• Nennt 14 Tage Rückgabefrist, die Richtlinie in der Wissensbasis sagt 30 Tage
• Kunde hat zweimal nach einem Menschen gefragt, der Assistent bot weiter FAQ-Links an

Wenn mehrere Personen labeln

Labeln mehrere Personen, lassen Sie zunächst alle dieselben 20 oder 30 Traces bewerten. Husain und Shankar empfehlen, die Übereinstimmung mit einer zufallskorrigierten Kennzahl wie Cohens Kappa zu messen. Wichtiger als die Zahl ist das Gespräch über die Abweichungen: Meist steckt eine ungeschriebene Regel dahinter, etwa ob eine richtige Antwort mit Duzen ein Fehler ist. Halten Sie sie schriftlich fest. Shankar und Kollegen haben beobachtet, dass sich Kriterien beim Bewerten verschieben, und nennen das Criteria Drift; sehen Sie frühe Labels später also noch einmal an.

Notizen gruppieren und zählen

Danach fassen Sie die Notizen zu Fehlertypen zusammen. Husain und Shankar nennen das den wichtigsten Schritt und schließen ihn mit einer Zählung der Fehler je Kategorie ab. Gute Kategorien sind eng genug, um eine Korrektur nahezulegen, und breit genug für mehrere Notizen. Ein LLM darf die Gruppierung entwerfen, entscheiden muss die Fachperson.

Ein hypothetisches Beispiel

Nehmen Sie einen hypothetischen deutschsprachigen Support-Assistenten eines Onlineshops für Haushaltsgeräte. Die Leiterin des Kundenservice las 100 Traces aus vier Wochen Chat. Die letzten 20 brachten noch einen neuen Fehlertyp, also las sie 20 weitere; diese ergaben keinen mehr, und sie hörte bei 120 auf. 41 Traces fielen durch, jeder gezählt unter seinem ersten Fehler:

Falsche Bestellabfragen und veraltete Regeln machen 20 der 41 Fehler aus, etwa die Hälfte, und ein generischer Score für Hilfsbereitschaft hätte beide übersehen, weil sich die Antworten gut lesen. Bei dieser Stichprobengröße ist weder 11 gegen 9 noch 9 gegen 7 eine belastbare Rangfolge.

Beheben, im Code prüfen oder einen Judge bauen

Nicht jeder Fehlertyp braucht einen Evaluator. Entscheiden Sie für jede Zeile, was ihn abstellt und woran Sie seine Rückkehr bemerken.

1. 1

   Beheben, wenn die Ursache offensichtlich ist

   Entfernen Sie das veraltete Dokument aus den Quellen und reparieren Sie den Kontext, der frühere Nachrichten verliert. Behalten Sie einige der ursprünglichen Traces als Regressionsfälle und bauen Sie keinen Judge für ein Problem, das es nicht mehr gibt.

2. 2

   Code-Prüfung schreiben, wenn der Fehler in den Daten sichtbar ist

   Ob das Bestell-Tool die Nummer des Kunden erhalten hat, ob die Antwort ohne Duzen auskommt, ob eine E-Mail Markdown enthält: Das prüfen jeweils wenige Zeilen Code. Husain und Shankar raten, in der CI deterministische Prüfungen gegenüber LLM-Judges zu bevorzugen, und die Dokumentation von Anthropic nennt codebasierte Bewertung die schnellste und verlässlichste Variante, der allerdings die Nuance fehlt.

3. 3

   Einen LLM-Judge nur bauen, wo Urteilsvermögen nötig ist

   Zu erkennen, dass ein Kunde einen Menschen sprechen will, ohne es zu sagen, verlangt Urteilsvermögen. Bauen Sie für diesen Fehlertyp einen Judge, der wie von Husain und Shankar empfohlen bestanden oder nicht bestanden zurückgibt, und vergleichen Sie seine Urteile mit den Labels der Fachperson, bevor Sie ihm vertrauen. Beginnen Sie mit höchstens zwei oder drei Judges.

Im Beispiel ergibt das drei Code-Prüfungen, einen Judge und zwei Korrekturen, die alle auf Fehler zurückgehen, die die Fachperson gesehen hat.

Was aus der Taxonomie wird

Die gelabelten Traces sind Ihr erstes Testset. Nicht bestandene Traces mit Kategorie und Notiz sind Fälle mit bekanntem Fehler, und bestandene Traces fangen Korrekturen ab, die normale Gespräche verschlechtern. Anthropic hält 20 bis 50 Aufgaben aus realen Fehlern für einen guten Anfang, 41 Fehler reichen also für den Start.

Die Kategorien werden zu Ihren Metriken: die Quote jedes Fehlertyps, gemessen mit seiner Prüfung oder seinem validierten Judge, statt eines einzigen Qualitäts-Scores. Wiederholen Sie die Analyse nach einem Wechsel von Modell, Kanal oder Produktlinie. Erzeugt das Produkt täglich Ausnahmen, hält eine laufende Prüfwarteschlange die Taxonomie aktuell; für Prozessagenten beschreiben wir sie in einem eigenen Leitfaden.

Wo Fehleranalyse schiefgeht

• Nur Beschwerden lesen; das verdeckt leise Fehler wie ein falsches Lieferdatum, das der Kunde geglaubt hat
• Engineers allein labeln lassen oder ein LLM labeln lassen, bevor ein Mensch mindestens 30 Traces selbst bewertet hat
• Kategorien, die so breit sind, dass sie keine Korrektur nahelegen, etwa Halluzination
• Bei einer festen Zahl aufhören, obwohl noch neue Typen auftauchen, oder noch lange weiterlesen, nachdem sich die Liste nicht mehr ändert

Ein praktischer erster Schritt: Exportieren Sie 100 aktuelle Traces, setzen Sie sich mit der Person zusammen, die die Arbeit kennt, schreiben Sie zu jedem Fehler einen Satz und vergleichen Sie die Liste dann mit den Metriken, die Sie ursprünglich verfolgen wollten.

LLM-Evaluierung für KI-ProdukteFehler von KI-Agenten aus der Produktion in Tests verwandeln