Comment affiner un LLM [et quand privilégier le RAG ou le prompting]

Le fine-tuning d’un grand modèle de langage (LLM) consiste à affiner un LLM pré-entraîné sur un petit jeu de données propre à une tâche, afin d’obtenir des résultats impossibles à atteindre par le seul prompting.

Le fine-tuning consiste à rassembler des exemples de paires entrée/sortie illustrant le comportement souhaité, à exécuter des passes d’entraînement qui rapprochent les poids du modèle de ces exemples, puis à comparer le résultat aux sorties du modèle d’origine. Les méthodes efficaces en paramètres comme LoRA rendent l’opération suffisamment économique pour être réalisée sur un seul GPU.

Si les sorties du LLM ne vous satisfont pas, commencez par affiner vos prompts et votre génération augmentée par récupération (RAG). Le fine-tuning modifie le comportement du LLM. Lorsque vous avez besoin qu’il exploite des informations récentes ou propriétaires, le prompting et le RAG sont généralement plus adaptés.

Voici comment effectuer le fine-tuning d’un LLM étape par étape, les principales méthodes de fine-tuning (LoRA et QLoRA), ainsi que les difficultés et les erreurs susceptibles de compromettre le processus.

Qu’est-ce que le fine-tuning d’un LLM et en quoi diffère-t-il de son pré-entraînement ?

Le pré-entraînement d’un LLM développe à partir de zéro les capacités linguistiques générales d’un modèle sur un vaste corpus, tandis que le fine-tuning ajuste un modèle pré-entraîné sur un petit jeu de données en vue d’une tâche précise.

Le pré-entraînement d’un LLM est la phase gourmande en ressources qui produit un modèle de base. Celui-ci apprend à partir d’un large corpus de textes, ce qui lui confère une maîtrise générale de la grammaire, des connaissances factuelles et des capacités de raisonnement, mais aucune spécialisation pour votre tâche.

Le fine-tuning d’un LLM prolonge l’entraînement du modèle de base sur un petit jeu de données soigneusement sélectionné, afin qu’il produise les résultats souhaités pour une tâche ou un cas d’usage précis. Pensez par exemple à un format cohérent, à une voix ou un ton de marque, à des schémas propres à un domaine, ou à des appels d’outils et de fonctions fiables.

Quand recourir au fine-tuning d’un LLM, et quand privilégier le prompting ou le RAG

Pour améliorer les performances d’un LLM, gravissez les échelons : prompting -> RAG -> fine-tuning.

Affinez vos prompts avec des instructions plus détaillées et utilisez le RAG pour fournir au modèle des informations à jour. Ne recourez au fine-tuning que si les améliorations apportées aux prompts et à la récupération ne suffisent pas.

Quand de meilleurs prompts l’emportent sur le fine-tuning, et quand ils ne suffisent pas

Le prompting est le levier le plus rapide et le moins coûteux. Bien souvent, des prompts plus précis et plus détaillés suffisent à obtenir les changements de comportement souhaités.

Mais des prompts plus longs ralentissent le travail, le rendent plus coûteux et ne permettent pas de surmonter les limites existantes du modèle.

Signes que le prompting a peut-être atteint ses limites :

• De nouveaux cas limites ne cessent de dégrader les résultats : Par exemple, le modèle renvoie de la prose alors que vous attendez du JSON, ou s’écarte du ton voulu, et vous corrigez le prompt pour chaque nouveau cas.
• Le prompt système ne cesse de s’allonger : Il atteint des centaines, voire des milliers de lignes, et devient difficile à gérer.
• Vous le payez à chaque appel : Le prompt est renvoyé et retraité à chaque requête, ce qui augmente le coût en tokens et la latence.
• Les modifications n’ont plus d’effet : Les nouvelles instructions n’améliorent pas les résultats.

