Google presenta Gemini 1.0: cómo leer un benchmark antes de creer el titular

Google DeepMind presentó Gemini 1.0 el 6 de diciembre de 2023 como una familia de modelos capaz de trabajar con texto, imágenes, audio, vídeo y código. El anuncio concentró la atención en dos cifras de Gemini Ultra: superar el mejor resultado publicado en 30 de 32 pruebas académicas y alcanzar el 90,0% en MMLU. Las cifras eran reales dentro de la evaluación de Google, pero no significaban que cualquier versión disponible de Gemini superara a una persona experta en cualquier tarea.

Para leer el lanzamiento con rigor hay que separar cuatro cosas: qué variante obtuvo el resultado, cómo se administró la prueba, qué producto podía usar el público ese día y qué límites reconocían los autores. Esa disciplina sirve para cualquier anuncio de modelos. Un benchmark es una medición bajo condiciones concretas, no un certificado general de inteligencia.

Gemini era una familia de tres tamaños

El anuncio oficial de Google distinguía Ultra, Pro y Nano. Ultra era la variante mayor para tareas de alta complejidad; Pro, la destinada a escalar un abanico amplio de tareas; Nano, la eficiente para dispositivos. El 6 de diciembre una versión ajustada de Pro empezó a llegar a Bard en inglés, Nano se activó en funciones concretas del Pixel 8 Pro y Ultra seguía en comprobaciones de seguridad antes de un acceso más amplio.

Por eso “Gemini logró un 90%” es una frase incompleta. El resultado de MMLU correspondía a Ultra con un método de respuesta específico. No describía Nano en un teléfono, Pro en Bard ni una futura llamada a una API. El nombre familiar funciona para una campaña; una evaluación técnica necesita apellido, versión y configuración.

La misma separación se aplica a la multimodalidad. El modelo se entrenó para trabajar con varias modalidades, pero un producto podía exponer solo texto al principio. La nota sobre Bard con Gemini Pro decía que el acceso inicial admitía indicaciones de texto y que otras modalidades llegarían después. Capacidad de una familia y función disponible en una interfaz no son sinónimos.

Qué midió realmente el 90,0%

MMLU reúne preguntas de elección múltiple de 57 materias, entre ellas matemáticas, física, historia, derecho, medicina y ética. No pone al modelo a ejercer esas profesiones. Comprueba si selecciona respuestas correctas en un conjunto definido. El término “experto humano” designa una referencia de rendimiento en la prueba, no una equivalencia entre un sistema y el juicio profesional de una persona en el mundo.

El informe técnico de Gemini 1.0 mostraba además que la forma de preguntar cambiaba la puntuación. Gemini Ultra alcanzaba el 90,04% con un enfoque de cadena de pensamiento que elegía entre responder directamente y razonar paso a paso según la confianza del modelo. En la evaluación de cinco ejemplos sin ese método, la cifra era 83,7%. Ambas describían el mismo modelo bajo protocolos distintos.

Ese contraste enseña una regla: nunca copie una cifra sin copiar también la columna metodológica. Hay que anotar el conjunto, la variante, el número de ejemplos incluidos en la indicación, si hubo razonamiento adicional, qué herramientas se permitieron y qué referencia se usó para comparar. Una mejora de protocolo puede ser valiosa, pero no debe presentarse como si el modelo hubiera cambiado.

Treinta de treinta y dos tampoco significa todo

Google informó que Ultra superaba el mejor resultado previo en 30 de 32 benchmarks usados en investigación de modelos de lenguaje. El denominador importa: era una cesta seleccionada de pruebas de texto, código y modalidades, no treinta y dos necesidades de una empresa ni treinta y dos situaciones de la vida cotidiana. Algunas medían conocimiento, otras resolución matemática, lectura de imágenes o transcripción.

Los benchmarks permiten comparar sistemas con una regla común, pero pueden saturarse, contener ejemplos parecidos a datos de entrenamiento o premiar atajos que no aparecen en una tarea real. El propio informe pedía evaluaciones más difíciles y robustas a medida que los modelos alcanzaban resultados altos. La respuesta correcta no es desechar todas las pruebas, sino conectarlas con una prueba local que represente el uso previsto.

