ecom.tech a comparé l'ajustement fin évolutionnaire de Qwen3-4B avec SFT et GRPO pour les tests Kotlin

L'équipe ecom.tech a testé si un petit modèle Qwen3-4B-Instruct pouvait être configuré pour écrire des tests unitaires utiles pour les backends Kotlin non pas par le fine-tuning supervisé standard, mais par un algorithme évolutionnaire appelé Evolution Strategies. Le résultat pratique s'est avéré fort : dans la tâche de génération de tests, cette approche a surpassé à la fois le fine-tuning supervisé et GRPO en termes de récompense finale et de couverture. Mais parallèlement à la victoire dans la spécialisation, les chercheurs ont vu le revers : plus le modèle était ajusté pour une tâche étroite, plus notablement il perdait certaines de ses capacités générales.

La motivation de l'expérience était tout à fait pratique. Au sein de leur service de génération de code, l'équipe faisait face à un problème typique : les LLMs produisent d'abord du code fonctionnant, puis écrivent des tests pour celui-ci qui semblent plausibles mais ne suivent pas les conventions internes et ne vérifient pas toujours la logique métier vraiment importante. Pour évaluer si cela pouvait être corrigé par fine-tuning, les chercheurs ont constitué un ensemble de données de 1.

500 exemples : 1.300 pour l'entraînement et 200 pour le test. Le modèle recevait non seulement la classe testée mais aussi le contexte complet autour d'elle, collecté par un agent basé sur qwen-code, et devait générer un fichier de test unitaire prêt à l'emploi.

Ils ont utilisé deux métriques pour l'évaluation. La première était Coverage, mais pas au sens habituel de couverture de lignes, plutôt comme couverture fonctionnelle : à quel point le test généré couvre réellement la même fonctionnalité publique que le test de référence. La deuxième était CodeBLEU, une métrique qui examine non seulement les correspondances de tokens mais aussi la syntaxe et le flux de données dans le code. Comme CodeBLEU standard ne supporte pas Kotlin, l'équipe a dû ajouter ce support séparément via tree-sitter-kotlin et un ensemble personnalisé de mots-clés.

La fonction de récompense était simple : 0,6 de poids a été attribué à CodeBLEU et 0,4 à Coverage, pour tenir compte à la fois de la forme du code et de son utilité pratique. L'essence d'Evolution Strategies dans cette expérience fonctionnait comme suit : au lieu de mises à jour basées sur les gradients, ils ont pris environ 30 copies perturbées du modèle de base, en ajoutant du bruit gaussien aux poids, puis ont fait générer à chaque copie une réponse en mode déterministe et l'ont évaluée avec la récompense. Ensuite, les poids de base ont été décalés vers les changements qui ont produit les meilleurs résultats.

Cette approche est plus simple à paralléliser, ne nécessite pas de stocker des gradients lourds et, selon les auteurs, est moins sujette au reward hacking.

Ils ont utilisé un projet ouvert Evolution Strategies at Scale avec accélération vLLM et ont entraîné le modèle sur un cluster de 8 H100s. En raison du coût d'un passage complet à travers l'ensemble de données à chaque itération, ils ont introduit le batching : en sélectionnant aléatoirement 32 exemples par lot.

L'expérience a montré une amélioration notable dès après 500 itérations. À la fin de l'entraînement, CodeBLEU avait augmenté de 21,3% par rapport au modèle de base, et Coverage de 18,6%. Le meilleur résultat d'ES a donné une couverture de 0,7381 et une récompense finale maximale ; selon les métriques sélectionnées, il a surpassé non seulement SFT et GRPO, mais même le plus grand Qwen3-Coder-480B.

Le tableau avec les méthodes concurrentes s'est avéré révélateur : SFT a produit des tests syntaxiquement corrects mais a eu du mal à atteindre la logique nécessaire, tandis que GRPO s'est réellement dégradé sur les deux métriques dans cette configuration.

Pour une tâche d'ingénierie étroite, la conclusion semble directe : le fine-tuning évolutionnaire peut être un outil viable même pour un modèle relativement petit. Mais ensuite est venue la partie moins agréable.

Face aux travaux récents sur l'oubli catastrophique, l'équipe a séparément vérifié ce qui se passe avec les connaissances générales du modèle fine-tuné. Ils ont exécuté la version ES de Qwen3-4B-Instruct à travers GPQA—un benchmark scientifique difficile. La baisse de précision a été en moyenne de 2,1% en zero-shot et de 5,3% en five-shot chain-of-thought. La capacité à utiliser des indices contextuels a été particulièrement affectée : l'avantage des exemples few-shot a chuté de 41–72%.

L'hypothèse s'aligne avec ce que montrent d'autres recherches : ES apporte des changements denses à presque tous les poids du modèle, ce qui l'aide à mieux résoudre la tâche cible mais le fait dévier davantage de la ligne de base et oublier certaines compétences antérieures.

Qu'est-ce que cela signifie en pratique ? Evolution Strategies ne semble pas être un remplacement universel pour RL, mais plutôt comme un puissant outil spécialisé pour les entreprises qui se soucient davantage d'extraire localement le maximum de performances d'un modèle pour un pipeline spécifique. S'il y a une fonction de récompense claire, des ressources informatiques suffisantes et une tolérance pour un compromis sur les capacités générales, ES peut déjà offrir des gains significatifs.

Mais pour les équipes produit, c'est aussi un rappel : améliorer la qualité sur une tâche n'est pas gratuit, et la bataille à venir ne portera pas seulement sur de nouvelles métriques, mais sur des moyens de faire du fine-tuning de modèles sans perdre leur flexibilité de base.