Même dans ce cas, essayez d’abord les correctifs moins coûteux au niveau du prompt. Utilisez des exemples few-shot pour montrer au modèle le schéma attendu (paires entrée/sortie), l’enchaînement de prompts pour décomposer les tâches complexes en étapes plus simples, ou des hooks d’appel de fonctions pour déléguer les recherches exactes ou les calculs.

Quand le RAG est plus pertinent que le fine-tuning du modèle

Le RAG modifie ce que le LLM sait, tandis que le fine-tuning modifie sa façon de se comporter. Si le manque porte sur les connaissances, en particulier des connaissances qui évoluent souvent ou qui se trouvent dans vos propres documents, le RAG est la solution. Si le manque est d’ordre comportemental, optez pour le fine-tuning.

Le fine-tuning modifie aussi ce que sait un modèle, mais les faits qu’il assimile sont figés au moment de l’entraînement et perdent vite leur actualité dans les domaines qui évoluent rapidement. En outre, ces informations sont intégrées aux poids du modèle, qui ne conservent aucune trace de leur source.

Mettre à jour les documents sources qu’utilise une couche de récupération est plus rapide et moins coûteux, et cette couche peut citer les sources exactes qu’elle a utilisées. C’est donc un meilleur choix lorsque vous avez besoin d’informations à jour et vérifiables.

L’inconvénient du RAG ? C’est une couche supplémentaire à développer et à maintenir, qui ajoute de la latence.

En pratique, vous aurez souvent besoin des deux. Les systèmes en production associent des modèles affinés au RAG : l’un garantit un comportement cohérent, l’autre fournit des faits actuels.

Pièges, risques et difficultés courants du fine-tuning

Même lorsque le fine-tuning est l’outil adapté, il comporte des coûts et des risques :

• Coût et délais : La collecte de données d’entraînement propres et représentatives, ainsi que la puissance de calcul nécessaire à l’entraînement, coûtent cher.
• Oubli catastrophique : Entraîné sur un jeu de données restreint, un modèle peut perdre des compétences générales et présenter de nouveaux modes de défaillance, ce qui entraîne des erreurs que le modèle de base ne commettait pas.
• Surapprentissage : Avec trop peu de données, ou des données trop répétitives, le modèle mémorise vos exemples d’entraînement au lieu d’apprendre des schémas : il obtient de bons résultats sur ses échantillons d’entraînement, mais de mauvais résultats sur des entrées réelles.
• Péremption : Les connaissances intégrées aux poids vieillissent vite, ce qui oblige à réentraîner le modèle sur de nouvelles données.
• Obsolescence : Lorsqu’un modèle plus performant sort, il surpasse souvent d’emblée votre modèle affiné, et vous devez refaire le travail.
• Difficultés d’évaluation et de reproductibilité : Il est difficile de prouver que le modèle affiné surpasse le modèle de base. Deux entraînements sur GPU avec les mêmes paramètres peuvent en outre produire des modèles légèrement différents.
• Gouvernance des données : L’entraînement sur des données propriétaires ou sensibles soulève des questions de confidentialité et de licences ; un modèle peut ultérieurement restituer des fragments de ses données d’entraînement.

Les principales méthodes de fine-tuning

Les principaux types de fine-tuning de LLM se distinguent par la part du modèle qu’ils modifient : le fine-tuning complet réentraîne l’ensemble du modèle, tandis que les méthodes de fine-tuning efficace en paramètres (PEFT), comme LoRA et QLoRA, ne mettent à jour qu’une partie des poids. Les méthodes PEFT ne nécessitent qu’une fraction de la mémoire requise par un fine-tuning complet et, avec les bons réglages, peuvent atteindre des résultats équivalents.

Le fine-tuning complet met à jour tous les poids du modèle. C’est la méthode la plus coûteuse, et celle qui présente le risque d’oubli catastrophique le plus élevé. Réservez-la aux changements de comportement importants, lorsque vous disposez des données et de la puissance de calcul nécessaires.

