KI-Features testen: Testset statt Bauchgefühl

Eine gute Demo ist noch kein gutes Produkt

Eine AI-Funktion kann in einer Präsentation beeindruckend wirken und im Alltag trotzdem enttäuschen. Für die Demo wird ein verständlicher Input gewählt, das Ergebnis passt zufällig gut und jemand formuliert den Prompt so lange um, bis die Antwort sitzt. Echte Nutzer bringen dagegen unvollständige Informationen, ungewöhnliche Schreibweisen, widersprüchliche Wünsche und Fälle mit, die niemand auf der Roadmap gesehen hat.

Das Problem ist nicht, dass ein Sprachmodell gelegentlich anders antwortet. Das Problem ist, wenn das Team keine gemeinsame Definition davon hat, welche Unterschiede akzeptabel sind und welche das Produkt unbrauchbar machen.

Ein kleines, gepflegtes Testset schafft diese Definition. Es macht Qualität wiederholbar sichtbar, bevor eine neue Anweisung, ein anderes Modell oder eine zusätzliche Datenquelle in Produktion geht.

Zuerst die Aufgabe beschreiben, nicht das Modell

„Die Antworten sollen besser werden“ lässt sich nicht testen. Eine brauchbare Produktaufgabe beschreibt, wer welchen Input liefert und was danach möglich sein muss.

Für eine AI-gestützte Sortierung von Kundenanfragen könnte die Aufgabe so lauten: Aus einer freien Nachricht werden Thema, Dringlichkeit und zuständiges Team abgeleitet. Unsichere Fälle werden nicht erfunden, sondern sichtbar zur Prüfung markiert. Das Ergebnis muss von der nachfolgenden Automatisierung eindeutig verarbeitet werden können.

Damit stehen bereits die wichtigsten Qualitätsdimensionen fest:

• Ist die erkannte Information fachlich richtig?
• Fehlt ein entscheidender Teil?
• hält sich das Ergebnis an das erwartete Format?
• wird Unsicherheit erkennbar?
• löst ein Fehler eine falsche oder riskante Aktion aus?

Die letzte Frage ist besonders wichtig. Ein falsches Komma und eine falsch priorisierte Sicherheitsmeldung sind nicht derselbe Fehler. Bewertung braucht den Kontext der späteren Entscheidung.

Ein Start-Testset aus echten Mustern bauen

Für den Anfang braucht es keine riesige Benchmark. Wichtiger ist, dass die Fälle das tatsächliche Produkt abbilden. Gute Quellen sind anonymisierte Support-Situationen, Beispielinhalte aus Workshops, bekannte Sonderfälle und bewusst konstruierte Grenzfälle.

Ein kompaktes Set sollte mehrere Gruppen enthalten:

1. Normale Fälle: häufige, klar formulierte Aufgaben, die zuverlässig funktionieren müssen.
2. Unvollständige Fälle: wichtige Angaben fehlen oder bleiben mehrdeutig.
3. Unbequeme Fälle: Tippfehler, Umgangssprache, lange Texte, gemischte Sprachen oder widersprüchliche Aussagen.
4. Riskante Fälle: Inhalte, bei denen das System ablehnen, eskalieren oder einen Menschen einbeziehen muss.
5. Nicht-Aufgaben: Eingaben, die ähnlich aussehen, aber bewusst nicht von der Funktion bearbeitet werden sollen.

Jeder Testfall braucht einen Namen, einen Input, relevante Rahmenbedingungen und eine Beschreibung des erwarteten Verhaltens. Personenbezogene Daten gehören nicht ungeprüft in diese Sammlung. Meist lassen sich Struktur und Schwierigkeit eines echten Falls erhalten, während Namen, Firmen und konkrete Details ersetzt werden.

Nicht immer eine Musterantwort verlangen

Bei klassischem Code lässt sich häufig ein exakter Rückgabewert prüfen. Natürliche Sprache erlaubt mehrere gute Antworten. Eine einzige goldene Formulierung würde sinnvolle Varianten fälschlich als Fehler markieren.

Besser ist eine Kombination aus festen Anforderungen und einer kurzen Bewertungsrubrik. Für eine generierte Zusammenfassung könnte sie so aussehen:

• Alle entscheidungsrelevanten Fakten sind enthalten.
• Keine Aussage wurde ergänzt, die nicht im Ausgangstext steht.
• Offene Fragen werden als offen benannt.
• Die Antwort bleibt innerhalb der vereinbarten Länge.
• Ton und Sprache passen zur Zielgruppe.

Jedes Kriterium kann beispielsweise mit „erfüllt“, „teilweise erfüllt“ oder „nicht erfüllt“ bewertet werden. Zusätzlich markieren wir kritische Fehler separat. Eine Antwort mit schönem Stil darf keinen guten Gesamtscore erhalten, wenn sie eine falsche Zahlungsfrist erfindet.

Erst messen, was sich eindeutig prüfen lässt

Ein Teil der Qualität lässt sich ohne weitere AI bewerten. Strukturierte Ausgaben können gegen ein Schema geprüft werden. Pflichtfelder, erlaubte Kategorien, Längen, Links oder Zahlenformate lassen sich deterministisch kontrollieren. Auch bekannte Begriffe und verbotene Inhalte können mit klaren Regeln erfasst werden.

Diese Prüfungen sind schnell, günstig und nachvollziehbar. Sie sollten vor jeder weicheren Bewertung laufen. Erst danach kommen Kriterien wie Relevanz, Verständlichkeit oder angemessener Ton.

