Qwen Validation Debugger Strategie und Implementierungsprotokoll

Erstellungsdatum: 30. Juni 2026

Zweck

Dieses Dokument beschreibt den Grund für die Erstellung von tools/qwen-validation-debugger und zeichnet den tatsächlichen Ablauf auf.

Am 28. Juni wurden manuell Qwen‑Code‑Chunks und JSONL für Godot erstellt und Prompt + Code‑Chunk + JSONL direkt zusammengefügt, um zu prüfen, wie das Ergebnis Ja/Nein aussieht. Diese Methode war gut, um eine Richtung zu finden, aber je mehr Punkte hinzukamen, desto größer wurden die Kosten für das manuelle Kopieren, das Erinnern an die Erzeugungsregeln und den Vergleich der Ergebnisse.

Deshalb wurde am 30. Juni dieser Prozess zu einem separaten Web‑Tool ausgebaut. Das Ziel dieses Tools ist es, nicht das endgültige Modelltraining zu unterstützen, sondern visuell nachzuvollziehen, welche Beziehung zwischen dem von Qwen erzeugten Testcode und dem JSONL besteht, und fehlerhafte Ja/Nein‑Entscheidungen schnell zu erkennen.

Aktueller Bildschirm

Das aktuelle Werkzeug wird unter http://localhost:8520/ ausgeführt.

Der Bildschirm ist grob in drei Bereiche unterteilt.

• Links: 50‑teilige Godot‑Test‑Checkliste
• Mitte/Rechts oben: KI‑Label des ausgewählten Elements und das Ergebnis der Godot‑Code‑Generierung
• Unten: docs_chunks, api_mapping, label_prototypes JSONL‑Erstellungs‑/Validierungs‑Slot

Warum ein separates Werkzeug nötig war

Ursprünglich wurde das Folgende direkt an den Qwen‑Chatbot angefragt.

Erstelle einen Godot‑Code‑Chunk,  
erstelle korrekte JSONL‑ und falsche JSONL‑Dateien im Format `docs_chunks/api_mapping/label_prototypes`.  
Und ich werde überprüfen, ob beim Anhängen von `SOURCE_CODE` und JSONL die Ja/Nein‑Antworten korrekt ausgegeben werden.

Aber beim manuellen Testen stellte sich heraus, dass es mehr Achsen zu überprüfen gab, als erwartet.

Wenn es sich um gemeinsame Syntax handelt, gibt es 6 Slots.

Gemeinsamer Code
  docs_chunks       Beschreibung Grundlage / andere Code-Beschreibung
  api_mapping       Gemeinsam/Unnötig / unrelevant Umwandlung
  label_prototypes  Gemeinsam/Unnötig / unrelevant Umwandlung

Version‑Trennsyntax hat 12 Slots.

Godot 3 Code
  docs_chunks       Beschreibung Begründung / andere Code-Beschreibung
  api_mapping       Umwandlung erforderlich / irrelevant Umwandlung
  label_prototypes  Umwandlung erforderlich / irrelevant Umwandlung

Godot 4 Code
  docs_chunks       Beschreibung Begründung / andere Code-Beschreibung
  api_mapping       bereits angewendet / irrelevant Umwandlung
  label_prototypes  bereits angewendet / irrelevant Umwandlung

Wenn man das von Hand immer wieder erstellt, kostet das Kopieren/Einfügen und das Aufbereiten der Ergebnisse mehr Zeit als der Test selbst. Deshalb habe ich die Elemente, den Code, JSONL und die Validierungsergebnisse in einer GUI auf einem Bildschirm zusammengefasst.

Gesamtablauf

flowchart TD
  A["50 Testpunkte"] --> B["Auswahl des Elements"]
  B --> C["Qwen-Labeling"]
  C --> D{"Ist es gemeinsame Syntax?"}
  D -->|"common"| E["Gemeinsamen Code erzeugen"]
  D -->|"separate"| F["Godot‑3‑Code erzeugen"]
  D -->|"separate"| G["Godot‑4‑Code erzeugen"]
  E --> H["6 JSONL‑Slots"]
  F --> I["6 JSONL‑Dateien für Godot 3"]
  G --> J["6 JSONL‑Dateien für Godot 4"]
  I --> K["Godot‑3‑Code prüfen"]
  I --> L["Godot‑4‑Code prüfen"]
  J --> K
  J --> L
  H --> M["Gemeinsamen Code prüfen"]

