KI-Evaluation ohne Vendor-Lock-in: Was exportierbar sein muss
Eine KI-Evaluation ist ausreichend portabel, wenn Ihr Team sie außerhalb der ursprünglichen Plattform nachvollziehen und mit vertretbarem Aufwand erneut ausführen kann. Ein Export mit Fragen und Antworten genügt dafür bei komplexeren Aufgaben nicht: Erforderlich sind auch Erwartungen, Bewertungslogik, Versionen und Ergebnisse pro Testfall.
Die Plattform kann die Ausführung und Auswertung übernehmen. Die fachlichen Abnahmekriterien sollten zusätzlich in einer von Ihnen kontrollierten Form vorliegen.
Warum dieses Thema gerade konkret wird
OpenAI kündigte am 3. Juni 2026 die Einstellung der bisherigen Evals-Plattform an. Bestehende Evals sollen ab 31. Oktober 2026 nur noch lesbar sein; Dashboard und API sollen am 30. November 2026 abgeschaltet werden. Auch die zugehörigen Grader sind Teil der Umstellung. Die offizielle Deprecation-Dokumentation verweist auf Promptfoo als Migrationspfad. Quellenstand: 22. Oktober 2026.
Diese Ankündigung betrifft ein konkretes Produkt. Sie ist zugleich ein praktischer Anlass, die eigenen Evaluationsartefakte zu prüfen: Welche Informationen existieren ausschließlich im Anbieter-Dashboard?
Auch Aufbewahrungsgrenzen sind relevant. Microsoft dokumentiert für Einzelantworttests in Copilot Studio, dass Testergebnisse 89 Tage verfügbar sind und für eine längere Speicherung als CSV exportiert werden müssen. Der dokumentierte Testfallimport verwendet CSV oder TXT mit Frage und erwarteter Antwort.
Ein verfügbares Importformat beweist noch keinen vollständigen Export. Prüfen Sie beide Richtungen und den tatsächlich enthaltenen Informationsumfang.
Was „portabel“ hier bedeutet
Portabilität bedeutet nicht, dass dieselbe Datei unverändert in jedem Werkzeug läuft. APIs, Grader und Trace-Formate unterscheiden sich; Adapter können notwendig bleiben.
Ihr Team sollte außerhalb der bisherigen Plattform erklären können:
- welches Verhalten getestet wurde,
- welche Daten und welcher Ausgangszustand galten,
- welches Ergebnis als richtig, falsch oder unzulässig bewertet wurde,
- wie die Bewertung berechnet wurde,
- welche Modell-, Prompt-, Tool- und Datenversion aktiv war,
- warum die getestete Konfiguration freigegeben oder abgelehnt wurde.
Der Nachweis gelingt erst, wenn ein alternatives Testsystem dieselben fachlichen Kriterien anwenden kann. Eine lesbare Archivdatei ist dafür ein Anfang, aber noch kein Ausführungstest.
Acht Bestandteile eines portablen Eval-Pakets
Die folgende Tabelle ist eine vorgeschlagene technische Prüfhilfe, kein formaler Standard.
| Bestandteil | Was gespeichert werden sollte | Zweck |
|---|---|---|
| Testfall-ID | Stabile ID, Titel, Kategorie und Herkunft | Fälle und Ergebnisse über Läufe vergleichen |
| Eingabe und Ausgangszustand | Anfrage, Rolle, Prozessdaten und Quellenreferenzen | Die für den Fall geltenden Bedingungen rekonstruieren |
| Erwartetes Verhalten | Erwartetes Ergebnis, erlaubte Varianten und Mindestanforderungen | Fachlichen Erfolg definieren |
| Verbotenes Verhalten | Kritische Fehler, unzulässige Aktionen und Eskalationsregeln | Grenzen auch bei richtigem Endergebnis prüfen |
| Grader | Prüfregel, Rubrik, Skala, Schwellenwert und Referenzdaten | Scores erklären und neu berechnen |
| Laufkonfiguration | Modell, Prompt, Tools, Retrieval-Konfiguration und Versionen | Änderungen nachvollziehen |
| Ergebnis pro Testfall | Ausgabe, Prüfresultate, Fehlerklasse, Latenz und relevante Trace-Referenzen | Einzelne kritische Fehler erkennen |
| Freigabeentscheidung | Grenzwerte, Ausnahmen, menschliche Prüfung und Begründung | Die Betriebsentscheidung nachvollziehen |
Bei RAG gehören erwartete Quellen, Dokumentversionen und die relevante Retrieval-Evidenz dazu. Wie Retrieval und Antwortqualität getrennt geprüft werden, beschreibt die RAG-Evaluation mit Golden Dataset.
Bei Agenten sind außerdem Tool Calls, Parameter, Abbruchbedingungen und erwartete Zustandsänderungen relevant. Die AI Agent Evaluation behandelt diese Ausführungsebene.
Warum zwei CSV-Spalten nicht immer ausreichen
Für einen einfachen FAQ-Test können Frage und erwartete Antwort genügen. Bei einem produktiven Workflow hängt die korrekte Reaktion aber möglicherweise von Rolle, Produktgruppe, Dokumentversion oder Prozesszustand ab.
Eine reine Musterantwort erfasst außerdem nicht automatisch:
- die Pflicht zur Quellenangabe,
- den zulässigen Fall „Information nicht vorhanden“,
- notwendige Rückfragen,
- verbotene Aktionen,
- erlaubte Tool-Aufrufe,
- die Gewichtung eines kritischen Fehlers.
Das Dateiformat entscheidet nicht über die Qualität. CSV passt zu flachen Daten; verschachtelte Zustände oder mehrere Referenzen lassen sich beispielsweise in JSONL abbilden. Dokumentieren und versionieren Sie in beiden Fällen das Schema.
Eine kleine, werkzeugunabhängige Paketstruktur
| Datei oder Verzeichnis | Inhalt |
|---|---|
README.md | Zweck, Scope, verantwortliche Person und Ausführungsanleitung |
manifest.yaml | Paketversion, Datenklassifikation und Konfiguration |
cases.jsonl | Eingaben, Ausgangszustände und Erwartungen |
rubrics/ | Bewertungsrubriken und Labeldefinitionen |
checks/ | Deterministische Prüfregeln |
runs/ | Fallresultate einzelner Evaluationsläufe |
decisions/ | Freigaben, Abweichungen und begründete Ausnahmen |
Die Struktur ist eine Empfehlung. Für einen kleinen Assistenten kann eine versionierte Tabelle mit verständlichen Bewertungsregeln ausreichen.
Das Manifest sollte zumindest Workflow, Paket- und Schemaversion, Testset-Version, Rubrik-Version und verwendete Konfigurationsstände referenzieren. Kennzeichnen Sie außerdem, welche Quelldaten nur referenziert werden und wie ein berechtigter Prüfer sie wiederherstellen kann.
Grader müssen genauso nachvollziehbar sein wie Testfälle
Deterministische Prüfungen
Regeln wie „Ausgabe erfüllt das JSON-Schema“, „Betrag entspricht der fachlichen Berechnung“ oder „es wurde keine Schreibaktion ausgeführt“ sollten als nachvollziehbarer Code oder deklarative Regel vorliegen.
Speichern Sie auch Beispiele für Bestehen und Nichtbestehen. Damit kann das Team prüfen, ob eine nachgebaute Regel dasselbe Verhalten bewertet.
Bewertungsrubriken
Eine Rubrik benötigt das Kriterium, eine definierte Skala, Beispiele und einen Schwellenwert. Kritische Fehler, die unabhängig von anderen Teilwerten zur Ablehnung führen, gehören ausdrücklich hinein.
LLM-as-Judge
Wenn ein Modell bewertet, dokumentieren Sie Modellkennung, Grader-Prompt, Eingabefelder, Ausgabeformat, Parameter und Kalibrierungsfälle. Speichern Sie fachliche Referenzbewertungen für die Überprüfung des Graders.
OpenAI empfiehlt in seinen Evaluation Best Practices, automatische Bewertungen mit menschlichen Urteilen abzugleichen und Testdaten um typische, ungewöhnliche und adversariale Fälle zu ergänzen.
Ein „Quality Score 84“ lässt sich ohne Rubrik, Grader-Version und Fallresultate nicht belastbar interpretieren. Ein anderes Grader-Modell kann zudem anders bewerten. Portabilität verspricht deshalb keine identischen Scores; sie soll die Unterschiede prüfbar machen.
Fiktives Beispiel: Der Download enthält zu wenig für einen Wechsel
Ein Unternehmen testet einen Service-Assistenten mit 60 Fällen. Das Dashboard zeigt 84 Prozent Gesamtqualität. Der Export enthält alle Fragen, generierten Antworten und den Gesamtscore.
Es fehlen jedoch Nutzerrollen, erwartete Dokumentversionen, Fälle mit Antwortverweigerung, der Grader-Prompt und die Modell- und Prompt-Version. Dieses Beispiel ist vollständig fiktiv und beschreibt keinen Plattformtest.
Das Team kann den sichtbaren Inhalt archivieren. Es kann aber nicht erklären, wie die 84 Prozent zustande kamen. Vor einem Vergleich müsste es die Bewertungsgrundlage rekonstruieren.
Ein sinnvoller erster Schritt wäre, eine kleine Teilmenge einschließlich eines Rollen- und eines No-Answer-Falls außerhalb der Plattform wiederherzustellen. Die dabei fehlenden Informationen zeigen, was im regulären Export ergänzt werden muss.
Der Exit-Test in fünf Schritten
- Paket exportieren. Testfälle, Regeln, Grader-Konfigurationen, Einzelresultate, Annotationen und Versionen sichern. Prüfen Sie ihre Beziehungen und nicht nur die Dateianzahl.
- Repräsentative Fälle auswählen. Standardfall, Grenzfall, fehlende Information, verbotene Aktion und Eskalation berücksichtigen, soweit sie zum Workflow gehören.
- Außerhalb der Plattform ausführen. Einen kleinen alternativen Runner mit denselben fachlichen Kriterien verwenden. Tool- und Schreibaktionen nur in kontrollierten Testumgebungen ausführen.
- Unterschiede klassifizieren. Fehlende Daten, nicht übertragbare Grader und fehlende Zustände von echten Qualitätsunterschieden des Systems trennen.
- Aufwand dokumentieren. Wiederverwendbare Teile, notwendige Adapter, manuelle Rekonstruktion und verbleibende Lücken festhalten.
Das Ergebnis ist eine begründete Einschätzung des Exit-Aufwands. Ein erfolgreicher Download alleine liefert sie nicht.
Was Sie vor Kauf oder Verlängerung klären sollten
- Sind Testfälle und stabile IDs gesammelt und maschinenlesbar exportierbar?
- Bleiben Beziehungen zu Läufen, Einzelbewertungen und Annotationen erhalten?
- Können benutzerdefinierte Rubriken, Grader-Prompts und Schwellenwerte exportiert werden?
- Sind Ausgaben, relevante Traces und Konfigurationsversionen enthalten?
- Wie lange bleiben historische Ergebnisse verfügbar?
- Gibt es einen dokumentierten Export per API oder nur manuelle Downloads?
- Sind Nutzungsrechte an Testdaten, Rubriken und abgeleiteten Ergebnissen geklärt?
- Wurde die Wiederherstellung außerhalb der Plattform tatsächlich erprobt?
Technische Portabilität und vertragliche Nutzungsrechte sind getrennte Fragen. Ein vertragliches Exportrecht belegt noch keinen brauchbaren technischen Export.
Datenkontrolle gehört zum Paket
Testfälle und Traces können vertrauliche Inhalte enthalten. Speichern Sie nur die für die Prüfung benötigte Evidenz und schützen Sie den Export entsprechend seiner Datenklasse. Zugangsdaten gehören nicht in das Paket; stattdessen werden notwendige Verbindungen und Rechte dokumentiert.
Export und Löschung sind ebenfalls unterschiedliche Vorgänge. Ein erfolgreiches Archiv sagt nichts darüber aus, wann Kopien in der bisherigen Plattform gelöscht werden. Dafür müssen deren konkrete Aufbewahrungs- und Löschverfahren geprüft werden.
Der Aufwand sollte zum System passen
Ein kleiner, vollständig manuell geprüfter Assistent braucht möglicherweise nur ein extern gespeichertes Testset und verständliche Rubriken. Ein geschäftskritischer Agent mit Schreibzugriff benötigt zusätzlich nachvollziehbare Zustände, Tool-Erwartungen und Freigaben.
Mehr eigene Kontrolle bringt auch Pflegeaufwand mit sich. Die Architekturentscheidung zu Private AI und Public Cloud hilft, diese Verantwortung bewusst zu verteilen.
Der nächste sinnvolle Schritt
Nehmen Sie einen bestehenden Lauf und versuchen Sie, fünf unterschiedliche Testfälle ausschließlich anhand des Exports zu erklären und erneut auszuführen. Das ist ein erster Lückentest, kein vollständiger Nachweis für alle Aufgaben.
Müssen Sie Wissen aus einer Anbieteroberfläche oder dem Gedächtnis einzelner Personen nachtragen, ergänzen Sie die fehlenden Artefakte. Für ein vorhandenes System kann die Prüfung im Rahmen eines begrenzten AI Production Readiness & Reliability Sprints erfolgen. Den genauen Umfang legen wir anhand Ihres Systems fest.