2026-07-03 Rückblick

Was ich heute gemacht habe

Heute habe ich einfach einen 24‑Stunden‑YouTube‑Stream laufen lassen, während ich die Sammlung betrieben, einen Übersetzungstest durchgeführt und das am 30. Juni erstellte Verifizierungs‑Tool weiter benutzt habe, um die Validierung durchzuführen.

Der Bereich Markdown → JSONL Converter ist von 737 auf 850 Einträge im offiziellen Dokument‑JSONL‑Umwandlungs‑Datensatz gestiegen. Heute habe ich, anstatt ein großes neues Feature zu pushen, die Sammlung weiterlaufen lassen, solange RunPod aktiv ist, und dabei schrittweise die Validierung und den Übersetzungs‑Workflow überprüft.

Im Übersetzungs‑Teil experimentiere ich mit einer Pipeline, die die kostenlose NVIDIA‑Modell‑API nutzt. Durch GitHub‑Workflow‑Secrets habe ich bereits teilweise Erfolg gesehen und Bildschirme, auf denen japanische/ chinesische README‑Dateien erzeugt werden, bestätigt. Es ist noch nicht der Zeitpunkt, um von einer vollständigen Einführung zu sprechen, aber je mehr Dokumente entstehen, desto stärker wird das Bedürfnis nach einem automatischen Übersetzungs‑Workflow.

Der Nutzen des Verifizierungs‑Tools

Das, was mir heute am meisten aufgefallen ist, dass es eine sehr gute Entscheidung war, am 30. Juni das Verifizierungs‑Tool erstellt zu haben. Ohne dieses Tool wäre fast ein großes Problem entstanden.

Nach der alten Vorgehensweise musste man Qwen separat Code und JSONL erzeugen lassen, das dann wieder in den Prompt einbetten und die erwartete Antwort im Kopf vergleichen. Jetzt kann man einen Eintrag anklicken, Code und JSONL generieren, sowohl den Godot 3‑ als auch den Godot 4‑Code prüfen und Roh‑Prompt sowie Roh‑Response auf einem Bildschirm sehen. Der manuelle Aufwand bleibt zwar bestehen, aber zumindest kann man jetzt genau erkennen, was falsch ist.

Heute habe ich die ersten zehn von fünfzig Testeinträgen durchgeklickt und überprüft. Dabei gab es tatsächlich Fälle, in denen das LLM falsche Ausgaben lieferte.

• Bei Eintrag 1 wurde docs_chunks fälschlicherweise als passend bewertet, weil es dieselben Hinweise wie _ready() oder viewport‑bezogene Stichwörter enthielt, obwohl es sich um eine andere Code‑Beschreibung handelte.
• Bei Eintrag 3, 4 und 7 wurde ein auf Godot 3 basierendes Migrations‑JSONL bereits in den Godot 4‑Code eingefügt, aber dennoch als „Ja“ bewertet.
• Bei Eintrag 8 wurde docs_chunks wegen ähnlicher Verfolgungs‑/Bewegungsthemen oder ähnlicher APIs als passend eingestuft, obwohl es nicht mit dem tatsächlichen Verhalten des SOURCE_CODE übereinstimmte.
• Bei Eintrag 6, 9 und 10 wurden alle erwarteten Werte erfüllt, sodass die Verbesserungsrichtung nicht grundsätzlich falsch ist.

Diese Probleme entstehen weniger durch ein fehlerhaftes einzelnes JSONL, sondern eher dadurch, dass bei einer späteren hybriden Suche ähnliche Kandidaten auftauchen und Qwen entscheiden muss, ob er diese als direkte Grundlage nutzt oder sie lediglich als Suchergebnis filtert. Deshalb sollte man nicht nur bestimmte Tokens blockieren, sondern den Verifizierungs‑Prompt so verfeinern, dass er die Beziehung zwischen aktuellem Code und JSONL‑Kandidaten genauer beurteilt.

Eindrücke

Heute war kein Tag mit besonders spektakulären Implementierungen. Ich habe die automatische Sammlung laufen lassen, manuell die Validierung geklickt und mir die JSONL‑ und Validierungsergebnisse angesehen, was länger dauerte als erwartet. Trotzdem bin ich zufrieden, weil ich das Gefühl habe, etwas erreicht zu haben.

Die Validierung dauert länger als gedacht. Auch wenn es so aussieht, als würde man nur einen Code‑ und einen JSONL‑Eintrag prüfen, unterscheiden sich die Eigenschaften von docs_chunks, api_mapping und label_prototypes, und zudem gibt es Unterschiede zwischen Godot 3‑ und Godot 4‑Code. Schon bei zehn Einträgen entstehen zahlreiche Fälle.

Wenn man jedoch bereits im Vorfeld die fehlerhaften Stellen identifiziert, kann man später bei der eigentlichen Datenbanksuche und dem Retriever‑Validierungs‑Workflow Unfälle vermeiden. Ich möchte auch künftig Probleme, die sich im Test frühzeitig abzeichnen, konsequent festhalten.

Falls ich etwas verbessern möchte, könnte man neben RunPod auch kostenlose APIs einsetzen. Wenn die kostenlose NVIDIA‑Modell‑API oder andere kostenlose Endpunkte zuverlässig für Übersetzung, unterstützende Validierung und Dokumentensynchronisation genutzt werden können, könnte die Abhängigkeit von RunPod etwas reduziert werden.