Das Werkzeug ruft Qwen in drei Rollen auf.

Kennzeichnungs‑Phase

Wenn ein Eintrag angeklickt wird, entscheidet Qwen zuerst, ob es sich um allgemeine Syntax oder um eine Versions‑Trennung handelt.

Zum Beispiel wird _process(delta) sowohl in Godot 3 als auch in Godot 4 als Frame‑Update‑Funktion verwendet und kann daher als allgemeine Syntax betrachtet werden.

Im Gegensatz dazu wird Spieler‑Bewegungs‑Geschwindigkeit und‑Beschleunigung‑Anwenden je nach Version unterschiedlich umgesetzt (physikalischer Body und Aufruf von move_and_slide()), sodass separate Godot‑3‑ und Godot‑4‑Codes erstellt werden.

JSONL‑Slot‑Design

Anfangs wurden die Slots nur in richtige JSONL und falsche JSONL unterteilt. Diese Unterscheidung war jedoch zu grob.

docs_chunks sind Erklärungs‑Belege. Wenn die Erklärung direkt zum Code passt, ist die Antwort Ja, bei Erklärungen zu anderem Code Nein.

api_mapping und label_prototypes sind jedoch keine reinen Erklärungen, sondern Transformations‑Belege für die Migration von Godot 3 zu Godot 4. Wird also in bereits für Godot 4 geschriebenem Code ein api_mapping‑ oder label_prototypes‑Eintrag mit Ja versehen, liest sich das wie „Du bist bereits in Godot 4 und sollst trotzdem migrieren“.

Deshalb wurden die Slot‑Bezeichnungen wie folgt geändert:

Dank dieser Kriterien ist das Ja/Nein nicht mehr nur eine einfache Relevanz‑Bewertung, sondern entspricht der jeweiligen Tabellennutzung.

Trennung von Erzeugungs‑Code und zu prüfendem Code

Der wichtigste Unterschied an dieser Stelle ist heute.

In der ersten Implementierung wurde ein Slot nur gegen seinen eigenen Code validiert.

Godot 3 Code mit erstellt JSONL  
  -> Nur für Godot 3 Code verifiziert  

Godot 4 Code mit erstellt JSONL  
  -> Nur für Godot 4 Code verifiziert

Aber die tatsächlich benötigte Validierung ist umfangreicher als dies.

Wenn ein mit Godot 3‑Code erstelltes JSONL an Godot 4‑Code angehängt wird, muss ebenfalls Nein ausgegeben werden. Umgekehrt muss man auch prüfen, welches Ergebnis entsteht, wenn ein mit Godot 4‑Code erstelltes JSONL an Godot 3‑Code angehängt wird. Nur so kann man das Problem finden, dass sich source/target‑Zeichenketten vermischen und fälschlicherweise Ja ausgegeben wird.

Also haben wir den Button von einem auf zwei aufgeteilt.

Jetzt kann jeder Slot des Versions‑Trennungs‑Elements alle folgenden Prüfungen durchführen.

JSONL, das mit Godot 3‑Code erzeugt wurde
-> Godot 3 Code‑Validierung
-> Godot 4 Codeüberprüfung

JSONL, das mit Godot 4‑Code erzeugt wurde
-> Godot 3 Code‑Verifizierung
-> Godot 4 Code-Validierung

Im Inneren des Werkzeugs wird dies wie folgt aufgeteilt.

Erwartete Antwort‑Berechnungsgrundlage

Das Validierungsergebnis wird weiterhin von Qwen als Ja oder Nein erhalten. Allerdings wird die erwartete Antwort nun nicht mehr nur anhand eines einzelnen Slots berechnet, sondern berücksichtigt Tabelle + JSONL‑Erstellungs‑Basis‑Version + Ziel‑Version + Slot‑Charakteristik.

Diese Grundlage dient eher als Debug‑Kriterium, um zu sehen, wo Qwens Begründungs‑Matching in diesem Schritt schwankt, als als endgültiges Bewertungs‑Kriterium.

