Rückblick vom 22. Juni 2026

Heute habe ich einen Ablauf erstellt, bei dem die offizielle Godot‑Dokumentation‑Markdown nicht direkt in RAG eingespeist wird, sondern zuerst in strukturiertes JSONL umgewandelt und überprüft wird. Anfangs war ich mir nicht sicher, wie man das Markdown am besten aufteilen sollte, aber als ich eine Umwandlungs‑UI gebaut und die Ergebnisse pro Datei visuell betrachtet habe, wurde es deutlich einfacher.

Markdown → JSONL‑Umwandler

Wenn man eine offizielle Godot‑Dokumentation‑Markdown‑Datei hochlädt, klassifiziert die Qwen‑API die Zieltabellen und teilt das Ergebnis in JSONL‑Dateien für docs_chunks, api_mapping und label_prototypes auf.

Zunächst dachte ich, man könnte das Markdown einfach lesen und sofort in die Datenbank schreiben, aber dann war es schwer nachzuvollziehen, welches Dokument in welche Tabelle gelangt. Deshalb erstelle ich zunächst ein JSONL‑Zwischenergebnis und vergleiche auf dem Bildschirm die Umwandlung mit dem Originaltext.

Die Vorteile dieses Ansatzes sind:

• Man kann das Original‑Markdown und das konvertierte JSONL nebeneinander sehen.
• Man erkennt, in welche der Tabellen docs_chunks, api_mapping oder label_prototypes ein Dokument eingeordnet wird.
• Falsch klassifizierte Dokumente oder leere Ergebnisse können vor dem Laden in die Datenbank herausgefiltert werden.
• Auch wenn die Umwandlungsregeln später geändert werden, lässt sich das JSONL neu erzeugen und vergleichen.

Umwandlungsergebnis prüfen

Der Umwandler zeigt die Anzahl der gespeicherten JSONL‑Dateien und die Fehlermeldungen an. Auf dem heutigen Bildschirm war zuerst das Ergebnis für docs_chunks sichtbar, während api_mapping, label_prototypes und die Fehlermeldungen noch leer waren.

Dieser Zustand ist nicht unbedingt ein Fehler, sondern erklärt sich dadurch, dass die ersten Dokumente hauptsächlich Beschreibungen sind und daher natürlich in docs_chunks landen. Wichtig ist, dass die Ergebnisse nicht sofort in die Datenbank fließen, sondern zuerst als JSONL gespeichert und von Menschen geprüft werden können.

JSONL‑Vorschau und Tabellenansicht

Die JSONL‑Ergebnisse können sowohl im JSON‑Format als auch in Tabellenform angezeigt werden. Zum Beispiel enthält ein docs_chunks‑Datensatz Felder wie chunk_id, doc_version, source_url, source_file, source_sha256, doc_type, section_path, heading, content, code_blocks, api_symbols, token_count und metadata.

So wirkt es deutlich besser als das bloße Durchblättern von Markdown‑Dateien. Besonders weil chunk_id und source_sha256 zusammen angezeigt werden, lässt sich später leicht nachvollziehen, aus welchem Original ein Chunk stammt. In RAG ist es entscheidend, die Herkunft der Informationen nicht zu verlieren – das JSONL‑Zwischenergebnis erfüllt genau diese Aufgabe.

Umwandlungs‑Log

Auch die Log‑Dateien pro Dokument wurden geprüft. Man kann sehen, welches Dokument gestartet wurde, in welche Tabelle Qwen es einsortiert hat und wie viele gültige Records erzeugt wurden.

Im heutigen Beispiel wurde das Dokument about__complying_with_licenses in docs_chunks klassifiziert und in mehrere Chunks aufgeteilt. Im Gegensatz dazu wurden Dokumente wie 404 übersprungen, weil keine Ziel‑Tabelle vorhanden war. Solche Logs sind unverzichtbar, um bei der Verarbeitung von 1 570 Dokumenten später Fehlerquellen zu identifizieren.

Lokales PostgreSQL‑Setup

Nachdem das JSONL erstellt wurde, habe ich die Datenbank so vorbereitet, dass sie die Daten aufnehmen kann. Mit einem Container auf Basis von pgvector/pgvector:pg16 wurden die Tabellen docs_chunks, api_mapping, label_prototypes und ingest_reports angelegt.

