AutoReason — refinement adversarial pour domaines subjectifs (NousResearch)¶

Resume¶

SHL0MS et NousResearch publient AutoReason (330 stars, 1.3K likes, 289K vues), une methode de raisonnement iteratif inspiree d'AutoResearch de Karpathy mais etendue aux domaines subjectifs — ceux ou il n'y a pas de test automatise ni de metrique numerique pour juger le resultat (strategie, positionnement, copy, politique, incident response).

Le paper a ete co-ecrit avec Hermes Agent de NousResearch en utilisant un skill de redaction de paper developpe pendant la redaction elle-meme (meta-recursivite assumee).

La methode resout trois problemes structurels de l'auto-refinement iteratif : prompt bias (le LLM hallucine des defauts quand on lui demande de critiquer), scope creep (chaque passe elargit le perimetre sans controle), et incapacite a dire "rien a changer" (le modele modifie toujours, meme quand il ne devrait pas).

Analyse critique¶

Le mecanisme — simple et elegant¶

A chaque iteration, AutoReason produit trois versions concurrentes :

• A : la version incumbente (inchangee)
• B : une revision adversariale (par un agent frais, sans contexte de A)
• AB : une synthese des deux (par un agent frais)

Un panel de 3+ juges aveugles (sans contexte partage) vote en Borda count. Le gagnant devient le nouvel A. "Ne rien changer" (garder A) est toujours une option valide — c'est la cle qui empeche le scope creep.

La convergence arrive quand A gagne systematiquement — l'output est stable, pas quand le modele "n'a plus rien a dire".

Les resultats — solides et surprenants¶

Le chiffre le plus frappant : Haiku 3.5 (modele ~10× moins cher que Sonnet 4) avec AutoReason obtient un Borda parfait 42/42 sur 3 taches. Chaque juge a prefere AutoReason a chaque fois. Les baselines standard (critique-and-revise, self-refine) degradent le meme modele en dessous de son single-pass non-raffine.

C'est le resultat central du paper : l'auto-refinement classique (critiquer puis corriger) rend les outputs pires, pas meilleurs. Le modele hallucine des defauts, supprime du contenu valide, et elargit le scope. Apres 15 rounds de "harsh critic", un pitch passe de 345 a 102 mots (-70%) — le modele detruisait son propre travail.

AutoReason evite ca parce que le panel de juges bloque les regressions : si la revision B est pire que A, A survit.

Autres resultats : - Sonnet 4.6 sur 5 taches d'ecriture : AutoReason moyenne Borda 27.8 (rank 1.4), jamais en dessous de 2^nd - Sur 150 problemes de programmation competitive : taux de recovery 62% vs 43% pour single-pass (p=0.041) - Haiku + AutoReason egalise Sonnet single-pass — un modele 10× moins cher matche le frontier avec la structure seule

Le sweet spot : AutoReason fonctionne le mieux sur les modeles mid-tier (Haiku 3.5, Gemini Flash). Les modeles trop faibles (Llama 8B) n'ont rien a arbitrer entre les versions. Les modeles trop forts (Sonnet 4.6 sur taches non-contraintes) ont deja une self-evaluation suffisante.

L'observation anti-intuitive sur le scope¶

Sur une tache non-contrainte, AutoReason finit dernier (Borda 7). Sur une tache contrainte a 500 mots, AutoReason finit premier (Borda 30) pendant que critique-and-revise explose a 932 mots. La methode brille quand il y a des contraintes a respecter — exactement le cas de nos gates avec seuils mathematiques.

Ce que le paper ne dit pas¶

• Cout : pas chiffre explicitement. Chaque iteration = 3 generations (A reste, B + AB generees) + 3+ jugements. Sur 26 passes, ca fait ~130 appels LLM par tache. A $0.003/call avec Haiku c'est ~$0.40 par tache. Avec Sonnet c'est ~$4. Pas negligeable sur un workflow de 10+ stories.
• Latence : 26 passes sequentielles = potentiellement plusieurs minutes par tache. Pas un probleme pour du batch (REX, strategy), bloquant pour du real-time.
• Reproductibilite : les Monte Carlo runs montrent "different paths but consistent final quality" — le resultat converge mais le chemin varie. Pour un workflow auditable (Art. III), c'est un point a surveiller.

Pertinence ProbatioVault¶

Impact modere — directement applicable a notre item [G13] AutoReason dans le TODO, et plus largement a la question "comment ameliorer les outputs subjectifs de nos gates".

Le mapping avec notre workflow¶

Notre workflow a deux types de taches :

1. Taches avec metrique : les gates ⅗/8 avec scoring deterministe (completeness, testability, clarity, traceability). Ici, AutoResearch de Karpathy s'applique directement (on optimise un score).

2. Taches sans metrique : la redaction du besoin (step 0), la redaction du plan (step 4), le REX (step 9). Pas de score numerique — juste "est-ce que c'est un bon besoin ?". C'est exactement le domaine d'AutoReason.

Le pattern A/B/AB + panel de juges Borda est quasi-identique a notre architecture de gates :

La difference principale : chez nous, les phases sont sequentielles (review → confrontation → dossier → verdict), pas concurrentes. Et le verdict est deterministe (scoring mathematique), pas Borda. Mais la philosophie "ne rien changer est une option valide" est exactement notre regle de convergence delta < 0.5 ET mean < 7 → ESCALADE : si l'iteration n'ameliore rien, on arrete.

Ce qu'on pourrait faire¶

Court terme : rien. Notre workflow fonctionne deja sur un pattern similaire. AutoReason confirme qu'on est dans la bonne direction (separation auteur/critique/juge, "ne rien changer" comme option valide, convergence par stabilite).

Moyen terme : tester AutoReason sur les taches redactionnelles du workflow (besoin step 0, plan step 4, REX step 9) ou il n'y a pas de scoring deterministe. Au lieu de "Claude redige → humain valide", on pourrait faire "Claude redige A → Claude adversarial B → Claude synthese AB → panel juge → meilleur gagne". Ca ajouterait une boucle d'auto-amelioration avant la validation humaine. Aligne avec [G13] dans la matrice TODO.

Le chiffre a retenir pour la decision : Haiku + AutoReason egalise Sonnet single-pass. Si on peut utiliser Haiku (10× moins cher) avec AutoReason sur step 0/4/9 et obtenir la meme qualite que Opus single-pass, le ROI est enorme. A mesurer.

Action recommandee¶

Lire le paper (GitHub NousResearch/autoreason). Tester sur une tache redactionnelle concrete (ex : redaction d'un besoin step 0 sur une story simple). Comparer qualite du besoin AutoReason-Haiku vs single-pass-Opus. Si la qualite est comparable, integrer comme option dans le workflow step 0/4/9. Cible : item [G13] du TODO.