2026-06-28 Rückblick

Heute habe ich die Arbeit, Markdown mit Qwen in JSONL zu sammeln, laufen lassen und darüber nachgedacht, wie man die JSONL später in die Datenbank einfügt und wie man sie abfragt.

Das AST-Debug‑Programm, das wir erstellt haben, extrahiert Code‑Chunks aus einem Godot‑Projekt. Auf Basis dieser Chunks musste eine Strategie entwickelt werden, wie man die in die DB eingefügten docs_chunks, api_mapping, label_prototypes‑JSONL abfragt. Deshalb habe ich die Suchstrategien von A bis F dokumentiert und mich derzeit für die F‑Strategie entschieden.

Da ich noch dabei bin, Markdown in JSONL zu sammeln, ist es noch zu früh, um Tests mit einer echten DB und einem Retriever durchzuführen. Deshalb habe ich heute 50 Checklisten erstellt und Qwen gebeten, beliebigen Godot‑Code zu schreiben. Für diesen Code habe ich passende und nicht passende JSONL erzeugt und dann jsonl + prompt + chunk zusammengeführt, um zu sehen, wie Qwen beurteilt. Auch mit nur fünf Beispielen wurde schnell klar, dass diese Arbeit deutlich aufwändiger ist als gedacht.

50‑Test‑Plan und Realität

Ursprünglich wollte ich heute alle 50 Godot‑Funktionen testen.

In der Praxis stellte sich jedoch ein anderes Bild ein. Zuerst habe ich eine Liste von 50 Funktionen erstellt, die in Godot 3 häufig in Funktions‑ oder kleinen Code‑Blöcken vorkommen, und diese Liste dokumentiert. Außerdem habe ich eine Prompt‑Vorlage vorbereitet, um zu prüfen, ob Qwen bei jsonl + prompt + chunk mit „Ja“ oder „Nein“ die Begründungs‑Übereinstimmung korrekt bewertet.

Anfangs dachte ich, man könnte sie einzeln erstellen und prüfen. Doch für jede zu testende Funktion musste ich mehr JSONL erzeugen als erwartet.

Man muss alle drei Tabellen docs_chunks, api_mapping, label_prototypes betrachten und für jede Tabelle sowohl passende als auch völlig unpassende JSONL anlegen. Zusätzlich muss man zwischen Fällen unterscheiden, bei denen die Syntax in Godot 3 und Godot 4 gleich ist und solchen, bei denen sie versionsabhängig ist.

Bei gemeinsamer Syntax kann man mit einem einzigen Code‑Beispiel die Erfolgs‑ und Fehl‑JSONL in allen drei Tabellen prüfen. Ist die Syntax nicht gemeinsam, muss man sowohl Godot 3‑ als auch Godot 4‑Code erzeugen. Und wenn man die für Godot 3 erstellten JSONL in den Godot 3‑Code einsetzt, muss man sie auch im Godot 4‑Code testen und umgekehrt.

Letztlich habe ich heute nur etwa 5 von 50 Funktionen getestet. Das ist zwar weniger als geplant, aber vielleicht besser, dass ich hier aufgehört habe. Hätte ich versucht, alle 50 manuell zu bearbeiten, wäre die Situation schnell unübersichtlich geworden.

Gemeinsame Syntax und Versions‑Basis

Beim Testen wurde mir am deutlichsten, dass es schwierig ist, Godot 3 und Godot 4 einfach in zwei Gruppen zu teilen.

Manche Funktionen haben fast identische Syntax in beiden Versionen. In solchen Fällen ist es unlogisch, anhand eines einzigen Codes zu entscheiden, ob er ausschließlich für Godot 3 oder Godot 4 gilt. Handelt es sich um gemeinsame Syntax, sollte man prüfen, ob die zugehörigen und die unpassenden JSONL in docs_chunks, api_mapping, label_prototypes korrekt unterschieden werden.

Bei Funktionen mit Versionsunterschieden wird es komplexer. Ein für Godot 3 erstelltes JSONL kann im Godot 4‑Code ebenfalls ein „Ja“ erzeugen, und umgekehrt kann ein für Godot 4 erstelltes JSONL im Godot 3‑Code wegen einzelner Felder ein „Ja“ liefern. Besonders bei Migrations‑JSONL, bei denen Quelle und Ziel gleichzeitig vorkommen, reicht reines String‑Matching nicht aus.

Deshalb sollte künftig festgehalten werden, für welche Version das JSONL erstellt wurde und für welche Version der prüfende Code gedacht ist. Auch ein „Ja“ muss unterschieden werden, ob es wegen gemeinsamer Syntax ein natürliches „Ja“ ist oder ein unsicheres „Ja“, das durch gemischte source/target‑Strings entsteht.

F1‑Score‑artige Aufzeichnung ist nötig

Wenn man Testergebnisse nur als „Erfolg“ oder „Fehler“ notiert, ist es später schwer, Muster zu erkennen.

Mein Ansatz ist, nicht sofort den F1‑Score zu berechnen, sondern die rohen Bewertungsresultate zu speichern, ähnlich wie bei Precision und Recall. Man sollte festhalten, ob ein erwartetes „Ja“ fälschlich als „Nein“ ausgegeben wurde, umgekehrt, ob bei gemeinsamer Syntax ein beidseitiges „Ja“ korrekt ist oder ob ein Migrations‑JSONL zu einem unsicheren „Ja“ geführt hat.

