Vous avez une tâche à confier à une IA. Vous demandez directement, ou vous montrez d’abord ce que vous voulez ?

C’est la question du zero-shot vs few-shot. Zero-shot, c’est demander sans exemple. Few-shot, c’est donner un ou plusieurs exemples avant votre vraie demande. Les noms viennent de la recherche en apprentissage automatique, mais l’idée est simple : montrer vs expliquer.

La plupart des gens n’utilisent jamais d’exemples, ou en mettent partout. Les deux sont de mauvaises approches. La bonne réponse dépend de ce que vous demandez, du modèle que vous utilisez, et de l’importance du format par rapport au fond.

L’approche par les exemples d’abord

Le few-shot prompting fonctionne par reconnaissance de motifs. Vous montrez à l’IA à quoi ressemble une bonne sortie, puis elle reproduit ce motif pour votre nouvelle entrée. C’est particulièrement puissant quand vous avez besoin d’un format, d’un ton ou d’une structure précise difficile à décrire avec des mots.

Disons que vous devez rédiger des descriptions produit pour un site e-commerce. Vous pouvez expliquer que vous voulez des descriptions courtes, percutantes, avec les caractéristiques clés dans un ordre précis. Ou vous pouvez simplement en montrer une :

Mug de voyage en céramique Garde le café chaud pendant 4 heures. Tient dans les porte-gobelets standard. Passe au lave-vaisselle. Disponible en 6 couleurs.

Ensuite, demandez une description d’une gourde en acier inoxydable. L’IA a maintenant un modèle. Elle reprend la longueur, la structure des phrases, le niveau de détail. Aucune ambiguïté sur ce que vous cherchez.

Un commentateur sur Hacker News l’a résumé simplement : “In general, showing an example of correct output (one shot prompting) can greatly improve output format consistency.”

C’est le bénéfice central. La cohérence. Quand vous avez besoin que l’IA produise plusieurs sorties dans le même format, les exemples battent presque toujours les consignes.

Quand les exemples changent tout

Les gains du few-shot prompting peuvent être spectaculaires. Dans une étude de cas sur le codage médical, ajouter des paires exemple-étiquette aux prompts a fait passer la précision de 0 % à 90 %. Ce n’est pas une faute de frappe. Le même modèle est passé de complètement faux à presque parfait juste en voyant quelques exemples d’abord.

Mais c’est un scénario idéal. Des recherches compilées par PromptHub montrent des rendements décroissants après environ deux à trois exemples. Vous voyez de gros gains avec les premiers, puis ça plafonne. Ajouter dix exemples au lieu de trois aide rarement, et peut même nuire en encombrant le prompt.

Une étude de l’University of London sur la réparation automatique de bogues a montré quelque chose de contre-intuitif : leur cadre MANIPLE a obtenu 17 % d’amélioration des corrections réussies en optimisant les exemples à inclure, mais ajouter plus d’exemples dégradait parfois les performances. Le prompt devenait plus bruyant, pas plus intelligent.

Le cas surprenant contre les exemples

C’est là que ça devient intéressant. Les règles changent avec les nouveaux modèles orientés raisonnement.

La série o1 d’OpenAI et des modèles similaires orientés raisonnement obtiennent en fait de moins bons résultats avec des exemples dans de nombreux cas. Des recherches citées par PromptHub ont montré qu’un prompting à 5 exemples réduisait les performances de o1-preview par rapport à une base minimale. La documentation de DeepSeek-R1 indique explicitement que le few-shot prompting “consistently degrades its performance.”

Pourquoi ? Ces modèles sont conçus pour raisonner par eux-mêmes. Leur donner des exemples peut contraindre leur réflexion ou les envoyer sur une mauvaise piste. Ils marchent mieux quand vous décrivez ce que vous voulez et que vous les laissez trouver comment y arriver.

C’est important parce que le domaine se dirige vers les modèles de raisonnement. Si vous utilisez o1, o3-mini, ou un équivalent, essayez d’abord sans exemples. Ajoutez-en seulement si le format de sortie doit être corrigé.

