Je voulais voir si le fait de poser la même question 51 fois rendrait la réponse plus fiable. J'ai pris un LLM local, je lui ai soumis un extrait de code de production et je lui ai demandé une revue. Puis je l'ai refait. Encore et encore. Cinquante et une fois au total, en utilisant le vote majoritaire pour choisir la « meilleure » réponse. L'idée était simple : si le modèle trébuche lors d'une exécution, peut-être que la sagesse de la foule à travers 51 générations annulerait le bruit pour faire émerger l'analyse correcte. Ce n'est pas ce qui s'est passé. L'expérience a montré que le vote majoritaire ne sélectionne pas la justesse. Il sélectionne ce sur quoi le modèle est le plus têtu.
Cette distinction est importante car le vote majoritaire est devenu un « hack » populaire dans les pipelines de LLM. Le schéma est simple. Vous exécutez le modèle plusieurs fois sur le même prompt, vous collectez les sorties et vous gardez la réponse qui apparaît le plus fréquemment. Dans des domaines comme l'imagerie médicale ou la détection de spam, les méthodes d'ensemble fonctionnent parce que différents modèles, ou différentes vues des données, produisent des erreurs indépendantes qui finissent par s'annuler. Les grands modèles de langage ne sont pas des votants indépendants. Ils constituent un système unique avec un historique d'entraînement unique, un ensemble de poids unique et un univers de biais unique. Lorsque vous posez la même question au même modèle cinquante et une fois, vous ne réunissez pas un comité. Vous effectuez un sondage auprès du même répondant sous des humeurs légèrement différentes.
Le problème de la persistance
Le problème de fond est que les erreurs des LLM sont rarement aléatoires. Ce sont des schémas ancrés dans les données d'entraînement et l'architecture. Un modèle qui interprète mal un décorateur Python spécifique lors d'une exécution est susceptible de commettre la même erreur lors de la suivante. Un modèle qui hallucine une vulnérabilité de sécurité parce que le nom d'une variable ressemble à un mot de passe hallucinera probablement encore lors de la quarante-septième exécution. Le bruit que vous tentez de lisser par la moyenne est généralement une variation superficielle de la formulation ou du formatage. Le raisonnement sous-jacent reste souvent figé.
Prenons un exemple concret. Imaginez une fonction qui analyse des fichiers journaux à l'aide d'une expression régulière. La regex est stricte et sûre. Mais la chaîne r'...' contient des caractères qui, dans un autre contexte, pourraient permettre une injection. Demandez à un LLM de l'examiner. Si le modèle a vu des milliers de publications sur Stack Overflow mettant en garde contre l'injection de regex dans les analyseurs de logs, il peut signaler cet extrait sûr comme un risque. Exécutez-le une fois, vous obtenez un faux positif. Exécutez-le 51 fois, et il y a de fortes chances que vous obteniez 51 faux positifs, ou du moins une large majorité. Le vote majoritaire vient alors ancrer l'hallucination. Le modèle est persistant, donc le « consensus » l'est aussi.
Cela se produit parce que la température et les astuces d'échantillonnage ne changent pas ce que le modèle sait. Elles ne font que réorganiser sa façon de s'exprimer. Une température élevée peut rendre l'explication bavarde ou concise. Elle peut échanger des synonymes. Elle n'apprend pas soudainement au modèle que la regex est en fait inoffensive. Les variations sur lesquelles vous votez sont cosmétiques. L'erreur est structurelle.
Ce que révèlent 51 exécutions
Lorsque j'ai étalé ces 51 sorties sur mon bureau, le schéma était évident. Le modèle n'a pas exploré 51 interprétations différentes du code. Il a répété la même interprétation avec des voix légèrement différentes. Quelques exécutions ont dévié du script, suggérant des correctifs pour des cas limites ou remarquant des problèmes de style sans rapport. Mais le groupe dominant, la majorité claire, revenait sans cesse à la même affirmation centrale incorrecte. Cette affirmation n'était pas correcte. Elle était simplement familière.
Les mathématiques du vote majoritaire supposent des essais de Bernoulli indépendants. Il faut des erreurs sans lien entre elles pour que la majorité surpasse l'individu. Dans mon expérience, les erreurs étaient profondément liées. Elles partageaient la même cause profonde : la distribution d'entraînement du modèle surpondère certains tropes de codage. Le vote majoritaire n'a donc pas réduit l'erreur. Il a amplifié le biais majoritaire. Il a donné un faux sentiment de certitude à une analyse erronée.
C'est particulièrement dangereux lors de la revue de code, car les développeurs considèrent les résultats d'une IA unanimes ou quasi unanimes comme faisant autorité. Une suggestion unique et hésitante est facile à écarter. Une recommandation qui reste constante sur cinquante et une exécutions ressemble à une vérité terrain. Ce n'est pas le cas. C'est une boucle de masse.
Là où le vote fonctionne réellement
Cela ne signifie pas que vous ne devriez jamais exécuter un modèle plus d'une fois. Le vote majoritaire peut aider dans des situations restreintes où la tâche est superficielle et les erreurs sont véritablement aléatoires. Demander à un modèle de choisir entre deux formats syntaxiques, de sélectionner une convention de nommage de variables ou d'extraire une chaîne de date d'une ligne de log — ces tâches à faible enjeu bénéficient parfois d'un échantillonnage répété. La variation est un bruit réel, et un vote rapide permet de le nettoyer.
Le problème commence lorsque la tâche nécessite un raisonnement sur l'intention. Cette vérification d'authentification a-t-elle sa place ici ? Cet appel asynchrone est-il sûr ? Cette collision de clé de cache est-elle réellement exploitable ? Ces questions exigent une compréhension du contexte, et pas seulement une reconnaissance de formes. Le moteur de reconnaissance de formes d'un modèle est déterministe dans son biais. Il privilégiera la réponse la plus courante issue de ses données d'entraînement, et non la réponse la plus précise pour votre base de code.
Des manières plus intelligentes d'utiliser votre puissance de calcul
Cinquante et une exécutions d'un modèle local coûtent du temps et de l'électricité. Il existe de meilleures façons d'investir cette puissance de calcul. Si vous voulez améliorer la fiabilité, la diversité l'emporte sur le volume. Exécutez deux modèles différents avec