Wie Sie einen KI-Assistenten vor dem Start testen: ein Testset aus eigenen Fällen aufbauen, Abnahmeschwellen festlegen und bestimmen, wer freigibt

Ein KI-Assistent kann Fragen anhand Ihrer Dokumente beantworten, Antworten an Kunden entwerfen oder Daten aus Formularen auslesen. Eine Demo zeigt, dass er das kann, aber nicht, wie oft er bei Ihren eigenen Fällen danebenliegt und auf welche Weise. Dafür brauchen Sie einen Test aus echten vergangenen Fällen. Ihre Leute schreiben für jeden Fall die richtige Antwort, und Sie legen im Voraus fest, wie viele Fehler jeder Art Sie akzeptieren. Eine namentlich benannte Person auf Ihrer Seite gibt die Ergebnisse dann frei.

Warum ist eine gute KI-Demo kein Test?

Eine Demo zeigt Fragen, die der Anbieter ausgewählt hat und die jeweils einmal beantwortet werden. Ihre Kunden und Mitarbeiter werden andere Fragen in ihren eigenen Worten stellen, und dieselbe Frage kann beim zweiten Versuch eine andere Antwort bekommen.

Der Leitfaden von OpenAI zu Best Practices für Evaluierungen beginnt genau damit: „Generative KI ist variabel. Modelle erzeugen bei derselben Eingabe manchmal unterschiedliche Ausgaben, was herkömmliche Methoden zum Testen von Software für KI-Architekturen unzureichend macht.“ Alle Quellen in diesem Artikel wurden am 4. November 2026 abgerufen.

Der Leitfaden nennt Tests der Antworten eines Modells Evals, kurz für Evaluierungen. Einer der Fehler, die er aufführt, ist das Eval nach Bauchgefühl: „‚Es scheint zu funktionieren‘ als Evaluierungsstrategie zu nutzen oder mit der Einführung von Evals zu warten, bis das Produkt ausgeliefert ist.“

Das NIST, das National Institute of Standards and Technology der USA, hat im Juli 2024 ein Generative AI Profile als freiwillige Leitlinie veröffentlicht. Das Profil verwendet für generative KI die Abkürzung GAI. Eine der darin vorgeschlagenen Maßnahmen lautet: „Vermeiden Sie es, die Leistung oder die Fähigkeiten von GAI-Systemen aus engen, unsystematischen und anekdotischen Bewertungen zu extrapolieren.“

Ein Testset leistet, was eine Demo nicht leisten kann: eine Liste echter Fälle, jeweils mit der Antwort, die Sie erwarten, nach jeder Änderung auf dieselbe Weise bewertet.

Woher sollten die Testfälle kommen?

Aus Ihrer eigenen Arbeit, ungefähr in der Mischung, mit der der Assistent zu tun haben wird. Der Leitfaden von Anthropic zum Festlegen von Erfolgskriterien und zum Aufbau von Evaluierungen für seine Claude-Modelle sagt: „Gestalten Sie Evals so, dass sie die reale Verteilung Ihrer Aufgaben widerspiegeln.“

Der Leitfaden von OpenAI ergänzt: „Stellen Sie sicher, dass Ihre Testdaten typische Fälle, Randfälle und adversariale Fälle enthalten.“ Randfälle sind seltene oder knifflige Eingaben. Adversariale Fälle versuchen, den Assistenten zu Fehlverhalten zu verleiten. Nehmen Sie die Fälle aus diesen Quellen:

• Frühere Fragen und Tickets aus einem ganzen Jahr und aus allen Kategorien, damit auch saisonale auftauchen
• Dokumente aller Art, die der Assistent lesen wird, einschließlich Scans und ungewöhnlicher Layouts
• Knifflige Fälle, etwa eine Frage, die zwei Themen vermischt, oder ein Formular mit einem fehlenden Feld
• Fragen, die Ihre Dokumente nicht beantworten und bei denen das richtige Ergebnis darin besteht, das zu sagen und an einen Menschen zu übergeben
• No-Go-Fälle, etwa eine Anfrage nach den Daten eines anderen Kunden oder eine Erstattung, die Ihre Richtlinie verbietet
• Versuche, den Assistenten hereinzulegen, etwa in einem Ticket oder einer hochgeladenen Datei versteckte Anweisungen

