Deriva con varias imágenes de referencia: separa composición y estilo
Trata cada imagen de referencia como una instrucción distinta. Esta guía explica cómo separar composición, sujeto y estilo, localizar dónde comienza la deriva y rechazar resultados atractivos que no respetan la estructura prevista.
Índice
Envías a una herramienta de generación una referencia de composición, otra de estilo y una imagen del sujeto. La solicitud termina sin errores, pero el resultado parece una ilustración genérica de banco: el sujeto cambia de sitio, desaparece el espacio reservado para el titular y varios estilos se funden en una estética indefinida de “imagen de IA”. No lo soluciones añadiendo más texto al prompt. Primero asigna una función concreta a cada referencia y después compara el resultado, punto por punto, con la composición que querías mantener.
En un informe público, un agente concatenó varias referencias de estilo dentro de un único parámetro plano. El modelo promedió las entradas y devolvió texturas genéricas sin producir un error de API. Ese caso aislado no demuestra un comportamiento universal, pero deja clara una distinción importante: una petición técnicamente correcta no equivale a una tarea visual bien resuelta.
Regla práctica: una imagen manda sobre la composición y otra sobre la apariencia
El cambio más útil consiste en dejar de tratar todas las imágenes como una lista de referencias equivalentes y sin explicar. Separa, como mínimo, estas tres funciones:
| Función de la referencia | Qué debe controlar | Qué no debe controlar |
|---|---|---|
| Referencia de composición | Número de sujetos, posición, escala relativa, cámara, encuadre y espacio negativo | Paleta, material, pincelada o estilo de iluminación |
| Referencia del sujeto | Identidad, forma y rasgos distintivos de una persona u objeto | Composición general u objetos de fondo no relacionados |
| Referencia de estilo | Paleta, textura, calidad de línea, grano, iluminación y lenguaje de renderizado | Objetos, texto o composición presentes en esa imagen |
Si la tarea solo necesita composición y estilo, utiliza únicamente esas dos imágenes. Añadir referencias no crea automáticamente más control; también puede introducir señales rivales que el sistema tendrá que reconciliar.
Por qué una lista plana suele producir un compromiso genérico
Una lista plana comunica que “todas estas imágenes importan”, pero no explica para qué sirve cada una. El modelo o el agente intermedio debe inferir la relación. Puede tomar el color de una imagen, la textura de otra y un objeto no deseado de una tercera, para acabar generando un compromiso visualmente plausible pero alejado del objetivo.
Este fallo puede ocurrir sin ningún error estructural. La autenticación, la subida, la sintaxis de la petición y el procesamiento de la respuesta pueden funcionar perfectamente. Por eso, un estado HTTP correcto o el mensaje “generation completed” no sirven como criterio visual de aceptación. El flujo necesita una revisión de composición después de generar.
Paso 1: escribe un contrato de función para cada referencia
Antes de redactar un prompt largo, responde cuatro preguntas sobre cada imagen:
- ¿Qué debe conservarse? Por ejemplo: el sujeto debe quedar abajo a la izquierda, la zona superior debe quedar libre para un titular y la cámara debe mantener un ángulo bajo.
- ¿Qué debe ignorarse? Por ejemplo: no copies la identidad de la persona, el texto de marca ni la arquitectura de fondo de la referencia de estilo.
- ¿Qué grado de rigidez tiene la regla? ¿La composición es obligatoria y el color solo una preferencia, o al revés?
- ¿Quién gana si las referencias entran en conflicto? Por ejemplo: la referencia de composición prevalece sobre cualquier colocación de objetos sugerida por la imagen de estilo.
Un contrato útil puede verse así:
| Archivo | Función | Conservar | Ignorar | Regla de conflicto |
|---|---|---|---|---|
layout.png | Composición | Dos sujetos con relación grande-pequeño, espacio libre a la derecha, vista cenital | Color y material | Sus relaciones espaciales prevalecen sobre las demás referencias |
subject.png | Sujeto | Silueta y detalles distintivos | Fondo y cámara originales | Sustituye el sujeto sin moverlo dentro de la composición |
style.png | Estilo | Paleta gris cálida, grano de papel, sombras suaves | Personas y texto de la imagen | Transfiere solo la apariencia; no copies el contenido |
Esto es más útil que “referencia 1, 2 y 3”, porque define tanto las señales deseadas como las transferencias prohibidas.
Paso 2: sustituye la lista plana por una petición jerárquica
Los campos reales de la API cambian según la herramienta. El siguiente bloque es una estructura conceptual, no un contrato real de ningún proveedor. Úsalo para comprobar si el agente conserva la información de función hasta la petición final:
references:
- id: layout
source: layout.png
role: composition
preserve: [subject_count, position, scale, camera, negative_space]
- id: subject
source: subject.png
role: identity
preserve: [shape, distinctive_details]
- id: style
source: style.png
role: appearance
preserve: [palette, texture, line_quality, lighting]
exclude: [objects, text, composition]
priority:
- layout
- subject
- style
acceptance_reference: layout.pngLa pregunta importante no es si tu API utiliza esos mismos nombres. La pregunta es si el significado sobrevive a toda la cadena. Inspecciona la petición que el agente envía de verdad: ¿el array de imágenes se convirtió en una sola cadena concatenada?, ¿las funciones se diluyeron en prosa general?, ¿un reintento o un proceso por lotes alteró el orden de los archivos?
Cuando la API de destino documente tipos de referencia separados, pesos o máscaras de edición, traduce el contrato de funciones a ese esquema. Cuando no lo haga, no inventes parámetros. Cambia a un flujo por etapas.
Paso 3: usa dos etapas si la herramienta no puede expresar funciones
Si la interfaz solo acepta un conjunto indiferenciado de imágenes, bloquea primero la composición y aplica después el estilo. Es más fácil diagnosticar dos transformaciones separadas que obligar a una sola petición a resolver todas las señales.
Etapa A: establece composición y sujeto
Usa la referencia de composición y añade la del sujeto solo cuando sea necesaria. Describe cantidad de sujetos, colocación, cámara, encuadre y espacio negativo. Deja fuera los materiales y el lenguaje de renderizado. El objetivo es conseguir una imagen estructuralmente correcta, aunque todavía resulte sencilla.
Etapa B: aplica la apariencia sin reconstruir la escena
Usa el resultado de la etapa A como nueva base y edítalo o redibújalo con la referencia de estilo. Indica que deben permanecer fijos la posición y los límites de los sujetos, la cámara, el encuadre y el espacio negativo; solo pueden cambiar la paleta, la textura, la calidad de línea y la iluminación.
Si la herramienta admite máscaras, expón únicamente las zonas que necesitan modificación. Sin modo de edición, mantén la imagen de la etapa A como referencia principal y la de estilo como secundaria. La disponibilidad de pesos explícitos depende de la documentación vigente de cada herramienta.
Paso 4: ejecuta cuatro variantes controladas para localizar la señal perdida
No sigas modificando una petición compleja de forma acumulativa. Mantén constantes el prompt, las dimensiones y las demás opciones controlables, y genera cuatro variantes:
| Prueba | Entrada | Qué debes revisar |
|---|---|---|
| A | Solo referencia de composición | ¿Conserva número de sujetos, posiciones, cámara, encuadre y espacio negativo? |
| B | Solo referencia de estilo | ¿Qué rasgos de paleta, textura, línea e iluminación transfiere realmente? |
| C | Composición y estilo como lista plana | ¿Crea un compromiso, promedia estilos o introduce contenido no deseado? |
| D | Composición y estilo con funciones y prioridad explícitas | ¿Cada objetivo queda más cerca que en la prueba C? |
Esto no decide si un modelo es “bueno” o “malo”. Sirve para descubrir si la avería comienza al interpretar una sola imagen, al combinar varias o al transformar los parámetros dentro del agente. Si A y B funcionan, C deriva y D mejora, la ambigüedad de funciones es una sospecha razonable. Si D se parece a C, inspecciona el payload final o utiliza el método por etapas.
Cuando exista un parámetro seed, mantenlo constante para reducir la variación aleatoria. Cuando no exista, no presentes la comparación como determinista; genera varias muestras por variante y busca fallos estructurales que se repitan.
Paso 5: acepta contra la composición objetivo, no porque “se ve bien”
El resultado peligroso no siempre es feo. Puede estar lo bastante pulido como para superar una revisión rápida y, aun así, incumplir la plantilla. Comprueba primero las restricciones duras y solo después evalúa el estilo.
Restricciones duras: descarta el candidato si falla una sola
- El número de sujetos es correcto.
- Sus posiciones y escala relativa coinciden con el diseño.
- La dirección de cámara, el encuadre y el punto de vista son correctos.
- Se mantiene el espacio reservado para texto o el espacio negativo.
- No se han filtrado objetos, personas o texto de la referencia de estilo.
- Los rasgos distintivos del sujeto siguen siendo reconocibles.
Restricciones blandas: úsalas para ordenar los candidatos que sobrevivan
- La paleta está cerca del objetivo.
- La textura y el grano parecen intencionados, no embarrados.
- Las líneas, bordes y sombras encajan con el lenguaje visual deseado.
- El resultado es coherente en lugar de parecer un promedio de varios estilos.
Coloca la referencia de composición junto a cada candidato y registra un aprobado o suspenso para cada restricción dura. No guardes solo la imagen final: conserva también la versión de la petición, el orden de referencias y el payload exacto enviado por el agente. Esa evidencia permite reproducir la siguiente deriva.
Diagnostica los síntomas habituales en el orden correcto
| Síntoma | Qué revisar primero | Respuesta preferida |
|---|---|---|
| El estilo es fuerte, pero cambia la composición | ¿La imagen de estilo se trató como referencia principal equivalente? | Da prioridad al diseño o divide composición y estilo en etapas |
| La composición es correcta, pero el estilo es débil | ¿El prompt usa solo palabras abstractas de ambiente? | Describe rasgos observables de paleta, material, línea e iluminación |
| Varios estilos se funden en un aspecto genérico | ¿Incluiste juntas imágenes de estilo incompatibles? | Elige una dominante y asigna a las demás un único rasgo concreto |
| Aparece el sujeto de la imagen de estilo | ¿Indicabas que solo debía transferirse la apariencia? | Excluye expresamente sus objetos, texto y composición |
| Los cambios del prompt no se reflejan | ¿El agente envió realmente los parámetros nuevos? | Compara los payloads finales, no solo el formulario anterior |
| La API tiene éxito, pero el resultado sigue derivando | ¿Usas el estado técnico como aceptación visual? | Añade puertas duras de composición y comparaciones controladas |
Flujo mínimo reutilizable
- Selecciona únicamente las referencias necesarias para completar la tarea.
- Asigna a cada imagen una función principal y reglas de conservar, ignorar y resolver conflictos.
- Revisa la petición final para confirmar que arrays, orden y funciones no se aplanaron.
- Ejecuta líneas base solo de composición y solo de estilo antes de comparar la lista plana con las funciones separadas.
- Descarta por restricciones duras de composición antes de comparar el estilo.
- Guarda juntos candidatos, referencias, versiones de petición y resultados de aceptación.
- Si la interfaz no puede representar funciones, trabaja primero la composición y después el estilo.
El objetivo no es escribir un prompt más largo. Es construir un flujo en el que cada señal visual tenga un responsable. Mientras puedas responder “qué imagen controla este atributo, qué regla gana un conflicto y qué significa aprobar”, varias referencias dejan de ser un montón de imágenes que el modelo debe interpretar por su cuenta.
