Testprotokoll · keine Messergebnisse
Ein Industrie-Workflow, zwei Modelle: Testprotokoll für einen Modellwechsel
Ob sich ein Modell austauschen lässt, zeigt sich am Ergebnis des Workflows. Ein erfolgreicher API-Aufruf reicht nicht. Dieses Protokoll beschreibt einen begrenzten Vergleich: Zwei Modelle sollen technische Anforderungen aus denselben synthetischen Anfrageunterlagen in einen prüfbaren Entwurf überführen.
Status: Testprotokoll. Es liegen zu diesem Versuch noch keine gemessenen Ergebnisse vor. Die folgenden Fallzahlen und Wiederholungen sind ein vorgeschlagener Versuchsaufbau. Sie sind weder ein Industriestandard noch ein Nachweis über Welf-Kundenprojekte.
Leere Ergebnistabelle als CSV herunterladen
Die Frage des Versuchs
Kann dieselbe Anwendung mit einem zweiten Modell einen fachlich brauchbaren Anforderungsentwurf erzeugen, ohne dass Geschäftsregeln oder Freigaben geändert werden müssen?
Die Anwendung darf keine Preise festlegen und keine Daten in ein produktives ERP schreiben. Sie gibt ein strukturiertes Ergebnis mit Quellen, Widersprüchen und offenen Angaben zurück. Untersucht werden Ergebnisqualität, menschlicher Prüfaufwand und die für den Wechsel nötigen Anpassungen.
Ein begrenzter Testsatz
Vorgesehen sind 40 synthetische Anfragen mit fiktiven Bauteilen. Zwanzig bilden gewöhnliche vollständige Fälle ab. Zehn enthalten fehlende oder widersprüchliche Angaben. Fünf prüfen Format- und Revisionsprobleme; fünf enthalten unzulässige Handlungsanweisungen im Dokument.
Erstellen Sie außerdem einen getrennten Entwicklungssatz. Die 40 Bewertungsfälle bleiben bis zum festgelegten Vergleich unangetastet. Werden sie später zur Verbesserung der Anwendung genutzt, braucht die nächste unabhängige Bewertung neue Fälle.
Eine fachkundige Person erstellt für jeden Fall das erwartete Ergebnis und die zulässigen Quellen. Eine zweite prüft strittige Zuordnungen. Auch synthetische Daten brauchen diese Kontrolle: Sie können fachlich unplausible oder zu einfache Aufgaben enthalten.
Was für beide Varianten gleich bleibt
Verwenden Sie dieselben Dokumente, Extraktionsfelder, Geschäftsregeln und Bewertungsmaßstäbe. Erfassen Sie Modellkennung, Version soweit verfügbar, Parameter, Prompt-Version, Hardware oder Hostingprofil und Datum.
Führen Sie zwei Vergleiche getrennt aus. Der erste hält den Anwendungsaufbau möglichst konstant und misst den unmittelbaren Wechsel. Der zweite darf dokumentierte Anpassungen enthalten, um beide Varianten für den Einsatz vorzubereiten. Vermischen Sie diese Ergebnisse nicht: Eine verbesserte Variante beantwortet eine andere Frage als der direkte Austausch.
Welche Werte wir erheben würden
| Messgröße | Definition für diesen Versuch |
|---|---|
| Vollständig korrekter Entwurf | Alle Pflichtfelder stimmen; belegte Angaben und offene Punkte sind korrekt zugeordnet |
| Kritischer Fehler | Erfundenes Pflichtfeld, übersehener definierter Widerspruch oder unzulässige Aktion |
| Quellenbeleg | Die angegebene Fundstelle trägt die konkrete Aussage |
| Menschlicher Aufwand | Gemessene Prüf- und Korrekturzeit bis zum akzeptablen Entwurf |
| Laufzeit | Ende-zu-Ende-Dauer; Median und langsame Fälle getrennt berichten |
| Kosten | Aufrufe, Infrastruktur und Prüfaufwand mit offengelegten Annahmen |
| Wechselaufwand | Dokumentierte Arbeitszeit und geänderte Komponenten |
Vorgesehen sind drei Läufe je Modell und Fall. Das ergibt bei zwei Modellen 240 Ausführungen. Es bleiben jedoch nur 40 unterschiedliche Fälle. Die Wiederholungen vergrößern nicht automatisch die inhaltliche Vielfalt des Tests.
Wie die Bewertung nachvollziehbar bleibt
Verdecken Sie für die fachliche Bewertung möglichst, welches Modell ein Ergebnis erzeugt hat. Variieren Sie die Reihenfolge und protokollieren Sie Uneinigkeiten zwischen Prüfern. Berichten Sie Fehler mit Beispielen, statt nur einen Gesamtscore zu veröffentlichen.
Führen Sie zusätzlich einen Schnittstellentest durch: Was passiert bei fehlender Antwort oder ungültigem Ausgabeformat? Dieser Test prüft den Anwendungscode. Er darf nicht als Modellqualität ausgegeben werden.
Der vorgesehene Freigabeprozess bleibt auch dann bestehen, wenn ein Modell in allen Testfällen korrekt antwortet. Ein kleiner Versuch deckt weder sämtliche Produktionsfälle noch die gesamte Sicherheitsbewertung ab.
Was eine Ergebnisveröffentlichung enthalten muss
Eine spätere Auswertung braucht die ausgeführte Konfiguration, Daten und Nutzungsrechte, Bewertungsregeln, absolute Fallzahlen und dokumentierte Einschränkungen. Ergebnisse werden erst nach der Durchführung ergänzt. Bis dahin lässt sich aus diesem Protokoll kein Gewinner und keine Einsparung ableiten.
Die Methode gehört zur Evaluationsarbeit von Welf Labs. Der begleitende Evaluationsleitfaden erklärt, wie Sie die Messgrößen auf Ihren eigenen Prozess übertragen.