Mon modèle fine-tuné surpasse OpenAI GPT-4

• Sur 724 tests d’extraction de données structurées à partir de communiqués de presse de l’ISAF, plusieurs modèles fine-tunés ont obtenu une précision supérieure à celle de la famille GPT-4
• La comparaison inclut GPT-4o, GPT-4 Turbo, GPT-3.5 Turbo ainsi que des modèles fine-tunés basés sur TinyLlama, Mistral, Llama3, Solar et GPT-3.5
• Les modèles OpenAI ont toujours produit un JSON valide, et les versions fine-tunées de Mistral et Llama3 se sont aussi montrées stables, mais TinyLlama a affiché de fortes variations de valeurs manquantes et de qualité du JSON selon le template
• Au classement final, Mistral-7B fine-tuné avec OpenPipe arrive en tête, suivi de très près par Solar LLM et Llama3-7B
• Le fine-tuning peut améliorer la confidentialité, le contrôle et les coûts, mais il augmente aussi la complexité MLOps liée à la gestion de l’inférence, de l’évaluation et de la reproductibilité de modèles dispersés dans plusieurs environnements

---

Objectif de l’expérience et jeu de données

• L’objectif est d’évaluer la précision de LLM fine-tunés sur une tâche d’extraction d’informations d’événements à partir de communiqués de presse de l’ISAF
• Les données sont disponibles dans un dépôt public sur Hugging Face Hub, et l’évaluation a été menée sur le test split non vu par les modèles
  • Le jeu de test se compose de 724 lignes
  • Les champs incluent name, eventrefnumber, text, StartDate, eventtype, province, targetgroup, minkilled, mincaptured, killq, captureq, killcaptureraid, airstrike, noshotsfired, minleaderskilled, minleaderscaptured, etc.
• Chaque ligne est convertie en objet Pydantic pour faciliter la validation et le traitement
• La sortie du modèle doit respecter la structure JSON suivante
  • name
  • start_date
  • event_type
  • province
  • target_group
  • min_killed
  • min_captured
  • killq
  • captureq
  • killcaptureraid
  • airstrike
  • noshotsfired
  • min_leaders_killed
  • min_leaders_captured

Méthode d’évaluation des modèles de référence OpenAI

• Les modèles GPT-4o, GPT-4 Turbo et GPT-3.5 Turbo sont utilisés comme références
• Les modèles GPT ne pouvaient pas utiliser exactement le même prompt que les modèles fine-tunés, et ont nécessité un prompt plus long
  • la liste des champs à extraire était explicitée
  • les valeurs autorisées pour le type d’événement, la province et le groupe cible étaient fournies
  • des règles d’annotation numériques étaient incluses
  • un exemple de communiqué et la sortie JSON attendue étaient ajoutés
• Les règles d’annotation numériques utilisaient les critères suivants
  • a couple est interprété comme 2
  • several est interprété comme un minimum de 3
  • a few, some, a group, a small group, multiple sont interprétés comme un minimum de 3
  • numerous, a handful sont interprétés comme un minimum de 4
  • a large number est interprété comme un minimum de 5
  • facilitator n’est pas considéré comme un leader
• Les prédictions en masse ont été exécutées en asynchrone, avec une logique de retry ajoutée à cause du rate limit de GPT-3.5 Turbo
• Les résultats de prédiction ont été stockés dans le champ predictions de chaque événement, par nom de modèle

Configuration des modèles fine-tunés

• Après les prédictions des modèles de référence OpenAI, des prédictions issues de modèles locaux fine-tunés précédemment et de modèles basés sur des services de fine-tuning en un clic ont été ajoutées au même jeu de données
• Les modèles fine-tunés inclus sont les suivants
  • tinyllama-templatefree
  • tinyllama-sharegpt
  • mistral-lora-templatefree
  • finetuned-openai-gpt-3.5-turbo-1106
  • finetuned-mistral-7b-optimised-openpipe
  • ft-solar-1-mini-chat-240612-predibase
  • finetuned-llama3-7b-32k-openpipe
