Le round 1 de l’expérience de play-training est terminé.
La question était simple :
Peut-on inculquer un goût en ingénierie à un modèle de code sans flinguer sa capacité à résoudre des problèmes complexes ?
Le run d’entraînement
On a entraîné Qwen sur un corpus axé Go, construit à partir de trajectoires de jeu, de critique, de révision, d’écriture et de résolution.
Le run final était étonnamment petit :
- 92 défis éligibles
- 536 tentatives
- 349 conversations de résolution
- 263 conversations d’écriture
- 1 epoch
- 44 étapes d’entraînement
- Export GGUF Q4_K_M de 21,7 Go
Justesse sur le benchmark de promotion
Ensuite, on a lancé un benchmark de promotion indépendant de 120 tâches, comparant le modèle de base exact et le SFT précédent.
Justesse sur les tâches difficiles :
- Nouveau candidat : 71/120
- Base exacte : 70/120
- SFT précédent : 73/120
Bilan : globalement la même tranche de capacité. Le nouveau modèle n’a pas battu le SFT précédent sur la justesse, donc on l’a gardé, mais sans le promouvoir.
Évaluation en aveugle du goût en ingénierie
Le résultat le plus intéressant vient de l’évaluation en aveugle du goût en ingénierie.
Le critique ne pouvait comparer que des tâches où au moins deux modèles produisaient des implémentations distinctes et objectivement correctes.
Sur 72 comparaisons valides :
- Nouveau candidat préféré : 28
- SFT précédent : 23
- Base exacte : 18
- Pas de préférence : 3
Sur les 47 comparaisons triples nettes :
- Candidat : 18
- SFT précédent : 17
- Base : 11
- Pas de préférence : 1
Ce que disent les résultats
L’interprétation rigoureuse est la suivante :
À condition de produire une solution correcte, le modèle fraîchement entraîné a été plus souvent préféré par le critique technique en aveugle que le modèle de base.
Ce n’est pas encore la preuve d’un jugement technique globalement supérieur. Une seule graine, une seule famille de critiques, échantillon modeste.
Mais c’est la preuve que la procédure d’entraînement peut modifier la MANIÈRE dont le modèle conçoit, sans changer substantiellement sa CAPACITÉ à résoudre le problème.
Et c’est exactement ce qu’on cherchait à tester.
Temps d’expérience actif total : environ 71 heures sur un DGX Spark.
Le run de réplication
L’étape suivante, c’est de la science délibérément ennuyeuse : reproduire exactement le run d’entraînement avec une graine différente.
Tous les paramètres expérimentaux restent identiques, à part ça. Base, jeu de données, recette et benchmark ne bougent pas.
Si le même schéma réapparaît, là, ça devient beaucoup plus intéressant.
Après ça, on testera si le modèle enfant peut aider à construire son propre prochain curriculum.