Ilustración editorial para AEGIS: qué mide este benchmark de imágenes académicas manipuladas y por qué detección, explicación y localización no son el mismo resultado
Imagen generada con gpt-image-2.5-sunburst para InferamaFonte ↗
01

AEGIS não equivale a uma prova de autenticidade científica

O AEGIS é um benchmark para avaliar a análise forense de imagens académicas geradas ou manipuladas por IA. O seu interesse não está apenas em perguntar se um modelo reconhece conteúdo sintético: procura separar uma decisão de classificação, uma explicação dos indícios e a localização espacial de uma possível alteração. Esta separação é importante porque as três saídas respondem a perguntas diferentes e podem falhar de forma independente.

Numa perspetiva de integridade científica, o resultado do AEGIS deve ser entendido como uma medição sob um protocolo definido, e não como uma certificação de que uma figura é autêntica ou fraudulenta. Uma pontuação elevada pode indicar que um sistema teve bom desempenho nos exemplos, formatos, anotações e regras de avaliação do conjunto. Não demonstra, por si só, que o sistema mantenha esse comportamento perante uma imagem inédita, uma figura com compressão diferente, uma edição legítima mal documentada ou um possível caso real de má conduta.

Isto também delimita o seu âmbito em relação aos benchmarks de deteção genérica de conteúdo sintético. Uma imagem académica costuma ter convenções visuais e semânticas específicas: painéis compostos, escalas, anotações, microscopia, gráficos ou outros subtipos documentados pelo conjunto. O contexto pode fornecer sinais úteis, mas também pode criar atalhos. Um modelo pode aprender correlações com estilos de geração ou edição presentes nos testes sem ter adquirido uma capacidade forense geral.

Por isso, a comparação útil não é, em abstrato, «que sistema tem a pontuação mais alta». É «que tarefa resolveu, com que entrada, em que partição, sob que critério de acerto e com que limitações declaradas». As rotas de benchmarks, segurança e glossário da Inferama podem ajudar a situar a distinção entre uma avaliação controlada e uma decisão aplicada.

02

Três tarefas, três tipos de alegação

A deteção binária coloca uma pergunta delimitada: segundo a definição operacional do benchmark, uma imagem deve ser classificada como real ou como gerada ou manipulada? A sua saída é uma etiqueta e pode ser acompanhada por uma pontuação ou probabilidade. É útil para ordenar casos que exigem revisão, mas não identifica necessariamente o mecanismo de edição nem mostra a evidência visual que motivou a decisão.

O raciocínio sobre indícios pede ao sistema que expresse por que razão suspeita de uma alteração. De acordo com o formato de referência e o avaliador previstos pelo AEGIS, a resposta deve relacionar-se com pistas observáveis ou com a estratégia de falsificação representada. Esta tarefa não fica validada pelo simples facto de a etiqueta binária estar correta. Um sistema pode acertar na classe através de uma correlação espúria e, ao mesmo tempo, fornecer uma explicação vaga, incompatível com a imagem ou posterior à decisão.

A localização exige indicar onde está a alteração, normalmente por meio de uma região, máscara ou outra representação espacial comparável com uma anotação de referência. É uma exigência distinta de descrever uma anomalia em linguagem natural. Uma explicação pode mencionar um painel ou um elemento visual sem o delimitar com precisão suficiente; inversamente, uma região razoável não demonstra que o modelo tenha explicado corretamente a natureza da manipulação.

Estas diferenças têm uma consequência prática: não é válido substituir o desempenho numa tarefa pelo de outra. Exatidão de deteção não é exatidão de explicação; uma correspondência textual não é uma máscara correta; e uma boa sobreposição espacial não determina, por si só, se a classificação final é fiável. Qualquer tabela de resultados deve manter as colunas de tarefa, métrica e protocolo, em vez de as reduzir a uma única ordenação de modelos.

O que cada saída permite afirmar

Saída avaliadaPergunta a que respondeAlegação sustentadaAlegação não sustentada automaticamente
DeteçãoA imagem corresponde à classe definida pelo benchmark?O sistema classificou exemplos do protocolo.Que identificou a área manipulada ou o mecanismo de edição.
RaciocínioA justificação corresponde ao critério de referência?O sistema produziu uma explicação avaliada nesse formato.Que a sua decisão se baseia causalmente nessa explicação.
LocalizaçãoA região prevista coincide com a anotação?O sistema delimitou a alteração com o critério espacial usado.Que consegue determinar intenção, autoria ou fraude real.
03

