evaluation

Evaluation: reproduzierbares Protokoll 3.2

evaluation/ enthält Studiendesign, Prompt-Erzeugung, Schema-Inferenz, Programmausführung, Audit und Runner. Die einzige autoritative maschinenlesbare Konfiguration ist study.yaml. Die wissenschaftliche Interpretation steht in docs/RESEARCH_QUESTIONS.md, die ausführbare STOP-/GO-Folge im docs/RUNBOOK.md.

Studienidentität und Ergebnisgrenze

Feld	Festlegung
Study-ID	gpt5_nano_three_approach_reproducible_v3_2
Protokoll	3.2
Ergebnis-Root	results/study_v3_2/
Vorgänger	v3.1 unter results/study/, nur unveränderliche Incident-Evidenz
v3.1-LLM-Output-Reuse	verboten

v3.2 baut Suites, Locks, Manifeste, Requests und Resultate neu. Weder v3.1-Schemaantworten noch partielle Direct-Antworten, Providerfehler, Run-Manifeste oder Ledger-Einträge werden übernommen. Wiederverwendbar sind nur providerfreie Studiengrundlagen wie eingefrorene Quellen, Taskdefinitionen, Transformationen, Gate-, Prompt-, Tokenizer-, Ausführungs- und Scoring-Code; sie werden unter einem neuen v3.2-Lock erneut geprüft.

Die drei Ansätze

Ansatz	Source-JSON im Prompt	Source-Schema im Prompt	Modelloutput
Zero-shot	ja	nein	fertiges Target-JSON
Mapping-Funktion	ja	nein	JavaScript-Funktion
Schema→Schema	nein	ja	JavaScript-Funktion

Alle Ansätze erhalten denselben öffentlichen Transformationsvertrag und dasselbe Target-Schema. Gold-JSON, interne Rezeptnamen und Auditmetadaten werden nie in Prompts geschrieben.

• Zero-shot transformiert das vollständige konkrete Source-JSON direkt.
• Mapping-Funktion sieht dasselbe Source-JSON und erzeugt mapRawToTarget(inputJson), die anschließend auf diesem Input läuft.
• Schema→Schema sieht statt konkreter Daten ein aus der vollständigen eingefrorenen API-Antwort abgeleitetes Source-Schema. Das einmal je Rezept und Variante erzeugte Programm läuft auf den verborgenen Inputs.

Ein Prompt-Guard prüft diese Informationsgrenzen für jede gespeicherte Message.

Drei Teilstudien

A · Overall-Vergleich

Für jedes der 38 Transformationsrezepte werden drei Größen und drei verschachtelte Samplingpfade verwendet:

n = 2, 4, 8
Seeds = 13, 17, 23
38 × 3 × 3 = 342 technische Ausführungsfälle je Ansatz

Die drei Headline-Arme sind:

zero_shot__direct
mapping_function_js__direct
schema_to_schema_js__examples_2_enums

Die primäre RQ1-Auswertung verwendet exakt 247 vorab Gate-positive und in allen drei Headline-Armen input-machbare Fälle. Diese gepaarte Population umfasst weiterhin 37 Rezeptcluster. Fall-IDs und SHA-256 werden vor dem ersten kanonischen v3.2-Providerrequest eingefroren. Ein providerfreier Preflight reproduziert die bereits in study.yaml festgeschriebenen Hashes noch vor dem getrennten technischen Pilot.

B · Belastungstest der Direct-Verfahren

Zero-shot und Mapping-Funktion verwenden denselben verschachtelten Seed-13-Pfad:

n = 4, 7, 10, 13, …, 64
777 technische Stress-Fälle je Direct-Arm

Kleinere Reservoirs enden an ihrem realen Bestand; Records werden nicht dupliziert. Die technische Failure-Frontier verwendet alle 777 Fälle einschließlich lokaler Inputlimit-Outcomes. Semantische Kurven vergleichen exakt 604 vorab Gate-positive und in beiden Direct-Armen input-machbare Fälle aus 36 Rezeptclustern je Arm.

Overall und Stress werden als Vereinigungsmenge gespeichert. Die überlappenden Fälle werden nicht doppelt ausgeführt; jeder Direct-Arm umfasst 1.081 eindeutige Fälle.

C · Source-Schema-Anreicherung

Vier Varianten laufen auf denselben 342 verborgenen Overall-Inputs:

Variante	examples	enum
Strict	nein	nein
Examples	höchstens zwei eindeutige Werte je geeignetem Attribut	nein
Enums	nein	vollständige erkannte Wertemenge
Examples und Enums	höchstens zwei Werte außerhalb von Enum-Feldern	ja

