Les grands modèles de langage trébuchent lorsqu'on leur demande d'en faire trop à la fois. Injectez un PDF de cinquante pages dans une fenêtre de chat et demandez une analyse structurée, une évaluation des risques et une synthèse en un seul souffle. Le résultat est généralement superficiel, confus ou totalement erroné. Une meilleure approche est mécanique. Divisez le travail en étapes distinctes. Alimentez la sortie de la première étape directement dans la seconde, et ainsi de suite. Anthropic appelle ce modèle le « prompt chaining ». Google l'appelle un « pipeline séquentiel ». Les deux noms décrivent la même chose : une chaîne de montage où chaque station gère une transformation spécifique.
Ce que cela donne en pratique
Au lieu d'un seul prompt géant, vous construisez une série de petites étapes ciblées. Imaginez une équipe de conformité qui traite les évaluations de sécurité des fournisseurs. La première étape extrait le texte brut d'un PDF numérisé. La deuxième étape identifie chaque mention des normes de chiffrement et des contrôles d'accès. La troisième étape compare ces résultats à une liste de contrôle interne. La quatrième étape rédige une courte note pour le responsable de la sécurité. Un agent transforme le PDF en texte. Le suivant extrait des données spécifiques de ce texte. L'agent final rédige un résumé basé sur ces données. Aucune de ces étapes n'est prestigieuse, et aucune ne fait de multitâche. Chaque partie fait un seul travail, mais elle le fait bien.
C'est pourquoi la métaphore de la chaîne de montage tient la route. Dans une usine, un seul ouvrier n'assemble pas toute la voiture. La spécialisation permet de maintenir une qualité élevée et de limiter les modes de défaillance. La même logique s'applique aux modèles de langage. Un prompt qui demande uniquement l'extraction de JSON est moins susceptible d'halluciner qu'un prompt qui demande également une opinion et une mise en forme dans la même requête.
Construisez des portes de contrôle, pas des suppositions
Le point le plus faible de toute chaîne est le passage de relais. Un modèle peut renvoyer un refus poli, un bloc de markdown au lieu de JSON, ou une réponse tronquée. Si ces déchets parviennent à la deuxième étape, toute la chaîne s'effondre. La solution est une porte de contrôle (gate).
Une porte de contrôle n'est pas un appel de modèle. C'est du code simple. Vous écrivez un court script qui s'exécute entre les étapes. Il peut vérifier la longueur de la sortie pour s'assurer qu'elle n'est pas vide. Il peut exécuter une validation de schéma JSON pour confirmer que les clés correspondent à ce que la troisième étape attend. Une vérification par regex peut vérifier qu'une adresse e-mail ou un champ de date est réellement présent avant même que le prompt suivant ne soit construit. Cela permet d'arrêter les erreurs avant de gaspiller de l'argent pour des résultats erronés. Une porte de contrôle ne coûte que quelques microsecondes de calcul. Un appel LLM échoué en aval coûte des tokens, de la latence et votre santé mentale.
Considérez cela comme un point de contrôle de la qualité dans l'usine. Vous n'avez pas besoin d'IA pour compter des pièces. Vous avez besoin d'une règle.
Quand chaîner, et quand s'arrêter
Le chaînage de prompts n'est pas adapté à tous les problèmes. Utilisez-le lorsque le travail comporte des étapes fixes et répétables. Les rapports financiers mensuels, la révision standardisée de contrats et les pipelines d'analyse de logs en sont de bons exemples. Si vous pouvez écrire la procédure sous forme de liste de contrôle, vous pouvez probablement la chaîner. Vous devriez également recourir au chaînage lorsque vous avez besoin d'une grande précision pour des travaux complexes. Diviser un problème en étapes force le modèle à traiter une seule couche logique à la fois. Enfin, les chaînes sont plus faciles à déboguer que les prompts monolithiques. Si le résumé est faux, vous inspectez l'extraction. Si l'extraction est fausse, vous inspectez le texte source. Vous disposez d'artefacts intermédiaires à examiner.
Évitez le chaînage de prompts lorsque vous ne connaissez pas les étapes à l'avance. La recherche exploratoire, le brainstorming ouvert ou les tâches d'investigation ne suivent pas une ligne droite. Passez outre également si la vitesse est votre seule priorité. Les chaînes sont sérielles ; la deuxième étape ne peut pas commencer tant que la première n'est pas terminée. Si vos étapes ne dépendent pas les unes des autres, exécutez-les plutôt en parallèle. Il n'y a aucune raison de chaîner trois traductions indépendantes du même document.
Le piège de la rigidité
La contrepartie de toute cette structure est la rigidité. Une chaîne fixe ne peut pas s'adapter à de nouvelles situations. Si un fournisseur envoie un formulaire à six champs et que votre porte de validation de schéma en attend cinq, la chaîne s'arrête. Si un utilisateur télécharge un document Word au lieu d'un PDF, la première étape échoue et le reste de la chaîne n'a plus rien à traiter.
Pire encore, les erreurs se propagent. Une erreur survenant tôt se propage dans toute la chaîne. Si l'extracteur de PDF supprime un signe négatif d'un chiffre financier, chaque étape en aval traitera ce mauvais chiffre comme