Dans le pipeline d’analyse du code source de Godot, j’ai réorganisé le rôle de docs_chunks, api_mapping et label_prototypes
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 d’AST/code et des invites, on élimine les preuves non pertinentes, puis on crée un 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 d’une modification complète du mode d’utilisation, de la composition des arguments ou du schéma d’appel.
J’ai structuré le processus d’analyse d’un projet GitHub ou du système de fichiers local par morceaux d’AST/code, en appelant le Retriever nécessaire puis en invoquant Qwen 3.6 à la demande
Le Markdown de la documentation officielle est classé selon sa nature : le texte explicatif va dans docs_chunks, les changements de noms/symboles dans api_mapping, les changements de mode d’utilisation ou de schéma d’appel dans 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 étiquettes du score DB ne sont pas encore définies ; pour l’instant, il ne sert que de dépôt de résultats pré‑classification avant la catégorisation 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, j’ai constaté que, contrairement à la demande initiale, le LLM ne transmettait que les 3000 premiers caractères du Markdown. J’ai corrigé cela pour envoyer le Markdown complet.
Cette tâche a rappelé que la documentation n’est pas seulement un enregistrement, mais aussi une 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, j’ai observé que l’état précédent n’était pas réinitialisé et que la conversion reprenait 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 existants sont réutilisés et le traitement reprend à partir du même fichier.
Pour les longues conversions, il est nécessaire de configurer une alerte permettant de détecter rapidement l’arrêt ou l’indisponibilité du serveur RunPod.