Le fine-tuning avec LoRA fait gagner du temps lorsque vous suivez une séquence fixe : confirmez que le prompting et la récupération ne peuvent pas résoudre la tâche, construisez un petit jeu de données propre, entraînez un adaptateur de bas rang sur un modèle ouvert, évaluez-le par rapport à un ensemble de test, et seulement ensuite déployez-le. Sauter les première et quatrième étapes est la cause principale des heures de GPU gaspillées et des modèles décevants.
LoRA, abréviation de Low-Rank Adaptation, entraîne un petit ensemble de poids supplémentaires au lieu de mettre à jour chaque paramètre d’un grand modèle. Le modèle de base reste gelé et l’adaptateur apprend le changement. Les adaptateurs sont de petits fichiers, souvent de quelques mégaoctets à quelques centaines, vous pouvez donc en conserver plusieurs pour différentes tâches et les échanger sur un modèle de base. QLoRA va plus loin en chargeant le modèle de base en précision 4 bits, ce qui permet aux modèles de taille moyenne de s’entraîner sur un seul GPU grand public ou cloud.
Quand le fine-tuning est-il le bon outil ?
Le fine-tuning enseigne bien le style, le format et les comportements restreints. C’est un mauvais moyen d’enseigner à un modèle de nouveaux faits qui changent souvent. Si vous avez besoin de réponses basées sur votre liste de prix actuelle, la récupération (injecter des documents pertinents dans le prompt) est moins chère et plus facile à mettre à jour.
Les bonnes tâches de fine-tuning partagent un modèle : le format de sortie est cohérent, vous avez des centaines ou des milliers de bons exemples, et un modèle général continue de se tromper légèrement sur le ton ou la structure, même avec un prompt soigné.
- Bonne adéquation : descriptions de produits dans un style d’entreprise strict, classification dans vos propres catégories, extraction de champs à partir de documents désordonnés.
- Faible adéquation : répondre à des questions sur des politiques fréquemment mises à jour, recherche générale, tâches avec moins d’une centaine d’exemples.
- Vérifiez d’abord : un prompt bien écrit avec cinq exemples sur un modèle hébergé puissant. Si cela atteint votre niveau de qualité, arrêtez-vous.
Comment préparez-vous les données d’entraînement ?
La qualité des données détermine le résultat plus que n’importe quel hyperparamètre. Collectez des exemples réels d’entrées et les sorties souhaitées, puis nettoyez-les à la main. Supprimez les contradictions, les exemples obsolètes et tout ce qui contient des données personnelles sur lesquelles vous n’avez pas le droit d’entraîner.
Formatez chaque exemple comme une paire prompt-réponse dans le modèle de chat attendu par votre modèle de base. Les incompatibilités de modèles sont une cause classique de sorties étranges après l’entraînement, vérifiez donc la carte du modèle pour connaître le format exact.
Diviser l’ensemble
Gardez 10 à 15 pour cent des exemples comme ensemble d’évaluation que le modèle ne voit jamais pendant l’entraînement. Gardez-le fixe tout au long des expériences, sinon vous ne pourrez pas comparer les exécutions. Si les exemples sont regroupés par client ou par produit, divisez-les par groupe afin que des éléments similaires ne fuient pas au-delà de la limite.
À quoi ressemble une exécution d’entraînement répétable ?
Les équipes qui gagnent du temps écrivent le processus une fois et le réutilisent. Les outils courants incluent Hugging Face Transformers avec la bibliothèque PEFT, TRL pour le fine-tuning supervisé, et des wrappers comme Axolotl ou Unsloth qui réduisent le travail de configuration. Des options hébergées existent également ; plusieurs fournisseurs de modèles proposent un fine-tuning géré où vous téléchargez des données et recevez un modèle ajusté.
- Choisissez un modèle de base dont la licence autorise votre utilisation et dont la taille correspond à votre matériel et à votre budget de latence.
- Commencez avec des paramètres LoRA courants (rang 8 à 16, alpha environ le double du rang) et changez une chose à la fois.
- Enregistrez chaque exécution : version du jeu de données, modèle de base, paramètres, perte d’entraînement et scores d’évaluation.
- Entraînez d’abord pour un petit nombre d’époques ; le surapprentissage se manifeste par une perte d’entraînement décroissante avec de moins bons résultats d’évaluation.
- Enregistrez l’adaptateur, la configuration et le hash exact des données ensemble.
Comment évaluer un adaptateur LoRA ?
Les courbes de perte vous indiquent que l’entraînement a fonctionné, pas que le modèle est utile. Notez les sorties sur l’ensemble de test avec des critères liés à la tâche : correspondance exacte pour la classification, précision des champs pour l’extraction, et une grille d’évaluation pour les tâches d’écriture. Pour l’écriture, demandez à une personne d’évaluer un échantillon à l’aveugle, sans savoir quelle sortie provient du modèle ajusté et laquelle provient de la ligne de base.
Testez également les régressions. Un modèle fortement ajusté sur des descriptions de produits peut devenir moins bon pour suivre des instructions non liées. Gardez un petit ensemble de test général et vérifiez-le à chaque exécution.
Comment déployer et maintenir les adaptateurs ?
Les frameworks de service comme vLLM peuvent charger plusieurs adaptateurs LoRA sur un modèle de base et choisir l’adaptateur par requête. Cela maintient les coûts bas lorsque vous exécutez des adaptateurs séparés par marque ou par tâche. Fusionner l’adaptateur dans les poids de base est une autre option lorsque vous avez besoin d’un modèle autonome.
La maintenance est principalement une maintenance des données. Lorsque le style d’entreprise change, mettez à jour les exemples et réentraînez. Planifiez une revue trimestrielle où vous comparez l’adaptateur aux modèles de base les plus récents ; parfois, un modèle général plus récent avec un bon prompt bat un ancien modèle ajusté.
Quels sont les plus grands gaspilleurs de temps ?
Le plus grand est d’entraîner avant que l’ensemble d’évaluation n’existe. Sans exemples de test fixes, chaque exécution semble prometteuse et personne ne peut dire laquelle est la meilleure. Le deuxième est de changer plusieurs paramètres à la fois, ce qui rend impossible d’apprendre ce qui a aidé. Le troisième est de poursuivre de minuscules améliorations de perte tout en ignorant des problèmes de données évidents, comme des exemples dupliqués ou des sorties qui se contredisent.
L’infrastructure consomme aussi du temps. Fixez les versions des bibliothèques, gardez une image de conteneur pour l’entraînement et écrivez un court README pour chaque projet. La personne suivante, souvent vous-même trois mois plus tard, vous remerciera.
Comment Alien Road applique le fine-tuning et LoRA
Dans un engagement typique, nous passons la phase de découverte à prouver si le fine-tuning est nécessaire. Nous testons la tâche du client avec des modèles hébergés puissants et des prompts soignés, et de nombreux projets se terminent là avec une bibliothèque de prompts au lieu d’un modèle.
Lorsque l’ajustement est justifié, la configuration couvre la collecte d’exemples approuvés, leur nettoyage avec les experts métier du client et l’exécution d’une petite série d’expériences LoRA documentées. La mesure utilise un ensemble d’évaluation fixe et des évaluations humaines à l’aveugle par rapport à la ligne de base sans fine-tuning. Les rapports montrent les scores de qualité, le coût par millier de sorties et une recommandation claire : déployer, itérer ou continuer à faire des prompts.
Par où commencer cette semaine
Choisissez une tâche répétitive de génération ou de classification. Écrivez le meilleur prompt possible, avec cinq exemples, et testez-le sur vingt entrées réelles. Notez combien de sorties nécessitent des modifications. Ce nombre est votre ligne de base ; un projet de fine-tuning n’a de sens que si vous pensez qu’un adaptateur peut le réduire considérablement.
Continuez à lire : Optimisation par IA · Optimisation par IA