Enchaîner des prompts, c’est résoudre une tâche avec plusieurs prompts en séquence, la sortie de l’un devenant l’entrée du suivant. La décomposition de prompts est l’étape de conception qui précède : décider comment découper la tâche. Ensemble, elles constituent la façon la plus fiable de faire accomplir à un modèle quelque chose de compliqué.
Pourquoi un gros prompt unique échoue
Un prompt qui demande à un modèle d’extraire, d’analyser, de décider et de rédiger en un seul passage pose plusieurs problèmes :
- Les instructions se font concurrence. Plus un prompt demande de choses, plus il est probable qu’une exigence soit négligée.
- On ne peut pas dire quelle partie a échoué. Une réponse finale fausse peut venir de n’importe quelle étape.
- On ne peut pas tester les parties. Il n’y a rien à vérifier avant la fin.
- Chaque appel paie chaque instruction, même celles sans rapport avec cette entrée.
Une chaîne donne à chaque étape un seul travail, une entrée claire et une sortie vérifiable.
Comment décomposer une tâche
Demandez-vous ce que ferait une personne soigneuse, dans l’ordre, et où elle confierait le travail à quelqu’un d’autre. Les bons points de découpe sont ceux où :
- le type de travail change (lire, puis juger, puis rédiger) ;
- un résultat intermédiaire mérite d’être vérifié (les faits extraits, avant de tirer des conclusions) ;
- une étape ne s’applique que parfois (traduire seulement si le texte n’est pas en anglais) ;
- des étapes différentes demandent des modèles différents (un petit modèle pour classer, un plus grand pour rédiger).
Un exemple travaillé
La tâche : répondre à un e-mail de réclamation d’un client.
Étape 1 : extraire. Un petit modèle rapide transforme l’e-mail en faits structurés.
Extract from the email in the tags: order_id, product, the problem in
one sentence, and what the customer is asking for. Return JSON only.
Use null for anything not stated.
<email>
{{email}}
</email>
Étape 2 : décider. Le code recherche la commande. Un prompt applique la politique.
Given the complaint and the order record, choose one action from:
refund, replace, escalate, explain. Give the policy clause that applies.
Return JSON: {"action": string, "clause": string}.
<complaint>{{step1_json}}</complaint>
<order>{{order_record}}</order>
<policy>{{policy}}</policy>
Étape 3 : rédiger. Un troisième prompt rédige la réponse à partir de la décision.
Write a reply to the customer, under 120 words, that states the action
and what happens next. Do not promise anything outside the action.
<action>{{step2_json}}</action>
<customer_name>{{name}}</customer_name>
Chaque étape peut être testée seule. Si les réponses promettent ce qu’il ne faut pas, vous regardez la sortie de l’étape 2 et vous savez aussitôt si la décision ou la rédaction est en cause.
Transmettre des données entre étapes
Utilisez une sortie structurée entre les étapes. Du JSON ou des champs balisés, pas de la prose. Le prompt suivant, et votre code, peuvent alors compter sur la forme. Voir les prompts de sortie structurée.
Ne transmettez que ce dont l’étape suivante a besoin. Faire suivre tout l’historique allonge les prompts suivants et laisse les premières erreurs se propager.
Validez à chaque frontière. Vérifiez la sortie de chaque étape avant de l’utiliser. Une chaîne sans validation multiplie les erreurs : cinq étapes justes chacune 95 % du temps ne le sont toutes ensemble qu’environ 77 % du temps.
Délimitez tout ce que vous insérez. La sortie d’un modèle est une entrée non fiable pour le suivant. Un e-mail de réclamation qui dit « ignore tes instructions » a traversé l’étape 1 et se trouve maintenant dans le prompt de l’étape 2. Enveloppez le contenu inséré dans des balises. Voir l’injection de prompt.
Formes de chaîne
| Forme | Description | Exemple |
|---|---|---|
| Séquentielle | A puis B puis C | Extraire, décider, rédiger |
| Routage | Classer, puis choisir une branche | Les questions de facturation vont à un prompt, les bogues à un autre |
| Parallèle | Étapes indépendantes simultanées, puis fusion | Résumer 10 documents, puis les combiner |
| Générer et vérifier | Un prompt produit, un autre relit | Rédiger, puis critiquer par rapport aux exigences |
| Boucle | Répéter jusqu’à ce qu’une condition soit remplie | Réviser jusqu’à ce que la validation passe, avec une limite d’essais |
Plafonnez toujours les boucles. Une chaîne qui réessaie indéfiniment, c’est une panne et une facture.
Enchaînement et alternatives
Face à la chaîne de pensée. La chaîne de pensée garde le raisonnement dans une seule réponse. Utilisez-la quand les étapes ne sont pas connues d’avance. Utilisez une chaîne quand elles le sont : vous gagnez en testabilité et en contrôle.
Face aux agents. Dans une chaîne, c’est votre code qui décide de l’ordre. Dans un agent, c’est le modèle. Une chaîne est moins chère, plus rapide et prévisible. Ne choisissez un agent que lorsque le chemin dépend de ce qui est découvert en route. Voir le prompting ReAct et les prompts pour agents IA.
Coûts à surveiller
Une chaîne fait plus d’appels. Gardez-la économique :
- Utilisez le plus petit modèle qui traite chaque étape.
- Exécutez les étapes indépendantes en parallèle pour réduire la latence.
- Sautez les étapes qui ne s’appliquent pas à cette entrée.
- Mettez en cache la partie fixe de chaque prompt lorsque le fournisseur le permet. Voir l’optimisation des tokens.
Gardez chaque maillon en bonne santé
Une chaîne a plusieurs prompts à maintenir, et un problème dans l’un d’eux passe facilement inaperçu. Stockez chacun dans un fichier et vérifiez-les tous à chaque modification. La barrière de test des prompts fait échouer une pull request lorsqu’un prompt du dépôt passe sous votre seuil de qualité ou dépasse son budget de tokens, et l’analyseur de prompts signale les variables non délimitées, qui comptent le plus là où une étape alimente la suivante.