Une technique qui surpasse des modèles de langage plus grands avec moins de données d’entraînement et des modèles plus petits

• Les grands LLM peuvent résoudre de nouvelles tâches en few-shot, mais leur coût de serving est élevé ; l’équipe Google Cloud AI propose distilling step-by-step, qui consiste à entraîner de petits modèles spécialisés avec des justifications en langage naturel (rationales)
• Cette approche extrait le raisonnement intermédiaire d’un LLM via un Chain-of-Thought (CoT) few-shot, puis le transforme en apprentissage multitâche où un modèle T5 apprend à la fois la prédiction du label et la génération de justifications
• Les expériences utilisent PaLM 540B comme LLM de référence et T5 comme modèle downstream, pour évaluer l’inférence en langage naturel, les questions-réponses de bon sens et les problèmes arithmétiques en langage naturel sur e-SNLI, ANLI, CQA et SVAMP
• Sur e-SNLI, la méthode dépasse le fine-tuning standard avec seulement 12,5 % des données ; sur ANLI, un T5 de 770M dépasse les performances few-shot de PaLM 540B avec 80 % des données, tout en réduisant la taille du modèle de plus de 700 fois
• C’est une approche qui réduit le compromis entre le déploiement de petits modèles et le coût de collecte des données d’entraînement, et elle est proposée en private preview dans Vertex AI

---

Coût de déploiement des LLM et limites de l’entraînement de petits modèles

• Les LLM peuvent traiter de nouvelles tâches jamais vues via le prompting zero-shot et few-shot, mais dans un service réel, la taille du modèle devient une contrainte majeure
  • Servir un LLM de l’ordre de 175B nécessite au minimum 350 Go de mémoire GPU sur une infrastructure spécialisée
  • Les LLM les plus récents à l’époque dépassaient les 500B paramètres
• En pratique, on déploie souvent des modèles plus petits et spécialisés par tâche, généralement selon deux approches
  • Fine-tuning : on met à jour un petit modèle préentraîné comme BERT ou T5 avec des données downstream annotées par des humains
  • Distillation : on entraîne un petit modèle à partir de labels générés par un LLM plus grand
• Les deux approches gardent toutefois un coût important
  • Le fine-tuning nécessite des labels produits par des humains, ce qui représente un coût et une charge de travail élevés
  • La distillation demande de grandes quantités de données non annotées, elles aussi parfois difficiles à collecter

Idée centrale de distilling step-by-step

• Distilling Step-by-Step! Outperforming Larger Language Models with Less Training Data and Smaller Model Sizes propose une méthode pour réduire le compromis entre la taille du modèle et le coût de collecte des données d’entraînement
• distilling step-by-step extrait du LLM des justifications en langage naturel, c’est-à-dire des étapes de raisonnement intermédiaires, pour s’en servir comme signal de supervision supplémentaire dans l’entraînement d’un petit modèle
• Ces justifications en langage naturel mettent en évidence le lien entre la question d’entrée et la réponse produite
  • Par exemple, si l’on donne la longueur et la largeur d’une pièce ainsi que la surface de moquette déjà disponible, le LLM peut générer une justification intermédiaire comme Area = length * width
  • Ces justifications peuvent contenir des connaissances sur la tâche qu’un petit modèle devrait autrement apprendre à partir d’un volume de données plus important
• Au lieu d’apprendre uniquement les labels, on entraîne conjointement les labels et les justifications afin que le petit modèle assimile la tâche avec moins de données

Procédure d’apprentissage en deux étapes

• La première étape consiste à extraire les justifications à partir du LLM via un prompting CoT few-shot
  • Pour chaque tâche, on place dans le prompt du LLM des exemples composés de trois éléments : entrée, justification et sortie
  • Le LLM suit ensuite ces exemples pour générer une justification pour une nouvelle entrée
• Dans un exemple de question-réponse de bon sens, on donne la question « Sammy wanted to go to where the people are » avec plusieurs choix
  • La bonne réponse est « (a) populated areas »
  • La justification fournit le lien suivant : il faut un endroit où il y a beaucoup de gens, et parmi les choix, seul populated areas correspond à un lieu où il y a beaucoup de monde
