VMem-Bench revela: a memória em geradores de vídeo derruba a precisão para 0,845

Os geradores de vídeos longos recorrem cada vez mais ao histórico de quadros anteriores para que um personagem não mude de rosto de cena para cena. Parece lógico: quanto mais acesso ao passado, mais estável o futuro. Uma equipe formada por Yuzhuo Chen, Huafeng Shi, Xinyu Wang, Yulong Xu, Yucheng Wang, Haoqin Hong, Guoxin Zhang, Zehua Ma e Weiming Zhang testou essa suposição com o benchmark VMem-Bench. A memória realmente eleva o recall de entidades de 0,559 para 0,628–0,693. Mas isso tem um custo: a precisão cai de 0,977 para 0,915–0,938, e a capacidade de não desenhar personagens e objetos proibidos despenca de 0,968 para 0,845–0,898.

A imagem está certa quanto ao passado e errada quanto ao presente

A ideia central do trabalho é simples: uma imagem pode corresponder exatamente ao que aconteceu antes e, ainda assim, ser um erro para o momento atual da história. O personagem trocou de roupa, ganhou uma cicatriz ou perdeu um objeto, e o sistema de memória entrega gentilmente ao gerador uma referência antiga. O resultado é que o modelo reproduz uma aparência obsoleta que o enredo já havia descartado.

Os autores mostraram que é exatamente isso que acontece. A busca no histórico reforça aparências obsoletas depois que a história já as mudou. A semelhança com aparições passadas aumenta, e, pelas métricas de "consistência", tudo parece ótimo. O problema é que a consistência em relação ao passado e a correção em relação ao enredo atual medem coisas diferentes.

Duas trilhas para separar a seleção de referências do desempenho do gerador

O VMem-Bench é estruturado como um estudo diagnóstico em duas partes.

• Track-A avalia quais referências são selecionadas do histórico, antes de qualquer geração e sem influência do próprio gerador. Material: 92 filmes reais, 16.548 segmentos.
• Track-B compara quatro políticas de busca com duas variantes de controle no mesmo gerador. Material: 30 histórias estruturadas causalmente, 2.824 segmentos. Controles: uma variante sem memória e uma variante de "última vez visto" com uma dica da anotação de referência.

Essa separação elimina a principal fonte de confusão na área. Quando um vídeo sai bom, não fica claro se uma boa escolha de referência ajudou ou se o próprio gerador se saiu bem por conta própria. O Track-A responde à primeira pergunta separadamente.

A armadilha do recall em intervalos longos

Há também um efeito inverso. Um recall alto em intervalos longos entre aparições de um personagem pode surgir sem memória alguma, se o próprio prompt já descreve a aparência. O modelo desenha o personagem certo porque foi instruído a isso, não porque "lembrou". Para expor isso, os autores aplicaram uma análise removendo as descrições de aparência dos prompts. Sem essa verificação, o ganho poderia ser erroneamente atribuído ao mecanismo de memória.

Números-chave

• Recall de entidades: 0,559 sem memória → 0,628–0,693 com busca no histórico.
• Precisão: 0,977 sem memória → 0,915–0,938 com memória.
• Evitação de entidades proibidas: 0,968 sem memória → 0,845–0,898 com memória.
• Escala do Track-A: 92 filmes, 16.548 segmentos.
• Escala do Track-B: 30 histórias, 2.824 segmentos, 4 políticas de busca, 2 controles.
• Efeito colateral: fixação de aparências obsoletas após mudanças no enredo.

O que mudar nos pipelines

Para equipes que constroem vídeos longos, séries, sequências publicitárias ou cinemáticas de jogos, a conclusão é prática. A relevância da referência encontrada e a consistência geral do vídeo, por si só, não comprovam que a memória esteja ajudando. São necessárias métricas separadas de precisão e de entidades "proibidas", caso contrário a degradação permanece invisível.

A memória deve estar vinculada ao estado do enredo, não apenas à proximidade visual: a busca precisa saber que o personagem já trocou de roupa ou que um objeto desapareceu. Os testes devem incluir um controle "sem memória" e uma variante com as descrições de aparência removidas do prompt, caso contrário pode-se confundir o trabalho do prompt com o trabalho da memória. O código e a página do projeto estão abertos: o repositório Suchenl/VMem-Bench no GitHub, e o artigo no arXiv sob o número 2610.35001.