Volevo vedere se porre la stessa domanda 51 volte avrebbe reso la risposta più affidabile. Ho preso un LLM locale, gli ho fornito un frammento di codice di produzione e gli ho chiesto una revisione. Poi l'ho rifatto. E ancora. Cinquantuno volte in totale, usando il voto a maggioranza per scegliere la risposta "migliore". L'idea era semplice: se il modello inciampa in un'esecuzione, forse la saggezza della folla attraverso 51 generazioni avrebbe annullato il rumore e fatto emergere l'analisi corretta. Non è quello che è successo. L'esperimento ha dimostrato che il voto a maggioranza non seleziona la correttezza. Seleziona ciò di cui il modello è più ostinato.
Questa distinzione è importante perché il voto a maggioranza è diventato un trucco popolare nelle pipeline degli LLM. Il pattern è semplice. Si esegue
None of this means you should never run a model more than once. Majority voting can help in narrow situations where the task is shallow and the errors are truly random. Asking a model to pick between two syntactic formats, to choose a variable naming convention, or to extract a date string from a log line—these low-stakes tasks sometimes benefit from repeated sampling. The variation is genuine noise, and a quick vote cleans it up.
The trouble starts when the task requires reasoning about intent. Does this auth check belong here? Is this async call safe? Is this cache key collision actually exploitable? These questions demand an understanding of context, not just pattern matching. A model's pattern matcher is deterministic in its bias. It will reach for the most common answer from its training data, not the most accurate answer for your codebase.
Smarter Ways to Spend Your Compute
Fifty-one runs of a local model cost real time and electricity. There are better ways to invest that compute. If you want to improve reliability, diversity beats volume. Run two different models with