• La deuxième étape injecte les justifications extraites dans l’entraînement du petit modèle
  • En plus de la tâche standard de prédiction du label, on entraîne une nouvelle tâche de génération de justification
  • On distingue les deux tâches en ajoutant au début de l’entrée du modèle un préfixe de tâche comme [label] ou [rationale]
  • La tâche de génération de justification apprend au modèle à produire des étapes de raisonnement intermédiaires, ce qui l’amène au final à mieux prédire les labels

Configuration expérimentale et bases de comparaison

• Le LLM de référence est PaLM 540B
• Les modèles downstream spécialisés par tâche utilisent des modèles T5
• Pour le prompting CoT, les prompts CoT existants sont utilisés lorsque c’est possible, et pour les nouveaux jeux de données, des exemples sont construits manuellement
• L’évaluation est menée sur 4 benchmarks couvrant 3 tâches NLP
  • e-SNLI, ANLI : inférence en langage naturel
  • CQA : questions-réponses de bon sens
  • SVAMP : problèmes arithmétiques en langage naturel
• Les comparaisons suivent deux axes
  • Pour comparer avec les LLM à prompting few-shot, les auteurs utilisent le prompting CoT few-shot de PaLM 540B
  • Le fine-tuning standard et la distillation standard sont aussi inclus dans la comparaison, même si le billet de blog met surtout l’accent sur la comparaison avec le fine-tuning standard

Dépasser le fine-tuning standard avec moins de données d’entraînement

• distilling step-by-step obtient de meilleures performances que le fine-tuning standard avec bien moins de données d’entraînement
• Sur e-SNLI, la méthode dépasse le fine-tuning standard entraîné sur l’ensemble du jeu de données en n’utilisant que 12,5 % des données
• La taille de jeu de données nécessaire diminue aussi sur les autres jeux de données
  • ANLI : réduction de 75 % de la taille du jeu de données
  • CQA : réduction de 25 % de la taille du jeu de données
  • SVAMP : réduction de 20 % de la taille du jeu de données
• Cette comparaison est réalisée avec un modèle T5 de 220M sur des jeux de données annotés par des humains de tailles variées

Dépasser la référence PaLM avec un modèle de déploiement plus petit

• distilling step-by-step obtient de meilleures performances qu’un LLM utilisant un prompting CoT few-shot avec un modèle bien plus petit
• Sur e-SNLI, un modèle T5 de 220M dépasse les performances de PaLM 540B
• Sur ANLI, un modèle T5 de 770M dépasse les performances de PaLM 540B
  • Ce modèle est plus de 700 fois plus petit que PaLM
  • Le même T5 de 770M aurait du mal à atteindre les performances de PaLM avec le seul fine-tuning standard
• Ces résultats montrent à la fois une petite taille de modèle et un dépassement des performances de référence du LLM

Résultats avec réduction simultanée des données et de la taille du modèle

• Sur ANLI, distilling step-by-step dépasse les performances few-shot de PaLM 540B avec seulement 80 % des données complètes et un T5 de 770M
• Dans les mêmes conditions, le fine-tuning standard ne parvient pas à rattraper PaLM même avec 100 % des données
• Une exploration grossière permet d’identifier la taille minimale de modèle T5 et le nombre minimal d’exemples annotés par des humains nécessaires pour dépasser les performances CoT few-shot du LLM
• Au final, cette approche réduit à la fois la taille du modèle déployé et le volume de données d’entraînement requis pour dépasser les performances du LLM

Disponibilité

• distilling step-by-step est proposé en private preview dans Vertex AI
• Pour l’utiliser, il est indiqué de contacter [e-mail] en incluant le numéro du projet Google Cloud et un résumé du cas d’usage

[GN⁺]

Avis sur Hacker News

• Il me semble que des modèles experts plus petits domineront la plupart des applications. Il existe un point d’équilibre optimal, assez subtil, entre taille et facilité d’utilisation, et divers mécanismes comme ceux présentés dans l’article devraient permettre de le trouver et de le concrétiser.

  • Les grands modèles généralistes peuvent être composés de plusieurs petits modèles experts et d’un modèle intermédiaire chargé de décider à quel modèle spécialisé par domaine poser la question.