Pro Transformationsrezept und Variante wird ein Programm generiert und auf neun Kombinationen aus Größe und Seed ausgeführt:

38 Providergenerierungen je Variante
38 × 9 = 342 technische Ausführungen je Variante

RQ3 verwendet exakt 249 Gate-positive Overall-Fälle aus 37 Rezeptclustern je Variante. Alle Schema-Generierungsprompts liegen innerhalb des v3.2-Inputbudgets.

Source-Schema-Inferenz

Im abgeschlossenen v3.2-Lauf wurden Struktur und Annotationen aus der vollständigen eingefrorenen API-Antwort erzeugt:

1. @jsonhero/schema-infer leitet aus der vollständigen Antwort die Struktur ab.
2. Eine dokumentierte Kompatibilitätsregel korrigiert ausschließlich dynamische SEC-Concept-Requiredness.
3. Die vollständige Antwort bestimmt Examples, enumfähige Felder und Enum-Werte.
4. Vollständige Source-Antwort und alle Ausführungsinputs validieren gegen ihre Varianten.

Für den separaten Schema→Schema-Sweep bei n = 30 ist zusätzlich ein taskbezogener Annotationsmodus implementiert:

1. Das Strict-Strukturschema wird weiterhin einmal aus der vollständigen eingefrorenen Antwort abgeleitet.
2. Examples, Enum-Felder und Enum-Werte werden für jeden Evaluationsfall ausschließlich aus dessen aktuellem input_data abgeleitet.
3. Die Example-Anzahl ist konfigurierbar; ausgewählte Examples sind typbewusst distinct.
4. Die Enum-Schwellen hängen dokumentiert von der Taskgröße n ab.
5. Werte werden zwischen Tasks weder vereinigt noch wiederverwendet.
6. Taskabhängige Varianten können mit einem konfigurierbaren max_workers parallel ausgeführt werden.
7. Nur das Strict-Schema kann weiterhin zwischen den neun n/Seed-Fällen eines Rezepts wiederverwendet werden.

Die ausführbare, von v3.2 getrennte Konfiguration des n=30-Sweeps liegt in evaluation/study_schema_n30.yaml.

Modell- und Requestfestlegung

Einstellung	v3.2-Festlegung
Modell	gpt-5-nano-2025-08-07
Endpoint	https://api.openai.com/v1/chat/completions
Seed	42
temperature	null, wird nicht gesendet
max_tokens	null, wird nicht gesendet
max_completion_tokens	86000
maximales Inputlimit	272000 Tokens
Input-Sicherheitspuffer	4096 Tokens
Gesamtkontext	400000 Tokens
Reasoning Effort	medium
Verbosity	medium
Service Tier	default
Timeout	900 Sekunden
Provider-Versuche	max_attempts=1
Parallelität	ein Worker

Vor einer Providerreservation müssen beide Regeln erfüllt sein:

estimated_input_tokens + 4.096 <= 272.000
estimated_input_tokens + 86.000 + 4.096 <= 400.000

Die Prüfung verwendet den eingefrorenen Tokenizer o200k_base. Das 272.000er-Limit ist eine eigenständige Providerrestriktion und darf nicht nur über die 400.000er-Gesamtsumme angenähert werden.

Technische und semantische Population strikt trennen

Die Studie löscht keine zu langen Fälle. Sie trennt zwei Estimanden:

1. Technische Population: alle 342 Overall-Fälle je Ansatz und alle 777 Stress-Fälle je Direct-Arm. Sie beantwortet Coverage, Operabilität und Failure-Frontier.
2. Semantische Population: vor dem ersten Request Gate-positive und für sämtliche verglichenen Arme input-machbare Fälle. Sie beantwortet konditionale Qualitätsfragen.

Exakt 300 Direct-Prompts sind nach der Inputregel nicht request-fähig, 150 je Direct-Arm. Der Runner muss sie vor einer Providerreservation als pre_request_input_limit speichern:

• vollständige Fall-, Prompt-, Token- und Fingerprint-Provenienz;
• provider_request_sent = false;
• keine Provider-ID und keine Usage;
• semantische Metriken null, niemals künstliche Nullpunkte.

So bleiben gerade schwierige Fälle technisch sichtbar, ohne eine nicht vorhandene Modellantwort semantisch zu bewerten.

Feste Fall- und Requestzahlen

