Fine-tuning, RAG ou prompting : quel levier pour adapter un modèle

« Il faudrait fine-tuner un modèle » — la phrase revient souvent, et neuf fois sur dix c'est la mauvaise réponse. Prompting, RAG et fine-tuning règlent des problèmes différents. Ce tuto te donne une méthode que tu appliques toi-même : diagnostiquer, choisir, puis mettre en œuvre le levier minimal. On déroule sur un cas fil rouge : un assistant qui répond aux clients sur tes prestations.

Étape 1 — Diagnostiquer avant de choisir

Prends une réponse actuelle qui te déçoit et écris ce qui cloche, précisément. Range-la dans une des trois cases :

• « Il ne connaît pas mes données / mon actu » → problème de connaissances.
• « Il connaît le sujet mais répond mal : format, ton, il ignore mes règles » → problème de comportement.
• « Il s'en sort quand je lui explique, mais je me répète » → problème de contexte.

Sur notre assistant : « il invente des tarifs » = connaissances. « il répond en trois paragraphes alors que je veux trois phrases » = comportement. Le levier découle de cette case, pas d'une mode.

Étape 2 — Prompting : toujours d'abord

Le prompting règle la majorité des cas « comportement » et « contexte ». C'est gratuit, instantané, sans infra. Avant tout le reste, teste un prompt système carré :

RÔLE : assistant commercial de [activité].
RÈGLES : réponse en 3 phrases maximum ; jamais de tarif hors de la liste
fournie ; si tu ne sais pas, propose d'écrire à [email].
EXEMPLE de réponse attendue :
« La prestation X coûte 900 €. Elle inclut A et B. Je t'envoie le détail
par mail si tu veux. »

L'exemple (few-shot) fait plus pour le format que dix adjectifs. Si ça règle ton problème, tu t'arrêtes là — beaucoup de « projets fine-tuning » disparaissent après un bon prompt.

Étape 3 — RAG : quand il manque des connaissances

Si le problème est « il ne connaît pas mes documents / mes données à jour », la réponse est le RAG : tu récupères les passages pertinents et tu les injectes dans le prompt au moment de la question. La version minimale, sans base vectorielle, tient en trois temps :

1. Découper tes documents (tarifs, FAQ) en petits morceaux.
2. À chaque question, sélectionner les morceaux pertinents
   (au plus simple : recherche par mots-clés).
3. Les coller dans le prompt : « Réponds uniquement à partir de ces
   extraits : [extraits]. Question : [question]. »

Avantages : connaissances à jour (tu changes les documents, pas le modèle) et vérifiables. Pour notre assistant, le RAG sur la grille tarifaire supprime les tarifs inventés — ce que le fine-tuning ne garantirait jamais.

Étape 4 — Fine-tuning : le comportement, en dernier

Le fine-tuning ré-entraîne le modèle sur des centaines d'exemples pour ancrer un comportement très spécifique et répétitif (un format strict, un style maison constant), quand le prompt devient trop long ou trop cher à répéter. Retiens la règle : le fine-tuning façonne le comportement, pas la mémoire factuelle.

En pratique on n'entraîne pas tout le modèle (coûteux) : on fait du LoRA, qui n'ajoute qu'un petit jeu de poids léger posé sur le modèle de base. Concrètement, ton travail se résume à préparer un dataset propre, une ligne = un exemple :

{"messages": [
  {"role": "user", "content": "Classe ce ticket : « Ma facture est fausse »"},
  {"role": "assistant", "content": "{\"categorie\": \"facturation\", \"urgence\": \"haute\"}"}
]}

Tu charges ce fichier sur la plateforme de fine-tuning de ton fournisseur, qui produit un modèle dérivé. Quelques centaines d'exemples cohérents valent mieux que des milliers bruités : la qualité du dataset est le projet.

Adapter à ton cas

• Assistant sur ta doc → RAG. Point.
• Sorties toujours au même format strict, gros volume → prompting + validation d'abord ; fine-tuning si le prompt devient ingérable ou trop cher en tokens.
• Ton de marque très spécifique et récurrent → fine-tuning léger, une fois le style stabilisé par prompting.
• Combiner : les trois se cumulent. Fine-tuné pour le format + RAG pour les connaissances + bon prompt système, c'est une architecture courante.

En cas de souci

• Fine-tuning qui « oublie » des faits : normal, ce n'est pas son rôle. Bascule les connaissances en RAG.
• RAG qui répond à côté : le problème vient presque toujours du découpage des documents, pas du modèle (voir le tuto dédié au RAG en production).
• Dataset trop petit ou incohérent : résultats erratiques. Nettoie et homogénéise avant d'ajouter du volume.
• Effort disproportionné : dans le doute, commence par le prompting, mesure, et ne monte d'un cran que si un besoin précis reste non couvert. L'ordre prompting → RAG → fine-tuning est aussi un ordre de coût croissant.