Como ler as métricas sem as transformar em equivalentes

As métricas de classificação, como a exatidão, resumem quantas decisões coincidem com as etiquetas do conjunto. Contudo, a exatidão agregada pode ocultar diferenças entre classes. Quando o protocolo publica métricas por classe, estas ajudam a verificar se o desempenho se concentra numa classe dominante ou se o sistema trata de forma desigual imagens reais e alteradas. Para interpretar qualquer percentagem, são ainda necessários o tamanho da partição, a distribuição de classes e as regras para respostas inválidas ou ambíguas.

A métrica espacial habitual em tarefas de segmentação ou localização é a interseção sobre união, conhecida como IoU. Compara a sobreposição entre a região prevista e a região anotada. Uma IoU baixa pode revelar uma região demasiado ampla, uma localização deslocada ou uma previsão que captura apenas uma fração da zona anotada. Mas a sua leitura depende do tipo de anotação, de se serem avaliadas caixas ou máscaras, dos limiares e da forma como são tratadas regiões múltiplas ou imagens sem alteração.

No raciocínio, a interpretação exige ainda mais prudência. A avaliação pode depender de respostas de referência, de critérios de correspondência semântica ou de um procedimento automático. O resultado informa sobre a conformidade com esse procedimento; não estabelece, por si só, que a explicação seja uma reconstrução causal do processo de edição. Antes de comparar resultados, convém verificar se os sistemas receberam a mesma imagem, as mesmas instruções, a mesma possibilidade de usar recuperação externa e o mesmo formato de saída.

Uma métrica não é menos valiosa por ser limitada. O problema é atribuir-lhe um significado que o protocolo não mede. O conjunto de dados distribuído pelo projeto inclui campos de tarefa, resposta de referência, categoria, subtipo, estratégia de falsificação e modelo generativo. Estes campos permitem desagregar alguns resultados, mas um valor global continua a ser um resumo, e não um diagnóstico completo.

Processo para ler uma métrica publicada

  1. 01Identifique a tarefa: deteção, raciocínio ou localização.
  2. 02Registe a métrica exata, o sentido desejável e o protocolo de cálculo.
  3. 03Verifique a partição, a distribuição de classes e o tratamento de casos inválidos.
  4. 04Procure resultados por categoria, subtipo, estratégia de falsificação e família generativa, quando disponíveis.
  5. 05Verifique que entrada, prompt, limiar e recursos externos recebeu o sistema.
  6. 06Limite a conclusão ao que a tarefa mede; não a estenda a autenticidade ou fraude real.
04

Do que é composto o conjunto e por que a composição importa

A ficha do conjunto publicada pelo BUPT Reasoning Lab declara 20.571 linhas e uma licença CC BY 4.0. A estrutura descrita inclui informação de tarefa, respostas de referência, categoria, subtipo, estratégia de falsificação e modelo generativo. O repositório de dados permite inspecionar exemplos e recursos associados, enquanto uma instantânea identificada do repositório enumera diretórios de imagens e ficheiros JSON para imagens reais e quatro estratégias de falsificação.

Esta rastreabilidade é útil, mas não substitui uma auditoria da partição concreta usada num resultado. O número de linhas não deve ser interpretado automaticamente como o número de imagens visualmente independentes: uma mesma imagem, ou uma imagem relacionada, pode participar em mais de uma tarefa ou ter metadados associados. A unidade de análise relevante deve ser a estabelecida pelo protocolo de avaliação e pelas suas separações entre treino, desenvolvimento e teste.

As categorias e os subtipos académicos são centrais para a dificuldade do teste. Um sistema pode ter desempenho desigual consoante as convenções visuais, o nível de detalhe ou o tipo de sinal disponível em cada subtipo. Do mesmo modo, diferentes estratégias de falsificação podem deixar artefactos distintos. Se os resultados forem agregados sem desagregação, não permitem saber se o desempenho resulta de uma capacidade amplamente distribuída ou de casos particularmente distinguíveis.

A presença de modelos generativos nos metadados permite estudar a generalização entre famílias de geradores, desde que o protocolo separe explicitamente as condições de treino e de teste. Essa separação não deve ser presumida sem documentação. Um resultado é mais informativo se esclarecer se avalia imagens produzidas por geradores vistos ou não vistos, se mantém uma estratégia de edição fora da fase de ajuste e se evita duplicados, variantes próximas ou metadados que liguem exemplos entre partições.

05