Bereich	Technische Ausführungen	Providergenerierungen
zwei Direct-Arme	2.162	1.862
vier Schema-Arme	1.368	152
Gesamt	3.530	2.014

Zusätzlich entstehen innerhalb der 2.162 Direct-Ausführungen 300 lokale Inputlimit-Outcomes. Die 1.368 Schema-Ausführungen beruhen auf 152 Providergenerierungen und 1.216 dokumentierten Programm-Reuses.

Der initiale GO darf exakt 2.014 Providerattempts autorisieren. Jeder Infrastruktur-Retry braucht einen neuen providerfreien Preflight, eine explizite zusätzliche Versuchsanzahl und ein neues Kosten-GO.

Semantische Finalisierung

Die primäre Analyse darf nur finalisiert werden, wenn:

• alle 247 RQ1-Fälle in jedem Headline-Arm vollständig beantwortet sind;
• alle 604 RQ2-Fälle in beiden Direct-Armen vollständig beantwortet sind;
• alle 249 RQ3-Fälle in allen vier Schema-Armen vollständig beantwortet sind.

„Vollständig beantwortet“ bedeutet eine gespeicherte HTTP-2xx-Antwort mit unverändertem Providerbody und Assistant-Output; Request-ID und Usage werden gespeichert, soweit der Provider sie liefert. Ein nachgelagerter Parse-, Extraktions-, Compile-, Timeout- oder Runtime-Fehler bleibt ein Modellergebnis im festen Nenner.

Technische Infrastrukturfehler werden quarantänisiert und nicht als semantische Nullpunkte gewertet. Der Nenner wird nicht nachträglich verkleinert. Ein terminaler unerwarteter Provider-Reject innerhalb der eingefrorenen Population blockiert die primäre Finalisierung.

Primäre Auswertung

Primär ist Leaf-F1. Für jeden der drei RQ1-Kontraste wird:

1. je gepaartem Fall Leaf-F1(Treatment) − Leaf-F1(Baseline) berechnet;
2. innerhalb jedes Transformationsrezepts gemittelt;
3. über Rezeptmittel mit gleichem Gewicht aggregiert;
4. ein 95-%-Cluster-Bootstrap mit 10.000 Ziehungen ganzer Rezepte erzeugt.

Die Intervalle beschreiben Rezeptzusammensetzungsunsicherheit, nicht Generation-zu-Generation-Stochastik. Pro eindeutigem Prompt gibt es genau eine Modellgenerierung.

Die zentralen Summary- und Effekttabellen nennen technischen Nenner, semantischen Nenner, vollständige Providerantworten, lokale Nicht-Requests und den tatsächlich ausgewerteten Zähler. Fallgenaue Flags stehen in all_results.csv; das gebundene Populationsmanifest enthält die sortierten Fall-IDs und ihre SHA-256. Plotüberschriften und Begleittext ordnen jede Darstellung eindeutig RQ1, RQ2 oder RQ3 zu.

v3.1-Incident und Anti-Bias-Begründung

Die Änderung wurde durch den unveränderlichen Incident results/study/audit/protocol_history/20260727_direct_input_limit_v31/INCIDENT.json ausgelöst:

Bindung	SHA-256
Incident-Datei	3eaed61624e13377e10cd1582004062fee4429a1337628996cb74e8c5a9243e0
selbstgebundener Incident-Inhalt	cb1ca64ec157dfcdcde77d34043d6333130d8a9cac4a4933c75333e9178e5f04
v3.1-Studien-Lock	2d07e8c9a947a20b2cea0b2334f06dfdedad60a7a0166116e437f9962ac98aa2
v3.1-GO	3e2513e915519385ab6e576ce4f4f81429cc204c930442fba14b8fa870c9159f
v3.1-Promptbudget	e57718b6a180d25c270655357833e287d29e71928b65e737944860db33c1cd8f

Die Fallmengen und Machbarkeitsregel werden vor neuen Modellantworten eingefroren. Es gibt keine armabhängigen Nenner, keine post-hoc Exklusion schlechter Outputs und keine selektive Übernahme bereits sichtbarer v3.1-Antworten. Technische Coverage und konditionale Semantik werden getrennt berichtet.

Ausführung

Offline-Vorbereitung, GO-Erzeugung, gestufte Live-Befehle, Retry-Regeln und Final-Audit stehen vollständig im Runbook.

Bis der dort definierte v3.2-Preflight alle festen Zahlen und Hashbindungen bestätigt und ein neues results/study_v3_2/audit/CANONICAL_GO.json vorliegt, darf kein Providerrequest gesendet werden.