Für ein Testset gibt es keine Standardgröße. Ein praktikabler Anfang sind einige Dutzend Fälle pro Fragetyp, denn bei nur zehn Fällen verschiebt ein einziger gescheiterter Fall den Score dieses Typs um zehn Prozentpunkte. Formulieren Sie jeden No-Go-Fall auf mehrere Arten, denn ein Modell kann eine Formulierung ablehnen und eine andere akzeptieren.

Das Set enthält echte Kundendaten, also geben Sie ihm dieselben Zugriffsregeln wie den Tickets und Dokumenten, aus denen es stammt.

Wer schreibt die erwarteten Antworten, und was gehört hinein?

Die erwarteten Antworten schreiben Ihre eigenen Experten, nicht die Firma, die den Assistenten baut. Eine erwartete Antwort, von Entwicklern Ground Truth genannt, ist die Antwort, die ein sorgfältiger Mitarbeiter akzeptieren würde. Ihre Form hängt von der Aufgabe ab:

• Antworten aus Dokumenten: die Fakten, die die Antwort enthalten muss, das Dokument und der Abschnitt, aus denen sie stammen, und was sie nicht sagen darf. Eine vollständige Musterantwort hilft weniger, weil sich eine richtige Antwort auf viele Arten formulieren lässt
• Antwortentwürfe: eine kurze Checkliste, etwa die richtigen Fakten, die eingehaltene Richtlinie und kein Versprechen außerhalb der Richtlinie
• Aus Dokumenten entnommene Daten: der korrekte Wert jedes Feldes, so wie Ihr System ihn speichert

Das Beispiel von OpenAI für Fragen zu Dokumenten baut seine Testdaten zum Teil aus „fest hinterlegten richtigen Antworten auf Fragen, die von Fachexperten erstellt wurden“ auf. In Ihrem Unternehmen sind diese Experten die Teamleitungen im Support und die Verantwortlichen für die Richtlinien.

Ein zweiter Experte prüft jede Antwort. Wenn zwei sorgfältige Menschen uneins sind, ist die Richtlinie hinter dem Fall wahrscheinlich unklar, und ein Assistent, der sie liest, wird sich ebenfalls schwertun. Der Leitfaden von Anthropic führt solche Fälle unter seinen Beispielen für Randfälle auf: „Mehrdeutige Testfälle, bei denen es selbst Menschen schwerfallen würde, zu einer übereinstimmenden Bewertung zu kommen“. Wer für die Richtlinie verantwortlich ist, entscheidet, und Sie korrigieren das Dokument zusammen mit dem Testfall.

Halten Sie zu jedem Fall seinen Fragetyp und die Dokumentversion fest, auf die er sich stützt. Wenn sich eine Richtlinie ändert, aktualisieren Sie diese Fälle, sonst lässt das Set Antworten durchfallen, die inzwischen richtig sind.

Wie legen wir Abnahmeschwellen fest?

Eine Abnahmeschwelle ist das niedrigste Ergebnis, das Sie vor dem Start akzeptieren. Legen Sie eine pro Fragetyp und pro Fehlerart fest, denn eine einzige Abnahmeschwelle für den ganzen Assistenten verdeckt zu viel. Der Leitfaden von Anthropic hält fest: „Die meisten Anwendungsfälle brauchen eine mehrdimensionale Evaluierung entlang mehrerer Erfolgskriterien.“

Ordnen Sie jeden gescheiterten Fall genau einer Fehlerart zu:

• Falscher Fakt: Die Antwort behauptet etwas Falsches. Das Profil des NIST nennt das Konfabulation: „Die Erzeugung von selbstsicher vorgetragenen, aber fehlerhaften oder falschen Inhalten (umgangssprachlich als ‚Halluzinationen‘ oder ‚Erfindungen‘ bezeichnet), durch die Nutzer in die Irre geführt oder getäuscht werden können.“
• Fehlende Antwort: Die Dokumente enthielten die Antwort, aber der Assistent sagte, er wisse es nicht, oder ließ einen wichtigen Fakt weg
• Falsche Quelle: Die Antwort zitiert ein Dokument, das sie nicht stützt, oder eine veraltete Version
• Gefährliche Antwort: Ein No-Go-Fall ist schiefgegangen
• Form und Ton: Die Fakten stimmen, aber die Antwort ist zu kurz angebunden oder im falschen Format

Diese Fehler kosten nicht gleich viel. Eine fehlende Antwort endet meist damit, dass ein Mensch den Fall übernimmt. Ein falscher Fakt erreicht den Kunden und sieht dabei richtig aus, und womöglich bemerkt es niemand. Deshalb bekommen falsche Fakten eine strengere Abnahmeschwelle als fehlende Antworten, und der Ton die großzügigste.