Änderungen im Validierungs‑Prompt

Im Validierungs‑Prompt werden nun zwei Versionsinformationen eingefügt.

JSONL_GENERATED_FROM_CODE_VERSION:
godot3

VERIFY_TARGET_CODE_VERSION:
godot4

Der Grund dafür, dies einzufügen, ist, dass Qwen nicht einfach mit „Ja“ antwortet, nur weil das target_api in der JSONL mit dem aktuellen Code übereinstimmt.

In api_mapping und label_prototypes ist das folgende Kriterium wichtig:

• source_api, source_pattern, input_pattern, before_code und required_when_seen_in_code müssen direkt im aktuellen Code vorhanden sein, um mit „Ja“ zu antworten.
• Wenn nur die Form von target_api, after_code und dem empfohlenen Ziel mit dem aktuellen Code übereinstimmt, ist dies bereits angewendet, also „Nein“.
• Bedeutet dies, dass keine Umwandlung nötig ist, wie bei signature_stable, no_change, common, so ist die Antwort „Nein“.
• Auch wenn ein Migrations‑JSONL an Godot‑4‑Code oder gemeinsamen Syntax‑Code angehängt wird, ist die Antwort „Nein“, wenn keine zusätzliche Umwandlung erforderlich ist.

Aufzeichnung von 50 Testeinträgen

1/50 _ready()-Funktion Initialisierung und Viewport‑Größeneinstellung

Am 3. Juli wurde der erste von 50 Testeinträgen zuerst überprüft. Dieser Eintrag wurde als gemeinsamer Code gekennzeichnet, und der Referenzcode sah wie folgt aus:

func _ready():
    var vp_size = get_viewport().get_visible_rect().size
    position = Vector2(vp_size.x / 2, vp_size.y / 2)

Zunächst wurde der Fehlerschlitz docs_chunks als „unrelevante Beschreibung JSONL“ bezeichnet. Bei tatsächlichen Tests stellte sich jedoch heraus, dass dieser Name ungenau war. Dieser Schlitz dient nicht dazu, absichtlich fehlerhafte oder falsche JSONL zu erzeugen, sondern er soll prüfen, ob der Retriever zusätzliche offizielle Dokumentationsbeschreibungen als Suchkandidaten einbringen kann und ob Qwen diese im abschließenden Validierungsschritt herausfiltert.

Daher wurde die Bedeutung dieses Schlitzes zu „andere Code‑Beschreibung JSONL“ umbenannt.

Im Test war das problematische JSONL zwar mit Viewport.get_visible_rect und _ready() versehen, der eigentliche Inhalt bezog sich jedoch auf safe‑area, UI‑Scaling, $Label, $Button.rect_position und andere Code‑Verhaltensweisen. Der SOURCE_CODE liest die Viewport‑Größe aus und verschiebt die position des aktuellen Knotens in die Bildschirmmitte; obwohl einige APIs sich überschneiden, ist das keine direkte Evidenz.

Die erwartete Antwort war „Nein“, doch Qwen gab „Ja“ zurück. Der Grund lag darin, dass die Validierungs‑Prompt‑Formulierung „exakte Übereinstimmung von Zeichenkette/API‑Aufruf“ zu weit ausgelegt wurde und auch Beschreibungen aus anderen Dokumenten, die dieselben APIs enthalten, als direkte Evidenz akzeptierte.

Änderungsprotokoll:

• Der Fehlerschlitz‑Name docs_chunks wurde von „unrelevante Beschreibung JSONL“ zu „andere Code‑Beschreibung JSONL“ geändert.
• Im JSONL‑Erzeugungs‑Prompt wurde dieser Schlitz definiert als „wie ein Suchkandidat können einige APIs/Themen überschneiden, aber tatsächlich wird ein offizielles Dokument‑JSONL verwendet, das ein anderes Code‑Verhalten beschreibt“.
• Der Validierungs‑Prompt wurde dahingehend verstärkt, dass das „Ja“‑Kriterium nicht nur eine einfache API‑Zeichenketten‑Übereinstimmung ist, sondern dass Zweck, Zielobjekt und Endergebnis des Codes exakt passen müssen.
• Auch wenn dieselbe API oder dieselbe Methode auftaucht, gilt: Beschreibt das JSONL ein anderes Ziel, ein anderes Objekt oder ein anderes Ergebnis, handelt es sich lediglich um einen Suchkandidaten und „Nein“ wird angegeben.
• Die Beschriftungen und Vorschautexte der Front‑UI‑Schlitze wurden nach denselben Kriterien angepasst.
• Ein Test in core.test.js wurde hinzugefügt, um sicherzustellen, dass diese Kriterien im Prompt erhalten bleiben.

