Votre équipe a des invites dispersées dans la base de code. Certains sont dans les fichiers de configuration. Certaines sont des chaînes codées en dur. Quelques-uns des plus critiques se trouvent dans un document Google géré par une seule personne. Personne ne se souvient pourquoi l'invite du système pour la fonction de résumé indique « répondez en tant que bibliothécaire britannique utile » - mais la suppression de cette phrase aggrave le résultat, donc il reste.
C'est ainsi que la plupart des équipes gèrent les invites, et c'est à peu près l'équivalent d'écrire du code sans contrôle de version en 2005. Cela fonctionne jusqu'à ce que cela ne fonctionne plus, et lorsqu'il cesse de fonctionner, vous n'avez aucune idée de ce qui a changé ni de comment y remédier.
Les rétrospectives d'ingénierie de prompts apportent la même discipline aux interactions LLM que les rétrospectives d'ingénierie ont apporté au développement de logiciels : examen systématique, apprentissage partagé et amélioration incrémentielle. Voici comment procéder réellement.
Le problème avec les invites ad hoc
La plupart des équipes développent des invites selon un cycle qui ressemble à ceci : quelqu'un rédige une invite, la teste par rapport à quelques exemples, l'envoie et passe à autre chose. Lorsque la qualité de sortie se dégrade ou qu'un nouveau mode de défaillance apparaît, quelqu'un modifie l'invite en fonction du cas d'échec spécifique, interrompt peut-être trois autres cas au cours du processus, et le cycle se répète.
Les problèmes liés à cette approche s’aggravent :
Pas d'historique. Lorsque vous modifiez une invite, l'ancienne version disparaît. Si la nouvelle version est pire, vous ne pouvez pas facilement revenir en arrière. Si quelqu'un demande « pourquoi l'invite dit-elle cela ? », personne ne le sait.
Pas d'apprentissage partagé. La personne qui a compris que l'ajout de « penser étape par étape » à l'invite de raisonnement améliorait considérablement la précision ne partage pas cette idée. La personne qui écrit l’invite suivante apprend la même leçon à partir de zéro.
Aucun test systématique. Les invites sont testées par rapport aux exemples qui viennent à l'esprit, qui sont généralement les cas faciles. Les cas extrêmes, les intrants contradictoires et les changements de distribution ne sont pas testés jusqu'à ce qu'ils échouent en production.
Aucune mesure. "Le résultat est meilleur" est la méthode d'évaluation la plus courante. Mieux, comment ? Par rapport à quoi ? Mesuré par qui ? Sans une évaluation cohérente, vous ne pouvez pas savoir si les changements constituent réellement des améliorations.
Une rétrospective rapide et régulière aborde ces quatre problèmes.
Ce qu'il faut examiner dans une rétrospective rapide
Rassemblez vos preuves
Avant la rétrospective, rassemblez :
Échecs de production. Toute instance dans laquelle une fonctionnalité basée sur LLM a produit une mauvaise sortie qu'un utilisateur a remarquée. Capturez l'entrée, l'invite et la sortie. Si vous avez des commentaires d'utilisateurs (coup de pouce, plaintes, corrections), incluez-les.
Modifications des invites depuis la dernière rétro. Quelles invites ont changé, quelle était l'intention derrière le changement et que s'est-il passé par la suite ? Si vous contrôlez la version de vos invites (vous devriez l'être), il s'agit d'une révision différentielle. Si ce n’est pas le cas, c’est la première action de votre rétro.
Tendances des mesures de qualité. Si vous effectuez des évaluations automatisées (plus d'informations ci-dessous), apportez les tendances. Les choses s'améliorent-elles ? Ça empire ? Plat?
Données de coût et de latence. Les invites affectent directement les deux. Une invite système détaillée qui améliore légèrement la qualité mais double l'utilisation de vos jetons est un compromis qui mérite d'être discuté explicitement.
La conversation
Une bonne rétrospective rapide couvre trois questions :
1. Où nos invites échouent-elles et pourquoi ?
Classez vos échecs. Catégories communes :
- Instruction suivante : Le modèle n'a pas fait ce que l'invite a demandé. Cela signifie généralement que l'instruction est ambiguë ou contredit une autre partie de l'invite.
- Violations de format : le modèle a renvoyé JSON lorsque vous vouliez du texte brut, ou vice versa. Généralement réparable avec des spécifications de format et des exemples plus clairs.
- Hallucination : Le modèle a généré des informations non prises en charge par le contexte fourni. Il peut s'agir d'un problème rapide (instructions de mise à la terre faibles) ou d'une limitation du modèle.
- Dérive tonalité/style : La sortie sonne différemment de celle prévue. Cela arrive souvent lorsque les invites sont longues et que les instructions de style sont enterrées.
- Echecs de cas Edge : L'invite fonctionne pour les entrées typiques mais s'interrompt pour les entrées inhabituelles. C’est là que le manque de tests systématiques fait le plus mal.
Pour chaque catégorie d'échec, demandez : s'agit-il d'un problème d'invite, d'un problème de modèle ou d'un problème d'entrée ? Le correctif est différent pour chacun.
2. Qu'avons-nous appris sur la conduite de ce modèle ?
Chaque modèle a des bizarreries. GPT-4 répond différemment à la même invite que Claude, et les deux changent de comportement avec les mises à jour. Votre équipe accumule des connaissances sur ces bizarreries grâce à son travail quotidien – la rétrospective est l'endroit où ces connaissances sont partagées et documentées.
Éléments utiles à capturer :
- Techniques qui améliorent de manière fiable le rendement (et pour quels types de tâches)
- Des approches qui semblaient devoir fonctionner mais qui n’ont pas fonctionné
- Le comportement du modèle change après les mises à jour du fournisseur
- Modèles d'invite qui fonctionnent bien pour vos cas d'utilisation spécifiques
Cela crée une base de connaissances d’équipe qui empêche tout le monde de redécouvrir les mêmes enseignements.
3. Que devrions-nous changer ou tester ensuite ?
Sur la base des échecs et des apprentissages, identifiez des expériences spécifiques. Les bonnes expériences sont :
- Portée étroite (changer une chose à la fois)
- Mesurable (définissez ce que « meilleur » signifie avant de tester)
- Limité dans le temps (exécuté pendant une période ou un nombre d'évaluations spécifique)
Exemple : "Nous testerons si l'ajout de deux exemples de format de sortie souhaité à l'invite du service client réduit les violations de format de 12 % à moins de 5 %, mesurées sur 200 requêtes de production."
Construire une pratique de gestion rapide
Les rétrospectives sont plus efficaces lorsque vous disposez d’une gestion de base des invites. Vous n'avez pas besoin d'outils sophistiqués pour commencer, juste quelques pratiques.
Contrôlez la version de vos invites
Traitez les invites comme du code. Stockez-les dans votre référentiel, examinez les modifications apportées aux PR et marquez les versions. Cela vous donne un historique, une capacité de restauration et une surveillance des révisions. Si une modification rapide dégrade la qualité, vous pouvez voir exactement ce qui a changé et l'annuler.
Pour les équipes avec de nombreuses invites, envisagez une structure de répertoires dédiée :
prompts/
summarization/
system.txt
few-shot-examples.json
customer-service/
system.txt
escalation-rules.txt
classification/
system.txt
label-definitions.json
Créer un ensemble d'évaluation
Pour chaque invite principale, conservez un ensemble de cas de test : des paires entrée-sortie où vous savez à quoi ressemble une bonne sortie. Cela n'a pas besoin d'être énorme : 20 à 50 cas par invite qui couvrent une utilisation typique, des cas extrêmes et des modes de défaillance connus.
Exécutez votre ensemble d’évaluation chaque fois que vous modifiez une invite. Cela détecte les régressions avant qu’elles n’atteignent la production. La mise en place prend du temps au départ, mais permet de gagner beaucoup plus de temps que le débogage des échecs de production.
Documentez vos décisions
Lorsque vous effectuez un changement rapide, rédigez une brève note : quel était le problème, qu'avez-vous changé et pourquoi espériez-vous que cela vous aide. Cela semble être une surcharge jusqu'à trois mois plus tard, lorsque vous regardez une invite et que vous vous demandez pourquoi elle inclut une instruction apparemment aléatoire qui s'avère critique.
Formats rétrospectifs rapides qui fonctionnent
Tous les modèles rétro ne doivent pas nécessairement être identiques. Voici deux formats qui fonctionnent bien à différentes cadences :
L'examen rapide (30 minutes, toutes les deux semaines)
Pour les équipes itérant rapidement. Passez en revue les échecs de production depuis la dernière session, discutez de toutes les modifications rapides qui ont été apportées, partagez chacun une idée d'incitation et choisissez l'expérience la plus prioritaire pour les deux prochaines semaines. Gardez-le serré et orienté vers l’action.
The Deep Dive (90 minutes, mensuellement)
Pour quand vous avez besoin de prendre du recul et de regarder la situation dans son ensemble. Examinez les mesures de qualité et les tendances dans toutes les invites. Choisissez l'invite la moins performante et effectuez une analyse approfondie : passez en revue les échecs, discutez de la cause profonde, réfléchissez aux approches et concevez une expérience appropriée. Vérifiez également votre bibliothèque d'invites et votre documentation pour vérifier qu'elles ne sont pas obsolètes : certaines invites sont-elles obsolètes ou inutilisées ?
L'examen des incidents (ad hoc)
Lorsqu'une défaillance rapide provoque un véritable incident pour l'utilisateur, effectuez un examen ciblé dans quelques jours. Que s'est-il passé, pourquoi l'invite a-t-elle échoué, pourquoi nos tests ne l'ont-elle pas détectée et qu'ajoutons-nous à notre ensemble d'évaluation pour éviter cette classe d'échec ?
Pièges courants
Invites de sur-ingénierie. Les invites plus longues ne sont pas toujours meilleures. Chaque instruction que vous ajoutez peut interagir avec toutes les autres instructions de manière imprévisible. Si votre invite contient plus de 500 mots, demandez-vous si vous essayez d'en faire trop dans une seule invite et si vous ne devriez pas la diviser en chaîne.
Optimisation pour la mauvaise métrique. Une invite qui obtient de bons résultats sur les métriques automatisées mais produit des sorties que les utilisateurs trouvent inutiles n'est pas une bonne invite. Incluez une évaluation humaine dans votre processus, et pas seulement une notation automatisée.
Ignorer le coût. Des améliorations rapides qui doublent l'utilisation de vos jetons pourraient ne pas valoir le gain de qualité. Suivez le coût par requête ainsi que la qualité et faites des compromis explicitement.
Corriger les symptômes au lieu des causes. Si vous continuez à corriger la même invite pour de nouveaux modes de défaillance, l'invite a probablement besoin d'une refonte plutôt que d'un autre pansement. Vos données rétrospectives montreront ce modèle : une invite qui apparaît dans les listes d'échecs de plusieurs rétrospectives nécessite une attention plus fondamentale.
Ne pas tester avec des entrées contradictoires. Vos utilisateurs feront des choses auxquelles vous ne vous attendez pas. Votre rétrospective doit périodiquement inclure un examen de ce qui se passe lorsque l'invite reçoit des entrées inhabituelles, hostiles ou hors de portée. N'attendez pas un incident de production pour découvrir que votre invite n'a aucun garde-fou.
Commencer
Vous n’avez pas besoin de tout comprendre pour commencer. Voici une première étape minimale :
- Choisissez votre fonctionnalité la plus importante alimentée par LLM.
- Collectez 10 échecs récents (mauvaises sorties, plaintes des utilisateurs, tout ce qui n'est pas optimal).
- Passez 30 minutes avec votre équipe à classer pourquoi chacun a échoué.
- Identifiez le modèle de défaillance le plus courant et concevez une expérience pour y remédier.
- Exécutez l’expérience et examinez les résultats dans deux semaines.
C'est votre première rétrospective rapide. Faites-le encore et encore et vous développerez vos muscles. Les équipes offrant la meilleure qualité de sortie d'IA ne sont pas celles qui proposent les invites les plus intelligentes : ce sont celles qui apprennent systématiquement de leurs échecs et ne commettent jamais deux fois la même erreur.
Essayez NextRetro gratuitement — Classez les échecs d'invite en catégories, votez sur les priorités et suivez les expériences d'amélioration au fil des sprints.
Dernière mise à jour : février 2026
Temps de lecture : 7 minutes