Besonders wichtig war, dass das DB‑Schema exakt zu den Feldnamen des JSONL passt. Wenn die Datenbank eigene Felder hinzufügt, wird das JSONL‑Vertrag unscharf und später können Umwandler und Inserter unterschiedliche Annahmen treffen. Deshalb wurden die Payload‑Spalten an das JSONL‑Schema angepasst, während betriebsrelevante Spalten wie id, embedding, search_tsv und created_at auf das Minimum reduziert wurden.

Der lokale DB‑Container läuft, und Beispiel‑Inserts sowie Suchabfragen im JSONL‑Format wurden im Rollback‑Test verifiziert. Noch nicht alle Dokumente wurden in die DB geladen, aber der Weg von JSONL zu PostgreSQL ist jetzt deutlich klarer.

Heutiges Fazit

Der heute erstellte Ablauf ist noch nicht der endgültige RAG‑Entscheider, aber er stellt einen bedeutenden Fortschritt dar.

Früher war unklar, wie man die offizielle Dokumentation‑Markdown verarbeiten sollte; ein direkter Sprung zu Chunking oder DB‑Injektion hätte die Struktur verwischt. Heute gibt es einen Zwischenschritt – die JSONL‑Umwandlung und -Validierung – der von Menschen geprüft werden kann.

Zusammenfassend sieht der weitere Weg so aus, dass wir diesen Prozess beibehalten und weiter verfeinern.

Godot offizielle Dokumentation Markdown  
-> JSONL-Konvertierung  
-> JSONL-Vorschau/Validierung  
-> PostgreSQL-Injektion  
-> Retriever-Suchvalidierung  
-> Validator/Qwen-Antwortzusammenfassung

Nach dem morgigen Tag muss überprüft werden, mit welchem Verhältnis docs_chunks, api_mapping und label_prototypes herauskommen, wenn alle 1.570 Dokumente vollständig konvertiert wurden. Insbesondere dürfen api_mapping und label_prototypes nicht beliebig von Qwen erstellt werden; das automatisch erzeugte Ergebnis darf nicht blind vertraut werden, sondern es muss ein separater Genehmigungs‑/Verifizierungs‑Schritt eingeführt werden.

Messung der Verarbeitungsgeschwindigkeit

Zusätzlich wurde die Umwandlungsgeschwindigkeit berechnet und es scheint, dass die Konvertierung aller 1.570 Markdown‑Dateien in JSONL etwa 42 Stunden dauern wird.

Die bisherige tatsächliche Verarbeitungszeit betrug etwa 1 Stunde 9 Minuten. In dieser Zeit wurden insgesamt 43 Dateien verarbeitet, nämlich 39 done und 4 deferred. Die durchschnittliche Geschwindigkeit liegt bei etwa 1,6 Minuten pro Datei.

Tatsächliche Bearbeitungszeit: ca. 1 Stunde 9 Minuten  
Derzeit verarbeitete Dateien: erledigt 39 Stück + zurückgestellt 4 Stück = 43 Stück
Durchschnittsgeschwindigkeit: ca. 1,6 Minuten pro Datei
Gesamte geschätzte Umwandlungszeit für 1.570 Stück: ca. 42 Stunden

Zunächst dachte ich, dass es etwa ein Stück pro Minute dauert, aber nach Berechnung anhand der tatsächlichen Logs dauert es etwas länger. Da es möglicherweise schwierig ist, heute alle 1.500 Stück vollständig zu konvertieren, sollten wir den Fortschritt fortlaufend dokumentieren, indem wir die Verarbeitungsgeschwindigkeit sowie die Anzahl fehlgeschlagener/zurückgestellter Dateien festhalten.

Nächster Validierungsplan

Morgen und übermorgen wird es wahrscheinlich nicht klappen, sodass wir die Arbeit nicht sofort fortsetzen können. Trotzdem ist der spätere Nachholbedarf bereits einigermaßen strukturiert.

Zunächst muss das bereits während Sammlung und Konvertierung erzeugte JSONL in die lokale PostgreSQL-Datenbank importiert werden. Bisher konzentrierte sich der erstellte Konverter darauf, Markdown in JSONL für docs_chunks, api_mapping und label_prototypes zu splitten; der nächste Schritt besteht darin, dieses JSONL in die tatsächliche Datenbank zu laden und zu prüfen, ob es durchsuchbar ist.

