Anhang A: Technische Methodik und Datenfluss
Dieser Anhang beschreibt die technischen Daten- und Verarbeitungsschritte der LLM Testsuite detaillierter als der Haupttext der Methodikstudie, bleibt jedoch auf der Ebene der Methodik. Die konkrete interne Implementierung und der Quellcode sind nicht Bestandteil.
Zweck und Abgrenzung
Dieser Anhang beschreibt die technische Methodik so detailliert, dass Datenfluss, Zuständigkeiten, Bewertungsstufen und veröffentlichte Kennzahlen nachvollzogen werden können.
Der Anhang enthält bewusst keinen Quellcode, keine internen Skripte, keine ausführbaren Befehle, keine Zugangsdaten und keine betriebliche Infrastrukturkonfiguration. Diese Elemente gehören zur konkreten Implementierung und werden nicht veröffentlicht.
Stufenmodell der Verarbeitung
| Stufe | Eingabe | Verarbeitung | Ergebnis |
|---|---|---|---|
| Testdefinition | fachliche Test-Idee | ID, Prompt, Kategorien und Bewertung festlegen | versionierter Testfall |
| Ausführungsableitung | Testfall und Modell-Inventar | Prompts und Modellselektion erzeugen | ausführbare Laufkonfiguration |
| Modell-Ausführung | Prompt, Modell und Laufparameter | mehrere Runs starten und protokollieren | rohe Laufdatensätze |
| Normalisierung | heterogene Provider-Antworten | gemeinsames Run-Format bilden | einheitliche Datensätze |
| technische Klassifikation | normalisierte Runs | Timeout, Fehler, Leer-Ausgabe oder Erfolg bestimmen | technischer Status |
| fachliche Bewertung | technisch verwertbare Antwort | deterministische Regel oder LLM-Judge anwenden | Label, Score und Begründung |
| Aggregation | bewertete Runs | Gruppierung und Kennzahlenberechnung | Modell-, Testfall- und Kategorie-Übersichten |
| Qualitätssicherung | Reports, Metadaten und Stichproben | Konsistenz und Freigabe prüfen | freigegebener Build |
| Veröffentlichung | freigegebener Build | LLM Testsuite Dashboard und optionale Exporte erzeugen | öffentliches Ergebnis-Angebot |
Zentrale Daten-Objekte
Die Architektur verwendet logisch getrennte Daten-Objekte. Ihre konkrete Speicherung kann sich technisch ändern, ohne die Methodik zu verändern.
| Daten-Objekt | Inhalt |
|---|---|
| Testfall | ID, Serie, Beschreibung, Kategorien, Prompt, Sollwert und Bewertungsmodus |
| Modellmetadaten | Modellname, Familie, Variante, Provider und Ausführungsweg |
| Run | einzelne Modell-Antwort mit Zeit- und Status-Informationen |
| Bewertungsregel | deterministische Kriterien oder Judge-Rubrik |
| Bewertung | Status, Label, Score, Begründung und Regelversion |
| Aggregation | Kennzahlen für eine definierte Gruppe von Runs |
| Build-Manifest | Versionen, Zeitstempel, Prüfsummen und Freigabestatus |
| Dashboard-Stand | geprüfte und für die Veröffentlichung aufbereitete Ergebnisse |
Aufbau einer Testfalldefinition
Ein Testfall enthält mindestens:
| Feldgruppe | Funktion |
|---|---|
| stabile Identifikation | eindeutige Zuordnung über alle Prozess-Stufen |
| fachliche Beschreibung | erklärt die geprüfte Fähigkeit |
| Prompt | konkrete Eingabe an das Modell |
| Kategorien | ordnen Domäne, Format, Standard und Fähigkeit zu |
| erwartetes Ergebnis | definiert den fachlichen Zielzustand |
| Bewertungsmodus | legt deterministische oder semantische Prüfung fest |
| Versionsmerkmale | Datum, Hash oder Regelversion für spätere Vergleiche |
Ein Prompt-Fingerabdruck stellt fest, ob zwei Runs wirklich auf demselben Prompt-Stand beruhen. Eine Änderung an Leerzeichen, Struktur oder Inhalt kann je nach Untersuchungsziel eine neue Testversion begründen.
Modellmetadaten
Für jedes Modell werden mindestens Modellname und Ausführungsweg gespeichert. Soweit verfügbar werden Familie, Variante, Größenklasse, Kontext-Angabe, Eingabe-Art und Provider ergänzt.
Die Modell-Identifikation muss präzise genug sein, um Varianten nicht zu vermischen. Ein Familienname allein reicht nicht aus, wenn mehrere Größen, Quantisierungen oder Cloud-Versionen getestet werden.
Run-Format
Ein Run ist die kleinste Beobachtungseinheit. Er verbindet genau einen Testfall mit genau einem Modell und genau einer Wiederholung.
Typische Felder sind:
| Bereich | Felder |
|---|---|
| Identität | Testfall-ID, Modellname, Run-Index, Zeitstempel |
| Herkunft | Ausführungsweg, Provider und Laufkonfiguration |
| Technik | Timeout, Rückgabestatus, Abschlussgrund |
| Zeit | Start, Ende und Dauer |
| Inhalt | Antwort-Text, Vorschau und Antwortlänge |
| Prompt | Prompt-Fingerabdruck und Prompt-Länge |
| Bewertung | technischer Status, Bewertungslabel, Score und Begründung |
Die vollständige Antwort kann für interne Prüfung erhalten bleiben. Für das öffentliche LLM Testsuite Dashboard kann abhängig von Freigabe und Datenschutz eine Vorschau, eine gekürzte Antwort oder nur eine Aggregation gezeigt werden.
Technische Statusklassen
| Status | Interpretation |
|---|---|
| erfolgreich | Run liefert eine fachlich bewertbare Antwort |
| Timeout | Zeitlimit wurde überschritten |
| leere Ausgabe | keine nutzbare Antwort vorhanden |
| API- oder Provider-Fehler | Schnittstelle oder Dienst meldet einen Fehler |
| nicht erfolgreicher Abschluss | lokaler oder externer Prozess endet mit Fehlerstatus |
| besonderer Abschlussgrund | provider-spezifischer Abbruch oder unvollständiger Abschluss |
Der technische Status wird vor der fachlichen Bewertung bestimmt. Damit bleibt erkennbar, ob ein Score aus einer inhaltlich falschen Antwort oder aus einem technischen Ausfall resultiert.
Deterministische Bewertungsformen
Die LLM Testsuite verwendet unterschiedliche deterministische Bewertungsformen:
| Form | Geeignete Aufgaben |
|---|---|
| exakter Vergleich | einzelne Zahl, Code oder streng definierte Zeichenfolge |
| normalisierter Vergleich | Antwort mit tolerierbaren Leerzeichen- oder Format-Unterschieden |
| Enthaltensein | Sollwert muss in einer ansonsten zulässigen Antwort vorkommen |
| Musterprüfung | mehrere alternative Schreibweisen sind zulässig |
| Pflichtstrukturprüfung | geforderte Elemente, Attribute oder Bestandteile müssen vorhanden sein |
| Parser- und Validator-Prüfung | XML, JSON oder andere strukturierte Ausgaben müssen formal gültig sein |
| testfallspezifische Logik | Aufgabe benötigt eine eigene, dokumentierte Entscheidungsregel |
Teilbewertungen können sinnvoll sein, wenn ein Ergebnis einige, aber nicht alle Pflichtbestandteile enthält. Die Semantik solcher Teilwerte wird pro Regel dokumentiert.
Semantische Bewertung durch einen LLM-Judge
Der LLM-Judge erhält eine strukturierte Bewertungsaufgabe. Dazu gehören Testfallbeschreibung, erwartete Inhalte, Muss-Kriterien, Ausschlusskriterien und die zu bewertende Modell-Antwort.
Das Judge-Ergebnis enthält mindestens:
| Feld | Funktion |
|---|---|
| Label | fachliche Klasse, beispielsweise korrekt, überwiegend korrekt, teilweise oder falsch |
| Score | numerische Abbildung des Labels |
| Begründung | kurze Erläuterung des Urteils |
| erkannte Treffer | erfüllte Kriterien |
| fehlende Punkte | nicht erfüllte Kriterien |
| Judge-Version | verwendetes Modell und Rubrikstand |
Judge-Urteile werden nicht als objektive Wahrheit behandelt. Sie sind eine versionierte Messung, die durch Stichproben und Kontrolltests geprüft werden muss.
Cache und Neubewertung
Semantische Bewertungen können zwischengespeichert werden. Der Cache muss sich auf den Inhalt und die Bewertungsbedingungen beziehen. Ändern sich Modell-Antwort, erwartetes Ergebnis, Judge-Modell, Prompt-Version oder Rubrik, ist eine Neubewertung erforderlich.
Dieses Prinzip verhindert, dass veraltete Judge-Urteile unbemerkt auf neue Regeln übertragen werden.
Bewertungsfelder
| Feld | Bedeutung |
|---|---|
| technischer Status | Ergebnis der technischen Klassifikation |
| Evaluations-Status | bewertet, ohne Regel, technischer Fehler oder Judge-Fehler |
| Bewertungslabel | maschinenlesbare fachliche Klasse |
| Correctness Score | fachliche Qualität technisch verwertbarer Antworten |
| effektiver Score | produktive Gesamtbewertung unter Einbeziehung technischer Fehler |
| Regelreferenz | verwendeter Bewertungsmodus und Versionsstand |
| Begründung | nachvollziehbare Erklärung des Resultats |
Aggregationskennzahlen
| Kennzahl | Aussage |
|---|---|
| Runs | Anzahl der Einzelbeobachtungen |
| technisch erfolgreich | verwertbare Modell-Antworten |
| Timeouts | Überschreitungen des Zeitlimits |
| leere Antworten | technisch abgeschlossene, aber inhaltslose Runs |
| API- oder Provider-Fehler | externe oder lokale Schnittstellenfehler |
| ohne Regel | technisch erfolgreiche Runs ohne fachliche Bewertung |
| bewertet | Runs mit deterministischer oder semantischer Bewertung |
| durchschnittlicher Correctness Score | Mittelwert der fachlichen Scores |
| durchschnittlicher effektiver Score | Mittelwert einschließlich technischer Fehler |
| vollständig korrekte Runs | Anzahl der Runs mit maximalem Score |
| Korrektrate | Anteil vollständig korrekter Runs an den bewertbaren Beobachtungen |
| Medianlaufzeit | typische Dauer erfolgreicher Runs |
| P95-Laufzeit | obere Laufzeitcharakteristik erfolgreicher Runs |
Gruppierungsebenen von Aggregationen
Aggregationen werden für mehrere Ebenen erzeugt:
- Modell,
- Testfall,
- Modell-Testfall-Kombination,
- Kategorie,
- Zugangsweg,
- Bewertungsverfahren.
Die Auswertung nach Modell-Testfall-Kombination ist die wichtigste Grundlage für Fähigkeitsprofile. Ein globaler Modellwert kann Unterschiede zwischen einzelnen Standards und Aufgaben verdecken.
Dashboard-Build
Ein veröffentlichter Stand des LLM Testsuite Dashboards wird aus geprüften Aggregationen, Run-Metadaten und Beschreibungen erzeugt. Er enthält je nach Freigabestufe:
- Übersichtskennzahlen,
- Modell- und Testfall-Tabellen,
- Kategorie-Ansichten,
- Modell-Testfall-Matrix,
- Laufzeit-Ansichten,
- technische Statuswerte,
- Judge-Ergebnisse,
- Detail-Informationen zu einzelnen Runs,
- maschinenlesbare Exporte.
Die Veröffentlichung ist ein kontrollierter Build und keine direkte Ansicht auf laufende interne Prozesse.
Build-Manifest und Provenienz
Ein Build-Manifest kann folgende Informationen enthalten:
| Information | Zweck |
|---|---|
| Build-Kennung und Datum | eindeutige Referenz für Artikel und Zitate |
| Methodenfassung | Zuordnung zur vorliegenden Studie |
| Testkatalogversion | Zuordnung der Testdefinitionen |
| Anzahl Modelle, Testfälle und Runs | Abdeckung des Datenstands |
| Regel- und Judge-Versionen | Nachvollziehbarkeit der Bewertung |
| Prüfsummen | Kontrolle unveränderter Artefakte |
| Freigabestatus | Unterscheidung zwischen internem Entwurf und Veröffentlichung |
Erweiterung um einen neuen Testfall
Das methodische Vorgehen umfasst:
- Fähigkeit und Hypothese festlegen.
- Testfall mit eindeutiger ID definieren.
- Prompt und Eingabedaten erstellen.
- erwartetes Ergebnis und Bewertungsverfahren bestimmen.
- positive, negative und partielle Beispiel-Antworten prüfen.
- Test in einer kleinen Modellgruppe pilotieren.
- Unklarheiten korrigieren und Version festlegen.
- Test in den regulären Lauf aufnehmen.
- Ergebnisse kontrollieren und im nächsten Build freigeben.
Erweiterung um eine Bewertungsregel
Eine neue Regel wird zunächst fachlich beschrieben. Danach wird geprüft, ob ein deterministischer Vergleich möglich ist oder eine semantische Rubrik benötigt wird. Die Regel wird mit korrekten, teilweise korrekten und falschen Beispiel-Antworten getestet.
Jede Änderung erhält eine neue Version. Bereits vorhandene Modell-Antworten können danach erneut bewertet werden, sofern der Prompt unverändert geblieben ist.
Qualitäts-Tore
Vor einer Veröffentlichung durchläuft ein Datenstand mehrere Qualitäts-Tore:
| Qualitäts-Tor | Prüfung |
|---|---|
| Definition | Testfall und Erwartung sind eindeutig |
| Ausführung | Modell- und Testfall-Zuordnung ist vollständig |
| Technik | Statuswerte und Laufzeiten sind plausibel |
| Bewertung | Regeln und Judge-Ergebnisse sind nachvollziehbar |
| Aggregation | Summen und Quoten stimmen mit Einzel-Runs überein |
| Inhalt | sensible und nicht freigegebene Daten sind ausgeschlossen |
| Darstellung | LLM Testsuite Dashboard, Exporte und Metadaten zeigen denselben Stand |
| Freigabe | Build-Kennung und Methodenfassung sind dokumentiert |
Öffentliche Nachvollziehbarkeit ohne Quellcode
Die Veröffentlichung des Quellcodes ist nicht die einzige Form wissenschaftlicher Transparenz. Für die fachliche Nachvollziehbarkeit sind insbesondere folgende Informationen entscheidend:
- genaue Beschreibung der geprüften Fähigkeit,
- dokumentierter Prompt-Stand,
- Modell- und Variantenbezeichnung,
- Zahl der Wiederholungen,
- technischer Status,
- Bewertungsverfahren und Regelversion,
- Definition der Kennzahlen,
- Datenstand und Build-Kennung,
- klare Benennung der Grenzen.
Diese Angaben werden in dieser Methodikstudie, im LLM Testsuite Dashboard und in Research Notes bereitgestellt. Der interne Code ist nicht Bestandteil des öffentlichen Angebots.
Nicht öffentlich bereitgestellte Implementierungsartefakte
Standardmäßig nicht veröffentlicht werden:
- Quellcode der Ausführungs- und Auswertungskomponenten,
- interne Skripte und Automatisierungsdateien,
- konkrete Kommandozeilen und Arbeitsverzeichnisse,
- Zugangsdaten, Tokens und Provider-Konfigurationen,
- interne Netzwerk- und Hardware-Details,
- nicht freigegebene Rohdaten und Antwortvolltexte,
- interne Judge-Caches und Monitoring-Daten,
- Sicherheits- und Betriebsdokumentation.
Die methodische Beschreibung bleibt davon unberührt. Sie erklärt, welche Funktionen diese Komponenten erfüllen und wie sie in den Gesamtprozess eingebunden sind.