
El problema
Existe la intuición de que “si ejecutas varios agentes, obtienes más precisión”. Solo es cierta a medias.
Lo que hay que apuntar con precisión no es el multiagente en sí, sino el multiagente que vota sin independencia. Si ejecutas N agentes hechos con el mismo modelo, los mismos datos y el mismo alineamiento, y luego votas por mayoría, no obtienes más precisión. Te equivocas todos juntos.
- Medición empírica de un ensemble de LLM en análisis de sentimiento: añadir modelos más grandes y precisos apenas aportaba ganancia. Porque la independencia que presupone el teorema de Condorcet estaba rota (arXiv:2409.00094).
- Debate multiagente (MAD): aunque enfrentes a los agentes en un debate, no logra vencer de forma estable a la self-consistency de un único agente (ICML 2024, arXiv:2311.17371).
- Mi observación anecdótica (muestra de 1, sin control): en la tarea ZenFlow, al ejecutar Grok Build con 8 agentes simultáneos, se detuvo en 3 de los 10 endpoints y no superó el validate. Es solo una anécdota, así que no le demos tanto peso como a los dos estudios anteriores.
La mayoría no es magia. El teorema del jurado de Condorcet especificó las precondiciones hace 200 años. Y si se cumplen esas premisas, el multiagente realmente funciona. Este texto trata sobre cuáles son esas premisas y cómo cumplirlas.
Las dos premisas de Condorcet
En 1785, Condorcet fijó en una fórmula las condiciones bajo las cuales la mayoría converge hacia la verdad.
- La precisión de cada votante > 50%
- Los errores entre votantes son independientes
(En rigor existe una tercera premisa de uniformidad: que todos tengan la misma precisión. La dejamos de lado por simplicidad.)
La número 2 es la clave. Los modelos alineados con los mismos datos de entrenamiento, la misma arquitectura y el mismo RLHF se equivocan en los mismos lugares. Al votar, la “respuesta equivocada compartida” se convierte en mayoría.
Esto no es solo intuición. Un estudio que analizó más de 350 LLM informa que cuando dos modelos se equivocan a la vez, convergen en la misma respuesta errónea con un 60% de probabilidad (ICML 2025, arXiv:2506.07962). En el mismo estudio se observó una paradoja aún mayor: cuanto más grande y preciso era el modelo, mayor era la correlación de errores. Incluso cuando la arquitectura difería. (Es un único análisis a gran escala y la replicación amplia aún está pendiente. Aun así, la dirección es exactamente la que Condorcet anticipó.)
Las matemáticas de los errores correlacionados
Si los errores son independientes, el ensemble recorta las respuestas equivocadas. Si están correlacionados, no hay nada que recortar.
- Cuando son independientes: P(ambos se equivocan) = 0,1 × 0,1 = 0,01
- Cuando hay correlación total: P(ambos se equivocan) ≈ 0,1 (si uno se equivoca, el otro también)
Esta intuición se arraiga en un teorema de hace 30 años. La descomposición de ambiguity de Krogh y Vedelsby (NeurIPS 1994): error del ensemble = error medio de los miembros − diversidad del ensemble. Cuanto más correlacionados estén los errores de los miembros, más converge a 0 el término de diversidad, y por mucho que añadas modelos, la ganancia desaparece. La teoría unificada de JMLR de 2023 lo generalizó: la diversidad no es una palanca aparte, sino una dimensión oculta dentro de la descomposición bias-variance (arXiv:2301.03962).
En resumen:
- Condición para que el ensemble aumente la precisión: cuanto menor sea la correlación de errores, mayor la ganancia (máxima con correlación negativa).
- Condición para que la ganancia del ensemble converja a 0: correlación de errores → 1 (mismos datos, mismo sesgo).
La forma del voto también importa. La mayoría (majority) eleva la precisión según Condorcet si hay independencia. Pero si la atas a un consenso de “todos deben aprobar” (unanimity, puerta AND), la precisión se derrumba multiplicativamente: si la precisión del clasificador es 0,977 y atas n con unanimidad, queda 0,977ⁿ. Si diseñas mal la puerta, más agentes producen menos precisión.
Hasta aquí el diagnóstico. Ahora la receta se bifurca en dos: reducir la correlación de errores (eje 1) o eludirla (eje 2).
Eje 1 — Si aseguras la independencia, el multiagente funciona
Seamos claros. El multiagente no es lo equivocado. Lo equivocado es votar sin independencia. Si cumples la segunda premisa de Condorcet —si haces que los errores de los agentes no estén correlacionados—, la mayoría eleva la precisión tal como promete. Hay dos caminos para crear independencia.
(a) Divide el problema: es lo más poderoso.
No des a los agentes el mismo problema para que voten; dales subproblemas distintos. Si las entradas son distintas, los errores se vuelven estructuralmente independientes, incluso con el mismo modelo. Dos agentes que leen documentos distintos no pueden equivocarse en el mismo lugar. Porque están mirando lugares diferentes.
Que el sistema de investigación multiagente de Anthropic informara de una mejora del 90,2% frente a un único agente responde exactamente a este principio. El agente líder divide el problema y lo distribuye a subagentes paralelos, y luego combina los resultados que cada uno exploró de forma independiente. No hizo falta verifier. La descomposición hizo la independencia gratis.
Pero hay una condición: debe ser un problema descomponible. En tareas donde las subtareas dependen unas de otras y deben coordinarse sin cesar —como corregir entre varios un mismo bloque de código a la vez—, los subagentes paralelos chocan. El contexto se fragmenta y toman decisiones contradictorias entre sí (Cognition, “Don’t Build Multi-Agents”). La independencia de la descomposición solo es gratis cuando los subproblemas son verdaderamente independientes.
(b) Heterogeneiza los modelos: funciona, pero tiene techo.
Aunque sea el mismo problema, si haces que lo resuelvan modelos distintos (GPT, Claude, Gemini), los pesos son diferentes y baja la correlación de errores. El debate multiagente también vence a la baseline única solo cuando mezclas modelos heterogéneos (arXiv:2502.08788); no lo refuto. La clave es que el problema no es la precisión individual, sino la correlación. Incluso al elegir los modelos para un ensemble, hay un resultado de teoría de la información según el cual no debes escoger el modelo más fuerte, sino la combinación menos correlacionada: aunque sean débiles, si son diversos vencen al modelo único más potente (arXiv:2602.08003). Pero esta palanca tiene un techo bajo. Los corpus de internet se solapan y, como vimos antes, cuanto más grande es el modelo más vuelven a equivocarse juntos (arXiv:2506.07962). La diversidad reduce la correlación, pero no la lleva a 0.
En tercer lugar, la self-consistency, que dispersa las rutas de razonamiento dentro de un mismo modelo, también descorrelaciona los errores superficiales y aporta ganancia (GSM8K +17,9pp, arXiv:2203.11171). Pero esa ganancia se detiene ante el punto donde el modelo se equivoca sistemáticamente: el mismo sesgo grabado por los mismos datos. Por mucho que diversifiques las rutas, el modelo solo tiene una forma de no saber lo que no sabe.
| Fuente de independencia | Cómo funciona | Límite |
|---|---|---|
| Descomposición del problema (entradas distintas) | Si las entradas difieren, los errores son estructuralmente independientes | Solo problemas descomponibles. Contraproducente en tareas dependientes o que requieren coordinación |
| Modelos heterogéneos (GPT+Claude+Gemini) | Si los pesos difieren, la correlación↓ | Solapamiento de corpus + cuanto más grande el modelo, correlación↑ |
| Diversificación de rutas de razonamiento (self-consistency) | Muestreo de rutas dentro de un modelo y mayoría | Se detiene ante el error sistemático |
Conclusión del eje 1: el multiagente funciona si diseñas la independencia. Y la independencia más segura no viene de conseguir otro modelo, sino de partir el problema en piezas independientes.
Eje 2 — El verifier elude la independencia
La tercera palanca es de otra clase. El eje 1 salva el voto reduciendo la correlación de errores. El verifier elude la correlación: aunque los agentes se equivoquen todos juntos, un criterio externo ajeno al error impide que pasen. No es un voto, es una puerta. Por eso funciona incluso donde no puedes asegurar la independencia, siempre que sea un dominio verificable.
Este diagnóstico no es solo mío. “Consensus is Not Verification” (arXiv:2603.06612) fijó antes la misma conclusión: la agregación basada en consenso no aporta ganancia consistente frente a una sola muestra y amplifica los malentendidos compartidos, y el escalado en tiempo de inferencia funciona en dominios verificables (matemáticas) pero falla en los no verificables. El consenso no funciona en matemáticas porque sea una señal de verdad, sino porque el verifier filtra los candidatos. Yo acepto ese diagnóstico y doy un paso más: hacia la receta. La fuente más fuerte de independencia es la descomposición, la independencia y la verificación no compiten sino que se complementan, y el punto donde el verifier determinista se distingue del juez LLM es triple (más abajo).
Sin embargo, la industria delega incluso esta verificación al LLM: LLM-as-Judge.
Empecemos siendo justos. El juez LLM a menudo funciona bien. En MT-Bench, el juez GPT-4 coincidió con la preferencia humana en más del 80%, un nivel igual al de la coincidencia entre humanos (arXiv:2306.05685). Para una evaluación de preferencia vaga, el juez LLM es útil. El problema es dónde se rompe.
El juez se rompe cuando comparte las mismas trampas que el generador. El LLM juez valora más alto que las personas las salidas que le resultan familiares (de baja perplexity) (self-preference bias, NeurIPS 2024 WS, arXiv:2410.21819). Si el juez comparte la misma distribución que el generador, deja pasar la alucinación creada por el mismo modelo “porque le resulta familiar”. El 80% de coincidencia no consuela porque el 20% en el que se equivoca se concentra justo donde también se equivoca el generador: el problema no es la precisión media, sino la correlación de errores. El juicio se tambalea incluso ante variables irrelevantes como la posición de presentación del candidato, no la respuesta correcta (position bias, arXiv:2406.07791).
Una evidencia auxiliar. El juicio del LLM se tambalea incluso en la capa de hardware. Con la misma entrada, incluso el greedy decoding a T=0 da resultados distintos según la configuración de la GPU por la no asociatividad de coma flotante y el batching dinámico: en BF16 la precisión varió hasta 9pp (arXiv:2506.09501). Esto es un problema de reproducibilidad, no de validez, así que no lo tomo como argumento principal. Solo digo que resulta incómodo sentar en el banquillo del juez final a algo que ni siquiera garantiza la misma respuesta a la misma pregunta.
Por eso hay una dirección opuesta. Generador débil + verifier fuerte. Un modelo débil, si le añades el mismo verifier, se acerca al modelo fuerte, y los errores del modelo débil resultan incluso más fáciles de detectar (arXiv:2509.17995). También puedes combinar varios verificadores débiles ponderándolos para construir uno fuerte (Weaver, arXiv:2506.18203), o refinar la salida del LLM con la retroalimentación de un formal verifier para garantizar la consistencia (AlphaVerus, arXiv:2412.06176). Esto no es una afirmación marginal: los modelos de razonamiento y los agentes de codificación que aprenden con recompensas verificables son ahora el área que avanza más rápido, y Jason Wei lo sintetizó como la verifier’s law: la medida en que la IA se fortalece es proporcional a la verificabilidad de la tarea.
Aquí hay que ser honestos. El verifier no es un oráculo mágico. Las pruebas pueden quedarse cortas y la especificación puede estar mal. Más afiladamente: si el verifier lo escribe un LLM, resucita exactamente la crítica que acabo de lanzar contra el LLM-as-Judge. Si el generador y el verificador son el mismo modelo, una prueba equivocada en el mismo lugar deja pasar un código equivocado en el mismo lugar. La correlación de errores solo cambia de sitio a la capa de verificación; no desaparece.
Entonces, ¿cómo evitar la resurrección? Elevando la fiabilidad del verifier fuera del generador. Tres cosas van juntas.
- Revisión humana. Una persona revisa una vez y fija los criterios de verificación (especificación, pruebas, propiedades). Aunque el LLM escriba el borrador, los criterios de aprobación los confirma una persona que está fuera de la distribución del generador. El coste es una sola vez, y un criterio fijado una vez se reutiliza infinitamente: el punto decisivo que lo distingue del LLM-as-Judge, que vuelve a juzgar en cada generación.
- Reducción a las matemáticas y la lógica. En la medida de lo posible, traslada la verificación a una forma mecánicamente decidible: type check, invariantes (invariant), demostración formal, propiedades matemáticas. Aquí no hay lugar para el “juicio” del LLM. El verdadero/falso lo decide una regla, no la opinión del modelo.
- Pruebas repetidas. Como los errores del verifier son reproducibles, se acumula la mejora. Si amplías la cobertura con pruebas de regresión y property-based testing, el agujero que el verifier dejó pasar una vez queda fijado por la prueba y nunca vuelve a filtrarse en el mismo lugar. El juez LLM se tambalea ante la misma entrada, lo que imposibilita esta acumulación.
Estos tres convierten al verifier en un criterio independiente del sesgo del generador. La forma de cortar la correlación de errores también en la capa de verificación es fijar el verifier en lo externo —personas, matemáticas, suites de pruebas— y no dentro del modelo.
Entonces, ¿dónde está la diferencia del verifier determinista? No en la infalibilidad. Son tres. Primero, el criterio de verificación está fuera de los pesos del generador: lo escriba una persona o se cree mediante otro procedimiento, se puede establecer un criterio independiente del sesgo del generador (el juez LLM es estructuralmente incapaz). Segundo, el error del verifier no se manifiesta como una alucinación segura de sí misma, sino como un fallo detectable y reproducible: como da el mismo juicio ante la misma entrada, se depura y se mejora acumulativamente. Tercero, la confianza se traslada a una superficie pequeña y auditable (especificación, pruebas), de modo que una vez que una persona la revisa se reutiliza infinitamente. El verifier no garantiza la precisión, sino que la calidad del verifier se convierte en el límite superior de la precisión, no el tamaño del generador.
La idea central
La fórmula de la precisión del multiagente:
precisión = f(precisión individual, independencia de errores, mecanismo de verificación)
La industria invierte solo en el primero (modelos más grandes). El segundo (independencia) no lo diseña, y el tercero (verificación) lo delega al LLM. Y la estrategia de invertir solo en el primero choca con una paradoja: cuanto más grande es el modelo, mayor es la correlación de errores, así que cuantos más agentes más inteligentes reúnas, más cordialmente se equivocan todos juntos.
El segundo y el tercero son las palancas de verdad. Y no compiten. La independencia (eje 1) salva el voto, y el verifier (eje 2) corta lo que el voto no alcanza. Con ambos a la vez, eres más fuerte.
- Sistema de investigación de Anthropic: lleva la descomposición del eje 1 al extremo, parte el problema y explora en paralelo independiente. Mejora del 90,2% sin verifier.
- SciencePedia (China, 2026): varios solver independientes resuelven cada uno por su lado (eje 1) y solo conserva lo que las respuestas entre modelos consensúan (cross-model consensus, arXiv:2510.26854). Pero como el filtro final es “consenso de modelos”, solo captó la mitad del eje 2: el consenso no es verificación determinista. Por eso solo es fiable cuando se limita a dominios verificables como las matemáticas y la lógica.
- Por qué fallan 8 agentes del mismo modelo: ausencia de ambos ejes. Cero independencia, cero bucle de verificación. Los 8 se detienen juntos en un mismo lugar.
- Por qué yongol funciona incluso con Haiku: implementación directa del eje 2. Aunque la precisión del modelo sea baja, el verifier determinista filtra en cada paso, mientras la calidad del verifier lo sostenga.
La analogía de la democracia
Así como la democracia, si es la mayoría de votantes que vieron las mismas noticias, se vuelve oclocracia, la mayoría de LLM entrenados con los mismos datos es un consenso de alucinaciones. El número de cabezas no crea la verdad. La crean cabezas independientes. Y donde el número de cabezas no alcanza, lo crea un criterio fuera de las cabezas.
Conexión con la evolución
La misma intuición se lee también en los algoritmos de aprendizaje. En la retropropagación, las direcciones del gradient están correlacionadas; en la evolución, las mutaciones se dispersan de forma independiente. Hay un informe de que un algoritmo genético que no usa gradient en absoluto explora un espacio de soluciones distinto del basado en gradient en el aprendizaje por refuerzo profundo (Deep Neuroevolution, arXiv:1712.06567). La exploración independiente alcanza lugares a los que la exploración correlacionada no llega: el principio que vimos en el ensemble tiene la misma forma en la optimización. Pero “es mejor por la independencia” sigue siendo todavía una interpretación a posteriori: lo dejo como hipótesis, no como demostración.
Conclusión
El multiagente no es “más, luego más preciso”. El blanco del ataque no es el multiagente, sino votar sin independencia. Reunir N copias del mismo modelo y votar por mayoría es criar un coro que se equivoca al unísono.
Las recetas son dos, y ambas son reales. Primero, diseña la independencia: si partes el problema en piezas independientes (lo más seguro), el multiagente funciona incluso con el mismo modelo. Segundo, si es un dominio verificable, levanta un verifier fuera del LLM: eleva el límite superior de la precisión con independencia de la independencia.
Fijemos el alcance con honestidad. El eje del verifier (eje 2) es la respuesta solo en dominios verificables: lugares como el código, las matemáticas o las especificaciones formales, donde la respuesta correcta se puede recortar con un criterio externo. En áreas sin ese criterio —como la generación abierta, el resumen, el asesoramiento, la creación o el juicio estratégico—, el eje 1, es decir, el diseño de la independencia, es la única palanca que queda. La palanca cerrada no es el tamaño del modelo, sino la independencia de los errores y, donde sea posible, un verifier externo.
(Aviso de conflicto de intereses: yo fabrico yongol, una herramienta que toma el verifier determinista como keystone. Por eso mi corazón se inclina hacia el eje del verifier. Lee la argumentación anterior teniendo en cuenta ese sesgo: si la columna vertebral está mal, la herramienta también lo está.)
Referencias
Condorcet y teoría de ensembles
- Teorema del jurado de Condorcet (1785) — las dos premisas de la convergencia por mayoría: precisión individual >50%, errores independientes
- Krogh & Vedelsby, Neural Network Ensembles, Cross Validation, and Active Learning (NeurIPS 1994) — descomposición de ambiguity
- Wood et al., A Unified Theory of Diversity in Ensemble Learning (JMLR 2023, arXiv:2301.03962) — descomposición bias-variance-diversity
Correlación de errores en LLM / límites del consenso
- Kim et al., Correlated Errors in Large Language Models (ICML 2025, arXiv:2506.07962) — cuando dos modelos fallan a la vez, 60% misma respuesta errónea; cuanto más grande el modelo, correlación↑
- Lefort et al., Examining Independence in Ensemble Sentiment Analysis … Condorcet Jury Theorem (arXiv:2409.00094) — el supuesto de independencia de Condorcet se rompe en los LLM
- Denisov-Blanch et al., Consensus is Not Verification: Why Crowd Wisdom Strategies Fail for LLM Truthfulness (2026, arXiv:2603.06612) — la agregación por consenso amplifica los malentendidos compartidos; el escalado en tiempo de inferencia solo funciona en dominios verificables (mismo diagnóstico que este texto; diferenciado como receta en el cuerpo)
Multiagente: independencia y descomposición
- Cemri et al., Why Do Multi-Agent LLM Systems Fail? (UC Berkeley, 2025, arXiv:2503.13657) — análisis de 1.600+ trazas de ejecución en 7 frameworks. Clasifica 14 modos de fallo en 3 categorías: diseño del sistema, fallos de alineamiento entre agentes y verificación (task verification)
- Smit et al., Should we be going MAD? (ICML 2024, arXiv:2311.17371) — el debate no vence de forma estable a una baseline simple
- Zhang et al., Stop Overvaluing Multi-Agent Debate (arXiv:2502.08788) — la heterogeneidad es el antídoto (funciona si recuperas la independencia)
- Du et al., Improving Factuality and Reasoning through Multiagent Debate (ICML 2024, arXiv:2305.14325) — la afirmación positiva original del MAD
- Wang et al., Self-Consistency Improves Chain of Thought Reasoning (ICLR 2023, arXiv:2203.11171) — la ganancia de la diversificación de rutas
- Turkmen et al., Don’t Always Pick the Highest-Performing Model: An Information Theoretic View of LLM Ensemble Selection (2026, arXiv:2602.08003) — el criterio de selección de ensembles no es el rendimiento individual sino correlación↓ (maximización de información mutua). Aunque sean débiles, si son diversos vencen
Fiabilidad de LLM-as-Judge
- Zheng et al., Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena (NeurIPS 2023, arXiv:2306.05685) — el juez GPT-4 coincide con humanos en 80%+ (evidencia positiva)
- Wataoka et al., Self-Preference Bias in LLM-as-a-Judge (NeurIPS 2024 WS, arXiv:2410.21819)
- Shi et al., Judging the Judges: Position Bias in LLM-as-a-Judge (arXiv:2406.07791)
- Numerical Sources of Nondeterminism in LLM Inference (arXiv:2506.09501) — la salida se tambalea incluso a T=0
Generador débil + verifier fuerte
- Saad-Falcon et al., Shrinking the Generation-Verification Gap with Weak Verifiers (Weaver, arXiv:2506.18203)
- Aggarwal et al., AlphaVerus: Formally Verified Code Generation (arXiv:2412.06176)
- Variation in Verification: Understanding Verification Dynamics in LLMs (arXiv:2509.17995)
Casos de generación verificable
- SciencePedia (DP Technology / DeepModeling, 2026) — Inverse Knowledge Search over Verifiable Reasoning (arXiv:2510.26854). solver independientes + filtro cross-model consensus
Evolución vs gradient
- Such et al., Deep Neuroevolution (arXiv:1712.06567) — el GA explora un espacio de soluciones distinto del gradient
Medición de primera mano (el propio autor)
- ZenFlow / Grok Build: 8 agentes concurrentes, 3 de 10 endpoints sin completar (sin pasar validate)
- ZenFlow / yongol: Haiku completó, Sonnet 131 min, Opus 76 min
Lecturas complementarias
- Don’t Build Multi-Agents — Cognition (creadores de Devin), 2025. Un texto de campo célebre que afirma rotundamente que es mejor no construir multiagentes. Cuando el contexto se fragmenta, los agentes chocan entre sí: la trampa de las tareas que no se descomponen. (Léelo junto con la continuación Multi-Agents: What’s Actually Working, 2026.)
- How we built our multi-agent research system — Anthropic, 2025. Léelo en pareja con el anterior. Muestra con una mejora del 90,2% la condición bajo la cual el multiagente funciona: cuando las subtareas se paralelizan de forma independiente (la descomposición del eje 1).
- Asymmetry of verification and verifier’s law — Jason Wei, 2025. “La medida en que la IA se fortalece es proporcional a la verificabilidad de la tarea.” La columna vertebral teórica del eje 2 (generador débil + verifier fuerte).
- Hallucinations in code are the least dangerous form of LLM mistakes — Simon Willison, 2025. El código delata la alucinación en el instante en que se ejecuta. El caso más intuitivo de por qué la verificación determinista es una palanca decisiva.
- Using LLM-as-a-Judge For Evaluation — Hamel Husain, 2024. Por qué no debes creer ciegamente al juez LLM y el procedimiento práctico para escalar con automatización solo tras alinearlo con humanos.
- Defeating Nondeterminism in LLM Inference — Thinking Machines Lab, 2025. La verdadera causa de que el LLM se tambalee incluso a temperature=0. El fundamento de infraestructura de por qué hay que poner el verifier fuera del modelo.
- The Wisdom of Crowds — la sabiduría de las multitudes se evapora cuando se derrumban la diversidad y la independencia. Una introducción que desarrolla de forma sencilla la premisa de independencia de Condorcet en un contexto no relacionado con la IA.
- Imagen de portada: generada por IA (Google Gemini)