Réflexion
La réflexion consiste à faire critiquer par un modèle sa propre sortie, puis à la réviser en utilisant cette critique comme retour d'expérience. C'est un moyen léger, basé sur un seul modèle, de détecter les erreurs et d'améliorer la qualité des tâches de raisonnement, de codage et de rédaction — au coût d'appels supplémentaires.
Définition
La réflexion est un modèle dans lequel un modèle examine et critique sa propre sortie par rapport à des critères explicites, puis la révise, échangeant une inférence supplémentaire contre une qualité supérieure.
Problème
Les modèles produisent souvent une première réponse imparfaite qu'ils pourraient améliorer si on les invitait à revoir leur propre travail, mais une seule passe ne leur en donne pas l'occasion.
Quand l'utiliser
Utilisez la réflexion lorsqu'une étape d'auto-examen améliore de manière mesurable la sortie et que vous souhaitez une alternative plus simple à une boucle d'évaluation à deux modèles — ce qui est courant dans les tâches de raisonnement et de codage.
Solution
Après avoir généré une réponse, demandez au même modèle de la critiquer par rapport à l'objectif (et à tout retour d'outil tel que des résultats de tests ou des erreurs), puis de produire une réponse révisée tenant compte de cette critique. Répétez l'opération pour un nombre limité d'itérations.
La réflexion fonctionne mieux lorsqu'elle s'appuie sur des signaux réels — erreurs d'exécution, résultats de tests, faits récupérés — plutôt que sur une simple auto-évaluation, qui peut être trop confiante.
Composants
Avantages
- Améliore la qualité avec un seul modèle — pas de second système.
- Efficace lorsqu'elle s'appuie sur les retours d'outils ou de tests.
- Simple à ajouter à un appel existant.
Risques
- L'auto-critique peut être trop confiante ou passer à côté de ses propres erreurs.
- Les appels supplémentaires ajoutent de la latence et des coûts.
- Sans ancrage, les gains sont limités.
Quand ne pas l'utiliser
- Lorsque vous disposez d'un contrôle externe objectif — utilisez l'évaluateur-optimiseur.
- Lorsqu'un seul passage atteint déjà le niveau requis.
- Lorsque les budgets de latence sont très serrés.
Technologies
Exemples
- Un agent de codage lisant les échecs de tests et corrigeant son propre correctif.
- Une tâche de raisonnement où le modèle vérifie à nouveau ses étapes avant de répondre.
- Un brouillon que le modèle examine pour y déceler des lacunes avant de le finaliser.
Preuves de production
- Contexte
- Tâches où la qualité des résultats importe plus que la latence ou le coût — rédaction, génération de code, analyse — et où les erreurs sont détectables lors de la révision.
- Scénario
- Après avoir produit une première réponse, le modèle (ou un critique distinct) l'évalue par rapport à des critères concrets et produit une version révisée ; la boucle est limitée à un ou deux passages.
- Technologie
- Une chaîne de prompts critique-puis-révision, idéalement soutenue par des signaux externes (tests, outils, évaluateur distinct) pour les tâches à enjeux élevés.
- Charge
- Chaque passage de réflexion double au moins les appels, il est donc appliqué de manière sélective aux résultats qui justifient ce surcoût.
- Résultats
- Modèle observé : la réflexion améliore la qualité lorsque le modèle peut réellement détecter ses propres erreurs, mais elle peut sur-réviser des réponses correctes et double au moins le coût. Mesurez l'amélioration de la qualité par rapport à un ensemble d'évaluation avant de lui faire confiance, et privilégiez les signaux externes lorsque les enjeux sont élevés.
KPI
- Amélioration de la qualité grâce à la réflexion
- Amélioration mesurée de la qualité des résultats avec l'étape de réflexion par rapport à une exécution sans ; si elle n'est pas mesurable, l'étape ne justifie pas son coût.
- Taux d'auto-correction
- Part des erreurs réelles que le modèle détecte et corrige lors de la révision — distincte des modifications cosmétiques.
- Latence et coût supplémentaires
- La réflexion double au moins les appels ; suivez le surcoût par rapport à la qualité qu'elle apporte.
- Taux de sur-révision
- Fréquence à laquelle la réflexion dégrade une réponse déjà satisfaisante en la remettant en question.
Modes de défaillance observés
- Angles morts de l'auto-évaluation : un modèle ne voit souvent pas ses propres erreurs, de sorte que la réflexion passe à côté.
- Sur-révision : le modèle « corrige » une réponse correcte pour en faire une moins bonne.
- Le coût et la latence doublent (ou plus) pour un gain de qualité marginal ou nul.
- Fausse confiance : le modèle affirme que le résultat est désormais correct alors qu'il ne l'est pas.
Leçons apprises
- Mesurez l'amélioration ; la réflexion n'en vaut la peine que lorsqu'elle améliore manifestement la qualité.
- Privilégiez les signaux externes (tests, outils, évaluateur distinct) à la simple auto-critique lorsque les enjeux sont élevés.
- Limitez la réflexion à un ou deux passages — les rendements diminuent rapidement et les coûts s'accumulent.
- Donnez à l'étape de réflexion des critères concrets, et non une consigne vague comme « améliore ceci ».
FAQ
- Réflexion ou évaluateur-optimiseur ?
- La réflexion utilise un seul modèle pour s'auto-critiquer (plus simple) ; l'évaluateur-optimiseur utilise un évaluateur distinct (plus précis, moins biaisé). Choisissez en fonction de la fiabilité de l'auto-évaluation pour votre tâche.
- La réflexion est-elle toujours utile ?
- Elle est surtout utile lorsqu'elle s'appuie sur des retours réels tels que des résultats de tests ou des erreurs. Une simple auto-évaluation peut être trop confiante et apporter peu.
- Combien de cycles de réflexion ?
- Limitez-les — souvent un ou deux. Les rendements décroissants et l'augmentation des coûts font que les boucles longues en valent rarement la peine.