Few-shot prompting : quand et comment donner des exemples

Le few-shot prompting consiste à ajouter à votre prompt quelques exemples travaillés, chacun montrant une entrée et la sortie souhaitée, pour que le modèle en déduise le schéma. C'est surtout utile quand le résultat est plus facile à montrer qu'à décrire : un ton précis, une classification aux frontières subtiles, un format de sortie fixe ou la façon de traiter des cas délicats. Deux à cinq exemples variés et de qualité suffisent généralement. Associez-les à des instructions claires, signalez-les clairement comme exemples et vérifiez qu'ils améliorent vraiment les résultats sur vos propres cas.

Cet article fait partie de notre série sur le prompting. Pour la méthode d'ensemble, commencez par le guide de l'ingénierie de prompt en entreprise.

Zero-shot, one-shot et few-shot

Approche	Contenu du prompt	Usage typique
Zero-shot	Instructions seules	Tâches courantes que le modèle maîtrise, comme résumer ou traduire
One-shot	Instructions et un exemple	Montrer une fois un format ou un style
Few-shot	Instructions et plusieurs exemples	Distinctions subtiles, style constant, sorties structurées

Les modèles actuels gèrent bien de nombreuses tâches en zero-shot. Le few-shot n'est pas un réflexe à appliquer partout, mais un outil pour les cas où les instructions seules donnent des résultats irréguliers.

Quand les exemples aident le plus

• Style maison et ton. Décrire « chaleureux sans bavardage, direct sans sécheresse » est difficile. Deux réponses types le rendent concret.
• Classification aux frontières floues. Si « réclamation » et « retour d'expérience » se chevauchent, des exemples de cas limites montrent où passe la ligne.
• Formats exacts. Un échantillon du JSON, du tableau ou du rapport attendu réduit les erreurs de format.
• Cas particuliers. Un exemple de réponse quand une information manque apprend au modèle à faire de même.
• Conventions métier. Formulations, abréviations ou structures propres à un secteur.

Quand les exemples ne valent pas la peine

• Tâches simples et bien comprises. Les exemples coûtent des tokens sans améliorer le résultat.
• Quand vous ne disposez pas de bons exemples. De mauvais exemples enseignent de mauvais résultats.
• Tâches très variées. Si chaque demande est différente, les exemples peuvent orienter le modèle vers le mauvais schéma.
• Exemples très longs. Si chaque exemple est un document entier, le prompt devient coûteux et le modèle risque de se concentrer sur les exemples plutôt que sur l'entrée réelle.

Un exemple concret : classer des messages clients

Instructions seules (zero-shot) :

Classe le message client dans l'une de ces catégories : suivi_commande, retour,
reclamation, question_produit, autre. Réponds uniquement par la catégorie.

Cela fonctionne pour les cas clairs, mais peut hésiter sur un message comme « La chaise est arrivée rayée, puis-je la renvoyer ? ». Réclamation ou retour ?

Version few-shot :

Classe le message client dans l'une de ces catégories : suivi_commande, retour,
reclamation, question_produit, autre. Réponds uniquement par la catégorie.

Règles :
- Si le client veut renvoyer un article, utilise retour, même s'il est aussi
  mécontent.
- Utilise reclamation quand le client exprime une insatisfaction sans demander
  de retour ni d'échange.

Exemples :
Message : "Où est ma commande ? Elle devait arriver hier."
Catégorie : suivi_commande

Message : "La chaise est arrivée rayée, puis-je la renvoyer ?"
Catégorie : retour

Message : "Votre livreur a été impoli et a laissé le carton sous la pluie."
Catégorie : reclamation

Message : "Le bureau en chêne existe-t-il aussi en 160 cm ?"
Catégorie : question_produit

Classe maintenant :
Message : """[message client]"""
Catégorie :

Trois points à noter : les règles énoncent explicitement la décision, les exemples couvrent la frontière délicate, et chaque catégorie apparaît une fois. Les exemples appuient les règles ; ils ne les remplacent pas.

Combien d'exemples ?

Il n'existe pas de nombre universel. Une approche pratique :

1. Commencez en zero-shot avec une instruction claire.
2. Si les résultats sont irréguliers, ajoutez deux ou trois exemples couvrant les cas problématiques.
3. Testez sur un ensemble fixe d'entrées réelles.
4. N'ajoutez d'exemples que s'ils corrigent des échecs précis.

Dans une application, les exemples font partie de l'entrée à chaque requête. Cinq exemples de 150 tokens ajoutent 750 tokens par appel. Sur de nombreuses requêtes, cela s'accumule ; notre article sur la tarification des API LLM montre comment le calculer, et le cache de prompt peut réduire le coût d'un bloc d'exemples stable.

Bien choisir ses exemples

