Personagem consistente na Gemini API: teste com 18 imagens mostrou que um prompt básico faz a roupa fugir da referência

Quem produz vídeos ou anúncios com os mesmos personagens conhece o problema: na terceira imagem, a protagonista já não se parece consigo mesma, e duas pessoas na mesma cena de repente trocam de rosto ou de roupa. Um autor do Habr explicou como lidar com isso pela Gemini API e avaliou suas técnicas em um pequeno teste.

Por que o rosto muda

O gerador não tem memória entre as requisições. Cada chamada monta a imagem do zero, a partir do texto e das imagens anexadas. Portanto, cabe ao cliente garantir a consistência do personagem.

O autor propõe quatro elementos:

• Ficha: um bloco fixo de texto que descreve a aparência e entra em todos os prompts, byte por byte. Ele deve conter apenas características que não mudam: idade, cabelo, olhos e traços distintivos. Não se deve incluir sorriso nem roupa; caso contrário, o sorriso aparecerá em todas as imagens.
• Referência: um retrato de frente, com fundo cinza, iluminação uniforme e expressão neutra. Ele acompanha todas as requisições como referência.
• Ângulos: de frente, em três quartos, de perfil e de costas. Cada vista é gerada em uma requisição separada, com a imagem de referência como entrada. Quando o autor pediu os quatro ângulos em uma única imagem, o modelo virou a cabeça para a esquerda e os pés para a direita.
• Inspeção visual de cada imagem em tamanho original.

Tecnicamente, é simples: em generateContent, as imagens são enviadas como inlineData no mesmo array parts que contém o texto. A ordem das partes define a ordem das imagens às quais o prompt se refere. É melhor definir a proporção pelo parâmetro imageConfig.aspectRatio: uma instrução no prompt continua sendo uma sugestão, enquanto o parâmetro é respeitado.

Teste: duas pessoas na cena

O autor usou gemini-3.1-flash-image e dois pares de personagens: uma mulher e um homem, além de duas mulheres com aparências bem diferentes. Foram três versões de prompt, com três gerações por par, totalizando 18 gerações:

1. Básico: “essas duas pessoas se encontram em um café”, sem definir papéis nem traços distintivos.
2. Com papéis definidos: quem está sentado, quem está em pé, quem fica à esquerda. As imagens não são numeradas.
3. Com numeração: “Image 1 é a mulher: …”, “Image 2 é o homem: …”, com os traços descritos por escrito e uma proibição explícita de misturar os rostos.

Os rostos não foram trocados nenhuma vez, e ninguém se sentou de costas. A diferença apareceu nos detalhes. Com o prompt básico, em uma das três gerações, a personagem ganhou uma jaqueta escura e uma pulseira de ouro que não constavam na referência, além de parecer mais velha. Em outra geração, surgiu o texto “EVENING SPECIALS” no quadro do café. A versão com papéis definidos preservou rostos e roupas em 6 de 6 gerações, mas duas delas tinham letreiros ao fundo, embora o prompt incluísse no text. A versão com numeração entregou 6 de 6 gerações sem erros e sem textos na imagem.

A principal conclusão: o risco do prompt básico não está na troca de rostos, mas no desvio de roupas e acessórios em relação à referência. Três gerações por versão formam uma amostra pequena, que não permite calcular “N por cento menos erros”. Além disso, a comparação não é ideal: o horário do dia varia nos prompts básicos, e no text aparecia apenas nos prompts com papéis definidos. O autor não testou dois personagens parecidos, como dois homens de cabelo escuro e terno.

Vídeo e Omni

Para vídeo, o autor usa gemini-omni-1.1-flash pela Interactions API. A função de cada imagem é definida por marcadores diretamente no texto: <FIRST_FRAME> para o primeiro quadro e <IMAGE_REF_n> para as imagens de referência dos personagens. O fluxo de trabalho é este: primeiro, montar e conferir uma imagem com os dois personagens; depois, usá-la como primeiro quadro e acrescentar os retratos de referência.

O modelo decide por conta própria onde cada personagem vai ficar. Ao receber o pedido “senta-se em frente”, o personagem se sentou ao lado, porque estava em pé na lateral. Se a disposição for importante, é preciso fornecer um primeiro quadro em que os personagens já estejam sentados, deixando apenas a ação para o vídeo.

A gemini-omni-1.2-flash está disponível desde 5 de novembro, e as requisições à 1.1 serão redirecionadas para ela a partir de 3 de dezembro. Nessa versão, a duração passou a ser um parâmetro (de 3 a 15 segundos), e o preço por segundo em 720p caiu de $0,10 para $0,07. Mas, em um teste, os marcadores do primeiro e do último quadro não funcionaram. Uma frase explícita no início do prompt resolveu: “The video starts exactly on the first image and ends exactly on the second image”. A configuração com apenas um FIRST_FRAME e IMAGE_REF não foi testada na 1.2.

O que fazer na prática

• Mantenha a ficha do personagem como uma constante no código, em vez de reescrever o texto a cada vez.
• Em cenas com dois personagens, numere as imagens e liste os traços distintivos. Isso custa poucas linhas e deixa o prompt inequívoco.
• Não confie em no text: confira o fundo, porque um letreiro atrás do personagem será a primeira coisa a chamar atenção em um anúncio.
• Reúna as gerações em uma folha de contato e abra as imagens suspeitas com ampliação. O autor só percebeu a jaqueta e a pulseira ao compará-las com as gerações sem esses desvios.

Quanto ao custo, uma imagem 1K sai por cerca de $0,067, o teste completo com 18 imagens custa aproximadamente $1,21, e um clipe de 6 segundos no Omni 1.1 custou $0,63.