Module 1 — Consigne, RAG ou affinage : choisir la bonne réponse
Le cours 16 a montré ce qu'un grand modèle de langage sait faire par défaut, le cours 17 comment lui parler, le cours 18 comment l'ancrer sur vos documents. L'affinage est la quatrième option, la plus coûteuse et la plus tentante à mal utiliser. Ce module trace la frontière entre les trois avant d'aller plus loin, parce qu'un affinage lancé pour la mauvaise raison ne pardonne pas.
Ce que l'affinage apprend vraiment
L'affinage modifie les poids d'un modèle pré-entraîné à partir de vos exemples. Cette phrase paraît anodine ; elle contient la seule règle qui compte. Ce que le modèle retient durablement, ce sont des régularités massives, présentes dans une quantité importante d'exemples : la forme attendue d'une réponse, le style d'écriture, le format de sortie, un vocabulaire de domaine, une convention de citation. Bref, tout ce qui peut être appris par imitation de plusieurs centaines à quelques milliers de démonstrations cohérentes.
Ce que l'affinage n'apprend pas de façon fiable, ce sont des faits particuliers récents ou changeants. Un modèle qui a vu vingt fois une date précise dans son jeu d'affinage ne garantit rien : la même date sera parfois restituée, parfois remplacée par une valeur plausible mais fausse. La mémoire d'un modèle de langage n'est pas une base de données, elle reste une distribution statistique. Cette distinction guide toute la décision qui suit.
Pour notre fil rouge — transformer une transcription de réunion en compte rendu structuré — l'affinage est le bon outil : la difficulté n'est pas de connaître un fait, elle est de reproduire une structure de sortie (décisions, points d'action, propriétaires, échéances) avec le ton neutre attendu. Deux mille exemples suffiront à installer cette régularité dans le modèle.
L'arbre de décision
Face à un besoin métier, la question à se poser d'abord n'est jamais « quel modèle affiner ? », c'est « ai-je vraiment besoin d'affiner ? ». L'ordre à suivre est le suivant.
Étape 1 — une consigne bien rédigée suffit-elle ? Le cours 17 a montré qu'une consigne avec deux ou trois exemples résout une part surprenante des besoins. C'est l'option la moins chère : zéro entraînement, changement instantané, retour arrière trivial. Elle échoue quand la tâche demande une structure trop stricte, quand chaque question rallonge la consigne au point de coûter cher, ou quand le style visé n'est pas atteint malgré des exemples.
Étape 2 — la tâche porte-t-elle sur des faits vérifiables dans vos documents ? Si oui, la bonne réponse est RAG (cours 18) et non l'affinage. Une note de service, une procédure, un règlement doivent être cités, pas mémorisés. Un modèle affiné sur ces documents devient impossible à mettre à jour sans réentraînement, ne cite pas ses sources, et ne saura pas dire « je ne sais pas » quand le document est manquant.
Étape 3 — la tâche est-elle un motif que l'on apprend par démonstration ? Format de sortie contraint, style d'écriture spécifique, extraction structurée, classification fine : c'est le territoire de l'affinage. La condition pratique est de disposer d'au moins plusieurs centaines d'exemples de qualité, homogènes dans leur format.
Le coût total, honnêtement
Comparer les trois options exige de sortir du seul coût de calcul, qui trompe.
| Critère | Consigne | RAG | Affinage |
|---|---|---|---|
| Mise en place | quelques heures | quelques jours | quelques semaines |
| Coût par requête | jetons de la consigne | jetons des passages | quasi nul |
| Mise à jour d'un fait | modifier la consigne | réindexer un fichier | réentraîner |
| Traçabilité | citation de la consigne | citation du passage | aucune |
| Confidentialité | données envoyées | permissions au filtre | modèle en local possible |
L'affinage est le seul à donner un modèle autonome, sans passages à joindre à chaque requête. C'est un avantage décisif quand le coût par appel devient dominant, ou quand le déploiement se fait hors ligne — sur un poste de travail via Ollama, dans notre cas d'école. En contrepartie, sa mise à jour est lourde et sa traçabilité nulle.
Les trois options ne s'opposent pas. Un système sérieux combine souvent un modèle affiné pour le style et le format, un ancrage RAG pour les faits, et une consigne qui orchestre l'ensemble. Le module 9 reviendra sur cette architecture combinée quand nous exporterons le modèle vers Ollama.
Les trois mauvaises raisons de se lancer
Trois raisons reviennent souvent pour justifier un affinage et sont presque toujours des erreurs. La première : « le modèle ne connaît pas nos produits ». Si vos produits ont une fiche descriptive, RAG est la bonne réponse. La deuxième : « le modèle hallucine des chiffres ». L'affinage ne corrige pas ce défaut, il le déplace. La troisième : « on veut un modèle qui nous appartient ». Un modèle affiné dépend toujours de sa base et de sa licence — c'est le sujet du module 9.
En résumé
- L'affinage apprend une forme, un style, un format par imitation ; il n'apprend pas de façon fiable des faits particuliers.
- L'ordre d'attaque est consigne, puis RAG, puis affinage ; on ne saute une étape que quand elle a été essayée sérieusement.
- Le coût total inclut la mise en place, la mise à jour, la traçabilité et la confidentialité — pas seulement le calcul.
- L'affinage est le seul à produire un modèle autonome, précieux hors ligne ou quand le coût par requête domine.
Module suivant : préparer un jeu de données d'instructions qui rendra l'affinage possible.