Personajes consistentes en Gemini API: una prueba con 18 imágenes mostró que un prompt básico altera la ropa

Si haces vídeos o anuncios con los mismos personajes, conocerás el problema: en la tercera imagen, la protagonista ya no se parece a sí misma, y dos personajes que comparten escena intercambian de pronto sus rostros o su ropa. Un autor de Habr explicó cómo abordar este problema con Gemini API y puso a prueba sus técnicas con un pequeño experimento.

Por qué cambia el rostro

El generador no tiene memoria entre solicitudes. Cada llamada construye la imagen desde cero a partir del texto y las imágenes adjuntas. Por tanto, la consistencia del personaje debe garantizarse desde el cliente.

El autor propone cuatro elementos:

• Ficha: un bloque de texto fijo que describe el aspecto y se inserta en cada prompt sin cambiar un solo byte. Solo incluye características invariables: edad, pelo, ojos y rasgos distintivos. No debe incluir la sonrisa ni la ropa; de lo contrario, la sonrisa aparecerá en todas las imágenes.
• Referencia base: un retrato de frente sobre fondo gris, con iluminación uniforme y expresión neutra. Se adjunta como referencia en cada solicitud.
• Vistas: de frente, de tres cuartos, de perfil y de espaldas. Cada vista se genera en una solicitud independiente que recibe la referencia base. Cuando el autor pidió las cuatro vistas en una sola imagen, el modelo giró la cabeza hacia la izquierda y los pies hacia la derecha.
• Revisión visual de cada imagen a tamaño completo.

La parte técnica es sencilla: en generateContent, las imágenes se envían como inlineData en el mismo array parts que el texto. El orden de los elementos determina el orden de las imágenes al que hace referencia el prompt. Conviene definir la relación de aspecto con el parámetro imageConfig.aspectRatio: indicarla en el prompt sirve de orientación, mientras que el parámetro sí se aplica.

La prueba: dos personajes en la imagen

El autor utilizó gemini-3.1-flash-image y dos parejas de personajes: una mujer y un hombre, y dos mujeres de aspecto claramente distinto. Probó tres variantes del prompt, con tres generaciones por pareja, hasta sumar 18 generaciones:

1. Básico: «estos dos se encuentran en una cafetería», sin roles ni rasgos distintivos.
2. Con roles: quién está sentado, quién está de pie y quién está a la izquierda. Las imágenes no están numeradas.
3. Con numeración: «Image 1 es la mujer: …», «Image 2 es el hombre: …», con los rasgos descritos por escrito y una prohibición explícita de mezclar los rostros.

Los rostros no se intercambiaron ni una vez y nadie se sentó de espaldas. Las diferencias aparecieron en los detalles. Con el prompt básico, en una de las tres generaciones la protagonista apareció con una chaqueta oscura y una pulsera de oro que no estaban en la referencia, y parecía mayor. En otra generación apareció el texto «EVENING SPECIALS» en la pizarra de la cafetería. La variante con roles mantuvo los rostros y la ropa en 6 de 6 generaciones, pero en dos aparecieron letreros en el fondo, aunque el prompt incluía no text. La variante con numeración produjo 6 de 6 generaciones sin errores ni textos.

La conclusión principal: el riesgo del prompt básico no está en el intercambio de rostros, sino en que la ropa y los accesorios se aparten de la referencia. Tres generaciones por variante son una muestra pequeña y no permiten calcular «un N por ciento menos de errores». Además, la comparación no es perfecta: la hora del día varía entre los prompts básicos y no text solo figuraba en los prompts con roles. El autor no probó con dos personajes parecidos, por ejemplo, dos hombres de pelo oscuro y traje.

Vídeo y Omni

Para el vídeo, el autor utiliza gemini-omni-1.1-flash a través de Interactions API. La función de cada imagen se indica mediante etiquetas directamente en el texto: <FIRST_FRAME> para el primer fotograma y <IMAGE_REF_n> para las referencias base de los personajes. El procedimiento es el siguiente: primero crear y revisar una imagen con los dos personajes, después proporcionarla como primer fotograma y añadir las imágenes base como referencias.

El modelo decide por sí mismo dónde queda cada personaje. Ante la petición «se sienta enfrente», el personaje se sentó al lado porque estaba de pie a un costado. Si la posición importa, hace falta un primer fotograma en el que los personajes ya estén sentados, de modo que en el vídeo solo quede por desarrollar la acción.

gemini-omni-1.2-flash está disponible desde el 5 de noviembre y, a partir del 3 de diciembre, las solicitudes a 1.1 se redirigirán a ella. En esta versión, la duración pasó a ser un parámetro (de 3 a 15 segundos) y el precio por segundo a 720p bajó de $0,10 a $0,07. Sin embargo, en una prueba no funcionaron las etiquetas del primer y el último fotograma. Se resolvió con una frase directa al principio del prompt: «The video starts exactly on the first image and ends exactly on the second image». No se probó en 1.2 la variante con un solo FIRST_FRAME e IMAGE_REF.

Qué hacer en la práctica

• Mantén la ficha del personaje como una constante en el código, en lugar de redactarla de nuevo cada vez.
• Para las escenas con dos personajes, numera las imágenes y enumera sus rasgos distintivos. Solo requiere un par de líneas y hace que el prompt sea inequívoco.
• No te fíes de no text: revisa el fondo; en un anuncio, un letrero detrás del personaje será lo primero que salte a la vista.
• Reúne las generaciones en una hoja de contactos y amplía las imágenes sospechosas. El autor solo detectó la chaqueta y la pulsera al verlas junto a las generaciones sin errores.

En cuanto al coste, una imagen 1K cuesta alrededor de $0,067, la prueba completa de 18 imágenes ronda los $1,21 y un clip de 6 segundos con Omni 1.1 costó $0,63.