Une technique d’auto-distillation étonnamment simple pour améliorer les performances en génération de code

 (arxiv.org)
12 points par GN⁺ 26 일 전 | 1 commentaires | Partager sur WhatsApp
  • Simple Self-Distillation (SSD) est une méthode qui améliore les performances d’un grand modèle de langage en réentraînant le modèle sur le code qu’il a lui-même généré, sans modèle enseignant ni apprentissage par renforcement
  • Le score pass@1 sur LiveCodeBench v6 du modèle Qwen3-30B-Instruct passe de 42,4 % à 55,3 %, avec en particulier +15,3 points sur les problèmes difficiles
  • SSD atténue le conflit entre précision et exploration lors de la génération de code et, selon le contexte, supprime les probabilités de queue tout en conservant une diversité utile
  • Le simple ajustement de la température ou la modification de la politique de décodage ne permettent pas de reproduire le même effet ; SSD reconfigure la distribution interne du modèle elle-même
  • Il s’agit d’une procédure simple d’apprentissage post-entraînement, applicable sans données externes ni validation, qui propose une alternative concrète pour améliorer la qualité de génération de code des LLM

Auto-distillation simple (Simple Self-Distillation, SSD)

  • SSD (Simple Self-Distillation) est une méthode qui améliore les performances des grands modèles de langage (LLM) en utilisant leurs propres sorties de code générées sans modèle enseignant, validateur ni apprentissage par renforcement
    • Le modèle génère des échantillons avec certains réglages de température (temperature) et de troncature (truncation), puis réapprend ces résultats via un affinage supervisé standard (SFT)
    • Aucune donnée externe annotée, aucun modèle de récompense et aucun environnement d’exécution ne sont nécessaires
  • Le score pass@1 de Qwen3-30B-Instruct sur LiveCodeBench v6 passe de 42,4 % à 55,3 % (+12,9 points, +30 % d’amélioration relative)
    • L’amélioration la plus forte apparaît en particulier sur les problèmes difficiles (hard split) (+15,3 points)
    • Le procédé se généralise à l’ensemble des modèles 4B, 8B et 30B des familles Qwen et Llama
  • SSD fonctionne en atténuant le conflit précision-exploration (precision-exploration)
    • Lors de la génération de code, certains tokens exigent une forte précision (« lock »), tandis que d’autres demandent une exploration variée (« fork »)
    • SSD supprime les distributions de queue inutiles selon le contexte tout en préservant une diversité utile

1. Contexte de la recherche

  • Le manque de signaux supervisés de haute qualité (par ex. du code écrit par des humains) limite l’amélioration des performances de génération de code des LLM
  • Limites des approches existantes
    • Distillation fondée sur un modèle enseignant : hérite des limites de performance du modèle enseignant
    • Apprentissage par renforcement (RL) : nécessite un modèle de récompense et une validation fondée sur l’exécution, tout en restant instable
    • Alternatives non supervisées (par ex. vote majoritaire, minimisation de l’entropie) : risque d’effondrement sur un apprentissage long
  • SSD démontre qu’une amélioration est possible sans données externes ni validation, en s’appuyant uniquement sur les sorties du modèle lui-même

2. Méthodologie SSD

  • Synthèse des données

    • Pour un ensemble donné d’invites de problèmes X, on échantillonne depuis le modèle pθ avec une température d’entraînement Ttrain et des réglages de troncature ρtrain (top-k, top-p)
    • Les sorties générées (y) sont utilisées telles quelles comme données d’apprentissage (DSSD), sans validation
    • Dans la plupart des cas, N=1 (un échantillon par problème) suffit

  • Entraînement

    • Un affinage supervisé est effectué avec une perte d’entropie croisée standard
    • L(θ) = −E(x,y)∼DSSD Σ log pθ(yt | x, y<t)

  • Inférence

    • Le modèle entraîné pθ* est décodé avec une température d’évaluation Teval et des réglages de troncature ρeval

