Few-shot, chain-of-thought et décomposition

Pourquoi ce chapitre compte

Un promptpromptIAConsigne ou contexte fourni à un modèle de langage pour orienter sa réponse. La qualité du prompt conditionne souvent la qualité du résultat.Voir dans le glossaire qui fonctionne une fois ne prouve rien sur les mille variantes qu'il rencontrera en production. Trois techniques structurent la fiabilité d'un prompt à l'échelle : le few-shotFew-shotIATechnique de prompt où l'on fournit quelques exemples entrée-sortie pour guider le modèle sans réentraînement.Voir dans le glossaire, qui montre plutôt qu'il n'explique ; le chain-of-thoughtchaîne de penséeIATechnique de prompting (Chain-of-Thought) qui demande au modèle de détailler son raisonnement étape par étape avant de produire sa réponse finale. Elle améliore significativement les performances sur les tâches complexes.Voir dans le glossaire, qui force un raisonnement explicite avant la conclusion ; et la décomposition, qui fragmente une tâche complexe en étapes vérifiables. Aucune des trois n'est gratuite. Chaque exemple ajouté, chaque étape de raisonnement demandée, chaque appel supplémentaire consomme des tokenstokenIAFragment de texte manipulé par un modèle de langage, généralement plus court qu'un mot — trois à quatre caractères en français. La tarification et la limite de contexte se comptent en tokens.Voir dans le glossaire, allonge la latence, et peut, mal calibré, dégrader la réponse au lieu de l'améliorer.

Ce chapitre ne présente pas ces techniques comme des recettes universelles à appliquer systématiquement. Il précise dans quelles situations chacune apporte un gain mesurable, et où elle devient un coût sans contrepartie.

Le few-shot prompting

Principe

Le few-shot consiste à insérer, dans le prompt, un petit nombre d'exemples d'entrée-sortie avant de soumettre la requête réelle. Le modèle n'apprend rien au sens strict du terme — ses paramètres ne changent pas d'un appel à l'autre — mais il infère un patron à partir du format observé et le reproduit sur la nouvelle entrée. C'est un apprentissage dans le contextefenêtre de contexteIAQuantité de texte qu'un modèle peut prendre en compte simultanément : question, documents fournis et historique. Au-delà, les éléments les plus anciens sortent du champ.Voir dans le glossaire (in-context learning), limité à la durée de la conversation.

Concrètement, un prompt few-shot pour une tâche de classification de tickets support ressemble à ceci :

Classe chaque ticket dans une des catégories : facturation, technique, résiliation.

Ticket : "Je n'arrive plus à me connecter depuis la mise à jour."
Catégorie : technique

Ticket : "Vous m'avez prélevé deux fois ce mois-ci."
Catégorie : facturation

Ticket : "Je veux arrêter mon abonnement à la fin du mois."
Catégorie : résiliation

Ticket : "L'export PDF génère un fichier vide."
Catégorie :

Le modèle complète la dernière ligne en s'appuyant sur le format des trois exemples précédents, pas seulement sur la consigne écrite en toutes lettres.

Quand l'utiliser

Le few-shot apporte un gain net dans trois situations récurrentes :

• Format de sortie strict. Un JSON avec des clés précises, une structure de tableau, un gabarit de réponse imposé : montrer un exemple conforme réduit les écarts de format bien mieux qu'une description textuelle du schéma attendu.
• Catégories ambiguës. Quand les frontières entre classes ne sont pas évidentes à partir de leur seul nom (« urgent » vs « prioritaire »), des exemples calibrent la limite mieux qu'une définition abstraite.
• Ton ou style spécifique. Reproduire une voix de marque, un registre de langue, une longueur de réponse constante : les exemples transmettent des nuances stylistiques qu'une instruction peine à formuler explicitement.

À l'inverse, pour une tâche simple et sans ambiguïté de format — résumer un paragraphe, traduire une phrase — le few-shot n'apporte généralement rien et alourdit le prompt pour rien.

