Few-shot : apprendre par l’exemple
Objectifs de ce chapitre
- Comprendre le pouvoir des exemples
- Choisir le bon nombre et le bon type d’exemples
- Montrer un pattern plutôt que le décrire
Montrer plutôt que décrire
Sofia passe vingt minutes à décrire le ton de sa marque : « dynamique mais pas agressif, accessible mais crédible, chaleureux mais professionnel »... Le résultat ne ressemble jamais à ce qu'elle imagine. Normal : ces adjectifs sont subjectifs, et le modèle en a une interprétation moyenne qui n'est pas la sienne.
La solution tient en un principe : montre, ne décris pas. Plutôt que d'expliquer un style, donne 2-3 paires entrée → sortie qui l'illustrent. Le modèle est une machine à repérer et prolonger des patterns : des exemples concrets lui transmettent le format, le ton, le niveau de détail et les choix implicites bien mieux que n'importe quelle consigne abstraite. C'est ce qu'on appelle le few-shot prompting : « few shots » = quelques exemples.
Transforme des fonctionnalités en bénéfices. Exemples : Fonction : « batterie 5000 mAh » → Bénéfice : « 2 jours sans recharger » Fonction : « chiffrement de bout en bout » → Bénéfice : « personne ne lit tes messages, pas même nous » Maintenant : « processeur 8 cœurs » →
Remarque ce que les exemples transmettent sans qu'on l'écrive nulle part : la longueur cible (courte), le registre (parlé, concret), la structure (résultat pour l'utilisateur, pas prouesse technique), et même l'astuce du « pas même nous » qui donne le ton. Décrire tout cela aurait pris un paragraphe — et aurait moins bien marché.
Zero-shot, one-shot, few-shot : trois régimes
Le vocabulaire est simple. Zero-shot : tu demandes sans aucun exemple — c'est le régime par défaut, suffisant pour les tâches courantes que le modèle connaît bien. One-shot : un seul exemple, utile pour ancrer un format simple. Few-shot : 2 à 5 exemples, le régime de choix dès que le format ou le ton est spécifique à ton usage.
Le few-shot a un coût : tes exemples consomment de la place dans la fenêtre de contexte et du temps d'écriture. La bonne pratique est donc progressive : commence en zero-shot ; si la sortie est correcte, inutile d'en faire plus. Si le format ou le ton dérive, ajoute des exemples. C'est une escalade, pas un réflexe systématique.
Combien d’exemples ? La règle du 2 à 5
2 à 5 exemples suffisent dans l'immense majorité des cas. En dessous de 2, le modèle ne peut pas distinguer le pattern de l'accident (cette sortie est-elle courte parce qu'il FAUT faire court, ou par hasard ?). Au-delà de 5, les gains deviennent marginaux : tu manges du contexte et du temps sans amélioration mesurable.
Plus important que le nombre : la diversité. Choisis des exemples qui couvrent les cas différents que la tâche rencontrera — un cas facile, un cas tordu, un cas limite — plutôt que cinq variations du même cas confortable. Si Sofia ne montre que des fonctionnalités techniques de smartphone, le modèle patinera sur « garantie 2 ans ». Un exemple non technique dans le lot règle le problème d'avance.
Pense aussi à l'ordre : le modèle accorde un peu plus de poids aux derniers exemples. Place en dernier celui qui ressemble le plus aux entrées que tu vas traiter. Et garde un format strictement identique d'un exemple à l'autre : même séparateur, même ponctuation, même casse.
La cohérence du pattern : ton contrat implicite
Tes exemples forment un contrat implicite : tout ce qui est constant dans tes exemples sera interprété comme une règle ; tout ce qui varie sera interprété comme libre. Si deux de tes exemples finissent par un point et le troisième non, tu envoies un signal contradictoire — et la sortie sera incohérente à son tour.
C'est la cause numéro un des few-shot qui échouent : non pas trop peu d'exemples, mais des exemples qui se contredisent sur un détail que tu n'as pas remarqué. Avant d'accuser le modèle, relis tes exemples comme un correcteur : longueurs comparables ? structure identique ? ton homogène ? même personne grammaticale ? Le diable est dans ces détails.
flowchart LR E1["Exemple 1 : entrée → sortie"] --> P["Pattern repéré : format, ton, longueur"] E2["Exemple 2 : entrée → sortie"] --> P E3["Exemple 3 : cas limite → sortie"] --> P P --> N["Nouvelle entrée"] N --> S["Sortie qui suit le pattern"] E2 -.->|"Exemple incohérent"| X["Pattern brouillé → sortie imprévisible"]
Avant/après : le ton de marque de Sofia
Version descriptive (celle qui échoue) :
Réécris cette description produit avec un ton dynamique mais pas agressif, accessible mais crédible : « Notre logiciel optimise la gestion des plannings de vos équipes. »
Le résultat retombe systématiquement dans le marketing générique : « Boostez vos équipes avec une solution innovante... ». Version few-shot (celle qui marche) :
Réécris des descriptions produit dans notre ton de marque. Exemples : Avant : « Notre module RH automatise le suivi des congés. » Après : « Les demandes de congés ? Validées en 30 secondes, sans tableur, sans email perdu. » Avant : « Notre tableau de bord centralise vos indicateurs. » Après : « Tous vos chiffres au même endroit. Vous ouvrez, vous savez, vous décidez. » Maintenant : Avant : « Notre logiciel optimise la gestion des plannings de vos équipes. » Après :
Pourquoi ça marche : les exemples montrent les phrases courtes, le rythme ternaire, l'adresse directe au lecteur, le bénéfice concret chiffré — tout ce que « dynamique mais pas agressif » échouait à transmettre. Sofia n'a plus jamais décrit son ton : elle le montre.
Quand le few-shot brille (et quand il échoue)
Le few-shot excelle sur les tâches à format précis et répétitif : reformuler des descriptions produit, classer des messages en catégories, extraire des informations dans un gabarit fixe, générer des variantes homogènes, imiter un ton de marque. Partout où tu peux dire « fais comme ça », il bat la consigne abstraite.
Il est en revanche peu utile, voire contre-productif, ailleurs. Sur les tâches de raisonnement complexe, des exemples de réponses finales n'apprennent rien du chemin pour y arriver (on verra mieux au chapitre 3). Sur les tâches créatives ouvertes, trop d'exemples enferment le modèle dans tes cas et appauvrissent la variété. Et sur les tâches que le modèle maîtrise déjà parfaitement, c'est de l'effort gaspillé.
Contexte
Sofia doit transformer une liste de 15 fonctionnalités produit en bénéfices clients pour le nouveau site web. Les trois premières tentatives en zero-shot donnent des formulations correctes mais hétérogènes : certaines longues, d'autres courtes, des tons qui varient d'une ligne à l'autre. Impossible de les mettre côte à côte sur une même page. Elle a pourtant deux anciennes fiches produit dont elle adore le style — exactement la matière première qu'il faut pour un few-shot.
Consignes
- Choisis une tâche répétitive de ton quotidien (descriptions, titres, réponses types).
- Sélectionne 2-3 sorties existantes dont tu es vraiment satisfait : ce seront tes exemples.
- Formate-les en paires entrée → sortie strictement identiques (même séparateur, même ponctuation).
- Vérifie leur diversité : ajoute un cas limite ou atypique si tous tes exemples se ressemblent.
- Ajoute la nouvelle entrée à traiter et lance le prompt.
- Compare avec la version zero-shot : note ce que les exemples ont transmis sans consigne explicite.
- Si la sortie dévie, cherche l'incohérence entre tes exemples avant de tout réécrire.
En résumé
- Montrer 2-3 exemples vaut mieux que décrire un style : le modèle prolonge les patterns mieux qu’il n’interprète les adjectifs.
- Zero-shot pour les tâches génériques, few-shot dès que le format ou le ton est spécifique : escalade progressivement.
- 2 à 5 exemples suffisent ; au-delà, tu consommes du contexte sans gain mesurable.
- La diversité des exemples compte plus que leur nombre : couvre les cas limites.
- Tout ce qui est constant dans tes exemples devient une règle implicite ; toute incohérence brouille le pattern.
- Place l’exemple le plus représentatif en dernier : il pèse un peu plus.
- Le few-shot brille sur le répétitif et le format ; il est inutile sur le trivial et limitant sur le créatif ouvert.
Quiz — vérifie ta compréhension
1. Combien d’exemples viser en few-shot ?
2. Pourquoi la sortie peut ne pas suivre le pattern ?
3. Qu’est-ce que le zero-shot ?
4. Que transmettent des exemples qu’une consigne abstraite transmet mal ?
5. Sur quel type de tâche le few-shot est-il le moins utile ?