LLM-Evaluierung, aufgebaut aus Ihren eigenen Traces

Im State-of-Agent-Engineering-Report von LangChain, 2026 veröffentlicht und gestützt auf Antworten von über 1300 Fachleuten, die mit Agenten arbeiten, hatten 89 % irgendeine Form von Observability im Einsatz, doch 29,5 % führten gar keine Evaluierungen durch, und Qualität war das am häufigsten genannte Hindernis für den Produktivbetrieb. Ein Trace zeigt, was in einem Gespräch passiert ist. Eine Evaluierung zeigt, wie oft ein bestimmter Fehler über alle Gespräche hinweg auftritt und ob eine Änderung diese Zahl bewegt hat.

Allgemeine Werte wie Hilfsbereitschaft oder eine Gesamtnote von eins bis zehn helfen selten. Sie steigen und fallen, ohne dass jemand weiß, was zu reparieren ist. Wir beginnen bei den Fehlern, die Ihr System tatsächlich macht.

In der ersten Woche ziehen wir mindestens 100 Traces oder abgeschlossene Fälle und lesen sie mit jemandem, der die Arbeit kennt, etwa einer Support-Leitung oder einem Sachbearbeiter. Zu jedem Fall notieren wir kurz, was als Erstes schiefging. Wir lesen weiter, bis neue Traces keine neuen Arten von Fehlern mehr zeigen.

Danach fassen wir die Notizen zu einer kurzen Liste von Fehlertypen zusammen und zählen sie. Die Häufigkeiten bestimmen die Arbeit. Manche Fehler werden direkt im Prompt oder in einer Retrieval-Einstellung behoben, manche bekommen eine Prüfung im Code, und nur die, die eine Beurteilung brauchen, bekommen einen LLM-Judge.

Das Testset entsteht aus Ihren Traces und abgeschlossenen Fällen, markiert nach Anliegen, Schwierigkeit und Sprache und versioniert neben Ihren Prompts, damit sich jeder Wert reproduzieren lässt. Hat ein Produkt noch keine Nutzer, erzeugen wir Fälle entlang festgelegter Dimensionen, statt ein Modell einfach nach Testfragen zu fragen, und Ihre Fachleute ergänzen die Fälle, von denen sie schon wissen, dass sie schwierig sind.

Bei RAG-Systemen markieren wir, welche Textstelle jede Frage beantworten soll, damit Retrieval und Antwort getrennt bewertet werden. Bei Agenten prüfen wir zuerst das Ergebnis und nutzen den Trace, um die Stelle zu finden, an der ein Lauf falsch abgebogen ist.

• Fälle aus echtem Betrieb, markiert und versioniert in Ihrem Repository
• Seltene, aber teure Fälle bleiben im Set, auch wenn sie nur einen kleinen Teil des Betriebs ausmachen
• Fragen in jeder Sprache, in der Ihre Nutzer schreiben
• Fälle für jeden Fehlertyp aus der Fehleranalyse

Zuerst schreiben wir Prüfungen im Code: gültiges JSON, Pflichtfelder, eine SQL-Abfrage, die läuft, ein Erstattungsbetrag innerhalb der Richtlinie. Sie kosten fast nichts und liefern jedes Mal dasselbe Ergebnis. Wo ein Fehler eine Beurteilung braucht, etwa eine Antwort, die eine Vertragsklausel falsch wiedergibt, bauen wir einen Judge, der für genau diesen Fehler bestanden oder nicht bestanden zurückgibt.

Jeder Judge wird an Fällen, die er noch nicht kennt, gegen die Bewertungen Ihrer Fachperson getestet. Wir berichten, wie viele echte Fehler er erkennt und wie viele gute Antworten er fälschlich durchfallen lässt, damit Sie wissen, wie weit Sie seinen Zahlen trauen können. Ändert sich das Judge-Modell, sein Prompt oder die Bewertungsvorgabe, testen wir erneut.

Eine kleine Suite, überwiegend Prüfungen im Code, läuft in der CI bei jeder Änderung an Prompts, Modellen, Tools oder Retrieval-Einstellungen. Jeder Fehlertyp hat einen eigenen Schwellenwert, damit ein Gewinn an einer Stelle keine Verschlechterung an einer anderen verdeckt. Im Betrieb laufen Judges auf einer Stichprobe des echten Verkehrs, mit Alarmen pro Fehlertyp.

Der Ausgangsbericht stellt Qualität, Kosten pro erfolgreicher Aufgabe und Latenz in eine Tabelle, mit Konfidenzintervallen. Bei 100 Fällen liegen 80 % und 83 % meist innerhalb des Rauschens, und das sagen wir, statt einen Erfolg zu verkünden.

Der Ausgangspunkt umfasst ein KI-Produkt oder einen Ablauf, etwa einen Support-Assistenten, ein internes RAG-Tool oder einen Prozessagenten, in bis zu zwei Sprachen. Er braucht von Ihrer Seite eine Fachperson für einige Stunden pro Woche und Zugang zu Traces oder abgeschlossenen Fällen. Vor dem Start vereinbaren wir, wie mit diesen Daten umgegangen wird, einschließlich der Pseudonymisierung personenbezogener Daten.

Wenn Sie bereits Evals betreiben, prüft ein zweiwöchiges Audit, ob Sie ihnen trauen können: wie die Fehlertypen gefunden wurden, ob die Judges gegen menschliche Bewertungen getestet wurden und ob die Kennzahlen zu den Entscheidungen passen, die Sie damit treffen.

• Fehlertypen mit Häufigkeiten
• Ein versioniertes Testset in Ihrem Repository
• Prüfungen im Code, Judge-Prompts und ein Bericht, wie gut jeder Judge mit Ihren Fachleuten übereinstimmt
• Konfiguration für das CI-Gate und für Stichproben im Betrieb
• Ein Ausgangsbericht mit Qualität, Kosten und Latenz sowie eine priorisierte Liste von Korrekturen

Wir arbeiten mit der Plattform, die Sie schon nutzen, etwa Langfuse, LangSmith oder Braintrust, oder ganz ohne. Testsets und Judges bleiben in einfachen Formaten in Ihrem Repository. Evaluierungstools haben in den letzten zwei Jahren oft den Eigentümer gewechselt, und OpenAI hat seine gehostete Evals-Plattform am 31. Oktober 2026 auf schreibgeschützt gestellt und schaltet sie am 30. November 2026 ab. Ihre Evals sollten deshalb von keinem einzelnen Tool abhängen.

Nach der KI-Verordnung treffen die Pflichten, gegen festgelegte Kennzahlen zu testen, die Genauigkeit anzugeben und nach dem Start zu überwachen, die Anbieter von Hochrisiko-Systemen. Nach dem 2026 beschlossenen Zeitplan gelten sie ab dem 2. Dezember 2027 für die in Anhang III aufgeführten Hochrisiko-Anwendungen und ab dem 2. August 2028 für KI in Produkten nach Anhang I. Für die meisten Chatbots, internen Assistenten und RAG-Tools sieht die Verordnung keine solche Pflicht vor. Evals sind in jedem Fall gute Ingenieursarbeit, und sie können einen großen Teil der Testnachweise liefern, die ein Anbieter braucht, falls ein Anwendungsfall zum Hochrisiko-Fall wird. Wir bewerten keine Konformität und leisten keine Rechtsberatung.