2026-06-14 Rétrospective

Pensées dans le bus qui monte à Séoul

Aujourd'hui, dans le bus qui monte à Séoul, j'ai repensé le pipeline de jeu de données/RAG Godot 4 que j'avais conçu la dernière fois. Le 12 juin, j'avais envisagé de crawler la documentation officielle, de collecter les projets Godot sur GitHub, puis de placer un chatbot RAG en façade pour déterminer si le projet était Godot 3 ou 4 et générer des données d'instruction.

Cependant, en y repensant aujourd'hui, j'ai réalisé qu'il restait de nombreuses questions à résoudre pour que cette architecture fonctionne réellement. En particulier, l'écart entre « j'ai rassemblé les documents » et « le modèle utilise bien ces documents » est plus grand que je ne le pensais.

Première question : le chatbot RAG peut‑il gérer tout le contexte ?

Au départ, je pensais que si je crawlais la documentation officielle de Godot pour créer un chatbot RAG, je pourrais l'utiliser pour classer ou valider les projets GitHub collectés. Mais en imaginant le scénario où l’on scrape les projets GitHub, on les convertit en md, jsonl et on les injecte d’un coup dans le chatbot, une interrogation apparaît.

Le modèle peut‑il absorber tout ce contexte d’entrée ?

Même pour un seul projet Godot, il y a le README, la structure des répertoires, plusieurs fichiers .gd, des scènes, des chemins de ressources, etc. Si l’on ajoute les fragments de documentation officielle récupérés par RAG, l’entrée peut rapidement devenir volumineuse. Le simple fait que les documents crawlés existent ne garantit pas que le modèle puisse lire de façon fiable l’ensemble du projet et les documents associés à chaque requête.

En fin de compte, créer un chatbot RAG ne signifie pas insérer le document en entier, mais concevoir une structure de recherche/filtrage qui décide quels fragments de document récupérer pour chaque question. Si cette partie est bâclée, le modèle risque de manquer des fichiers importants ou de lire des documents inutiles, perdant ainsi le contexte du projet réellement nécessaire.

Deuxième question : une seule réponse de code suffit‑elle à chaque question ?

La deuxième interrogation portait sur la forme du jeu de données d’instruction. Par exemple, pour la question « Crée‑moi une carte », la réponse ne se résume pas forcément à un seul bloc de code.

Pour qu’un LLM génère réellement une réponse, il doit passer par plusieurs étapes : examiner la structure du projet, identifier les scènes et scripts présents, vérifier les assets disponibles, lire le style de code existant, s’assurer de la conformité à la syntaxe de Godot 4, puis décider quels fichiers et quel code modifier.

Ainsi, la question « Crée‑moi une carte » apparaît comme une seule requête en surface, mais implique en interne plusieurs couches de raisonnement. Si l’on ne conserve dans les données d’entraînement que le code final, on se demande si le modèle pourra apprendre le processus de jugement intermédiaire.

Les données de réponse correcte ne devraient pas contenir uniquement le code complet, mais aussi indiquer quels fichiers lire, quelles informations ont servi de base au jugement, pourquoi une API particulière a été choisie, etc. Si l’on veut que le modèle se comporte comme un agent de codage, il peut être plus approprié de conserver le flux « question → exploration → jugement → modification → validation » plutôt que simplement « question → réponse ».

Troisième question : le poids du Python ne réapparaîtra‑t‑il pas lors du traitement par morceaux ?

La troisième interrogation concernait le biais linguistique. Même si l’on donne le prompt « Crée‑moi une carte avec Godot 4 », le modèle, en découpant le projet ou la documentation en morceaux, pourrait accorder davantage de poids aux patterns de code Python ou aux résolutions de problèmes à la Python.

Les modèles de codage généraux ont très probablement été entraînés beaucoup plus intensivement sur du Python. Ainsi, simplement préfixer « Godot » ne suffit peut‑être pas. Si les morceaux récupérés ne contiennent pas un contexte Godot 4 suffisamment fort, ou si le raisonnement intermédiaire fait appel à des patterns de codage généraux, le modèle pourrait dériver vers une réponse de type Python.

Il faut donc aller au-delà du simple « Écris‑le avec Godot 4 ». Il faut renforcer le contexte Godot 4 dès le prompt et la phase de pré‑traitement des données. Par exemple, ajouter un tag dédié à Godot 4 dans les données d’entrée, filtrer plus strictement les données contenant du code Godot 3 ou d’autres langages, ou injecter de façon récurrente la contrainte « Cette tâche suit la syntaxe GDScript de Godot 4 » avant la génération de la réponse.

Synthèse du jour

L’idée principale d’aujourd’hui est que le RAG ou le simple crawling ne sont pas des solutions en soi. Ce qui est plus important que de collecter beaucoup de documents, c’est de concevoir comment le modèle lira quel contexte et quel jugement il devra faire lors d’une requête réelle.

La structure actuelle doit être découpée davantage :

• Au lieu d’insérer tout le projet d’un coup, il faut créer une architecture searchable basée sur les fichiers/rôles/dépendances.
• Il faut examiner si les données d’instruction doivent inclure non seulement le code final, mais aussi le processus d’exploration et de jugement.
• Il faut concevoir des prompts, tags, filtres et critères de données préférées plus robustes afin que le contexte Godot 4 ne soit pas dilué pendant le raisonnement.

En fin de compte, créer un « modèle de codage Godot 4 » ne se résume pas à rassembler uniquement du code Godot 4. Il faut refléter dans les données comment le modèle parcourt le projet, comment il identifie qu’il s’agit de Godot 4, et comment il sélectionne la meilleure réponse.

Rétrospective

Aujourd’hui, je n’ai pas beaucoup codé, mais j’ai revu les lacunes de la conception précédente. En réfléchissant dans le bus, j’ai remarqué des problèmes que j’avais manqués devant mon bureau. Dire que l’on veut créer un chatbot RAG est facile, mais en pratique, les unités de recherche, la taille du contexte, la structure des données question/réponse et le contrôle du biais linguistique sont tous interconnectés.

Il n’y a pas encore de réponse. Mais le fait que ces questions surgissent est un bon signe. En consignant ces interrogations maintenant, je disposerai d’un repère pour les vérifier plus tard lors de la mise en œuvre du pipeline.

Ensuite, je devrai préciser comment découper le contexte du projet, jusqu’où inclure le processus de raisonnement dans les données d’instruction, et quelles règles de pré‑traitement appliquer pour maintenir fortement le contexte Godot 4.