Durch solche Aufzeichnungen lässt sich später besser analysieren, ob das Prompt‑Design, die JSONL‑Erstellungsrichtlinien oder das Tabellenschema das Problem ist. Wenn man wie bisher handschriftlich Notizen macht, wird das Nachvollziehen später sehr mühsam.

Selbst mit nur fünf Tests wurden bereits einige unklare Punkte sichtbar. Ab dem sechsten Test sollte daher nicht nur die Test‑Strategie weiterverfolgt, sondern auch die Dokumentations‑ und Prompt‑Strategie angepasst werden.

Grenzen manueller Tests

Das manuelle Kopieren von Prompts, Einfügen von Code‑Chunks, Einpflegen einzelner JSONL und das erneute Aufzeichnen von Qwen‑Antworten ist extrem ineffizient.

Einige Tests von Hand zu starten, half zunächst, ein Gefühl für die Basis zu bekommen. In der Praxis zeigte sich jedoch, dass bereits für eine einzige Funktion viele JSONL nötig sind, dass man zwischen gemeinsamer und versionsspezifischer Syntax unterscheiden muss und dass die Bedeutung von „Ja“ und „Nein“ kontextabhängig ist.

Den gesamten Prozess für 50 Funktionen manuell zu wiederholen, ist nicht realistisch. Fehler beim manuellen Eintragen sind unvermeidlich und ein später Vergleich der Ergebnisse wird schwierig.

Deshalb denke ich über ein Debug‑Tool nach, das Code‑Chunk, Tabellentyp, JSONL‑Erstellungs‑Version, Prüf‑Code‑Version, erwartete Antwort und tatsächliche Antwort auf einer Oberfläche zusammenführt und die Qwen‑Aufrufe automatisch protokolliert. Ähnlich wie ich bereits die AST‑ und Retriever‑Flows im Web betrachtet habe, wäre ein GUI‑ oder Debug‑Page‑Ansatz für JSONL‑Matching‑Tests sehr hilfreich.

Qwen‑Chatbot‑Testdatengenerierung – Überlegungen

Heute habe ich darüber nachgedacht, wie man mit dem Qwen‑Chatbot zufällige Testdaten erzeugt.

Ich wollte ein kleines Demo‑Set erstellen, das die Verifikations‑Methode selbst herausfordert. Zum Beispiel den Chatbot bitten, einen Godot 3‑Code‑Chunk, einen Godot 4‑Code‑Chunk sowie passende und unpassende JSONL für docs_chunks, api_mapping, label_prototypes zu generieren.

Das Problem ist, dass ein einfacher Befehl wie „Erstelle korrekte JSONL und falsche JSONL“ zu zu plausibel gemischten Ergebnissen führen kann. Je nachdem, ob es sich um gemeinsame Syntax, Godot 3‑exklusiv, Godot 4‑exklusiv oder um Migrations‑Source/Target handelt, ändern sich die „Ja“/„Nein“-Antworten. Deshalb muss man beim Erzeugen zufälliger Daten Version, Prüf‑Code‑Version, Tabellentyp und erwartete Antwort mit angeben.

Mir wurde klar, dass die Generierung zufälliger Testdaten mit Qwen und die dazugehörigen Prompts präziser definiert werden müssen, um zu prüfen, ob Qwen in diesem Test nur auf sein internes Wissen zurückgreift oder ausschließlich die im JSONL enthaltenen String‑Belege zur Bewertung nutzt.

Heute’s Fazit

Heute war nicht so sehr ein Tag, an dem wir eine große Menge getestet haben, sondern ein Tag, an dem wir festgestellt haben, dass sowohl die Retriever‑Suchstrategie als auch das Qwen‑Chatbot‑basierte JSONL‑Matching‑Experiment mehr Aufwand erfordern als erwartet.

Ich dachte zunächst, ich könnte alle 50 Tests durchführen. In der Praxis zeigte sich jedoch, dass bereits 5 Tests ausreichend viele Probleme aufdeckten. Manchmal unterscheiden sich Godot 3 und Godot 4 völlig, aber es gibt auch gemeinsame Syntax, und bei Fällen wie dem Migrations‑JSONL, bei dem Quelle und Ziel zusammenkommen, schwankt die Bewertung.

Deshalb ist das, was jetzt wirklich gebraucht wird, nicht einfach die Anzahl der Tests wahllos zu erhöhen, sondern eine Struktur, die die Testergebnisse ordentlich festhält. Es sollten JSONL‑Erstellungs‑Basisversion, Prüfcode‑Version, Tabellentyp, Erwartete Antwort, Tatsächliche Antwort und Unklare Gründe dokumentiert werden. Nur so kann man, wenn man alle 50 Tests abgeschlossen hat, nicht nur eine bloße Meinung, sondern ein Muster erkennen.

Heute begann ich ohne große Überlegungen, indem ich willkürliche Daten erstellte und testete, doch schließlich erkannte ich die Notwendigkeit, Testdaten mit dem Qwen‑Chatbot zu erzeugen, Prompt‑Strategien zu entwickeln und ein automatisch aufgerufenes Debug‑Tool zu nutzen. Ab morgen sollte ich ab dem 6. Test die Kriterien leicht anpassen und zuerst Wege finden, den manuellen Wiederholungsaufwand zu reduzieren.