3. Expériences

  • Configuration des modèles

    • Llama-3.1-8B-Instruct, Qwen3-4B/30B (Instruct, Thinking) et 5 modèles au total
    • 2 familles (Llama, Qwen), 3 tailles (4B, 8B, 30B), 2 styles de raisonnement (Instruct, Thinking)

  • Données

    • Environ 10K problèmes de programmation compétitive issus du dataset rSTARcoder
    • Application d’un simple filtrage syntaxique sans validation des réponses correctes

  • Paramètres d’entraînement

    • Basé sur Megatron-LM, avec 8 GPU B200
    • Optimiseur AdamW, longueur de séquence maximale de 65 536
    • 2 500 étapes pour les modèles Instruct, 300 étapes pour les modèles Thinking

  • Évaluation

    • LiveCodeBench v6 (LCB v6) utilisé comme benchmark principal
    • Évaluation détaillée par pass@1, pass@5 et par niveau de difficulté (Easy/Medium/Hard)

4. Résultats principaux

  • Amélioration globale des performances

    • Qwen3-30B-Instruct : 42,4 % → 55,3 % en pass@1 (+12,9 points)
    • Qwen3-4B-Instruct : +7,5 points, Llama-8B : +3,5 points
    • Les modèles Thinking progressent eux aussi de +2 à 3 points

  • Améliorations par niveau de difficulté

    • Qwen3-30B-Instruct : Easy +6,5 points / Medium +14,2 points / Hard +15,3 points
    • Les plus fortes hausses sur les modèles Thinking apparaissent également sur la tranche Hard

  • Maintien de la diversité

    • L’amélioration de pass@5 est plus importante que celle de pass@1 → la diversité de génération est maintenue et améliorée
    • Exemple : Qwen3-30B-Instruct pass@5 +18,1 points (Hard +23,0 points)

  • Généralisation de domaine

    • Les performances sont maintenues sur des tâches de mathématiques, de code généraliste et de compréhension en dehors de la programmation compétitive

5. Comparaison des politiques de décodage

  • L’ajustement de la température seul ne permet pas de reproduire l’effet de SSD

    • Sur le modèle de base, un balayage de température produit des variations de pass@1 de l’ordre de 1,5 à 3,0 points
    • SSD apporte, dans les mêmes conditions, une amélioration de +11,8 points (Qwen3-30B-Instruct)
    • L’écart est particulièrement marqué sur les problèmes Hard et sur pass@5
    • SSD modifie la distribution interne du modèle elle-même et ne peut donc pas être remplacé par un simple ajustement du décodage

6. Interaction des hyperparamètres

  • Le produit de la température d’entraînement (Ttrain) et de la température d’évaluation (Teval), Teff = Ttrain × Teval, détermine les performances
    • Les meilleures performances apparaissent autour de Teff ≈ 1,2
    • Plus Ttrain est élevé, plus le modèle devient sensible aux variations de Teval
  • L’ajout de la troncature (truncation) augmente le plafond de performance
    • Réglage optimal : Ttrain=2.0, Teval=1.1, top-k=10 → pass@1 49,7 % (+7,3 points)
    • La troncature apporte un gain supplémentaire en supprimant les queues de faible probabilité

7. Mécanisme de fonctionnement de SSD

  • Conflit précision–exploration (Precision–Exploration)

    • Lock : position où la bonne réponse grammaticale est presque figée → faible température requise
    • Fork : position où plusieurs solutions sont possibles → température élevée requise
    • Une température unique satisfait difficilement ces deux exigences à la fois

  • Rôle de SSD

    • Dans les cas Lock, il supprime les probabilités de queue pour renforcer la précision
    • Dans les cas Fork, il aplatit les probabilités entre les principaux candidats pour préserver la diversité d’exploration
    • Il réalise ainsi une reconfiguration de distribution dépendante du contexte

8. Validation expérimentale

  • Expérience en environnement simulé

    • Application de SSD dans un environnement simple avec une structure comprenant 1 Fork + 3 Lock
    • Après SSD, la probabilité de succès augmente et la plage de température optimale s’élargit
    • Cela confirme que l’apprentissage et le décodage sont complémentaires

  • Analyse sur modèle réel

    • Après SSD, la probabilité cumulée des tokens de tête augmente, tandis que les probabilités de queue diminuent
    • Même avec un Teval élevé, le nombre de candidats valides de premier plan augmente et l’entropie progresse
    • Autrement dit, SSD obtient à la fois l’élimination des queues et l’élargissement de la distribution de tête

