LLM Council de Karpathy : faire débattre quatre modèles, et ce qui en sort

L’instinct quand on a une question difficile et qu’on hésite entre Claude, GPT et Gemini, c’est d’en poser la même question aux trois et de comparer mentalement les réponses. Karpathy a transformé ce réflexe en un protocole de cent-cinquante lignes : son LLM Council interroge quatre modèles en parallèle, leur fait anonymement relire et noter les réponses des autres, puis désigne un chairman qui synthétise un seul rendu final. Le projet, qu’il décrit lui-même comme “99 % vibe coded as a fun Saturday hack”, n’est pas un produit. C’est une démonstration tournée vers une chose précise : ce que ça change quand on remplace l’opinion unique d’un modèle par la délibération de plusieurs.

Le protocole mérite d’être lu pour ce qu’il révèle, pas pour l’imiter à l’identique.

Trois étapes, et pourquoi chacune compte

L’architecture, telle qu’elle est posée dans le repo, tient en trois passes.

Premières opinions. La requête de l’utilisateur part en parallèle à tous les modèles du conseil, par défaut GPT-5.1, Gemini 3 Pro Preview, Claude Sonnet 4.5, et Grok-4. Chaque modèle répond indépendamment, sans voir ce que les autres disent. Les quatre réponses sont affichées en onglets pour qu’on puisse les inspecter brutes.

Revue anonyme. Chaque modèle reçoit les réponses des autres, mais sans étiquette d’identité. Réponse A, B, C, D, sans dire qui est qui. La consigne : classer ces réponses par justesse et profondeur. L’anonymisation est le détail qui sauve le protocole d’un biais évident : sans elle, un modèle est statistiquement plus généreux avec lui-même ou avec la maison qu’il connaît. Avec elle, il est forcé de juger le contenu, pas l’auteur.

Synthèse par le chairman. Un modèle désigné (Gemini 3 Pro par défaut) reçoit l’ensemble, les quatre réponses initiales et les évaluations croisées, et compile une réponse finale. Ce n’est pas une moyenne ; c’est une réécriture qui hiérarchise ce qui ressort comme solide à travers les votes et ce qui n’apparaît que dans une seule voix.

Le tout tourne en local (FastAPI côté back, React côté front, OpenRouter pour la fédération des modèles, JSON pour la persistance), sur un poste avec un peu de crédit OpenRouter. La conception est délibérément frugale.

Ce que le protocole révèle

Au-delà du gadget, la mécanique met en lumière deux choses qu’un seul modèle, même très bon, ne fait pas naturellement.

Diversité des angles. Quatre modèles sortis de quatre traditions d’entraînement abordent une question hors-distribution avec quatre vocabulaires différents. Sur des questions ouvertes, “comment ce passage du livre fait-il écho à ce thème ?”, “quelle est la meilleure façon de structurer cet argument ?”, la diversité des angles est un signal, pas du bruit. Une affirmation qui survit à quatre réécritures indépendantes est probablement plus solide qu’une affirmation qu’aucun autre modèle n’aurait formulée.

Adversarité minimale via revue anonyme. C’est l’élément le plus astucieux. En forçant chaque modèle à juger les autres sans savoir qui est qui, on obtient une couche d’évaluation indépendante presque gratuite. Le pattern fait écho, à toute petite échelle, à ce que les dynamic workflows codifient à l’industriel : des agents qui produisent du travail, suivis par d’autres agents qui essaient de le critiquer. La différence, c’est qu’ici l’adversaire n’est pas un autre instance du même modèle, c’est un modèle entraîné par une autre boîte avec d’autres biais.

C’est aussi pour ça que ce protocole vaut la peine d’être pensé à côté de la mémoire structurée façon wiki que Karpathy a posée en parallèle : les deux explorent la même idée, le résultat utile n’est pas la sortie d’un modèle, c’est l’artefact qui survit à un passage. Pour le wiki, c’est l’artefact persistant ; pour le council, c’est la synthèse délibérée.

Pourquoi ça marche sur les questions dures

Le council est utile quand les conditions suivantes sont réunies : la question a plusieurs angles valables, l’utilisateur ne sait pas a priori lequel est le bon, et la sortie est destinée à de la réflexion ou de la décision plutôt qu’à l’exécution machine. Trois exemples concrets dans cet esprit :

Lecture critique d’un texte difficile, l’usage que Karpathy mentionne, c’est de lire un livre à la lumière de plusieurs modèles à la fois.
Décisions de cadrage, quel angle prendre pour un essai, comment structurer une proposition, quels critères retenir pour une décision multi-dimensionnelle.
Questions encyclopédiques où le risque de l’hallucination unique est élevé. Le vote croisé tend à éliminer les faits que seul un modèle invente.

Pour ces cas, le coût marginal (quatre appels payants plutôt qu’un) est dérisoire devant la valeur d’une réponse qui a résisté à un passage par d’autres modèles.

Pourquoi ça ne se généralise pas au code

C’est le point que les présentations enthousiastes du council passent sous silence.

Sur du code, le council est très souvent contre-productif. Les modèles convergent vers des solutions différentes qui ne sont pas comparables sur les critères d’élégance ou de profondeur, elles sont comparables sur des critères mécaniques (est-ce que ça compile, est-ce que les tests passent, est-ce que la complexité tient). Le chairman doit alors arbitrer entre des artefacts qu’il ne peut pas exécuter et dont la qualité est en grande partie hors de son contexte. Le risque concret est une synthèse qui prend la moitié d’une solution et la moitié d’une autre, et qui produit du Frankenstein cassé.

Sur du code, le bon réflexe est plutôt de séparer dans le temps, un modèle qui code, un autre qui révise fresh après. La diversité de jugement reste utile, mais elle s’exerce sur un artefact déjà cohérent, pas sur quatre artefacts hétérogènes à fondre.

L’autre limite est financière. Pour des tâches répétitives, faire quatre appels par requête multiplie la facture par quatre, sans amélioration mesurée sur la majorité des tâches de production. Le council ne survit pas à un volume industriel ; il a été conçu pour des questions singulières où la valeur du verdict justifie le coût.

Ce qu’il faut retenir, même si on n’utilise jamais l’outil

Karpathy le dit explicitement dans le README : “I’m not going to support it in any way, it’s provided here as is for other people’s inspiration and I don’t intend to improve it. Code is ephemeral now.” L’outil n’est pas le livrable, le pattern l’est. Et le pattern survit à n’importe quelle implémentation.

Trois leçons pratiques qu’on peut emporter sans cloner le repo :

D’abord, la revue anonyme entre modèles. Si vous voulez juger deux sorties LLM, retirez les marques de fabrique avant de demander à un troisième de les comparer. Le verdict est plus fiable.

Ensuite, le chairman synthétique plutôt que la moyenne. La fusion de plusieurs réponses doit être faite par un modèle qui hiérarchise, pas par un script qui concatène. La valeur ajoutée est dans la structuration.

Enfin, la frugalité du protocole. Quatre modèles, trois passes, cent-cinquante lignes de code. Pas de framework d’orchestration, pas d’abstraction inutile. C’est exactement le genre de prototype qu’on construit en un samedi pour penser un problème, et qui mérite d’être lu pour ce qu’il dit plutôt qu’utilisé pour ce qu’il fait.

Si cela vous a parlé, vous aimerez LLM Wiki de Karpathy : pré-digérer ses sources plutôt que les réinterroger et Dynamic Workflows dans Claude Code : ce que change l’orchestration externalisée. Abonnez-vous ci-dessous pour recevoir le billet de vendredi prochain.