2/50 _process(delta) Frame‑weise Update‑Schleife

Am 3. Juli wurde Punkt 2 überprüft. Dieser Punkt wurde von Qwen als gemeinsamer Code gekennzeichnet.

Kennzeichnungs‑Zusammenfassung:

syntax_scope: common
label: _process(delta) Rahmenweise Aktualisierung
reason: In Godot 3 und 4 ist die Signatur und Aufrufweise der Funktion _process(delta) identisch, und es gibt keine syntaktischen Unterschiede beim Schreiben von Logik pro Frame.

Das Prüfungsergebnis stimmt bei allen 6 Slots mit der erwarteten Antwort überein.

Dieser Eintrag dokumentiert einen Fall, in dem im gemeinsamen Syntax docs_chunks als Begründung mit Ja und api_mapping sowie label_prototypes als gemeinsame/unnötige oder irrelevante Umwandlung mit Nein korrekt funktioniert haben.

3/50 Spielerbewegungs-Eingabe verarbeiten

Punkt 3 wurde von Qwen mit Versions‑Trennungs‑Code gekennzeichnet.

Kennzeichnungs‑Zusammenfassung:

syntax_scope: separate
label: Spielerbewegungs‑Eingabeverarbeitung
reason: Die Eingabeüberprüfung ist zwar ähnlich, aber aufgrund der in Godot 4 eingeführten Input.get_vector() und der geänderten Signatur von CharacterBody2D's move_and_slide() muss die Code‑Struktur getrennt werden.
godot3_focus: KinematicBody2D‑Vererbung, manuelle Berechnung von velocity.x/y und Aufruf von move_and_slide(up_direction)
godot4_focus: CharacterBody2D‑Vererbung, Vereinfachung der diagonalen Bewegung mit Input.get_vector() und Weglassen des Parameters bei move_and_slide()

Validierungsergebnis:

Nicht übereinstimmend:

Beobachtungen zum Prompt:

Im hybriden Suchverfahren ist es üblich, dass ein Code‑Chunk zusammen mit einem ähnlichen JSONL‑Vorschlag erscheint. Daher muss der Validierungsprompt beurteilen, ob der Suchvorschlag tatsächlich auf den aktuellen SOURCE_CODE angewendet werden soll. Die drei Fehlfälle zeigen, dass die Frage nicht eindeutig genug war, sodass Qwen api_mapping und label_prototypes als breitere Relevanz‑Übereinstimmung statt als Migrationsbedarf interpretierte.

Insbesondere bei Fall 3 traten folgende Probleme auf:

• Wenn ein Funktionsname wie move_and_slide, der sowohl in Godot 3 als auch in Godot 4 vorkommen kann, allein steht, neigt Qwen dazu, „Ja“ zu wählen.
• Wird ein Godot‑3‑JSONL an Godot‑4‑Code angehängt, darf label_prototypes · Transformations‑JSONL nicht „Ja“ ergeben, wenn der Code bereits nach der Änderung vorliegt.
• Auch bei einem für Godot 4 erstellten irrelevanten JSONL, das an Godot‑3‑Code angehängt wird, darf „Ja“ nicht ausgegeben werden, wenn die Transformation nicht wirklich anwendbar ist.
• Der Kern liegt nicht im Erstellungsprozess des JSONL, sondern in der Prüffrage. Der Prompt muss entscheiden, ob der aktuelle Code vor oder nach der Änderung steht oder ob es sich um eine völlig andere Transformation handelt.

Daher wurde der Prompt wie folgt angepasst:

