Heute soll entschieden werden, welchem Such‑/Verifizierungs‑Ansatz gefolgt wird
chunkText bleibt unverändert als Eingabe, und es muss entschieden werden, wie BM25, PostgreSQL‑Volltextsuche, Embedding, Reranker und der Qwen‑Direct‑Evidence‑Validator kombiniert werden
Anfangs war es noch kein festes Design, sondern lediglich eine Sammlung von Vor‑ und Nachteilen der jeweiligen Suchmethoden, die über ChatGPT erhalten wurden, sowie von Ja/Nein‑Antwort‑Flows als Entscheidungsgrundlage
Anschließend wurde anhand von Simulationen und einer Gesamttabelle beschlossen, die F‑Strategie vorrangig zu wählen
Das heißt, chunkText wird als Such‑Input verwendet, BM25 und Embedding sammeln breit Kandidaten, der Reranker sortiert neu, und zum Schluss prüft Qwen, ob das gefundene JSONL tatsächlich als Beleg zum aktuellen Code‑Chunk passt
Der nächste Test wird mit Qwen durchgeführt, indem je 50 Einträge aus docs_chunks, api_mapping und label_prototypes pro Tabelle getestet werden
In jeder Tabelle werden etwa 50 Stichproben in „relevante Fälle“ und „nicht‑relevante Fälle“ aufgeteilt, um zu sehen, wie sich die Antworten „Ja“ bzw. „Nein“ unterscheiden
Dieser Test prüft nicht nur, ob die Suche gut funktioniert, sondern ob der Qwen‑Direct‑Evidence‑Validator das gefundene JSONL als gültigen Beleg für den Code‑Chunk akzeptiert oder verwirft
Da alles manuell erfolgt, ist der tatsächliche Testaufwand größer als erwartet
Es wurden 50 Godot‑Testfälle erstellt, und für jeden Fall müssen die drei Tabellen docs_chunks, api_mapping und label_prototypes geprüft werden
Bei gemeinsamen Funktionen/ Syntax wird ein Godot‑Code‑Chunk erstellt und die erwarteten Ja‑/Nein‑Daten für die drei Tabellen erzeugt; anschließend werden Prompt, Testcode und 6 Datenpunkte eingesetzt, um das Antwortverhalten zu analysieren
Bei nicht‑gemeinsamen 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 Klassifikations‑Metrik (z. B. F1‑Score) zusammenzufassen, müssen alle wahren/falschen Ergebnisse manuell dokumentiert werden
Daher wurde entschieden, dass es unmöglich ist, alle 50 Fälle an einem Tag zu erledigen; das heutige Ziel ist, nur 5 Fälle zu bearbeiten
Nach den 5 Fällen soll nicht einfach die Testanzahl erhöht, sondern zunächst das bisherige Ja/Nein‑Antwortmuster analysiert werden
Tatsächlich wurden 5 von 50 Fällen bearbeitet
Auch bei nur 5 Fällen zeigte sich, dass die Antwortflüsse für JSONL, die nach Godot 3 bzw. Godot 4 erstellt wurden, unterschiedlich sind
Insbesondere bei versionsabhängigem Code kann ein JSONL, das nach Godot 3 erstellt wurde, beim Prüfen von Godot 4‑Code wegen gemeinsamer Zeichenketten oder Migrations‑Belegen ein „Ja“ ergeben, und umgekehrt kann ein Godot 4‑JSONL beim Prüfen von Godot 3‑Code bei gemischten source/target‑Strings zu uneindeutigen Ergebnissen führen
Deshalb soll ab dem nächsten Test nicht nur geprüft werden, ob die 6 Antworten „Ja/Nein“ passen, sondern zunächst zwischen gemeinsamer Syntax und Versionsunterschieden unterscheiden und dann „JSONL‑Erstellungs‑Version“ und „Prüf‑Code‑Version“ getrennt protokollieren
Dabei wird klar, dass nicht nur die Prompt‑Formulierung, sondern auch die Prompt‑Strategie und die Datensammel‑Strategie angepasst werden müssen
Künftig sollte beim Erstellen von JSONL darauf geachtet werden, dass gemeinsame Syntax, Godot 3‑spezifische Belege, Godot 4‑spezifische Belege und bidirektionale Migrations‑Belege getrennt gesammelt/erstellt 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