O que é realmente comparado entre modelos

O AEGIS pode reunir sistemas com capacidades diferentes: modelos multimodais de propósito geral, detetores forenses especializados e abordagens unificadas que produzem várias saídas. O facto de todos aparecerem na mesma tabela não significa que as suas condições sejam idênticas. Um detetor especializado pode receber uma imagem e emitir uma pontuação; um modelo multimodal pode precisar de instruções, gerar texto livre e depender da forma como esse texto é convertido numa etiqueta ou região avaliável.

A comparabilidade exige declarar a versão exata do modelo, a configuração de inferência, os prompts, o número de tentativas, o tratamento de imagens de grande dimensão, as transformações prévias, os limiares de decisão e o orçamento de recursos. Se for usada recuperação ou informação adicional, isso também deve ficar registado. Uma alteração aparentemente pequena — por exemplo, uma regra diferente para interpretar uma resposta textual — pode modificar uma métrica sem que a capacidade visual subjacente tenha mudado.

Os resultados de um modelo como o Amazon Nova 2 Lite só são interpretáveis perante o AEGIS se existir uma configuração documentada para essa avaliação. A sua pertença a uma família de modelos multimodais não permite inferir uma pontuação, uma capacidade de localização nem uma adequação à integridade científica. O mesmo se aplica a qualquer produto ou detetor especializado: uma alegação de desempenho exige o protocolo que a produziu.

O repositório oficial do AEGIS documenta a execução do benchmark e liga dados JSON, respostas de referência, imagens, máscaras e recursos opcionais de recuperação. Esta arquitetura permite distinguir entre o que o avaliador calcula e o que um sistema pode utilizar. Contudo, quem reproduz um resultado deve registar que recursos estavam ativos e que materiais permaneceram inacessíveis ao modelo avaliado.

Condições que têm de coincidir antes de comparar dois valores

ElementoO que deve ser declaradoRisco se mudar
Conjunto e revisãoPartição, instantânea e filtros aplicadosSão comparados exemplos diferentes.
SistemaModelo, versão, ajuste e configuraçãoO nome comercial não identifica o comportamento avaliado.
EntradaResolução, pré-processamento, texto e imagens auxiliaresUma variante pode receber mais sinal visual ou contextual.
InferênciaPrompt, temperatura, novas tentativas e limiarAs regras de decisão modificam a métrica.
AvaliaçãoAvaliador, formato de resposta e regra de pontuaçãoA mesma saída pode transformar-se em resultados diferentes.
06

O que os resultados publicados permitem, e não permitem, concluir

O artigo do AEGIS apresenta o benchmark, as suas tarefas, a construção do conjunto, as métricas e as avaliações de referência. Esse documento é a fonte apropriada para atribuir resultados aos baselines estudados pelos autores. Ainda assim, a leitura crítica deve preservar a granularidade do artigo: uma média agregada descreve o comportamento sob uma mistura particular de exemplos, e não uma garantia uniforme para cada categoria, subtipo ou estratégia de falsificação.

Os resultados diagnósticos são aqueles que mostram onde o desempenho muda: diferenças entre tarefas, categorias, subtipos, estratégias ou famílias de geração, quando o estudo as comunica. Estas desagregações podem revelar que a deteção parece mais sólida do que a localização, ou que determinados casos dominam uma média. A conclusão prudente é condicional: na configuração avaliada, o sistema teve desempenho diferente nesses grupos. Isto não autoriza extrapolar esse padrão para conjuntos externos sem nova avaliação.

Também não é correto traduzir uma pontuação baixa de localização numa incapacidade absoluta para detetar manipulação, nem uma pontuação elevada de classificação em evidência de explicabilidade. Cada resultado identifica um tipo de erro potencial. Para uma organização que revê figuras, esta informação pode servir para desenhar um fluxo de priorização e revisão humana, e não para automatizar uma sanção.

O AEGIS não fornece, por si só, uma estimativa da prevalência de fraude na literatura, uma taxa de falsos positivos no contexto operacional de uma revista nem uma validação jurídica ou institucional de uma acusação. Estas questões exigem amostras representativas do contexto de utilização, critérios de revisão independentes, procedimentos de recurso e uma avaliação prospetiva. Exigem também distinguir alterações enganosas de transformações legítimas e devidamente declaradas.

07

Riscos metodológicos: distribuição, contaminação e calibração