• Die Prüffrage lautet nicht mehr „Ist das JSONL mit dem Code relevant?“, sondern „Soll anhand dieses JSONL die aktuelle SOURCE_CODE migriert werden?“.
• Wenn die aktuelle SOURCE_CODE bereits die Ziel‑Form von Godot 4 hat, wird selbst bei scheinbarer Relevanz des JSONL „Nein“ angegeben („bereits angewendet“).
• label_prototypes · Transformations‑JSONL wird nur mit „Ja“ bewertet, wenn die aktuelle SOURCE_CODE tatsächlich das alte Nutzungsmuster, die Argumentstruktur und das Aufrufmuster enthält.
• Irrelevante Transformations‑JSONL erhalten „Nein“, selbst wenn das Prüfobjekt Godot 3‑Code ist, solange die Transformation nicht auf den aktuellen Code anwendbar ist.
• Jeder Feldwert im JSONL dient als Kontext für die Entscheidung. In der Validierungsphase wird geprüft, ob die SOURCE_CODE im Vor‑ oder Nach‑Änderungszustand ist.
• Da source_api und target_api denselben Namen teilen können oder match_terms sowohl Quell‑ als auch Zielbegriffe enthalten können, reicht ein einzelner Funktionsname oder ein breiter match_terms‑Treffer nicht aus, um „Ja“ zu rechtfertigen.
• Selbst wenn der Funktionsname übereinstimmt, muss das gesamte Muster – Aufrufparameter, Rückgabeverarbeitung, Vererbungs‑Node, umgebende Code‑Struktur – das im JSONL beschriebene Quell‑Vorher‑Muster im SOURCE_CODE widerspiegeln, damit „Ja“ gilt.
• Wenn JSONL_GENERATED_FROM_CODE_VERSION und VERIFY_TARGET_CODE_VERSION unterschiedlich sind, muss zuerst bestimmt werden, ob die aktuelle SOURCE_CODE die Vor‑ oder Nach‑Version des JSONL darstellt.

4/50 Anwendung von Spieler‑Geschwindigkeit und Beschleunigung

Auch bei Punkt 4 hat Qwen die Versionstrennung als Label verwendet.

Label‑Zusammenfassung:

syntax_scope: separate
label: Spielerbewegungsgeschwindigkeit und Beschleunigung anwenden
reason: In Godot 4 wurde der Physik-Node von KinematicBody zu CharacterBody geändert, und die Signatur von move_and_slide() wurde auf eine Argumentübergabe umgestellt, wodurch sich die Code-Struktur ändert.
godot3_focus: velocity-Eigenschaft zuweisen, dann move_and_slide() aufrufen, KinematicBody2D/3D verwenden
godot4_focus: Argumente mit move_and_slide(velocity) übergeben, CharacterBody2D/3D verwenden, bei Anwendung von Beschleunigung lerp() oder move_toward() nutzen

Validierungsergebnis:

Abweichungen:

| godot3:api_mapping:positive | Godot 4 Code | Nein | Ja | Auch wenn das auf Basis von Godot 3 move_and_slide konvertierte JSONL an den Godot 4 Code angehängt wird, erschien ebenfalls Ja. Wenn es bereits in Godot 4-Form vorliegt, ist es trotz möglicher Relevanz der Konvertierungsbeschreibung kein Ziel für die Migration des aktuellen Codes. |

Prompt‑Beobachtung:

Die Inkonsistenz bei 4 war weniger als bei 3, aber die Ursache ist dieselbe. Wenn im api_mapping Quell‑ und Zielfunktionsnamen gleich oder ähnlich sind, kann Qwen mit der breiten Relevanzbewertung „Dieses JSONL beschreibt die entsprechende Funktionsänderung“ mit „ja“ antworten. Was dieses Werkzeug jedoch benötigt, ist keine Relevanzbewertung, sondern die Frage, ob eine Migration im aktuellen Code erforderlich ist.

Daher wurde basierend auf den Beobachtungen bis 4 der Verifizierungs‑Prompt nicht nur auf die reine Übereinstimmung von API‑Namen beschränkt, sondern um Folgendes erweitert.

