Como avaliar o Nano Banana 2 na edição visual por turnos

O que sabemos e o que a documentação ainda não demonstra

A pergunta deste benchmark não é se uma imagem parece atraente nem se o modelo consegue produzir uma edição convincente num exemplo isolado. É mais específica: quando alguém solicita várias alterações em turnos sucessivos, as alterações pedidas são aplicadas e os elementos que não deveriam ser tocados permanecem estáveis? Também importa saber se os erros de uma edição passam para a seguinte e se acumulam.

A Google apresenta o Nano Banana 2 em documentação dirigida a programadores e descreve capacidades relacionadas com a geração e a edição de imagens e com a iteração. Essa descrição ajuda a identificar a finalidade anunciada, mas não equivale a uma medição independente da preservação de detalhes ao longo de vários turnos. As fontes disponíveis não fornecem resultados quantitativos para esta tarefa específica nem um protocolo que permita inferir um nível de desempenho.

Por isso, o que se segue é uma proposta de avaliação, não um relatório de resultados. Não atribui ao modelo uma taxa de sucesso, não o declara melhor ou pior do que uma alternativa e não pressupõe que uma edição preserve automaticamente o estado da anterior. Antes de executar o teste, será necessário confirmar qual é exatamente a versão disponível, através de que interface e com que controlos.

A pergunta operacional do benchmark

O caso de uso consiste em partir de uma imagem e pedir alterações sequenciais. Por exemplo, primeiro mudar a cor de um casaco, depois substituir o fundo e, por fim, acrescentar um objeto a uma mesa. Em cada etapa, o teste deve verificar tanto a alteração solicitada como a preservação dos elementos alheios a essa alteração: rosto, pose, peças de roupa não mencionadas, objetos, enquadramento e características relevantes do fundo.

A avaliação deve separar duas obrigações. A primeira é o cumprimento: a alteração pedida aparece? A segunda é a preservação: os elementos designados como controlos permanecem suficientemente estáveis? Uma saída pode cumprir uma obrigação e falhar a outra. Se só for avaliada a semelhança geral ou o aspeto atraente da imagem, estas falhas podem passar despercebidas.

Também é necessário registar se o resultado de um turno introduz defeitos que condicionam os turnos seguintes. Uma mão deformada no início pode continuar deformada depois, ainda que as instruções seguintes se refiram a outros elementos. O benchmark não deve atribuir automaticamente esse defeito à última instrução: é preciso guardar as imagens de cada etapa e avaliar a trajetória completa.

Conceção das tarefas e seleção das imagens

O conjunto de teste deve incluir imagens iniciais variadas, com pessoas, objetos, cenas interiores e exteriores e diferentes níveis de complexidade. A variedade, por si só, não demonstra representatividade; serve para verificar se o comportamento observado depende do tipo de conteúdo. As conclusões terão de se limitar às categorias e condições efetivamente avaliadas.

Para cada imagem, convém preparar antecipadamente uma sequência de instruções e uma lista de elementos-alvo e elementos de controlo. Os alvos são os elementos que se pede para alterar. Os controlos são aqueles que a instrução não deve modificar. Uma ficha de tarefa pode indicar o que deve mudar, o que deve ser preservado, que alterações colaterais são importantes e que ambiguidades podem levar avaliadores diferentes a discordar.

As instruções devem ser específicas, mas não tão rígidas que transformem o benchmark numa verificação de uma única resposta exata. Por exemplo, trocar uma chávena por uma chávena azul pode permitir variações de forma e textura; preservar o número de pessoas ou manter a posição aproximada de um candeeiro pode constituir um critério mais objetivo. Os critérios de aceitação e as exclusões devem ser definidos antes de consultar o modelo.

A seleção dos casos também deve evitar limitar-se a exemplos fáceis ou visualmente apelativos. Recomenda-se informar como as imagens foram reunidas, quantas tarefas foram excluídas e porquê. Se forem utilizados materiais sujeitos a restrições de utilização ou dados pessoais, o protocolo deve documentar a sua origem e as medidas pertinentes. As fontes disponíveis não permitem afirmar que dados de treino foram usados no modelo, nem se existe sobreposição com um conjunto de avaliação específico; essa incerteza deve permanecer explícita.

Condições de execução e comparação

Antes de executar os casos, a equipa deve identificar o modelo e a versão exatos disponibilizados pelo canal de acesso escolhido. O nome visível numa página ou interface não é suficiente se não permitir distinguir com certeza o Nano Banana 2 de outros modelos de imagem. Também é necessário registar a data do teste, a interface ou API, os parâmetros disponíveis, o formato e o tamanho das imagens e quaisquer instruções de sistema que afetem a edição.

Uma condição fundamental é a forma como o estado é gerido entre turnos. A interface pode manter o contexto da conversa ou a pessoa que realiza o teste pode ter de voltar a enviar a imagem resultante em cada etapa. Estas condições não são equivalentes: no segundo caso, o modelo recebe uma nova imagem como entrada em cada turno. O protocolo deve especificar o que acontece e guardar tanto as instruções como as imagens enviadas e recebidas.

Como referência, é possível comparar o fluxo iterativo com uma condição de passagem única: uma instrução reúne as alterações previstas na sequência e é feita uma edição. A comparação só será informativa se ambos os fluxos utilizarem o mesmo modelo, as mesmas imagens iniciais, a mesma qualidade de entrada, os mesmos parâmetros e as mesmas oportunidades de geração, na medida em que o canal o permita. Se essas condições diferirem, isso deve ser declarado e a diferença não deve ser atribuída exclusivamente ao número de turnos.