• Le modèle Mistral fine-tuné en local était difficile à exécuter localement, donc l’inférence a été faite dans un environnement A100 sur Modal
  • il a ensuite échoué sur presque toutes les métriques de l’évaluation
  • dans les graphiques, il apparaît sous le nom mistral-lora-templatefree
• Le service de fine-tuning en un clic d’OpenAI a été utilisé pour fine-tuner gpt-3.5-turbo-1106
• OpenPipe a servi à générer des prédictions avec Mistral 7B, Mistral 8x7B et des modèles Llama3
• Sur Predibase, un modèle basé sur le Solar LLM d’Upstage a été évalué
  • Solar LLM est présenté comme un modèle entraîné pour être performant sur des tâches où le fine-tuning est souvent utilisé, comme l’extraction de données structurées
  • le modèle de base est supposé être upstage/SOLAR-10.7B-v1.0 sur Hugging Face Hub
• L’inférence Predibase de Qwen2 ne fonctionnait pas et a donc été exclue de cette évaluation
• Le jeu de données final avec prédictions a été publié comme dataset public sur Hugging Face Hub

Validité du JSON et valeurs manquantes

• La première évaluation consistait à vérifier si la sortie de chaque modèle était un JSON valide
• Les modèles OpenAI ont produit un JSON valide à chaque fois
• Les modèles Mistral et Llama3 fine-tunés ont eux aussi produit de manière stable un JSON valide
• TinyLlama a montré une forte sensibilité au choix du template
  • tinyllama-sharegpt contient 38 valeurs manquantes
  • sans ces valeurs manquantes, il aurait vraisemblablement obtenu 724 prédictions et du JSON valide sur l’ensemble
• Le décompte des valeurs manquantes est le suivant
  • gpt-4o: 0
  • gpt-4-turbo: 0
  • gpt-3.5-turbo: 0
  • tinyllama-templatefree: 0
  • tinyllama-sharegpt: 38
  • finetuned-openai-gpt-3.5-turbo-1106: 0
  • finetuned-llama3-7b-32k-openpipe: 0
  • mistral-lora-templatefree: 0
  • finetuned-mistral-7b-optimised-openpipe: 0
  • ft-solar-1-mini-chat-240612-predibase: 0

Précision par champ

• L’évaluation de précision a été menée sur un total de 13 attributs
  • start_date
  • province
  • target_group
  • event_type
  • min_killed
  • min_captured
  • killq
  • captureq
  • killcaptureraid
  • airstrike
  • noshotsfired
  • min_leaders_killed
  • min_leaders_captured
• Le nombre total de tâches dans tous les graphiques est de 724

• start_date

  • Sur start_date, Solar et le modèle GPT-3.5 fine-tuné ont obtenu les meilleures performances
  • Les scores sont les suivants
    • gpt-4o: 527
    • gpt-4-turbo: 522
    • gpt-3.5-turbo: 492
    • tinyllama-templatefree: 231
    • tinyllama-sharegpt: 479
    • finetuned-openai-gpt-3.5-turbo-1106: 646
    • finetuned-llama3-7b-32k-openpipe: 585
    • mistral-lora-templatefree: 0
    • finetuned-mistral-7b-optimised-openpipe: 636
    • ft-solar-1-mini-chat-240612-predibase: 649
  • Même le meilleur modèle se trompe encore sur 75 dates, ce qui montre qu’il reste une marge d’amélioration sur l’extraction des dates

• province

  • Sur la prédiction de la province, les modèles fine-tunés devancent les modèles OpenAI
  • Les scores sont les suivants
    • gpt-4o: 649
    • gpt-4-turbo: 645
    • gpt-3.5-turbo: 595
    • tinyllama-templatefree: 335
    • tinyllama-sharegpt: 660
    • finetuned-openai-gpt-3.5-turbo-1106: 704
    • finetuned-llama3-7b-32k-openpipe: 707
    • mistral-lora-templatefree: 0
    • finetuned-mistral-7b-optimised-openpipe: 711
    • ft-solar-1-mini-chat-240612-predibase: 704