• Ob der aktuelle Code tatsächlich das vor der Änderung von JSONL vorhandene Muster enthält
• Ob bei demselben Funktionsnamen die Aufrufparameter und die Rückgabeverarbeitung mit dem Code vor der Änderung übereinstimmen
• Ob der zu prüfende Code bereits in der nach‑Änderungs‑Form vorliegt, sodass keine Migration erforderlich ist (Nein)
• Ob das neutrale Transformations‑JSONL nicht wegen bloßer Relevanz fälschlich mit Ja beantwortet wird

5/50 Begrenzung der maximalen Geschwindigkeit des Spielers

Punkt 5 wurde von Qwen als Versions‑Trennungs‑Code gekennzeichnet.

Kennzeichnungs‑Zusammenfassung:

syntax_scope: separate
label: Spieler maximale Geschwindigkeitsbegrenzung
reason: Auf Grund der Klassennamensänderung zwischen KinematicBody2D in Godot 3 und CharacterBody2D in Godot 4 sowie der Unterschiede in der Signatur der move_and_slide()-Methode und der Art der Velocity‑Übergabe ist separater Code erforderlich.
godot3_focus: Vererbung von KinematicBody2D, Zuweisung der Geschwindigkeit zu self.velocity, anschließend Aufruf von move_and_slide(), Geschwindigkeitsbegrenzung mit limit_length()
godot4_focus: Vererbung von CharacterBody2D, Zuweisung der Geschwindigkeit zur velocity‑Variable, explizite Übergabe mittels move_and_slide(velocity), Anwendung von limit_length()

Erzeugter Codefluss:

Validierungsergebnis:

Nicht übereinstimmend:

Prompt‑Beobachtung:

Nummer 5 entspricht einer Situation, die bei der hybriden Suche tatsächlich auftreten kann. Später, wenn aus der Datenbank gesucht wird, erscheint nicht nur völlig falsches JSONL, sondern es können ähnliche Kandidaten derselben API oder derselben Bewegungs‑/Geschwindigkeits‑Verarbeitung mitgeliefert werden. In diesem Fall muss die Validierungs‑Prompt nicht prüfen, ob es ein „ähnlicher Suchkandidat“ ist, sondern ob dieses JSONL das aktuelle SOURCE_CODE‑Verhalten direkt beschreibt.

In diesem fünften Beispiel funktionierten api_mapping und label_prototypes in beiden Prüfungen (Godot 3/4) wie erwartet. Besonders bemerkenswert ist, dass bei Godot 4 bereits angewendete Formen oder JSONL‑Einträge mit no_change, pattern_validation zu „Nein“ führten – ein Hinweis darauf, dass das frühere Migrations‑Bewertungsproblem (Beispiele 3/4) teilweise gemindert wurde.

Im Gegensatz dazu muss docs_chunks noch genauer untersucht werden. Da es bei docs_chunks nicht um die Anwendung einer Migration, sondern um die Übereinstimmung von Erklärungshintergrund geht, führt bereits ein gemeinsamer API‑Name oder ein Hinweis auf dieselbe Version zu „Ja“ und erzeugt Rauschen im Validierungs‑Schritt der hybriden Suche. Daher sollte die nachfolgende Validierungs‑Prompt bei docs_chunks stärker prüfen, ob Zweck, Zielobjekt und Ergebniszustand des SOURCE_CODE mit der Beschreibung im JSONL tatsächlich übereinstimmen.

6~10/50 zusätzliche Verifizierungsaufzeichnungen

Von 6 bis 10 wird zunächst das Ergebnis festgehalten und anschließend die Verifizierungs‑Prompt korrigiert. In diesem Schritt wird ohne Prompt‑Anpassung nur notiert, in welchen Slots das aktuelle Werkzeug korrekt bzw. inkorrekt ist.

Gesamtübersicht:

Zusammenfassung nach Eintrag:

Die Nummern 6, 9 und 10 entsprachen allen Erwartungen. Bei 6 wurden die Abläufe von Godot 3 (PackedScene.instance(), Input.is_mouse_button_pressed(1), get_viewport().get_mouse_position()) und Godot 4 (instantiate(), InputEventMouseButton, get_global_mouse_position()) getrennt, und die richtigen sowie falschen Kandidaten wurden jeweils korrekt zugeordnet. Bei 9 wurden alle Version‑aufgeteilten Kandidaten für Bewegung und Rotation wie erwartet bewertet. Nummer 10 wurde als gemeinsame Syntax klassifiziert; die Behandlung von außerhalb des Viewports mittels get_viewport_rect().size, global_position, hide() wurde in der Dokumentation mit Ja bestätigt, während Migrationskandidaten vom Typ api_mapping/label_prototypes mit Nein bewertet wurden.

