Architecture de notation d'analyse du code source Godot

Date de rédaction : 25 juin 2026

Objectif

Utiliser le RAG de la documentation officielle de Godot pour classer le code source GitHub par projet, puis organiser le flux menant à la génération de données SFT/DPO.

Le point central de cette organisation est de considérer docs_chunks, api_mapping et label_prototypes comme des cibles de classification Markdown → JSONL de la documentation officielle. Selon la nature du document, les morceaux explicatifs vont dans docs_chunks, les changements de noms de fonctions/classes/symboles dans api_mapping, et les modifications de mode d’utilisation des fonctions, de la composition des arguments ou des schémas d’appel dans label_prototypes.

Conclusion actuelle

Les trois tables essentielles à préparer lors de la phase initiale de collecte de la documentation officielle sont les suivantes.

Unité d'analyse finale

L’entrée est un projet GitHub ou un répertoire de projet local.

L’analyseur parcourt le système de fichiers et découpe les fichiers liés à Godot en unités AST ou fragments de code.

Cibles initiales :

Flux d’appel LLM à la demande

Le LLM n’est pas maintenu en permanence, mais appelé à la demande pour chaque fragment AST/code nécessaire.

Chaque fragment AST est transmis au LLM avec les justifications suivantes.

AST/code chunk
+ Résultats de recherche JSONL de la documentation officielle requise
+ Schéma JSONL de sortie
+ Informations d'identification du projet/fichier

Le schéma de réponse LLM et les colonnes de stockage DB du score ne sont pas encore finalisés. Dans ce document, on ne consigne que quelles tables sont recherchées dans quel flux, et comment le résultat est utilisé pour la classification du système de fichiers.

Flux de données de génération de description du code

Dans la génération de la description du code, docs_chunks est la preuve principale.

Flux:

1. L'utilisateur saisit « Quel est le sens de ceci ? » ainsi que le code source.

2. L'AST Parser découpe le code en fragments.

3. Le Retriever recherche la documentation pertinente dans docs_chunks.

4. Qwen 3.6 vérifie si le prompt, le fragment de code source et les références de recherche sont liés entre eux.

5. Les résultats de recherche non pertinents sont rejetés.

6. Les références pertinentes et le fragment de code sont renvoyés à Qwen 3.6 pour générer un JSONL d'explication.

7. Le Validator valide la réponse.

8. Enregistrer les résultats vérifiés dans la base de données des scores.

9. Classifier le système de fichiers à partir des résultats de la base de données des scores.

Godot 3 -> Godot 4 conversion des noms de fonctions

Dans la migration, api_mapping est la preuve principale.

Flux :

1. L'utilisateur saisit « Ce besoin de conversion ? » et le code source.
2. L'AST Parser extrait les symboles candidats de l'API Godot.
3. Le Retriever recherche dans api_mapping l'API source, l'API cible et le type de changement.
4. Qwen 3.6 vérifie si le résultat de la recherche est réellement lié à cet extrait de code.
5. Les mappings non pertinents sont abandonnés.
6. Seuls les mappings pertinents sont utilisés pour générer le JSONL de migration Godot 3 → 4.
7. Le Validator valide la réponse de conversion.
8. Le résultat validé est stocké dans la base de données de scores.
9. Le résultat de la base de données de scores classe le système de fichiers.

Godot 3 -> Godot 4 flux de conversion des modèles d'utilisation

Dans la conversion des modèles d'utilisation, label_prototypes est la preuve principale.

Flux :

1. L'utilisateur saisit « Ce besoin de conversion ? » et le code source.
2. L'AST Parser extrait les appels de fonctions, la composition des arguments et les modèles d'appel candidats.
3. Le Retriever recherche dans label_prototypes les bases de conversion du mode d'utilisation / des arguments / du modèle d'appel.
4. Qwen 3.6 vérifie si le résultat de la recherche est réellement lié à cet extrait de code.
5. Les prototypes non pertinents sont abandonnés.
6. Seuls les prototypes pertinents sont utilisés pour générer le JSONL de conversion des modèles d'utilisation Godot 3 → 4.
7. Le Validator valide la réponse de conversion.
8. Le résultat validé est stocké dans la base de données de scores.
9. Le résultat de la base de données de scores classe le système de fichiers.

Score DB

Les résultats de recherche du Retriever par fragment AST, les résultats de validation LLM et les résultats de passage du Validator sont finalement enregistrés dans la base de données de scores.

La base de données de scores n’est pas la source des données d’apprentissage, mais un dépôt de résultats de jugement utilisé pour classer le système de fichiers. Elle consigne les résultats du Retriever/LLM/Validator issus du processus d’analyse du code source.

• docs_chunks résultats de recherche : résultat de la vérification de la pertinence d’une référence de documentation officielle par rapport au code réel dans une demande d’explication du code
• api_mapping résultats de recherche : résultat de la vérification de la pertinence de la conversion de noms de fonctions/symboles de Godot 3 → Godot 4 par rapport au code réel
• label_prototypes résultats de recherche : résultat de la vérification de la pertinence de la conversion du mode d’utilisation des fonctions, de la composition des arguments et des modèles d’appel par rapport au code réel

Les colonnes, les méthodes d’agrégation et les étiquettes de classification de la base de données de scores ne sont pas encore définies. Dans ce document, la base de scores est uniquement fixée comme « un dépôt qui rassemble les résultats de jugement avant classification ».

Classification finale du système de fichiers :

project source
  -> AST/code chunks
  -> official docs JSONL retrieval
  -> on-demand LLM verification
  -> score DB
  -> classified filesystem

Conception SFT et DPO

Les détails de la conception de SFT et DPO ne sont pas encore définis. Ce qui est confirmé pour l’instant, c’est que la base de données de scores n’est pas la source des données d’apprentissage. Nous classerons d’abord le système de fichiers, puis, sur la base du système de fichiers classifié, nous créerons les sources pour concevoir SFT et DPO.

Critères de sécurité pour le téléchargement sur Git

Dans cette documentation, nous n’inclurons pas l’interface Web UI, les scripts de conversion locaux, les scripts d’analyse AST, les clés API, les fichiers JSONL générés, ni le code source des tests.

Autorisé à télécharger :

• Documentation d’architecture
• Images de diagrammes de flux
• Textes de rétrospective/feuille de route pouvant être rendus publics

Interdit de télécharger :

• Code d’application Web Streamlit
• Script d’expérimentation de conversion Markdown → JSONL
• Script d’expérimentation d’analyse Retriever/AST
• Clé API, point de terminaison, .env
• Archive zip contenant l’ensemble du Markdown original collecté
• Résultats d’analyse AST/segment de code
• Fichiers intermédiaires JSONL
• Source d’un projet Godot externe cloné à des fins de test