L’alternative est le fine-tuning efficace en paramètres, ou PEFT. Ce terme générique désigne des méthodes qui figent la majeure partie du modèle et n’entraînent qu’un petit ensemble de paramètres. Elles consomment beaucoup moins de mémoire et sont moins sujettes à l’oubli, puisque le modèle de base reste intact.

Avec des rangs faibles, le PEFT apprend moins qu’un fine-tuning complet, mais augmenter le rang et ajuster le taux d’apprentissage permet de combler l’essentiel de l’écart sur les tâches d’instruction-tuning.

Parmi les méthodes PEFT, on trouve :

• LoRA (Low-Rank Adaptation) : Point de départ habituel, cette méthode fige les poids d’origine et entraîne un petit ensemble de paramètres d’adaptateur ajoutés, représentant souvent moins de 1 % du total, ce qui lui permet de fonctionner sur un seul GPU grand public.
• QLoRA (Quantized Low-Rank Adaptation) : Cette méthode compresse le modèle de base en précision 4 bits avant d’appliquer LoRA, ce qui permet d’effectuer le fine-tuning d’un grand modèle sur un seul GPU.

En complément, nous utilisons des méthodes d’instruction-tuning et de preference-tuning, du RLHF (Reinforcement Learning from Human Feedback, apprentissage par renforcement à partir de rétroaction humaine) à des alternatives plus légères comme Direct Preference Optimization (DPO) et Odds Ratio Preference Optimization (ORPO), afin de façonner la manière dont un modèle suit les instructions et s’aligne sur les préférences humaines.

Comment effectuer le fine-tuning d’un LLM étape par étape

Une fois que vous avez décidé que le fine-tuning d’un LLM est la bonne solution, voici le flux de travail à suivre.

Agrandir

Étape 1 : Définir la tâche et la manière de mesurer la réussite

Déterminez le comportement que vous attendez du LLM et la manière dont vous saurez que vous l’avez obtenu.

Précisez la tâche que le modèle affiné doit accomplir, par exemple classer des tickets d’assistance, résumer des contrats dans un format fixe ou générer du code selon les conventions de votre équipe.

Définissez ensuite ce qu’est la réussite. Les options courantes sont notamment :

• Validité des sorties : Par exemple, le résultat peut-il être analysé comme du JSON valide ou respecte-t-il la structure Markdown dont vous avez besoin ?
• Scores automatisés : Utilisez des indicateurs comme BLEU ou ROUGE, qui comparent le texte généré à des réponses de référence, ou la précision sur la tâche mesurée à l’aide d’un jeu de données étiqueté.
• Évaluations humaines : Une grille d’évaluation notée ou binaire (réussite/échec) pour les qualités qu’un script évalue mal, comme le ton ou l’utilité.
• Fiabilité sur les entrées difficiles : Le modèle gère-t-il les entrées inhabituelles qui mettaient en difficulté le modèle de base ?

Étape 2 : Préparer votre jeu de données

La qualité des données détermine la réussite du fine-tuning : consacrez donc des efforts à la constitution d’un jeu de données de fine-tuning adapté.

Structurez vos données en paires instruction/réponse, au format JSONL, où chaque ligne contient l’entrée (accompagnée de tout contexte utile) et la sortie exacte que vous souhaitez obtenir.

Par exemple, consultez des jeux de données publics comme Alpaca-cleaned, consacré aux instructions générales, ou Dolly de Databricks, ou encore banking77, propre à une tâche, qui regroupe plus de 13 000 requêtes d’assistance réelles étiquetées selon 77 intentions.

Pour une tâche ciblée, quelques centaines à quelques milliers d’exemples propres et variés peuvent suffire à faire évoluer le comportement, à condition que ces exemples reflètent les entrées réelles en production, y compris les cas limites, et soient formatés de manière cohérente.

Vous n’avez pas encore de paires entrée/sortie ? Constituez le jeu à partir des données dont vous disposez déjà, comme des tickets d’assistance et leurs meilleures réponses, ou des documents et leurs résumés.