Nicht übereinstimmend:

Beobachtungen:

Der Durchlauf 6‑10 zeigt insgesamt ein Verbesserungssignal. Von 102 Verifizierungen entsprachen 97 den Erwartungen, und die Nummern 6/9/10 bestanden alle. Besonders bei der gemeinsamen Syntax (Nummer 10) fielen api_mapping und label_prototypes komplett mit Nein aus – ein Hinweis darauf, dass die Regel „bei gemeinsamem Code keine Migrationsbegründung anhängen“ teilweise funktioniert.

Die verbleibenden Diskrepanzen lassen sich in zwei Kategorien einteilen. Erstens Fälle wie Nummer 7, bei denen Migrationsbegründungen für Godot 3 auch bei Godot 4‑Code mit Ja markiert werden. Hier muss klarer unterschieden werden, ob der aktuelle Code bereits migriert ist oder noch migriert werden muss. Zweitens Fälle wie Nummer 8, bei denen docs_chunks‑Kandidaten wegen ähnlicher Themen oder APIs fälschlicherweise mit Ja erscheinen. Hier muss geprüft werden, ob die Dokumentation tatsächlich das konkrete Verhalten des SOURCE_CODE erklärt oder nur ein ähnlicher Suchtreffer ist.

Wichtig ist, dass dieses Problem nicht durch das Blockieren bestimmter Zeichenketten oder Kandidaten gelöst wird. Wenn später JSONL‑Daten in die Datenbank geladen und per Hybrid‑Search abgerufen werden, ist es normal, dass ähnliche, aber unterschiedliche Kandidaten erscheinen. Daher sollte die nachfolgende Anpassung nicht das Filtern von Kandidaten, sondern die Verbesserung des Verifizierungs‑Prompts fokussieren, sodass dieser die Beziehung zwischen aktuellem SOURCE_CODE und den Suchergebnissen genauer beurteilt.

Erweiterungen des Verifizierungs‑Prompts nach den Aufzeichnungen:

• Bei docs_chunks wird nun zuerst geprüft, ob die Version, nach der das JSONL erzeugt wurde, von der zu verifizierenden Version abweicht und ob das JSONL die aktuelle Code‑Ausführung erklärt.
• Auch wenn die Version unterschiedlich ist, kann ein Ja resultieren, wenn ein gemeinsames API/Verhalten explizit beschrieben wird; bei Kandidaten, die versionsspezifische Strukturen oder Node/API‑Unterschiede behandeln, wird separat geprüft, ob sie das gleiche Verhalten wie der aktuelle SOURCE_CODE haben.
• Bei api_mapping und label_prototypes wird zunächst bestimmt, ob der aktuelle SOURCE_CODE vor der Migration, bereits nach der Migration, irrelevant oder nicht migrierungsbedürftig ist.
• Ja wird nur dann erlaubt, wenn der aktuelle SOURCE_CODE vor der Migration steht und die im JSONL beschriebene Transformation jetzt angewendet werden muss.
• Diese Erweiterung ist keine reine Zeichenketten‑Filterung, sondern stärkt den Prozess, Kandidaten aus der Hybrid‑Search anhand des aktuellen Codes zu bewerten.

Verifizierungsergebnisse prüfen

Die Verifizierungsergebnisse werden unter jedem Slot versionsspezifisch angezeigt.

Auf diese Weise kann man innerhalb eines Slots sofort Folgendes sehen.

Godot 3 Code‑Überprüfung vor / Antwort / Erwartung / Übereinstimmung  
Godot 4 Code‑Überprüfung vor / Antwort / Erwartung / Übereinstimmung

Früher wurde nur „Dieses JSONL ist richtig/falsch“ angezeigt. Jetzt kann man sehen, „Bei welchem Code ist es richtig/falsch“.

Aktuelle Probleme, die das Tool löst

Veränderung der Entwicklerproduktivität

