Stable Diffusion 3.5 Large à prova: como medir o seguimento de prompts

A que pergunta este benchmark responde

Uma avaliação do seguimento de prompts pergunta se uma imagem gerada contém os elementos pedidos na instrução e se eles aparecem com os atributos e as relações especificados. Por si só, ela não responde se o resultado é bonito, original ou adequado a qualquer uso. Também não permite declarar um modelo «melhor» em termos universais: descreve o comportamento do modelo perante um conjunto de tarefas, uma configuração e um método de pontuação específicos.

Para o Stable Diffusion 3.5 Large, a pergunta prática poderia ser: com que frequência as imagens geradas respeitam requisitos verificáveis, como incluir três objetos, colocar um à esquerda de outro ou mostrar uma determinada palavra? A comparação proposta com o Stable Diffusion 3.5 Medium deve ser entendida como um novo teste. Nas fontes disponíveis aqui, não há resultados quantitativos verificados nem um protocolo completo que permitam apresentar uma classificação já estabelecida.

Uma página de modelo, uma receita de software ou uma demonstração visual podem ajudar a identificar uma implementação ou a colocá-la em funcionamento. Não substituem uma avaliação controlada. Por isso, este artigo descreve como produzir e comunicar evidências; não atribui uma pontuação de seguimento de prompts nem ao Large nem ao Medium.

O que está verificado e o que continua por esclarecer

A comunicação da Stability AI anuncia a disponibilidade do Stable Diffusion 3.5 Large e do código de inferência. O cartão do modelo alojado no espaço da Stability AI no Hugging Face identifica o Large como um modelo de texto para imagem e descreve-o como um Multimodal Diffusion Transformer. Estes dados ajudam a identificar o modelo e a sua proveniência, mas os excertos disponíveis não apresentam medições do seguimento de instruções.

A documentação do Amazon Bedrock descreve uma oferta do SD 3.5 Large com oito mil milhões de parâmetros e saída de um megapíxel. Trata-se de informação referente à documentação e à configuração dessa plataforma; ela não deve ser automaticamente generalizada a todas as implementações nem interpretada como prova de qualidade. Uma receita do vLLM menciona, dentro da família, uma variante Medium de 2,5 mil milhões de parâmetros e uma Large de 8,1 mil milhões. Identificar esses tamanhos também não demonstra qual variante segue melhor um prompt.

O repositório da Stability AI apresenta-se como uma implementação de referência centrada em inferência. A existência do código facilita a inspeção de uma via de execução, mas, por si só, não determina os parâmetros adequados para uma comparação. Do mesmo modo, os testes informais partilhados no Reddit são experiências anedóticas: podem sugerir casos a investigar, mas não substituem um conjunto de teste com critérios definidos antecipadamente.

A conclusão metodológica é limitada, mas importante: com as evidências fornecidas, não é possível afirmar qual modelo obtém melhores resultados no seguimento de prompts, que diferença existe entre Large e Medium ou que configuração produziu resultados comparáveis. A ausência desses dados neste conjunto de fontes também não demonstra que não existam avaliações publicadas noutros locais; significa que não se devem atribuir resultados que aqui não foram verificados.

Conceber prompts que permitam verificar requisitos

O conjunto de avaliação deve decompor o seguimento em dimensões observáveis, em vez de depender de uma impressão geral. É conveniente incluir presença de objetos, quantidade, relações espaciais, atributos visuais e texto solicitado. Cada prompt deve especificar que requisito será avaliado e o que conta como cumprimento antes da geração das imagens. Se uma frase admitir interpretações diferentes, deve ser reescrita ou identificada como ambígua, em vez de ser interpretada depois de se ver o resultado.

A seleção deve abranger casos simples e combinações mais exigentes. Por exemplo, um prompt pode pedir duas chávenas; outro, uma chávena vermelha à esquerda de um livro azul; e outro, uma cena com uma etiqueta cuja palavra tem de ser legível. São exemplos de conceção do protocolo, não resultados atribuídos aos modelos. As instruções devem evitar detalhes irrelevantes que dificultem a identificação do requisito que falhou.