A comparação nem sempre é perfeitamente equivalente. Uma instrução conjunta pode ser mais longa ou ambígua do que as instruções sucessivas, e uma sequência pode permitir correções que uma passagem única não oferece. Estas diferenças fazem parte da questão prática, mas devem ser descritas com precisão. Se o acesso não permitir configurar uma condição comparável, a equipa pode executar o teste iterativo e apresentá-lo como tal, sem afirmar que demonstrou uma vantagem em relação a uma passagem única.

Métricas, avaliação humana e resultados

O resultado principal não deve ser resumido numa única pontuação sem explicar o que essa pontuação combina. No mínimo, devem ser comunicados separadamente o cumprimento de cada alteração, a preservação de cada controlo, a coerência com a imagem inicial e os erros novos ou persistentes. Pode calcular-se a percentagem de critérios aprovados, mas também devem ser apresentados os números absolutos e exemplos de falhas, para que a agregação não esconda casos importantes.

A avaliação humana é pertinente porque alguns critérios — como preservar a aparência de uma pessoa — podem exigir juízo visual. Para reduzir enviesamentos, a rubrica deve ser redigida antes de examinar as saídas. Sempre que viável, as pessoas responsáveis pela avaliação não devem saber que condição produziu cada imagem. Se houver vários avaliadores, devem ser comunicados o grau de concordância e a forma como os desacordos foram resolvidos. Uma impressão informal não deve ser apresentada como se fosse uma medição reproduzível.

As métricas automáticas podem ajudar a comparar imagens ou detetar alterações, mas não devem substituir a verificação de que a intenção de uma instrução foi cumprida. A equipa terá de especificar que ferramentas utilizou e que aspeto medem. Uma semelhança global elevada, por exemplo, pode coexistir com a alteração incorreta de um pequeno detalhe; uma diferença global acentuada pode ser esperada quando se pede a substituição de um fundo.

Para descrever a variação entre execuções, os casos devem ser repetidos em condições documentadas, sempre que o canal permita novas gerações. O número de repetições deve ser definido antes de interpretar os resultados e publicado juntamente com as falhas, as saídas inválidas e qualquer incidente. Não convém selecionar apenas a melhor saída de cada caso: essa prática mede o desempenho depois de selecionar resultados, não a fiabilidade de uma execução normal.

Reprodutibilidade, limites e alcance das conclusões

Um relatório reproduzível deve publicar a lista de tarefas, as instruções exatas, a origem ou descrição das imagens, os parâmetros disponíveis, o número de execuções e a rubrica. Também deve apresentar os resultados falhados e explicar as exclusões. Quando as imagens não puderem ser partilhadas por motivos de licença, privacidade ou outras restrições, essa limitação deve ser explicada e deve ser fornecida informação suficiente para compreender como os casos foram constituídos.

Os antecedentes disponíveis não resolvem, por si só, esta avaliação. Um estudo do Nano Banana Pro sobre diferentes tarefas de visão diz respeito a outro modelo e a outro desenho de teste; as suas conclusões não podem ser transferidas para o Nano Banana 2 nem para a edição conversacional por turnos. Do mesmo modo, um benchmark do Nano Banana 2 Lite não constitui uma comparação direta do modelo exato aqui proposto. Uma avaliação de restauro de imagens com o Nano Banana 2 pode fornecer contexto sobre uma tarefa relacionada, mas não mede necessariamente a preservação de elementos após instruções sucessivas.

Se o protocolo for executado, as conclusões devem limitar-se às versões, condições, imagens e tarefas testadas. Um bom resultado em algumas cenas não demonstra fiabilidade para toda a edição visual, para outros canais de acesso ou para utilizações profissionais com requisitos diferentes. Também não permite concluir nada sobre o comportamento em tarefas que não foram incluídas. Se não houver um canal verificável para identificar o modelo ou registar as condições, o teste poderá ser descrito como exploratório, mas não como uma comparação plenamente reproduzível.

Critérios práticos antes de tomar uma decisão

Para uma equipa que esteja a considerar integrar a edição por turnos num fluxo de trabalho, a decisão deve apoiar-se em tarefas próximas da sua própria utilização, e não apenas em imagens de demonstração escolhidas pelo fornecedor. Convém dar prioridade aos elementos cuja alteração teria consequências importantes, como identidade, texto, logótipos, objetos de produto ou componentes de uma cena, e definir que nível de alteração colateral seria aceitável.

Antes de interpretar qualquer pontuação, confirme quatro aspetos: que o modelo testado está identificado sem ambiguidades; que se sabe como o estado é transmitido entre turnos; que as alterações solicitadas e os elementos a preservar são avaliados separadamente; e que o relatório inclui variação, erros e limites. Se faltar algum destes aspetos, a evidência resultante será mais fraca e essa incerteza deve influenciar a decisão.

A documentação disponível justifica colocar a questão da avaliação, mas não antecipa a resposta. O passo seguinte não é proclamar um vencedor, mas executar um teste controlado, preservar o registo completo e publicar resultados que permitam distinguir uma edição bem-sucedida de uma sequência realmente estável.

Continue a explorar

Correções e transparência

Se encontrar informação incorreta ou desatualizada, envie-nos a página e a fonte que devemos rever.