Le fine-tuning adapte un modèle de langage ou d’image pré-entraîné à une tâche spécifique en l’entraînant davantage sur vos propres exemples. LoRA, abréviation de Low-Rank Adaptation, est une méthode qui entraîne de petits poids d’adaptateur au lieu du modèle entier, ce qui réduit les coûts de calcul et le stockage. Une check-list d’implémentation couvre quand effectuer un fine-tuning, comment préparer les données, comment évaluer et comment déployer en toute sécurité.
LoRA a été introduit par des chercheurs de Microsoft en 2021 et est devenu la norme pour adapter les modèles à poids ouverts tels que Llama, Mistral et Qwen, ainsi que les modèles d’image comme Stable Diffusion. Les fournisseurs hébergés, notamment OpenAI et Google, proposent leur propre fine-tuning géré pour certains modèles, utilisant souvent des méthodes similaires d’efficacité des paramètres en arrière-plan.
Devriez-vous effectuer un fine-tuning ?
Souvent non. De nombreuses tâches marketing sont mieux résolues par de bons prompts, des exemples dans le prompt ou la génération augmentée par récupération (RAG) qui alimente le modèle avec vos documents au moment de la réponse. Le fine-tuning vaut la peine lorsque la même tâche étroite se répète en grand volume et que les prompts seuls donnent des résultats incohérents.
Bonnes raisons d’effectuer un fine-tuning
- Un format de sortie fixe que le modèle continue de casser, comme des attributs de produit structurés
- Une voix de marque que les prompts ne peuvent pas maintenir sur des milliers de sorties
- Tâches de classification, comme le tri des tickets de support ou des avis en catégories
- Réduire les coûts en déplaçant une tâche d’un grand modèle vers un modèle plus petit et ajusté
- Un style visuel cohérent pour la génération d’images, en utilisant un LoRA d’image
Mauvaises raisons
- Enseigner au modèle des faits qui changent souvent, comme les prix ou les niveaux de stock
- Réparer une tâche que vous n’avez pas encore définie clairement
- Avoir moins de quelques centaines de bons exemples
Étape 1 : définir la tâche et les critères de succès
Notez l’entrée, la sortie attendue et ce que signifie “bon” en termes mesurables. Les objectifs vagues tels que “meilleure copie” ne peuvent pas être testés, et une tâche qui ne peut pas être testée ne peut pas être ajustée. Pour une tâche de description de produit, “bon” pourrait signifier des attributs corrects, une plage de longueur définie, aucune affirmation interdite et une évaluation du style par un réviseur.
Ensuite, construisez un jeu d’évaluation avant tout entraînement. Prenez 100 à 300 entrées réelles, écrivez ou approuvez des sorties idéales et mettez-les de côté. Ce jeu n’entre jamais dans l’entraînement. Chaque version du modèle sera notée par rapport à lui.
Étape 2 : préparer les données d’entraînement
La qualité bat la quantité. Quelques centaines d’exemples soigneusement vérifiés surpassent souvent des milliers d’exemples bruyants pour des tâches étroites. Supprimez les doublons, corrigez les erreurs de formatage et assurez-vous que les exemples couvrent les cas limites, tels que des entrées très courtes ou des champs manquants.
Vérifiez les droits sur les données et la confidentialité. Les e-mails des clients, les chats de support et les avis peuvent contenir des données personnelles. Supprimez les noms, e-mails et numéros de téléphone, et confirmez que vous avez une base légale pour utiliser les données pour l’entraînement sous le RGPD ou la KVKK, selon l’endroit où se trouvent vos clients.
Étape 3 : comment choisissez-vous le modèle de base et les paramètres ?
Choisissez le plus petit modèle capable de bien effectuer la tâche, car les modèles plus petits sont moins chers à exécuter. Testez d’abord le modèle de base non ajusté sur votre jeu d’évaluation ; l’écart entre ce score et votre objectif vous indique combien le fine-tuning doit apporter.
Pour LoRA, les paramètres principaux sont le rang (souvent de 8 à 64), le taux d’apprentissage, le nombre d’époques et quelles couches reçoivent des adaptateurs. Des bibliothèques comme Hugging Face PEFT, Axolotl et Unsloth gèrent la mécanique. QLoRA, une variante qui charge le modèle de base en précision 4 bits, vous permet d’ajuster des modèles de taille moyenne sur un seul GPU.
Étape 4 : évaluer honnêtement
Notez chaque version entraînée sur le jeu d’évaluation mis de côté. Utilisez des vérifications automatiques dans la mesure du possible, telles que la validité du format, les champs requis et la longueur, et une révision humaine pour le ton et la précision sur un échantillon.
Surveillez le surapprentissage : la perte d’entraînement diminue tandis que les scores d’évaluation stagnent ou chutent. Si cela se produit, réduisez les époques, baissez le taux d’apprentissage ou ajoutez des exemples plus variés avant d’essayer un rang plus grand. Testez également le comportement général. Un modèle ajusté trop fortement sur une tâche peut devenir moins bon pour suivre des instructions de base ou commencer à répéter des phrases d’entraînement mot pour mot.
Étape 5 : planifier le déploiement en production
Les choix de déploiement dépendent du modèle. Les fine-tunings hébergés s’exécutent sur le point de terminaison du fournisseur. Les modèles à poids ouverts avec des adaptateurs LoRA peuvent s’exécuter sur des serveurs d’inférence tels que vLLM ou Text Generation Inference, et certaines configurations chargent plusieurs adaptateurs sur un modèle de base, ce qui maintient les coûts bas lorsque vous avez des adaptateurs pour différents clients ou tâches.
Check-list de production
- Versionnez chaque adaptateur et enregistrez ses données d’entraînement et son score d’évaluation
- Gardez la version précédente prête pour un retour en arrière rapide
- Enregistrez les entrées et sorties, avec les données personnelles supprimées, pour une révision ultérieure
- Dirigez d’abord une partie du trafic vers la nouvelle version et comparez
- Établissez un cycle de révision, par exemple mensuel, pour réentraîner sur de nouveaux exemples approuvés
Contrôle des coûts
Les coûts d’entraînement sont généralement faibles par rapport à l’inférence à grande échelle. Estimez les demandes mensuelles, les jetons moyens par demande et le prix par jeton ou heure GPU, puis comparez le petit modèle ajusté au grand modèle non ajusté. L’option ajustée gagne souvent sur les coûts d’exploitation même lorsque le grand modèle obtient un score légèrement meilleur. Incluez également les coûts cachés : les heures passées à préparer les données, à réviser les sorties et à réentraîner lorsque la tâche change. Un pilote qui ignore le temps du personnel semblera moins cher sur le papier qu’il ne l’est.
Comment Alien Road applique le fine-tuning et LoRA
Dans un engagement typique, la découverte commence par tester si le prompting ou la récupération résout déjà le problème. De nombreuses demandes s’arrêtent là, ce qui épargne au client un projet d’entraînement. Lorsque le volume et les besoins de cohérence le justifient, nous définissons la tâche, construisons le jeu d’évaluation avec l’équipe du client et vérifions les données pour les informations personnelles et les droits.
La configuration couvre la sélection du modèle de base, les exécutions d’entraînement LoRA et la notation côte à côte par rapport au modèle de base. La mesure se poursuit après le lancement via des échantillons enregistrés révisés selon les mêmes critères, et les rapports montrent les scores de qualité, le coût par millier de sorties et toute dérive. Chaque version d’adaptateur est documentée afin que le client puisse auditer ou revenir en arrière.
Par où commencer cette semaine
Choisissez une tâche répétitive et notez vingt entrées réelles avec des sorties idéales. Exécutez-les via votre modèle actuel avec votre meilleur prompt et notez les résultats.
Si moins de huit sur dix atteignent la norme après les améliorations du prompt, collectez quelques centaines d’exemples supplémentaires. C’est le point où un pilote LoRA commence à avoir du sens.
Continuer la lecture : Optimisation par IA · Optimisation par IA