Las aplicaciones de inteligencia artificial empiezan a parecerse menos a una conversación con un único modelo y más a una pequeña central de distribución. Una consulta puede enviarse a ChatGPT, Claude, Gemini o cualquier otro sistema según su precio, rapidez o especialidad. La promesa consiste en asignar cada tarea al modelo que tenga más probabilidades de resolverla bien, del mismo modo que un equipo reparte el trabajo entre personas con habilidades diferentes.

La propuesta parece sensata, pero viene acompañada preguntas difíciles que, a priori, no podemos imaginarnos. Hay que decidir qué modelo debe responder, cuándo conviene consultar a varios, cómo se comparan sus resultados y cuánto cuesta mantener toda esa infraestructura. El beneficio de combinar modelos depende tanto de sus capacidades como de la posibilidad de reconocer cuál ha acertado. Un trabajo reciente de Josef Chen estudia ese problema mediante 67 modelos de 21 proveedores y plantea una forma más precisa de medir los límites de estas arquitecturas. 

De un solo modelo a una pequeña orquesta

Existen varias estrategias para combinar modelos de lenguaje. Un enrutador analiza cada consulta y la dirige al sistema que considera más adecuado. Una cascada comienza por una opción barata y recurre a otra más potente cuando detecta poca confianza. También pueden pedirse varias respuestas y elegir la mayoritaria, o encargar a un modelo adicional que sintetice las propuestas. Todas estas técnicas intentan obtener una precisión superior a la de cualquier componente aislado.

La diversidad parece ofrecer una ventaja evidente. Si un modelo destaca en programación y otro resuelve mejor las preguntas científicas, reunirlos debería reducir los puntos débiles del conjunto. Para estimar esa complementariedad se suele medir la correlación entre sus errores: cuanto menos coincidan dos modelos al equivocarse, mayor parece el margen para combinarlos.

El problema es que esa comparación se realiza por parejas. Saber que A y B fallan de manera distinta, y que B y C también lo hacen, no permite reconstruir todo el patrón de errores del grupo. Tres o más modelos pueden presentar relaciones similares por pares y, pese a ello, diferir mucho en la frecuencia con la que todos fallan a la vez. El paper demuestra matemáticamente que esa información conjunta no puede deducirse a partir de una sola medida de correlación. 

El techo de fallo compartido

El concepto central del estudio es la tasa de fallo conjunto, representada por la letra griega beta. Mide la proporción de preguntas en las que todos los modelos del grupo dan una respuesta incorrecta. Si esto sucede, cualquier mecanismo que se limite a elegir una de las respuestas disponibles también se equivocará.

La consecuencia puede expresarse con una fórmula sencilla. Si la tasa de fallo conjunto es β, ningún enrutador, votación o cascada puede superar una precisión de 1 − β. Un sistema cuyos modelos fallan simultáneamente en el 5 % de las consultas tendrá un techo máximo del 95 %, incluso bajo el supuesto irreal de que el selector acierta siempre que alguna respuesta es correcta.

En MATH-500, un conjunto de problemas matemáticos de respuesta abierta, los 67 modelos fallaron juntos en 17 de las 330 preguntas cubiertas por todos ellos. La tasa observada fue del 5,2 %, frente al 2,3 % previsto por un modelo estadístico construido con las correlaciones entre pares. La frecuencia real resultó 2,25 veces mayor que la estimación completa basada en una cópula gaussiana. 

La diferencia crecía al aumentar el número de modelos. Con dos sistemas, la información por parejas describe necesariamente el fallo conjunto; al ampliar el grupo, las interacciones de orden superior adquieren más peso. El estudio denomina common-mode atom al conjunto de consultas que provocan un fracaso generalizado. Añadir más modelos apenas ayuda cuando todos tropiezan con la misma parte difícil del problema.

Tener una respuesta correcta tampoco basta

El techo de fallo compartido describe un límite absoluto, pero no es el único obstáculo. Puede ocurrir que al menos uno de los modelos conozca la solución y que el sistema sea incapaz de identificarlo. En ese escenario, la respuesta correcta ya está presente, aunque queda mezclada entre alternativas plausibles.

Los autores probaron varios enrutadores sobre un conjunto de 15 modelos. Un clasificador basado en características del texto, un sistema de predicción de aciertos por modelo, un selector multiclase y un modelo de lenguaje utilizado como enrutador capturaron muy poco de la mejora que habría obtenido un selector perfecto. La consulta, por sí sola, ofrecía escasas pistas sobre qué modelo acertaría cuando los mejores discrepaban. En uno de los experimentos, el enrutador basado en otro modelo eligió siempre al mismo sistema y aprovechó exactamente cero de la ganancia teórica. 

