2026-06-17 Mémoire sur la structure de génération de données basée sur le détecteur Godot RAG

Image de la structure

Idée principale

L’idée centrale de cette structure est de ne pas confier la décision finale d’étiquetage au LLM. Le LLM joue un rôle d’assistance à la génération, tel que la production de code de correction, d’explications, de questions/réponses SFT, de mauvaises réponses DPO, ou d’ébauches de correctifs, tandis que l’assemblage et la validation du label réel ainsi que du JSONL final sont déterminés par le pipeline du système local.

En résumé, voici les principes.

LLM est une assistance à la génération  
Les étiquettes sont déterminées par le système  
Le JSONL final est assemblé/vérifié par le pipeline

Flux global

Document préparatoire
-> Construction de la base de données locale
-> Saisie des données sources GitHub
-> Extraction des symboles
-> Recherche de règles/vecteurs/mots-clés
-> Attribution de scores aux étiquettes et décision
-> Assistance à la génération LLM
-> Génération du JSONL final

Cette structure est un brouillon visant à créer les données de classification Godot 3/4, mappage d'API, correction de migration, instruction SFT, préférence DPO, explorateur de dépôt, génération de correctifs et vérification des métadonnées dans un seul pipeline.

1. Préparation de la documentation

Collecter et nettoyer la documentation officielle de Godot lors de la phase hors ligne.

• Collecte de la documentation officielle de Godot
• Suppression des phrases inutiles
• Classification du type de document
• Analyse basée sur la structure
• Génération de fragments de documentation
• Construction d'embeddings et d'index

Livrables de base générés :

docs_chunks.jsonl

2. Trois bases de données essentielles construites

Base de données de mappage API

Elle stocke les relations de changement entre l’API Godot 3 et l’API Godot 4.

Exemple :

KinematicBody2D -> CharacterBody2D
yield -> await
export var -> @export
move_and_slide(v) -> move_and_slide()

Fichier enregistré:

api_mapping.jsonl

Documentation officielle DB vectorielle

Divisez les documents en morceaux et créez une base de données vectorielle pour la recherche de références.

Utilisations :

• Recherche de morceaux de documentation officielle pertinents
• Fournir des références de transformation
• Expliquer les raisons des changements d'API
• Réduire les hallucinations

Prototype de DB d'étiquettes

Stockez un prototype pour la recherche de similarité avec les candidats d'étiquettes.

Exemple d'étiquette :

godot3_code
godot4_code
mixed_code
broken_code

Fichier enregistré:

label_prototypes.jsonl

3. Recherche/détermination des étiquettes

Lorsque les données sources collectées sur GitHub arrivent, le système analyse d'abord le code et la documentation.

Exemple d'entrée:

repo: owner/repo
file_path: scripts/Player.gd
content: ...
repo_tree: ...

Le système extrait les symboles.

Exemple :

KinematicBody2D
move_and_slide(velocity)
export var
yield

Ensuite, effectuez les recherches suivantes.

• Rechercher dans la base de données de mappage API
• Rechercher dans la base de données vectorielle de la documentation officielle
• Rechercher dans la base de données de prototypes d'étiquettes

Le label final est déterminé par le scoring du système, pas par le LLM.

Exemple :

label: godot3
confidence: 0.93
bad_apis:
  - KinematicBody2D
  - move_and_slide(v)
  - export var
replacement_apis:
  - CharacterBody2D
  - move_and_slide()
  - @export

4. Assistance à la génération LLM

LLM ne détermine pas directement les étiquettes, mais aide la tâche de génération en recevant comme entrée les étiquettes et les justifications décidées par le système.

Tâches de génération possibles :

• Génération de code corrigé
• Génération d’explications/justifications
• Génération de questions/réponses SFT
• Génération de mauvaises réponses DPO
• Génération de réponses d’exploration de fichiers
• Assistance à la génération de correctifs
• Validation/analyse des problèmes

Les points importants sont les suivants.

Le résultat de la génération LLM est un brouillon.  
Les étiquettes, le schéma final, la confiance et le statut de validation sont gérés par le système.

5. Génération finale de JSONL

Le pipeline assemble les résultats du système et les résultats générés par le LLM en un seul objet JSON.

Lors de l'étape de validation, les points suivants sont vérifiés :

• Présence des champs obligatoires
• Cohérence des libellés
• Absence d'API incorrectes résiduelles
• Recalcul de la confiance
• Liaison entre les références du document et la sortie

8 jeux de données générés

1. Données de classification de version

Fichier:

version_classification.jsonl

Contenu :

• Classification Godot 3/4/mixed/broken
• Détermination valid_for_godot4
• Extraction des bad_apis

2. Données de mappage API

Fichier :

api_mapping.jsonl

Contenu :

• old_api -> new_api mappage
• change_type, category etc

3. Données de réponse de conversion/modification

Fichier :

migration_fix.jsonl

Contenu :

• code avant/après
• raison du changement
• liste des paramètres

4. Données SFT Questions/Réponses

Fichier:

instruction_sft.jsonl

Contenu :

• instruction/input/output
• Échantillons de divers modèles

5. Données de préférence DPO

Fichier :

dpo_preference.jsonl

Contenu:

• chosen
• rejected
• Raison/Condition

6. Données du Repo Explorer

Fichier:

repo_explorer.jsonl

Contenu :

• Prévision des fichiers à lire pour la résolution de tâches/erreurs
• Raison de la lecture

7. Données de correctif

Fichier :

patch_generation.jsonl

Contenu :

• before/after
• unified diff / patch
• Raison d'application

8. Informations méta/validation

Fichier :

metadata_verification.jsonl

• confiance
• score
• justification
• ID du fragment du document source
• Informations qualité/risque

Résumé du flux d'exécution

Données source GitHub  
-> Extraction de symboles  
-> Recherche de règles/DB  
-> Évaluation des labels  
-> Assistance à la génération LLM  
-> Assemblage et sauvegarde du JSON final

Principes fondamentaux

• L'étiquette est déterminée par le système.
• Le LLM ne joue qu'un rôle d'assistance à la génération.
• Le JSONL final est assemblé et validé par le pipeline.
• Les informations de document de référence, le score, la confiance et la source sont enregistrées ensemble.
• Vérifiez absolument qu'aucune API Godot 3 incorrecte ne subsiste.