Quería ver si ejecutar la misma pregunta 51 veces haría que la respuesta fuera más fiable. Tomé un LLM local, le proporcioné un fragmento de código de producción y le pedí una revisión. Luego lo hice de nuevo. Y de nuevo. Un total de cincuenta y una veces, utilizando el voto por mayoría para elegir la "mejor" respuesta. La idea era sencilla: si el modelo tropieza en una ejecución, tal vez la sabiduría de la multitud a través de 51 generaciones cancelaría el ruido y sacaría a la luz el análisis correcto. Eso no fue lo que pasó. El experimento demostró que el voto por mayoría no selecciona la corrección. Selecciona aquello en lo que el modelo es más obstinado.
Esta distinción es importante porque el voto por mayoría se ha convertido en un truco popular en los pipelines de LLM. El patrón es directo. Ejecutas el modelo varias veces con el mismo prompt, recopilas los resultados y te quedas con la respuesta que aparece con más frecuencia. En campos como el diagnóstico por imágenes médicas o la detección de spam, los métodos de ensamble funcionan porque diferentes modelos, o diferentes perspectivas de los datos, producen errores independientes que realmente se cancelan entre sí. Los grandes modelos de lenguaje no son votantes independientes. Son un único sistema con un único historial de entrenamiento, un único conjunto de pesos y un único universo de sesgos. Cuando le haces al mismo modelo la misma pregunta cincuenta y una veces, no estás convocando a un comité. Estás haciendo una encuesta al mismo encuestado bajo estados de ánimo ligeramente diferentes.
El problema de la persistencia
El problema central es que los errores de los LLM rara vez son aleatorios. Son patrones integrados en los datos de entrenamiento y en la arquitectura. Es probable que un modelo que lee mal un decorador de Python específico en una ejecución lo vuelva a leer mal en la siguiente. Un modelo que alucina una vulnerabilidad de seguridad porque el nombre de la variable parece una contraseña, probablemente la volverá a alucinar en la ejecución número cuarenta y siete. El ruido que estás promediando suele ser una variación superficial en la redacción o el formato. El razonamiento subyacente a menudo permanece estático.
Consideremos un ejemplo concreto. Imagina una función que analiza archivos de registro utilizando una expresión regular. La regex es estricta y segura. Pero la cadena r'...' contiene caracteres que, en un contexto diferente, podrían permitir una inyección. Pídele a un LLM que revise esto. Si el modelo ha visto mil publicaciones en Stack Overflow advirtiendo contra la inyección de regex en analizadores de registros, podría marcar este fragmento seguro como un riesgo. Ejecútalo una vez y obtendrás un falso positivo. Ejecútalo 51 veces y hay una gran probabilidad de que obtengas 51 falsos positivos, o al menos una mayoría contundente. El voto por mayoría ahora afianza la alucinación. El modelo es persistente, por lo que el "consenso" también lo es.
Esto sucede porque los trucos de temperatura y muestreo no cambian lo que el modelo sabe. Solo reorganizan su forma de hablar. Una temperatura alta podría hacer que la explicación sea más conversacional o escueta. Podría intercambiar sinónimos. No le enseña de repente al modelo que la regex es en realidad inofensiva. Las variaciones sobre las que estás votando son cosméticas. El error es estructural.
Lo que revelan las 51 ejecuciones
Cuando extendí esos 51 resultados sobre mi escritorio, el patrón era obvio. El modelo no exploró 51 interpretaciones diferentes del código. Ensayó la misma interpretación con voces ligeramente distintas. Un puñado de ejecuciones se salió del guion, sugiriendo correcciones para casos límite o notando problemas de estilo no relacionados. Pero el grupo dominante, la clara mayoría, seguía volviendo a la misma afirmación central incorrecta. Esa afirmación no era correcta. Solo era familiar.
La matemática del voto por mayoría asume ensayos de Bernoulli independientes. Se necesitan errores no relacionados para que la mayoría supere al individuo. En mi experimento, los errores estaban profundamente relacionados. Compartían la misma causa raíz: la distribución de entrenamiento del modelo otorga un peso excesivo a ciertos tropos de programación. Por lo tanto, el voto por mayoría no redujo el error. Amplificó el sesgo de la mayoría. Dio una falsa sensación de certeza a un análisis defectuoso.
Esto es especialmente peligroso en la revisión de código porque los desarrolladores tratan la salida de la IA, ya sea unánime o casi unánime, como algo definitivo. Una sola sugerencia vacilante es fácil de descartar. Una recomendación que se mantiene constante a lo largo de cincuenta y una ejecuciones se siente como una verdad absoluta. No lo es. Es un bucle de tierra.
Dónde funciona realmente el voto
Nada de esto significa que no debas ejecutar un modelo más de una vez. El voto por mayoría puede ayudar en situaciones limitadas donde la tarea es superficial y los errores son verdaderamente aleatorios. Pedirle a un modelo que elija entre dos formatos sintácticos, que seleccione una convención de nomenclatura de variables o que extraiga una cadena de fecha de una línea de registro; estas tareas de bajo riesgo a veces se benefician del muestreo repetido. La variación es ruido genuino, y un voto rápido lo soluciona.
El problema comienza cuando la tarea requiere razonar sobre la intención. ¿Este control de autenticación pertenece aquí? ¿Es segura esta llamada asíncrona? ¿Es esta colisión de claves de caché realmente explotable? Estas preguntas exigen una comprensión del contexto, no solo una coincidencia de patrones. El buscador de patrones de un modelo es determinista en su sesgo. Buscará la respuesta más común de sus datos de entrenamiento, no la respuesta más precisa para tu base de código.
Formas más inteligentes de gastar tu capacidad de cómputo
Cincuenta y una ejecuciones de un modelo local cuestan tiempo real y electricidad. Hay mejores formas de invertir ese cómputo. Si quieres mejorar la fiabilidad, la diversidad vence al volumen. Ejecuta dos modelos diferentes con