• target_group et event_type

  • target_group peut contenir plusieurs groupes, donc le score est calculé selon la proportion de groupes corrects identifiés par le modèle
  • Les modèles fine-tunés se montrent nettement meilleurs que les modèles OpenAI pour l’identification des groupes cibles
  • En revanche, les performances peuvent baisser si de nouveaux groupes absents des données d’entraînement sont ajoutés
  • event_type comporte des catégories au sens partiellement recouvrant et est donc considéré comme difficile même pour des annotateurs humains
  • Même sur cet attribut difficile, les modèles fine-tunés affichent de bonnes performances

• Champs numériques et booléens

  • Sur des estimations numériques comme min_killed, l’écart entre modèles fine-tunés et modèles OpenAI se réduit
  • Mistral obtient le meilleur score, mais l’écart reste faible, et les modèles OpenAI se montrent aussi performants sur cet attribut
  • Il est possible que les règles d’annotation numériques incluses dans le long prompt aient aidé
  • Les attributs booléens comme killq affichent une précision élevée pour la plupart des modèles
  • Le Mistral fine-tuné dépasse aussi sur cet attribut le meilleur score de GPT-4o
  • killcaptureraid apparaît comme un point faible pour les modèles OpenAI
    • kill-capture raid était un terme métier employé d’une manière spécifique dans le labeling
    • les modèles OpenAI ne connaissaient pas ce critère de labellisation
  • noshotsfired est un champ issu de communiqués d’une certaine période qui insistaient sur le fait qu’“aucun tir n’avait été effectué”
  • Les modèles OpenAI y ont montré des performances dans un ordre inverse de celui attendu, et il faudra une analyse supplémentaire pour en comprendre la cause
  • min_leaders_killed et min_leaders_captured obtiennent globalement des scores élevés
  • Contrairement à l’idée reçue selon laquelle les LLM sont faibles avec les nombres, ils ont montré ici de bonnes performances, même si les modèles fine-tunés obtiennent encore les meilleurs résultats

Résultats agrégés finaux

• La précision agrégée finale est calculée sur une échelle de 0 à 100 en additionnant les 13 scores de précision individuels puis en en faisant la moyenne
• Dans le résultat final, les modèles fine-tunés dépassent les modèles OpenAI de la famille GPT
• Même TinyLlama affiche une précision agrégée supérieure à GPT-3.5 Turbo
• Le modèle le plus performant est Mistral-7B fine-tuné avec OpenPipe
• Solar LLM et Llama3-7B suivent Mistral-7B de très près
• Pour le fine-tuning dédié à l’extraction de données structurées, il semble pertinent de commencer avec Mistral-7B, Solar 7B et Llama3-7B puis de comparer lequel convient le mieux
• En termes de précision pure, les trois modèles peuvent être presque équivalents
• Il peut exister d’autres compromis sur le serving, l’efficacité et la latence

Avantages et coûts du fine-tuning

• Les modèles OpenAI peuvent aussi améliorer leurs performances si l’on ajoute plus d’exemples et de règles dans le prompt
• Mais à mesure que le prompt s’allonge, le coût par requête augmente
• Un modèle fine-tuné maison offre les avantages suivants
  • confidentialité des données, puisqu’il n’est pas nécessaire d’envoyer des informations sensibles à OpenAI
  • amélioration potentielle des performances grâce à des modèles plus petits
  • davantage de contrôle
  • possibilité de réduire les coûts
• La comparaison des coûts reste difficile à trancher clairement à ce stade
  • les grands fournisseurs cloud peuvent bénéficier d’économies d’échelle
  • dans des cas d’usage réels avec inférence répétée sur le long terme, l’argument économique en faveur des modèles maison peut devenir plus convaincant
  • améliorer un appel OpenAI peut nécessiter d’ajouter beaucoup d’exemples et d’explications, ce qui augmente le coût par requête

Exploitation de l’évaluation et complexité MLOps

• Le fine-tuning a permis d’obtenir de meilleures performances que GPT-4 avec relativement peu d’ajustements
  • les modèles utilisés étaient les premiers modèles fine-tunés construits à partir des données collectées
  • la plupart des paramètres sont restés sur les valeurs par défaut