Testez toujours en zero-shotZero-shotIACapacité d'un modèle à réaliser une tâche sans exemple fourni dans le prompt, en s'appuyant uniquement sur ses connaissances pré-entraînées.Voir dans le glossaire avant d'ajouter des exemples. Si la sortie est déjà correcte et stable, le few-shot n'ajoute que du coût. N'investissez des exemples que là où le zero-shot échoue de façon reproductible.

Combien d'exemples, et lesquels

La littérature et l'expérience convergent sur un ordre de grandeur : entre 3 et 8 exemples suffisent dans la grande majorité des cas. Au-delà, les gains marginaux s'effondrent alors que le coût par appel continue de croître linéairement.

Le choix des exemples compte autant que leur nombre :

• Représentativité. Des exemples non représentatifs du cas réel entraînent un surapprentissagesurapprentissageIADéfaut d'un modèle qui mémorise ses exemples d'entraînement au lieu d'en dégager des régularités. Il excelle sur les données vues et échoue sur toute donnée nouvelle.Voir dans le glossaire de surface : le modèle reproduit des traits stylistiques accessoires (longueur, tournures) plutôt que la logique de la tâche.
• Équilibre des classes. Si trois exemples sur quatre appartiennent à la même catégorie, le modèle développe un biaisbiaisIARégularité correctement apprise dans des données qui ne représentent pas la réalité visée, ou qui enregistrent des décisions passées avec leurs préjugés. Changer d'algorithme ne le corrige pas.Voir dans le glossaire vers cette catégorie, indépendamment du contenu réel de la nouvelle entrée.
• Ordre. Les modèles présentent un effet de récence : les derniers exemples pèsent souvent plus lourd que les premiers dans la réponse produite. Ne placez pas systématiquement le cas le plus rare en tête de liste, et faites varier l'ordre entre plusieurs runs de test pour vérifier que le résultat ne dépend pas d'un simple artefact de position.
• Diversité de formulation. Varier la longueur et la structure syntaxique des exemples évite que le modèle n'associe la catégorie à un simple motif de surface (mots-clés récurrents) plutôt qu'au sens réel de l'énoncé.

Les exemples few-shot sont souvent copiés depuis des cas réels — tickets clients, contrats, échanges internes. Vérifiez systématiquement qu'ils ne contiennent pas de donnéesdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire personnelles ou confidentielles avant de les figer dans un prompt, a fortiori si ce prompt est journalisé, versionné dans un dépôt de code ou partagé avec un tiers.

Le chain-of-thought (CoT)

Principe

Le chain-of-thought consiste à demander au modèle d'expliciter un raisonnement intermédiaire avant de produire sa réponse finale, plutôt que de sauter directement à la conclusion. La formulation la plus simple — le zero-shot CoT — tient en une consigne ajoutée en fin de prompt : « Réfléchis étape par étape avant de répondre. »

Cette instruction, à elle seule, améliore sensiblement les performances sur les tâches qui demandent plusieurs étapes de calcul ou de déduction logique enchaînées. Le mécanisme sous-jacent est structurel : un modèle de langagegrand modèle de langageIAModèle entraîné à prédire le token suivant d'une séquence de texte. Toutes ses capacités apparentes — résumer, traduire, coder — découlent de cette unique tâche.Voir dans le glossaire génère token après token, et chaque token généré devient du contexte pour le suivant. En forçant la production d'étapes intermédiaires, on donne au modèle davantage d'espace computationnel pour construire la réponse, au lieu de lui demander de produire directement un résultat qui exigerait, en une seule génération, l'équivalent d'un calcul multi-étapes.

Le few-shot CoT va plus loin : les exemples fournis en amont incluent eux-mêmes le raisonnement, pas seulement la réponse finale.

Question : Un train part à 14h10 et met 2h35 pour arriver. À quelle heure arrive-t-il ?
Raisonnement : 14h10 + 2h = 16h10. Puis 16h10 + 35 min = 16h45.
Réponse : 16h45

Question : Un atelier produit 145 pièces en 5 heures. Combien produit-il en 8 heures, à rythme constant ?
Raisonnement :

Quand le CoT apporte un gain réel

