KI Workflow testen: Qualität mit Referenzfällen messbar machen

Ein KI-Workflow kann bei einer Vorführung überzeugend wirken und im laufenden Betrieb trotzdem unzuverlässig sein. Einzelne gute Ausgaben zeigen nicht, ob der Prozess mit unterschiedlichen Eingaben, fehlenden Informationen oder Änderungen am Modell stabil bleibt. Für Geschäftsführung, Produktverantwortliche und technische Leitung lautet die entscheidende Frage daher nicht nur, ob die KI eine Aufgabe erledigt. Entscheidend ist, woran Sie korrekte Ergebnisse erkennen, wie Sie Fehler sichtbar machen und wann ein Schritt gestoppt oder einem Menschen vorgelegt werden muss. Der Prove-Gedanke setzt dafür auf Referenzfälle, nachvollziehbare Bewertungskriterien und wiederholbare Prüfungen. So wird Qualität nicht mit einem allgemeinen Eindruck verwechselt, sondern anhand der Anforderungen des konkreten Workflows beurteilt.

Kurz gesagt

Ein KI-Workflow ist erst dann belastbar geprüft, wenn seine Ergebnisse an repräsentativen Referenzfällen bewertet werden. Legen Sie vor dem Test fest, welche Eigenschaften ein akzeptables Ergebnis haben muss und welche Fehler den Ablauf stoppen. Prüfen Sie sowohl einzelne Fälle als auch Stichproben im Betrieb und führen Sie nach relevanten Änderungen Regressionstests aus. Wo ein falsches Ergebnis Folgen haben kann, gehört eine menschliche Prüfung oder ein Quality Gate in den Prozess.

Ausgangslage

Klassische Software folgt bei gleichen Eingaben meist denselben Regeln. KI-Ausgaben können dagegen variieren. Schon eine geänderte Anweisung, ein anderes Modell oder eine veränderte Datenquelle kann beeinflussen, was ein Workflow zurückgibt. Ein Test, der nur einen erfolgreichen Durchlauf zeigt, beantwortet deshalb nicht, wie sich das System bei anderen Fällen verhält.

Auch „Qualität“ ist ohne konkreten Auftrag zu ungenau. Bei einer Zusammenfassung kann es auf Vollständigkeit und Quellentreue ankommen. Bei der Datenextraktion zählen möglicherweise korrekte Felder und ein klarer Umgang mit fehlenden Angaben. Bei einer Klassifikation sind die Folgen einer falschen Kategorie entscheidend. Der Prüfmaßstab muss zum Prozess und zu den Konsequenzen passen.

Das Ziel ist nicht, jede mögliche Ausgabe vorab festzulegen. Es geht darum, überprüfbare Eigenschaften des Ergebnisses und Grenzen des Workflows zu definieren. Damit wird sichtbar, welche Fälle automatisch weiterlaufen dürfen und welche eine Prüfung benötigen.

Entscheidungskriterien

1. Referenzfälle müssen den Einsatz abbilden

Ein Referenzfall besteht aus einer repräsentativen Eingabe und einer Beschreibung dessen, was ein akzeptables Ergebnis ausmacht. Sammeln Sie nicht nur einfache Standardfälle. Berücksichtigen Sie auch unvollständige, mehrdeutige oder widersprüchliche Eingaben sowie Fälle, bei denen der Workflow keine belastbare Antwort geben sollte.

Die Fälle sollten aus dem tatsächlichen Prozess stammen oder dessen relevante Bedingungen nachvollziehbar nachbilden. Achten Sie darauf, keine unnötigen personenbezogenen oder vertraulichen Daten in Testmaterial aufzunehmen. Bei sensiblen Anwendungen ist zusätzlich zu prüfen, wer Testdaten sehen und verändern darf.

2. Bewertungskriterien vor dem Lauf festlegen

Beschreiben Sie Eigenschaften statt eines einzigen idealen Wortlauts. Je nach Aufgabe können dazu gehören:

• erforderliche Felder sind vorhanden und passend typisiert;
• Aussagen lassen sich aus der Eingabe oder einer angegebenen Quelle ableiten;
• Unsicherheit oder fehlende Angaben werden kenntlich gemacht;
• unzulässige oder nicht angeforderte Inhalte fehlen;
• bei einem kritischen Fehler wird nicht automatisch weitergearbeitet.

Trennen Sie dabei harte Bedingungen von abgestuften Qualitätsurteilen. Ein fehlendes Pflichtfeld kann einen Test sofort scheitern lassen. Eine knappe, aber verständliche Formulierung kann dagegen innerhalb einer Bewertungsstufe akzeptabel sein. Wenn Menschen bewerten, benötigen sie eine gemeinsame Skala und kurze Anweisungen. Andernfalls misst der Test unterschiedliche persönliche Erwartungen.