No-Go-Fälle müssen ausnahmslos bestehen. Ein einziger gescheiterter Fall stoppt den Start, bis Sie die Ursache behoben haben und das ganze Set wieder besteht.

Auch Fragetypen unterscheiden sich, denn ein Fehler bei den Öffnungszeiten kostet weniger als ein Fehler bei den Gebühren. Richten Sie jede Abnahmeschwelle danach aus, was Sie dieser Fehler kostet und wie oft Ihr Team heute bei denselben Fällen danebenliegt. Halten Sie die Abnahmeschwellen vor dem ersten Durchlauf schriftlich fest, damit niemand sie an die Ergebnisse anpasst.

Wer oder was bewertet die Antworten des Assistenten?

Daten, die aus Dokumenten entnommen wurden, kann Code bewerten: Jedes Feld stimmt mit dem erwarteten Wert überein oder nicht. Freitextantworten und Entwürfe brauchen ein Urteil, von Menschen oder von einem zweiten Sprachmodell, das nach der Checkliste arbeitet.

Der Leitfaden von Anthropic beschreibt die Bewertung durch Menschen so: „Am flexibelsten und von hoher Qualität, aber langsam und teuer. Wenn möglich vermeiden.“ Die Bewertung durch ein Modell beschreibt er als „schnell und flexibel, skalierbar und für komplexe Urteile geeignet“ und rät dann: „Testen Sie zuerst die Zuverlässigkeit, dann skalieren Sie.“

Ein Modell, das als Bewerter eingesetzt wird, hat bekannte Eigenheiten. Der Leitfaden von OpenAI zählt „Positionsbias (Reihenfolge der Antworten), Ausführlichkeitsbias (Bevorzugung längerer Antworten)“ zu den Herausforderungen. Die Reihenfolge der Antworten kann also das Urteil beeinflussen, und eine längere Antwort gewinnt womöglich allein wegen ihrer Länge. Zu den Tipps des Leitfadens gehört: „Nutzen Sie menschliches Feedback, um die automatisierte Bewertung zu kalibrieren.“ In der Praxis bewerten Ihre Experten eine Stichprobe, die auch das Modell bewertet, und Sie korrigieren die Checkliste überall dort, wo die beiden nicht übereinstimmen.

Bei Entwürfen hilft ein Blindtest. Mischen Sie die Entwürfe des Assistenten mit den Antworten Ihrer Mitarbeiter auf dieselben Tickets, und lassen Sie Prüfer sie bewerten, ohne dass diese wissen, welche Antwort von wem stammt. Der Leitfaden von OpenAI nennt einen „randomisierten, verblindeten Test“ als ein Beispiel für die Bewertung durch Menschen.

Da jede erwartete Antwort ihre Quelle nennt, können Sie auch das Retrieval prüfen, also den Suchschritt, der die Passagen findet, die das Modell liest. Wenn die Suche die richtige Passage gar nicht gefunden hat, bessern Sie die Suche nach, nicht das Modell. Das Profil des NIST schlägt eine verwandte Prüfung vor: „Überprüfen und verifizieren Sie Quellen und Zitate in den Ausgaben von GAI-Systemen während der Risikomessung vor dem Einsatz und bei der laufenden Überwachung.“

Lassen Sie jeden Fall mehrmals laufen, und stellen Sie wichtige Fragen in mehr als einer Formulierung. Der Leitfaden von Anthropic behandelt Konsistenz als eigenes Kriterium: „Wenn ein Nutzer dieselbe Frage zweimal stellt, wie wichtig ist es, dass er semantisch ähnliche Antworten erhält?“ Semantisch ähnlich bedeutet, dass die Antworten dasselbe aussagen, auch in anderen Worten.

Wann lassen wir das Testset erneut laufen?

Nach jeder Änderung, bevor sie Kunden erreicht. Dazu zählen eine neue Modellversion, bearbeitete Dokumente, neue Sucheinstellungen oder ein neuer Prompt, also die schriftlichen Anweisungen, denen das Modell folgt. Der Leitfaden von OpenAI macht daraus einen eigenen Schritt: „Richten Sie eine kontinuierliche Evaluierung (CE) ein, um bei jeder Änderung Evals auszuführen“.

Jeder Durchlauf sucht nach Regressionen, also nach Fällen, die vor einer Änderung bestanden haben und danach scheitern. Der Durchschnitt kann steigen, während ein Fragetyp einbricht, also sehen Sie sich jeden Typ einzeln an. Eine Änderung geht nur live, wenn:

