L’essentiel
En one-shot, vous fournissez un seul exemple complet de la tâche. En few-shot, vous en fournissez quelques-uns. Chaque démonstration montre une entrée et la sortie attendue : elle enseigne temporairement un motif dans le contexte de la requête, sans modifier durablement le modèle. Cette technique est utile lorsque le résultat souhaité est plus facile à montrer qu’à décrire.
Un exemple médiocre peut ancrer une erreur. Choisissez des cas exacts, cohérents avec vos instructions et assez variés pour représenter la tâche réelle. Mesurez ensuite le résultat sur des entrées qui ne figuraient pas dans les démonstrations.
Une démonstration, pas une anecdote
Un bon exemple comporte les mêmes champs que la future demande. Pour une classification, montrez le texte d’entrée et une étiquette autorisée. Pour un e-mail, montrez les données disponibles puis le message final. Pour une extraction, montrez le document et la structure produite. Si l’exemple contient des informations que la nouvelle entrée n’aura jamais, le modèle peut apprendre un motif trompeur.
Le one-shot suffit souvent à fixer une convention de présentation ou un ton. Le few-shot aide à matérialiser plusieurs catégories, des variations de longueur ou des cas limites. Le nombre optimal n’est pas universel : plus d’exemples occupent davantage de contexte et peuvent introduire des contradictions. Commencez par un, ajoutez seulement ce qui corrige un écart mesuré.
Choisir des exemples qui généralisent
- Représentatifs : ils ressemblent aux entrées réellement rencontrées, y compris en longueur et en vocabulaire.
- Diversifiés : ils couvrent des catégories et difficultés différentes sans multiplier les variantes redondantes.
- Corrects : chaque étiquette, fait et format a été relu avant d’être donné comme référence.
- Équilibrés : une classe rare ne disparaît pas de la démonstration si elle compte dans l’usage réel.
- Anonymisés : les exemples ne deviennent pas un moyen détourné d’exposer des données sensibles.
L’ordre peut influencer certains modèles. Testez au moins une permutation lorsque l’enjeu est important, et ne placez pas systématiquement le même type de cas en dernier. Les travaux fondateurs sur l’apprentissage en contexte ont montré l’intérêt des démonstrations, mais les performances varient avec le modèle, la tâche, les exemples et leur présentation.
Quand utiliser ou éviter cette technique
Utilisez des démonstrations pour une taxonomie interne, un style éditorial précis, une extraction à champs fixes ou un format dont les nuances résistent aux descriptions. Restez en zero-shot si la tâche est déjà stable : un exemple supplémentaire complexifie alors la maintenance sans apporter de valeur.
Évitez le few-shot si vous ne disposez que de cas douteux, si les catégories changent chaque semaine ou si les exemples risquent d’être pris pour des faits concernant la nouvelle entrée. Pour un système automatisé, complétez les démonstrations par une validation de schéma, des tests et une gestion des cas inconnus.
Exemple avant / après : classer des demandes de support
Avant
Classe le message en « facturation », « incident » ou « question » : “Je ne reconnais pas le montant de 49 € prélevé hier.”
La tâche paraît simple, mais une « question » sur un prix pourrait être confondue avec la facturation. Une démonstration clarifie la frontière.
Après, avec deux démonstrations
Entrée : « Quel est le prix du forfait équipe ? » Sortie : question.
Entrée : « Deux abonnements apparaissent sur ma facture. » Sortie : facturation.
Nouvelle entrée : « Je ne reconnais pas le montant de 49 € prélevé hier. » Sortie attendue : une seule étiquette autorisée.
Les exemples montrent que la catégorie dépend d’une opération déjà facturée, pas de la présence du mot « prix ».
Prompt à copier : few-shot propre
TÂCHE
Classe chaque message dans une seule catégorie :
[liste et définition courte de chaque catégorie].
Si aucune catégorie ne convient, réponds « autre ».
DÉMONSTRATIONS
Entrée : [exemple représentatif 1]
Sortie : [étiquette exacte]
Entrée : [exemple représentatif 2 ou cas limite]
Sortie : [étiquette exacte]
Entrée : [exemple représentant une autre catégorie]
Sortie : [étiquette exacte]
NOUVELLE ENTRÉE
[message à classer]
FORMAT
Réponds uniquement avec l’une des étiquettes autorisées.Exercice guidé : construire un jeu de démonstrations
Créez trois catégories d’avis sur une application : bug, demande de fonction et appréciation.
- Définissez chaque catégorie en une phrase.
- Rédigez un exemple clair pour chacune.
- Ajoutez un cas limite : un avis positif qui mentionne aussi un petit défaut.
- Testez sur six nouveaux avis, dont deux ambigus.
- Comparez zero-shot, one-shot puis few-shot avec la même grille.
Critères de réussite
- Les exemples ne contiennent aucune donnée réelle.
- Le même format entrée-sortie est utilisé partout.
- La règle d’arbitrage du cas mixte est explicite.
- L’amélioration est mesurée sur les six avis nouveaux.
Erreurs fréquentes
- Montrer une sortie plus longue ou plus riche que celle réellement attendue.
- Mélanger plusieurs formats d’étiquette : « Bug », « BUG » et « problème ».
- Donner cinq exemples presque identiques et aucun cas limite.
- Utiliser des exemples comportant une erreur factuelle ou une exception non signalée.
- Évaluer le prompt sur les mêmes cas que ceux montrés.
- Ajouter une démonstration sans retester les anciennes catégories.
Checklist des démonstrations
- Chaque exemple suit-il exactement la même structure ?
- Les sorties ont-elles été validées par une personne compétente ?
- Les cas sont-ils variés plutôt que redondants ?
- Une règle couvre-t-elle les entrées inconnues ou ambiguës ?
- Les tests utilisent-ils des cas jamais montrés ?
- L’ordre des exemples a-t-il été testé si l’enjeu le justifie ?
Mini-quiz
Question 1. Qu’est-ce qui distingue le one-shot du few-shot ?
Voir la réponse
Le one-shot fournit une seule démonstration entrée-sortie ; le few-shot en fournit quelques-unes pour montrer plusieurs motifs ou cas.
Question 2. Pourquoi tester sur des cas nouveaux ?
Voir la réponse
Pour vérifier que le prompt généralise au-delà des exemples et ne se contente pas de reproduire leur contenu ou leur ordre.
Sources et approfondissement
- Brown et al., Language Models are Few-Shot Learners, prépublication du 28 mai 2020, version du 22 juillet 2020.
- Anthropic, bonnes pratiques et exemples multishot, documentation évolutive consultée le 29 juillet 2026.
- Google AI for Developers, exemples few-shot et itération, documentation évolutive consultée le 29 juillet 2026.
Vérifié le 29 juillet 2026.