Fine-tuning de LLM

Un fine tuning LLM part d’un modèle généraliste. L’équipe prépare des paires entre une entrée réaliste et la sortie attendue, puis un entraînement ajuste certains paramètres afin de rapprocher les réponses futures de ces exemples. Le jeu ne doit pas seulement montrer les cas faciles. Il doit inclure les formulations courantes, les dossiers incomplets, les exceptions connues et la réponse attendue lorsqu’aucune décision ne peut être proposée.

Cette technique apprend une manière de répondre. Elle ne donne pas au modèle un accès direct à un référentiel qui change chaque semaine. Une procédure mise à jour, un tarif révisé ou un contrat nouveau restent hors de portée si ces éléments ne sont pas fournis au moment de la demande. C’est une différence importante avec le RAG, qui sélectionne des documents au moment où l’utilisateur pose sa question.

1. Définir la tâche : classer, extraire, reformater ou rédiger selon une règle observable.
2. Constituer les exemples : retirer les données inutiles, expliquer les cas limites et faire relire les réponses par le métier.
3. Séparer les contrôles : réserver des cas jamais vus pour évaluer le modèle plutôt que vérifier sa mémoire.
4. Comparer : mesurer le modèle adapté face à une instruction simple et à une version avec quelques exemples dans le contexte.

Le choix du modèle, la version du jeu d’apprentissage et les paramètres de l’essai doivent être conservés. Sans cette trace, une équipe ne peut pas expliquer pourquoi un résultat a changé ni reproduire une sortie utile. Un audit IA peut établir ce protocole avant qu’un entraînement ne soit lancé.

L’adaptation devient pertinente lorsque la valeur vient d’un comportement répétable. Une équipe peut, par exemple, vouloir transformer des comptes rendus libres en catégories précises, produire un objet structuré selon un schéma interne ou appliquer un vocabulaire rédactionnel contrôlé. Dans ces situations, les exemples relus décrivent mieux la décision attendue qu’une collection de documents à retrouver.

Il faut néanmoins commencer par les options plus simples. Un prompt engineering clair, complété par quelques démonstrations dans le contexte, résout parfois le besoin sans entraîner de version spécialisée. Cette première étape révèle aussi les ambiguïtés du processus métier : deux experts qui annotent différemment le même dossier n’offrent pas encore une base saine pour l’adaptation.

• Choisissez l’adaptation pour une décision ou une forme de sortie durable.
• Choisissez le RAG quand la réponse dépend d’un corpus qui doit rester à jour et identifiable.
• Associez les deux si le modèle doit respecter un format stable tout en citant des sources actualisées.
• Conservez une règle déterministe lorsque les conditions sont simples, complètes et ne demandent aucune interprétation.

Un projet de IA générative doit donc documenter l’alternative écartée. Cela évite de transformer un défaut de données, d’instruction ou d’interface en problème d’entraînement. Nous déconseillons cette voie quand le besoin n’est pas stabilisé, quand l’équipe ne dispose pas de réponses de référence ou quand le coût d’une erreur dépasse la capacité de relecture prévue.

La décision ne se prend pas sur une démonstration isolée. Elle se prend après comparaison de jeux de tests représentatifs, avec une personne capable de dire quel résultat est acceptable et pourquoi.

Un modèle adapté peut reproduire les défauts contenus dans ses exemples : libellé erroné, pratique ancienne, biais de classement ou donnée confidentielle placée sans nécessité dans une entrée. Il peut aussi améliorer la moyenne tout en échouant sur une catégorie rare mais importante. La validation doit donc examiner chaque classe de dossier, les refus, les sorties vides et les cas pour lesquels le modèle répond avec une assurance injustifiée.

Le jeu de test mérite une gouvernance propre. Il ne doit pas être réinjecté dans l’apprentissage après chaque correction, sinon il cesse de jouer son rôle de contrôle indépendant. L’équipe conserve les annotations initiales, la raison des modifications et la date à laquelle une règle métier a changé. Ces éléments permettent de décider s’il faut constituer une nouvelle version ou retirer le service en attendant une revue.

• Vérifiez les droits d’usage des données avant leur préparation.
• Évaluez les résultats par type de demande, pas seulement sur un score global.
• Prévoyez une sortie humaine et une procédure de correction pour chaque prédiction contestable.
• Testez à nouveau lors d’un changement de modèle, de fournisseur ou de périmètre métier.

Dans une démarche de conseil IA, le livrable utile est autant la décision de ne pas entraîner que la recette retenue. Un modèle spécialisé ne doit jamais masquer l’origine de ses limites. L’utilisateur doit savoir quelle tâche il peut lui confier, quelle preuve contrôler et à quel moment interrompre le traitement.

Le déploiement progressif aide à recueillir des corrections dans le travail réel. Ces corrections deviennent des candidats à l’évaluation suivante, pas des données ajoutées automatiquement sans relecture.