A diferença entre falsificações simuladas e casos reais é um limite fundamental. As estratégias incorporadas no benchmark permitem controlar anotações e tarefas, mas as manipulações reais podem ser mais heterogéneas, ser degradadas por cadeias de publicação ou combinar procedimentos não representados. Ao mesmo tempo, imagens autênticas em utilização real podem incluir recortes, ajustes de contraste, compressão ou composição legítima de painéis que se assemelhem parcialmente a sinais de edição.

A fuga ou contaminação pode assumir várias formas. Um modelo pode ter visto imagens, textos associados, modelos ou recursos próximos durante o seu treino; uma equipa pode ajustar prompts repetidamente em itens de teste; ou exemplos relacionados podem atravessar partições. A publicação dos materiais ajuda à reprodução, mas torna essencial documentar que dados eram públicos, que elementos foram reservados e como a avaliação foi protegida contra o ajuste iterativo.

A calibração importa quando uma pontuação se transforma numa ação. Um limiar escolhido para maximizar uma métrica de benchmark pode ser inadequado num ambiente em que as manipulações são pouco frequentes e o custo de um falso positivo é elevado. Uma ferramenta aplicada deveria comunicar curvas e erros relevantes para o seu cenário, bem como critérios para encaminhar casos para revisão humana. Sem essa informação, a exatidão isolada diz pouco sobre a utilidade operacional.

Por fim, a transferência entre domínios deve ser demonstrada, e não presumida. Um sistema avaliado nas categorias do AEGIS pode comportar-se de outra forma perante novas disciplinas, instrumentos, idiomas de anotação, formatos de revista ou geradores. Uma avaliação externa, com separação clara em relação aos recursos de desenvolvimento, é a evidência adequada para sustentar uma alegação de generalização.

08

Lista de verificação antes de usar um resultado do AEGIS

Antes de reproduzir um resultado, comprar uma ferramenta ou incluir uma pontuação num relatório, peça evidência que permita reconstruir a comparação. A primeira pergunta é que versão do conjunto e do avaliador foi usada. A segunda é que informação recebeu o modelo. A terceira é que decisão se pretende tomar com a saída. Estas perguntas ligam o desenho técnico aos riscos institucionais.

Também é aconselhável pedir os resultados desagregados relevantes para a decisão. Se o objetivo for priorizar imagens para revisão, são particularmente importantes os falsos positivos, a calibração e a estabilidade entre subtipos. Se se pretender assinalar uma região, deve examinar-se a métrica de localização e exemplos de erros. Se for avaliada uma explicação, é necessário rever o critério que define uma resposta aceitável, e não apenas a fluência do texto gerado.

O AEGIS é mais útil como instrumento de diagnóstico quando é apresentado juntamente com as suas condições e limites. Assim, pode revelar que tipo de evidência um sistema fornece e que verificações adicionais necessita. Tratá-lo como uma certificação de autenticidade eliminaria precisamente as distinções entre deteção, raciocínio e localização que o benchmark procura medir.

Perguntas mínimas para uma avaliação ou aquisição

  1. 01Que revisão do conjunto, ficheiros e partição foram avaliados?
  2. 02Qual é a definição operacional de cada tarefa e como é pontuada?
  3. 03Que modelo, versão, prompt, pré-processamento, limiar e recursos externos foram usados?
  4. 04Há resultados por categoria, subtipo, estratégia e família generativa?
  5. 05Como foi evitado o ajuste ao teste, a contaminação e a fuga entre exemplos relacionados?
  6. 06Que falsos positivos e falsos negativos são previsíveis no contexto de utilização?
  7. 07Existe validação externa em imagens académicas separadas do benchmark?
  8. 08Que revisão humana, direito de resposta e evidência primária serão exigidos antes de uma decisão adversa?

Questões em aberto

  • As fontes fornecidas documentam a estrutura e a avaliação do AEGIS, mas não fornecem nesta síntese uma reprodução independente do benchmark nem uma validação prospetiva em fluxos reais de integridade científica.
  • Não se deve inferir o número de imagens independentes apenas a partir das 20.571 linhas declaradas; a unidade exata de avaliação depende da documentação e da partição utilizada.
  • A aplicabilidade a disciplinas, geradores, formatos de publicação e práticas de edição não representados deve ser demonstrada através de avaliações separadas.
  • Qualquer comparação com um modelo concreto exige uma configuração publicada para o AEGIS; o nome do modelo, por si só, não comprova um resultado.
09

Continue a explorar

09

Fontes consultadas

03

Correções e transparência

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

Propor uma correção