Evals sind die Spezifikation für ein KI-Feature

Ein Feature, das auf einem Sprachmodell beruht, antwortet jedes Mal anders, wenn man es fragt. Das bricht den Satz, auf dem jedes Anforderungsdokument ruht: „Es funktioniert.“ Dieser Artikel handelt davon, was ihn ersetzt, wer den Ersatz schreibt, und was das Studio beim Spezifizieren von acht KI-Umgebungen in einem Produkt gelernt hat.

Warum versagt „es funktioniert“ bei einem KI-Feature?

Weil es keine einzelne Ausgabe zum Prüfen gibt. Ein deterministisches Feature wird einmal abgenommen; ein modellgestütztes muss statistisch abgenommen werden, über die Fälle hinweg, die zählen, und jedes Mal neu, wenn sich Prompt oder Modell ändern. Hamel Husain, ein KI-Berater, der solche Systeme seit 2023 ausliefert, schrieb am 29. März 2024, dass gescheiterte KI-Produkte „almost always share a common root cause: a failure to create robust evaluation systems“. Die Teams, die scheitern, spielen Whack-a-Mole: eine Antwort reparieren, eine andere kaputtmachen, und nie wissen, wo man steht.

Was ist ein Eval, in Produktbegriffen?

Eine Spezifikation in drei Teilen, in der Sprache des Lesers geschrieben und im Besitz der Produktrolle.

• Die Fälle, die es bewältigen muss: echte Eingaben, idealerweise von echten Nutzern oder aus Logs, jede mit dem, was eine gute Antwort enthält.
• Die Fälle, in denen es ablehnen muss: die Fragen außerhalb des Umfangs, die Daten, die es nie preisgeben darf, die Handlungen, die es nie ausgeführt zu haben behaupten darf.
• Die Toleranz: wie oft es in jeder Menge danebenliegen darf, bevor das Feature zurückgezogen wird, als Zahl, die eine Person unterschrieben hat.

Husain beschreibt drei Teststufen, die auf diese Teile passen: billige Prüfungen, die bei jeder Änderung laufen, Durchsicht protokollierter Läufe durch Mensch und Modell, und A/B-Tests mit echten Nutzern. Die ersten beiden sind das Eval. Die Spezifikation ist eine Liste von Fällen und eine Zahl, und die Zahl ist eine Produktentscheidung, weil sie Qualität gegen Auslieferung tauscht.

Wer schreibt es?

Die Person, die sonst die Abnahmekriterien schreiben würde. Ein Entwickler kann das Testgerüst schreiben; nur die Produktrolle kann sagen, welche zwanzig Fälle zählen, welche Ablehnungen nicht verhandelbar sind und welche Fehlerquote das Geschäft verträgt. Anthropics Leitfaden zum Agenten-Design, veröffentlicht am 19. Dezember 2024, macht denselben Punkt von der Architekturseite: „the simplest solution possible, and only increasing complexity when needed“ finden, und überall dort einen vordefinierten Workflow einem autonomen Agenten vorziehen, wo die Schritte im Voraus bekannt sein können. Diese Wahl ist eine Spezifikationsentscheidung, und sie trifft, wer die Fälle besitzt.

Was hat das Studio dabei gelernt?

Torn Studio hatte bis Juni 2026 die Produktrolle bei Changemkr, einer KI-Plattform für Change Management, an der das Studio beteiligt ist. An der Juni-Grenze liefen acht KI-Umgebungen auf einem Dienst, jede mit eigenem Modell, eigenen Werkzeugen und eigener Prompt-Versionierung mit Rollback per Klick, zählbar im Prompt-Register. Jede Prompt-Änderung war ein Release, und jedes Release wurde gegen seine Fälle abgenommen.

Im Juni 2026 testete eine externe Beratung den KI-Assistenten des Planers und meldete ihn als unzuverlässig. Das Studio machte aus dem Bericht 27 nummerierte Befunde, gruppierte sie nach Ursache, bevor Code angefasst wurde, und stellte fest, dass 4 der 27 Produktentscheidungen ohne jede Code-Korrektur waren: Das Feature tat, was ihm gesagt worden war, und was ihm gesagt worden war, war falsch. Diese Trennung, Fehler oder Entscheidung, ist das, was ein Eval sichtbar macht, bevor ein Tester es tut.

Die Verifikation ist der Ort der ehrlichen Grenze. Die Korrekturen liefen gegen den vollständigen Stack in Containern mit Browser-Tests: 11 bestanden, 1 übersprungen, und die drei großen generativen Abläufe wurden nie Ende-zu-Ende verifiziert, weil ihre Ausgaben zwischen Läufen variieren und ein Test, der jedes Mal dieselbe Ausgabe erwartet, sie nicht tragen kann. Der Bericht sagt das pro Befund, und das ist der Punkt: Eine Verifikation, die sich selbst als vollständig grün meldet, ist eine, der beim nächsten Mal niemand traut.

Wo kommt das Vertrauen ins Spiel?

Ein Eval deckt Korrektheit ab; die Fälle zu Ablehnung und Offenlegung decken Vertrauen ab, und sie gehören in dasselbe Dokument. Google PAIRs People + AI Guidebook bittet Teams, Vertrauen zu kalibrieren — „tell the user when a lack of data might mean they’ll need to use their own judgment“ — und Konfidenz als Kategorien zu zeigen. Die Seite der Europäischen Kommission zum AI Act sagt, dass Chatbots Menschen bewusst machen müssen, dass sie mit einer Maschine interagieren, mit Transparenzregeln, die ab August 2026 gelten, und verlinkt den Text. Wie ein Feature dieses Vertrauen verdient, ist ein eigener Artikel; das Eval ist der Ort, an dem die Fälle zuerst aufgeschrieben werden.

Wo das Modell in einem bestehenden System sitzt — die begrenzte Aufgabe mit einer Prüfung darum herum — steht in KI in bestehenden Systemen. Die Fälle in einem Eval werden so gewählt, wie ein Backlog priorisiert wird, und diese Methode steht in Was als Nächstes gebaut wird.

So spezifiziert das Studio ein KI-Feature

Product Management bei Torn Studio wird je Auftrag bepreist, mit einem Festpreis, bevor die Arbeit beginnt, und ein KI-Feature im Projektumfang bekommt sein Eval vor seinem Prompt geschrieben: die Fälle, die Ablehnungen, die Toleranz, unterschrieben von der Person, die die Zahl lesen wird. Das Studio baut dann dagegen, sodass das Feature mit dem Dokument ausgeliefert wird, das sagt, was es tun darf und wo es ablehnen muss.