Few-shot vs zero-shot pour le code
Quand montrer un exemple de code dans le prompt paie le coût en tokens -- et quand le zero-shot suffit.
Zero-shot et few-shot : deux façons de prompter
En prompt engineering, zero-shot signifie demander quelque chose à l’agent sans lui montrer d’exemple. Few-shot signifie inclure un ou plusieurs exemples dans le prompt pour guider le format, le style ou la logique attendue.
Point clé : Zero-shot : “Écris une méthode qui calcule le prix TTC à partir du prix HT et du taux de TVA.” Few-shot : “Voici comment j’écris mes méthodes de calcul :
public decimal CalculateDiscount(decimal price, decimal rate) => price * rate;. Maintenant, écris une méthode qui calcule le prix TTC.”
Le modèle connaît déjà la syntaxe C#, les patterns standard, et les conventions courantes. Le zero-shot fonctionne donc bien pour les tâches classiques. Le few-shot devient utile quand l’agent ne peut pas deviner ce que vous attendez — conventions maison, format de sortie spécifique, style de code non standard.
Quand le few-shot paie son coût
Cas où le few-shot est rentable
Le few-shot se justifie dans quatre situations : les conventions internes non standard (nommage spécifique, structure de fichiers maison), le format de sortie précis (JSON ou YAML dans un schéma exact), le style de code cohérent (même structure d’exception handling, même façon d’organiser les tests), et les tâches ambiguës où le zero-shot produit un résultat correct mais pas dans le format voulu.
Cas où le zero-shot suffit
Le zero-shot est suffisant pour les tâches standard (écrire une classe, un test unitaire simple, une requête LINQ classique), les conventions connues (le modèle connaît déjà les conventions officielles de .NET), et les situations où le contexte est déjà chargé — ajouter des exemples peut alors être contre-productif.
Le coût en tokens
Chaque exemple dans un prompt few-shot consomme des tokens. Un exemple de 10 lignes de code peut représenter 100 à 200 tokens. Dans une session longue où le contexte est déjà chargé, ces tokens ne sont pas gratuits.
Attention : Le piège classique est d’ajouter 5 exemples “pour être sûr” alors qu’un seul suffirait. Le modèle n’a pas besoin de redondance — il a besoin de clarté. Un exemple bien choisi vaut mieux que cinq exemples similaires.
La règle pratique : commencer en zero-shot. Si le résultat n’est pas dans le format ou le style attendu, ajouter un seul exemple. N’ajouter plus d’exemples que si le pattern est complexe ou si le modèle produit des variations non souhaitées.
Point clé : Le few-shot est un outil de correction, pas un réflexe. Le coût en tokens doit être justifié par un gain mesurable en qualité ou en cohérence.
Alternatives au few-shot
Avant de recourir au few-shot dans chaque prompt, considérer ces alternatives qui persistent automatiquement :
| Alternative | Mécanisme | Quand l’utiliser |
|---|---|---|
| CLAUDE.md | Instructions persistantes lues à chaque session | Conventions stables du projet |
| Fichiers de référence | Fichiers existants que l’agent peut lire | Exemples de code dans le projet même |
| Slash commands | Prompts pré-rédigés avec contexte | Workflows répétitifs |
Si la convention est stable et applicable à tout le projet, elle a sa place dans CLAUDE.md, pas dans un prompt few-shot répété à chaque session. Le few-shot est pour les besoins ponctuels ou contextuels.