Qwen Validation Debugger synthetische Daten E2E Vertrag

Erstellungsdatum: 15. Juli 2026

Dokumentzweck

Qwen Validation Debugger ist ein Werkzeug, das den gesamten Ablauf mit synthetischen Daten testet, bevor der produktive Retriever und der Verifier fertiggestellt sind.

Ein Testthema wird sowohl mit Godot 3‑Code als auch mit Godot 4‑Code erstellt, und dazu werden passende JSONL‑Dateien sowie nicht passende JSONL‑Dateien generiert. Anschließend wird dieselbe JSONL‑Datei in den jeweiligen Code jeder Version eingesetzt, um zu prüfen, ob das endgültige Urteil korrekt als ja oder nein ausgegeben wird.

Das bisherige Antwort‑Schema und die Arten der Urteile wurden nicht geändert.

Syntaxbereich: common, separate
JSONL‑Tabelle: docs_chunks, api_mapping, label_prototypes
Slots: positive, negative
Endgültige Entscheidung: ja, nein

Ein drittes Bewertungsfeld, Punktzahl und zusätzliches Begründungsfeld wurden nicht erstellt.

Gesamtablauf

TEST_ITEM
  -> common / separate Klassifizierung
  -> Klassifizierungsergebnis speichern
  -> Zielversionscode erzeugen
  -> tatsächliche Godot‑Engine‑Parser‑Prüfung
  -> Qwen Ja/Nein‑Code‑Prüfung
  -> Nur durchgelaufene Codes zu JSONL erzeugen
  -> vorhandenes JSON‑Schema prüfen
  -> aktuellen Code direkt verifizieren
  -> JSONL und Code kreuzvalidieren

separate‑Eintrag erstellt zuerst den Godot 3‑Code. Der Godot 4‑Code nimmt diesen Godot 3‑Code als REFERENCE_GODOT3_CODE und erzeugt entsprechenden Code, der dieselbe Funktion und den gleichen Ablauf beibehält.

Klassifizierung und Trennung der Code‑Generierungseingaben

Die Klassifizierungsantwort behält die bestehenden fünf Felder bei.

{
  "syntax_scope": "common 또는 separate",
  "label": "짧은 한국어 라벨",
  "reason": "분류 근거",
  "godot3_focus": "Godot 3 코드 생성 포인트",
  "godot4_focus": "Godot 4 코드 생성 포인트"
}

reason, godot3_focus, godot4_focus werden zwar in der Anzeige und im Protokoll belassen, aber nicht an den Code‑Generierungs‑Prompt übergeben. Das dient dazu, dass selbst wenn die Klassifizierungsphase eine falsche Versionssyntax erklärt, dieser Satz nicht die faktische Grundlage für die nächste Code‑Generierung bildet.

Testpunkt
common oder separate
Zielversion
separate Godot 4‑Erstellung, zuerst bestandener Godot 3‑Code
Bei einem erneuten Versuch der zuletzt abgelehnte Code und die tatsächliche Prüfungsdiagnose

Synthese‑Code‑Vertrag

Der erzeugte Code muss keine Zeichenkette sein, die wie ein Code‑Snippet aussieht, sondern eine einzelne GDScript‑Datei, die von der Engine geparst werden kann.

Die erste auszuführende Anweisung ist die extends‑Deklaration.
Verwende die Klasse, die die Test‑API tatsächlich besitzt.
Normale Funktionen werden nicht in anderen Funktionen verschachtelt.
Verwende die tatsächliche Aktions‑API des Test‑Elements.
Simuliere das Zielverhalten nicht mit pass, Kommentaren oder lokalen calls.
Mische keine versionsspezifische Syntax in Kommentare oder Code.
Godot‑4‑Code muss die Funktionen, Eingaben, Ziele und Ergebnisse des zuvor bestandenen Godot‑3‑Codes beibehalten.

