Prompt, few-shot, RAG ou fine-tuning : l'arbre de décision
Quatre leviers, quatre effets différents
Adapter un modèle, c'est le faire mieux réussir votre tâche. On dispose de quatre leviers, du moins cher au plus cher :
| Levier | Ce qu'on change | Ce que ça apporte | Coût de mise en place |
|---|---|---|---|
| Prompt (consignes) | le texte d'instructions | le comportement attendu, le format de sortie | minutes |
| Few-shot | on ajoute quelques exemples question / réponse dans le prompt | le style, les cas limites, le format | minutes, mais chaque appel coûte plus de tokens |
| RAG (génération augmentée par la recherche) | on injecte des documents trouvés par une recherche | des connaissances à jour ou privées | jours (index, découpage, évaluation) |
| Fine-tuning (réglage supervisé) | les poids du modèle, à partir d'exemples | un comportement stable, des prompts plus courts | jours à semaines (données, job payant, suivi) |
Le réglage supervisé (SFT, supervised fine-tuning) consiste à montrer au modèle des centaines d'exemples « entrée → sortie attendue » ; Vertex AI entraîne alors un petit ensemble de poids supplémentaires (un adaptateur) au-dessus du modèle de base.
L'arbre de décision
flowchart TD A["La tâche échoue avec un bon prompt ?"] -->|"non"| P["Rester au prompt"] A -->|"oui"| B["Il manque des connaissances : documents, données à jour ?"] B -->|"oui"| R["RAG ou outils"] B -->|"non"| C["Quelques exemples dans le prompt corrigent-ils ?"] C -->|"oui"| F["Few-shot"] C -->|"non, ou trop cher à grande échelle"| D["Avez-vous au moins 100 exemples fiables ?"] D -->|"non"| G["Fabriquer des données : distillation, annotation"] D -->|"oui"| T["Réglage supervisé, puis évaluer avant / après"] G --> T
Trois raisons valables de régler un modèle, toutes citées par la documentation Vertex AI :
- le prompt ne donne pas des résultats constants (format qui varie, étiquettes inventées) ;
- la tâche est trop difficile à décrire en consignes (un jugement métier subtil) ;
- vous voulez raccourcir le contexte : remplacer 10 exemples few-shot répétés à chaque appel par un modèle qui « sait déjà ».
La troisième raison est économique : sur des millions d'appels, des centaines de tokens d'exemples en moins par appel, ça se voit sur la facture.
Un assistant interne doit répondre à partir du règlement intérieur, mis à jour chaque trimestre. Quel levier choisir en premier ?
C'est un besoin de connaissances qui changent : le RAG lit la dernière version à chaque question. Un modèle réglé figerait une version du règlement, sans garantie de restituer les faits exactement.
Appliqué aux tickets de support
| Question de l'arbre | Réponse pour les tickets |
|---|---|
| Besoin de connaissances externes ? | Non : classer un ticket ne demande pas de documents |
| Le prompt suffit-il ? | À mesurer (leçon suivante) |
| Volume ? | Élevé : chaque token par appel compte |
| Données disponibles ? | Pas encore : on va les fabriquer par distillation |
On ne décide donc rien avant d'avoir une ligne de base : la note qu'obtient le modèle sans aucune adaptation lourde.
Quelles situations justifient d'envisager un réglage supervisé ? (plusieurs réponses)
Un comportement instable et un contexte few-shot coûteux à grande échelle sont deux raisons classiques. Le prix du jour est une connaissance (outil ou RAG). Et sans mesure, on ne peut ni décider ni prouver un gain.
Exercice : classez ces besoins
Pour chacun, choisissez le premier levier à essayer : prompt, few-shot, RAG ou fine-tuning.
- Répondre aux questions des clients sur leur commande en cours.
- Rédiger les réponses du support dans le ton très particulier de la marque, avec 2 000 réponses validées disponibles.
- Extraire la date et le montant d'une facture en JSON.
- Classer 5 millions de tickets par mois dans 40 catégories, avec un historique de 30 000 tickets déjà classés par des humains.
Voir la solution
- Outil (ou RAG) : le statut d'une commande est une donnée vivante, il faut aller la chercher.
- Few-shot d'abord, puis fine-tuning si le ton reste approximatif : 2 000 réponses validées sont un excellent jeu de réglage.
- Prompt avec sortie structurée (
response_schema) : c'est souvent suffisant ; few-shot pour les formats exotiques. - Fine-tuning très probablement : beaucoup de catégories (le prompt devient long), énorme volume (chaque token compte) et des données étiquetées déjà là. Mais on mesure quand même la ligne de base avant.
Résultat obtenu
Mesure réelle du 2026-10-15 (détails à la leçon suivante) sur 15 tickets de test, modèle gemini-2.5-flash-lite sur Vertex AI :
zero-shot exactitude=0.933 hors_etiquette=0.000 tokens_entree_moyens=88
few-shot exactitude=0.933 hors_etiquette=0.000 tokens_entree_moyens=497Sur cette tâche, 10 exemples few-shot multiplient les tokens d'entrée par 5,6 sans gagner un point. L'arbre de décision a déjà une réponse partielle : le few-shot ne vaut pas son coût ici.
Je sais faire
- Expliquer ce que change chacun des quatre leviers
- Distinguer un besoin de connaissances d'un besoin de comportement
- Citer trois raisons valables de régler un modèle
- Refuser un fine-tuning tant qu'il n'y a pas de ligne de base