Esto permite distinguir dos situaciones. En las tareas limitadas por el techo, como parte de las matemáticas abiertas o la programación competitiva, todos los modelos comparten ciertos errores. En las tareas limitadas por la realizabilidad, alguno suele acertar, pero el selector no sabe cuál. La primera situación carece de respuestas correctas disponibles; la segunda carece de un criterio fiable para encontrarlas.

La distinción evita una lectura demasiado simple. Una tasa de fallo conjunto pequeña deja abierto un techo elevado, pero no garantiza que el sistema pueda alcanzarlo. Hace falta una señal relacionada con cada consulta: una prueba automática, una verificación formal, un esquema de salida rígido o algún indicador que permita discriminar entre las respuestas.

La forma de la pregunta importa

El experimento con GPQA-Diamond ofrece una comparación especialmente clara. Los investigadores utilizaron las mismas 79 preguntas científicas en dos formatos. En la versión de elección múltiple, ningún ítem hizo fallar a todos los modelos. Al retirar las opciones y exigir una respuesta libre, aparecieron diez fallos conjuntos. La tasa pasó de aproximadamente cero al 12,7 % sin cambiar el contenido de las preguntas.

Las opciones actúan como una estructura de apoyo. Permiten descartar alternativas, reconocer la respuesta y reducir la libertad de generación. La versión abierta obliga al modelo a producir el resultado sin esas pistas. También hizo caer la precisión media del 66 % al 51 %, mientras que la del mejor sistema descendió del 91 % al 77 %.

El resultado tiene una consecuencia práctica. Convertir una tarea abierta en una operación verificable puede modificar los límites del sistema. Pedir un texto libre es distinto de exigir una salida estructurada; generar código sin comprobación es distinto de ejecutarlo contra una batería de pruebas; redactar una consulta de base de datos es distinto de verificar si funciona.

Esta vía no mejora el conocimiento interno de los modelos, pero facilita detectar errores. En entornos donde el resultado puede comprobarse de forma automática, una arquitectura multimodelo tiene más posibilidades de escoger bien. Cuando la calidad es subjetiva o la respuesta admite muchas formas, el margen se vuelve más difícil de aprovechar.

Cuando la mayoría se equivoca

La votación entre modelos introduce otro problema: los participantes pueden tener calidades muy distintas. Si varios sistemas mediocres coinciden en una respuesta incorrecta, pueden imponerse al modelo más preciso. Una mayoría numérica no equivale a una mayoría competente.

En los ensayos del paper, la votación ingenua entre modelos desiguales produjo una ganancia media negativa en el conjunto más difícil. El resultado encaja con una regla práctica, la diversidad funciona mejor cuando los miembros se encuentran en una franja de calidad parecida. Al comparar conjuntos equilibrados, los grupos formados por modelos diferentes y con errores menos correlacionados superaron a los que repetían varias veces el mismo modelo.

La cantidad de componentes tampoco compensa por sí sola la falta de variedad útil. Incorporar un vigésimo modelo puede aumentar los costes, la latencia y la dificultad de mantenimiento sin cubrir las preguntas que derrotan a los diecinueve anteriores. La variable decisiva es la diversidad de los modos de fallo, no el tamaño del catálogo.

Medir antes de construir

El estudio propone una comprobación previa que puede realizarse con los registros de evaluación existentes. El equipo selecciona un conjunto representativo de consultas, ejecuta todos los modelos candidatos y cuenta cuántas veces fallan juntos. Mediante un intervalo de Clopper-Pearson puede estimar un límite conservador para la tasa real. Ese cálculo permite saber cuánto margen máximo existe antes de entrenar un enrutador o desplegar una arquitectura compleja.

La prueba no exige llamadas adicionales si las respuestas ya han sido evaluadas. Su coste de inferencia es, por tanto, nulo. Una empresa puede repetirla cuando cambie de modelos, de proveedor o de tipo de consulta. Si el mejor modelo disponible se encuentra ya cerca del techo calculado, el margen para mejorar será pequeño y quizá no compense la infraestructura adicional.

Conviene mantener cierta prudencia. Los experimentos se concentran en tareas verificables de matemáticas, ciencia y programación, y algunos resultados dependen de pocos fallos conjuntos. El propio autor reconoce que queda abierta la cuestión de si el patrón se mantiene en trabajos subjetivos, como la redacción creativa o la evaluación estética. El estudio ofrece una herramienta para decidir mejor, no una prohibición general contra los sistemas multimodelo.

Combinar ChatGPT, Claude, Gemini u otros modelos puede resultar útil cuando aportan capacidades comparables, fallan en preguntas distintas y existe una señal fiable para escoger entre sus respuestas. Sin esas condiciones, la arquitectura corre el riesgo de convertirse en una maquinaria costosa que reorganiza los mismos errores. Antes de sumar modelos, conviene averiguar qué problemas comparten y cuánto espacio real queda por conquistar.