Expérience de fine-tuning de Mistral 7B sur le draft de Magic: The Gathering
(substack.com/generallyintelligent)- En prenant la sélection de cartes en draft de Magic: The Gathering comme tâche, l’expérience mesure dans quelle mesure le fine-tuning peut améliorer les performances de raisonnement dans un environnement de cartes récent, potentiellement absent du corpus d’entraînement des LLM
- Les historiques de draft de 17lands ont été convertis en prompts, et les choix des joueurs au meilleur taux de victoire ont servi de signal de vérité terrain, afin que le modèle choisisse une carte à partir du pack actuel et du pool déjà constitué
- Le modèle de 7B de paramètres fine-tuné a nettement surpassé GPT-4 sur cette tâche, avec des performances proches de celles d’un humain ou de l’expérimentateur ; un GPT-3.5 fine-tuné pourrait faire encore mieux, mais à un coût bien plus élevé
- Le format des données et la structure des prompts ont été difficiles à valider rapidement à cause de longues boucles d’entraînement, et même après environ 40 heures d’expérimentation, il n’y avait toujours pas de certitude sur le meilleur format de prompt
- D’un point de vue pratique, il vaut mieux commencer par constituer un jeu d’évaluation et utiliser un outil comme axolotl plutôt que d’écrire soi-même un script d’entraînement ; même les petits OSS LLM restent exigeants en mémoire GPU et en espace de stockage
Tâche expérimentale : le draft Magic
- L’expérience utilise le draft de Magic: The Gathering pour observer dans quelle mesure un LLM peut raisonner sur des données hors distribution
- Magic: The Gathering est un jeu de cartes à collectionner stratégique où l’on affronte un adversaire avec des créatures et des sorts ; le draft consiste à construire un deck en choisissant à tour de rôle des cartes dans des paquets aléatoires
- Le draft se prêtait bien à l’expérience pour deux raisons
- Raisonnement : faire un bon choix exige de comprendre à la fois les cartes déjà sélectionnées et celles du pack actuel
- Données hors distribution : de nouvelles cartes Magic sortent 4 à 6 fois par an, et les plus récentes peuvent ne pas figurer dans le corpus d’entraînement des LLM
- Les données proviennent des journaux de suivi de draft de 17lands
- 17lands est un service qui suit les données de draft du client Magic numérique
- En observant les choix des joueurs les mieux classés en taux de victoire, on peut construire un signal proche de la « bonne réponse »
- Ce signal n’est pas totalement univoque, car même parmi les joueurs de Magic les débats sur le bon choix sont fréquents, mais il est suffisant pour tester si le modèle apprend une nouvelle tâche
Construction du dataset et format des prompts
- Les données de draft 17lands se présentent sous la forme d’un gros fichier CSV contenant approximativement les informations suivantes
- les cartes disponibles dans le pack actuel
- les cartes déjà choisies par le drafteur
- la carte réellement choisie dans ce pack
- Pour adapter ces données au fine-tuning d’un modèle de langage, elles ont été converties en format de conversation textuelle
- le message system définit le modèle comme « DraftGPT » et lui demande de répondre d’abord par le nom de la carte lorsqu’un pick de draft lui est demandé
- le message user inclut le numéro du pack et du pick, le pool de cartes actuel, le nombre de cartes vues par couleur sur les 5 derniers packs et la description des cartes du pack actuel
- le message assistant ne renvoie que le nom de la carte choisie
- Des exemples de conversion sont fournis via un exemple de transformation des données 17lands en prompts LLM et un prompt de draft complet au format ChatML
- La partie la plus difficile a été de formater les données pour obtenir le comportement souhaité
- En fine-tuning, tester une modification de prompt impose généralement de lancer un entraînement de plusieurs heures
- La boucle d’expérimentation semblait donc 100 fois plus lente qu’en prompt engineering classique
- Les essais ont porté sur environ cinq formats de prompt, la quantité de détails par carte, l’ajout de contexte sur les derniers picks et l’inclusion de lignes d’entraînement de « connaissances carte » destinées à faire mémoriser les nouvelles cartes
- Même après environ 40 heures d’expérimentation, il n’a pas été possible de déterminer avec certitude quel format de prompt était le meilleur pour cette tâche
Environnement de fine-tuning
- Le GPU a été loué à l’heure via Runpod
- le GPU utilisé était un RTX 4090 avec 24 Go de VRAM
- le coût était d’environ 0,7 $/heure
- Au départ, l’idée était d’écrire un script d’entraînement maison avec HuggingFace transformers et PEFT, et QLoRA a été choisi en raison des contraintes GPU
- Cette approche de script maison a entraîné beaucoup d’essais et d’erreurs
- entre des optimisations simples une fois qu’on les connaît, comme FlashAttention, et des choix plus difficiles à comprendre sans lire les articles de recherche, comme les paramètres LoRA, les points de friction étaient nombreux
- chacun de ces problèmes pouvait être résolu, mais les comprendre soi-même prenait beaucoup de temps
- Au final, axolotl a été utilisé
- l’outil implémente de base plusieurs optimisations, ce qui a facilité l’exécution
- sa documentation a été jugée correcte, et il est présenté comme un bon point de départ pour la plupart des personnes qui débutent en fine-tuning de LLM
Taille des modèles et coût
- Même les « petits » OSS LLM sont énormes à l’échelle des standards passés
- vers 2019, BERT, souvent entraîné à l’époque, comptait environ 110 millions de paramètres
- un modèle 7B est environ 70 fois plus grand
- Un modèle 7B reste lourd à exploiter en pratique
- ses poids occupent environ 16 Go, ce qui pose un problème de stockage
- même avec des méthodes comme QLoRA, la mémoire GPU reste une contrainte importante
- Le fine-tuning de GPT-3.5 semblait pouvoir produire de meilleurs résultats, mais à un coût élevé
- environ 100 fois plus cher que le fine-tuning de Mistral sur bare metal
- l’inférence est elle aussi facturée à un tarif premium
- un fine-tuning GPT-3.5 comparable à la plus grosse exécution d’entraînement de Mistral-7B aurait coûté environ 500 $ selon les estimations
Méthode d’évaluation et résultats
- Il est important de constituer d’abord un bon jeu d’évaluation avant de lancer les expériences
- ici, une partie des drafts complets a été mise de côté hors des données d’entraînement pour vérifier si le modèle choisissait les mêmes cartes que les humains
- disposer de ce jeu d’évaluation a facilité le jugement des résultats du fine-tuning
- La précision du choix de carte était relativement facile à définir, mais les critères suivants étaient plus flous
- lorsqu’il fait un choix différent, le modèle devrait pouvoir justifier ce choix
- idéalement, il devrait être capable d’expliquer de manière raisonnable pourquoi il a choisi cette carte
- Ces critères plus ambigus ont été examinés via une évaluation à l’œil sur plusieurs exemples, un processus lent
- GPT-4 faisait des choix moins aberrants qu’un petit modèle fine-tuné et se montrait meilleur pour les justifier
- Le modèle 7B fine-tuné a toutefois facilement surpassé GPT-4 et l’apprentissage in-context sur cette tâche de sélection de cartes, à la fois en précision et en coût
- Dans une expérience, le modèle a été fine-tuné sur une édition de cartes puis évalué sur une autre qu’il n’avait jamais vue
- cela suggère qu’il n’avait pas simplement mémorisé les bonnes cartes, mais qu’il avait généralisé dans une certaine mesure le concept de draft
Magic Copilot et les bots de draft
- Le modèle fine-tuné de pick de draft a été relié aux logs de Magic Arena, puis intégré dans une application Electron légère appelée « Magic Copilot », utilisée sur quelques drafts
- La sélection des cartes était générée par le modèle fine-tuné, tandis que GPT-4 produisait les explications
- dans l’ensemble, cela fonctionnait bien, mais GPT-4 n’était parfois pas d’accord avec le choix du modèle fine-tuné et le contestait immédiatement
- Huit IA de draft ont aussi été reliées entre elles pour simuler des drafts entre bots
- lorsque seuls les bots se passaient les cartes, ils avaient une forte tendance à construire des decks monocolores
- lorsque des choix humains variés étaient injectés, les decks convergeaient vers des formes beaucoup plus normales
- Globalement, cette IA de draft semblait se rapprocher d’une IA de draft plus puissante et plus humaine que ce qui existe aujourd’hui
- Par rapport aux bots de quick draft de Magic Arena, ses choix se rapprochaient davantage de ceux de drafteurs humains de haut niveau que de bots heuristiques
1 commentaires
Avis sur Hacker News
J’ai apprécié que cet article montre bien à quel point il est difficile de mettre en œuvre avec le fine-tuning de LLM une idée qui paraît conceptuellement simple
Même avec un jeu de données initial plutôt correct et un modèle de départ, la tâche semble avoir été loin d’être facile. Ce type de modèle paraît adapté aux situations naturelles, sans réponse déterministe correcte. Par exemple, choisir la carte parfaite dans une liste donnée serait difficile à résoudre de manière combinatoire, mais choisir une bonne carte est possible, et un LLM peut s’approcher du niveau humain. On voit ici, me semble-t-il, la famille de problèmes que les LLM actuels peuvent résoudre via fine-tuning
Par exemple, ce mois-ci, je m’en sers pour m’aider à trouver des cadeaux pour des amis et des enfants. Pour résoudre le problème, je n’ai pas besoin du meilleur choix, un bon choix suffit
Ce ne sera peut-être pas la révolution la plus spectaculaire du quotidien, mais j’attends vraiment avec impatience des adversaires bots avec des styles de jeu intéressants dans des jeux comme Magic: The Gathering
Cela me semble être un cas d’usage évident pour améliorer nettement la capacité des équipes de R&D à créer et tester de nouvelles mécaniques à différents niveaux de jeu
Dans le passage « avec ces données, extraire les bonnes réponses à partir des picks de draft faits par les meilleurs joueurs du service », est-ce que cela signifie qu’ils ont regardé les picks de draft de https://www.17lands.com/leaderboard et les ont triés par taux de victoire ?
J’aurais pensé qu’il fallait plutôt choisir Match Wins ou Trophies. Sinon, on ne mesure pas les meilleurs joueurs du service, mais on apprend à partir de drafts où la plupart des choix étaient très bons, c’est-à-dire de joueurs qui ont eu de la chance. Cet effet se retrouvera tel quel dans la validation ou les tests.
Il me semble qu’il faudrait comparer non pas à une baseline LLM, mais à une baseline calculant, à partir des données 17lands, un score de type « Elo » pour chaque carte par rapport aux autres. Avant que les deux couleurs ne soient fixées, elle recommanderait la carte au score le plus élevé ; une fois les couleurs fixées, elle recommanderait la carte au score le plus élevé dans ces couleurs ou parmi les terrains.
Il est possible qu’un LLM possède une certaine connaissance des règles, mais sur des cartes jamais vues, il semble surtout capter des signaux comme la rareté, le coût ou le fait que ce soit « gros ». L’« exactitude » du draft me paraît aussi faible, et je ne suis pas sûr que cela signifie ce qu’ils pensent. Si, dans des situations où toutes les options sont globalement bonnes, comme les choix à fort taux de victoire, cela veut dire qu’il a choisi différemment du joueur source, alors choisir entre plusieurs bonnes options paraît au contraire plus difficile
Le seuil est diamant ou plus. En revanche, ils regardent tous les drafts de ces joueurs, y compris ceux qui se sont mal passés.
Ici, l’exactitude signifie : pour un paquet donné, a-t-il fait le même choix que l’un des bons joueurs ? C’est évidemment subjectif, donc pas un indicateur parfait, mais c’est correct pour vérifier la capacité à imiter des drafteurs de haut niveau
Je me demande s’ils ont aussi essayé la perte pondérée dans Axolotl, au lieu de mettre la perte du prompt à 0
Il me semble qu’à une époque, la documentation GPT-3 de Microsoft disait que cette approche était avantageuse lorsque la réponse était courte, comme ici avec « Cut in. ». Une adaptation au domaine avant le fine-tuning, via des subreddits ou des forums, pourrait aussi aider
Je réfléchissais aussi à l’adaptation au domaine, et j’envisage également de transcrire des vidéos YouTube de drafts. Je suis assez curieux de voir à quel point cela aiderait
Si j’ai bien lu l’article de l’auteur, à chaque moment de choix, le prompt donné à l’agent ne contient que les noms des cartes du pool accumulé jusque-là, tandis que seul le paquet reçu contient le texte complet des cartes
J’imagine que le contexte entre les choix n’est pas conservé à cause de la taille de la fenêtre de contexte.
Si c’est bien le cas, et si l’hypothèse selon laquelle ces sets sont postérieurs au cutoff d’entraînement du bot est correcte, devenir un bon drafteur ne relève-t-il pas du pur hasard ? Le bot n’a littéralement aucun moyen de savoir quelles cartes vont bien avec les picks précédents, quels signaux il a envoyés ou reçus jusque-là, etc. Même le meilleur joueur humain ne peut pas savoir avec quoi « Gadwick's First Duel -- {1}{U} (uncommon) » fonctionne bien à partir de cet exemple de prompt s’il n’a jamais vu cette carte.
Au final, il va choisir des cartes de draft généralement bonnes qui partagent les couleurs des picks précédents, ce que les heuristiques classiques fondées sur l’ordre des picks ont toujours fait
Le modèle est aussi entraîné sur des données de complétion de quiz de cartes, où il doit compléter le texte complet, le type, le CMC et d’autres informations d’une carte. De plus, pour les cartes présentes dans le paquet, il doit apprendre la complétion du token suivant ; il apprend donc aussi à prédire le texte complet des cartes pendant qu’il produit les picks de draft. Au total, le bot apprend de façon assez complète le texte des nouvelles cartes
Si vous ne l’avez pas vu, https://news.ycombinator.com/item?id=38525978 pourrait aussi intéresser ce lectorat
C’est l’article « I hacked Magic the Gathering: Arena for a 100% win rate », et il vaut le détour ne serait-ce que parce que l’enquêteur y a découvert que Sparky, la pseudo-IA de MTGA, ne semble pas être aussi stupidement compliquée qu’on le soupçonnait de l’extérieur
Elle sert plutôt à offrir aux nouveaux joueurs qui découvrent le jeu et ne connaissent pas encore les règles l’expérience de jouer contre un ordinateur idiot, ou de version informatique du « goldfish » pour vérifier comment un deck qu’on a construit sort et enchaîne ses combos. Ce n’est pas comparable à un moteur d’échecs
Le fait qu’on puisse représenter le draft avec un LLM est très intéressant
Les meilleures IA de draft que j’ai vues utilisaient toutes, d’une manière ou d’une autre, de l’apprentissage de représentations. Référence : https://arxiv.org/pdf/2107.04438.pdf
Si tu entendais autre chose par « apprentissage de représentations », j’ai peut-être mal compris
Cela dit, la représentation par LLM a quelque chose d’amusant. Par exemple, on peut donner au bot des préférences ou une personnalité via le prompt système, ce qui est assez fun
Je me demande si l’on pourrait utiliser un modèle plus petit, ou obtenir de meilleurs résultats, en traitant chaque carte comme un token, en donnant l’état du draft en entrée, et en faisant du token prédit la carte à choisir
Il faudrait entraîner depuis zéro avec un tokenizer personnalisé
<|post_author|>username<|post_title|>title here...Le modèle obtenu était nettement moins bon que lorsque tout était formaté en texte ordinaire. C’était avec MPT-30B, 15 tokens spéciaux, 300 millions de tokens d’entraînement et un fine-tuning complet.
J’ai peut-être fait une erreur, mais je n’ai pas encore vu beaucoup d’exemples de fine-tuning open source où l’ajout d’un grand nombre de tokens ait été réussi
Cela ne fonctionnerait pas sur des « cartes jamais vues », et quand le modèle se tromperait il pourrait faire des choix absurdes, mais je pense qu’on pourrait atteindre 90 % de précision
Ce serait intéressant de comparer avec l’entraînement d’un réseau neuronal de draft sans partir de Mistral. J’aimerais voir les résultats à la fois en nombre d’époques et en coût
On ne voit pas clairement pourquoi l’aspect LLM est pertinent. Il y a peut-être suffisamment de listes de decks ou de drafts simulés sur Internet pour que cela ait eu un effet, ou alors l’infrastructure autour du « fine-tuning de LLM » est simplement mieux établie que celle pour « créer un réseau neuronal ». Il faudrait peut-être quelque chose comme nnfiddle pour rendre cela facile
Le fine-tuning est relativement peu coûteux, et il suffit d’y injecter des données pour lui faire accomplir ce type de tâche assez correctement. Créer le checkpoint de base demande beaucoup de calcul, mais la majeure partie du « savoir » s’y trouve déjà.
Si l’on crée un réseau neuronal depuis zéro, il faut d’abord résoudre la question de la représentation des cartes en entrée. Je ne connais pas énormément MTG, mais la plupart des jeux de cartes à collectionner ont des descriptions textuelles et des effets complexes. Faire correspondre du texte à de la logique est précisément quelque chose que les LLM font très bien ; sans cela, il faut repartir de zéro, avec probablement beaucoup de calcul avant de voir émerger un comportement correct.
C’est aussi plus simple pour la plupart des développeurs logiciels. Le fine-tuning consiste en général à rassembler du texte et à le donner à un script de fine-tuning. On peut le faire sans savoir ce qu’est l’algèbre linéaire ni une « convolution »
Je suppose que par « entraîner un réseau neuronal de draft sans Mistral », tu veux dire utiliser comme couche d’entrée un vecteur bitmap des cartes présentes dans le booster. La fonctionnalité clé de cette expérience est que le modèle fonctionne uniquement à partir du texte des cartes, même sur un set qu’il n’a jamais vu et pour lequel il n’a aucune donnée d’entraînement. Sans LLM, je vois difficilement comment faire
J’ai beaucoup aimé cet article. En fait, cette semaine justement, je regardais le fine-tuning de LLM pour Magic: The Gathering
Je construis un petit navigateur de similarité de cartes qui utilise des embeddings sémantiques pour trouver des cartes proches, aussi bien fonctionnellement que par leur ambiance.
Pour l’instant, je n’utilise qu’InstructorXL, mais je ne sais pas si Instructor manque de connaissances innées sur le jeu, ou si je dois simplement mieux concevoir mes prompts. J’ai essayé 9 prompts jusqu’ici, mais les performances de génération d’embeddings ne me semblent pas très bonnes : https://github.com/HanClinto/MtgMatrix/blob/main/data/create...
L’étape suivante était de télécharger un jeu de données de cartes similaires, pour voir si je pourrais entraîner un grand modèle d’embeddings avec quelque chose comme une perte triplet. Je n’ai pas encore trouvé concrètement comment relier tout ça, mais cet article est très inspirant