É útil equilibrar as categorias e registar a sua composição. Se houver muitos prompts sobre presença de objetos e poucos sobre texto, uma pontuação global pode esconder desempenhos desiguais. Também devem ser definidas antecipadamente as exclusões: por exemplo, se o texto só será avaliado quando estiver claramente visível ou se será admitida alguma variação tipográfica. Não se devem excluir prompts por produzirem imagens inconvenientes para uma conclusão esperada.

Fixar as condições de execução

Antes de gerar imagens, deve registar-se a identificação exata do modelo e dos pesos, juntamente com a versão do software, a implementação e qualquer modificação do pipeline. Também devem ser publicados a resolução, o número de passos, os parâmetros de orientação, a precisão numérica, o hardware e as opções de aceleração. Se uma plataforma ocultar parte desta informação, isso deve ser declarado e as conclusões devem ser limitadas em conformidade.

A semente e o número de gerações por prompt têm de ser documentados. Uma única imagem por instrução pode fazer com que uma variação aleatória domine o resultado; várias gerações permitem observar essa variabilidade, embora aumentem o custo. O protocolo deve determinar quantas amostras serão produzidas antes de os resultados serem inspecionados, aplicando o mesmo critério aos dois modelos. Para que a comparação seja interpretável, também convém indicar se as sementes foram emparelhadas entre modelos e o que significa esse emparelhamento nas implementações utilizadas.

Não basta declarar uma resolução ou um número de passos se o Large e o Medium forem executados com pipelines diferentes. A comparação mais clara mantém iguais os parâmetros que possam ser partilhados e publica todas as diferenças inevitáveis. Se as limitações de memória obrigarem a alterar a precisão, o tamanho do lote ou outras opções, essas diferenças fazem parte da descrição e podem impedir que o resultado seja atribuído exclusivamente ao modelo.

Pontuar requisitos e recorrer a avaliadores cegos

A unidade principal de pontuação deve ser o requisito verificável. Para cada imagem, os avaliadores podem assinalar se o objeto está presente, se a quantidade corresponde ao pedido, se o atributo solicitado aparece, se a relação espacial é respeitada e se o texto é legível e corresponde ao solicitado. Uma escala binária facilita a contagem, embora possa ser necessária uma categoria adicional de «não avaliável» para imagens corrompidas ou instruções efetivamente ambíguas. As regras para usar essa categoria devem ser fixadas antes da revisão dos resultados.

A avaliação humana deve ocultar que modelo gerou cada imagem e apresentar as imagens numa ordem aleatória. Os avaliadores precisam de instruções comuns, exemplos de aplicação da rubrica e uma forma de registar dúvidas. Convém incluir mais de uma pessoa e publicar tanto o grau de concordância como os desacordos; se os desacordos forem frequentes, a definição do requisito pode não ser suficientemente clara. Um desacordo não deve ser resolvido em silêncio nem o consenso apresentado como certeza absoluta.

As métricas automáticas podem servir de apoio, mas não substituem universalmente o julgamento de todos os requisitos. Antes de as utilizar, é necessário explicar o que medem, em que casos se aplicam e como foram verificadas em relação a uma amostra revista por pessoas. Uma medida global de semelhança não demonstra, por si só, que existem exatamente três objetos, que um está à esquerda de outro ou que uma palavra é lida corretamente. Quando uma métrica não estiver validada para uma dimensão, o relatório deve dizê-lo, em vez de a tratar como árbitro.

Comparar Large e Medium sem atribuições indevidas

A comparação deve partir do mesmo conjunto de prompts e da mesma rubrica. Tanto quanto as implementações permitirem, devem ser iguais a resolução, o número de gerações, os parâmetros de inferência e as condições de avaliação. Para cada requisito, convém apresentar resultados por modelo e categoria, com o número de amostras e uma descrição da variabilidade, em vez de apenas uma média geral.

