Les exemples (few-shot)#

Montrer deux entrées et leurs sorties attendues remplace une page de consignes — et marche mieux.

Temps de lecture : 13 min | Niveau : Débutant

Ce que tu sauras faire après#

• Choisir entre zéro, un et plusieurs exemples selon la tâche.
• Sélectionner des exemples représentatifs qui couvrent les cas limites.
• Formater tes exemples pour que le modèle ne les confonde pas avec les instructions.
• Appliquer la méthode sur deux cas data : normaliser des libellés produits, classer des tickets.
• Éviter le piège des exemples trop nombreux ou contradictoires.

📚 Le vocabulaire en 30 secondes#

Few-shot prompting (aussi appelé multishot) : glisser dans le prompt des paires entrée → sortie pour montrer au modèle le comportement attendu.

Microsoft précise un point important : ce n'est pas de l'apprentissage au sens où le modèle serait modifié. Les exemples conditionnent seulement la réponse pour cette requête-là. Rien n'est mémorisé.

Anthropic recommande 3 à 5 exemples pour de bons résultats. Google recommande d'en inclure quasiment toujours : « les prompts sans exemples few-shot sont probablement moins efficaces ».

🎯 Ce que les exemples corrigent vraiment#

Un exemple est le bon outil quand tu n'arrives pas à décrire une règle, mais que tu sais la reconnaître. C'est exactement ta situation quand tu as du mal à formuler.

Trois choses qu'un exemple transmet mieux qu'une phrase :

1. Le format exact. Séparateurs, casse, ordre des champs, présence ou non de guillemets.
2. Le niveau de détail. Une ligne ou un paragraphe ? Le modèle copie la longueur de tes exemples.
3. Les règles implicites. Ce que tu fais sans savoir l'expliquer : abréviations tolérées, arbitrages entre deux catégories.

Microsoft donne une illustration nette de ce dernier point : à partir de trois titres de presse étiquetés Baseball, Soccer, Football, le modèle déduit « Basketball » pour un quatrième titre, alors qu'aucun exemple ne contenait ce label. Les exemples enseignent la catégorie de réponse attendue, pas seulement la liste des réponses possibles.

Les 3 critères d'un bon exemple#

Anthropic les nomme explicitement : Relevant, Diverse, Structured.

1. Pertinent (relevant)#

L'exemple doit refléter ton cas d'usage réel. Si tes vraies données sont sales, tes exemples doivent être sales. Un exemple propre sur une entrée sale ne sert à rien.

2. Divers (diverse)#

Il doit couvrir les cas limites et varier assez pour que le modèle ne capte pas un motif non voulu.

C'est le critère le plus souvent raté. Si tes 4 exemples commencent tous par une majuscule et font tous 3 mots, le modèle apprend « majuscule + 3 mots » au lieu de la règle que tu visais.

Checklist de diversité, à passer sur ton jeu d'exemples :

• [ ] Un cas franchement simple
• [ ] Un cas ambigu, à la frontière entre deux catégories
• [ ] Un cas sale (faute de frappe, accent manquant, espaces en trop)
• [ ] Un cas vide ou incomplet, avec la sortie attendue dans ce cas
• [ ] Un cas qui tombe dans la catégorie « autre / inconnu »

Le quatrième et le cinquième sont ceux qui te font gagner le plus de temps en production.

3. Structuré (structured)#

Enveloppe les exemples dans des balises <example>, et le groupe entier dans <examples>, pour que le modèle les distingue des instructions. Sans délimiteur, le modèle peut prendre ton exemple pour une consigne — ou pour la donnée à traiter.

Google ajoute une règle simple et impitoyable : la structure et le formatage des exemples doivent être identiques entre eux, sinon tu obtiens des sorties au format indésirable. Un seul exemple mal aligné suffit à casser la série.

🧹 Cas 1 — Normaliser des libellés de produits#

Situation classique en data engineering : un fichier fournisseur où le même produit s'écrit de six façons.