• Il est intéressant qu’ils aient utilisé T5 pour le modèle distillé. Je pensais que les architectures encodeur-décodeur étaient en voie de disparition, mais elles semblent encore pertinentes.
  Il est aussi intéressant de voir que cette idée n’est pas non plus incroyablement ingénieuse ni complètement hors cadre. Cela montre qu’il reste encore beaucoup de fruits à portée de main à explorer, et que l’avenir des grands modèles de langage n’est pas gravé dans le marbre. La vraie solution pourrait être un mélange d’experts entraînés de cette manière. C’est enthousiasmant de voir qu’avec la bonne combinaison d’idées, un objectif proche du Graal semble atteignable.

  • La famille T5 est excellente. FastChat-T5 offre une qualité de génération de texte surprenante ; il convient par exemple très bien aux chatbots avec génération augmentée par recherche, et il est assez rapide pour permettre une conversation en temps réel même sur CPU.
  • L’article mentionné a été soumis en mai. Les architectures encodeur-décodeur semblent encore tout à fait pertinentes pour les modèles multimodaux.
    Il reste encore beaucoup de fruits à portée de main. J’ai l’impression d’avoir vu des dizaines de variantes : chaîne de pensée, arbre de pensée, graphe de pensée, self-ask, self-critique, self-plan, self-reflect, etc.
  • Je suis curieux de savoir pourquoi tu pensais que les architectures encodeur-décodeur étaient en voie de disparition.

• Le niveau d’activité et les progrès dans les grands modèles de langage, le machine learning et l’intelligence artificielle sont vraiment impressionnants. Ces optimisations ont une valeur particulière, surtout dans un contexte où du matériel comme celui de Nvidia coûte très cher.

• N’est-ce pas la même chose que https://arxiv.org/abs/2212.08410, mais publiée un an plus tard ?

  • L’ampleur de l’amélioration est impressionnante, mais 22 % sur GSM8K comme résultat final, ce n’est pas forcément très accrocheur.

• Je ne suis pas chercheur, mais j’ai toujours eu l’intuition que les modèles les plus efficaces seraient multimodaux et entraînés avec un curriculum central soigneusement conçu.
  On voudrait garantir que le système acquière et conserve les structures et compétences de base nécessaires pour généraliser efficacement et correctement. Ensuite, tout en conservant ces éléments, on lui fournirait beaucoup de données variées afin qu’il apprenne les exceptions et les façons de combiner les compétences. Il faut toutefois un moyen de garantir jusqu’au bout ces compétences et connaissances fondamentales. Comme dans l’article, cela pourrait peut-être se faire en lui demandant de produire non seulement la réponse finale, mais aussi le processus de compréhension ou de manipulation.
  Par exemple, pour un modèle de génération de code, on pourrait lui demander de produire une simulation de machine à états du programme demandé.

  • Je suis d’accord pour dire que le multimodal est la voie à suivre, mais il n’y a rien d’intuitif qui permette de s’attendre à ce que le curriculum doive forcément être soigneusement conçu. À comparer avec https://gwern.net/scaling-hypothesis.
  • Si l’on pense à l’idée d’un cursus scolaire, je me demande si l’ordre des données d’entraînement fait une différence. Cela pourrait varier selon qu’on les donne du simple au complexe ou l’inverse. La descente de gradient peut sûrement aboutir à différents minima locaux, meilleurs ou pires.

• Je me demande pourquoi, dans la première figure, la quantité de données d’entraînement du grand modèle de langage est inférieure à celle du modèle distillé et du modèle spécialisé pour une tâche.
  Ou bien les auteurs ont-ils inclus la quantité de données d’entraînement nécessaire au grand modèle de langage dans celle nécessaire aux modèles distillés/spécialisés ?
  https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj...

  • Oui. Ils comptent la quantité de données qu’il faut collecter soi-même pour résoudre le problème.
    On peut prendre un grand modèle de langage préentraîné, auquel cas les données que je dois collecter sont celles nécessaires pour affiner ce modèle.

