Problema
Los equipos creativos suelen evaluar un modelo de imagen con una galería: varios prompts, resultados llamativos y una conversación sobre cuál parece más avanzado. Esa prueba favorece la novedad visual, pero dice poco sobre el trabajo que llegará el lunes.
En producción, una imagen falla de formas distintas. Puede alterar un producto que debía preservar, editar una zona y contaminar el resto, romper una jerarquía, introducir texto inutilizable o tardar demasiado para un flujo de variantes. Dos modelos pueden producir piezas atractivas y tener perfiles de error incompatibles con la misma operación.
OpenAI documenta GPT Image 2.5 como una familia con dos variantes. Sunburst se orienta a máxima capacidad y precisión de edición. Flare se orienta a generación cotidiana rápida con alta calidad. La existencia de ambas elimina una excusa habitual: ya no hay que escoger «el modelo nuevo», sino decidir qué clase de fallo cuesta más en cada tarea.
Tesis
Un modelo creativo debe elegirse por la distribución de errores que el workflow puede tolerar, detectar y corregir.
Sunburst y Flare no forman necesariamente una clasificación lineal. Sus descripciones oficiales plantean roles diferentes. En una adaptación de packaging, preservar la referencia y localizar el cambio puede dominar la decisión. En exploración de conceptos o variantes de bajo riesgo, la velocidad puede pesar más. La selección correcta depende del contrato del activo.
El benchmark útil no pregunta qué imagen gana. Pregunta qué modelo falla menos en el criterio que bloquea publicación y cuánto cuesta descubrir ese fallo.
Framework
La evaluación debe clasificar errores antes de comparar resultados:
- Preservación: cambia identidad, producto, personaje o composición que debían mantenerse.
- Localización: una edición solicitada altera zonas que estaban fuera de alcance.
- Instrucción: omite una restricción, mezcla prioridades o añade elementos no pedidos.
- Legibilidad: degrada texto, jerarquía o información que debe sobrevivir al formato final.
- Operación: la latencia, el consumo o la revisión hacen inviable el volumen requerido.
OpenAI Docs indica que ambas variantes aceptan texto e imagen, generan y editan, admiten inpainting y pueden utilizarse mediante la Image API o como herramienta dentro de Responses. La guía diferencia también dos formas de integración: una operación directa para generar o editar una imagen y un flujo conversacional para iterar manteniendo contexto.
Eso permite diseñar routing por tarea. Un flujo puede usar Flare para explorar rutas y reservar Sunburst para ediciones donde la precisión sea el gate. También puede descubrir lo contrario en un corpus concreto. La documentación orienta la hipótesis; solo las pruebas del equipo autorizan la regla.
Por qué importa ahora
La generación visual está entrando en pipelines, no solo en sesiones individuales. Una misma campaña puede necesitar conceptos, adaptación de formatos, localización, retoque y versiones para distintos canales. Elegir un único modelo por defecto traslada su perfil de error a toda la cadena.
Las opciones de calidad tampoco resuelven por sí solas el problema. Subir el nivel de render no garantiza mejor preservación, menor contaminación de una edición o una jerarquía más correcta. Calidad técnica y adecuación al contrato son variables distintas.
Cuando la imagen forma parte de una conversación en Responses, el historial facilita refinamientos sucesivos. Esa continuidad también puede acumular deriva. El equipo necesita decidir cuándo seguir editando, cuándo volver a una referencia limpia y cuándo una nueva generación deja de ser la misma pieza.
Anti-ejemplo
Una marca prueba ambos modelos con prompts diferentes, selecciona las imágenes más espectaculares y declara un ganador. Después utiliza ese modelo para conceptos, producto, adaptaciones y retoque.
Los primeros fallos aparecen tarde: un detalle del producto cambia entre formatos, una edición modifica el fondo aprobado y el texto necesita corrección manual. El equipo culpa al prompt y añade instrucciones. La complejidad crece, pero nunca se midió el error que importaba.
El problema no era falta de calidad. Era una evaluación sin corpus común, sin taxonomía y sin criterio de cierre.
Protocolo (3 pasos)
| Paso | Decisión | Evidencia mínima |
|---|---|---|
| Construir | Reunir briefs y referencias representativos del trabajo real | Corpus versionado con activos de riesgo alto y bajo |
| Evaluar | Ejecutar modelos y ajustes con entradas equivalentes | Revisión ciega etiquetada por tipo y gravedad de error |
| Enrutar | Asignar modelo, API y nivel de revisión por tarea | Regla operativa con fallback y fecha de reevaluación |
No agregues todos los errores en una puntuación única demasiado pronto. Una media puede ocultar un fallo raro que invalida una pieza regulada o un defecto frecuente que el equipo corrige con poco esfuerzo. Conserva el perfil por tarea y decide con el coste de error, no con el promedio estético.
Relacionado
- Gemini Omni y Google Flow: dirección creativa después del output
- Creative Ops as System: producción de marca sin perder criterio
- Magnific y la creatividad como infraestructura
Fuentes consultadas
- OpenAI Docs — GPT-Image-2.5 Sunburst
- OpenAI Docs — GPT-Image-2.5 Flare
- OpenAI Docs — Image generation
Próximo paso
Selecciona activos que representen tus errores más caros y ejecútalos con entradas equivalentes en Sunburst y Flare. Etiqueta cada fallo antes de discutir preferencias. La decisión correcta no será el modelo que produzca la imagen más novedosa, sino el que encaje mejor en un loop de producción que sabe detectar, corregir y aprender.