Kurz zusammengefasst
- Evals prüfen eine konkrete Anwendung in ihrem vorgesehenen Einsatz – nicht nur das zugrunde liegende Modell.
- Gute Testfälle bilden häufige Aufgaben, schwierige Randfälle und relevante Risiken aus dem Arbeitsalltag ab.
- Qualität besteht aus mehreren Kriterien wie Richtigkeit, Vollständigkeit, Quellenbezug, Sicherheit, Laufzeit und Kosten.
- Evals werden vor der Einführung, nach Änderungen und während des Betriebs wiederholt.
Was genau wird mit einem Eval geprüft?
Ein Eval verbindet eine klar beschriebene Aufgabe, passende Eingaben, erwartete Eigenschaften des Ergebnisses und eine nachvollziehbare Bewertung. Es beantwortet nicht allgemein, ob ein Modell intelligent ist, sondern ob eine konkrete Lösung unter definierten Bedingungen genügend gut funktioniert.
Dafür sollte möglichst die vollständige Anwendung geprüft werden: Prompt, Modell, abgerufene Quellen, Berechtigungen, Werkzeuge, Geschäftsregeln und Ausgabeformat. Ein Modell kann in einem öffentlichen Benchmark gut abschneiden und in einem konkreten Unternehmensprozess trotzdem ungeeignete Ergebnisse liefern.
- Aufgabenerfüllung: Wird das gewünschte Ergebnis tatsächlich erreicht?
- Fachliche Qualität: Sind Aussagen korrekt, vollständig und nachvollziehbar?
- Sicherheit: Werden unzulässige Inhalte, Aktionen oder Datenzugriffe verhindert?
- Betrieb: Bleiben Laufzeit, Stabilität und Kosten im vereinbarten Rahmen?
Was gehört in ein gutes Testset?
Das Testset sollte die tatsächliche Nutzung widerspiegeln. Eine Sammlung einfacher Musterfragen reicht nicht aus, wenn im Alltag unvollständige Angaben, widersprüchliche Dokumente, seltene Ausnahmen oder mehrdeutige Formulierungen vorkommen.
Beginnen Sie mit anonymisierten oder synthetisch nachgebildeten Fällen aus dem vorgesehenen Prozess. Ergänzen Sie neue Fehler aus Pilot und Betrieb laufend als Regressionstests, damit ein bereits gelöstes Problem nach einer Änderung nicht unbemerkt zurückkehrt.
- Häufige Standardfälle, die den grössten Teil der Nutzung ausmachen
- Geschäftskritische Fälle, bei denen ein Fehler besonders schwer wiegt
- Randfälle wie fehlende Angaben, widersprüchliche Quellen oder ungewöhnliche Sprache
- Negativfälle, bei denen die Lösung ablehnen oder nachfragen soll
- Angriffs- und Missbrauchsfälle, etwa manipulative Dokumente oder unzulässige Anweisungen
Wie werden Ergebnisse bewertet?
Die Bewertungsmethode hängt vom Kriterium ab. Ein strukturiertes Feld kann exakt mit einem Sollwert verglichen werden. Eine fachliche Zusammenfassung braucht möglicherweise eine Bewertungsrubrik und die Prüfung durch Fachpersonen. Ein weiteres Sprachmodell kann grössere Mengen vorsortieren, muss dafür aber selbst gegen menschliche Bewertungen kalibriert werden.
Ein einzelner Gesamtscore verdeckt häufig wichtige Unterschiede. Sinnvoller ist ein kleines Set von Qualitätsdimensionen mit klaren Mindestwerten und einer getrennten Betrachtung kritischer Fehler.
- Regelbasierte Prüfung für Format, Pflichtfelder, Zahlen oder erlaubte Werte
- Vergleich mit Referenzantworten oder freigegebenen Quellen
- Fachliche Stichprobe durch Personen mit Prozess- und Domänenwissen
- Modellgestützte Bewertung anhand einer präzisen Rubrik
- Manuelle Prüfung aller Fehlerklassen mit hohen Auswirkungen
Wie sieht eine ausgefüllte Eval-Scorecard aus?
Die folgende Scorecard zeigt ein vereinfachtes Beispiel für einen internen Wissensassistenten mit 100 versionierten Testfällen. Schwellenwerte werden vor dem Lauf festgelegt. Ein kritisches Ausschlusskriterium darf nicht durch gute Durchschnittswerte in anderen Dimensionen ausgeglichen werden.
| Kriterium | Mindestwert | Beispielresultat | Entscheid |
|---|---|---|---|
| Antwort durch freigegebene Quelle belegt | Mindestens 95 von 100 Fällen | 97 von 100 | Bestanden |
| Vollständige Muss-Aussagen | Mindestens 90 von 100 Fällen | 92 von 100 | Bestanden |
| Korrekte Ablehnung ohne Evidenz | Mindestens 9 von 10 Negativfällen | 8 von 10 | Nicht bestanden: Retrieval- und Ablehnungslogik verbessern |
| Kritische falsche Vertragsaussage | 0 Fälle | 1 Fall | Stop-Kriterium: keine Freigabe |
| Antwortzeit bei 95 Prozent der Anfragen | Höchstens 8 Sekunden | 6,2 Sekunden | Bestanden |
| Variable Kosten pro Anfrage | Höchstens CHF 0.08 | CHF 0.05 | Bestanden |
Wie entsteht ein belastbarer Eval-Prozess?
Evals sind am nützlichsten, wenn sie bereits vor der Modell- oder Anbieterwahl beginnen. Das Team übersetzt den erwarteten Nutzen und die möglichen Fehlerfolgen in überprüfbare Kriterien. Anschliessend lassen sich Prompts, Modelle oder Architekturvarianten unter denselben Bedingungen vergleichen.
- Schritt 1
Ziel festlegen
Beschreiben, welche Arbeit unterstützt wird, welches Ergebnis erwartet wird und wer es verwendet.
- Schritt 2
Erfolg definieren
Messbare Kriterien, Mindestwerte und nicht akzeptable Fehler festhalten.
- Schritt 3
Fälle sammeln
Reale Standard-, Grenz-, Risiko- und Negativfälle in einem versionierten Testset zusammenführen.
- Schritt 4
Ausführen und analysieren
Nicht nur Durchschnittswerte betrachten, sondern Fehlerarten und betroffene Nutzergruppen untersuchen.
- Schritt 5
Änderungen absichern
Vor einer Freigabe dieselben Tests erneut ausführen und Verschlechterungen sichtbar machen.
Warum endet Qualitätssicherung nicht mit dem Go-live?
Modelle, Prompts, Datenquellen und Nutzerverhalten verändern sich. Deshalb muss eine produktive Lösung neben festen Testsets auch reale Nutzungssignale beobachten: fachliche Korrekturen, Abbrüche, Ablehnungen, Laufzeit, Kosten und gemeldete Vorfälle.
Produktionsdaten ersetzen kein kontrolliertes Eval. Sie helfen jedoch, neue Fälle zu entdecken und zu prüfen, ob die Testverteilung weiterhin zum tatsächlichen Einsatz passt. Kritische Inhalte müssen vor ihrer Verwendung anonymisiert und nach den geltenden Zugriffs- und Aufbewahrungsregeln behandelt werden.
- Modell-, Prompt- und Datenänderungen versionieren
- Neue Fehler als wiederholbare Regressionstests aufnehmen
- Ergebnisse nach Falltyp statt nur als Gesamtdurchschnitt auswerten
- Klare Verantwortliche für Prüfung, Freigabe und Reaktion benennen
Beispiel: Qualität eines Wissensassistenten prüfen
Ein Serviceteam erstellt ein Testset aus anonymisierten Fragen zu Verträgen, Fristen und internen Abläufen. Für jeden Fall werden die freigegebenen Fundstellen sowie Muss- und Darf-nicht-Kriterien dokumentiert. Geprüft werden Quellenbezug, fachliche Vollständigkeit, richtige Ablehnung bei fehlender Evidenz und die Zeit bis zum Entwurf. Vor jedem Modell- oder Promptwechsel läuft dasselbe Testset erneut; neue Fehler aus der Pilotphase werden ergänzt.
Was Sie mitnehmen sollten
Definieren Sie Qualität aus Sicht der konkreten Arbeit. Ein kleines, gepflegtes Testset mit echten Fällen und klaren Fehlergrenzen ist für eine Unternehmensentscheidung wertvoller als ein allgemeiner Modellbenchmark.
Quellen und Vertiefung
Diese Primärquellen vertiefen Definitionen, technische Grundlagen oder verantwortlichen Einsatz.
Inhaltlich geprüft