3. Prüfverfahren an die Eigenschaft anpassen

Ein Teil der Anforderungen lässt sich technisch prüfen: etwa ob ein JSON-Objekt gültig ist, Pflichtfelder enthält oder zulässige Werte verwendet. Andere Eigenschaften, wie Quellentreue oder die Relevanz einer Zusammenfassung, benötigen fachliche Bewertung. Ein einzelner Gesamtscore kann beides verdecken.

Definieren Sie für jedes Kriterium, wie es geprüft wird und wer bei Zweifeln entscheidet. Wo eine automatische Bewertung eingesetzt wird, sollte sie anhand menschlich bewerteter Fälle überprüft werden. Eine automatisierte Bewertung ist selbst ein Verfahren mit Grenzen, kein unabhängiger Beweis für Qualität.

Das folgende Beispiel zeigt eine Testdefinition. Es legt Eigenschaften und Bewertungskriterien fest, aber keinen exakten Wortlaut der erwarteten Ausgabe:

{
  "input": {
    "task": "Angaben aus dem Auszug zuordnen",
    "document": "Der Satz beträgt 12 Prozent. Im Auszug steht kein Aufschlag."
  },
  "expected_properties": [
    "Der Satz wird als Prozentwert ausgegeben.",
    "Der Aufschlag wird nicht aus dem Satz abgeleitet.",
    "Eine im Auszug fehlende Angabe wird als nicht angegeben markiert."
  ],
  "evaluation_criterion": {
    "pass": "Alle Eigenschaften sind erfüllt; fehlende Angaben werden nicht erfunden.",
    "fail": "Ein Wert wird ergänzt, verwechselt oder als belegt dargestellt, obwohl er fehlt."
  }
}

Die Prüfung bezieht sich auf Bedeutung und Verhalten, nicht auf eine bestimmte Formulierung. Falls der Workflow strukturierte Daten liefern muss, können Sie zusätzlich Schema und zulässige Werte technisch validieren. Das ersetzt aber nicht die Prüfung, ob der Inhalt sachlich aus der Eingabe folgt.

4. Stichproben nach Risiko auswählen

Nicht jeder Fall muss gleich häufig oder gleich aufwendig geprüft werden. Legen Sie fest, welche Fälle wegen möglicher Folgen, geringer Sicherheit oder ungewöhnlicher Eingaben vorrangig eine menschliche Kontrolle erhalten. Prüfen Sie daneben eine Stichprobe der Fälle, die automatisch weiterlaufen. So wird nicht nur die Fehlerquote in auffälligen Fällen betrachtet, sondern auch, ob der unauffällige Normalbetrieb stabil bleibt.

Die Stichprobe sollte dokumentiert sein: Welche Fälle wurden geprüft, nach welchen Kriterien und mit welchem Ergebnis? Eine feste, wiederholbare Auswahl macht Veränderungen über die Zeit besser erkennbar als zufällige Einzelkontrollen ohne Protokoll.

5. Regressionen und Quality Gates definieren

Ein Regressionstest prüft bekannte Referenzfälle erneut, nachdem sich etwas geändert hat. Als Auslöser kommen beispielsweise Änderungen an Anweisungen, Datenaufbereitung, Modell oder nachgelagerten Regeln infrage. Halten Sie fest, was sich geändert hat und welche Tests davon betroffen sind.

Ein Quality Gate legt fest, ob der nächste Prozessschritt ausgeführt werden darf. Das Gate kann etwa verlangen, dass Pflichtfelder validiert sind, bestimmte Fehler nicht auftreten oder eine Person den Fall freigegeben hat. Legen Sie auch fest, was bei einem nicht bestandenen Test geschieht: anhalten, zur Prüfung weiterleiten oder einen kontrollierten Rückfall auf einen früheren Prozessschritt auslösen.

6. Im Betrieb auf Veränderungen achten

Vor dem Start sind Tests eine kontrollierte Momentaufnahme. Im Betrieb können sich Eingaben und Daten verändern, und Fehlerbilder zeigen sich erst über mehrere Fälle. Erfassen Sie daher geeignete Qualitätsindikatoren, etwa fehlgeschlagene Validierungen, menschliche Korrekturen oder Fälle, die wegen fehlender Informationen angehalten wurden.

Definieren Sie, wer diese Signale prüft und wann daraus eine Untersuchung folgt. Speichern Sie nur Informationen, die für Betrieb und Prüfung erforderlich sind, und beachten Sie die internen Anforderungen an Datenschutz und Zugriffsrechte. Monitoring ohne Zuständigkeit ist lediglich Datensammlung.

Typische Fehler

