idea_world_labDEV JOURNAL
Mittwoch, 17. Juni 2026

2026-06-17 Godot LLM/RAG Erkennungs‑Tool Aufbau Rückblick

Einzeilige Zusammenfassung

Heute wurde die Ausrichtung des auf Godot spezialisierten Codierungsmodells von einem einfachen Q&A‑Modell zu einem repo‑basierten SWE‑Agenten geändert, und davor wurde der notwendige, auf der offiziellen Dokumentation basierende RAG‑Erkenner sowie die erste konkrete Daten‑Erzeugungs‑Pipeline erstellt.

Der große Ablauf des heutigen Tages

Anfangs war das Ziel etwa „einen RAG‑Chatbot mit der Godot‑Dokumentation erstellen“. Doch im Verlauf von Diskussion und Arbeit wurde das Ziel klarer.

Godot-Officialdokumente sammeln
-> Auf Basis offizieller Dokumente RAG-Detektor
-> GitHub Godot-Projekt-Labeling
-> SFT/DPO-Datenerstellung
-> Qwen-basiertes Godot 4 Coding-Modell
-> Repository‑Ebene SWE-Agent

Kurz gesagt, das Ziel von heute war nicht, einen einzelnen Chatbot zu erstellen, sondern eine Daten‑Erkennungs‑/Erzeugungs‑Basis zu schaffen, um später ein Modell zu entwickeln, das Godot‑Projekte tatsächlich lesen und korrigieren kann.

1. Die Einschätzung, dass ein einfaches Q&A‑Modell nicht ausreicht

Heute habe ich zuerst das Wesen des Modellziels geklärt.

Vorher dachte man daran, einen Frage‑Antwort‑Datensatz zu Godot 4 zu erstellen und das Modell so zu trainieren, dass es gute Godot‑4‑Code‑Antworten liefert. Aber wenn man Anfragen wie „Erstelle eine Karte für mich“ in Betracht zieht, ist das kein einfaches Q&A‑Problem.

Der tatsächliche Anforderungsablauf ist eher wie folgt.

Benutzeranfrage verstehen
-> Repository-Struktur durchsuchen
-> Verwandte Szene/Skript/Resource finden
-> Asset-Pfad und bestehenden Code-Stil prüfen
-> Godot 4 Syntax/API beurteilen
-> Code ändern
-> Ausführen/Testen/Validieren
-> Patch erstellen

Dieser Ablauf ist kein Problem, das nur eine Antwort erzeugt, sondern ein Software‑Engineering‑Agent‑Problem. Deshalb habe ich heute die Modellrichtung erneut aus der Perspektive des SWE-agent trajectory training festgelegt.

Heute aufgezeichnete Schlüsselwörter:

Long-context repository-level software engineering agent training
SWE-agent trajectory training
Godot repo-level patch generation
long-context trajectory dataset

Referenzbeispiele wurden ebenfalls zusammengefasst.

SWE-agent trajectories
SWE-smith
SWE-Gym
CoderForge-Preview
ACC
RepoBench / CrossCodeEval / RepoCoder
aiXcoder CoLT
godot-dodo
wallstoneai/godot-gdscript-dataset

Das heutige Fazit war, dass kleine Instruction Q&A nicht ausreichen. Letztendlich wird die Exploration, Bewertung, Korrektur und Verifizierung von Godot‑Projekteinheiten benötigt.

Verwandte Notizen:

docs/research-notes/2026-06-17-swe-agent-trajectory-keywords.md

2. Godot LLM Gesamte Roadmap Zusammenfassung

Danach habe ich den gesamten Entwicklungsfahrplan neu erstellt.

Der große Ablauf wurde wie folgt zusammengefasst.

Daten
-> Erster RAG‑Chatbot
-> SFT
-> DPO
-> SWE Agent

Wenn man die Schritte genauer aufteilt, sieht es wie folgt aus.

