Heute geht es darum, zu entscheiden, welchem Such‑/Verifizierungs‑Ansatz wir folgen wollen
chunkText bleibt unverändert als Eingabe, und wir müssen entscheiden, wie BM25, PostgreSQL‑Volltextsuche, Embedding, Reranker und der Qwen‑Direct‑Evidence‑Validator kombiniert werden sollen
Anfangs war es noch kein fester Entwurf, sondern wir hatten nur die Vor‑ und Nachteile der einzelnen Suchmethoden, die wir über ChatGPT erhalten hatten, sowie die Ja/Nein‑Antwortflüsse als Entscheidungsgrundlage gesammelt
Anschließend haben wir anhand von Simulationen und einer Gesamttabelle die F‑Strategie priorisiert
Das heißt, wir verwenden chunkText weiterhin als Such‑Input, sammeln zunächst breit Kandidaten mit BM25 und Embedding, sortieren sie anschließend mit dem Reranker und lassen zuletzt Qwen prüfen, ob das gefundene JSONL tatsächlich als Beleg zum aktuellen Code‑Chunk passt
Der nächste Validierungsschritt besteht darin, mit Qwen jeweils 50 Einträge aus docs_chunks, api_mapping und label_prototypes pro Tabelle zu testen
In jeder Tabelle werden etwa 50 Stichproben in „relevante Fälle“ und „nicht‑relevante Fälle“ aufgeteilt, um zu beobachten, wie sich die Antworten bei erwarteten Ja‑ bzw. Nein‑Fällen unterscheiden
Dieser Test prüft nicht nur, ob die Suche funktioniert, sondern ob der Qwen‑Direct‑Evidence‑Validator die gefundenen JSONL als gültige Belege für den Code‑Chunk akzeptiert oder verwirft
Da wir alles manuell durchführen, ist das zu testende Volumen größer als erwartet
Wir haben 50 Godot‑Testfälle erstellt, und für jeden Fall müssen alle drei Tabellen (docs_chunks, api_mapping, label_prototypes) geprüft werden
Bei gemeinsamen Funktionen/ Syntax erzeugen wir einen Godot‑Code‑Chunk und erstellen erwartete Ja/Nein‑Daten für docs_chunks, api_mapping und label_prototypes; anschließend prüfen wir mit Prompt + Testcode + sechs Daten, wie das Antwortmuster ausfällt
Für nicht‑gemeinsame Funktionen müssen separate Code‑Chunks für Godot 3 und Godot 4 erstellt werden, was den Arbeitsaufwand praktisch verdoppelt
Um die Ergebnisse später als Klassifikationskennzahl (z. B. F1‑Score) zusammenzufassen, müssen wir die wahren/ falschen Resultate aller Fälle manuell festhalten
Daher ist es unrealistisch, alle 50 Fälle an einem Tag abzuschließen; das heutige Ziel ist, nur 5 Fälle zu bearbeiten
Nach den 5 Fällen wechseln wir von einer reinen Erhöhung der Testanzahl zu einer Analyse der bisherigen Ja/Nein‑Antwortmuster
Wir haben tatsächlich 5 von 50 Fällen bearbeitet
Schon bei diesen 5 Fällen zeigte sich, dass die Antwortflüsse für JSONL, die nach Godot 3‑ bzw. Godot 4‑Standards erstellt wurden, unterschiedlich sind
Insbesondere bei versionsabhängigem Code kann ein mit Godot 3 erstelltes JSONL beim Prüfen von Godot 4‑Code wegen gemeinsamer Zeichenketten oder Migrationsbelegen ein Ja ergeben, und umgekehrt kann ein Godot 4‑JSONL beim Prüfen von Godot 3‑Code ein uneindeutiges Ergebnis liefern, wenn Quell‑/Ziel‑Zeichenketten vermischt sind
Deshalb sollten wir ab dem nächsten Test nicht nur prüfen, ob die 6 Antworten Ja/Nein entsprechen, sondern zunächst zwischen gemeinsamer Syntax und Versionsunterschied unterscheiden und dann die JSONL‑Erstellungs‑Version und die Prüf‑Code‑Version getrennt protokollieren
Dabei wird klar, dass wir nicht nur den Validierungs‑Prompt anpassen, sondern auch die Prompt‑Strategie und die Datensammlungs‑Strategie überarbeiten müssen
Künftig sollten wir beim Erstellen von JSONL die Sammlung/Erzeugung so trennen, dass gemeinsame Syntax, Godot 3‑spezifische Belege, Godot 4‑spezifische Belege und bidirektionale Migrationsbelege nicht vermischt werden
Gleichzeitig läuft die Konvertierung von offizieller Dokumentation Markdown → JSONL weiter; bis heute wurden von insgesamt 1 570 Markdown‑Dateien etwa 600 in JSONL umgewandelt