Bevor das Tool erstellt wurde, musste jeder Test manuell durchgeführt werden.

1. Qwen-Testpunktbeschreibung  
2. Godot 3 Code-Anfrage  
3. Godot 4 Code-Anfrage  
4. docs_chunks Richtige/Falsche JSONL-Anfrage  
5. api_mapping Richtige/Falsche JSONL-Anfrage  
6. label_prototypes Richtige/Falsche JSONL-Anfrage  
7. Jedes JSONL erneut mit SOURCE_CODE verknüpfen und prüfen  
8. Ja/Nein-Ergebnisse von Hand notieren  
9. Erwartungswert im Kopf mit dem Ergebnis vergleichen

Jetzt ist derselbe Ablauf im Bildschirm fixiert.

1. Eintrag anklicken  
2. AI‑Label erstellen  
3. Gemeinsamen oder Godot 3/4 Code erzeugen  
4. JSONL pro Slot erzeugen  
5. Godot 3 Code prüfen / Godot 4 Code prüfen  
6. Ergebnis und Prompt/Antwort prüfen

Besonders der Teil, bei dem die Produktivität gestiegen ist, liegt näher an „verwirrt nicht“ als an „schnell viel produzieren“. Bei dieser Arbeit ist es wichtiger, dass die Bewertungsmaßstäbe nicht schwanken, als die reine Produktionsmenge. Durch das Werkzeug wurde Folgendes erleichtert.

• Zuerst festlegen, ob es sich um eine gemeinsame Grammatik oder um eine Versionsaufteilung handelt
• Den Verwendungszweck von JSONL pro Tabelle ständig auf dem Bildschirm prüfen
• Erwartete und tatsächliche Prüfungsergebnisse der Erzeugungsrichtlinien trennen
• dieselbe JSONL im Godot‑3/4‑Code kreuzvalidieren
• Prompt und Rohantwort des fehlgeschlagenen Slots sofort einsehen
• Den Zustand, den sich eine Person merken muss, beim Wiederholen von 50 Einträgen reduzieren

Noch offene Probleme

Dieses Werkzeug ist noch kein endgültiger Evaluator. Im Moment ist es ein Debug‑Tool.

Offene Probleme sind:

• Die Begründung für docs_chunks kann auch dann als gemeinsame Beschreibung anerkannt werden, wenn die Versionen unterschiedlich sind.
• Wenn sowohl Quell‑ als auch Ziel‑Zeichenketten in api_mapping in die JSONL gelangen, kann Qwen nur die Ziel‑Zeichenkette sehen und „Ja“ sagen.
• Bei label_prototypes kann die Unterscheidung von Vorher‑/Nachher‑Mustern wichtiger sein als ein einfacher Zeichenkettenabgleich.
• Die aktuelle Berechnung der erwarteten Antwort dient nur Debug‑Zwecken; später muss die eigentliche Score/F1‑Berechnung gesondert verfeinert werden.
• Das Problem der Auswahl von Suchkandidaten und die Bewertung von Prüf‑Prompts lassen sich nicht allein anhand des Ergebnisses sofort trennen.

Aktuelle Schlussfolgerung

Am 28. Juni hatte man das Gefühl, „die 50 Tests von Hand durchzuführen“. In der Praxis stellte sich heraus, dass es zu viele Achsen zum Testen gab und dass man schnell verwirrt wurde, wenn gemeinsame Grammatik, Versionsaufteilung, Erzeugungs‑ und Prüf‑Versionen vermischt wurden.

Am 30. Juni wurde das Problem beim Erstellen des Werkzeugs weitgehend geklärt. Jetzt kann man nicht mehr nur „richtig/falsch“ sehen, wenn Qwen die JSONL erzeugt, sondern auch, in welchem Code sie erzeugt und in welchem Code sie geprüft wurde.

Dieses Werkzeug kann auch dann auf dieselbe Weise verwendet werden, wenn die tatsächlichen Suchergebnisse von docs_chunks, api_mapping und label_prototypes angehängt werden. Es ist also zu einem Basis‑Tool geworden, das nicht nur für manuelle Demo‑Daten, sondern auch für die Validierung von Datenbank‑Suchergebnissen eingesetzt werden kann.