• Kein No-Go-Fall scheitert
• Kein Fragetyp fällt unter seine Abnahmeschwelle
• Ein Mensch hat jeden neu gescheiterten Fall gelesen und kennt die Ursache

Bewahren Sie die Ergebnisse jedes Durchlaufs auf, zusammen mit den getesteten Versionen von Modell, Prompt und Dokumenten.

Anbieter nehmen Modelle außerdem nach ihrem eigenen Zeitplan außer Betrieb. Die Abkündigungsseite von OpenAI sieht für allgemein verfügbare Modelle eine Vorankündigung von mindestens sechs Monaten vor, sofern Sicherheits- oder Compliance-Bedenken keinen schnelleren Zeitplan erfordern. Preview-Modelle können mit deutlich kürzerer Vorankündigung außer Betrieb genommen werden. Die Seite von Anthropic sieht für öffentlich veröffentlichte Modelle eine Vorankündigung von mindestens 60 Tagen vor und warnt: „Anfragen an Modelle nach dem Datum der Außerbetriebnahme schlagen fehl.“

Diese Vorankündigung ist Ihr Zeitfenster, um das Set mit dem Nachfolgemodell laufen zu lassen, zu beheben, was scheitert, und erneut freizugeben. Planen und budgetieren Sie das von Anfang an.

Was prüfen wir nach dem Start?

Jede Woche bewertet ein Experte eine Zufallsstichprobe echter Antworten und Entwürfe mit derselben Checkliste, denn der Live-Traffic bringt Fälle, an die niemand gedacht hat. Das ist eine menschliche Prüfung einer Stichprobe, nicht jeder einzelnen Antwort.

Das AI Risk Management Framework des NIST, eine freiwillige Leitlinie vom Januar 2023, sagt: „KI-Systeme sollten vor ihrem Einsatz und regelmäßig während des Betriebs getestet werden.“ Laut NIST ist eine überarbeitete Fassung in Arbeit.

Geben Sie Mitarbeitern und Kunden eine einfache Möglichkeit, eine schlechte Antwort zu melden, und machen Sie aus jedem bestätigten Fehler einen neuen Testfall. Einer der Tipps von OpenAI lautet: „Protokollieren Sie schon während der Entwicklung, damit Sie Ihre Logs nach guten Eval-Fällen durchsuchen können.“

Wer gibt den Start frei, und auf Grundlage welcher Belege?

Die Freigabe erteilt die für den Prozess verantwortliche Person, bei einem Support-Assistenten zum Beispiel die Leitung des Supports. Die No-Go-Fälle gibt Compliance oder die Rechtsabteilung frei. Der Entwickler legt die Ergebnisse vor, gibt aber seine eigene Arbeit nicht frei.

Das Framework des NIST beschreibt eine ähnliche Trennung bei Bewertungen: „Interne Fachleute, die nicht unmittelbar als Entwickler an dem System gearbeitet haben, und/oder unabhängige Prüfer sind an regelmäßigen Bewertungen und Aktualisierungen beteiligt.“ Der Teil des Frameworks namens Manage beginnt dann mit einer Entscheidung über das KI-System: „ob seine Entwicklung oder sein Einsatz fortgesetzt werden soll.“

Die Unterlagen für diese Entscheidung sollten Folgendes zeigen:

• Wie das Set aufgebaut wurde, seine Größe pro Fragetyp und wer die Antworten geschrieben hat
• Die getesteten Versionen: Modell, Prompt, Dokumente und Sucheinstellungen
• Ergebnisse pro Fragetyp und Fehlerart, gemessen an vorab vereinbarten Abnahmeschwellen
• Jeder No-Go-Fall und sein Ergebnis
• Jeder gescheiterte Fall, gelesen und erklärt
• Die Ergebnisse Ihres Teams bei denselben Fällen
• Was der Assistent nicht übernimmt und wer nach dem Start die wöchentliche Stichprobe prüft

Die Freigabe kann auch teilweise erfolgen. Der Assistent kann für die Fragetypen live gehen, die bestanden haben, während die übrigen an einen Menschen gehen, bis auch sie bestehen.

Wem gehört das Testset?

Ihrem Unternehmen sollten die Fälle, die erwarteten Antworten, die Checklisten, die Skripte und die Historie der Ergebnisse gehören. Zusammen sind sie Ihre schriftliche Definition einer guten Antwort. Mit ihnen können Sie jedes spätere Modell und jeden späteren Anbieter am selben Maßstab messen.