Le CoT aide de façon mesurable sur :

• les problèmes arithmétiques ou logiques à plusieurs étapes ;
• les tâches de déduction où la conclusion dépend de plusieurs prémisses à combiner ;
• l'extraction d'information dans un texte long, quand il faut croiser plusieurs passages avant de répondre ;
• les tâches de planification, où il faut définir un ordre d'étapes valide.

Il n'aide pas — et peut nuire — sur :

• les recherches factuelles simples (« quelle est la capitale de… ») ;
• les classifications courtes et non ambiguës ;
• les tâches où la réponse est immédiate et ne bénéficie d'aucune décomposition.

Chaque étape de raisonnement générée est un ensemble de tokens de sortie facturés et comptés dans la latence. Sur un cas simple, imposer un CoT peut doubler ou tripler le nombre de tokens produits sans gain de justesse, parfois même en dégradant la réponse par surinterprétation d'une question simple.

Modèles à raisonnement natif

Une distinction devenue importante : certains modèles récents intègrent un mécanisme de raisonnement interne avant de produire leur réponse visible, sans qu'il soit nécessaire de le demander explicitement dans le prompt. Avec ces modèles, ajouter une consigne de type « réfléchis étape par étape » est souvent redondant, et peut dans certains cas allonger inutilement la sortie sans bénéfice supplémentaire. Le CoT prompté reste en revanche pleinement pertinent avec les modèles qui ne raisonnent pas nativement, ou lorsqu'on veut contraindre la forme du raisonnement affiché — à des fins d'audit, de pédagogie ou de débogage.

La chaîne de raisonnement n'est pas une preuve

Un raisonnement affiché de façon cohérente et détaillée n'implique pas que le modèle a réellement suivi ce chemin logique pour produire sa réponse. Il est possible d'observer un raisonnement plausible aboutissant à une conclusion, alors que la conclusion a en réalité été « décidée » avant, et que le raisonnement affiché en est une reconstruction a posteriori, cohérente en apparence mais non causale. Cette distinction compte particulièrement dès lors qu'on utilise le CoT comme outil d'audit ou de conformité : la trace de raisonnement documente ce que le modèle a écrit, pas nécessairement le mécanisme réel de sa décision. Pour les cas à enjeu — décision médicale, juridique, financière — le raisonnement affiché doit être vérifié indépendamment, et non pris comme justification suffisante en soi.

La décomposition de tâches

Principe

Plutôt que de soumettre une tâche complexe en un seul prompt géant, la décomposition consiste à la fragmenter en une suite d'appels, chacun ciblant une sous-tâche précise et vérifiable. Un pipeline de génération de contenu, par exemple, peut se décomposer en : extraction des faits sources → structuration du plan → rédaction section par section → vérification de cohérence finale — quatre appels distincts plutôt qu'un prompt unique demandant tout à la fois.

Avantages

• Vérifiabilité. Chaque sortie intermédiaire est plus courte et plus ciblée, donc plus facile à valider automatiquement ou manuellement.
• Débogage localisé. Quand le résultat final est mauvais, on peut identifier l'étape précise qui a échoué, plutôt que de deviner où, dans un prompt monolithique, l'erreur s'est introduite.
• Contrôle différencié. Chaque étape peut utiliser un modèle, une température ou des contraintes différentes — un modèle peu coûteux pour l'extraction, un modèle plus capable pour la synthèse finale.
• Points de contrôle humains. La décomposition permet d'insérer une validation humaine entre deux étapes sur les cas à enjeu, sans bloquer l'ensemble du pipeline.

Inconvénients

• Latence cumulée. Chaque appel ajoute son propre temps de réponse ; un pipeline à quatre étapes séquentielles est, au minimum, quatre fois plus lent qu'un appel unique, sauf parallélisation possible entre étapes indépendantes.
• Coût cumulé. Les tokens de contexte peuvent être redemandés à chaque étape (rappelrappelIAProportion des cas positifs réels effectivement détectés par un modèle. Sur un jeu déséquilibré, c'est un indicateur bien plus parlant que l'exactitude globale.Voir dans le glossaire du texte source, des instructions), ce qui gonfle la facture totale par rapport à un seul appel.
• Propagation d'erreurs. Une erreur non détectée à l'étape 1 se propage et se complexifie aux étapes suivantes, si aucune validation intermédiaire n'est en place.
• Complexité d'orchestration. Le pipeline exige un code de coordination (gestion des échecs partiels, retries, format de passage entre étapes) qui n'existe pas avec un prompt unique.

