Essence Du Pattern
Reflection Agent est un pattern où, après un brouillon de réponse, l'agent fait une vérification qualité rapide : il repère les problèmes évidents (formulations floues, contradictions, affirmations trop sûres) et les corrige une fois avant la réponse finale.
Important : Reflection est une vérification légère avant envoi. Ce n'est pas une validation complète par règles ou policies.
Quand l'utiliser : quand il faut une auto-vérification courte et contrôlée avant envoi, avec une seule révision.
Reflection ne remplace pas le workflow principal de l'agent.
Il ajoute une courte étape de contrôle :
- vérifier rapidement si la réponse est claire, cohérente et sans oubli important
- trouver les risques évidents
- corriger uniquement ce qui est nécessaire
- terminer sans créer un nouveau cycle infini
Problème
Imagine qu'un agent prépare une réponse client pour une demande à haut risque.
Le brouillon est globalement correct, mais contient de petits risques :
- formulation trop catégorique sans base
- contradiction entre paragraphes
- avertissement manquant
- limite d'applicabilité peu claire
Sans passe de contrôle, ce brouillon part directement vers l'utilisateur.
Les erreurs les plus dangereuses sont souvent non grossières, mais "presque invisibles" dans un texte qui semble normal.
Conséquences :
- la confiance dans la réponse baisse
- une fausse certitude apparaît
- le risque de mauvaises décisions augmente
C'est le problème central : même un bon brouillon peut sortir avec des imprécisions critiques sans vérification.
Solution
Reflection ajoute une reflection-policy avant l'envoi final.
Analogie : comme un tailleur avant de livrer un costume. Il vérifie d'abord l'ajustement, puis fait une correction précise. Le résultat est meilleur, sans transformer le processus en essayages infinis.
Principe clé : une vérification qualité courte et une correction, sans "améliore encore" en boucle.
L'agent peut proposer des changements, mais la policy définit :
- si une révision est nécessaire
- ce qui est exactement autorisé à changer
- quand appliquer
stop/escalate
Processus contrôlé :
- Brouillon : générer la première version
- Revue : exécuter une vérification structurée
- Décision :
ok/réviser/escalader - Révision : faire une correction
patch-onlyselonfix_plan - Finalisation : retourner la version finale sans nouveau cycle
Cela apporte :
- suppression des risques évidents avant envoi
- amélioration notable de qualité avec peu d'overhead
- contrôle de la révision dans
fix_plan - protection contre le self-edit infini
Fonctionne bien si :
no_new_factsest appliqué- les modifications sont uniquement
patch-only - les cas high-risk sont escaladés au lieu d'être réécrits sans fin
Le modèle peut "vouloir" éditer encore et encore, mais c'est la reflection-policy qui clôt le processus dans des limites prévisibles.
Comment Ça Fonctionne
Règle clé : reflection doit être borné.
Cela signifie :
- max 1 passe de revue
- max 1 passe de révision
- ne pas ajouter de nouveaux faits
- la révision doit être
patch-onlyet uniquement dansfix_plan - escalader en cas de problème high-risk
Flow complet : Draft → Review → Revise → Finalize
Brouillon
L'agent crée la réponse initiale à partir du contexte disponible.
Revue
Un prompt séparé vérifie le brouillon avec des points simples : clarté, logique, cohérence interne, et affirmations trop fortes.
Révision
Si des problèmes sont trouvés, l'agent fait une seule révision selon un fix_plan structuré.
Finalisation
Le système renvoie le résultat ou stoppe si le risque est trop élevé.
En Code, Ça Donne Ça
draft = writer.generate(goal, context)
review = reflector.review_once(
draft=draft,
rubric=[
"no_new_facts",
"preserve_uncertainty",
"consistency_check",
],
)
if review.high_risk:
return escalate_to_human(review.reason)
if review.ok:
return draft
revised = writer.revise_once(
draft=draft,
fix_plan=review.fix_plan,
rules=["no_new_facts", "keep_scope"],
)
# optionnel : vérifier que la révision reste dans `fix_plan`
approved = supervisor.review_output_patch(
original=draft,
revised=revised,
allowed_changes=review.fix_plan,
)
return approved
Reflection ne doit pas tourner "jusqu'à parfait". Une passe de revue, une amélioration via revise, puis une vérification que la révision reste dans fix_plan.
À L'exécution, Ça Ressemble À Ça
Goal: préparer une réponse précise avec formulation SLA correcte
Draft:
"Le SLA pour tous les clients est de 99.99%."
Review:
- problème : affirmation trop catégorique
- problème : niveau de plan non précisé
- fix : ajouter condition et source
Revised:
"Le SLA dépend du niveau de plan. Pour enterprise, il est de 99.99% selon la policy support."
Exemple complet d'agent Reflection
Quand Ça Convient - Et Quand Non
Adapté
| Situation | Pourquoi Reflection Convient | |
|---|---|---|
| ✅ | La réponse part vers l'extérieur et nécessite une vérification supplémentaire | Reflection attrape les problèmes évidents avant envoi à l'utilisateur. |
| ✅ | Besoin d'améliorer la qualité sans grosse pénalité de latence | Une passe bornée donne souvent une amélioration de qualité visible. |
| ✅ | Rubric qualité et stop rules claires | Des critères formalisés rendent l'auto-review stable et prévisible. |
| ✅ | Besoin d'une réponse finale plus fiable sans boucle de réécriture | Reflection ajoute un contrôle sans lancer des réécritures infinies. |
Non Adapté
| Situation | Pourquoi Reflection Ne Convient Pas | |
|---|---|---|
| ❌ | Latence critique | Même une passe en plus peut rendre la réponse trop tardive. |
| ❌ | Pas de rubric qualité claire | Sans critères, reflection devient chaotique et n'améliore pas de façon stable. |
| ❌ | Validation externe des faits via tools ou humains nécessaire | Reflection ne remplace pas le fact-checking externe ou la revue manuelle. |
Parce que reflection ajoute une passe de génération supplémentaire et augmente le temps et le coût de réponse.
Différence Avec Self-Critique
| Reflection | Self-Critique | |
|---|---|---|
| Objectif | Repérer les problèmes évidents avant envoi | Vérifier la réponse avec des règles plus strictes et la réécrire si besoin |
| Profondeur | Contrôle qualité rapide : clarté, logique, absence d'erreurs évidentes | Souvent critique et révision plus strictes |
| Type de résultat | ok/problèmes/plan de correction | risques détaillés + changements obligatoires + orientation diff |
| Risque | Devenir un deuxième cycle sans limites | Réécriture excessive et coût en hausse |
Reflection est un contrôle rapide borné. Self-Critique est une passe plus profonde avec réécriture.
Quand Utiliser Reflection Parmi Les Autres Patterns
Utilisez Reflection quand il faut vérifier rapidement la réponse avant envoi : claire, logique, et sans erreurs évidentes.
Test rapide :
- si vous devez "faire une vérification courte et corriger avant final" -> Reflection
- si vous devez "critiquer en profondeur par checklist et réécrire" -> Self-Critique Agent
Comparaison avec d'autres patterns et exemples
Aide-mémoire rapide :
| Si la tâche ressemble à cela... | Utilisez |
|---|---|
| Une vérification courte est nécessaire avant la réponse finale | Reflection Agent |
| Une critique profonde par critères et réécriture sont nécessaires | Self-Critique Agent |
| Il faut récupérer le process après timeout, exception ou panne d'outil | Fallback-Recovery Agent |
| Des checks policy stricts sont nécessaires avant une action risquée | Guarded-Policy Agent |
Exemples :
Reflection : "Avant la réponse finale, vérifier rapidement logique, complétude et erreurs évidentes".
Self-Critique : "Évaluer la réponse par checklist (précision, complétude, risques), puis réécrire".
Fallback-Recovery : "Si API ne répond pas, faire retry -> source fallback -> escalation".
Guarded-Policy : "Avant envoi de données vers l'extérieur, vérifier policy : si c'est autorisé".
Comment Combiner Avec D'autres Patterns
- Reflection + RAG : Reflection vérifie que les conclusions correspondent bien aux sources retrouvées.
- Reflection + Supervisor : les conclusions high-risk ne sont pas corrigées automatiquement, elles passent en approbation humaine.
- Reflection + ReAct : après une série d'étapes ReAct, l'agent effectue une vérification finale avant réponse.
En Bref
Reflection Agent:
- Effectue une auto-vérification de contrôle
- Corrige la réponse une seule fois
- N'ajoute pas de nouveaux faits
- Réduit le risque d'erreurs évidentes en production
Avantages Et Inconvénients
Avantages
vérifie la réponse avant envoi
corrige les erreurs évidentes
améliore clarté et structure
aide à maintenir le format requis
Inconvénients
ajoute une étape et de la latence
consomme plus de tokens
sans limites peut compliquer inutilement la réponse
FAQ
Q: Reflection peut-il remplacer fact-checking et tests ?
A: Non. C'est une couche qualité supplémentaire. Fact-checking, validation et contrôles policy restent nécessaires séparément.
Q: Pourquoi limiter le nombre de passes ?
A: Sinon reflection devient un second cycle : latence, coût et risque de nouvelles erreurs augmentent.
Q: Que faire si reflection trouve un problème high-risk ?
A: Ne pas continuer automatiquement. Stopper le process ou escalader vers revue humaine / policy Supervisor.
Et Ensuite
Reflection ajoute un contrôle qualité borné avant la réponse finale.
Que faire quand il faut une critique plus stricte et un process de révision avec règles structurées de changement ?