Für Punkte, deren Syntax je nach Version eindeutig unterschiedlich ist (wie RPC), wird der offizielle Syntax‑Vertrag im Prompt bereitgestellt. Dies ist keine Logik, die Wörter im Ergebnis nachträglich ersetzt. Der erzeugte Quellcode wird nicht willkürlich geändert, sondern unverändert in den Engine‑Parser eingespeist.

Tatsächliche Godot‑Engine‑Überprüfung

Qwen konnte fehlerhafte Syntax nur dadurch passieren lassen, dass es seinen eigenen Code erneut bewertete. In einem realen Test gab es einen Fall, bei dem der Qwen‑Checker „Ja“ antwortete, obwohl Godot‑4‑@rpc in Godot‑3‑Code eingefügt war.

Jetzt wird die reale Engine sofort nach der Codegenerierung ausgeführt.

Godot 3: --no-window --check-only --script  
Godot 4: --headless --check-only --script  
common: Godot 3 und Godot 4 beide prüfen

Die ausführbare Datei kann als GODOT3_BIN oder GODOT4_BIN angegeben werden. Die lokale Standardinstallation wird im Benutzerdatenverzeichnis außerhalb des Repositories abgelegt. Der zu prüfende Code wird nur als temporäre Datei erstellt und nach der Prüfung gelöscht. In den Diagnoseprotokollen werden temporäre Pfade und das Benutzer‑Home‑Verzeichnis entfernt.

Die Codegenerierung und -prüfung werden höchstens dreimal durchgeführt. Bei einem Fehlschlag wird der Seed geändert, um dieselbe Antwort nicht zu wiederholen, und der vorherige Code sowie die tatsächliche Engine‑Diagnose werden in die nächste Generierungsaufforderung eingefügt.

JSONL Schema beibehalten

Die Top‑Level‑Felder entsprechen den bestehenden drei Tabellendefinitionen.

docs_chunks

chunk_id, doc_version, source_url, source_file, source_sha256,
doc_type, symbol, section_path, heading, content, code_blocks,
language_tags, godot_version_tags, api_symbols, token_count, metadata

api_mapping

mapping_id, source_api, target_api, change_type, godot_from,
godot_to, confidence, evidence_chunk_ids, match_terms, notes,
negative_patterns

label_prototypes

prototype_id, label, task_type, input_pattern, expected_finding,
recommended_action, evidence_mapping_ids, evidence_chunk_ids,
severity, validator_rules

validator_rules verwendet ebenfalls nur die bestehenden vier Felder.

{
  "required_when_seen_in_code": [],
  "before_code": "",
  "after_code": "",
  "reject_when_seen_in_code": []
}

Nach Erhalt der Antwort wird das vorhandene JSON‑Schema geprüft, ob erforderliche Felder, Typen, enum‑Werte und optionale Felder vorhanden sind. Wenn das Modell confidence als Zahl oder section_path als Zeichenkette verwendet, wird die Eingabe abgelehnt und bis zu dreimal erneut generiert.

positive und negative Erzeugung

positive JSONL verwendet den direkten Beweis des aktuellen Synthesecode.

docs_chunks: Beschreibt Zweck, Ziel, Eingabefluss und Ergebnis des Codes direkt.
api_mapping: Die source_api von Godot 3 und die target_api von Godot 4 müssen jeweils im tatsächlichen Code vorhanden sein.
label_prototypes: Der before‑Beweis muss im Godot‑3‑Code stehen, der after‑Beweis im Godot‑4‑Code.
Die Felder negative_patterns und reject_when_seen_in_code von positive sind leere Arrays.

Für die Erzeugung von negative JSONL werden weder der aktuelle Code noch das aktuelle Element bereitgestellt. Das nächste Beispiel‑Element nach dem aktuellen Element wird dynamisch als NEGATIVE_TEST_ITEM ausgewählt und ausschließlich daraus wird das JSONL erstellt. Nach der Erzeugung vergleicht der Server das Ergebnis mit dem aktuellen Code; überschneidet sich der source/before‑Beweis, wird die Ausgabe abgelehnt.