• Nur mit einem Erfolgsfall testen: Das belegt nicht, wie der Workflow mit Varianten oder fehlenden Informationen umgeht.
• Nachträglich bewerten: Wer erst nach dem Lauf festlegt, was als gut gilt, riskiert, den Maßstab an das Ergebnis anzupassen.
• Nur das Ausgabeformat prüfen: Gültiges JSON kann sachlich falsch oder unbelegt sein.
• Eine Kennzahl für alles verwenden: Ein Mittelwert kann kritische Einzelfehler verdecken.
• Änderungen nicht nachtesten: Eine Anpassung an Anweisung, Modell oder Datenfluss kann bestehende Ergebnisse beeinflussen.
• Menschliche Prüfung ohne klare Regeln einsetzen: Ohne Kriterien und Zuständigkeit entstehen uneinheitliche Freigaben.
• Monitoring mit Kontrolle gleichsetzen: Ein Signal hilft nur, wenn klar ist, wer es bewertet und welche Reaktion folgt.

Praxisbeispiel

Bei Ting antworten mehrere KI-Anbieter unabhängig und stimmen strukturiert mit „approve“, „revise“ oder „reject“ ab. Eine Freigabe erfolgt nur bei Einstimmigkeit; strukturierte Ausgaben werden per Schema abgebildet. Das veranschaulicht zwei prüfbare Eigenschaften eines Workflows: die zulässigen Abstimmungswerte und eine klare Freigabebedingung. Daraus folgt nicht automatisch, dass die inhaltliche Qualität jeder Antwort belegt ist. Dafür braucht es zusätzlich passende Referenzfälle und Kriterien, die die konkreten Aufgaben bewerten. Ting ansehen

Empfehlung

Wenn ein Fehler leicht erkennbar und folgenarm ist, starten Sie mit einem kleinen Satz repräsentativer Referenzfälle, technischen Validierungen und einer dokumentierten Stichprobe.

Wenn Ausgaben in nachgelagerte Prozesse einfließen oder fachlich schwer zu beurteilen sind, definieren Sie vorab Kriterien, menschliche Prüfregeln und ein Quality Gate. Prüfen Sie Regressionen nach Änderungen am Workflow.

Wenn falsche Ergebnisse erhebliche Folgen haben können oder die Aufgabe sensible Entscheidungen berührt, automatisieren Sie nicht allein auf Grundlage eines guten Durchschnittswerts. Begrenzen Sie den automatischen Handlungsspielraum, legen Sie Eskalationswege fest und prüfen Sie die Anforderungen im konkreten Einsatz. Die rechtliche Bewertung ist gesondert und im Einzelfall vorzunehmen.

Checkliste

• Ist der konkrete Zweck des KI-Workflows dokumentiert?
• Gibt es Referenzfälle für Standardfälle, Grenzfälle und unvollständige Eingaben?
• Sind akzeptable Eigenschaften des Ergebnisses vor dem Test festgelegt?
• Sind harte Fehler von abgestuften Qualitätsurteilen getrennt?
• Ist festgelegt, welche Eigenschaften technisch und welche fachlich geprüft werden?
• Gibt es Regeln für Stichproben und menschliche Freigaben?
• Werden Referenzfälle nach relevanten Änderungen erneut geprüft?
• Legt ein Quality Gate fest, wann der Workflow weiterläuft oder stoppt?
• Sind Monitoring, Zuständigkeit und Reaktion auf Auffälligkeiten definiert?

Häufige Fragen

Muss jede KI-Ausgabe manuell geprüft werden?

Nicht zwingend. Die Entscheidung hängt von den Folgen eines Fehlers und der Verlässlichkeit der automatischen Prüfungen ab. Auch wenn nicht jeder Fall geprüft wird, sollten Stichproben und klare Eskalationsregeln vorgesehen sein.

Wie viele Referenzfälle sind nötig?

Eine feste Zahl passt nicht für jeden Workflow. Entscheidend ist, ob die Fälle die relevanten Eingaben, Fehlerarten und Grenzen abdecken. Ergänzen Sie Fälle, wenn im Betrieb neue Muster auftreten.

Wie oft sollte ein KI-Workflow getestet werden?

Führen Sie Tests vor dem produktiven Einsatz und nach relevanten Änderungen durch. Ergänzen Sie regelmäßige Stichproben im Betrieb. Welche Intervalle passen, hängt von Veränderungshäufigkeit und Risikoprofil ab.

Weiterführend

• KI-Automatisierung im Unternehmen: Prozesse sicher steuern
• Human-in-the-loop: Warum gute KI-Workflows Menschen nicht entfernen
• Strukturierte Ausgaben mit KI und JSON
• AI Guardrails: Wie sich KI-Ausgaben begrenzen und prüfen lassen

Weiterführende Quellen

Diese offiziellen Dokumentationen und Standards vertiefen die behandelten Themen.

• NIST AI Risk Management Framework
• OpenAI: Structured Outputs