9. Analyse théorique

  • La perte d’entraînement de SSD se décompose en trois termes
    1. Support Compression : suppression des probabilités de queue
    2. Within-Support Reshaping : reconfiguration de la distribution de tête
    3. Alignment to Base Model : maintien de l’alignement avec le modèle d’origine
  • Dans les cas Lock, le premier terme domine → suppression de la queue
  • Dans les cas Fork, c’est le deuxième terme qui agit → aplatissement de la distribution de tête
  • L’entropie globale diminue, mais l’entropie d’exploration utile est préservée
  • Un simple ajustement du décodage ne peut pas effectuer cette reconfiguration contextuelle

10. Expérience sur des données anormales

  • Avec Ttrain=2.0, sans troncature, 62 % des données générées sont du bruit incohérent (gibberish)
  • Malgré cela, après application de SSD
    • pass@1 : 42,4 % → 48,1 % (+5,7 points)
    • pass@5 : 53,5 % → 64,0 % (+10,5 points)
    • Sur les problèmes Hard, amélioration de +7,3 points / +13,8 points
  • Cela montre que SSD peut produire des gains en apprenant la structure de distribution plutôt que la qualité intrinsèque des bonnes réponses

Conclusion

  • Simple Self-Distillation (SSD)
    • améliore les performances de génération de code uniquement à partir des sorties du modèle lui-même, sans enseignant externe ni validation
    • atténue le conflit précision–exploration et obtient des gains généralisés grâce à une reconfiguration de la distribution
  • SSD est une méthode simple mais puissante, applicable en phase de post-training, qui propose une alternative concrète pour améliorer la qualité de génération de code des LLM

À lire aussi