• La suite des travaux se concentrera sur Solar, Llama3 et Mistral 7B
• L’évaluation a été principalement implémentée dans des notebooks Jupyter, et l’exploitation était fastidieuse
  • certains modèles tournent en local
  • d’autres sont déployés sur différents services et environnements
  • parcourir les 724 lignes était lent
• Lors de la prochaine itération, il faudra pouvoir exécuter l’évaluation en local et commencer par n’évaluer qu’un sous-ensemble des données avant d’étendre au dataset complet
• Lorsqu’on gère plusieurs modèles dans un même projet, une interface d’inférence standardisée est nécessaire
• Quand les modèles sont dispersés à plusieurs endroits, que le fine-tuning et les mises à jour se répètent et que les données continuent d’évoluer, il faut un système pour gérer l’ensemble
• Le principal compromis du fine-tuning de LLM est qu’il faut gérer de nombreux composants pour assurer une exploitation stable et reproductible

Valeur de l’évaluation et prochaines étapes

• Même si l’implémentation de l’évaluation a été laborieuse, elle fournit un référentiel spécifique à la tâche pour vérifier si les améliorations des données d’entraînement ou du modèle produisent un vrai progrès
• Sans évaluation, il est difficile de savoir si l’on s’améliore réellement
• L’idée de créer séparément plusieurs modèles hyper-spécialisés n’est pas, pour l’instant, la prochaine étape la plus évidente
  • par exemple, un modèle distinct spécialisé uniquement dans l’estimation du nombre de personnes capturées
  • vu les performances actuelles, on ne sait pas clairement si cette approche ferait fortement progresser la précision
• La prochaine étape prioritaire est d’exécuter des évaluations au-delà de la seule précision
  • l’évaluation sur des données out-of-domain mentionnée dans un billet précédent en est un exemple
  • l’objectif est de vérifier le comportement sur de fausses données portant sur des sujets complètement différents
• Une autre étape consiste à examiner plus en profondeur le LLM serving des trois meilleurs modèles
  • le LLM serving implique des outils, des compromis et des techniques différents de ceux du serving de modèles non LLM
• En creusant davantage, il pourrait être utile de publier les cas erronés dans une interface web comme Lilac ou Argilla afin d’analyser les schémas d’échec
• Comprendre les scénarios d’échec pourrait davantage améliorer la précision qu’un simple ajustement des paramètres de fine-tuning

[GN⁺]

Commentaires sur Hacker News

• En tant que fondateur d’OpenPipe, je constate que l’extraction de données est un cas d’usage où les modèles fine-tunés excellent particulièrement, donc ces bons résultats ne sont pas surprenants
  Si l’on peut créer de solides données d’entraînement, il a souvent été assez facile de battre GPT-4 sur plusieurs types de tâches, et dans une étude publiée il y a une semaine, un Llama 3 8B fine-tuné a surpassé GPT-4 sur 3 des 4 tâches d’exemple suivantes : résumé créatif, questions-réponses, extraction de données et classification
  L’essentiel a été de concevoir une méthode pour générer de façon itérative des données d’entraînement de haute qualité, et l’article aborde précisément ce point : https://openpipe.ai/blog/mixture-of-agents

  • Je me demande s’il est facile, même pour quelqu’un de simplement passionné de technique et non expert, de faire du fine-tuning et de l’exécuter
    L’idée serait d’entraîner un LLM expert d’un sujet sur de la documentation technique, certaines actualités, deux ans de billets de blog, des sources primaires et des fils explicatifs sur Twitter, afin de regrouper les informations de niche sur un thème au cours des deux dernières années
  • Je me demande si un méta-modèle sous forme de LLM, chargé de choisir l’un de plusieurs modèles fine-tunés selon la question, ne pourrait pas produire globalement de meilleurs résultats que GPT-4
  • Je me demande si l’entraînement d’un nouveau modèle à partir des réponses de modèles de grands fournisseurs de LLM (OpenAI, Anthropic, etc.) viole leurs conditions d’utilisation