Für solche offenen Kriterien bleibt eine menschliche Stichprobe der verlässlichste Ausgangspunkt. Eine modellgestützte Bewertung kann später Routinearbeit übernehmen, sollte aber zuerst an bereits von Menschen bewerteten Fällen kalibriert werden. Wenn menschliche Reviewer regelmäßig uneinig sind, ist meist die Rubrik noch unklar — nicht der automatische Bewerter zu schwach.

Änderungen immer gegen denselben Hafen fahren

Prompts, Modelle, Datenquellen und Nachbearbeitung bilden gemeinsam die Funktion. Ändert sich nur ein Teil, kann sich die Qualität an unerwarteter Stelle verschieben. Eine präzisere Antwort wird vielleicht länger. Eine strengere Struktur kann bei ungewöhnlichen Eingaben häufiger scheitern. Ein neues Dokument verbessert die Fachlichkeit und bringt gleichzeitig veraltete Informationen zurück.

Deshalb erhält jede prüfbare Variante eine eindeutige Version. Das Testset läuft vor und nach der Änderung unter denselben Bedingungen. Verglichen werden nicht nur Durchschnittswerte, sondern auch einzelne Rückschritte und kritische Fehler.

Hilfreiche Fragen für den Vergleich sind:

• Welche bisher guten Fälle sind schlechter geworden?
• Welche Fehlerklasse wurde tatsächlich reduziert?
• Sind Laufzeit und Kosten noch passend für den Produktablauf?
• Entsteht die Verbesserung nur in einer Sprache oder Nutzergruppe?
• Gibt es neue Fälle, die jetzt ausdrücklich in das Testset gehören?

So wird aus „fühlt sich besser an“ eine Entscheidung mit sichtbaren Konsequenzen.

Beispiel: Anfragen für ein Serviceteam vorsortieren

Angenommen, eine Website empfängt freie Nachrichten und soll sie den Bereichen Verkauf, Support oder Abrechnung zuordnen. Zusätzlich soll sie Dringlichkeit erkennen und eine kurze Zusammenfassung vorbereiten.

Das erste Testset enthält typische Produktfragen, bestehende Kunden mit technischen Problemen, Rechnungsfragen, Spam und mehrere Mischfälle. Eine Nachricht fragt etwa nach einem neuen Vertrag und erwähnt gleichzeitig einen Ausfall im bestehenden Account. Die richtige Reaktion ist nicht einfach „Verkauf“ oder „Support“, sondern eine definierte Prioritätsregel und eine sichtbare Begründung für den Mitarbeiter.

Deterministische Checks prüfen, ob Kategorie, Dringlichkeit und Zusammenfassung vorhanden sind. Reviewer beurteilen, ob die Zuordnung fachlich passt, ob wesentliche Informationen fehlen und ob Unsicherheit ehrlich behandelt wird. Kritisch ist jede Einstufung, die eine akute Störung als normale Verkaufsanfrage ablegt.

Nach einer Änderung werden genau dieselben Fälle erneut ausgeführt. Neue Produktionsfehler kommen anonymisiert als zusätzliche Regressionstests hinzu. Das Testset wächst damit nicht zufällig, sondern entlang realer Produktlektionen.

Qualität nach dem Launch weiter beobachten

Ein Testset deckt nur bekannte Situationen ab. In Produktion verändern sich Sprache, Kundengruppen, Angebote und Daten. Das Produkt braucht deshalb einen sicheren Rückkanal.

Sinnvoll sind explizite Nutzerkorrekturen, stichprobenartige Reviews und technische Signale wie Formatfehler oder häufige Wiederholungsversuche. Dabei sollte nur gesammelt werden, was für die Verbesserung wirklich nötig und datenschutzrechtlich vorgesehen ist. Sensible Inhalte dürfen nicht automatisch in ein dauerhaftes Trainingsarchiv wandern.

Wiederkehrende Fehler werden zunächst beschrieben, dann als bereinigter Testfall ergänzt und erst danach behoben. So bleibt die Ursache nachvollziehbar und die Verbesserung kann später nicht unbemerkt verloren gehen.

Eine pragmatische Routine für kleine Teams

Für viele AI-Funktionen reicht zu Beginn dieser Ablauf:

1. Kernaufgabe und Folgen eines Fehlers beschreiben.
2. Reale, schwierige und riskante Fälle sammeln und anonymisieren.
3. Erwartetes Verhalten und kritische Fehler pro Fall notieren.
4. Eindeutige Anforderungen automatisch prüfen.
5. Offene Qualitätskriterien mit einer kurzen Rubrik bewerten.
6. Jede relevante Variante gegen dasselbe Set laufen lassen.
7. Rückschritte vor dem Launch bewusst akzeptieren oder beheben.
8. Neue Produktionslektionen als Regressionstests aufnehmen.

Gute AI entsteht aus guten Entscheidungen

Ein Testset macht ein probabilistisches System nicht vollkommen vorhersehbar. Es macht aber sichtbar, ob eine Änderung das Produkt für die vorgesehenen Aufgaben verlässlicher oder nur in einer Demo beeindruckender macht.

Das ist der eigentliche Gewinn: Das Team diskutiert nicht mehr über einzelne Lieblingsantworten. Es entscheidet gemeinsam, welche Qualität Nutzer brauchen, welche Fehler tolerierbar sind und wann eine AI-Funktion bereit ist, echte Arbeit zu übernehmen.