Si vous ne disposez que des sorties, utilisez un modèle plus performant pour générer une entrée plausible pour chacune d’elles, ou rédigez à la main un petit ensemble initial et étoffez-le à l’aide d’un modèle « enseignant » plus grand, puis conservez les meilleures paires.

Terminez en répartissant les données en jeux d’entraînement, de validation et de test, afin de pouvoir mesurer les performances sur des exemples que le modèle n’a jamais vus.

Étape 3 : Choisir un modèle de base et une méthode

Commencez par un petit modèle open source de 3 à 7 milliards de paramètres et une méthode de fine-tuning efficace en paramètres comme LoRA ou QLoRA.

Les familles de modèles ouverts comme Llama, Mistral et Qwen offrent une base solide que vous pouvez héberger vous-même, et les méthodes PEFT limitent les exigences matérielles : QLoRA quantifie la base en 4 bits, si bien que le fine-tuning d’un modèle 7B ne nécessite qu’une carte grand public de 16 à 24 Go. Un fine-tuning complet du même modèle requiert plusieurs fois cette quantité de mémoire.

Étape 4 : Définir vos hyperparamètres d’entraînement

Voici les principaux paramètres de fine-tuning d’un LLM et les plages de départ suggérées :

• Le taux d’apprentissage détermine l’ampleur de chaque mise à jour des poids. Une étude de Biderman et al. publiée en 2024 a montré que les meilleurs taux pour LoRA étaient environ dix fois plus élevés que pour le fine-tuning complet, généralement de 5e-5 à 5e-4 contre 1e-5 à 5e-5. L’étude recommande de balayer les valeurs de 1e-5 à 5e-4 et de retenir la valeur la plus élevée qui permet un entraînement stable.
• La taille de lot (batch size) correspond au nombre d’exemples à partir desquels le modèle apprend avant chaque mise à jour des poids. Sur un seul GPU, utilisez un petit lot par appareil, de 1 à 8, et l’accumulation de gradient pour atteindre un lot effectif d’environ 16 à 64.
• Le nombre d’époques correspond au nombre de fois où le modèle parcourt l’ensemble du jeu de données. Pour entraîner le modèle à effectuer des tâches spécifiques, 1 à 3 époques constituent une bonne règle empirique, mais les entraînements LoRA en nécessitent souvent davantage.
• Le rang LoRA (r) définit la capacité de l’adaptateur, c’est-à-dire la quantité d’informations qu’il peut apprendre. Commencez avec une valeur comprise entre 8 et 32 pour les tâches simples et augmentez-la pour les plus complexes : dans l’étude sur LoRA de Biderman et al. citée plus haut, l’instruction tuning d’un modèle 7B sur du code a nécessité un rang de 256 pour égaler un fine-tuning complet, tandis qu’un rang de 64 s’en approchait en mathématiques.
• La longueur maximale de séquence correspond à l’entrée la plus longue que l’entraînement traitera. Choisissez-la de façon à couvrir vos exemples les plus longs, dans la limite de la fenêtre de contexte du modèle, car tout ce qui dépasse sera tronqué.
• Le préchauffage (warmup) et la planification (schedule) déterminent la façon dont le taux d’apprentissage augmente puis évolue au cours de l’entraînement. Une courte phase de préchauffage et une décroissance cosinus sont les réglages par défaut habituels. Toutefois, l’étude de Pareja et al. sur les petits modèles a montré que supprimer le préchauffage ne nuisait pas aux scores finaux.

Considérez ces valeurs comme des points de départ pour un balayage d’hyperparamètres, et non comme des réglages figés.

Étape 5 : entraîner le modèle et surveiller la perte

Pendant l’entraînement, surveillez les courbes de perte d’entraînement et de validation pour vérifier que tout fonctionne.

La perte mesure l’écart entre les sorties du modèle et vos exemples ; elle doit diminuer régulièrement au fil de l’entraînement. La perte d’entraînement porte sur les données à partir desquelles le modèle apprend. La perte de validation porte sur les exemples mis de côté.

