Erst bewerten, dann vorführen
Eine beeindruckende Sprachmodell-Demo baut jeder an einem Nachmittag. Die Evaluationssuite sagt Ihnen, ob sie nächsten Monat noch funktioniert.
Der Abstand zwischen Demo und Produkt ist nicht die Modellqualität. Er besteht darin, dass eine Demo daran gemessen wird, ob sie den Raum beeindruckt hat, und ein Produkt daran, ob es sich bei der tausendsten Anfrage korrekt verhält — vor jemandem, der genervt ist.
Der Mechanismus, der diesen Abstand schliesst, ist unglamourös: ein geprüfter Datensatz aus echtem Verkehr, samt Grenzfällen und Fehlschlägen, mit hinterlegten Sollergebnissen. Alles andere — Prompt-Änderungen, Modellwechsel, Routing — wird dagegen zu einer messbaren Entscheidung.
Ohne ihn landen Teams in einer Schleife, die wir ständig sehen. Jemand justiert einen Prompt, um eine Beschwerde zu beheben, niemand prüft, was sich sonst geändert hat, und drei Wochen später ist ein Verhalten, das früher funktionierte, still zurückgefallen. Wann, kann niemand sagen, denn es gab nie eine Basislinie.
Die Bewertung lässt sich teilweise automatisieren, indem ein Modell als Prüfer dient — aber erst, nachdem es an menschlichen Bewertungen derselben Beispiele kalibriert wurde. Ein unkalibrierter Prüfer ist ein selbstbewusster Zufallszahlengenerator, und er wird Ihnen bereitwillig sagen, die Qualität sei gestiegen.
Sobald die Suite existiert, wandert sie als Schranke in die CI. Eine Prompt-Änderung, die den Wert senkt, wird nicht zusammengeführt. Diese eine Regel macht aus KI-Arbeit, die sich riskant anfühlt, etwas, das sich verhält wie der Rest Ihrer Entwicklung.
Sie ist ausserdem die einzig ehrliche Antwort auf einen Kunden, der fragt, ob das Ding funktioniert. Sie können ihm eine Zahl zeigen, erzeugt aus seinen eigenen Daten, bevor irgendjemand ein Budget ausgegeben hat.