Das Unternehmen will ein LLM-gestütztes Summary-Feature bauen. Wie würdest du bewerten, ob es gut genug zum Ausliefern ist?

Definiere, was gut für diese Aufgabe heißt, bevor du irgendetwas generierst, und bau dann ein festes Evaluationsset aus echten Inputs mit rubrikbasierter Bewertung. Kombiniere automatisierte Checks (faktische Konsistenz zur Quelle, Formatvalidität, Refusal- und Latenzraten) mit stichprobenhafter menschlicher Prüfung. Ship hinter einem Flag, miss nachgelagertes Nutzerverhalten und behalte das Eval-Set als Regressionssuite für Modellversionswechsel.

Die Falle hier ist, dass die ersten zehn Outputs immer großartig aussehen und alle sofort shippen wollen. Also schreibe ich auf, was gut heißt, bevor ich irgendetwas generiere: treu zum Quelldokument, deckt die Kernpunkte ab, richtige Länge, keine erfundenen Fakten. Dann ziehe ich ein paar hundert echte Inputs, gewichtet auf die harten Fälle statt auf die hübschen, und friere das als Evaluationsset ein. Automatisiert prüfe ich faktische Konsistenz zur Quelle, Formatvalidität und Refusal-Rate, und für die Rubrikwerte nutze ich ein Modell als Judge, aber erst, nachdem ich es auf einer Teilmenge gegen menschliche Bewertungen kalibriert habe, denn ein ungegroundeter Judge stimmt vor allem sich selbst zu. Ein Mensch bewertet weiterhin jede Runde eine Stichprobe. Dann ship ich hinter einem Flag an einen Teil des Traffics und schaue, was Nutzer wirklich tun: Editieren sie das Summary, öffnen sie trotzdem das ganze Dokument? Dieses nachgelagerte Verhalten ist die echte Metrik. Und ich behalte das Eval-Set als Regressionssuite, denn wenn der Provider das Modell unter dir aktualisiert, verschiebt sich das Verhalten, und das willst du aus deinen eigenen Tests erfahren und nicht aus Support-Tickets.