Une réponse de ChatGPT peut sembler aboutie tout en oubliant une contrainte ou en inventant un détail. Le recursive prompting consiste à s’appuyer sur cette réponse pour formuler une nouvelle instruction, plus ciblée. Une boucle de génération, de contrôle et de correction se met alors en place.
Pratique pour améliorer un article, déboguer un programme ou approfondir une analyse, cette technique n’est pourtant ni une garantie d’exactitude ni une fonctionnalité magique. Les spécialistes emploient même le terme pour des approches différentes. Pour en tirer quelque chose, il faut comprendre ce qui est réellement récursif, organiser les retours et reconnaître le moment où une nouvelle réponse n’apportera plus rien.
Trois points clés
- Le recursive prompting exploite les sorties précédentes pour ajuster les consignes et progresser par étapes.
- Une boucle utile isole les défauts, préserve les contraintes et confronte les réponses à des preuves indépendantes.
- Les résultats de recherche concernent des protocoles précis : ils ne garantissent pas qu’une répétition améliore chaque réponse.
Le recursive prompting utilise la réponse comme nouveau point de départ
Dans un échange classique, l’utilisateur pose une question et reçoit une réponse. Avec le recursive prompting, il reprend cette sortie dans une nouvelle demande : « Quelles conditions as-tu omises ? », « Vérifie cette affirmation » ou « Réécris uniquement le passage incorrect ». La réponse précédente fait ainsi évoluer le contexte et le prompt suivant. Les définitions de Moveworks, LatentView et Promptitude décrivent cette progression par retours successifs.
Une FAQ illustre le mécanisme. Le modèle rédige une première version, puis l’utilisateur lui fournit les conditions contractuelles absentes. Un autre prompt demande de corriger uniquement les réponses concernées. Ce n’est pas le nombre de messages qui compte, mais l’information ajoutée à chaque passage. La méthode prolonge le prompt engineering et peut être conduite manuellement, sans agent ni programmation. Elle n’exige pas non plus un « mode récursif » dédié dans l’interface. Le changement vient du protocole de dialogue : relire, identifier une lacune, transmettre un signal nouveau et comparer les résultats. Pour un travail ponctuel, cette simplicité est précisément son intérêt.
Itération, récursion et autocorrection ne sont pas synonymes
Le mot « recursive » entretient une ambiguïté. Dans les guides pratiques, comme celui de Jeremy Morgan, il désigne surtout une révision itérative : une version, un commentaire, une version corrigée. Au sens informatique strict, la récursion implique qu’une procédure se rappelle sur un problème réduit. Un système peut ainsi décomposer une question complexe en sous-questions, les traiter, puis assembler leurs résultats.
Ces méthodes sont compatibles, mais différentes. Une boucle de correction retravaille le même objet ; une décomposition récursive construit souvent un arbre de sous-tâches. De même, l’autocorrection par un LLM ne signifie pas que ce modèle a acquis de nouvelles connaissances ou modifié ses paramètres. Il reformule une réponse dans le contexte disponible. Sans donnée nouvelle, il peut reproduire son erreur initiale avec davantage d’assurance.
Une boucle efficace repose sur quatre étapes vérifiables
La première étape consiste à définir le but et les critères de réussite. Pour une fiche produit, il peut s’agir de contrôler la garantie, le prix annoncé et le pays de disponibilité. La deuxième produit une réponse de référence. Conservez-la : sans version initiale, difficile de savoir ce qui a réellement progressé.
La troisième étape examine le résultat en pointant les défauts. Il faut demander des extraits précis, pas un jugement vague sur la qualité. La quatrième corrige les problèmes identifiés, puis compare le texte aux critères initiaux. Cette organisation évite qu’une révision stylistique masque une erreur factuelle. Le diagnostic peut être produit par l’IA, mais la vérification décisive doit venir d’un document, d’un calcul ou d’un test quand c’est possible.
Fixez également une condition d’arrêt : objectifs atteints, défaut non résoluble avec les sources disponibles ou absence de progrès. Une deuxième version plus longue n’est pas nécessairement meilleure. La comparaison doit relever à la fois les erreurs corrigées et les éventuelles régressions.
« Probe, Scope Tighten, Refine » organise une autre forme de boucle
Le dépôt GitHub Recursive Prompting de Seth Robins présente une séquence complémentaire : Probe pour explorer plusieurs pistes, Scope Tighten pour resserrer le périmètre, puis Refine pour améliorer l’option retenue. Plutôt que de polir la première idée venue, le système cherche d’abord à éviter un mauvais choix initial.
Dans un rapport, cela signifie proposer trois angles, sélectionner celui qui correspond au lectorat, puis retravailler son plan. Le document Implementation, Diagnostics, and Checklists décrit des symptômes concrets : réponse générique, digression ou choix prématuré. À chaque défaut correspond une intervention ciblée. Il s’agit d’un cadre proposé par son auteur, pas d’une norme universelle : le dépôt présente une analyse de 441 conversations menée auprès d’un seul praticien. Ses chiffres ne peuvent être généralisés sans essais indépendants. Le dépôt distingue également plusieurs mouvements de pilotage, comme comparer des hypothèses, décomposer une tâche ou reformuler une contrainte. Inutile de tous les enchaîner à chaque fois. Face à un mauvais angle, on revient à l’exploration ; face à un contenu hors sujet, on resserre les instructions. Le choix de l’étape dépend du problème observé.
Un exemple de prompt pour ChatGPT ou Claude
Pour appliquer la méthode, donnez le document à corriger, les sources et quelques exigences prioritaires. Le modèle doit d’abord établir un diagnostic distinct de la réécriture. On conserve ainsi une trace des décisions et des éléments impossibles à confirmer.
OBJECTIF : améliorer le document sans inventer de faits.
CRITÈRES : exactitude, sources, longueur et lisibilité.
1. Repère jusqu’à cinq défauts, avec leurs extraits.
2. Classe-les selon leur impact et indique les preuves disponibles.
3. Corrige uniquement les passages concernés.
4. Signale séparément toute information invérifiable.
ARRÊT : ne relance pas la correction sans défaut nouveau.
Si le modèle ne possède pas la documentation nécessaire, mieux vaut la fournir que lui demander de réfléchir encore. Promptitude mentionne aussi la possibilité de faire améliorer le prompt initial par l’IA. Utile pour clarifier une demande, cette variante ne remplace ni la définition des critères ni le contrôle des sources.
Rédaction, programmation, support : trois applications concrètes
Un journaliste peut extraire les informations d’un communiqué, faire relire son brouillon à l’aune des documents officiels, puis corriger les affirmations trop catégoriques. Cette boucle est pertinente pour repérer une disponibilité mal datée. Le journaliste conserve néanmoins la responsabilité de la vérification finale.
Un développeur transmet le message d’erreur et le test défaillant. Le modèle propose un correctif limité, puis les tests sont relancés. Ici, le retour d’un outil externe permet de juger le résultat. Une réponse persuasive ne suffit pas si le programme échoue toujours. Les tests de non-régression sont importants : un correctif qui résout un bug mais en introduit deux autres ne constitue pas un progrès. La boucle doit donc vérifier les fonctions voisines, pas uniquement la ligne modifiée.
Un assistant peut comparer une réponse à une politique de remboursement, puis corriger un délai erroné. Il ne doit pas inventer les conditions particulières d’un dossier ni autoriser une opération non permise. Les outils, les documents à jour et les permissions décrits dans le context et harness engineering restent indispensables.
Les limites : dérive, illusions de progrès et chiffres non confirmés
Une boucle mal conduite peut amplifier une erreur initiale. Si chaque version reprend une date inventée, le résultat devient plus fluide sans gagner en fiabilité. Les consignes peuvent aussi dériver : une exception disparaît, une tâche secondaire prend toute la place. Les diagnostics du dépôt de Seth Robins invitent justement à resserrer le périmètre dès qu’une réponse s’éloigne de l’objectif. Un nouveau prompt doit corriger une faiblesse identifiable, pas ajouter du bruit.
Il faut également distinguer les niveaux de preuve. Une publication sur le forum Hugging Face présente une interprétation ludique du recursive prompting, avec des gains chiffrés revendiqués. Ce message communautaire n’est pas, à lui seul, une validation scientifique indépendante ; il ne faut ni confondre cette proposition avec le dépôt GitHub précédent, ni reprendre ses pourcentages comme des résultats établis. De façon plus générale, chaque itération augmente le temps et le coût de traitement. Lorsque l’historique devient très long, les contraintes importantes risquent aussi d’être moins visibles dans le contexte envoyé au modèle. Une synthèse des règles fixes peut alors être préférable à la réinjection intégrale des anciennes réponses.
Ce que le recursive prompting ne remplace pas
Le prompt chaining enchaîne des étapes prévues à l’avance ; une boucle de recursive prompting revient sur une étape lorsqu’un contrôle échoue. Un agent peut automatiser ce retour et appeler des outils, mais un chatbot suffit pour l’approche manuelle. Les Recursive Language Models constituent encore autre chose : une approche de gestion de grands contextes par sous-appels, et non une formule de prompt prête à copier.
Enfin, réinjecter des documents dans la conversation pose aussi des questions de sécurité. Une instruction malveillante placée dans un fichier peut tenter de détourner le système. La répétition des prompts ne protège pas contre les injections de prompt décrites par l’OWASP. Les permissions et les contrôles humains restent nécessaires, en particulier lorsque des agents IA exécutent des actions.
La bonne boucle est celle qui sait s’arrêter
Avant d’automatiser la méthode, comparez ses sorties à celles d’un prompt unique sur plusieurs exemples représentatifs. Suivez le nombre de corrections justifiées, les régressions, le coût et le temps humain économisé. Puis imposez un arrêt après un contrôle réussi ou une absence de progrès. Le recursive prompting apporte surtout une discipline : explorer, vérifier et corriger ce qui le mérite. Si le défaut persiste faute de preuve, la prochaine étape n’est pas un nouveau prompt, mais une meilleure source ou une décision humaine.
- Partager l'article :