Legen Sie sie in einem Speicher ab, den Sie kontrollieren, denn auch Werkzeuge von Anbietern werden eingestellt. Laut der Abkündigungsseite von OpenAI hat das Unternehmen Entwickler, die seine Evals-Plattform nutzen, am 3. Juni 2026 darüber informiert, dass das Produkt abgekündigt wird. Die Seite nennt den 31. Oktober 2026 als Datum, ab dem bestehende Evals nur noch gelesen werden können, und den 30. November 2026 für die geplante Abschaltung des Dashboards und der API.

Benennen Sie auf Ihrer Seite eine verantwortliche Person für das Set, die Zeit dafür hat, Fälle hinzuzufügen und Antworten zu aktualisieren, wenn sich Richtlinien ändern.

Was sollten wir einen Anbieter oder eine Firma fragen, die den Assistenten bauen würde?

Wenn ein Anbieter eine Genauigkeitszahl nennt, fragen Sie, woran sie gemessen wurde. Das Profil des NIST empfiehlt: „Bewerten Sie Aussagen über die Fähigkeiten von Modellen mit empirisch validierten Methoden.“ Stellen Sie dann jedem Anbieter und jeder Firma auf Ihrer Liste diese Fragen:

• Testen Sie mit unseren Fällen und mit erwarteten Antworten, die unsere Leute geschrieben haben?
• Welchen Teil des Testsets bekommen Sie vor dem finalen Durchlauf nicht zu sehen?
• Welche Abnahmeschwellen schlagen Sie für jeden Fragetyp und jede Fehlerart vor, und warum?
• Wie bewerten Sie Freitext, und wie haben Sie Ihr Bewertungsmodell am Urteil von Menschen überprüft?
• Können wir das ganze Set nach jeder Änderung selbst erneut laufen lassen, ohne Sie?
• Wer bezahlt den erneuten Test, wenn der Modellanbieter das Modell außer Betrieb nimmt?
• Erhalten wir am Ende die Fälle, die Checklisten, die Skripte und die Historie der Ergebnisse?

Wo passt amBrain ins Bild?

amBrain gibt diesen Blog heraus. Zu seinem eigenen Produkt sagt es: „Unser eigenes Produkt shyash.ai läuft auf KI-Agenten, die aus einem gemeinsamen Speicher von Unternehmensfakten recherchieren, schreiben, prüfen und messen. Ein Mensch gibt alles frei, was rausgeht.“

Über die Arbeit mit einem Sprachmodell in einem Kundenprojekt sagt amBrain: „Wir haben eine LLM-Integration innerhalb des FinTech-Perimeters eines Kunden in Produktion gebracht: die Extraktion und Normalisierung unstrukturierter Mitteilungen von Brokern und Handelsplätzen – Kapitalmaßnahmen, Instrumenten- und Margin-Änderungen – zu strukturierten Datensätzen, die das Handelssystem verarbeitet.“

Dieser Artikel ist keine Case Study und beschreibt keine Arbeit für Kunden über diese Zeile hinaus, die nicht sagt, wie das Projekt getestet wurde. Nichts hier behauptet, dass amBrain die oben beschriebenen Testsets, Abnahmeschwellen oder Freigabeschritte erstellt hat, oder sagt, wie shyash.ai getestet wird. Die Beispiele sind allgemein und stammen nicht aus der Arbeit von amBrain.

Die hier genannten Organisationen werden anhand ihrer veröffentlichten Seiten zitiert. Der Artikel behauptet keine Beziehung zwischen amBrain und einer von ihnen und nennt weder Preise noch Zeitpläne von amBrain.

amBrain entwickelt seit 2019 Software. Dazu, wie es mit Kunden arbeitet, sagt es: „Drei Formate: vollständige Umsetzung, ein dediziertes Team oder in Ihr Team eingebettete Entwickler.“ Zum Eigentum lautet sein Satz: „Der Kunde behält das volle Eigentum an Produkt und Code, ausgenommen unsere wiederverwendbaren Komponenten.“ Verlangen Sie vor der Unterschrift die namentliche Liste dieser Komponenten.

Dieser Artikel ist auch keine Rechtsberatung. Fragen Sie Ihre Anwälte, wie das Datenschutzrecht auf Testsets anzuwenden ist, die aus Kundendaten aufgebaut werden. Wenn amBrain auf Ihrer Shortlist steht, stellen Sie ihm dieselben Fragen wie jeder anderen Firma.