Stage 0. Vorbereitungsphase  
Stage 1. Datensammlung und Strukturierung  
Stage 2. Entwicklung des ersten RAG‑Chatbots  
Stage 3. Datenkennzeichnung und Datensatzgenerierung  
Stage 4. Modelltraining  
Stage 5. Entwicklung des SWE‑Agents  
Stage 6. Kontinuierliche Verbesserung

Dieser Roadmap liegt die wichtigste Entscheidung zugrunde, dass der erste RAG‑Chatbot nicht als reines Frage‑Antwort‑Werkzeug betrachtet wird. Zunächst soll ein RAG‑Detektor entwickelt werden, der die Rolle eines Experten für die offizielle Godot‑Dokumentation übernimmt, und über diesen Detektor sollen GitHub‑Daten gekennzeichnet und aufbereitet werden, um sie anschließend mit SFT/DPO und einem SWE‑Agenten zu erweitern.

Insbesondere der SWE‑Agent in Stage 5 soll kein einfacher Code‑Generator sein, sondern die folgenden Fähigkeiten besitzen.

Projektanalyse
Notwendige Dateien durchsuchen
Code ändern
Godot-CLI oder Ausführungsergebnis überprüfen
Analyse der Fehlerursache
Patch erstellen

Zugehörige Roadmap:

docs/roadmaps/2026-06-17-godot-llm-roadmap.md

3. RAG‑Entscheiderbasierte Daten‑Generierungsstruktur entwerfen

Heute war eine weitere wichtige Entscheidung, dass „die endgültige Label‑Entscheidung nicht dem LLM überlassen wird“.

Anfangs war es leicht zu denken, dass ein RAG‑Chatbot GitHub‑Code oder Dokumente ansehen und entscheiden könnte, ob es sich um Godot 3/4 handelt. Da das Labeln jedoch die Qualität der Trainingsdaten direkt beeinflusst, ist es riskant, die spontane Entscheidung des LLMs zu übernehmen.

Deshalb haben wir die Struktur wie folgt festgelegt.

LLM ist eine Generierungsunterstützung  
Das Label wird vom System bestimmt  
Das endgültige JSONL wird von der Python‑Pipeline zusammengebaut/validiert

Was das System übernehmen muss:

Symbolextraktion
API-Mapping-DB-Abfrage
Offizielle Dokumenten-Vektorsuche
Stichwortsuche
Label-Prototyp-Suche
Label-Scoring
Confidence-Berechnung
Endgültige JSONL-Zusammenstellung
Validierung

Was ein LLM übernehmen kann:

Entwurf für korrigierten Code erstellen  
Erklärung erstellen  
SFT Fragen/Antworten erstellen  
DPO schlechte Antworten erstellen  
Patch-Entwurf erstellen  
Validierung/Hilfestellung zur Problembeschreibung

Die zu erzeugenden Datensätze wurden ebenfalls in 8 Kategorien zusammengefasst.

version_classification
api_mapping
migration_fix
instruction_sft
dpo_preference
repo_explorer
patch_generation
metadata_verification

Dieses Theorem wurde zum Designprinzip des heute erstellten RAG‑Nachbearbeitungscodes. Insbesondere wird hier auch der Grund für die Trennung von api_mapping, symbol_catalog, keyword_index, search_text erläutert.

Verwandte Notizen:

docs/research-notes/2026-06-17-godot-rag-labeler-data-generation.md

4. MVP‑Ablauf vom RAG‑Detektor zum Qwen‑3.6‑Modell

Der MVP‑Ablauf zwischen dem Godot‑RAG‑Detektor und dem Qwen‑3.6‑Codierungsmodell wurde separat dokumentiert.

Der dokumentierte Ablauf:

godot_docs_full.zip Originaldokumente vorbereiten
-> Erster Chunking basierend auf chunk_docs.py
-> Godot-spezifische Nachbearbeitung
-> Aufbau einer lokalen Suchinfrastruktur
-> GitHub-Daten sammeln und strukturieren
-> RAG-Detektor ausführen
-> Trainingsdatensatz erstellen
-> Qwen 3.6 SFT/DPO

Hier bedeutet die lokale Suchinfrastruktur nicht nur eine einzige Vektor‑DB.

