Sora 2 Pro en los benchmarks de vídeo: qué mide una preferencia ciega y qué deja sin responder

Una puntuación de vídeo no equivale a una evaluación completa

Decir que Sora 2 Pro «rinde bien» en un benchmark puede referirse a resultados distintos. Puede significar que las personas prefirieron sus clips en una comparación por pares, que obtuvo una puntuación alta en una dimensión automática o que cumplió mejor un conjunto de instrucciones. Esas conclusiones no son intercambiables: cada una depende de qué se midió, con qué muestras y bajo qué condiciones.

La distinción importa porque un ranking agregado puede resumir una preferencia general, pero no diagnostica necesariamente qué propiedad del vídeo causó esa preferencia. Un clip podría resultar más atractivo en una votación y, al mismo tiempo, contener errores de continuidad, omitir elementos del prompt o sincronizar mal el sonido. Para atribuir una fortaleza concreta hay que consultar la tarea y la métrica correspondientes, no deducirla de la posición en una clasificación.

Las fuentes disponibles permiten describir la metodología de varias evaluaciones y algunos datos publicados por una arena, así como las opciones de la API de Sora. No demuestran que Sora 2 Pro haya sido evaluado en los benchmarks VBench o Video-Bench. Esos trabajos sirven aquí para explicar qué dimensiones puede separar un benchmark; no deben presentarse como resultados del modelo.

Primero, identificar la unidad evaluada

«Sora 2 Pro» no basta como descripción experimental. Un informe útil debe especificar la variante identificada, el canal de acceso y la fecha de generación. También debería aclarar si las muestras se obtuvieron mediante la API o mediante otra interfaz, qué opciones estaban disponibles y si hubo procesamiento posterior. Sin esos datos, una diferencia observada no puede atribuirse con seguridad al modelo por sí solo.

La documentación de OpenAI identifica sora-2-pro y describe parámetros como tamaño y duración, además de la posibilidad de usar una imagen de referencia. Eso permite plantear preguntas concretas al leer un resultado: ¿se usó texto a vídeo o imagen a vídeo?, ¿qué tamaño se solicitó?, ¿cuál fue la duración?, ¿se generó audio? La presencia de una opción documentada no demuestra que estuviera habilitada en un benchmark determinado; hace falta que el protocolo lo indique.

También conviene registrar la fecha porque los sistemas, las interfaces y las condiciones de acceso pueden cambiar. La página de cambios de Arena documenta incorporaciones de Sora 2 y Sora 2 Pro a su clasificación de texto a vídeo, pero el registro de una incorporación no describe por sí solo todos los detalles de generación ni garantiza que dos periodos de la clasificación sean directamente comparables.

Qué aporta una arena de preferencias

Una arena basada en preferencias suele presentar salidas para que alguien elija cuál prefiere, sin que el nombre del sistema determine deliberadamente la respuesta. En una comparación ciega, la elección ofrece evidencia sobre la preferencia bajo ese formato: qué clip gustó más a quienes participaron ante las muestras que vieron. Es una señal relevante para percepción humana, pero su interpretación debe mantenerse dentro de ese alcance.

La clasificación de texto a vídeo de Arena muestra Sora 2 Pro con una puntuación y un intervalo, junto con una fecha de corte indicada en la página. La forma responsable de comunicar ese dato es atribuirlo a esa clasificación y a esa instantánea, no describirlo como una medida universal de calidad. El intervalo expresa incertidumbre de la estimación según el método de la plataforma; no debe omitirse ni convertirse en una garantía de que un sistema será superior en cualquier prompt.

El método de ranking de Arena explica cómo se calcula y cómo se tratan la incertidumbre y los rangos. Aun así, para juzgar la solidez de una afirmación hay que revisar qué comparaciones entraron, cómo se asignaron, cuántas observaciones sostienen el resultado y qué población de prompts quedó representada. Si la página no ofrece todos esos detalles en la vista consultada, no se deben suplir con conjeturas.

Una preferencia ciega tampoco identifica por sí sola el motivo de la elección. Las personas pueden favorecer composición, estilo, legibilidad del movimiento o adecuación aparente al prompt, y esos factores pueden combinarse. El voto no equivale automáticamente a una rúbrica de seguimiento de instrucciones, continuidad temporal o sincronización audiovisual.

Por qué hacen falta benchmarks por dimensiones

Los benchmarks diseñados alrededor de tareas o dimensiones explícitas permiten preguntar qué aspecto se está evaluando. VBench, por ejemplo, organiza la evaluación de modelos de generación de vídeo en distintas dimensiones, entre ellas consistencia, parpadeo temporal y suavidad del movimiento. Video-Bench se presenta como un benchmark alineado con juicios humanos. Estos diseños ilustran alternativas a reducir la evaluación a una única preferencia global, pero no constituyen evidencia de que Sora 2 Pro haya obtenido un resultado concreto en ellos.

La ventaja de separar dimensiones es diagnóstica. Si una evaluación detecta una debilidad en consistencia temporal, eso no implica necesariamente que la calidad visual global sea baja; si una dimensión visual es fuerte, tampoco prueba que el modelo respete todos los detalles de una instrucción. Las medidas deben interpretarse según la definición y el procedimiento del benchmark, y una puntuación automática no debería equipararse sin más a una valoración humana.

La comparación con una arena puede ser complementaria. Una prueba por preferencias resume qué salida se elige bajo un protocolo, mientras que una batería por dimensiones intenta describir propiedades separadas. Ninguna es suficiente para todas las preguntas: la primera no ofrece automáticamente un diagnóstico causal y la segunda puede no reflejar qué clips prefieren las personas en una situación de uso determinada.

