Prompting inversé : transformer une bonne session avec un LLM en un prompt réutilisable

Le prompt qui fonctionne finalement est rarement celui avec lequel vous avez commencé : il émerge au fil de plusieurs rounds de corrections, puis disparaît lorsque vous fermez la conversation. Le prompting inversé inverse le flux de travail habituel. Vous obtenez d’abord un résultat qui vous convient, puis vous demandez au modèle de reconstituer les instructions capables de le produire de manière fiable. Vous apprendrez comment extraire ces instructions à partir d’une conversation, comment récupérer un prompt approximatif uniquement à partir des résultats, et où ces deux techniques cessent d’être fiables.

Pourquoi le prompt fonctionnel se perd généralement

Le prompting inversé repose sur le fait que les modèles de pointe actuels sont capables de réfléchir à leur propre contexte. Il fonctionne manuellement dans une fenêtre de conversation ou sous forme de script en tant qu’étape d’un pipeline, et il est particulièrement efficace dans la génération de code et les workflows agents, où les exigences sont nombreuses et faciles à oublier.

Un cycle de perfectionnement typique

Imaginez un développeur qui ajoute une extrémité d’enregistrement d’utilisateur à un service Python. L’objectif est de créer du code FastAPI de qualité professionnelle : entrées validées, réponses d’erreur structurées, journalisation et tests. La demande initiale est délibérément vague, du type « écrivez une extrémité FastAPI pour l’enregistrement d’utilisateur », et la première réponse est prévisiblement minimale. Le développeur itère donc :

• Demander des modèles Pydantic qui valident l’adresse e-mail et imposent une force de mot de passe adéquate.
• Demander des exceptions HTTP appropriées ainsi que de la journalisation.
• Demander une structure JSON unique et cohérente pour chaque erreur.
• Demander des cas pytest couvrant le scénario réussi ainsi que les échecs de validation.

Quelques tours plus tard, le code atteint les critères fixés par l’équipe, est copié dans le répertoire de stockage, et la conversation est oubliée, tout comme toutes les contraintes et corrections qui l’ont façonnée. Le prochain point d’entrée reprend alors à partir d’une instruction vague et concise.

Extraction d’un prompt unique à partir de la conversation

La version basée sur la conversation du reverse prompting résout ce problème grâce à un message supplémentaire. Une fois que le résultat est correct, on ajoute une instruction métainstructive demandant au modèle d’examiner l’ensemble de l’échange et de le compresser en un seul prompt autonome. L’instruction ci-dessous précise ce que ce prompt doit contenir : le rôle, le contexte accumulé, toutes les contraintes convenues, le format de sortie, les critères de qualité et tous les exemples possibles. Prêtez attention aux deux dernières lignes : elles demandent uniquement le prompt, sans aucun commentaire, afin que le résultat puisse être collé directement dans une nouvelle session.

Now that we have reached this final output, reverse-engineer
the entire conversation. Look at every correction, added constraint,
tone adjustment, format decision, and the result.
Produce one complete, standalone prompt that would generate
this exact output quality in a single shot with no follow-ups.

The prompt must explicitly state:
- Role and expertise level
- All background context and requirements established
- Every constraint and rule settled on
- Output format and structure
- Tone, style, and quality criteria
- Any examples or reference patterns used

Output only the prompt itself, ready to copy into a fresh session.
No explanation.

Ce qui est retourné constitue une spécification explicite de tout ce qui était implicite dans le dialogue. Une nouvelle session l’utilisant devrait produire des résultats comparables dès la première tentative ; si des actions supplémentaires sont encore nécessaires, cela signifie qu’un élément a été oublié.

Considérez ce résultat comme un atout technique :

• Committez-le dans le répertoire à côté du code qu’il génère, afin que les modifications soient examinées et versionnées.
• Partagez-le avec les collègues pour que les mêmes normes s’appliquent quel que soit celui qui l’exécute.
• Remplacez les parties spécifiques à une tâche par des paramètres (nom de l’entité, champs, codes d’erreur) et réutilisez-le pour des endpoints similaires.

Récupérer une instruction à partir uniquement des résultats

La méthode conversationnelle ne fonctionne que tant que l’historique est encore disponible. Une technique plus générale, connue sous le nom d’inversion de prompt ou d’ingénierie inverse de prompt (RPE), permet de reconstruire une approximation du prompt à partir uniquement du texte qu’il a généré.

Formulé de manière formelle : un prompt caché X a produit une sortie O. On souhaite trouver un prompt P dont la sortie N soit sémantiquement et fonctionnellement proche de O. On n’a accès qu’à une boîte noire, c’est-à-dire sans logits ni données d’entraînement, seulement la capacité d’envoyer des prompts et de lire les réponses.

Sélection des candidats et validation de ceux-ci

L’approche directe comporte trois étapes :