Avant#

Nettoie ces libellés de produits.

- lait demi ecreme 1L
- LAIT DEMI-ÉCRÉMÉ 1 LITRE
- lait 1/2 écrémé  1l

Le modèle va « nettoyer » selon sa propre idée : parfois tout en minuscules, parfois en Title Case, parfois en inventant une catégorie. Deux exécutions donnent deux résultats différents. Impossible de bâtir un pipeline dessus.

Après#

Tu normalises des libellés de produits alimentaires issus de fichiers fournisseurs.

Règles de normalisation :
- Minuscules, accents conservés.
- Format : <produit> <variante> <contenance><unité>, dans cet ordre.
- Unités normalisées : l, cl, ml, kg, g. Pas d'espace entre le nombre et l'unité.
- Un seul espace entre les mots.
- Si la contenance est absente ou illisible, mets « inconnue » dans ce champ.

<examples>
<example>
<entree>lait demi ecreme 1L</entree>
<sortie>lait demi-écrémé 1l</sortie>
</example>
<example>
<entree>LAIT DEMI-ÉCRÉMÉ 1 LITRE</entree>
<sortie>lait demi-écrémé 1l</sortie>
</example>
<example>
<entree>lait 1/2 écrémé  1l</entree>
<sortie>lait demi-écrémé 1l</sortie>
</example>
<example>
<entree>Yaourt nature x4 500 GR</entree>
<sortie>yaourt nature x4 500g</sortie>
</example>
<example>
<entree>jus orange</entree>
<sortie>jus d'orange inconnue</sortie>
</example>
<example>
<entree>  </entree>
<sortie>VIDE</sortie>
</example>
</examples>

Normalise maintenant les libellés ci-dessous. Sortie : un CSV à deux colonnes,
entree;sortie, séparateur point-virgule, sans en-tête, une ligne par entrée,
dans le même ordre que l'entrée. Aucun texte avant ou après le CSV.

<a_normaliser>
[COLLER_ICI_TES_LIBELLES_UN_PAR_LIGNE]
</a_normaliser>

Pourquoi c'est mieux#

Les trois premiers exemples enseignent la même sortie pour trois entrées différentes : c'est ça qui apprend la normalisation, pas le nettoyage. Le quatrième introduit une autre unité (g) et un motif différent (x4), ce qui évite le surapprentissage sur le lait. Le cinquième montre le cas « contenance absente ». Le sixième montre le cas vide, qui sinon produit n'importe quoi. Et le format CSV imposé, dans le même ordre, rend la sortie directement joignable à ton DataFrame.

🎫 Cas 2 — Classer des tickets#

Avant#

Classe ce ticket : "l'export du matin est vide depuis 3 jours"

Le modèle invente une taxonomie. Elle ne sera pas la tienne et elle changera d'un appel à l'autre.

Après#

Tu classes des tickets entrants d'une équipe data.

Catégories autorisées, exactement ces cinq valeurs :
incident_pipeline, qualite_donnee, demande_acces, nouvelle_demande, autre

Règles d'arbitrage :
- Une donnée absente ou un job en échec = incident_pipeline.
- Une donnée présente mais fausse, en double ou incohérente = qualite_donnee.
- Un doute entre incident_pipeline et qualite_donnee se tranche en incident_pipeline.
- Si aucune catégorie ne convient clairement, réponds autre. Ne force jamais.