A igualdade de valores numa tabela de parâmetros não garante que as execuções sejam equivalentes se o pipeline, a precisão, as opções de amostragem ou o software forem diferentes. Por isso, qualquer desajuste deve ficar visível. Se não for possível controlar uma diferença importante, o relatório deve descrevê-la como uma comparação entre duas configurações completas, e não como prova isolada de que o tamanho ou a variante do modelo causou o resultado.

Não se devem preencher com valores presumidos os campos para os quais ainda não tenham sido executadas avaliações. O relatório pode publicar o protocolo previsto e indicar que o resultado está pendente. Quando houver dados, cada conclusão deverá estar associada ao conjunto, à configuração e à rubrica que a sustentam. A avaliação proposta não permite antecipar se o Large terá resultados melhores do que o Medium no seguimento de instruções.

Contaminação, seleção de amostras e limites

Um benchmark pode ser enviesado se os prompts forem públicos, tiverem sido usados repetidamente em demonstrações ou forem semelhantes a exemplos vistos durante o desenvolvimento do sistema. Sem acesso a informações sobre os dados de treino, nem sempre é possível confirmar ou descartar uma exposição anterior. A equipa de avaliação pode reduzir os riscos redigindo prompts para o teste, limitando o acesso ao conjunto até à sua execução e publicando-o depois. No entanto, estas medidas devem ser descritas como controlos parciais, não como prova de que não houve contaminação.

Também há enviesamento quando se escolhem e mostram apenas as imagens mais convincentes. Para o evitar, devem ser preservadas todas as gerações previstas e definidas antecipadamente as regras de exclusão. Galerias de exemplos podem ilustrar falhas ou acertos, mas não substituem as contagens completas. Uma única semente, uma seleção manual posterior ou uma categoria com muito poucos casos podem criar uma impressão enganadora.

A rubrica incorpora decisões humanas: o que conta como uma relação espacial suficiente, quando um texto é legível ou que nível de detalhe permite considerar um atributo cumprido. Por isso, são necessárias definições operacionais, avaliação independente e comunicação dos desacordos. Os resultados não devem ser combinados sem mais com pontuações de outros conjuntos, configurações ou métodos: se as tarefas e as regras de medição forem diferentes, os números podem não representar o mesmo fenómeno.

Lista de reprodução do benchmark

Uma avaliação útil deve permitir que outra pessoa repita o procedimento e compreenda os seus limites, mesmo que não obtenha imagens idênticas. O material publicado deve incluir os prompts, os critérios de inclusão e exclusão, as sementes, o número de gerações, as versões e configurações, além das imagens ou de uma explicação clara para a sua não distribuição. Deve incluir também a rubrica, os formulários de avaliação, o método de ocultação da identidade do modelo e os resultados discriminados por dimensão.

O relatório deve separar factos observados, decisões metodológicas e interpretações. Por exemplo, a contagem das respostas dos avaliadores é um resultado da execução; a definição de «relação espacial cumprida» é uma decisão da rubrica; afirmar que uma diferença se deve ao modelo é uma interpretação que exige condições comparáveis e evidências suficientes. Esta separação ajuda quem consulta a avaliação a não confundir uma recomendação de protocolo com um resultado já medido.

Até que um teste deste tipo seja publicado e reproduzido, o mais responsável é apresentar o Stable Diffusion 3.5 Large e o Medium como variantes que precisam de ser avaliadas em condições explícitas, e não como vencedores ou derrotados num benchmark de seguimento de prompts. O índice de benchmarks pode servir de contexto editorial, e a ficha de avaliação do SD 3.5 Large pode ser uma referência para o teste, desde que os resultados pendentes não sejam descritos como medições. A conclusão prática é simples: publicar o método antes de interpretar as imagens e publicar os dados juntamente com qualquer pontuação.

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.