Self-Critique (Auto-critique IA)
La self-critique est la capacité d’un LLM à évaluer, critiquer et corriger ses propres réponses, soit en analysant directement sa sortie (critique intrinsèque), soit en s’appuyant sur des outils externes pour vérifier ses résultats (critique assistée par outils).
- Catégorie
- Technique d’amélioration des sorties LLM à l’inférence
- Aussi appelé
- Self-correction, self-reflection, self-refinement, auto-évaluation
- Frameworks clés
- Self-Refine (Madaan et al., 2023), Reflexion (Shinn et al., 2023), CRITIC (Gou et al., 2023), Constitutional AI (Anthropic)
- Gain typique
- +20 % de performance en moyenne sur 7 tâches (Self-Refine), jusqu’à +300 % sur des tâches ciblées (AIME avec Double-Checker)
- Limite critique
- Sans feedback externe, la self-critique peut dégrader les résultats (le modèle « corrige » des réponses justes en réponses fausses)
- Verdict
- Puissante avec un feedback externe vérifiable, fragile sans. Ne pas confondre « le modèle dit que c’est correct » avec « c’est correct »
Le principe : le LLM comme son propre relecteur
Les humains ne produisent pas toujours leur meilleur travail du premier coup. Nous écrivons un brouillon, le relisons, identifions les faiblesses et le réécrivons. La self-critique applique ce même cycle aux LLM : générer une première réponse, la critiquer, puis la raffiner en boucle.
Le mécanisme de base se décompose en trois étapes :
def self_critique(prompt):
# Étape 1 : Génération initiale
output = llm.generate(prompt)
while True:
# Étape 2 : Critique
feedback = llm.generate(f"Évalue cette réponse. Identifie les erreurs, "
f"imprécisions ou améliorations possibles :n{output}")
# Étape 3 : Raffinement
refined = llm.generate(f"Améliore la réponse en tenant compte "
f"de cette critique :n{feedback}n{output}")
if is_good_enough(refined, feedback):
return refined
output = refinedCe pattern, formalisé par Madaan et al. sous le nom Self-Refine (mars 2023, publié à NeurIPS 2023), ne nécessite ni données d’entraînement supervisé, ni renforcement, ni modèle séparé. Un seul LLM joue trois rôles : générateur, critique et raffineur. Sur 7 tâches variées (génération de dialogues, raisonnement mathématique, optimisation de code), Self-Refine a amélioré les résultats de 20 % en moyenne par rapport à la génération en une seule passe, y compris avec GPT-4.
Les frameworks fondateurs
Self-Refine : la boucle feedback-raffinement
Self-Refine (Madaan et al., 2023) est le framework le plus direct. Le LLM génère, critique, raffine, et recommence jusqu’à ce qu’un critère d’arrêt soit atteint (le modèle juge la réponse satisfaisante ou un nombre maximum d’itérations est atteint).
Le feedback est en langage naturel et couvre deux dimensions : la localisation du problème (« le troisième paragraphe contient une erreur factuelle ») et l’instruction d’amélioration (« reformulez en utilisant les données correctes »). Ce feedback actionnable est ce qui distingue Self-Refine d’une simple réévaluation binaire (bon/mauvais).
Un exemple concret en optimisation de code : Self-Refine identifie que le code initial utilise six boucles imbriquées (complexité exponentielle), diagnostique le problème, et produit une version optimisée avec programmation dynamique. La complexité temporelle passe de O(n⁶) à O(amount × coins).
Reflexion : apprendre de ses échecs
Reflexion (Shinn et al., 2023) étend le pattern ReAct pour les agents IA. Quand l’agent échoue, il ne recommence pas simplement. Il s’arrête, réfléchit sur l’ensemble de sa trajectoire d’actions, produit une « réflexion » textuelle qui analyse ce qui a mal tourné, et charge cette réflexion en contexte pour la tentative suivante.
La différence avec Self-Refine : Reflexion opère sur des trajectoires d’actions complètes (pas juste sur une réponse textuelle) et maintient une mémoire de ses réflexions passées. L’agent accumule de l’expérience au fil des tentatives sans modifier les poids du modèle. C’est un apprentissage par essai-erreur purement basé sur le contexte.
Reflexion a montré des améliorations significatives sur des benchmarks de prise de décision (AlfWorld), de question-réponse (HotPotQA) et de navigation web (WebShop).
CRITIC : la critique assistée par outils
CRITIC (Gou et al., 2023) introduit une idée clé : au lieu de demander au LLM de critiquer sa propre réponse uniquement avec son raisonnement interne, on lui donne accès à des outils externes pour vérifier. Le modèle utilise un moteur de recherche pour vérifier les faits, un interpréteur de code pour tester le code généré, ou un vérificateur logique pour valider les raisonnements.
C’est une distinction fondamentale. La critique intrinsèque (le modèle qui se juge lui-même) est limitée par les connaissances et les biais du modèle. La critique assistée par outils (tool use) est ancrée dans la réalité : le code fonctionne ou ne fonctionne pas, le fait est vrai ou faux selon la source externe.
Constitutional AI : la self-critique pour l’alignement
Anthropic a développé Constitutional AI (CAI) comme un mécanisme de self-critique à l’échelle de l’entraînement. Le modèle est entraîné à critiquer ses propres réponses selon un ensemble de principes constitutionnels (pas de contenu dangereux, pas de biais, réponses utiles et honnêtes). Plutôt qu’un feedback humain pour chaque réponse, le modèle apprend à s’auto-évaluer selon ces principes.
La différence avec les autres approches : Constitutional AI intègre la self-critique dans les poids du modèle via l’entraînement, alors que Self-Refine et Reflexion opèrent uniquement à l’inférence via le prompting.
Techniques de self-critique avancées
Self-Calibration
Le modèle évalue la confiance qu’il accorde à sa propre réponse. Après avoir généré une réponse, on lui demande : « Es-tu sûr de cette réponse ? Quel est ton niveau de confiance ? » Cela aide à identifier les cas où le modèle « devine » plutôt qu’il ne « sait », réduisant les faux positifs.
Self-Consistency
Plutôt qu’une seule critique, le modèle génère N réponses indépendantes au même problème (avec une température non nulle) et sélectionne la réponse la plus fréquente. Si 8 réponses sur 10 convergent vers le même résultat, la confiance est élevée. C’est une forme de critique par consensus plutôt que par analyse directe.
Reversing Chain-of-Thought (RCoT)
Le modèle inverse son raisonnement : à partir de sa réponse, il reconstruit le problème original. Si le problème reconstruit diffère significativement du problème réel, c’est un signal d’hallucination. Cette technique est particulièrement efficace pour détecter les incohérences logiques dans les chaînes de chain-of-thought.
Chain-of-Verification (CoVe)
Le modèle génère des questions de vérification sur sa propre réponse, puis y répond. Si les réponses aux questions de vérification contredisent la réponse initiale, le modèle raffine. C’est une forme de cross-examination automatisée.
Critique adversariale (Self-Play)
Le framework SPC (Self-Play Critic, Chen et al., 2025) entraîne deux modèles en jeu adversarial : un « générateur sournois » qui produit des erreurs subtiles dans les étapes de raisonnement, et un critique qui apprend à les détecter. Par apprentissage par renforcement itératif, les deux s’améliorent mutuellement. C’est l’extension de la self-critique vers le self-play.
Résultats et performances
| Framework / Technique | Benchmark | Avant self-critique | Après self-critique | Gain |
|---|---|---|---|---|
| Self-Refine | 7 tâches (moyenne) | Baseline LLM | +20 % absolu | Significatif |
| Critic-CoT | GSM8K | 89,6 % | 91,7 % (95,4 % avec ensemble) | +2,1 % à +5,8 % |
| Double-Checker | AIME (pass@1) | 4,4 % | 18,2 % | +314 % |
| Reflexion | AlfWorld | Baseline ReAct | Amélioration significative | Variable par tâche |
Les gains sont réels, mais ils varient considérablement selon la tâche et le modèle. Sur les tâches où un feedback externe vérifiable existe (code, maths), les améliorations sont spectaculaires. Sur les tâches subjectives (rédaction, dialogue), les gains sont plus modestes et parfois contestés.
Limites fondamentales : quand la self-critique échoue
Le paradoxe de l’auto-évaluation
Un résultat contre-intuitif et crucial : les LLM sont significativement plus aptes à détecter et corriger les erreurs dans des textes écrits par d’autres que dans leurs propres sorties. Une étude (Tsui, juillet 2025) montre un taux de correction de 64,5 % en moyenne sur 14 modèles, mais avec un biais systématique vers la correction d’erreurs externes plutôt qu’internes. Les modèles entraînés par RL (avec des marqueurs de correction comme « Wait ») réduisent cet « angle mort » (self-correction blind spot).
L’auto-correction sans feedback externe est peu fiable
La survey critique de Kamoi et al. (2024, TACL) a analysé l’ensemble de la littérature sur la self-correction des LLM et conclut qu’il n’y a pas de consensus sur la capacité des LLM à corriger leurs propres erreurs sans aide externe. Beaucoup d’études rapportant des résultats positifs utilisent des évaluations imparfaites ou des cadres impratiques. Le message est clair : ne faites pas confiance à un LLM qui dit « ma réponse est correcte ».
Les conditions nécessaires pour une self-critique efficace :
| Condition | Exemple | Fiabilité |
|---|---|---|
| Feedback externe vérifiable | Exécuter le code, vérifier le résultat | Élevée |
| Critique par outil | Recherche web pour fact-checking | Bonne (dépend de la source) |
| Critique par un modèle différent | GPT-4 critique la sortie de Claude | Moyenne (réduit les biais d’auto-préférence) |
| Auto-critique pure (même modèle, pas de feedback) | « Relis ta réponse et corrige les erreurs » | Faible à nulle |
Le biais d’auto-préférence
Les LLM utilisés comme juges (pattern LLM-as-Judge) ont tendance à préférer leurs propres sorties à celles d’autres modèles. Ce biais d’auto-préférence (self-preference bias, Panickssery et al., 2024) signifie que la critique d’un modèle envers sa propre sortie est systématiquement biaisée positivement. Pour une évaluation fiable, utilisez un modèle différent comme critique, ou mieux, un outil externe.
Implémentation pratique
Le pattern simple : generate-critique-refine
import anthropic
client = anthropic.Anthropic()
def self_critique_loop(prompt, max_iterations=3):
# Génération initiale
response = client.messages.create(
model="claude-opus-4-6",
max_tokens=2048,
messages=[{"role": "user", "content": prompt}]
)
output = response.content[0].text
for i in range(max_iterations):
# Critique
critique = client.messages.create(
model="claude-opus-4-6",
max_tokens=1024,
messages=[{"role": "user",
"content": f"Évalue cette réponse de manière critique. "
f"Identifie les erreurs factuelles, les "
f"imprécisions, les lacunes et les améliorations "
f"possibles. Si la réponse est satisfaisante, "
f"réponds 'APPROVED'.nnRéponse :n{output}"}]
)
feedback = critique.content[0].text
if "APPROVED" in feedback:
break
# Raffinement
refined = client.messages.create(
model="claude-opus-4-6",
max_tokens=2048,
messages=[{"role": "user",
"content": f"Améliore cette réponse en tenant compte "
f"de la critique suivante :nn"
f"Critique : {feedback}nn"
f"Réponse originale : {output}"}]
)
output = refined.content[0].text
return outputLe pattern avec vérification par outil
Pour les tâches vérifiables (code, maths, faits), combinez la self-critique avec un outil de vérification externe :
def self_critique_with_tool(prompt, verifier):
output = llm.generate(prompt)
for i in range(max_iterations):
# Vérification externe (pas par le LLM)
result = verifier.check(output) # ex: exécuter le code, fact-check
if result.is_correct:
return output
# Critique informée par le feedback externe
output = llm.generate(
f"La vérification a échoué avec cette erreur :n"
f"{result.error}nn"
f"Corrige ta réponse :n{output}"
)
return output # ou signaler l'échecCe pattern est nettement plus fiable que la self-critique pure car le feedback est ancré dans la réalité. C’est exactement ce que font les agents de code quand ils exécutent les tests après chaque modification.
Self-critique dans les agents modernes
Les modèles de raisonnement modernes (série o d’OpenAI, Claude Opus 4.6 en mode thinking, DeepSeek-R1) intègrent la self-critique directement dans leur chaîne de pensée interne. Quand le modèle écrit « Wait, let me reconsider… » ou « Vérifions ce résultat… », il exécute une forme de self-critique en temps réel pendant le raisonnement séquentiel.
Cette intégration native est fondamentalement différente des approches par prompting (Self-Refine, Reflexion). Le modèle a été entraîné par renforcement à identifier et corriger ses erreurs pendant la génération, pas après coup. C’est ce qui explique les gains spectaculaires des modèles de raisonnement sur les benchmarks de maths et de code.
Les recherches récentes (Bohnet et al., décembre 2025) sur l' »Intrinsic Self-Critique » montrent qu’entraîner un modèle à critiquer ses propres réponses de planning améliore significativement ses capacités de planification, confirmant que la self-critique intégrée à l’entraînement est plus efficace que la self-critique par prompting seul.
Verdict
La self-critique est une technique puissante mais mal comprise. Le message le plus important : elle ne fonctionne de manière fiable que lorsqu’elle est ancrée dans un feedback externe vérifiable (exécution de code, vérification factuelle, tests automatisés). La self-critique « pure » (le modèle se relisant lui-même sans outil) est peu fiable et peut même dégrader les résultats.
Pour les développeurs : utilisez la self-critique comme une couche de raffinement, pas comme une garantie de qualité. Combinez-la systématiquement avec des vérifications externes. Et mesurez toujours l’impact : dans certains cas, une seule génération avec un meilleur prompt est plus efficace (et moins chère) que trois itérations de self-critique.
Le futur de la self-critique est dans son intégration native aux modèles de raisonnement. Les tokens « Wait » et « Let me reconsider » de DeepSeek-R1, la chaîne de pensée d’o3, l’adaptive thinking de Claude Opus 4.6 : ces modèles ont appris à se critiquer en temps réel pendant la génération. C’est plus efficace, plus naturel et plus fiable que le post-processing par prompting.
Questions fréquentes
Un LLM peut-il vraiment corriger ses propres erreurs ?
Avec des réserves importantes. Un LLM peut corriger des erreurs qu’il sait identifier : incohérences logiques, violations de format, problèmes de style. Mais il ne peut pas corriger des erreurs factuelles qu’il ne reconnaît pas comme telles (il ne sait pas ce qu’il ne sait pas). La survey de Kamoi et al. (2024) montre qu’il n’y a pas de consensus scientifique sur l’efficacité de l’auto-correction sans feedback externe. En pratique, combinez toujours la self-critique avec une vérification externe pour les tâches critiques.
Quelle est la différence entre Self-Refine et Reflexion ?
Self-Refine (Madaan et al., 2023) opère sur une seule réponse textuelle : le LLM génère, critique et raffine une sortie. Reflexion (Shinn et al., 2023) opère sur des trajectoires d’actions complètes d’un agent : l’agent agit, échoue, réfléchit sur l’ensemble de ses actions, et retente avec cette réflexion en mémoire. Self-Refine est pour le raffinement de texte. Reflexion est pour l’apprentissage par essai-erreur des agents.
La self-critique augmente-t-elle toujours la qualité ?
Non. Sans feedback externe, la self-critique peut dégrader les résultats (RealCritic, Tang et al., 2025). Le modèle peut « corriger » des réponses correctes en réponses incorrectes, ou tourner en boucle sans amélioration. Les gains sont systématiques uniquement quand un feedback externe vérifiable est disponible (code exécutable, tests, sources factuelles).
Combien d’itérations de self-critique faut-il ?
Les études montrent que la majorité des gains se produisent dans les 2-3 premières itérations. Au-delà, les améliorations sont marginales et le coût continue d’augmenter linéairement. Fixez un maximum de 3 itérations pour les tâches générales, et ajustez selon le rapport coût/bénéfice de votre cas d’usage. Pour le code, le nombre d’itérations peut être plus élevé car chaque itération est vérifiable par exécution.
Comment intégrer la self-critique dans un pipeline de production ?
Trois approches par ordre de fiabilité croissante : (1) self-critique par prompting (le plus simple, le moins fiable), (2) critique par un second modèle différent (réduit le biais d’auto-préférence), (3) critique assistée par outils (le plus fiable). En production, la troisième approche est recommandée pour toute tâche critique. Pour les tâches non critiques (rédaction marketing, résumé), la première approche peut suffire avec un monitoring de la qualité des sorties.