Anschließend soll der in docs/roadmaps/2026-06-21-initial-rag-classifier-architecture.md beschriebene Workflow‑Ablauf in einem kleinen Python‑Skript verifiziert werden.

source code
-> AST Parser
-> Retriever
-> evidence JSONL / evidence bundle
-> Qwen 3.6 API-Aufruf
-> Antwort prüfen

Das heißt, wir setzen beliebigen Godot-Quellcode in ein Python‑Skript ein und prüfen, ob der AST‑Parser die Symbole und Versionssignale extrahiert. Das Ergebnis geben wir an den Retriever weiter, damit er aus PostgreSQL die zugehörigen offiziellen Dokumenten‑Chunks oder API‑Mappings abruft, und wenn wir das zurückgegebene JSONL/evidence‑Bundle an die Qwen 3.6‑API übermitteln, prüfen wir zwischendurch, welche Antwort entsteht.

Dieser Vorgang ist keine vollständige Automatisierung, sondern eher ein kleiner End‑to‑End‑Test, um zu überprüfen, ob jeder Schritt tatsächlich funktioniert. Insbesondere muss festgestellt werden, ob Qwen aus dem Gedächtnis antwortet oder ob es basierend auf den vom Retriever bereitgestellten Belegen antwortet.

Gedanken zur öffentlichen und privaten Umwandlung von Repositories

Kürzlich habe ich dieses Repository einmal öffentlich gemacht und dann wieder auf privat umgestellt. Der Grund war wohl einfach: Ich wollte meine Fähigkeiten nicht zeigen.

Jetzt fühle ich, dass meine Fähigkeiten noch ziemlich unzureichend sind. Gleichzeitig kam mir der Gedanke, ein spezielles Modell für Godot zu erstellen, es auf Hugging Face hochzuladen und es als Ausgangspunkt zu nutzen, um es auf verschiedene Bereiche wie Lehrvideos, Universitäten, Portfolios und Ehrungen auszudehnen. Aus einer Sichtweise wirkt das fast wie ein zu träumerisches Hirngespinst. Trotzdem dachte ich, wenn jemand meine Rückblicke und Arbeitsprotokolle als Sprungbrett nutzt, um zu wachsen, könnte ich dadurch selbst schneller vorankommen.

Tatsächlich gibt es immer noch das Gefühl, es nicht veröffentlichen zu wollen. Ich habe Angst, dass das, was ich geschaffen habe, nicht tiefgründig wirkt, und gleichzeitig habe ich mich davor gefürchtet, dass jemand die Teile, die ich durch das flache Verknüpfen verschiedener Kenntnisse leicht erscheinen ließ, einfach übernehmen könnte. Es war weniger die enorme Technologie des Endprodukts, sondern vielmehr die Sorge, dass die Spuren meiner bisherigen Überlegungen und Verknüpfungen vollständig sichtbar werden.

Ich habe zwar PRs und CI/CD‑Pipelines eingerichtet, aber der ursprünglich geplante Ablauf war, dass bei einem PR in GitHub‑Workflow automatisch ein lokal gehosteter LLM‑Endpoint in Oracle Cloud den PR‑Review übernimmt. Da die Oracle‑Cloud‑Umgebung über 24 GB VRAM verfügt, dachte ich, dass die meisten lokalen Modelle dort laufen könnten, und wollte das gehostete LLM zur Automatisierung von Code‑Reviews einsetzen. Allerdings habe ich den Oracle‑Cloud‑Account verloren, sodass dieser Ablauf vorerst nicht wiederverwendet werden kann. Auch bei RunPod gibt es beim Einsatz für PR‑Validierung den Aufwand, bei jeder Ausführung die Umgebung neu einrichten zu müssen. Deshalb konzentriere ich mich zunächst auf manuelle Prozesse und Dokumentation, und die LLM‑basierte PR‑Review‑Automatisierung wird später wieder aufgenommen – das erscheint realistischer.

Der Schluss scheint dies zu sein. Obwohl die Wahrscheinlichkeit groß ist, dass niemand es überhaupt sehen wird, war ich sehr vorsichtig, nicht entlarvt zu werden. Aber selbst wenn jemand meine Arbeit als Referenz nimmt oder übernimmt, sollte ich das als Sprungbrett nutzen, um noch besser zu werden. Ob ich es veröffentliche, muss weiterhin vorsichtig entschieden werden, aber aus Angst sollte ich das Aufzeichnen selbst nicht einstellen.