• Fournissez au modèle la sortie O et demandez-lui d’inférer le prompt qui se cache derrière. Une seule tentative a tendance à surajuster ou à inventer des contraintes qui n’existaient pas, il faut donc le faire plusieurs fois avec différentes températures et paramètres d’échantillonnage afin de recueillir un ensemble de prompts candidats.
• Faites passer chaque candidat par le modèle et comparez ce qu’il génère avec O, en utilisant une métrique d’overlap telle que ROUGE-1 (le score F1 basé sur les unigrammes communs).
• Conservez le candidat ayant le score le plus élevé.

C’est l’étape de validation qui transforme cela en quelque chose de plus qu’une simple supposition : vous mesurez quel candidat reproduit réellement l’objectif, plutôt que de vous fier à l’opinion du modèle.

Évolution des candidats comme dans un algorithme génétique

• Évaluer la qualité en fonction de la similarité moyenne entre les résultats générés par un candidat et l’O original.
• Conserver les meilleurs résultats.
• Muter ceux qui sont moins performants en fournissant au modèle le prompt actuel ainsi que les différences observées, et lui permettre de reformuler, d’ajouter ou de supprimer des contraintes, ou de restructurer le texte.
• Repetir jusqu’à ce que les scores cessent d’améliorer ou que le budget soit épuisé.

Cette approche ne nécessite aucune formation. On a constaté qu’elle permet d’obtenir des prompts cohérents et réutilisables à partir de seulement cinq résultats d’échantillon, et les modèles propriétaires ne posent aucun obstacle, car tout ce dont on a besoin, c’est d’une fonction de similarité peu coûteuse.

Limites à prendre en compte

La reconstruction est toujours une approximation. Le prompt récupéré est souvent plus long et plus explicite que celui qui a donné naissance au résultat, car il doit indiquer des nuances initialement contenues dans le contexte.

Deux autres précautions :

• Les prompts issus de reverse engineering conservent les particularités du modèle d’où ils proviennent. Un prompt optimisé pour un modèle peut nécessiter des ajustements avant de fonctionner aussi bien sur un autre ; validez-le à nouveau lors du changement.
• Les métriques lexicales comme ROUGE-1 récompensent la présence de mots communs, et non le bon fonctionnement. Pour du code ou des résultats structurés, envisagez d’ajouter des vérifications importantes pour vous, telles que le succès des tests générés ou la validité du JSON, en plus du score de similarité.

Le rôle des agents de codage

Les outils de codage basés sur des agents tels que OpenAI Codex et Claude Code sont optimisés pour l’approche en avant, avec une forte capacité d’ingénierie de contexte, des boucles d’agent longues et un usage intensif du cache de prompts. Néanmoins, ils peuvent s’arrêter avant d’écrire du code et vous poser des questions à choix multiples pour clarifier les besoins dès le début. Itérez avec l’agent jusqu’à obtenir un résultat solide, puis extrayez un prompt principal de cette session afin de pouvoir l’utiliser à nouveau immédiatement. Pour une méthode complémentaire pour structurer les prompts que vous extrayez, consultez notre guide sur la création de prompts prêts à l’emploi pour les LLM avec un cadre en sept couches.

Points clés

• La véritable valeur d’une longue session de création de prompts réside dans les contraintes accumulées ; capturez-les avant de fermer la conversation.

Une seule instruction métainstruction à la fin d’une conversation réussie permet de la transformer en une requête autonome et versionnable.

Lorsqu’il n’y a que des résultats d’output, générer de nombreuses requêtes candidates et laisser une métrique de similarité, plutôt que la confiance du modèle, choisir le meilleur résultat.

Les requêtes récupérées sont des approximations liées à un modèle spécifique ; il convient donc de les valider lors d’une session nouvelle, ainsi que chaque fois que le modèle change.

Lectures complémentaires

• Échanger des modèles LLM en toute sécurité : étiquettes humaines, métriques par étape, paramètres d’effort — Comment migrer un pipeline LLM à plusieurs étapes vers de nouveaux modèles sans subir de régressions invisibles : données de référence fournies par des humains, métriques par étape, requêtes obsolètes et effort de raisonnement.
• Où se trouvent les instructions de Claude Code : CLAUDE.md, règles de chemin ou hooks — Découvrez pourquoi Claude Code traite CLAUDE.md comme un contexte, comment le raccourcir, appliquer des règles en fonction du chemin, déplacer les étapes obligatoires dans des hooks, et vérifier ce qui est réellement chargé.
• Des outils d’évaluation pour les applications basées sur des LLM : ensembles de données, systèmes de notation et mécanismes de détection des régressions — Apprenez ce qu’est un outil d’évaluation pour des LLM, ses quatre composants principaux, ainsi que la manière dont il détecte les régressions liées aux prompts et compare équitablement les modèles avant qu’ils n’arrivent aux utilisateurs.
• Vision LLM OCR auto-hébergée en Go : Rastérisation, incitation, parsing — Comment un processus en Go transforme des PDF médicaux en JSON structuré à l’aide d’Ollama, pdftoppm, de prompts stricts, d’un parsing de secours et de groupes de consommateurs Redis Streams.
• Construire un refineur et générateur de prompts personnalisé avec les artefacts Claude — Comment transformer une conversation Claude en un outil de prompts réutilisable qui améliore les prompts faibles et développe des idées approximatives en versions de base, avancées et expertes.