Dieser Vorgang ersetzt keine spezifischen API‑Namen oder Sätze eins‑zu‑eins. Es werden lediglich die Auswahl der Beispielreihenfolge und der direkte String‑Vergleich der erzeugten Ergebnisse verwendet.

Prüfungsreihenfolge

Die Validierung erfolgt in der folgenden Reihenfolge.

Wenn das Ergebnis durch die Versions‑Slot‑Struktur feststeht, wird das Modell nicht aufgerufen und mit „Nein“ bewertet.
Wenn vor der Migration kein direkter Beweis im aktuellen Code vorhanden ist, wird ebenfalls mit „Nein“ bewertet.
Nur wenn die beiden vorherigen Bedingungen nicht zutreffen, vergleicht Qwen Bedeutung und Verwendungsweise.

Das deterministische Gate erzeugt keinen neuen Zustand. Der Rückgabewert ist wie bisher „Ja“ oder „Nein“.

JSONL	Prüfungsziel	Erwartete Antwort
gleiche Version `docs_chunks` positive	Erzeugungs‑Basiscode	Ja
andere Version `docs_chunks` positive	Kreuz‑Versions‑Code	Nein
`docs_chunks` negative	Beliebiger Code	Nein
`3 -> 4` migration positive	Godot 3‑Code	Ja
`3 -> 4` migration positive	Godot 4‑Code	Nein
`3 -> 4` migration negative	Beliebiger Code	Nein

API‑Anfrage‑Stabilität

Die Ausgabe von thinking wird deaktiviert.
Klassifikation, Code und JSONL werden mit einer JSON‑Schema‑Antwort angefordert, die nur die vorhandenen Felder enthält.
Die endgültige Bewertung erlaubt nur „Ja“ oder „Nein“ im Grammar‑Format.
Für die Neuerzeugung von Code und JSONL wird der Seed geändert.
HTTP 429, 502, 503, 504, Verbindungsabbrüche und Zeitüberschreitungen werden bis zu dreimal mit begrenztem Retry versucht.

Der API‑Schlüssel wird ausschließlich aus dem aktuellen Eingabewert im Browser‑Speicher in die Anfrage eingefügt. Er wird nicht in Repositorys, Dokumentationen, Logs oder Commits gespeichert.

Testergebnis vom 15. Juli 2026

Von 27 Unit‑Contract‑Tests bestanden.

Bei der eigentlichen Godot‑Engine‑Prüfung wurde Folgendes festgestellt:

Der remote func‑Code von Godot 3 bestand den Godot 3‑Parser.
Das Hinzufügen von @rpc zu Godot 3‑Code führte zu einer Ablehnung mit „Unexpected '@'“.
Der @rpc‑Code von Godot 4 bestand den Godot 4‑Parser.

Die Ergebnisse des RunPod‑Qwen‑Tests waren:

Erste komplette E2E: 5/12 bestanden. Fehlerhafte Godot 3‑Synthesecodes und zu weite Relevanz‑Bewertungen wurden entdeckt.
Nach Anwendung von Engine‑Prüfung und Erzeugungs‑Vertrag: 10/12 bestanden.
Nach dynamischer negativer Item‑Erzeugung und direkter String‑Gate‑Anwendung bei migration negative: 4/4 bestanden.
Die verbleibenden 2 Fälle betrafen ein Modell‑Ignorieren der Slot‑Vertragsbedingung, dass ein migration positive nicht erneut auf Godot 4 angewendet werden darf. Diese Bedingung wurde in ein deterministisches Versions‑Gate verschoben und die Unit‑Tests bestanden.
Der abschließende Gesamtretest wurde gestartet, jedoch stoppte RunPod den Dienst, weil /v1/models und Erzeugungs‑Requests HTTP 502 zurückgaben. Es handelte sich nicht um eine Ablehnung von Code oder JSONL, sondern um keine Antwort des Remote‑Dienstes.

Wenn der Remote‑Dienst wieder reagiert, müssen die 12 E2E‑Slots von vorne neu ausgeführt werden.