Erforderliche Komponenten:

Vector DB
Keyword Index
Reranker
API Mapping DB
Label Prototype DB

Außerdem sollten GitHub‑Daten nicht nur als einfache Code‑Snippets, sondern als repository‑basierte Struktur eingebunden werden.

Erforderliche Eingabe:

.gd
.tscn
.tres
project.godot
README
repo tree
metadata

Das Ziel des ersten SFT wurde erneut zusammengefasst.

Godot 4 Priorität  
GDScript Grundausgabe  
Godot 3 API Ablehnung  
Godot 3 -> 4 Umwandlungsbegründung erklären

Nachfolgend muss der DPO die Kriterien für gute und schlechte Antworten klarer definieren.

Schlechte Antwort: Antwort, die die Godot 3‑API mischt  
Gute Antwort: Antwort mit reinem Godot 4‑Code und Begründung

Zugehörige Notiz:

docs/research-notes/2026-06-17-godot-rag-to-qwen-coding-model-flow.md

5. v1 Offizielle Dokumentation Chunking

Nach der Zusammenfassung des Designs wurde das eigentliche offizielle Dokumentations‑Datenmaterial in ein Format gebracht, das in RAG eingespeist werden kann.

Das zuerst erstellte Ergebnis befindet sich in der folgenden Datei.

work/godot_rag/chunks/docs_chunks.jsonl

Die offizielle Dokumentation Markdown wurde anhand von Überschriften und Länge in 1.570 Teile aufgeteilt und daraus 9.741 Chunks erstellt.

Ergebnis:

Input pages: 1,570
Output chunks: 9,741
Max chunk chars: 2,800
Overlap chars: 350

Was an v1 gut war:

  • Die gesamte offizielle Dokumentation wurde in JSONL‑Chunks erstellt.
  • JSONL-Parsing war stabil.
  • class_reference, tutorial, migration und ähnliche Grunddokumenttypen wurden klassifiziert.

Problem von v1:

  • Es sind noch viele Resttexte von Sphinx übrig.
  • Es gab zu kurze Rausch‑Chunks.
  • heading, section, method/property Struktur war nicht ausreichend erhalten.
  • Klassenreferenz wurde nicht präzise nach API‑Einheiten getrennt.

v1 war die Phase „Erfassung offizieller Dokumente und grundlegendes Chunking erfolgreich“. Es war der Ausgangspunkt für das Such‑MVP, reichte jedoch nicht für den Label‑Erkenner aus.

6. v2 Nachbearbeitung

Als Nächstes wurde postprocess_chunks.py erstellt und v2‑Chunks generiert.

Datei:

work/godot_rag/postprocess_chunks.py
work/godot_rag/chunks/docs_chunks_v2.jsonl

Was in v2 verarbeitet wurde:

404-Chunk entfernen  
Kurze Rausch-Chunk entfernen  
Sphinx-Resttext entfernen  
Symbole extrahieren  
Klassenname extrahieren  
Abschnitt/Member_Typ/Member_Name verstärken  
Migration-bezogene Chunk anzeigen

Ergebnis:

Input chunks: 9,741
Output chunks: 8,778
Dropped 404 chunks: 3
Dropped short/noise chunks: 960
Migration-related chunks: 695

v2 ist jetzt in einem Zustand, in dem es als MVP für die offizielle Dokumentations‑basierte RAG‑Suche verwendet werden kann. Dennoch war es noch nicht ausreichend, um als endgültiger Label‑Entscheider zu dienen. Insbesondere Änderungen wie move_and_slide, velocity, @export, await waren nicht als unabhängige Bewertungskriterien getrennt.

7. Falsche v3‑Richtung und Rückkehr

Die ursprünglich gedachte v3 war ein Ansatz, bei dem einige zentrale APIs hartkodiert wurden, um den api_focus‑Chunk zu erzeugen.

Beispiel:

KinematicBody2D
CharacterBody2D
move_and_slide
@export
await

Diese Methode kann den Anschein erwecken, die Suchleistung schnell zu steigern. In der Praxis war sie jedoch gefährlich.