Para resumir contratos, por ejemplo, importa recuperar excepciones, conservar negaciones y citar el pasaje de origen. Para asistir en código, importa que el programa pase pruebas nuevas, sea seguro y pueda mantenerse. MMLU no mide por sí solo ninguna de esas cadenas completas. Una organización debe convertir su riesgo en casos comprobables antes de elegir un modelo.

El caso AlphaCode 2 muestra el sistema completo

El lanzamiento también presentó AlphaCode 2 como una aplicación especializada basada en modelos Gemini. Su informe técnico decía que resolvía 1,7 veces más problemas que el AlphaCode original y obtenía un rendimiento superior al 85% de los participantes en la plataforma de evaluación. No era simplemente “Gemini escribe código”: combinaba modelos, muestreo masivo, ejecución, filtrado y un sistema de puntuación.

La arquitectura importa más que el adjetivo. AlphaCode 2 generaba hasta un millón de candidatos por problema, filtraba los que no compilaban o fallaban ejemplos, agrupaba soluciones y elegía un conjunto pequeño. El resultado dependía de cómputo abundante y verificación automática. Google advertía que el coste hacía que el sistema operara a escala de competición y que aún necesitaba más trabajo antes de alcanzar las capacidades de los mejores participantes.

La lección se traslada a productos: un modelo generativo puede proponer; herramientas externas pueden comprobar; una política decide qué salida aceptar. Cuando existe un verificador fiable, como un compilador y pruebas ocultas, la generación puede insertarse en un circuito más seguro. Cuando no existe, una respuesta elocuente conserva mucha más incertidumbre.

Seguridad evaluada no significa riesgo resuelto

Google describió evaluaciones de sesgo, toxicidad, ciberataques, persuasión y autonomía, además de pruebas adversarias internas y externas. También incorporó clasificadores y filtros en los productos. Es información sobre el proceso de mitigación, no una demostración de ausencia de daño.

El informe técnico reconocía alucinaciones y dificultades en comprensión causal, deducción lógica y razonamiento contrafactual. Su ficha indicaba que los modelos no debían incorporarse a aplicaciones posteriores sin analizar el daño potencial del uso concreto. En otras palabras, superar un examen y pasar una batería de seguridad no elimina el deber de evaluar el contexto donde se va a desplegar.

Disponibilidad: presente y futuro en la misma página

El 6 de diciembre, Bard comenzaba a usar una versión afinada de Gemini Pro en inglés en más de 170 países y territorios; Europa y otros idiomas quedaban para más adelante. Nano llegaba a dos funciones del Pixel 8 Pro. El acceso de desarrolladores a Pro mediante Google AI Studio y Vertex AI estaba anunciado para el 13 de diciembre. Ultra se reservaba para pruebas tempranas antes de una apertura prevista para el año siguiente.

Una tabla con filas de variante y columnas de fecha, producto, idioma, modalidad y estado evita convertir planes en hechos. “Presentado” no significa “disponible”; “disponible” no significa “disponible en mi región”; y “el modelo es multimodal” no significa que la interfaz que puedo abrir acepte todas las modalidades.

Una plantilla para la próxima comparación

Antes de repetir un titular de rendimiento, escriba una ficha de seis líneas: variante exacta; benchmark y versión; protocolo de indicación; herramientas permitidas; referencia comparada; producto disponible. Añada una séptima: limitación reconocida por el propio informe. Si una línea no puede completarse, la afirmación necesita reducirse.

Después diseñe una prueba ciega con ejemplos propios y criterios previos. Separe exactitud, tasa de abstención, coste, latencia y daño de un error. Revise casos fallidos y no solo la media. El mejor modelo en una cesta académica puede no ser el mejor componente para un proceso que exige trazabilidad o una respuesta rápida en un dispositivo.

La capacidad transferible es leer una cifra como evidencia condicionada: quién fue medido, con qué método y para qué conclusión. Gemini 1.0 fue un lanzamiento técnico importante; su valor se entiende mejor al conservar esos límites. El benchmark abre una investigación. No la cierra.