Stratégie de prompting

Zero-shot vs few-shot prompting : quand utiliser chaque approche et quel problème elle résout le mieux

Un guide pratique pour savoir quand de simples instructions suffisent et quand il faut ajouter des exemples pour gagner en précision et en cohérence.

Mis à jour : 4 avril 202614 min de lectureGuide de prompt engineering

Contexte

Pourquoi ce guide compte

L’une des erreurs les plus fréquentes en prompt engineering consiste à ajouter des exemples par défaut, sans se demander s’ils sont vraiment nécessaires. Dans certains cas, le few-shot améliore fortement la précision. Dans d’autres, il n’apporte qu’un coût supplémentaire, du bruit et une dépendance à des exemples mal choisis.

La différence est surtout opérationnelle. Il faut savoir quand une instruction claire suffit déjà, et quand le modèle a besoin de voir un comportement de référence pour réduire l’ambiguïté.

Ce guide t’aide à choisir entre zero-shot et few-shot de façon pragmatique, selon la tâche, le niveau de risque et le contrôle recherché.

Synthèse

Points clés

  • Le zero-shot suffit souvent quand la tâche est claire et le format simple.
  • Le few-shot apporte de la valeur quand le ton, la classification ou les cas limites comptent vraiment.
  • Les exemples doivent être peu nombreux, solides et choisis pour leur signal.
  • Plus d’exemples ne veut pas dire automatiquement de meilleurs résultats.
  • Compare toujours le coût en tokens avec le gain réel de précision.
1

Bloc opérationnel

1) Le zero-shot marche mieux qu’on ne le pense souvent

Quand la tâche est bien cadrée, avec un objectif clair et un format défini, les modèles actuels résolvent énormément de demandes sans aucun exemple. Cela fait du zero-shot une option plus rapide, plus propre et moins coûteuse pour de nombreux workflows récurrents.

C’est particulièrement vrai pour les synthèses structurées, les tableaux comparatifs, les résumés et certaines tâches d’extraction simple, à condition que les instructions soient nettes.

2

Bloc opérationnel

2) Le few-shot devient utile quand le comportement attendu n’est pas évident

Dès qu’il faut classifier, scorer, respecter un ton précis ou traiter des cas frontière, les exemples peuvent faire une vraie différence. Ils montrent non seulement la tâche, mais aussi le standard exact à suivre.

Encore faut-il que ces exemples soient bons. Des exemples médiocres ou contradictoires tirent le modèle vers un standard flou.

3

Bloc opérationnel

3) Les exemples servent à calibrer, pas à compenser un mauvais prompt

Beaucoup d’équipes ajoutent des exemples alors que le vrai problème est une instruction de base trop faible. C’est un pansement coûteux. Il faut d’abord améliorer le prompt principal : tâche, critères, contraintes et format. Ensuite seulement, on ajoute quelques exemples si l’ambiguïté persiste.

4

Bloc opérationnel

4) Évalue le gain réel face au coût de maintenance et de tokens

Chaque exemple prend de la place, consomme des tokens et demande de la maintenance quand ton standard change. Le few-shot doit donc être réservé aux cas où le gain de précision a un vrai impact métier ou qualité.

Bibliothèque de modèles

Modèles réutilisables

Modèle zero-shot

Pour les tâches bien définies où le modèle n’a pas besoin d’exemples.

Agis comme [RÔLE].
Résous cette tâche : [TÂCHE].
Contexte utile :
[CONTEXTE]

Contraintes :
- [CONTRAINTE 1]
- [CONTRAINTE 2]

Retourne la réponse sous ce format :
[FORMAT ATTENDU]

Modèle few-shot

Pour la classification, le scoring, le ton ou les cas limites où tu veux plus de contrôle.

Je veux que tu suives ce pattern.

Exemple 1 :
Input : [INPUT]
Output attendu : [OUTPUT]

Exemple 2 :
Input : [INPUT]
Output attendu : [OUTPUT]

Maintenant traite ce nouveau cas :
Input : [INPUT RÉEL]

Applique le même critère que dans les exemples et signale clairement les cas ambigus.

Contrôle qualité

Erreurs fréquentes et corrections

Ajouter des exemples par réflexe

Problème : Le prompt coûte plus cher sans amélioration nette de qualité.

Correction : Commence par un zero-shot propre, puis ajoute des exemples seulement si le gain est mesurable.

Exemples faibles ou contradictoires

Problème : Le modèle apprend un standard confus.

Correction : Choisis peu d’exemples, mais avec un signal fort et cohérent.

Utiliser le few-shot pour masquer une mauvaise spécification

Problème : Tu compenses un mauvais prompt avec plus de tokens.

Correction : Améliore d’abord l’instruction, le contexte et le format. Ensuite seulement, ajoute des exemples si nécessaire.

FAQ

Questions fréquentes

Le zero-shot est-il forcément moins bon ?

Non. Sur beaucoup de tâches bien définies, il suffit largement et coûte moins cher. Tout dépend du niveau d’ambiguïté et de précision attendu.

Combien d’exemples faut-il utiliser en few-shot ?

En général, 1 à 3 bons exemples suffisent. Au-delà, cela ne vaut la peine que si tu couvres des cas limites réellement importants.

Quelles tâches profitent le plus du few-shot ?

La classification, le scoring, le labeling, le ton de marque, la compliance éditoriale et tous les cas où le standard de sortie est critique.

Sources

Références et lectures complémentaires