Comparabilidad: prompt, generaciones y selección de clips

Dos resultados solo son comparables si se sabe qué condiciones comparten. La modalidad de entrada es una primera diferencia: generar a partir de texto no plantea exactamente la misma tarea que animar una imagen de referencia. También deben considerarse la duración y el tamaño solicitados, la presencia o ausencia de audio y las restricciones aplicadas a cada sistema. La documentación de una interfaz puede confirmar qué parámetros admite, pero no cuáles usó el experimento.

El prompt es parte del protocolo, no un detalle editorial. Una colección de instrucciones sencillas, una lista de escenas complejas y un conjunto que exige acciones en un orden preciso pueden producir perfiles distintos. Si el benchmark no publica o describe las entradas, se limita la posibilidad de entender qué cubre la muestra y de repetirla.

El número de generaciones por prompt y la regla de selección son especialmente importantes. Si se crean varias salidas y se publica una elegida entre ellas, el resultado mide también el proceso de selección, no únicamente una generación individual. Para comparaciones justas hay que indicar si se mostró la primera salida, una salida seleccionada mediante una regla previa o una muestra obtenida de otro modo. Las fuentes aportadas no establecen una regla única aplicable a toda evaluación de Sora 2 Pro; debe verificarse caso por caso.

También puede cambiar la evaluación humana: quién vota, qué instrucciones recibe y qué elementos puede ver. Si se incluye audio, hay que especificar si el voto considera el sonido o solo la imagen. Si se usan evaluadores automáticos, el informe debería describir qué evalúan y cómo se validó su uso. Sin tales datos, un número puede seguir siendo informativo como resultado publicado, pero su alcance es más estrecho.

Límites de atribución: modelo, interfaz y configuración

Una evaluación no observa un modelo en abstracto: observa salidas obtenidas mediante un sistema y unas condiciones concretas. El resultado puede depender de la variante, de los parámetros, del modo de acceso, de la política de generación y de cualquier selección o procesamiento posterior. Si se comparan servicios con interfaces distintas, una diferencia no permite aislar automáticamente el efecto del modelo.

Por eso conviene distinguir tres niveles al redactar: el resultado observado («estas muestras recibieron estas preferencias»), la interpretación compatible («en esta prueba, bajo estas condiciones, una salida fue elegida con mayor frecuencia») y la afirmación general («el sistema es mejor»). El tercer nivel exige más evidencia que el primero y el segundo: tareas diversas, condiciones comparables y resultados que respalden la propiedad concreta que se atribuye.

Los repositorios de VBench y los trabajos de Video-Bench aportan referencias metodológicas para entender evaluaciones multidimensionales y sus artefactos. El repositorio de VBench reúne código, prompts, dimensiones, instrucciones de evaluación y enlaces a vídeos y configuraciones. Que existan materiales reproducibles para ese proyecto no significa que estén disponibles los prompts, las generaciones o la configuración de una evaluación de Arena. La reproducibilidad debe comprobarse para cada resultado por separado.

Reproducibilidad tras el cierre de la API

OpenAI informa que la API y los modelos Sora se apagarán el 24 de septiembre de 2026. Su documentación de ayuda distingue ese cierre del fin de las experiencias web y de la aplicación. Por tanto, no debe describirse el anuncio como si todas las formas de acceso cesaran necesariamente en el mismo momento. La fecha se refiere al cierre de la API según la documentación del proveedor; para cualquier reproducción futura habrá que comprobar las condiciones vigentes y el acceso efectivo.

La consecuencia metodológica es clara: un resultado archivado puede seguir siendo una observación útil aunque ya no sea posible solicitar una generación nueva con la misma configuración. Reproducir una puntuación a partir de clips almacenados tampoco equivale a repetir el experimento de generación. En el primer caso se puede volver a evaluar el material existente; en el segundo se requiere acceso a la generación, a la configuración y a las entradas originales.

Un informe histórico debería indicar qué se conserva: vídeos, prompts, parámetros, fecha, instrucciones de evaluación, resultados desglosados y procedimiento de agregación. Si solo queda una clasificación o una puntuación publicada, puede citarse como registro de esa página, pero no reconstruirse como una prueba completa. Las fuentes disponibles no confirman que todos esos artefactos existan para la clasificación de Sora 2 Pro; esa disponibilidad debe tratarse como una incertidumbre, no como un hecho.

Lista de comprobación para leer resultados sobre Sora 2 Pro

Antes de convertir una clasificación en una conclusión editorial o técnica, revisa qué afirmación respalda exactamente. El nombre del benchmark, la puntuación y la posición en una tabla no bastan si se desconocen la tarea, las muestras y el método. Una ficha incompleta sigue siendo citable con cautela, siempre que la omisión quede clara y no se atribuya al resultado una capacidad que no mide.

En particular, evita comparar directamente una clasificación de preferencias con una métrica de benchmark por dimensiones. Tampoco compares periodos de una misma arena sin comprobar sus cambios metodológicos, ni presentes resultados de modelos distintos como si hubieran recibido idénticos prompts, parámetros y oportunidades de generación cuando la fuente no lo documenta.

La conclusión más sólida que permiten las fuentes es metodológica: una preferencia puede indicar qué muestra gustó más dentro de un protocolo; una batería de tareas explícitas puede investigar propiedades delimitadas; y la reproducibilidad depende de artefactos y acceso que deben verificarse. Ninguna de esas piezas, por sí sola, autoriza una afirmación universal sobre la calidad de Sora 2 Pro.

Continúa explorando

Correcciones y transparencia

Si detectas un dato incorrecto o desactualizado, puedes enviarnos una corrección indicando la página y la fuente que debemos revisar.