Stable Diffusion 3.5 Large bajo prueba: cómo medir el seguimiento de prompts

Qué pregunta responde este benchmark

Una evaluación de seguimiento de prompts pregunta si una imagen generada contiene los elementos que la instrucción solicita y si estos aparecen con los atributos y las relaciones indicados. No responde, por sí sola, si el resultado es bello, original o adecuado para cualquier uso. Tampoco permite declarar un modelo «mejor» en términos universales: describe su comportamiento bajo un conjunto de tareas, una configuración y un método de puntuación concretos.

Para Stable Diffusion 3.5 Large, la pregunta práctica podría ser: ¿con qué frecuencia las generaciones respetan requisitos verificables como incluir tres objetos, situar uno a la izquierda de otro o mostrar una palabra determinada? La comparación propuesta con Stable Diffusion 3.5 Medium debe entenderse como una prueba nueva. En las fuentes disponibles aquí no hay resultados cuantitativos verificados ni un protocolo completo que permitan presentar una clasificación ya establecida.

La información de una página de modelo, una receta de software o una demostración visual puede ayudar a identificar una implementación o a ponerla en marcha. No sustituye una evaluación controlada. Por tanto, este artículo describe cómo producir y comunicar evidencia; no atribuye a Large ni a Medium una puntuación de seguimiento de prompts.

Qué está verificado y qué sigue sin saberse

La comunicación de Stability AI anuncia la disponibilidad de Stable Diffusion 3.5 Large y de código de inferencia. La tarjeta alojada bajo el espacio de Stability AI en Hugging Face identifica Large como un modelo de texto a imagen y lo describe como un Multimodal Diffusion Transformer. Estos datos sirven para reconocer el modelo y su procedencia, pero los fragmentos disponibles no ofrecen mediciones de seguimiento de instrucciones.

La documentación de Amazon Bedrock describe una oferta de SD 3.5 Large con ocho mil millones de parámetros y salida de un megapíxel. Es un dato referido a esa documentación y a la configuración de esa plataforma; no debe trasladarse automáticamente a cualquier implementación ni interpretarse como evidencia de calidad. Una receta de vLLM menciona una variante Medium de 2,5 mil millones de parámetros y Large de 8,1 mil millones dentro de la familia, pero identificar esos tamaños tampoco demuestra cuál variante sigue mejor un prompt.

El repositorio de Stability AI se presenta como una implementación de referencia centrada en inferencia. La existencia de código facilita inspeccionar una vía de ejecución, pero no determina por sí misma los parámetros adecuados para una comparación. Asimismo, las pruebas informales compartidas en Reddit son experiencias anecdóticas: pueden sugerir casos para investigar, no sustituir un conjunto de prueba con criterios fijados de antemano.

La conclusión metodológica es limitada pero importante: con la evidencia aportada no se puede afirmar qué modelo obtiene mejores resultados en seguimiento de prompts, qué diferencia existe entre Large y Medium ni qué configuración produjo resultados comparables. La ausencia de esos datos en este conjunto de fuentes tampoco demuestra que no existan evaluaciones publicadas en otros lugares; significa que no se deben atribuir resultados que aquí no se han verificado.

Diseñar prompts que permitan comprobar requisitos

El conjunto de evaluación debe descomponer el seguimiento en dimensiones observables, en lugar de depender de una impresión general. Conviene incluir presencia de objetos, cantidad, relaciones espaciales, atributos visuales y texto solicitado. Cada prompt ha de especificar qué requisito se evaluará y qué cuenta como cumplimiento antes de generar las imágenes. Si una frase admite interpretaciones distintas, debe reescribirse o etiquetarse como ambigua, no resolverse después de ver el resultado.

La selección debería cubrir casos sencillos y combinaciones más exigentes. Por ejemplo, un prompt puede pedir dos tazas; otro, una taza roja a la izquierda de un libro azul; otro, una escena con una etiqueta cuya palabra debe ser legible. Estos son ejemplos de diseño del protocolo, no resultados atribuidos a los modelos. Las instrucciones deben evitar detalles irrelevantes que hagan difícil decidir qué requisito falló.

Es útil equilibrar las categorías y registrar su composición. Si hay muchos prompts de presencia de objetos y pocos de texto, una puntuación global puede ocultar un desempeño dispar. También deben definirse exclusiones de antemano: por ejemplo, si el texto se evaluará solo cuando sea claramente visible o si se admitirá una variación tipográfica. No se deben eliminar prompts porque produzcan imágenes incómodas para una conclusión esperada.

Fijar las condiciones de ejecución

Antes de generar, se debe registrar la identificación exacta del modelo y de los pesos, junto con la versión del software, la implementación y cualquier modificación del pipeline. También han de publicarse resolución, número de pasos, parámetros de guía, precisión numérica, hardware y opciones de aceleración. Si una plataforma oculta parte de esa información, hay que decirlo y limitar las conclusiones en consecuencia.

La semilla y el número de generaciones por prompt deben quedar documentados. Una única imagen por instrucción puede hacer que una variación aleatoria domine el resultado; varias generaciones permiten observar esa variabilidad, aunque aumentan el coste. El protocolo debe determinar cuántas muestras se producirán antes de inspeccionar los resultados y aplicar el mismo criterio a ambos modelos. Para que la comparación sea interpretable, también conviene indicar si las semillas se emparejaron entre modelos y qué significa ese emparejamiento en las implementaciones usadas.

No basta con declarar una resolución o un número de pasos si Large y Medium se ejecutan con pipelines distintos. La comparación más limpia conserva los parámetros que puedan compartirse y publica toda diferencia inevitable. Si las limitaciones de memoria obligan a cambiar precisión, tamaño de lote u otras opciones, esas diferencias forman parte de la descripción y pueden impedir atribuir el resultado exclusivamente al modelo.

