Module 6 — Autocritique et vérification des résultats
Un agent qui répond « voici la note demandée » finit rarement bon du premier coup. Sources incomplètes, contradiction interne, chiffre transposé : les défauts abondent, et le modèle ne les voit pas parce qu'il vient de les produire. Ce module ajoute une étape de vérification, mais surtout il pose la question qui compte : à quelles conditions cette vérification améliore-t-elle réellement le résultat ?
Trois formes d'autocritique
La réflexion en une passe demande au même modèle, dans le même appel, de relire sa réponse et de la corriger. C'est l'option la moins chère, la moins efficace : le modèle est en général d'accord avec lui-même. Elle attrape les erreurs grossières — sortie tronquée, oubli d'une source demandée — mais rate les erreurs de raisonnement.
La vérification par un second modèle est un appel distinct, avec une consigne dédiée : « voici la note et les faits recueillis, indique toute contradiction, tout fait sans source, tout écart au plan ». Comme le vérificateur n'a pas produit la réponse, il est plus libre de la contester. C'est le mode qui apporte le plus, en particulier quand le vérificateur est un modèle différent — un modèle plus petit fait souvent une lecture plus littérale qui repère les incohérences.
La vérification par outil est la plus solide. Plutôt que de demander au modèle « es-tu sûr ? », on lui donne un outil qui vérifie objectivement : recalculer une somme, réinterroger la source citée, comparer une date à celle de l'article. C'est l'équivalent des tests unitaires en logiciel — inflexible mais fiable.
Réflexion en pratique
def raffiner(reponse, question, faits):
critique = client.chat.completions.create(
model="gpt-4o-mini",
messages=[
{"role": "system", "content": (
"Tu relis la note d'un agent de veille. Signale, "
"en liste courte : les faits sans source, les contradictions "
"internes, les elements de la question restes sans reponse. "
"Ne reformule pas la note."
)},
{"role": "user", "content": (
f"Question :\n{question}\n\nFaits :\n{faits}\n\n"
f"Note :\n{reponse}"
)},
],
temperature=0,
).choices[0].message.content
if "aucun probleme" in critique.lower():
return reponse
return reecrire(reponse, critique, faits)
Deux choix comptent. Le vérificateur est un modèle plus petit (gpt-4o-mini), à la fois pour le coût et parce qu'il produit des critiques moins verbeuses. Et il est temperature zero, parce qu'il ne doit rien inventer.
Vérification par outil sur le fil rouge
Sur l'agent de veille, deux vérifications automatiques valent leur pesant.
Chaque phrase de la note doit avoir une source. Un petit code parcourt la note à la recherche d'affirmations non attribuées ; s'il en trouve, il rejette la sortie et demande à l'agent de compléter. Ce test est absurdement simple et attrape 30 % des défauts observés sur le fil rouge.
Chaque URL citée doit avoir été effectivement lue. L'agent est parfois tenté d'inventer une URL plausible à partir de son entraînement. En rapprochant la note du journal des appels à lire_url, on repère ces hallucinations d'URL et on refuse la sortie. Le coût est nul : c'est du code, pas un appel modèle.
Limites de l'autocritique
L'autocritique par le même modèle a une limite documentée par la recherche : elle améliore beaucoup les erreurs faciles à vérifier et pratiquement rien les erreurs difficiles. Une contradiction évidente sera corrigée ; une erreur de raisonnement complexe passera parce que le modèle qui a produit l'erreur produit la même erreur en la relisant. C'est ce qu'on appelle l'autocorrection illusoire — une amélioration visible sur des cas triviaux qui masque l'échec sur les cas critiques.
Un signal net : sur les tâches où l'autocritique améliore le score du modèle qui l'a écrite, elle amène rarement au-delà de +5 points. Ce qui apporte +15 à +25 points, c'est la vérification externe — un second modèle, ou mieux, un outil de vérification objectif.
Le risque de sur-correction
Une critique trop pointilleuse peut détériorer une bonne réponse. Le modèle qui reçoit une liste de reproches réécrit alors la note en dégradant ce qui était juste, en ajoutant des nuances non demandées, en gonflant la longueur. Le protocole robuste :
- La critique doit renvoyer une liste bornée — au plus cinq points, avec pour chacun l'endroit précis à modifier.
- La réécriture s'applique localement — chaque point signale une phrase, seule cette phrase est révisée.
- Une seule passe de critique est autorisée ; itérer amène le modèle à réécrire indéfiniment.
Vérification versus consensus
Une variante utile : plutôt que de faire critiquer par un second modèle, on lance le même agent trois fois avec des semences différentes puis on compare les sorties. Si les trois s'accordent sur les faits, c'est un consensus qui protège des hallucinations ; si elles divergent, on demande à un modèle de consolider en signalant les divergences.
C'est plus cher qu'une critique — trois exécutions au lieu d'une — mais c'est le mode qui a le mieux fonctionné sur les questions techniques du fil rouge, où une erreur d'un modèle est difficile à détecter par relecture. Sur les évaluations du module 10, le consensus à trois passe de 78 % à 88 % de bonnes réponses, au prix d'un coût multiplié par 3,1.
En résumé
- Réflexion, vérificateur, outil : trois modes, du moins cher au plus solide ; la vérification par outil est la seule qui garantisse quelque chose.
- L'autocritique par le même modèle plafonne à +5 points ; l'autocorrection illusoire dissimule les vrais problèmes derrière des corrections cosmétiques.
- La critique doit être bornée et la réécriture locale pour éviter la dégradation par sur-correction.
- Le consensus à trois passes dépasse la critique pour un coût triplé, quand la vérification objective n'est pas possible.
Module suivant : les garde-fous — budget de jetons, permissions par outil, points d'arrêt humains — pour qu'un agent autonome reste contrôlable.