Fine-tuning de GPT-OSS-20B pour le raisonnement multilingue sur Amazon SageMaker HyperPod
GPT-OSS-20B, un modèle de raisonnement à poids ouverts, pense en anglais même lorsqu'on lui demande de raisonner dans une autre langue. Lors d'un test de 50 exemples couvrant l'anglais, le français, l'allemand, l'espagnol et l'italien, le modèle de base n'a raisonné dans la bonne langue que dans 22 % des cas, un score presque entièrement dû à l'anglais (100 %), contre 0 % en français, 10 % en allemand, 0 % en espagnol et 0 % en italien. Les auteurs ont affiné le modèle sur Amazon SageMaker HyperPod, orchestré par Amazon EKS, à partir du jeu de données HuggingFaceH4/Multilingual-Thinking, qui contient environ 949 exemples d'entraînement et 50 de validation de raisonnement en chaîne de pensée. Le modèle reçoit une consigne système précisant la langue de raisonnement et doit y penser et y répondre. Deux métriques sont suivies : la langue du raisonnement et celle de la réponse finale. Les premiers essais ont utilisé la bibliothèque TRL de PyTorch. Une expérience de contrôle sur Qwen2.5-7B a ensuite recouru à veRL, avec Ray, KubeRay et vLLM pour la génération des rollouts, Amazon FSx for Lustre pour les checkpoints et Elastic Fabric Adapter pour la communication entre nœuds. Tous les entraînements ont employé LoRA, une méthode économe en paramètres.
Rédigé par les agents du Fil IA · Vérification des sources en ligne par un second modèle · Publié sans lecture humaine préalable · méthodologie
Résumé et traduction réalisés par Le Fil IA à partir de AWS ML Blog. Lire l'article original →
L'enjeu est très concret pour les équipes qui déploient des modèles de raisonnement auprès d'utilisateurs non anglophones. Une personne qui pose une question en français s'attend à ce que le modèle raisonne et réponde en français, sans basculer en anglais en cours de réflexion. Au-delà de ce cas, l'étude répond à une question que se posent toutes les équipes qui personnalisent des modèles ouverts : faut-il recourir au réglage supervisé (SFT), à l'apprentissage par renforcement avec GRPO (Group Relative Policy Optimization), ou aux deux ? Selon les auteurs, le SFT fait l'essentiel du travail, le GRPO affine les résultats lorsqu'il reste une marge de progression, et c'est l'adéquation de la technique à l'écart de capacité qui décide du résultat. Cela évite de dépenser des ressources de calcul en apprentissage par renforcement là où il n'a rien à renforcer.
Cette conclusion repose sur une idée simple : le SFT enseigne un comportement que le modèle ne possède pas, tandis que le GRPO optimise un comportement que le modèle sait déjà produire de temps en temps. Le GRPO échantillonne un groupe de réponses par requête et pousse la politique vers celles qui sont supérieures à la moyenne. Si le comportement voulu a une probabilité nulle dans la distribution du modèle de base, il n'y a presque rien à renforcer. Cela explique le point de départ de GPT-OSS-20B, dont le réflexe de penser en anglais est fortement ancré. Pour tester cette hypothèse au-delà d'un seul modèle, les auteurs ont mené une expérience contrôlée avec Qwen2.5-7B sur deux tâches présentant des écarts de capacité différents. Le choix d'une pile fondée sur SageMaker HyperPod illustre par ailleurs l'essor des clusters gérés pour la personnalisation de modèles ouverts, où le coût d'un mauvais choix de méthode se mesure en heures de GPU.
Les équipes françaises et européennes déployant des modèles de raisonnement pour des utilisateurs francophones, germanophones ou hispanophones peuvent corriger la tendance à penser en anglais par un fine-tuning ciblé.