Resumo Técnico: PaSBench-Video

Definição do Problema

Os atuais Modelos de Linguagem de Grande Escala Multimodais (MLLMs) possuem capacidades de compreensão de vídeo, mas carecem da habilidade de funcionar como monitores de segurança proativos. Embora acidentes sejam frequentemente precedidos por sinais de alerta visualmente reconhecíveis, os benchmarks existentes falham em avaliar a janela crítica entre o primeiro sinal visível de perigo e o momento em que o dano ocorre. Os benchmarks de segurança atuais sofrem de três limitações primárias:

1. Entradas Estáticas: Eles dependem de imagens estáticas ou sequências de imagens em vez de streaming de vídeo contínuo.
2. Falta de Calibração Temporal: Eles não distinguem entre avisos prematuros (emitidos antes do risco ser visível) e avisos tardios (emitidos após o dano ocorrer).
3. Ausência de Medição de Falsos Positivos: Eles omitem a avaliação em cenas benignas, ignorando o problema crítico de que alarmes falsos frequentes degradam a confiança do usuário e causam fadiga de alarme.

Consequentemente, não há um ambiente de teste controlado para determinar se os MLLMs podem observar causalmente um fluxo de vídeo, identificar o momento preciso em que um risco se torna acionável, emitir um aviso oportuno e permanecer em silêncio em cenas seguras.

Metodologia

Construção do Dataset: PaSBench-Video

Os autores introduzem o PaSBench-Video, um benchmark composto por 740 vídeos em quatro domínios: direção, saúde, vida cotidiana (casa inteligente) e produção industrial.

• Divisão de Risco (481 vídeos): Clipes verificados manualmente contendo riscos de segurança em evolução. Cada vídeo é anotado com limites de nível de frame:
  • Início do Risco ($r$): O frame mais precoce onde a evidência visual suporta um aviso acionável.
  • Acidente ($a$): O frame onde o evento adverso começa.
  • Fonte do Risco e Ação de Evitação: Agentes de perigo específicos e intervenções recomendadas.
• Divisão de Não-Risco (259 vídeos): Clipes benignos de condução normal, vigilância e monitoramento doméstico, usados exclusivamente para medir as taxas de falsos positivos.
• Fontes de Dados: Inclui datasets do mundo real (ex: DADA-2000, Nexar, OOPS) e dados sintéticos gerados via Kling v3 Omni para cenários de saúde e industriais onde dados do mundo real com granularidade de anotação específica não estavam disponíveis.
• Filtragem: Um filtro rigoroso de dois estágios (baseado em modelos usando Qwen3.5 e Gemini-3.1-Pro, seguido de adjudicação humana) garante que os clipes sejam previsíveis (risco inferível a partir de frames passados/atuais), evitáveis (intervenção possível), não intencionais (não são acrobacias encenadas) e visualmente fundamentados.

Protocolo de Avaliação

O benchmark utiliza um protocolo de avaliação de streaming:

• Observação Causal: Os modelos recebem apenas frames passados e atuais dentro de uma janela deslizante (janelas de 3 segundos, stride de 0,3s).
• Tarefa: O modelo deve decidir se emite um aviso estruturado (identificando a fonte do risco e a ação) ou permanece em silêncio.
• Métricas: Uma hierarquia de métricas progressivamente mais rigorosas parametrizadas pelo tempo de antecedência da intervenção $\tau$ (padrão 1,0s):
  1. Any-Det@$\tau$: Detecção de qualquer aviso antes do acidente.
     केवळ
  2. Any-Hit@$\tau$: Detecção de um aviso dentro da janela de risco válida $[r, a-\tau]$.
  3. First-Hit@$\tau$: O primeiro aviso do vídeo ocorre dentro de $[r, a-\tau]$.
  4. First-Act@$\tau$: O primeiro aviso é cronometrado corretamente e identifica corretamente a fonte e o conteúdo do risco.
• Taxa de Falso Positivo: Medida como a fração de vídeos sem risco que disparam $\ge K$ avisos.

Configuração Experimental

