Vous avez trois minutes pour extraire des données structurées d’e-mails clients. Le modèle hallucine des champs. Vous essayez un prompt plus détaillé. Il hallucine toujours. Vous ajoutez des exemples. Mieux, mais pas fiable. Vous décortiquez le raisonnement étape par étape. Ça marche.
La différence entre ces tentatives n’est pas de la chance — ce sont trois modèles de prompting distincts qui échangent simplicité contre précision. Comprendre quand chacun échoue est plus important que de savoir qu’ils existent.
Zero-Shot : La vitesse avant la précision
Le zero-shot signifie que vous donnez au modèle une tâche sans exemples. Juste l’instruction et l’entrée.
# Prompt Zero-shot
Extrayez le montant total de la commande du client, le nom du produit et l'adresse de livraison de cet e-mail :
---
[e-mail client ici]
---
Répondez au format JSON.Cela fonctionne lorsque : la tâche est simple, le domaine est courant (service client, classification basique) et vous vous souciez plus de la vitesse que de la précision. Claude Sonnet 4 et GPT-4o gèrent cela bien sur des tâches simples — typiquement 70–85 % de précision sur l’extraction structurée si les données sont clairement présentes dans le texte source.
Cela échoue rapidement lorsque : la tâche nécessite des connaissances spécifiques au domaine, la reconnaissance de motifs dans des cas limites, ou une logique en plusieurs étapes. Un prompt zero-shot demandant à un modèle de classifier des transactions financières suspectes sans exemples manquera des motifs subtils qu’un prompt few-shot attrape immédiatement. Le modèle n’a pas de point de référence pour ce que signifie « subtil » dans votre domaine.
Coût en tokens : le plus bas. Vous envoyez une instruction et une entrée. Pour les tâches à haut volume (des milliers d’inférences), cette différence se cumule.
Few-Shot : Le juste milieu pratique
Le few-shot ajoute 2 à 5 exemples avant la tâche réelle. Le modèle apprend le motif à partir de ces exemples sans réentraînement explicite.
# Version Zero-shot (baseline)
Classifiez ce ticket de support comme urgent ou de routine :
Ticket : « Mon paiement a échoué et ma commande était censée arriver aujourd'hui. »
# Version Few-shot (améliorée)
Classifiez ce ticket de support comme urgent ou de routine.
Exemples :
Ticket : « Je n'arrive pas à me connecter à mon compte. »
Classification : Routine
Ticket : « Le paiement a échoué et ma commande était censée arriver aujourd'hui. »
Classification : Urgent
Ticket : « Comment réinitialiser mon mot de passe ? »
Classification : Routine
Ticket : « Le serveur est en panne et les clients ne peuvent pas vérifier le statut de leur commande. »
Classification : Urgent
Maintenant, classez celui-ci :
Ticket : « Mon paiement a échoué et ma commande était censée arriver aujourd'hui. »
Classification :La version few-shot montre au modèle exactement ce que vous entendez par « urgent » dans votre contexte spécifique. Échec de paiement + promesse de livraison = urgent. Le modèle ne devine pas les définitions — il extrapole à partir de vos exemples.
Cela fonctionne lorsque : vous avez 3 à 10 exemples clairs et représentatifs et que la tâche présente des motifs reconnaissables. Le few-shot surpasse systématiquement le zero-shot de 15 à 30 % sur les tâches de classification et d’extraction dans les benchmarks (tests internes Anthropic, janvier 2025). C’est suffisamment fiable pour une utilisation en production sur des tâches à enjeux moyens.
Cela échoue lorsque : vos exemples ne couvrent pas les cas limites, ou que le motif est réellement complexe. Si vos exemples de tickets « urgents » concernent tous des problèmes de paiement, mais qu’un ticket concernant des préoccupations de confidentialité des données nécessite également une gestion urgente, le few-shot apprend le mauvais motif. Il n’est bon que comme vos exemples.
Coût en tokens : plus élevé que le zero-shot, inférieur au chain-of-thought. Trois exemples ajoutent environ 300 à 500 tokens par requête. À grande échelle, cela compte.
Chain-of-Thought : Raisonnement plutôt que reconnaissance de motifs
Le chain-of-thought demande au modèle d’expliquer son raisonnement avant de répondre. « Pensez étape par étape » est la version la plus simple. Le modèle montre son travail, et la précision s’améliore — parfois de manière spectaculaire.
# Few-shot sans raisonnement
Un client a commandé 3 widgets à 50 $ chacun avec 15 $ de frais de port.
Il a appliqué un code de réduction de 10 %. Quel est le total final ?
Total : 165 $
# Few-shot avec chain-of-thought
Un client a commandé 3 widgets à 50 $ chacun avec 15 $ de frais de port.
Il a appliqué un code de réduction de 10 %. Quel est le total final ?
Réfléchissons étape par étape :
1. Coût des widgets : 3 × 50 $ = 150 $
2. Ajout des frais de port : 150 $ + 15 $ = 165 $
3. Application de la réduction de 10 % : 165 $ × 0.90 = 148,50 $
4. Total final : 148,50 $
Réponse finale : 148,50 $Le modèle obtient la bonne réponse. Sans la décomposition étape par étape, il pourrait confondre l’ordre des opérations ou appliquer la réduction incorrectement. Le chain-of-thought force un raisonnement intermédiaire qui expose une logique défaillante.
Cela fonctionne lorsque : la tâche implique des mathématiques, de la logique, un raisonnement en plusieurs étapes, ou des compromis complexes. Les recherches d’OpenAI montrent que le chain-of-thought peut améliorer la précision sur les tâches de mathématiques et de raisonnement de 40 à 60 % (Wei et al., 2022). En production chez AlgoVesta, nous utilisons le chain-of-thought pour les prompts d’analyse de portefeuille — le résultat du raisonnement devient également une preuve auditable de la manière dont une décision a été prise.
Cela échoue lorsque : vous avez besoin de vitesse et que la tâche est simple. Une tâche de classification (« est-ce du spam ? ») n’a pas besoin de chain-of-thought. Les tokens et la latence supplémentaires perdent du temps sans gain de précision. De plus, le chain-of-thought peut amplifier les hallucinations si le modèle explique avec confiance un raisonnement incorrect. Il est plus transparent sur le fait d’avoir tort, mais il a quand même tort.
Coût en tokens : le plus élevé. Le résultat du raisonnement étape par étape peut doubler ou tripler l’utilisation des tokens par rapport au zero-shot. À l’échelle des inférences, cela devient une véritable contrainte de coût.
Lequel utiliser : un cadre de décision
- Zero-shot : Classification simple, extraction directe, tâches à haut volume où 80 % de précision est acceptable. Commencez par là — c’est la référence.
- Few-shot : Complexité moyenne, motifs spécifiques au domaine, besoin de plus de 90 % de précision. Ajoutez des exemples lorsque le zero-shot manque les cas limites.
- Chain-of-thought : Raisonnement requis, mathématiques impliquées, logique en plusieurs étapes, ou lorsque vous avez besoin d’auditer le raisonnement lui-même. Combinez avec des exemples few-shot pour de meilleurs résultats sur les tâches complexes.
Les trois ne s’excluent pas mutuellement. Les flux de travail de production utilisent souvent le zero-shot comme première passe (vérification de vitesse), le few-shot pour les cas qui échouent, et le chain-of-thought pour les décisions à fort enjeu qui nécessitent une validation du raisonnement.
Commencez par le Zero-Shot, ajoutez seulement si nécessaire
La plupart des équipes gaspillent des tokens en commençant par le few-shot alors que le zero-shot fonctionnerait. Testez d’abord le zero-shot. Si la précision tombe en dessous de votre seuil, ajoutez 3 à 5 exemples et re-testez. Passez au chain-of-thought uniquement si la tâche nécessite réellement du raisonnement. Dans les systèmes de production réels, vous utiliserez les trois — à différentes étapes du même pipeline.