Le problème modèle par modèle

Il y a une autre complication. Les meilleurs exemples pour un modèle ne sont pas forcément les meilleurs pour un autre.

Aickin, fondateur de Libretto, a mené des expériences pour tester si les exemples les plus performants sur un modèle seraient aussi les meilleurs sur un autre. Le constat est clair : “Most of the time, the answer was no, even between different versions of the same model.”

L’implication pratique est rude. Vous devez probablement optimiser les exemples modèle par modèle, et refaire ce travail à chaque nouvelle version. Les trois exemples parfaits que vous avez construits pour GPT-4 ne se transfèrent pas forcément à GPT-4o ou Claude 3.5.

Pour la plupart des gens, cela veut dire : garder des exemples simples et éviter la sur-optimisation. Plus vos exemples sont spécifiques, plus ils risquent de casser quand vous changez de modèle ou quand le modèle est mis à jour.

Montrer vs expliquer : quand chaque approche marche

Oubliez les règles rigides. Réfléchissez à ce que vous essayez vraiment d’obtenir.

Les exemples marchent le mieux quand :

Le format est prioritaire. Si vous avez besoin de JSON, de tableaux markdown, ou d’un modèle précis à remplir, un exemple bat souvent des paragraphes d’instructions. L’IA voit la structure et la reproduit.

Le style est difficile à décrire. “Écris avec notre ton de marque” est vague. Montrer trois phrases dans votre ton de marque, c’est concret. Le motif est plus simple à reproduire que la description.

Vous faites des tâches répétitives. Besoin de vingt descriptions produit ? Donnez deux exemples, obtenez-en dix-huit de plus dans le même format. La cohérence se cumule.

Le modèle est un LLM standard comme GPT-4 ou Claude. Ces modèles sont entraînés à suivre des motifs. Ils répondent bien aux approches où l’on montre plutôt que d’expliquer.

Évitez les exemples quand :

La tâche exige du raisonnement. Problèmes de maths, énigmes logiques, débogage de code, analyse stratégique. Ici, expliquez ce que vous voulez et laissez le modèle réfléchir. Ajouter des exemples peut contraindre sa démarche ou introduire des erreurs liées à la solution spécifique de l’exemple.

Vous utilisez un modèle de raisonnement. o1, o3-mini, DeepSeek-R1. Ces modèles génèrent déjà leur propre chaîne de pensée en interne. Les exemples peuvent perturber ce processus.

La tâche est simple. “Résume cet article en trois phrases” n’a pas besoin d’exemple. La consigne est déjà assez claire. Ajouter des exemples ne fait que brûler des jetons sans améliorer la sortie.

Vous avez besoin de créativité, pas de cohérence. Si vous voulez que l’IA vous surprenne, les exemples réduisent l’espace des sorties possibles. Vous lui montrez ce qui est permis, au lieu de ce qui est possible.

Le test en conditions réelles

La théorie, c’est bien. La pratique, c’est mieux.

Faites une expérience simple avant de vous engager sur une approche. Prenez votre tâche, exécutez-la trois fois en zero-shot, puis trois fois avec deux exemples. Comparez les sorties. Les exemples ont-ils amélioré la qualité ? Ont-ils amélioré la cohérence ? Ont-ils changé quoi que ce soit ?

Souvent, la réponse est : “Les exemples ont aidé pour le format, mais pas pour la qualité du contenu.” C’est une information utile. Elle vous dit quand investir dans les exemples et quand investir plutôt dans de meilleures consignes.

Certains praticiens constatent que le meilleur compromis, c’est un exemple pour le format et des consignes détaillées pour tout le reste. Vous obtenez la cohérence structurelle grâce à l’exemple, tout en laissant les consignes guider le fond.

Le calcul des coûts

Les exemples ne sont pas gratuits. Chaque exemple ajouté coûte des jetons à chaque appel API. Avec Claude Haiku ou GPT-4o-mini, le coût est négligeable. Avec GPT-4 ou Claude Opus, ça s’accumule.