• Représentatifs : ils doivent ressembler à de vraies entrées, pas à des cas idéalisés.
• Variés : longueurs, formulations et situations différentes, pour que le modèle apprenne le schéma et non la surface.
• Équilibrés : en classification, évitez une majorité d'exemples d'une même catégorie, que le modèle pourrait privilégier.
• Exacts : chaque sortie d'exemple doit être exactement ce que vous voulez. Un seul exemple bâclé peut être copié.
• Avec des cas limites : au moins un exemple de la situation où le modèle échoue d'habitude.
• Courts : réduisez-les à ce qui démontre le point.

Formater les exemples

Une structure claire aide le modèle à séparer les exemples de la tâche réelle :

• Utilisez des libellés constants comme « Message : » et « Catégorie : », ou « Entrée : » et « Sortie : ».
• Séparez les exemples par des lignes vides ou des délimiteurs.
• Encadrez-les éventuellement de balises, par exemple <example>...</example>.
• Placez l'entrée réelle en dernier, au même format que les exemples, suivie du libellé de sortie.
• Précisez : « Les exemples illustrent le format et le style. N'en reprends pas le contenu. »

Éviter la copie excessive

Problème fréquent : le modèle imite trop les exemples, reprend des formulations ou impose la même structure à chaque réponse. Pour le limiter :

• Variez la formulation et la longueur des exemples.
• Prenez des exemples de contextes différents.
• Dites ce qui doit être repris (« ton et structure ») et ce qui ne doit pas l'être (« formulations, noms, faits précis »).
• Évitez les exemples contenant des faits précis que le modèle pourrait répéter ailleurs.
• Si le problème persiste, réduisez le nombre d'exemples ou décrivez plutôt le schéma en mots.

Le few-shot pour le style rédactionnel

Pour la rédaction, des exemples de bons textes passés sont souvent le moyen le plus efficace de transmettre un style. Un schéma qui fonctionne bien :

Rédige une réponse à l'e-mail client ci-dessous dans notre style maison.

Notre style : aimable, direct, phrases courtes, pas de points d'exclamation, toujours
terminer par une prochaine étape claire.

Deux réponses que nous jugeons réussies (pour le style uniquement, pas le contenu) :
<example>[réponse passée 1]</example>
<example>[réponse passée 2]</example>

E-mail client :
"""[e-mail]"""

Retirez les données personnelles des réponses passées avant de les utiliser comme exemples, conformément à la charte IA de votre entreprise.

Le few-shot dans les prompts système

Dans les applications, les exemples figurent souvent dans le prompt système pour s'appliquer à chaque conversation. Gardez-les courts, clairement signalés, et revoyez-les à chaque mise à jour des règles, pour que exemples et instructions ne se contredisent jamais. Rédiger un prompt système explique où les exemples s'insèrent dans la structure globale.

Few-shot prompting ou fine-tuning

Les deux enseignent au modèle par l'exemple, mais très différemment :

	Few-shot prompting	Fine-tuning
Où se trouvent les exemples	Dans le prompt, à chaque requête	Intégrés au modèle par l'entraînement
Nombre d'exemples	Une poignée	Généralement beaucoup plus
Effort de mise en place	Quelques minutes	Préparation des données, entraînement, évaluation
Structure de coûts	Plus de tokens d'entrée par requête	Coût d'entraînement plus utilisation du modèle
Souplesse	Exemples modifiables à tout moment	Réentraînement nécessaire pour changer

Commencez par le few-shot. N'envisagez le fine-tuning qu'avec beaucoup d'exemples de qualité, un fort volume et une tâche stable. Voir RAG ou fine-tuning pour une comparaison complète.

Vérifier que les exemples aident

1. Constituez un jeu de test d'entrées réelles, y compris difficiles.
2. Lancez le prompt sans exemples et notez les résultats.
3. Lancez-le avec exemples et comparez.
4. Examinez les échecs des deux versions. Les exemples les ont-ils corrigés, ou en ont-ils créé de nouveaux ?
5. Ne gardez que les exemples qui méritent leur place.

Les erreurs fréquentes

• Des exemples qui contredisent les instructions. Le modèle risque de suivre l'exemple plutôt que la règle.
• Des exemples tous semblables. Le modèle apprend un schéma trop étroit.
• Des catégories déséquilibrées. Le modèle penche vers la plus fréquente.
• Des exemples erronés. Ils sont reproduits.
• Des exemples à la place des instructions. Combinez les deux : énoncez la règle, puis montrez-la.
• Ne jamais revoir les exemples. Mettez-les à jour quand vos règles, produits ou style changent.

À vous de jouer

Le générateur de prompt IA propose un champ pour un exemple de bon résultat et ajoute une consigne demandant au modèle d'en suivre le style et la structure, pas le contenu. Collez-y l'un de vos meilleurs résultats passés et comparez avec la version sans exemple. Pour d'autres points de départ, consultez nos modèles de prompts pour l'entreprise.