• Ces énormes grands modèles de langage ont-ils beaucoup de capacité inutilisée, ou bien les petits modèles de langage ne font-ils qu’imiter les tâches de raisonnement ? Une imitation de l’imitation, en quelque sorte ?

  • Il n’y a pas de distinction fondamentale entre le réel et l’imitation.
    Les jeux de données sur lesquels sont entraînés les grands modèles de langage gigantesques contiennent beaucoup de bruit qui freine les progrès. Ils contiennent aussi beaucoup de connaissances non pertinentes, que le modèle doit aussi apprendre ou mémoriser, ce qui finit par nécessiter un nombre absurde de paramètres.
    Si l’on ne cherche pas à enseigner à un modèle de langage la somme des connaissances humaines, mais qu’on lui fournit un jeu de données soigneusement sélectionné et de haute qualité, la barrière de taille devient beaucoup plus basse.
    https://arxiv.org/abs/2305.07759
  • Cette question me semble presque équivalente à « les grands modèles de langage gigantesques actuels sont-ils proches de l’optimal ? », et il paraît évident que non.
    Je me demande quelles idées on pourrait avoir pour estimer la taille optimale.
  • Les grands modèles généralisent mieux. Les petits modèles sont plus faciles à entraîner pour des tâches spécifiques.

• Intéressant. Le RLHF est-il indispensable pour qu’un petit modèle atteigne des performances similaires aux grands modèles de langage les plus récents ? Les problèmes liés à la structure de sortie, au ton et à la compréhension du domaine semblent pouvoir être résolus par l’ajustement sur instructions, mais je ne sais pas si cela suffit aussi à améliorer les capacités de raisonnement des petits modèles.

• On dit que servir un grand modèle de langage à 175 milliards de paramètres nécessite au minimum 350 Go de mémoire GPU sur une infrastructure spécialisée.
  Apple vend des Mac Studio prenant en charge jusqu’à 144 Go de mémoire GPU utilisable.
  Ce serait assez amusant si Apple sortait un Mac Pro avec plus de 300 Go et dominait le marché du service de grands modèles de langage.

  • Existe-t-il un framework permettant le traitement par lots de grands modèles de langage avec Metal ? Il me semble que GGML ou MLC ne le proposent pas encore.
    Sinon, c’est simplement une raison de plus pour laquelle ce n’est pas adapté à l’hébergement de grands modèles de langage à l’heure actuelle.
    Quoi qu’il en soit, le vrai acteur capable de rebattre les cartes, c’est Intel. En théorie, ils pourraient arriver avec des cartes Arc 2×48 Go et attaquer à prix plus bas un marché sur lequel AMD/Nvidia n’osent pas trop se lancer à cause de leurs clients de cartes professionnelles.
  • J’espère que les avantages matériels d’Apple se concrétiseront vraiment avec la génération M3. Le fait que l’A17 Pro prenne en charge le ray tracing donne l’espoir qu’ils puissent rattraper rapidement les acteurs établis.
    Honnêtement, c’est la seule raison qui me pousse à éviter le matériel Apple récent. J’utilise surtout mon ordinateur à un bureau, et le matériel PC, en particulier les GPU, est très loin devant ce que les meilleurs produits Apple peuvent faire. Linux convient très bien à mon travail, et je peux aussi jouer une fois la journée terminée ; il est difficile de justifier presque 4 000 dollars.
  • Je me demande qui sera le premier à augmenter radicalement la capacité de RAM de ses produits matériels pour capter les utilisateurs de grands modèles de langage. Cela ressemble à un moyen de gagner des parts de marché.
  • Ce chiffre ne tient même pas compte de la quantification. Si l’on quantifie 175 milliards de paramètres en 4 bits, cela devrait tenir dans environ 120 Go de VRAM. Un modèle à 34 milliards de paramètres tient sur une seule RTX 3090 avec 24 Go de VRAM en quantification 4 bits.

• Je me demande si Facebook pourrait entraîner un grand modèle de langage sur l’intégralité de l’historique de discussion de tous ses utilisateurs.