• Ce résultat n’est pas du tout surprenant et concorde avec les travaux antérieurs montrant que, pour l’extraction d’information et la classification de texte, de petits modèles spécialisés peuvent faire mieux
  Pendant mon doctorat, j’ai travaillé sur l’extraction fine d’événements et de sentiments de type ACE, et de “petits” transformeurs spécialisés fine-tunés faisaient mieux que le prompting de LLM comme BERT ou Roberta-large
  Ce serait bien d’inclure aussi les scores de petits modèles avec les pipelines les plus récents, et c’est un bon travail même s’il s’agit de reproduire des résultats déjà connus

  • Il y a un bémol : si l’on ne sait pas construire un bon modèle spécialisé, on ne fait que gaspiller le temps et l’argent de tout le monde : https://www.threads.net/@ethan_mollick/post/C46AfItO8RS?hl=e...
  • Le sujet de l’article a l’air intéressant, auriez-vous un lien ?

• Dans mon travail réel, le seul usage sérieux des LLM qui m’ait été utile a été l’extraction/structuration de données
  Je devais extraire le début, la fin et la description d’événements à partir de rapports d’échantillonnage d’expérience non partageables en ligne, et j’ai utilisé un modèle via llama.cpp pour les convertir en CSV à 4 colonnes : onset, offset, description et respect ou non d’une condition donnée
  Rien qu’en mettant dans le prompt quelques exemples de la structure souhaitée, plusieurs modèles s’en sortaient bien, et j’ai particulièrement apprécié Mixtral 8x7b, qui était le plus rapide de sa catégorie de qualité sur un ordinateur portable
  Pour cette tâche, un modèle plus petit fine-tuné a de fortes chances d’être meilleur et plus rapide, et lorsqu’on ne peut pas envoyer les données à un acteur comme OpenAI, un traitement hors ligne est nécessaire : c’est là que des modèles petits, exécutables en local et fine-tunables peuvent vraiment briller

  • J’ai compris cela très tôt en expérimentant l’extraction de données web avec GPT-3, et après avoir publié le premier prototype sur Reddit et HN, j’ai constaté une forte demande pour l’automatisation des piles de scraping web basées sur des règles
    Cela a conduit à la startup https://kadoa.com, qui automatise ce problème “ennuyeux et difficile”, lourd à maintenir et difficile à faire évoluer
    C’est dans ce type d’usage relativement moins spectaculaire que l’IA apporte le plus de valeur, et elle automatisera des tâches répétitives comme le scraping web, le remplissage de formulaires ou la saisie de données, plutôt que de supprimer des emplois
  • Comme prochaine étape, j’aimerais travailler sur le déploiement/l’inférence pour voir jusqu’où on peut réduire la taille des modèles
    Spacy pousse depuis longtemps cette approche avec des modèles de quelques dizaines de Mo, et je suis content de voir l’intérêt augmenter aujourd’hui
    Dans l’idéal, il y aurait beaucoup de micro-modèles chacun très spécialisé, de petite taille et rapides à l’inférence, mais si l’architecture n’est pas bien pensée, leur maintenance et leur mise à jour finissent par devenir ingérables

• C’est précisément le cœur du fine-tuning des modèles
  J’ai apprécié qu’on montre le processus de fine-tuning en combinant options d’hébergement et options locales

  • Je me demande s’il existe un bon service du type : “voici mon jeu de données, fine-tunez ces 9 modèles et donnez-moi les statistiques d’évaluation”
  • Le point clé n’est pas simplement qu’un modèle fine-tuné s’améliore, mais qu’un modèle bien plus simple, fine-tuné, ait battu un modèle beaucoup plus avancé

• L’article est bien écrit et instructif
  J’ai remarqué l’usage de temperature=1 dans les tests GPT de l’exemple, et je me demande si c’est une bonne pratique pour les tâches nécessitant une sortie structurée
  De ce que j’en comprends, une temperature de 0 serait préférable pour ce type de charge, tandis qu’une temperature élevée conviendrait davantage à des tâches créatives

  • Les paramètres ont été définis conformément au guide du modèle concerné
    Certains fournisseurs de fine-tuning de LLM recommandaient effectivement une temperature de 0, ce que j’ai suivi tel quel, tandis que d’autres recommandaient 1
    On pourrait faire des expériences itératives pour trouver la meilleure valeur pour chaque modèle, et cela vaudrait la peine de le faire pour les modèles sur lesquels se concentrer ensuite dans les itérations/fine-tuning

