Eu queria ver se fazer a mesma pergunta 51 vezes tornaria a resposta mais confiável. Peguei um LLM local, alimentei-o com um

Eu queria ver se rodar a mesma pergunta 51 vezes tornaria a resposta mais confiável. Peguei um LLM local, alimentei-o com um trecho de código de produção e pedi uma revisão. Depois fiz de novo. E de novo. Cinquenta e uma vezes no total, usando votação majoritária para escolher a "melhor" resposta. A ideia era simples: se o modelo tropeçasse em uma execução, talvez a sabedoria da multidão através de 51 gerações cancelasse o ruído e trouxesse à tona a análise correta. Não foi o que aconteceu. O experimento mostrou que a votação majoritária não seleciona a correção. Ela seleciona aquilo em que o modelo é mais teimoso.

Essa distinção é importante porque a votação majoritária tornou-se um "hack" popular em pipelines de LLM. O padrão é direto. Você executa o modelo várias vezes no mesmo prompt, coleta as saídas e mantém a resposta que aparece com mais frequência. Em campos como imagem médica ou detecção de spam, métodos de ensemble funcionam porque diferentes modelos, ou diferentes visões dos dados, produzem erros independentes que realmente se cancelam. Grandes modelos de linguagem não são votantes independentes. Eles são um único sistema com um único histórico de treinamento, um único conjunto de pesos e um único universo de vieses. Quando você faz a mesma pergunta ao mesmo modelo cinquenta e uma vezes, você não está convocando um comitê. Você está fazendo uma pesquisa com o mesmo entrevistado sob estados de espírito ligeiramente diferentes.

O Problema da Persistência

A questão central é que os erros de LLM raramente são aleatórios. Eles são padrões incorporados nos dados de treinamento e na arquitetura. Um modelo que lê incorretamente um decorador Python específico em uma execução provavelmente o lerá incorretamente na próxima. Um modelo que alucina uma vulnerabilidade de segurança porque o nome da variável se parece com uma senha provavelmente a alucinará novamente na execução número quarenta e sete. O ruído que você está tentando neutralizar é geralmente uma variação superficial na redação ou formatação. O raciocínio subjacente muitas vezes permanece travado no lugar.

Considere um exemplo concreto. Imagine uma função que analisa arquivos de log usando uma expressão regular. A regex é estrita e segura. Mas a string r'...' contém caracteres que, em um contexto diferente, poderiam permitir uma injeção. Peça a um LLM para revisar isso. Se o modelo tiver visto mil postagens no Stack Overflow alertando contra injeção de regex em analisadores de log, ele pode sinalizar esse trecho seguro como um risco. Execute uma vez, você obtém um falso positivo. Execute 51 vezes, e há uma boa chance de você obter 51 falsos positivos, ou pelo menos uma maioria esmagadora. O voto majoritário agora consolida a alucinação. O modelo é persistente, então o "consenso" também é persistente.

Isso acontece porque truques de temperatura e amostragem não mudam o que o modelo sabe. Eles apenas reorganizam como ele fala. Uma temperatura alta pode tornar a explicação tagarela ou concisa. Pode trocar sinônimos. Não ensina de repente ao modelo que a regex é, na verdade, inofensiva. As variações sobre as quais você está votando são cosméticas. O erro é estrutural.

O que 51 Execuções Revelam

Quando espalhei aquelas 51 saídas sobre minha mesa, o padrão era óbvio. O modelo não explorou 51 interpretações diferentes do código. Ele ensaiou a mesma interpretação em vozes ligeiramente diferentes. Algumas execuções saíram do roteiro, sugerindo correções de casos de borda ou notando problemas de estilo não relacionados. Mas o cluster dominante, a maioria clara, continuava retornando à mesma afirmação central incorreta. Aquela afirmação não estava correta. Era apenas familiar.

A matemática da votação majoritária assume ensaios de Bernoulli independentes. Você precisa de erros não relacionados para que a maioria supere o indivíduo. No meu experimento, os erros estavam profundamente relacionados. Eles compartilhavam a mesma causa raiz: a distribuição de treinamento do modelo sobrecarrega certos tropos de codificação. O voto majoritário, portanto, não reduziu o erro. Ele amplificou o viés da maioria. Ele deu uma falsa sensação de certeza a uma análise falha.

Isso é especialmente perigoso na revisão de código porque os desenvolvedores tratam a saída de IA unânime ou quase unânime como autoritativa. Uma única sugestão hesitante é fácil de descartar. Uma recomendação que se mantém firme ao longo de cinquenta e uma execuções parece ser a verdade absoluta. Não é. É um loop de terra.

Onde a Votação Realmente Funciona

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