Une équipe commerciale automatise la qualification de leads entrants en trois étapes : (1) extraction structurée des informations du message (secteur, budget évoqué, urgence) ; (2) score de qualification calculé à partir de cette extraction selon une grille fixe ; (3) rédaction d'une réponse personnalisée si le score dépasse un seuil. Chaque étape est testée et validée séparément, et l'étape 2 n'appelle même pas de modèle de langage — un simple calcul suffit une fois l'extraction structurée obtenue.

Coût et latence : ordres de grandeur

Pour donner une intuition, un prompt zero-shot de classification simple peut tenir en 200 tokens d'entrée. Le même prompt en few-shot avec six exemples représentatifs peut monter à 800 ou 1000 tokens d'entrée, répétés à chaque appel — soit un coût multiplié par quatre ou cinq sur la seule partie du prompt, avant même de compter la sortie. Un CoT ajouté à une tâche qui n'en avait pas besoin peut faire passer une sortie de 20 tokens à 150 ou 200 tokens, avec un impact direct et proportionnel sur la latence perçue par l'utilisateur final. Un pipeline décomposé en quatre appels séquentiels, même rapides individuellement, peut cumuler une latence totale supérieure à la seconde, incompatible avec une interaction conversationnelle en temps réel.

Ces ordres de grandeur ne sont pas des constantes universelles — ils dépendent du modèle, du fournisseur et de la tâche — mais ils illustrent un principe stable : chaque technique de ce chapitre déplace un curseur entre qualité de sortie et coût d'exécution. Le choisir consciemment, plutôt que par défaut, est ce qui distingue un prompt de production d'un prompt de démonstration.

Choisir la bonne technique

Ces techniques se combinent naturellement : un pipeline décomposé peut inclure une étape en few-shot CoT si cette étape précise l'exige, tandis qu'une autre étape du même pipeline reste en zero-shot simple parce qu'elle ne le justifie pas. Traiter chaque étape isolément, avec la technique minimale suffisante, évite d'appliquer uniformément la solution la plus coûteuse à l'ensemble d'un pipeline.

Schéma de décision

Le schéma ci-dessous résume l'ordre de questions à se poser avant d'ajouter une technique : chaque branche ne s'active que si la précédente a été écartée, ce qui garantit qu'on n'empile jamais plus de complexité que nécessaire.

Checklist avant déploiement

• Le zero-shot a été testé et documenté comme insuffisant avant d'ajouter des exemples.
• Les exemples few-shot ont été vérifiés pour l'absence de données sensibles.
• Les classes représentées dans les exemples sont équilibrées.
• Le CoT n'est activé que sur les étapes qui en tirent un gain démontré, pas par défaut.
• Le comportement de raisonnement natif du modèle a été vérifié avant d'ajouter une consigne CoT redondante.
• Chaque étape d'un pipeline décomposé dispose d'une validation, même minimale, avant de transmettre sa sortie à l'étape suivante.
• Le coût et la latence cumulés du pipeline ont été mesurés sur un échantillon représentatif, pas uniquement sur des cas favorables.

Erreurs fréquentes

• Ajouter du few-shot ou du CoT par réflexe, sans avoir mesuré l'écart avec le zero-shot.
• Multiplier les exemples au-delà du point de rendement décroissant, par excès de prudence.
• Confondre une chaîne de raisonnement convaincante avec une preuve de justesse.
• Décomposer une tâche simple qui n'en avait pas besoin, ajoutant de la latence sans bénéfice mesurable.
• Oublier de mesurer le coût cumulé réel d'un pipeline en production, au-delà du coût par appel isolé.