• J’aimerais voir des exemples où GPT-4o s’est trompé mais où le modèle le plus performant a eu raison
  Et ayant beaucoup pratiqué l’extraction de données structurées, j’aimerais aussi voir un nouvel essai avec une temperature de 0 ; d’après mon expérience, il faut toujours utiliser 0 et la différence peut être très importante
  Une temperature de 1 signifie en pratique qu’on commence à choisir aussi des tokens dont la probabilité d’être corrects est plus faible

  • Pour ce type d’usage fondé sur des données passées avec des réponses clairement justes ou fausses, une comparaison à temperature 0 serait intéressante
    Quand j’ai expérimenté la temperature dans un éditeur SQL pour l’IA, 0.3 était la valeur idéale, car plus on se rapproche de 0, plus on optimise la précision, mais lorsqu’une erreur apparaît, l’auto-correction devient plus difficile

• J’ai écrit un article sur un sujet proche : https://www.nature.com/articles/s41467-024-45563-x

• Je me demande si des éléments potentiellement controversés dans l’article de presse source peuvent affecter la capacité de résumé de ChatGPT

  • J’utilise l’extraction d’information par LLM sur des articles de presse financière via OpenAI Azure, et c’est un vrai problème
    Même avec du simple texte d’articles financiers, 4 % des articles renvoient une réponse de modération de contenu 404, ce qui est l’une des principales raisons pour lesquelles nous examinons les modèles ouverts
  • Je ne pense pas
    En général, quand ce type d’erreur se produit, il n’y a tout simplement aucune sortie, alors que l’article montre qu’un JSON valide a été obtenu pour les 724 cas de test
    Ce genre de sujet a probablement été bien couvert dans les données d’entraînement, et les modèles open source ont sans doute utilisé des données similaires, donc l’écart entre modèles propriétaires et modèles open source ne devrait pas être énorme

• Au risque de parler comme quelqu’un d’une autre époque, la priorité absolue devrait être de rendre tous les modèles aussi libres et open source que possible afin que tout le monde puisse les fine-tuner
  C’est un sous-cas de l’idée selon laquelle le libre/open source est généralement meilleur à la fois pour la liberté et pour la qualité

  • Cela semble vouloir dire que celui qui accumule le plus de données personnelles et en revendique la propriété finira par fabriquer les meilleurs produits
    C’est similaire à l’époque où l’on trouvait normal que la publicité ciblée soit “meilleure” parce que plus “pertinente”, sauf qu’aujourd’hui cela ne concerne plus seulement la publicité, mais aussi des produits utiles
    Les propriétaires de plateformes comme Apple ou Microsoft peuvent aspirer des données depuis les applications et les produits, voire en local, ce qui leur donne un avantage bien plus grand qu’une simple avance de 3 à 6 mois sur la qualité des modèles
    Je n’aime pas cette centralisation de la technologie, et même s’il est encourageant de voir que de petits modèles fine-tunés peuvent être meilleurs, l’ouverture et la confidentialité risquent à elles seules de ne pas suffire à gagner, voire de ne laisser presque aucune chance
    Le mieux serait que les modèles ouverts deviennent largement répandus et efficaces dans le domaine des services aux PME, au point que le coût des tokens OpenAI ne soit plus nécessaire
    C’était probablement le plan de Zuck, avec l’intention d’empêcher l’émergence d’un gardien centralisé dans une technologie qui profite surtout à ses concurrents
    Malgré tout, l’ennemi de mon ennemi est mon ami, donc cela pourrait bien être ce qu’il a fait de mieux pour l’intérêt public

• Chez Predibase, nous avons récemment mené plus de 700 expériences de fine-tuning pour benchmarker les performances de LLM open source populaires sur 30 tâches et les comparer à GPT-4
  Dans 85 % des cas, ils ont battu GPT-4, et les résultats sont visibles ici : https://predibase.com/fine-tuning-index
  Le site propose un graphique interactif et un lien vers l’article sur Arxiv