Problem:

  • Der Suchalgorithmus kann bei den vom Menschen ausgewählten APIs überangepasst sein.
  • APIs außerhalb der Liste werden schwächer.
  • Einige repräsentative APIs können so aussehen, als würden sie die gesamte Godot-API repräsentieren.
  • Fehlende APIs können später zu einem Beschriftungsfehler führen.

Also haben wir die ursprüngliche v3 zurückgesetzt. Diese Entscheidung war wichtig. Kurzfristig sieht es nach einem Verlust aus, aber wenn man die Qualität des endgültigen Klassifikators bedenkt, war das hartkodierte Focus‑Chunk die falsche Richtung.

8. catalog-basierte v3-Neugestaltung

Nachdem wir zurückgekehrt waren, änderten wir die Richtung.

Neue Prinzipien:

v2 Chunk wird kein einziger verloren.  
Ein neuer Fokus‑Chunk wird nicht willkürlich erstellt.  
symbol/catalog/index/mapping wird automatisch aus der gesamten offiziellen Dokumentation extrahiert.  
Suchverstärkungsinformationen werden als Metadaten angehängt.

Hinzugefügter Code:

work/godot_rag/build_symbol_catalog.py
work/godot_rag/build_keyword_index.py
work/godot_rag/build_api_mapping.py
work/godot_rag/make_chunks_v3.py
work/godot_rag/validate_rag_artifacts.py
work/godot_rag/retrieval_smoke_test.py

Erzeugte Ausgabe:

work/godot_rag/catalog/symbol_catalog.jsonl
work/godot_rag/catalog/keyword_index.json
work/godot_rag/catalog/api_mapping.jsonl
work/godot_rag/chunks/docs_chunks_v3.part-*.jsonl
work/godot_rag/validation/validation_report.json
work/godot_rag/validation/retrieval_smoke_test.json

Die gesamte docs_chunks_v3.jsonl ist etwa 189 MB groß und könnte die GitHub‑Einzeldateigröße‑Beschränkung überschreiten. Deshalb habe ich im Repository geteilte Dateien hochgeladen, die zeilenweise gespeichert werden, und sie bei Bedarf lokal wieder zusammengefügt.

cat work/godot_rag/chunks/docs_chunks_v3.part-*.jsonl \
  > work/godot_rag/chunks/docs_chunks_v3.jsonl

9. v3 Konsistenzprüfung

Bei v3 war das Verhindern von Auslassungen am wichtigsten. Wenn auch nur ein Chunk aus v2 fehlt, kann später die Grundlage in der offiziellen Dokumentation verloren gehen.

Deshalb wurde validate_rag_artifacts.py erstellt.

Prüfungskriterien:

v2 chunk_id set == v3 chunk_id set
no missing or extra v3 chunks
catalog/index/mapping references point to existing chunks
search_text is present
no old hardcoded api_focus fields remain

Validierungsergebnis:

status: pass
v2 chunks: 8,778
v3 chunks: 8,778
v2 unique chunk_id: 8,778
v3 unique chunk_id: 8,778
symbol catalog entries: 134,922
keyword index keys: 192,257
api mapping records: 144
v3 chunks with api mappings: 1,900
v3 migration-related chunks: 2,392

Außerdem wurde vor dem Einbetten ein auf Lexikalisch/Schlüsselwörtern basierender Smoke-Test durchgeführt.

Beispielabfrage:

KinematicBody2D Godot 4 replacement
CharacterBody2D move_and_slide velocity
yield await Godot 4
export var @export Godot 4
onready var @onready Godot 4

Das Ergebnis hat alle 5 Fälle bestanden.

10. Das größte Risiko, das ich heute entdeckt habe

Die wichtigste Erkenntnis von heute war, dass „viel auswählen“ und „vertrauenswürdig beschriften“ unterschiedlich sind.

Wenn man aus der gesamten offiziellen Dokumentation breit auswählt, verbessert sich der Recall. Wird jedoch das Ergebnis alle mit derselben Vertrauenswürdigkeit behandelt, wird der Keyword‑Index verschmutzt.