Os autores testaram 13 MLLMs, incluindo modelos de pesos abertos (Qwen3.5, Gemma) e modelos proprietários (Gemini, Claude, GPT). Todos os modelos foram avaliados com prompts idênticos, temperatura 0 e amostragem de frames.

Principais Resultados

1. Baixo Desempenho e Falha Qualitativa

Nenhum modelo excedeu 20,0% na métrica mais rigorosa (First-Act@1). Isso indica que menos de um em cada cinco vídeos recebe um aviso cronometrado corretamente que também identifica corretamente a fonte do risco. A lacuna entre detecção (Any-Det) e aviso acionável (First-Act) é enorme; por exemplo, o Gemini 3.1 Pro detecta o risco em 93,6% dos vídeos, mas atinge uma pontuação de First-Act de apenas 20,0%.

2. Acoplamento Estreito entre Recall e Falsos Positivos

Existe uma forte correlação positiva (Pearson $\rho=0,64$) entre as taxas de recall e de falsos positivos. Os modelos não conseguem melhorar a detecção sem inflar proporcionalmente os alarmes falsos. Isso sugere que os modelos atuais funcionam como detectores de limiar de sensibilidade em vez de sistemas que realizam raciocínio de risco genuíno. Aumentar a sensibilidade desloca os avisos de "perdidos" para "cedo demais", mas não aumenta a proporção de avisos "válidos".

3. Desempenho Dependente do Domínio

O desempenho varia drasticamente com base na discriminabilidade visual do domínio:

• Vida Cotidiana: Os modelos alcançam um recall moderado com baixas taxas de falsos positivos porque os riscos são frequentemente anômalos por natureza (ex: uma pessoa caindo, chamas abertas).
• Direção: Os modelos performam mal, disparando indiscriminadamente. Cenas rotineiras (mudança de faixa, cruzamentos) e cenas pré-colisão parecem visualmente similares, fazendo com que os modelos disparem avisos antes que o risco seja realmente visível (90% das falhas para modelos de alta sensibilidade foram "cedo demais").

4. Modos de Falha

Mesmo quando o tempo está correto, os modelos frequentemente falham ao identificar a fonte do risco:

• Objeto de Risco Errado (36,9%): Identifica a classe de entidade correta, mas a instância específica errada (ex: prevendo um ônibus em vez de um sedan).
• Troca de Tipo de Entidade (33,9%): Alucina uma categoria diferente de agente (ex: prevendo um pedestre quando o perigo é um veículo).
• Esses erros indicam uma dependência de pistas de atividade em nível de cena em vez de raciocínio causal sobre se uma atividade escalará para um dano.

5. Restrições de Implementação

Além das lacunas de capacidade, restrições de engenharia impedem a implementação imediata:

• Latência: Mesmo os modelos mais rápidos (GPT-5.4 mini) têm latências medianas (~3,5s) que excedem o stride da janela de 0,3s em uma ordem de magnitude.
• Custo: Custos de monitoramento contínuo para modelos proprietários de alto nível excedem $2.000/dia por câmera, enquanto modelos de pesos abertos sofrem com latência proibitiva.

Significância e Alegações

O artigo afirma que o PaSBench-Video fornece o primeiro ambiente de teste controlado para avaliar avisos de segurança de vídeo proativos que isola o progresso algorítmico das melhorias de infraestrutura. Ao remover a pressão de velocidade e restringir os modelos à observação causal, o benchmark revela que os atuais MLLMs dependem de pistas de atividade superficiais em vez de raciocinar sobre o surgimento de danos.

Os autores enfatizam que a tarefa de aviso proativo ainda não está pronta para implantação devido tanto às restrições de engenharia (latência, custo) quanto à insuficiência de capacidade (baixo recall, altos falsos positivos). No entanto, eles argumentam que o benchmarking desta capacidade agora é "oportuno e necessário" para guiar o progresso algorítmico em direção ao verdadeiro raciocínio de risco temporal, indo além da simples detecção de atividade para a antecipação de riscos. O dataset é liberado para facilitar essa pesquisa, com o objetivo explícito de desenvolver modelos que possam distinguir entre atividade rotineira e perigo iminente.