Wie man ein LLM-System testet

Ein LLM-System ist nicht eine Sache. Es ist eine Kette: die Frage verstehen, ein Werkzeug wählen, die Argumente für dieses Werkzeug erzeugen, Daten holen, dann schreiben. Beim Testen greifen Teams instinktiv ans Ende der Kette, weil die Nutzenden das sehen. Das ist der schlechteste Anfang.

Prüfen Sie die Argumente, nicht die Prosa

Auf einer konversationellen Analytikplattform und später erneut bei einem RAG-Assistenten haben wir Integrationssuiten gebaut, die etwas Einfacheres tun, als es klingt: Zu einem gegebenen Prompt prüft der Test, ob das Modell die richtigen Retrieval-Filter erzeugt hat. Nicht die richtige Antwort — die richtige Abfrage.

Dieser eine Schritt verändert die Ökonomie des Testens. Die Assertion ist deterministisch: Ein Satz Filter stimmt überein oder nicht. Sie ist schnell, weil strukturierte Werte verglichen und nicht Texte beurteilt werden. Sie läuft bei jedem Release wie jeder andere Test, in der CI, ohne Menschen in der Schleife und ohne Bewertungsmodell.

Der Test prüft die Abfrage und führt sie nie aus. Filter-Regressionen werden gefunden, ohne für Retrieval zu bezahlen.

Und die Rechnung wächst nicht mit

Es gibt einen zweiten Vorteil, der in der Eval-Literatur nicht auftaucht. Weil die Suite die Abfrage nie ausführt, rührt sie den Suchindex nicht an. In einem Projekt waren die Retrieval-Kosten bei Produktionsvolumen spürbar geworden — genug, dass eine vollständige End-to-End-Suite bei jedem Commit jemandem aufgefallen wäre. Nur die Tool-Call-Ebene zu testen, hat das vollständig beseitigt.

Qualität und Kosten ziehen in diesen Systemen meist gegeneinander. Dies ist einer der wenigen Punkte, an denen dieselbe Entscheidung beides verbessert — weshalb ich das heute als Erstes aufsetze.

Was das nicht abdeckt

Es sagt nichts darüber, ob die finale Antwort gut ist. Nichts Günstiges tut das. Dafür braucht es die langsamere Hälfte: Referenzfälle mit erwarteten Ausgaben, eine Rubrik, manchmal von einem Modell angewandt, wo sich das lohnt, und vor allem ein Validierungsprogramm mit den Menschen, die für das Ergebnis geradestehen.

Jede dieser drei hat später einen eigenen Artikel bekommen, und es lohnt sich, sie in dieser Reihenfolge zu lesen: erst der Massstab, dann wer ihn hält, schliesslich wer für das geradesteht, was dabei herauskommt.

Bei der Arbeit an den Leitlinien hiess das ein langes, iteratives Programm mit den Fachleuten, die das Dokument unterschreiben. Ihr Feedback hat die Pipeline gut gemacht, nicht die Modellwahl. Es hat Monate gedauert und war der wertvollste Teil des Projekts.

Eine praktische Reihenfolge

Beginnen Sie mit den Tool-Call-Assertions: Sie kosten wenig und fangen die Regressionen, die tatsächlich passieren. Ergänzen Sie Referenzfälle für die erzeugte Ausgabe, ausgeführt vor jedem Release statt bei jedem Commit. Und erfassen Sie im Betrieb strukturiertes Feedback der Nutzenden — eine Bewertung und eine Zeile Text pro Ausgabe genügen, um zu sehen, wo die Qualität abdriftet.

Was nicht gemessen wird, ist nicht fertig. Aber Messen muss nicht heissen, eine teure End-to-End-Umgebung zu bauen, die niemand zweimal startet.

Die Reihe, die daraus entstanden ist

Die drei Dinge, die dieser Beitrag offen lässt, haben jeweils ihren eigenen Artikel bekommen, und es lohnt sich, sie in dieser Reihenfolge zu lesen.

Golden Dataset und Testset ist der Massstab. Ohne eine Sammlung von Beispielen mit erwarteter Antwort bleibt «funktioniert besser» eine Meinung, und jede andere technische Entscheidung ruht auf nichts.

LLM-as-judge ist, wer den Massstab hält, wenn die Fälle für einen Menschen zu viele werden. Es funktioniert, aber erst nach der Kalibrierung an echten menschlichen Urteilen — und mit den eigenen dokumentierten Verzerrungen unter Kontrolle.

Human-in-the-loop ist der Mensch, der ohnehin im Kreis bleibt. Er ist kein Ersatz für die Messung: er ist die Art, zu überleben, während man sie aufbaut — und im dritten Monat sieht man, ob er gut entworfen war.