Wie Sie ein LLM-Feature evaluieren, bevor es live geht

„Ich habe es an ein paar Beispielen ausprobiert und es hat funktioniert" ist das Häufigste, was wir hören, wenn ein Team beschreibt, wie es ein KI-Feature getestet hat, und das ist keine Evaluation, das ist eine Demo. Die Lücke zwischen „hat bei den Beispielen funktioniert, die ich zufällig ausprobiert habe" und „zuverlässig genug, um es Kunden zu zeigen" ist genau dort, wo KI-Features nach dem Launch schiefgehen, und sie lässt sich vor dem Launch schließen, wenn Sie einen echten Evaluationsprozess bauen statt eines informellen.

Ein echtes Evaluationsset beginnt mit tatsächlichen Anfragen, nicht erfundenen. Ziehen Sie echte Beispiele aus Support-Tickets, Suchprotokollen oder wie auch immer Nutzer tatsächlich mit dem Feature interagieren würden, nicht die sauberen, gut formulierten Fragen, die ein Entwickler beim Bauen schreibt. Echte Nutzer stellen mehrdeutige Fragen, machen Tippfehler und formulieren Dinge auf Weisen, die Ihre Testfälle nie vorhergesehen haben, wenn Sie sie selbst geschrieben haben.

Jedes Beispiel braucht eine gelabelte korrekte Antwort, entschieden von jemandem, der die Domäne tatsächlich kennt, bevor Sie irgendetwas gegen das Modell laufen lassen. Ohne eine gelabelte Antwort zum Vergleich wird „wie gut war das" zu einer Ad-hoc-Bewertung im Moment, und genau das ist die Art inkonsistenter Evaluation, die ein Feature auf Gefühl hin live gehen lässt.

Bemessen Sie das Set an der tatsächlichen Varianz in Ihren Eingaben, nicht an einer runden Zahl, die gründlich wirkt. Fünfzig gut gewählte Beispiele, die Ihre echten Anfragemuster abdecken, einschließlich der schwierigen, fangen mehr Regressionen als fünfhundert Beispiele, die alle leichte Variationen des einfachen Falls sind. Wir bauen diese Sets iterativ, beginnend klein, und fügen Beispiele hinzu, sobald neue Fehlermuster in der Produktion auftauchen.

Das Set verdient sich seinen Nutzen nur, wenn es bei jeder Änderung erneut läuft, nicht nur vor dem ersten Launch. Eine Prompt-Anpassung, ein Modell-Upgrade, eine Änderung dessen, was vor der Generierung abgerufen wird, jede davon kann manche Fälle verbessern und andere still kaputt machen. Dasselbe gelabelte Set nach jeder Änderung erneut laufen zu lassen, ist es, was „wir haben das behoben, was uns aufgefallen ist, und drei Dinge kaputt gemacht, die uns nicht aufgefallen sind" erfasst.

Verfolgen Sie Fehler nach Kategorie, nicht nur als Erfolgsquote. Eine einzelne Prozentzahl sagt Ihnen, dass etwas nicht stimmt; sie sagt Ihnen nicht, was zu beheben ist. Fehler in Buckets zu trennen, falsches Retrieval, korrektes Retrieval aber falsches Reasoning, korrekte Antwort aber falscher Ton oder falsches Format, sagt Ihnen, ob die nächste Korrektur in Ihre Daten, Ihren Prompt oder Ihre Retrieval-Pipeline gehört.

Entscheiden Sie, was „gut genug zum Launch" bedeutet, bevor Sie die Ergebnisse sehen, nicht danach. Es ist leicht, einen mittelmäßigen Score zu rechtfertigen, sobald man davorsitzt und launchen will. Im Voraus eine Schwelle festzulegen, und was mit Fehlern darunter passiert (menschlicher Fallback, eine UI-Behandlung mit geringerer Konfidenz, das Feature ganz blockieren), hält die Evaluation ehrlich, statt zur Formalität zu werden, an der man sich vorbeiredet.

Nichts davon ist ein einmaliges Gate vor dem Launch. Das Evaluationsset ist ein lebendiges Asset: Jeder echte Produktionsfehler, der gemeldet wird, wird zu einem neuen gelabelten Beispiel, das hinzugefügt wird, sodass das Set besser darin wird, genau die Fehler zu fangen, auf die Ihre Nutzer tatsächlich stoßen, nicht nur die, die Sie beim Bauen vorhergesehen haben. Ein Feature, das einmal vor dem Launch evaluiert und danach nie wieder wird, ist ein Feature, bei dem Sie innerhalb eines Monats nach dem Launch blind fliegen.