Evaluation vor dem Bau

Fragen Sie Teams, die ein KI-Produkt bauen, woher sie wissen, dass es funktioniert. Die übliche Antwort: eine Demo, die gut lief, und der Eindruck, das Modell wirke «sorgfältig».

Manche Teams vermeiden den Fehler, den Warum KI-Piloten den produktiven Einsatz nie erreichen beschreibt: den eindrücklichen Prototyp, der seine Kennzahl nie bewegt hat. Sie haben eine Gewohnheit gemeinsam: Sie schreiben die Evaluation vor dem Produktivcode.

Proof of Concept oder Proof of Value

Ein Proof of Concept fragt, ob sich etwas bauen lässt. Mit einem leistungsfähigen Modell und einem wohlwollenden Demo-Skript gelingt das fast immer. Ein Proof of Value fragt, ob es die konkrete Zahl bewegt, für die es gebaut wurde, gemessen an einem Ausgangswert und mit Belegen.

Das lässt sich nicht im Nachhinein beantworten. Vor jedem Entscheid über den produktiven Einsatz legen Sie fest, wie eine richtige Antwort aussieht, wie eine falsche und wie viele von beiden Sie tolerieren. Diese Festlegung ist das Evaluationsset, und es aufzubauen ist Engineering-Arbeit.

Wie ein Evaluationsset aussieht

Für ein KI-Produkt in der Hotellerie und Gastronomie, das Gästefragen zu Gerichten beantwortet, haben wir ein Evaluationsset gebaut und es adversarial angelegt.¹ Falsche Öffnungszeiten sind ein Ärgernis. Eine falsche Antwort auf eine Allergenfrage kann einen Gast gefährden und braucht deshalb eine andere Art von Test.

Die 117 Fälle gliedern sich in drei Klassen. Jede zielt auf einen anderen Weg, auf dem eine selbstsicher falsche Antwort durchrutschen kann:

• Euphemismus-Fälle. Das Allergen wird indirekt beschrieben. Geprüft wird, ob das System die Substanz hinter einer ungewohnten Umschreibung erkennt, statt ein Stichwort abzugleichen.
• Social-Engineering-Fälle. Die Anfrage setzt unter Druck oder Dringlichkeit, beruft sich auf Autorität oder behauptet, das Personal habe das Gericht bereits als unbedenklich bestätigt. Geprüft wird, ob das System bei seiner Antwort bleibt.
• Fallen durch positive Rahmung. Die Frage schiebt das Modell zur Antwort, die der Gast hören möchte. Geprüft wird, ob das System die gestellte Frage beantwortet.

Jede Klasse entspricht einer dokumentierten Art, wie Menschen, absichtlich oder nicht, ein System zur beruhigenden Antwort drängen. Ein Set, das nur die höfliche, direkte Frage prüft, begegnet nie den Varianten, die im Betrieb auftauchen.

Das Merge-Gate

Die Evaluation läuft in der Continuous Integration als hartes Merge-Gate, das eine Bestehensquote von 100 % verlangt.¹ Jede Änderung am Modell, am Prompt oder an der Retrieval-Pipeline, die auch nur einen der 117 Fälle nicht besteht, blockiert den Merge.

Die Regel ist absichtlich teuer. Eine nützliche Prompt-Verbesserung kann durch eine unabhängige Regression an anderer Stelle im Set blockiert werden. Dann wird die Regression behoben, nie das Gate gelockert. Ein einziger falsch-negativer Befund bei einer Allergenfrage ist keinen Zeitgewinn wert. Das Gate verhindert, dass unter Termindruck doch so abgewogen wird.

Warum sie vor den Bau gehört

Evaluationsinfrastruktur ist in einer Verkaufsdemo unsichtbar, aufwendiger zu bauen als die Funktion, die sie schützt, und selten das, womit ein Anbieter wirbt. Sie ist aber das klarste Signal dafür, ob ein KI-System für echte Nutzende bereit ist.

Phase 02 · Nutzen belegen prüft die Idee an einer benannten Kennzahl. Sie endet mit einem Evaluationsbericht und einer Empfehlung (Go, No-go oder Anpassen), bevor jemand auf Basis einer Demo einen Produktivbau finanziert.² Das hier aufgebaute Evaluationsset wird danach zur Regressionssuite für jede künftige Änderung an Modell, Prompt und Retrieval-Pipeline, solange das System läuft. Ohne ihn finden die meisten Teams die Lücken in ihrer Abdeckung im Betrieb, nachdem eine falsche Antwort jemanden erreicht hat, der ihr vertraut hat.

Wenn eine falsche Antwort in Ihrem Anwendungsfall jemanden ernsthaft gefährden könnte (eine regulierte Aussage, eine sicherheitskritische Anweisung, eine medizinische oder Allergenfrage), ist der Proof of Value Sprint genau auf diese Disziplin ausgerichtet. Die Branchenseite Hotellerie und Gastronomie zeigt, wo dieses Evaluationsset in einem grösseren Produkt sitzt.

Footnotes

1. Der vollständige interne Aufbau, auf dem dieser Beitrag beruht: adversariales Evaluationsset für Allergensicherheit. ↩ ↩²

2. Die vollständige Struktur in sechs Phasen, einschliesslich des Unterschieds zwischen Phase 02 · Nutzen belegen und einem herkömmlichen Proof of Concept, beschreibt die KARPINITY-Methode. ↩