Si la perte d’entraînement et la perte de validation diminuent ensemble, le modèle apprend à généraliser. Si la perte d’entraînement continue de baisser alors que la perte de validation stagne ou remonte, le modèle mémorise le jeu d’entraînement au lieu d’apprendre le schéma sous-jacent (surapprentissage).

Agrandir

Étape 6 : évaluer, puis déployer

Une faible perte d’entraînement ne garantit pas des sorties correctes : évaluez donc le modèle affiné selon les critères définis à l’étape 1.

Une fois le modèle validé, deux options de déploiement s’offrent à vous :

• Servir l’adaptateur par-dessus le modèle de base et charger les deux à l’exécution ; l’adaptateur reste ainsi interchangeable.
• Fusionner l’adaptateur dans les poids de base pour obtenir un modèle autonome unique, plus simple à héberger.

Utilisez Perplexity pour permettre à votre LLM d’accéder à des informations à jour

Le fine-tuning est le bon choix lorsque vous souhaitez adapter le comportement d’un modèle à vos besoins.

Si votre modèle a besoin d’informations actuelles, en particulier d’informations qui évoluent rapidement, il vous faut un système RAG ou un outil de recherche tiers fiable.

Une pile de récupération personnalisée convient le mieux aux jeux de données propriétaires, comme votre wiki interne, l’historique de votre service client, vos contrats ou votre documentation produit.

Lorsque les connaissances que vous souhaitez exploiter sont publiques, inutile de créer une couche de récupération sur mesure. Perplexity est un moteur de réponses qui renvoie des réponses accompagnées de citations cliquables intégrées, issues d’un index web en temps réel. Son Agent API fournit ces réponses sourcées et ancrées dans le web en un seul appel, afin que votre application puisse s’appuyer sur des sources actuelles.

Questions fréquentes sur le fine-tuning des LLM

Peut-on affiner un LLM gratuitement ?

Oui, vous pouvez affiner gratuitement un petit LLM ouvert. Par exemple, l’offre gratuite de Google Colab fournit suffisamment de ressources GPU pour exécuter QLoRA sur un modèle de 3B à 8B, ce qui suffit amplement pour une tâche ciblée. Vous commencez à payer dès que vous avez besoin de plus de mémoire, d’entraînements plus longs ou d’un modèle de base plus grand que ce que l’offre gratuite permet.

Faut-il posséder son propre GPU, ou peut-on affiner un modèle dans le cloud ?

Vous n’avez pas besoin de posséder un GPU pour affiner des LLM. Les services managés et les fournisseurs de GPU dans le cloud louent le matériel à l’heure : un seul GPU loué suffit pour un entraînement QLoRA sur un petit modèle. L’achat d’un GPU n’est rentable que si vous affinez souvent des modèles ou si vous devez conserver toutes vos données sur vos propres machines.

Combien de temps prend le fine-tuning d’un LLM ?

Pour un petit LLM, un entraînement peut durer de quelques minutes à quelques heures, selon la taille du jeu de données et le matériel. Oumi, par exemple, a réalisé le fine-tuning complet d’un modèle de 0,8B en un peu plus d’une heure sur sa plateforme hébergée.

Avec des modèles plus grands ou des dizaines de milliers d’exemples, cette durée peut atteindre une journée ou plus : les entraînements LoRA d’Emburse sur un modèle 7B ont pris 8 heures pour 5 000 exemples et environ 30 heures pour 50 000 sur un seul GPU de 40 Go.

Peut-on continuer à mettre à jour un modèle affiné à mesure que les données évoluent ?

Vous pouvez relancer un fine-tuning sur des données récentes, mais chaque itération consomme de la puissance de calcul et expose à un risque d’oubli catastrophique. Pour des connaissances qui changent souvent, le RAG est généralement la meilleure solution, puisque vous mettez à jour les documents sources au lieu de réentraîner le modèle.