1 commentaires

 
GN⁺ 26 일 전
Commentaires Hacker News

  • Ce qui rend cet article intéressant, c’est qu’il met réellement en œuvre le concept de context-aware decoding
    Il explique que, lors de la génération de code, des points de « fork » (embranchements créatifs où plusieurs interprétations sont possibles) et des points de « lock » (décisions syntaxiques exigeant de la précision) alternent
    Il est impressionnant que la méthode SSD (Simple Self-Distillation) améliore le classement des tokens optimaux dans les deux cas, aidant ainsi le modèle à être plus créatif lorsqu’il explore, et plus précis lorsqu’il doit l’être

    • En réalité, ce genre de découverte de nouvelles propriétés des LLM paraît moins surprenant qu’inévitable
      Même le cerveau humain a été étudié pendant des millénaires, et il reste encore largement incompris
      Même le comportement émergent du trafic routier n’a été clairement compris que récemment
      Donc continuer à découvrir de nouvelles propriétés des LLM est tout à fait naturel
    • Ce qui est intéressant, c’est que le modèle consacre la même quantité de calcul aux tokens « fork » et « lock »
      Avec l’échantillonnage fondé sur une grammaire ou le grammar-aware decoding, on pourrait même insérer directement un token syntaxiquement unique sans appel au modèle
      Pourtant, cela n’est presque jamais appliqué dans les systèmes largement utilisés aujourd’hui
      Je me demande s’il serait possible de généraliser une approche qui met plus de calcul sur les choix importants et moins sur les tokens évidents
    • En fine-tunant un petit modèle, j’ai rencontré un problème de mode collapse, mais le fait de mélanger aléatoirement l’ordre des champs pendant l’apprentissage l’a résolu
      Je me demande encore s’il faut appliquer la même méthode au moment de l’inférence
    • Ce qui est intéressant, c’est que SSD fonctionne même sans ajuster la temperature en temps réel ni prédire les points fork/lock
    • Ce concept peut s’appliquer non seulement au code, mais aussi à l’ensemble des contenus génératifs
      Dans le code, la différence est surtout que la structure est plus explicite, mais le mécanisme fork/lock reste valable dans de nombreux domaines

  • La self-distillation semble être une direction clé pour les progrès des LLM
    Les travaux Self-Distillation Fine-Tuning (SDFT) publiés par les équipes du MIT et de l’ETH avaient déjà montré une grande efficacité
    Le SSD (Simple Self-Distillation) de cet article s’inscrit en pratique dans la même lignée, seul le nom change
    Le fait que le terme SSD se confonde aussi avec SSD (solid-state drive) ajoute de la confusion
    J’aurais aimé qu’ils reconnaissent plus clairement la source et la filiation du travail initial, SDFT

  • J’ai récemment vu une vidéo où Gemma 4 tournait en local à 50 tokens par seconde
    On est déjà au niveau de Sonnet 3x~4 en termes de capacités
    Si on y ajoute des techniques comme SSD, d’ici 2028 on aura probablement des modèles de code bon marché et puissants largement diffusés
    Les développeurs expérimentés feront probablement tourner leurs propres modèles comme des transpileurs non déterministes convertissant le langage naturel en code

    • J’y pense souvent moi aussi. Si l’on entraînait un modèle uniquement sur les versions récentes des langages que j’utilise (PHP, SQL, JS, etc.), n’obtiendrait-on pas un modèle bien plus petit et rapide ?
      En ce moment, j’ai l’impression de « construire une maison sur un clou »
    • Bien sûr, d’ici là, les modèles frontier avec mémoire par projet et apprentissage à la demande pourraient aussi écraser les modèles personnels

  • L’hypothèse centrale du SSD, le conflit précision–exploration (precision–exploration), ressemble beaucoup au problème que tente de résoudre Adaptive Decoding

    • Adaptive Decoding m’intéresse beaucoup aussi
      Il semble évident qu’au cours de l’inférence, on a besoin d’une temperature élevée quand une pensée créative est nécessaire, et d’une temperature basse quand la précision syntaxique prime

  • Le simple fait de demander à répétition « est-ce la solution la plus élégante ? » améliore visiblement les sorties des LLM
    Si le modèle peut trouver aussi facilement une meilleure réponse, on peut se demander pourquoi il ne l’a pas produite dès le départ

    • En pratique, les solutions élégantes n’apparaissent presque jamais au premier essai
      On commence par construire quelque chose qui fonctionne, puis on affine plusieurs fois avant d’arriver à quelque chose de concis
    • C’est pareil pour les développeurs humains
      Certains passent une demi-journée à réfléchir avant d’écrire du code, d’autres implémentent immédiatement une première solution
      Les LLM actuels ressemblent davantage à cette seconde catégorie

  • Cette recherche a de fortes chances de mener à de meilleurs modèles de génération de code
    Mais nous ne comprenons toujours pas vraiment ce qui se passe dans les espaces de grande dimension
    Au final, nous explorons encore surtout en essayant des choses pour voir ce qui marche

  • Les percées du machine learning paraissent souvent simples en apparence
    C’était déjà le cas du Transformer, et c’est encore le cas avec ce SSD
    C’est probablement parce que nous ne disposons pas encore d’une base théorique profonde

    • Comme pour beaucoup de découvertes, la simplicité est souvent un signe de justesse
      La complexité est souvent le signe d’une compréhension insuffisante
      D’après mon expérience en programmation, c’est une règle assez fiable

  • Ironiquement, Apple continue de publier ses recherches en IA, alors qu’OpenAI ne le fait pas

    • Moi aussi, je trouve cela étrange. Il ne semble pas y avoir de raison évidente de garder cela fermé
    • Peut-être qu’OpenAI n’a tout simplement pas encore de marché à défendre

  • Quelqu’un a résumé cet article comme « un modèle simplement affiné pour bien réussir sur du code de benchmark », mais ce n’est pas vraiment le cas

    • Quand on lit l’article, on voit que sans vérification des bonnes réponses ni évaluation de la qualité, ils injectent simplement les entrées du benchmark et réutilisent ensuite les sorties produites pour l’entraînement
      Puis le modèle, avec des paramètres de décodage (temp, top-k) ajustés, obtient de meilleurs résultats que l’original
      Il ne s’agit donc pas simplement d’un fine-tuning sur benchmark, mais bien d’une amélioration fondée sur ses propres sorties

  • On peut comparer cette recherche à l’entraînement au golf
    À force de frapper des milliers de balles et d’automatiser le swing de base, on peut ensuite tenter en confiance des coups créatifs et risqués en situation réelle
    SSD adopte la même logique : renforcer les schémas fondamentaux pour se donner plus de marge dans les choix créatifs