ecom.tech compare le fine-tuning évolutif de Qwen3-4B au SFT et au GRPO pour des tests Kotlin

L'équipe d'ecom.tech a cherché à savoir si l'on pouvait amener un petit modèle, Qwen3-4B-Instruct, à écrire des tests unitaires utiles pour un backend Kotlin non pas avec le SFT habituel, mais avec un algorithme évolutif, Evolution Strategies. Le résultat pratique est solide : sur la génération de tests, cette approche a battu à la fois le fine-tuning supervisé (SFT) et le GRPO en reward final et en coverage. Mais en parallèle du gain de spécialisation, les chercheurs ont constaté un revers : plus le modèle était adapté à la tâche étroite, plus il perdait de capacités générales.

L'expérience répondait à un besoin très concret. Dans son service de génération de code, l'équipe butait sur un problème classique : le LLM produit d'abord un code fonctionnel, puis écrit des tests qui paraissent plausibles mais ne respectent pas les conventions internes et ne vérifient pas toujours la logique métier réellement importante. Pour évaluer si le fine-tuning pouvait y remédier, les chercheurs ont constitué un jeu de 1500 exemples : 1300 pour l'entraînement et 200 pour le test. En entrée, le modèle recevait non seulement la classe à tester, mais aussi tout son contexte, rassemblé par un agent basé sur qwen-code, et devait produire un fichier de tests unitaires prêt à l'emploi.

Deux métriques ont servi à l'évaluation. La première est Coverage, non pas au sens habituel de couverture de lignes, mais comme couverture fonctionnelle : dans quelle mesure le test généré touche la même fonctionnalité publique que le test de référence. La seconde est CodeBLEU, une métrique qui regarde non seulement la correspondance des tokens, mais aussi la syntaxe et le flux de données du code.

Comme le CodeBLEU standard ne prend pas en charge Kotlin, l'équipe a dû ajouter ce support séparément via tree-sitter-kotlin et un jeu de mots-clés maison. La fonction de reward est restée simple : un poids de 0,6 pour CodeBLEU et de 0,4 pour Coverage, afin de prendre en compte à la fois la forme du code et son utilité pratique.

Dans cette expérience, Evolution Strategies fonctionnait ainsi : au lieu d'une mise à jour par gradient, l'équipe prenait environ 30 copies perturbées du modèle de base en ajoutant un bruit gaussien aux poids, faisait générer à chaque copie une réponse en mode déterministe, puis l'évaluait avec la récompense. Les poids de base étaient ensuite déplacés vers les modifications ayant donné le meilleur résultat. Cette approche se parallélise plus facilement, n'oblige pas à stocker de lourds gradients et, selon les auteurs, est moins sujette au reward hacking.

Le projet ouvert Evolution Strategies at Scale, accéléré par vLLM, a servi de base, et le modèle a été entraîné sur un cluster de 8 H100. Un passage complet sur le jeu de données à chaque itération étant coûteux, l'équipe a introduit du batching : 32 exemples tirés au hasard à chaque fois.

L'expérience a donné un gain net dès 500 itérations. À la fin de l'entraînement, CodeBLEU avait progressé de 21,3 % par rapport au modèle de base et Coverage de 18,6 %. Le meilleur résultat d'ES atteint un coverage de 0,7381 et le reward final le plus élevé ; sur les métriques retenues, il a devancé non seulement le SFT et le GRPO, mais même le bien plus gros Qwen3-Coder-480B.

Le tableau des méthodes concurrentes est parlant : le SFT produisait des tests syntaxiquement propres mais touchait peu la bonne logique, tandis que le GRPO, dans cette configuration, s'est dégradé sur les deux métriques. Pour une tâche d'ingénierie étroite, la conclusion est simple : le fine-tuning évolutif peut être un outil efficace, même pour un modèle relativement petit.

Vient ensuite la partie moins agréable. À la lumière de travaux récents sur l'oubli catastrophique, l'équipe a vérifié séparément ce qu'il advient des connaissances générales du modèle affiné. La version ES de Qwen3-4B-Instruct a été testée sur GPQA, un benchmark scientifique difficile.

L'accuracy a baissé en moyenne de 2,1 % en zero-shot et de 5,3 % en five-shot chain-of-thought. La capacité à exploiter les indices du contexte a particulièrement fléchi : le bénéfice des exemples few-shot a reculé de 41 à 72 %. L'hypothèse rejoint ce que montrent d'autres études : ES modifie de façon dense presque tous les poids du modèle, ce qui lui permet de mieux résoudre la tâche visée, mais l'éloigne davantage de son état de base et lui fait oublier une partie de ses compétences antérieures.

Que faut-il en retenir en pratique ? Evolution Strategies ressemble moins à un remplaçant universel du RL qu'à un outil spécialisé et puissant pour les entreprises qui veulent avant tout tirer le maximum d'un modèle pour un pipeline précis. Avec une fonction de reward claire, assez de ressources de calcul et un compromis acceptable sur les capacités générales, ES peut déjà offrir un gain tangible. Pour les équipes produit, c'est aussi un rappel : améliorer une tâche n'est pas gratuit, et la compétition portera non seulement sur de nouvelles métriques, mais aussi sur les moyens d'affiner les modèles sans perdre leur souplesse de base.