Zum Beispiel ist das Folgende wahrscheinlich ein tatsächlicher API‑ oder Syntax‑Element.

CharacterBody2D
move_and_slide
FileAccess
@export
await

Im Gegensatz dazu ist es wahrscheinlich, dass das Folgende ein allgemeines Wort im Dokument oder eine Tabellenspalte ist.

Returns
See
Tip
MIT
Software
Type

Tatsächlich haben wir im Verlauf der Überprüfung des Smoke‑Tests ein Problem entdeckt, bei dem reguläre Tabellenspalten wie Type -> EditorSceneFormatImporterFBX2GLTF als API‑Mapping‑Kandidaten erfasst werden können. Dieses Problem wurde behoben, indem Type von den Mapping‑Kandidaten ausgeschlossen wurde.

Die daraus gezogene Schlussfolgerung ist eindeutig.

Eine breite Extraktion ist notwendig.
Aber man darf nicht alles, was breit extrahiert wurde, als vertrauenswürdige Fakten verwenden.

11. v3.1 Umstrukturierung mit getrennter Vertrauenswürdigkeit

Nachdem die oben genannten Risiken festgestellt wurden, wurde entschieden, dass v3 nicht unverändert im endgültigen Label‑Erkennungsmodul verwendet werden darf. Deshalb wurde in v3.1 der Katalog nicht mehr als ein einziges Ganzes verwendet, sondern nach Vertrauenswürdigkeit und Verwendungszweck getrennt.

Die in v3.1 neu eingeführte Struktur:

trusted_api_symbols
syntax_symbols
migration_mappings
mentioned_symbols
candidate_terms
rejected_terms
retrieval_keys
search_text

Die Bedeutung jedes Feldes wurde ebenfalls klar getrennt.

> **Hinweis:** Es wurde kein Markdown-Fragment zum Übersetzen bereitgestellt. Bitte fügen Sie den zu übersetzenden Inhalt ein.

Hinzugefügter Code:

work/godot_rag/build_v31_artifacts.py
work/godot_rag/validate_v31_artifacts.py

Erzeugtes v3.1 Ergebnis:

work/godot_rag/chunks/docs_chunks_v3_1.jsonl
work/godot_rag/chunks/docs_chunks_v3_1.summary.json
work/godot_rag/catalog_v3_1/trusted_api_catalog.jsonl
work/godot_rag/catalog_v3_1/syntax_catalog.jsonl
work/godot_rag/catalog_v3_1/api_mapping.jsonl
work/godot_rag/catalog_v3_1/mention_index.json
work/godot_rag/catalog_v3_1/keyword_index.json
work/godot_rag/catalog_v3_1/v3_1.summary.json
work/godot_rag/validation_v3_1/validation_report.json
work/godot_rag/validation_v3_1/retrieval_smoke_test.json

v3.1 Ergebnis:

Source v2 chunks: 8,778
Output v3.1 chunks: 8,778
Trusted API catalog entries: 26,318
Syntax catalog entries: 68
API mapping records: 144
Mention index keys: 10,292
Keyword keys: 71,543
Validation status: pass
Retrieval smoke tests: 5 / 5 passed

Wichtige Korrekturen wurden ebenfalls vorgenommen.

Im ersten Erstellungsprozess von v3.1 konnte es vorkommen, dass class_name aus den v2-Metadaten unverändert übernommen wurde und falsche Werte wie Tutorials, All, String in den trusted catalog gelangten. Deshalb wurde der kanonische Klassenname anhand der Quell‑URL und des Klassenreferenzpfads neu erstellt. Nach dieser Anpassung wurde das Problem mit der Groß‑/Kleinschreibung, etwa Characterbody2d, sofort zu CharacterBody2D korrigiert.