<examples>
<example>
<ticket>l'export du matin est vide depuis 3 jours</ticket>
<categorie>incident_pipeline</categorie>
<urgence>haute</urgence>
</example>
<example>
<ticket>le CA de mars est en double dans le dashboard</ticket>
<categorie>qualite_donnee</categorie>
<urgence>moyenne</urgence>
</example>
<example>
<ticket>pouvez-vous m'ouvrir le schéma finance sur Snowflake ?</ticket>
<categorie>demande_acces</categorie>
<urgence>basse</urgence>
</example>
<example>
<ticket>il faudrait ajouter la marge par famille dans le rapport hebdo</ticket>
<categorie>nouvelle_demande</categorie>
<urgence>basse</urgence>
</example>
<example>
<ticket>le dag tourne mais les chiffres sont bizarres depuis la migration</ticket>
<categorie>incident_pipeline</categorie>
<urgence>haute</urgence>
</example>
<example>
<ticket>merci pour hier</ticket>
<categorie>autre</categorie>
<urgence>basse</urgence>
</example>
</examples>

Classe le ticket ci-dessous. Réponds uniquement par un objet JSON
{"categorie": "...", "urgence": "..."}, sans texte autour.

<ticket>[COLLER_ICI_LE_TICKET]</ticket>

Pourquoi c'est mieux#

Les cinq catégories sont énumérées et fermées : le modèle ne peut plus en inventer. L'exemple 5 est le plus précieux : c'est le cas ambigu, et il montre comment la règle d'arbitrage s'applique en pratique. L'exemple 6 couvre le bruit (« merci pour hier ») qui sinon serait classé de force dans une vraie catégorie. Chaque catégorie apparaît au moins une fois, sinon le modèle sous-utilise celles qui manquent.

Pour une classification appelée en production, l'énumération dans le prompt ne suffit pas toujours. Anthropic recommande de passer par un outil avec un champ enum contenant tes labels valides, ou par les sorties structurées, ce qui garantit la conformité au lieu de l'espérer. Voir le fichier 06.

⚖️ Combien d'exemples, concrètement#

Si tu as besoin de plus de 8 exemples pour que ça marche, le problème n'est probablement pas le nombre d'exemples : c'est que ta règle n'est pas claire, ou que la tâche devrait être découpée en deux.

Astuce : fais-toi aider pour construire tes exemples#

Anthropic suggère explicitement de demander au modèle d'évaluer tes exemples sur leur pertinence et leur diversité, ou d'en générer d'autres à partir de ton jeu initial. Template prêt à l'emploi :

Voici mon jeu d'exemples few-shot pour une tâche de [DECRIRE_LA_TACHE].

<examples>
[COLLER_ICI_TES_EXEMPLES]
</examples>

1. Dis-moi quels cas limites ne sont pas couverts par ce jeu.
2. Dis-moi si deux exemples se contredisent ou enseignent la même chose en double.
3. Repère les motifs non intentionnels que le modèle risque d'apprendre
   (longueur toujours identique, même casse, même structure de phrase).
4. Propose 3 exemples supplémentaires qui comblent les manques, au même format.

A retenir#

• Les exemples conditionnent la réponse pour cette requête seulement : rien n'est mémorisé entre deux appels.
• Vise 3 à 5 exemples. Au-delà de 8, tu risques le surapprentissage.
• Trois critères : pertinents, divers, structurés (balises <example> dans un bloc <examples>).
• Le cas limite et le cas vide sont tes exemples les plus rentables, pas le cas simple.
• Le formatage doit être identique d'un exemple à l'autre, sinon la sortie devient irrégulière.
• Un exemple sert surtout quand tu sais reconnaître la bonne réponse sans savoir décrire la règle.
• Demande au modèle de critiquer et compléter ton jeu d'exemples.

Sources#

• Prompting best practices — Anthropic
• Prompt design strategies — Google Gemini API
• Prompt engineering techniques — Microsoft Foundry / Azure OpenAI
• Prompt engineering — OpenAI
• Tutoriel interactif de prompt engineering — Anthropic (GitHub) — le chapitre Anthropic 1P/07_Using_Examples_Few-Shot_Prompting.ipynb fait tourner le few-shot avec exercices corrigés
• NirDiamant/Prompt_Engineering — code d'exemple sur le few-shot : all_prompt_engineering_techniques/few-shot-learning.ipynb, et le zero-shot dans zero-shot-prompting.ipynb du même dossier