Fine-tuning

Ce que l'on modifie vraiment

Affiner ne consiste pas à repartir de zéro. On charge un modèle déjà entraîné, on le fait passer sur quelques centaines ou quelques milliers d'exemples de la tâche visée, et l'on ajuste ses paramètres avec un pas d'apprentissage faible. L'objectif est de déplacer légèrement son comportement, pas de le remplacer. Un affinage trop long ou trop fort efface les capacités générales acquises. C'est un risque réel, souvent découvert après coup, quand le modèle ne sait plus répondre hors de son nouveau domaine.

Le résultat est un nouveau jeu de poids, à héberger et à versionner. Il faut donc prévoir l'infrastructure, la sauvegarde et la comparaison avec la version précédente. Un modèle affiné n'est pas un fichier de configuration : c'est un artefact lourd, qui doit être traité comme un livrable logiciel, avec ses tests et sa documentation. Cette discipline distingue un projet industriel d'une expérimentation. Sans elle, personne ne sait plus quelle version tourne réellement en production.

Les données font le résultat

La qualité des exemples décide de tout. Quelques centaines de cas bien rédigés, cohérents et représentatifs produisent souvent un meilleur résultat qu'un volume important de données approximatives. Chaque exemple doit montrer la réponse attendue dans son intégralité, y compris les refus, les demandes de précision et les cas où l'information manque. Les cas ambigus enseignent l'ambiguïté. Il faut aussi vérifier les droits sur les textes utilisés, car un jeu constitué de réponses obsolètes transmet une erreur durable.

La préparation demande plus de temps que l'entraînement lui-même. Il faut collecter, nettoyer, anonymiser, relire, équilibrer les catégories et séparer un jeu de contrôle. Les équipes sous-estiment presque toujours cette phase. Un projet d'affinage qui échoue échoue rarement à cause du calcul : il échoue parce que les exemples étaient faux, incohérents ou trop peu nombreux pour couvrir la variété des demandes réelles. Compter le temps de relecture évite les mauvaises surprises.

Les méthodes légères

Réentraîner tous les poids d'un grand modèle coûte cher et exige du matériel conséquent. Les méthodes d'adaptation légère contournent cette difficulté en ajoutant un petit module entraînable, tout en gardant le modèle d'origine figé. LoRA est la plus connue : elle réduit fortement la mémoire nécessaire et permet de produire plusieurs variantes pour plusieurs usages à partir du même modèle de base. C'est ce qui rend l'affinage accessible à des équipes modestes.

Ces méthodes ont leurs limites. Elles conviennent bien à un style, un format ou une terminologie, moins bien à l'acquisition d'un corpus de connaissances volumineux. Pour un savoir documentaire, la recherche augmentée reste plus simple à mettre à jour : corriger un document suffit, alors qu'un affinage demande de refaire l'opération. Le choix dépend donc de la nature du besoin, pas de la mode technique. Un mélange des deux est fréquent dans les projets matures.

Quand cela n'en vaut pas la peine

Trois signaux doivent faire renoncer. Si une consigne bien écrite et quelques exemples suffisent, l'affinage ajoute du coût sans bénéfice. Si le besoin est de connaître des documents qui changent souvent, la recherche documentaire est plus adaptée. Si l'équipe ne peut pas maintenir un jeu de données à jour, le modèle se dégradera à mesure que la réalité évolue. Ces trois cas couvrent une grande partie des demandes, et les reconnaître tôt économise des semaines de travail.

L'affinage se justifie quand le comportement attendu est stable, répétitif et difficile à décrire. Classification interne, extraction structurée, rédaction selon un canevas maison, reformulation dans un jargon métier : ces tâches se prêtent bien à l'exercice. Il faut alors mesurer le gain par rapport à une solution plus simple, sur le même jeu de test, et vérifier qu'il justifie le coût d'exploitation. Sans comparaison, l'affinage devient un choix de confort, difficile à défendre devant un comité de direction.