Eine weitere wichtige Prüfung betraf move_and_slide. Bei der breiten Extraktionsmethode bestand das Risiko, dass falsche trusted‑Einträge wie ProjectSettings.move_and_slide entstanden. In v3.1 wurde die Beförderung zu trusted darauf beschränkt, dass nur Mitglieder, die in den strukturierten Abschnitten der Klassenreferenz gefunden wurden, zugelassen werden, und schließlich blieb der trusted‑Eintrag move_and_slide ausschließlich bei den tatsächlichen Godot‑Klassen, wie nachfolgend gezeigt.

CharacterBody2D.move_and_slide
CharacterBody3D.move_and_slide

Das heißt, was wir heute in v3.1 gemacht haben, war nicht nur das Hinzufügen von Feldern, sondern die Umstellung auf eine Struktur, bei der „bei der Suche breit verwendet wird, aber bei der Label‑Entscheidung nur enge und verlässliche Belege verwendet werden“.

12. v3.1 Konsistenzprüfung

In v3.1 war das Auslassen besonders gefährlich. Wenn auch nur ein Chunk von den 8.778 Chunks in v2 fehlt, kann die offizielle Dokumentationsgrundlage verloren gehen.

Validierungskriterien:

v2 chunk_id set == v3.1 chunk_id set
v3.1 unique chunk_id count == 8,778
doc_type Verteilung beibehalten
legacy gemischte Felder entfernen
trusted/syntax/migration Katalogreferenz-Integrität prüfen
search_text Vorhandensein prüfen

Validierungsergebnis:

status: pass
errors: 0
warnings: 0
v2 chunks: 8,778
v3.1 chunks: 8,778

Suchtest erneut durchgeführt.

KinematicBody2D Godot 4 replacement
CharacterBody2D move_and_slide velocity
yield await Godot 4
export var @export Godot 4
onready var @onready Godot 4

Alle fünf Ergebnisse haben bestanden. Diese Phase bedeutet nicht, dass der endgültige Labeler fertig ist, sondern dass die v3.1‑Struktur so fehlerfrei ist, dass sie zumindest in einen MVP‑Vektor/Keyword‑Index übergehen kann.

13. GitHub‑Integration und Dokumentationsaufbereitung

Heute habe ich nicht nur Code‑ und Datenausgaben erstellt, sondern auch die GitHub‑Integration organisiert.

Erledigte Aufgaben:

remote Einstellung → Remote‑Einstellung
Großdatei‑v3‑Aufteilung → Großdatei‑v3‑Aufteilung
Arbeitszweig push → Arbeitszweig pushen
Remote‑main und lokaler Verlauf zusammenführen
main push → main pushen  
Dokumentverzeichnis bereinigen → Dokumentverzeichnis bereinigen

docs_chunks_v3.jsonl ist etwa 189 MB groß, daher könnte das Hochladen als einzelne Datei die GitHub‑Einzeldateigrößenbeschränkung überschreiten. Deshalb wurde es in docs_chunks_v3.part-000.jsonl, docs_chunks_v3.part-001.jsonl und docs_chunks_v3.part-002.jsonl aufgeteilt.

Außerdem wurde das Retrospektive‑Verzeichnis zunächst im Root‑Verzeichnis retrospectives/ angelegt, passte jedoch nicht zur bestehenden Repository‑Struktur. Daher wurde die Dokumentenstruktur wie folgt organisiert.

docs/research-notes/   Entwurfsnotiz
docs/roadmaps/         Gesamter Fahrplan
docs/retrospectives/   Rückblick nach Datum
work/godot_rag/        RAG-Code und Ergebnisse
outputs/godot_docs_full/ Ergebnisse des offiziellen Dokumenten-Crawlings

Zusätzlich habe ich docs/README.md erstellt, um die Rolle des Dokumentenverzeichnisses zu klären.

14. Git author/email Bereinigung

Wie heute im README festgehalten, habe ich auch das Problem mit der GitHub‑Grasanzeige geklärt.

Festgestelltes Problem:

Die author/committer E-Mails im main-Verlauf sind gemischt  
Lokale Host-E-Mail  
Naver-E-Mail  
GitHub-Noreply-E-Mail

Bearbeitete Richtung:

Globale Git‑Einstellungen zu yyeongjin <appsky1888@gmail.com> ändern
main Historie author/committer Vereinheitlichung
Remote-Rendering
Backup-Branch vor dem Neuschreiben aufbewahren

Backup‑Zweig:

backup/before-author-email-rewrite-2026-06-17

Dieser Vorgang ist nicht direkt mit RAG selbst verbunden, war aber eine der wichtigen Aufräumarbeiten des Tages. Es war eine Grundlage, damit spätere Aufzeichnungen und Commits korrekt im GitHub‑Profil erscheinen.

15. Heute erstellte/aufgeräumte Dokumente

Hauptdokumente, die heute erstellt oder aufgeräumt wurden:

docs/research-notes/2026-06-17-swe-agent-trajectory-keywords.md
docs/research-notes/2026-06-17-godot-rag-labeler-data-generation.md
docs/research-notes/2026-06-17-godot-rag-to-qwen-coding-model-flow.md
docs/roadmaps/2026-06-17-godot-llm-roadmap.md
docs/retrospectives/2026-06-17-godot-rag-judge.md
docs/README.md

Ich habe dem README auch das Entwicklungstagebuch vom 17. Juni und den Abschnitt zur Vorbereitung von RAG‑Daten hinzugefügt.

16. Aktuelle Schlussfolgerung

Der aktuelle Stand kann wie folgt zusammengefasst werden.

Richtung:
Es muss nicht das Godot Q&A‑Modell, sondern der Godot SWE Agent verwendet werden.

Daten:
Das offizielle Dokument RAG muss als Klassifikator für die Erstellung von Trainingsdaten dienen.

Label:
Nicht das LLM, sondern die Python‑Pipeline muss entscheiden.

RAG:
v2 ist ein sicheres Basis‑Chunk‑Set.  
v3 ist ein breit extrahiertes Zwischenergebnis des Katalogs.  
v3.1 ist das derzeit empfohlene RAG‑Ergebnis, das sogar eine Vertrauenswürdigkeitsseparation anwendet.

Risiko:
Extrahierte Symbole dürfen nicht alle mit derselben Vertrauenswürdigkeit verwendet werden.

Heute war die Arbeit nicht nur das Erstellen einiger Dateien, sondern ein Tag, an dem wir mehrere Richtungen, die leicht in die falsche Richtung führen konnten, umgekehrt haben. Besonders wichtig waren die Entscheidung, den hardcodierten API‑Focus‑Chunk zurückzusetzen, die Entdeckung des Rausch‑Risikos von broad v3 und die Trennung von trusted/syntax/migration/mention/candidate/rejected in v3.1.

17. Nächste Aufgaben

Die nächsten Aufgaben sind nicht sofort das Labeln von GitHub‑Code.

Zuerst zu erledigen:

  1. Embeddings basierend auf search_text in docs_chunks_v3_1.jsonl erzeugen
  2. Hybrid‑Retrieval‑Test mit Kombination aus Vektor‑Suche und Keyword‑Suche
  3. Entwurf einer Python‑Pipeline zur Bestimmung von Labels basierend auf trusted_api_symbols, syntax_symbols, migration_mappings
  4. Definition des Eingabe‑Formats für strukturierte GitHub‑Repo‑Daten
  5. Entwurf eines repo‑weiten Entscheidungs‑Flows, der .gd, .tscn, .tres, project.godot und README gemeinsam betrachtet
  6. Verknüpfung des RAG‑Entscheiders mit einer Pipeline zur Erstellung eines 8‑teiligen JSONL‑Datensatzes
  7. Sobald ein Remote‑LLM‑Endpoint bereitsteht, Verbindung zur Unterstützung bei Code‑/Erklärungs‑/SFT‑/DPO‑Kandidaten‑Generierung
  8. Anschließend Erweiterung durch SFT/DPO auf Basis von Qwen und das Training von SWE‑Agent‑Trajektorien

Das ist die abschließende Lehre des Tages.

Es ist wichtiger, die gesammelten Kenntnisse nach ihrer Vertrauenswürdigkeit zu trennen, als viele Dokumente zu sammeln.