Puntuar requisitos y usar evaluadores a ciegas

La unidad principal de puntuación debería ser el requisito verificable. Para cada imagen, los evaluadores pueden marcar si el objeto está presente, si la cantidad coincide, si el atributo solicitado aparece, si la relación espacial se cumple y si el texto puede leerse y coincide. Una escala binaria facilita el recuento, aunque una categoría adicional de «no evaluable» puede ser necesaria para imágenes corruptas o instrucciones realmente ambiguas. Las reglas para usarla deben fijarse antes de revisar los resultados.

La evaluación humana debe ocultar qué modelo generó cada imagen y mezclar el orden de presentación. Los evaluadores necesitan instrucciones comunes, ejemplos de aplicación de la rúbrica y una forma de registrar dudas. Conviene emplear más de una persona y publicar tanto el acuerdo como los desacuerdos; si estos son frecuentes, la definición del requisito puede ser insuficiente. No debe resolverse un desacuerdo de forma silenciosa ni presentarse el consenso como certeza absoluta.

Las métricas automáticas pueden servir como apoyo, no como sustituto universal del juicio sobre todos los requisitos. Antes de utilizarlas, hay que explicar qué miden, en qué casos se aplican y cómo se han comprobado frente a una muestra revisada por personas. Una medida global de similitud no demuestra por sí sola que haya exactamente tres objetos, que uno esté a la izquierda de otro o que una palabra se lea correctamente. Cuando una métrica no esté validada para una dimensión, el informe debe indicarlo en vez de tratarla como árbitro.

Comparar Large con Medium sin atribuciones indebidas

La comparación debe partir del mismo conjunto de prompts y la misma rúbrica. En la medida en que las implementaciones lo permitan, se deben igualar resolución, número de generaciones, parámetros de inferencia y condiciones de evaluación. Para cada requisito, conviene presentar resultados por modelo y categoría, con cantidades de muestras y una descripción de la variabilidad, no solo un promedio general.

La igualdad de valores en una tabla de parámetros no garantiza que las ejecuciones sean equivalentes si cambian el pipeline, la precisión, las opciones de muestreo o el software. Por ello, todo desajuste debe quedar visible. Si no puede controlarse una diferencia importante, el informe debe describirlo como comparación entre dos configuraciones completas, no como prueba aislada de que el tamaño o la variante del modelo causó el resultado.

No se deben rellenar con valores supuestos los campos que aún no se hayan ejecutado. El informe puede publicar el protocolo previsto y dejar el resultado como pendiente. Cuando se disponga de datos, cada conclusión deberá enlazarse con el conjunto, la configuración y la rúbrica que la sustentan. La evaluación propuesta no permite anticipar si Large superará a Medium en seguimiento de instrucciones.

Contaminación, selección de muestras y límites

Un benchmark puede estar sesgado si los prompts son públicos, se han utilizado repetidamente en demostraciones o guardan semejanza con ejemplos vistos durante el desarrollo del sistema. Sin acceso a información sobre los datos de entrenamiento, no siempre es posible confirmar o descartar exposición previa. El equipo evaluador puede reducir riesgos mediante prompts redactados para la prueba, acceso restringido hasta su ejecución y publicación posterior del conjunto, pero debe describir estas medidas como controles parciales, no como prueba de ausencia de contaminación.

También hay sesgo si se escogen y muestran solo las imágenes más convincentes. Para evitarlo, deben conservarse todas las generaciones previstas y definir de antemano las reglas de exclusión. Las galerías de ejemplos pueden ilustrar fallos o aciertos, pero no reemplazan los recuentos completos. Una sola semilla, una selección manual posterior o una categoría con muy pocos casos puede producir una impresión engañosa.

La rúbrica incorpora decisiones humanas: qué se considera una relación espacial suficiente, cuándo un texto es legible o cuánto detalle cuenta como atributo cumplido. Por eso se necesitan definiciones operativas, evaluación independiente y reporte de desacuerdos. Los resultados no deben combinarse sin más con puntuaciones de otros conjuntos, configuraciones o métodos: si las tareas y las reglas de medición difieren, la cifra no necesariamente representa el mismo fenómeno.

Lista de reproducción del benchmark

Una evaluación útil debe permitir que otra persona repita el procedimiento y entienda sus límites, incluso si no obtiene imágenes idénticas. El material publicado debería incluir prompts, criterios de inclusión y exclusión, semillas, número de generaciones, versiones y configuraciones, además de las imágenes o una explicación clara de por qué no se distribuyen. También debe incluir la rúbrica, los formularios de evaluación, el método de cegamiento y los resultados desglosados por dimensión.

El informe debería separar hechos observados, decisiones metodológicas e interpretaciones. Por ejemplo, un recuento de respuestas de evaluadores es un resultado de la ejecución; la definición de «relación espacial cumplida» es una decisión de rúbrica; afirmar que una diferencia se debe al modelo es una interpretación que requiere condiciones comparables y evidencia suficiente. Esta separación ayuda a que quien consulte la evaluación no confunda una recomendación de protocolo con un resultado ya medido.

Hasta que se publique y reproduzca una prueba de este tipo, lo responsable es presentar Stable Diffusion 3.5 Large y Medium como variantes que requieren evaluación bajo condiciones explícitas, no como ganadores o perdedores de un benchmark de seguimiento de prompts. El índice de benchmarks puede servir como contexto editorial, y la ficha de evaluación de SD 3.5 Large como referencia de la prueba, siempre que sus resultados pendientes no se describan como mediciones. La conclusión práctica es sencilla: publicar el método antes de interpretar las imágenes y publicar los datos junto con cualquier puntuación.

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.