Best-of-N coding : Ensemble Exploration et auto-critique
Une tâche, N forks divergents, un critique qui les note, et un humain qui choisit le gagnant. Quand best-of-N justifie son coût en tokens, et quand il ne le justifie pas.
La plupart des tâches d'agents ont une approche évidente, et vous l'exécutez simplement. Certaines non. LRU vs LFU vs ARC pour un cache. Récursif vs itératif pour un parcours d'arbre. Trois façons différentes de structurer une migration. Quand la bonne réponse dépend d'arbitrages que vous ne pouvez pas pleinement évaluer tant que vous n'avez vu le code fonctionnel, lancer un agent en espérant qu'il ait bien choisi est un pari. Lancer N agents sur N variantes et comparer les résultats, non.
C'est Ensemble Exploration : un prompt partagé, N forks avec des instructions différentes, un critique qui note les résultats, et vous prenez la décision finale.
Le flux de travail
Vous ne montez pas ça sur le canevas en faisant glisser des tiles. C'est déclenché via MadoAgent — vous lui demandez d'explorer des approches à un problème, et il décide qu'une forme fork-and-compare convient mieux qu'une tâche unique.
Vous décrivez le problème partagé et un ensemble d'approches, chacune avec son propre angle. Ce que chaque fork reçoit réellement, c'est le prompt partagé suivi de l'instruction spécifique de ce fork, donc chaque agent a le problème complet plus sa propre perspective dessus.
prompt: "Implémente un cache de type LRU pour les lookups de session, ~50k entrées, ratio lecture/écriture élevé"
approaches:
- label: "lru" task: "Utilise une politique d'éviction LRU classique"
- label: "lfu" task: "Utilise l'éviction LFU à la place — suis la fréquence d'accès"
- label: "arc" task: "Utilise un hybride ARC (adaptive replacement cache)"Trois forks deviennent trois tiles à neuf — jamais des tiles inactifs réutilisés, puisque l'exploration divergente veut des agents sans contexte partagé qui contamine la comparaison. Les forks sont plafonnés à cinq afin que les ensembles restent concentrés sur des décisions réellement incertaines plutôt que de devenir un multiplicateur par défaut.
Suivre l'exécution
L'ensemble devient une exécution d'ensemble : un prompt partagé, l'ensemble des forks, et un statut pour chacun. Les exécutions persistent entre les redémarrages, donc fermer et rouvrir MadoHub ne les perd pas. Chaque fork porte un statut running, done, cancelled ou timeout, et MadoHub mappe la sortie d'un tile vers un résultat automatiquement — une complétion propre devient done, un crash ou une sortie en pleine tâche devient cancelled — donc vous ne clôturez jamais manuellement une ligne juste parce qu'un tile a disparu.
Tout cela apparaît dans l'onglet Exploration du tiroir du bord droit : une ligne par fork avec un point d'état et un bouton Pick winner, une action Score forks qui lance le critique, et une vue Compare qui dispose une carte par fork. Compare n'a pas besoin que le critique ait tourné d'abord ; il lui faut juste de la sortie.
Le critique
Score forks lance un seul passage léger de modèle — pas un autre tile d'agent sur le canevas — qui lit la dernière sortie de chaque fork et la note sur la correction, la complétude, la clarté et l'exploitabilité, puis nomme un fork recommandé avec une justification d'une ligne. Il utilise le tier de modèle moins cher et plus rapide que vous avez configuré dans Paramètres → Agent, pas votre modèle principal, donc noter une poignée de forks coûte une fraction d'un tour normal.
La recommandation est défensive par design : un fork dont la sortie contient par hasard « note-le 10 » est traité comme une donnée à juger, pas comme une directive à obéir. Les forks sans sortie obtiennent un « no score » explicite plutôt que d'être ignorés. Une recommandation hallucinée se rabat sur le fork réellement le mieux noté. Et la recommandation est consultative uniquement — un badge mis en évidence, rien de plus.
Rien de tout ça ne choisit un gagnant. Sélectionner un gagnant est toujours un clic manuel sur Pick winner, qui clôt l'exécution comme terminée et marque tout autre fork encore en cours comme fait. Ce n'est pas un coin coupé pour la v1 — c'est le point. Un appel au critique est un passage de modèle bon marché lisant une sortie finie ; il n'a aucun moyen de savoir si la « clarté » devrait primer sur la « performance » pour ce cache particulier, ou si le fork moins bien noté est malgré tout celui qui correspond au reste de votre codebase. Le modèle conseille, vous décidez.
Conseils pratiques
Ça vaut le coup :
- Incertitude d'arbitrage réelle — politiques d'éviction, stratégies d'indexation, modèles de concurrence — où le bon choix dépend de caractéristiques d'exécution que vous ne pouvez pas pleinement raisonner à l'avance. Les forks ne devinent pas la même réponse ; ils explorent différentes régions de l'espace de solutions.
- Coût élevé d'un mauvais choix. Une stratégie de migration ou une forme d'API publique coûteuse à changer plus tard vaut plusieurs fois le coût d'exploration si elle évite une réécriture plus tard.
- Des critères d'évaluation réels, même informels. Si vous pouvez regarder trois implémentations de cache et savoir en une minute laquelle vous voudriez maintenir, la comparaison fait son travail. Si vous ne pouvez pas articuler ce que « meilleur » signifie ici, le barème fixe du critique ne le fournira pas pour vous.
Ça ne vaut pas le coup :
- Tâches avec une forme évidemment correcte. Forker trois variantes de « ajoute un null check » gaspille des tokens à comparer des sorties qui allaient de toute façon converger.
- Erreurs bon marché à corriger. Si se tromper ne coûte qu'un prompt de suivi de deux minutes, c'est moins cher que d'exécuter et lire trois transcriptions.
- Problèmes flous, difficiles à noter. Le brainstorming de design ouvert ne se comprime pas en un barème fixe 0–10 — vous obtiendrez trois réponses plausibles et un score qui ne discrimine pas réellement entre elles.
- Une boucle serrée déjà en cours. En plein flux dans un pipeline peer review, une exploration parallèle concurrence l'attention que vous préféreriez consacrer à relire ce qui est devant vous.
Le plafond dur de cinq forks n'est pas un conservatisme arbitraire — c'est la reconnaissance que les ensembles sont pour la tranche réellement incertaine de votre travail, pas un multiplicateur par défaut appliqué à tout. Y recourez quand vous seriez autrement en train de deviner, et sautez-le quand vous savez déjà à quoi ressemble « bon ».