Le calcul change selon le volume. Si vous exécutez un prompt une fois, ajoutez autant d’exemples que vous voulez. Si vous l’exécutez des milliers de fois par jour, chaque jeton compte.

Minimaxir a noté sur Hacker News que l’économie favorise plus que jamais le few-shot prompting : “You will often get better results with few-shot prompting (with good examples) on a modern LLM than with a finetuned LLM.” Les jetons d’entrée sont devenus peu chers, surtout avec des modèles comme Claude Haiku. Le coût d’ajouter des exemples a fortement baissé.

Mais la comparaison ne se limite pas au coût des jetons. Selon les tarifs d’OpenAI, affiner un modèle coûte 4 à 6 fois plus que l’usage API standard. Si vous hésitez entre l’affinage et l’utilisation de nombreux exemples, les exemples gagnent souvent sur le coût, même avec les jetons supplémentaires.

L’entre-deux dangereux

La pire approche consiste à ajouter des exemples sans réfléchir à leur utilité.

Le prompting en mode cargo cult. Vous avez lu quelque part qu’il faut “toujours ajouter des exemples”, donc maintenant chaque prompt en contient trois, qu’ils soient pertinents ou non. L’IA confond ce qui relève de la consigne et ce qui relève du contexte. La sortie se dégrade au lieu de s’améliorer.

Ou l’inverse : vous avez intégré que les prompts doivent être “clairs et directs”, donc vous ne montrez jamais d’exemple même quand le format est crucial. Vous finissez par écrire des paragraphes pour décrire la structure d’un tableau alors qu’un exemple communiquerait la même chose en deux lignes.

La compétence ne consiste pas à mémoriser des règles. Elle consiste à reconnaître dans quelle situation vous êtes.

Mélanger les approches

Le choix entre exemples et consignes n’est pas binaire. Vous pouvez expliquer ce que vous voulez, puis le montrer.

Pour l’extraction de documents, vous pouvez écrire : “Extrais le nom du client, l’e-mail, la note et le principal point de retour de ces formulaires. Formate en JSON.”

Puis ajouter un exemple qui montre le format. La consigne explique la tâche. L’exemple verrouille la structure de sortie. Vous gagnez à la fois en clarté et en cohérence.

Cette approche hybride fonctionne particulièrement bien quand : le format est spécifique (utilisez l’exemple), mais le raisonnement derrière les décisions est important (utilisez la consigne). Aucune des deux approches seule ne suffit. Ensemble, elles couvrent des aspects différents de ce dont vous avez besoin.

Ce qui compte vraiment

Après toute la recherche et toute l’expérimentation, quelques points sont clairs.

Les exemples aident surtout pour le format, la cohérence et le style. Si ce sont vos priorités, utilisez-les. Si vos priorités sont la qualité du fond et le raisonnement, les exemples peuvent ne pas aider et même nuire.

Deux à trois exemples suffisent en général. Au-delà, la valeur ajoutée est rare et le bruit peut augmenter. La recherche PromptHub montre que les rendements décroissants arrivent vite.

Testez sur votre vraie tâche avec votre vrai modèle. Les moyennes de la recherche masquent d’énormes variations. Ce qui marche pour le codage médical peut ne pas marcher pour du texte marketing.

Et observez ce qui se passe quand les modèles évoluent. Vos exemples soigneusement optimisés peuvent devoir être recalibrés. Le meilleur prompt few-shot du mois dernier peut être moyen aujourd’hui.

Si vous ne retenez qu’une chose, retenez celle-ci : la différence entre zero-shot et few-shot ne vient pas de la technique “meilleure”. Elle vient de savoir si la reconnaissance de motifs ou le raisonnement sert votre tâche. Parfois, vous voulez que l’IA copie une structure. Parfois, vous voulez qu’elle réfléchisse. Savoir faire la différence, c’est tout le jeu.