Re‑organisé le rôle de docs_chunks, api_mapping et label_prototypes dans le pipeline d’analyse du code source de Godot
docs_chunks est utilisé dans le flux de génération de descriptions de code. On recherche les fragments de documentation officielle à partir des morceaux de code/AST et des prompts, on élimine les preuves non pertinentes, puis on crée le JSONL de description.
api_mapping stocke les changements de noms de fonctions, de classes et de symboles entre Godot 3 et Godot 4.
label_prototypes conserve les modèles de transformation lorsqu’il ne s’agit pas seulement d’un changement de nom, mais que la façon d’utiliser la fonction, la composition des arguments ou le schéma d’appel sont entièrement modifiés.
Structuré l’analyse de projets GitHub ou du système de fichiers local par morceaux de code/AST, puis l’appel à un Retriever suivi d’un appel à la demande de Qwen 3.6
Le Markdown de la documentation officielle est classé selon son type de contenu : texte descriptif → docs_chunks, changements de noms/symboles → api_mapping, changements de mode d’utilisation/patterns d’appel → label_prototypes. Chaque catégorie est enregistrée en JSONL.
Les résultats de recherche du Retriever, la validation par LLM et le passage du Validateur sont stockés dans un flux JSONL/score DB.
Les colonnes, les méthodes d’agrégation et les libellés de classification de la base de scores ne sont pas encore définis ; pour l’instant, elle ne sert qu’à stocker les résultats de jugement avant la classification du système de fichiers.
À terme, le système de fichiers classifié servira de source pour concevoir le SFT et le DPO.
En documentant la méthode de classification LLM, nous avons découvert que, contrairement à la demande initiale, le code généré par le LLM ne transmettait que les 3000 premiers caractères du Markdown au lieu du document complet ; nous avons corrigé cela pour transmettre le Markdown entier.
Cette tâche a rappelé que la documentation n’est pas seulement un enregistrement, mais aussi un processus de vérification du comportement réel du code.
Lors de la conversion Markdown → JSONL, le serveur RunPod s’est arrêté de façon inattendue ; en relançant l’application Streamlit, nous avons observé que l’état précédent n’était pas réinitialisé et la conversion a repris là où elle s’était arrêtée.
Après le redémarrage, le fichier en cours de traitement est revenu à l’état pending ; en relançant, les résultats de classification déjà obtenus sont réutilisés et le traitement reprend à partir du même fichier.
Pour les conversions longues, il est nécessaire de configurer une alerte précoce indiquant l’arrêt ou l’indisponibilité du serveur RunPod.