Pattern Self-Critique Agent : brouillon → critique → révision

Essence Du Pattern

Self-Critique Agent est un pattern où l’agent écrit d’abord un brouillon, puis consigne les risques et les changements obligatoires selon un format fixe, applique une révision contrôlée, et enregistre exactement ce qui a changé.

Quand l’utiliser : quand vous avez besoin d’une revue des risques stricte et structurée, avec révision contrôlée et trace d’audit.

Par rapport à une reflection légère, self-critique est généralement plus strict :

• la critique a un format fixe (par exemple JSON)
• les modifications sont autorisées uniquement par règles
• la croissance de longueur est contrôlée
• le système garde un journal des changements (avant → après)

Problème

Imaginons qu’un agent prépare une mise à jour client sur un incident.

Brouillon :

"Le release est retardé à cause d’une panne du module de paiement."

Puis une demande arrive :

"Adoucis la formulation."

Sans cadre self-critique, l’agent fait souvent une "jolie réécriture" qui dépasse la tâche :

• ajoute de nouvelles hypothèses
• rend le ton moins précis
• allonge le texte hors du périmètre nécessaire
• masque le problème au lieu de le clarifier

"Améliorer la formulation" ne doit pas devenir "changer le sens".

Résultat :

• le sens dérive sans que ce soit visible
• on ne sait pas clairement ce qui a été corrigé
• l’audit ne peut pas reconstruire la logique des modifications
• la réponse devient moins fiable pour décider

C’est le problème central : pendant "l’amélioration", l’agent peut changer le contenu alors qu’il devait seulement changer la forme.

Solution

Self-Critique impose une règle : ne modifier que ce qui est listé dans "required changes".

Analogie : comme une révision éditoriale à partir d’une liste de remarques. On fige d’abord ce qu’il faut corriger, puis on applique une seule révision contrôlée. La réponse devient plus claire sans changer le sens.

Principe clé : critique structurée d’abord, puis une seule révision contrôlée avec trace d’audit.

L’agent peut proposer des réécritures, mais le système n’autorise que des modifications ciblées explicitement présentes dans "required changes".

Flow contrôlé :

1. Brouillon : générer la première version
2. Critique : produire un artefact (risks + required_changes)
3. Décision : ok/réviser/escalader
4. Révision : faire une seule révision contrainte
5. Audit : enregistrer diff + metadata

Cela apporte :

• plus de clarté sans modifier les faits
• séparation nette entre "ce qui ne va pas" et "ce qui a été corrigé"
• révisions reproductibles
• contrôle des sorties high-risk avant publication

Fonctionne bien si :

• critique suit une structure fixe (schema-driven)
• revision est limitée à required_changes
• no_new_facts est appliqué
• audit diff est obligatoire

Comment Ça Fonctionne

Pour que ce pattern reste sûr, il faut des limites claires :

• une passe de critique
• une passe de révision
• ne pas ajouter de nouveaux faits
• modifier uniquement les points de required changes
• ne pas gonfler le texte (par exemple, +20% max)
• en cas de risque élevé : stop ou revue humaine

En Code, Ça Donne Ça

draft = writer.generate(goal, context)

critique = critic.review_once(
    draft=draft,
    schema="risks_required_changes_v1",
)

if critique.high_risk:
    return escalate_to_human(critique.reason)

if critique.ok:
    return draft

revised = writer.revise_once(
    draft=draft,
    required_changes=critique.required_changes,
    rules=[
        "no_new_facts",
        "max_length_increase_pct=20",
        "keep_scope",
    ],
)

approved = supervisor.review_output_patch(
    original=draft,
    revised=revised,
    allowed_changes=critique.required_changes,
)

audit.log_diff(
    before=draft,
    after=approved,
    risks=critique.risks,
)

return approved

Self-Critique ne doit pas tourner "jusqu’à parfait". Une critique + une révision (revise), puis vérification que la revision est restée dans required_changes.

À L’exécution, Ça Ressemble À Ça

Goal: proposer un plan d’action sûr pendant un incident réseau

Draft:
"Le problème vient du réseau. Il faut redémarrer tout le cluster."

Critique:
- risk: affirmation de cause sans preuve
- risk: action avec blast radius trop large (changements d'état)
- required_change: ajouter des vérifications avant restart

Revision:
"Une cause probable est une panne réseau.
Avant de redémarrer le cluster, vérifier l’état des nœuds et la latence.
Si une panne partielle est confirmée, redémarrer seulement les nœuds affectés."

Quand Ça Convient - Et Quand Non

Adapté

Non Adapté

Parce que self-critique ajoute un second passage de génération et augmente le coût d’exécution.

Différence Avec Reflection

Reflection sert plus souvent de filtre léger avant envoi. Self-Critique sert quand il faut un contrôle plus strict des changements.

Quand Utiliser Self-Critique (vs Autres Patterns)

Utilisez Self-Critique quand vous avez besoin d’une critique approfondie selon des critères explicites et d’une réécriture contrôlée.

Test rapide :

• si vous devez "évaluer selon une checklist et réécrire la réponse" -> Self-Critique
• si vous devez "faire juste un court contrôle avant envoi" -> Reflection Agent

Combinaison Avec D’autres Patterns

• Self-Critique + RAG : critique et révisions autorisées uniquement dans les faits du contexte de retrieval.
• Self-Critique + Supervisor : les modifications risquées ne sont pas appliquées automatiquement et partent en validation humaine.
• Self-Critique + Reflection : Reflection fait un pre-check rapide, puis Self-Critique s’active pour les réponses complexes ou discutables.

En Bref

Avantages Et Inconvénients

FAQ

Q: Peut-on faire plusieurs passes de critique ?
A: Techniquement oui, mais cela devient vite une boucle coûteuse. Standard sûr de base : 1 + 1.

Q: Pourquoi le logging des changements est obligatoire ?
A: Sans diff, il est difficile de comprendre ce qui a modifié la qualité et où l’erreur est apparue.

Q: Faut-il un modèle critique séparé ?
A: Parfois oui, mais ce n’est pas obligatoire. Le plus important : schéma strict, validation de sortie, et règles de révision strictes.

Et Ensuite

Self-Critique améliore la qualité grâce à une réécriture contrôlée.

Mais que faire quand la réponse doit non seulement être réécrite, mais aussi validée par policy avant une action risquée ?