Personnage constant dans l'API Gemini : un test sur 18 images montre qu'un prompt nu fait dériver les vêtements

Si vous réalisez des vidéos ou des publicités avec les mêmes héros, le problème principal vous est familier : au troisième plan, l'héroïne ne se ressemble déjà plus, et deux personnages dans la même scène échangent soudain leurs visages ou leurs vêtements. Un auteur de Habr a étudié comment y remédier via l'API Gemini et a vérifié ses méthodes par un petit test.

Pourquoi le visage dérive

Le générateur n'a aucune mémoire entre les requêtes. Chaque appel reconstruit l'image à partir du texte et des images jointes. La constance du héros doit donc être assurée côté client.

L'auteur propose quatre éléments :

• Fiche signalétique : un bloc de texte figé décrivant l'apparence, inséré octet pour octet dans chaque prompt. On n'y met que l'invariable : âge, cheveux, yeux, signes distinctifs. Il ne faut y écrire ni sourire ni vêtements, sinon le sourire apparaîtra sur chaque image.
• Référence : un portrait de face sur fond gris, lumière uniforme, visage neutre. Il est joint comme référence à chaque requête.
• Vues : face, trois quarts, profil, dos. Chaque vue est générée par une requête distincte avec la référence en entrée. Quand l'auteur a demandé les quatre vues sur une seule image, le modèle a tourné la tête vers la gauche et les pieds vers la droite.
• Vérification de chaque image à l'œil, en taille réelle.

Techniquement, c'est simple : dans generateContent, les images sont transmises en inlineData dans le même tableau parts que le texte. L'ordre des parties est l'ordre des images auquel le prompt fait référence. Il vaut mieux définir le format avec le paramètre imageConfig.aspectRatio : la mention dans le prompt reste une suggestion, alors que le paramètre est appliqué.

Le test : deux personnages dans le cadre

L'auteur a pris gemini-3.1-flash-image et deux paires de héros : une femme et un homme, puis deux femmes nettement différentes. Trois variantes de prompt, trois prises par paire, soit 18 générations au total :

1. Nu : « ces deux-là se retrouvent dans un café », sans rôles ni signes distinctifs.
2. Avec rôles : qui est assis, qui est debout, qui est à gauche. Pas de numérotation des images.
3. Avec numérotation : « Image 1 est la femme : … », « Image 2 est l'homme : … », signes distinctifs en toutes lettres et interdiction explicite de mélanger les visages.

Les visages ne se sont jamais intervertis et personne ne s'est assis dos tourné. La différence se trouvait dans les détails. Dans le prompt nu, l'héroïne portait, dans une prise sur trois, une veste sombre et un bracelet en or absents de la référence, et paraissait plus âgée. Dans une autre prise, l'inscription « EVENING SPECIALS » est apparue sur le tableau du café. La variante avec rôles a conservé visages et vêtements dans 6 prises sur 6, mais dans deux prises, des enseignes figuraient à l'arrière-plan, bien que le prompt contienne no text. La variante avec numérotation a donné 6 sur 6 sans erreur et sans inscriptions.

Principale conclusion : le risque du prompt nu n'est pas l'échange de visages, mais la dérive des vêtements et accessoires par rapport à la référence. Trois prises par variante, c'est un petit échantillon, et l'on ne peut pas en tirer un « moins N % d'erreurs ». De plus, la comparaison est imparfaite : le moment de la journée diffère dans les prompts nus, et no text n'était présent que dans les prompts avec rôles. L'auteur n'a pas testé deux héros semblables, par exemple des bruns en costume.

Vidéo et Omni

Pour la vidéo, l'auteur utilise gemini-omni-1.1-flash via l'API Interactions. Les rôles des images sont définis par des balises directement dans le texte : <FIRST_FRAME> pour la première image et <IMAGE_REF_n> pour les références des héros. L'ordre qui fonctionne : d'abord composer et vérifier l'image avec les deux héros, puis la fournir comme première image, et ajouter les références des héros.

Le modèle décide lui-même qui se retrouve où. À la demande « s'assoit en face », le héros s'est assis à côté, parce qu'il se tenait sur le côté. Si la disposition compte, il faut une première image où les personnages sont déjà assis, et la vidéo ne contient plus que l'action.

Depuis le 5 novembre, gemini-omni-1.2-flash est disponible, et à partir du 3 décembre les requêtes vers la 1.1 seront redirigées vers elle. La durée y devient un paramètre (de 3 à 15 secondes), et la seconde en 720p est passée de 0,10 $ à 0,07 $. Mais dans un test, les balises de première et dernière image n'ont pas fonctionné. Une phrase directe au début du prompt a aidé : « The video starts exactly on the first image and ends exactly on the second image ». La variante avec un seul FIRST_FRAME et IMAGE_REF n'a pas été testée sur la 1.2.

Que faire en pratique

• Gardez la fiche du héros comme constante dans le code, et non comme un texte réécrit à chaque fois.
• Pour les scènes à deux héros, numérotez les images et listez les signes distinctifs. Cela coûte quelques lignes et rend le prompt univoque.
• Ne vous fiez pas à no text : regardez l'arrière-plan, l'enseigne derrière le héros d'une publicité apparaîtra en premier.
• Assemblez les prises en planche-contact et agrandissez les images suspectes. L'auteur n'a remarqué la veste et le bracelet qu'à côté des prises propres.

Côté coûts, une image 1K coûte environ 0,067 $, le test complet de 18 images environ 1,21 $, et un clip de 6 secondes sur Omni 1.1 est revenu à 0,63 $.