---
title: "Testando os limites da visão artificial"
author: "Ricardo Pupo Larguesa"
date: "2026-09-27 18:49:00-03"
category: "Na Prática"
url: "http://aintuicao.scale.press/portal/aintuicao/post/2026/09/27/testando-os-limites-da-visao-artificial/md"
---

Já há alguns anos eu gravo as partidas de futsal do meu filho com uma Insta360 X5 (uma câmera que grava vídeos em 360º) e os publico em um canal do YouTube para a molecadinha curtir e também para manter um registro histórico dessa fase tão gostosa. Eu deixo a câmera Insta360 fixada em algum lugar da quadra e ela registra a partida inteira. Depois, gasto de 2 a 3 horas editando o vídeo, reenquadrando lance a lance para parecer uma transmissão de uma partida de futebol, e adicionando um placar dinâmico.

Parecia uma boa tarefa para delegar às minhas IAs. Não envolvia descobrir uma nova lei da física nem administrar uma empresa. Eu conseguia assistir à gravação e perceber onde estava a ação. A expectativa era que um agente também conseguisse, poupando-me do trabalho repetitivo de reposicionar o enquadramento.

Consegui chegar a resultados excelentes. Mas, se publicasse somente o vídeo final acompanhado da frase “automatizei a edição com IA”, estaria omitindo a parte mais instrutiva da experiência.

Houve tentativas interrompidas, modelos que respondiam com convicção sem localizar corretamente a bola, vídeos tecnicamente perfeitos com a câmera apontada para o lugar errado, erros de configuração, limites de serviço e um placar que passou nas verificações automáticas, mas que eu não queria ver no meu vídeo.

A experiência tornou-se uma investigação sobre o que significa uma IA enxergar. Também me fez pensar na distância entre o trabalho real e as demonstrações que consumimos nas redes sociais.

## A câmera gravou tudo. A IA ainda precisava escolher o que importava

Gravar em 360 graus resolve um problema e cria outro. Eu não preciso acompanhar a bola com a câmera durante a partida, mas alguém precisa decidir depois qual parte da gravação merece aparecer na tela.

No futsal, a bola é pequena, rápida e desaparece atrás dos jogadores. Quando reduzimos um panorama inteiro para enviá-lo a um modelo, ela pode ficar com poucos pixels. Um tênis, uma linha da quadra ou um reflexo oferecem distrações suficientes para uma resposta plausível e errada. O editor visual da Insta360 é ótimo, e tem um rastreador de objetos. Mas, obviamente, não funciona nada bem para acompanhar uma bola pequena correndo lá e cá rapidamente pela imagem.



*Imagem da experiência: a projeção cilíndrica apresenta a quadra inteira numa vista contínua. É uma representação para análise, não o enquadramento final destinado ao espectador.*



Comecei explorando ferramentas e modelos diferentes. Houve operação visual do Insta360 Studio, uso do SDK da câmera, renderização com FFmpeg, modelos locais e serviços remotos. Um piloto curto funcionava; a versão seguinte, aplicada à partida inteira, deixava de funcionar como eu esperava.

Em uma dessas passagens, a análise visual do piloto foi substituída por uma heurística que procurava regiões com mais movimento entre imagens. Parecia uma simplificação razoável. Só que o árbitro também se movimenta. Um atleta longe da disputa pode correr mais do que quem está recebendo um passe. A região com mais pixels mudando não é necessariamente a região que eu quero assistir.

Também houve problemas que não eram de inteligência. Uma configuração de campo de visão deformava as proporções. Outra fazia a câmera acelerar e parar a cada intervalo de meio segundo. Corrigir a interpretação da jogada não resolveria esses defeitos, assim como suavizar o movimento não faria uma câmera mal orientada encontrar a ação.

Uma tentativa com análise mais pesada passou quase dez horas sem entregar o primeiro vídeo final. Esse tempo existiu, embora não apareça em nenhum dos vídeos que ficaram bons.

## A pergunta que mudou o resultado

A mudança mais produtiva veio quando intervir na pergunta aparentemente óbvia que aIA fazia: onde está a bola?

Fiz diversos testes manuais enviando variações de ângulo, proporção e resolução de imagens anexas e refinando a pergunta até conseguir um resultado funcional. Um verdadeiro trabalho de engenharia de prompt. E o resultado foi um prompt otimizado. Passei a pedir que a IA identificasse onde a jogada estava concentrada. A bola continuava sendo uma pista, mas não a única. O posicionamento dos atletas, a direção dos corpos, os apoios e a postura dos goleiros também ajudavam a interpretar a cena.

Eu não precisava de uma coordenada certificada da bola. Precisava de um enquadramento que fizesse sentido para quem acompanha a partida.

Esse método produziu partidas completas aprovadas. Depois, para comparar modelos de forma mais controlada, preparei um trecho de dois minutos com uma vista cilíndrica da quadra. Cada consulta mostrava um quadro atual grande e até dez quadros anteriores, espaçados em um segundo. Acrescentei o histórico das últimas decisões daquele modelo. Mas a IA não decidiu fazer isso sozinha. Sequer sugeriu. Eu tive que ter a ideia e pedir explicitamente um script que fizesse essa composição, validar o script e o resultado para só então iniciar os testes.



*Entrada real enviada aos modelos: o contexto temporal aparece nas miniaturas, enquanto o quadro maior indica o instante a classificar. As decisões anteriores de um modelo não eram compartilhadas com os demais.*



A saída foi simplificada em cinco regiões, da extrema esquerda à extrema direita. Um script convertia essas decisões em movimentos suaves. O modelo interpretava a cena; ferramentas convencionais faziam a projeção e a renderização.

O vídeo final continuava com 30 quadros por segundo, mas a IA não estava tomando trinta decisões por segundo. Na comparação, ela decidia uma vez por segundo. O movimento entre os pontos era calculado pelo renderizador. Essa diferença é essencial para não confundir um vídeo fluido com percepção artificial contínua.

## O modelo mais caro não foi a escolha mais interessante

Na primeira rodada, os cinco vídeos concluídos ficaram ótimos. O Luna destacou-se num chute específico. GLM Flash e MiMo Flash também entregaram resultados excelentes, com custos muito menores.

Na rodada seguinte, com modelos de fronteira, Opus, Astra e Sol Pro ficaram excelentes. Gemini perdeu a bola num instante. Terra e Grok não acompanharam a velocidade dela em um lance, mas o resultado permaneceu aceitável.

Estes são alguns números da comparação, todos para o mesmo trecho de dois minutos:



*Tempos incluem análise, renderização e verificações registradas, além de retomadas quando ocorreram. Excluem preparação compartilhada e intervalos externos. Custos desconhecidos de algumas tentativas com erro não foram considerados gratuitos.*



Não encontrei, nesse trecho, uma justificativa automática para escolher a alternativa mais cara. Os modelos econômicos ficaram na mesma ordem de grandeza de tempo e entregaram qualidade que me satisfez.



*Saída real do GLM Flash aos dez segundos, correspondente ao instante das imagens anteriores. Um quadro ilustra o recorte; minha avaliação de qualidade foi feita assistindo ao vídeo em movimento.*



As duas baterias OpenRouter somaram aproximadamente US$ 26,75 em custos confirmados. Isso não é o preço de editar uma partida nem o custo integral do projeto. É o subtotal de uma comparação deliberada entre vários modelos, com resultados incompletos e falhas também registrados. Assinaturas, computador, energia e meu tempo de acompanhamento ficaram fora dessa conta.

Tampouco esse teste é um campeonato universal de modelos. Usei um trecho, uma representação e um critério editorial. Um lance perdido pode decorrer da cadência de amostragem ou do movimento permitido à câmera, não apenas de uma falha do modelo.

## O placar também precisou de supervisão

Em outra partida, anunciei gols próximo à câmera para facilitar a elaboração do placar. A transcrição inicial quase não encontrou os anúncios. As tentativas seguintes recuperaram trechos úteis, mas com números e nomes incertos.

Minha própria lembrança também estava errada: inicialmente pensei em 6 a 1 e depois confirmei 5 a 1. A IA precisava confrontar evidências, não inventar um gol para concordar comigo.

Depois veio a arte. O primeiro placar passou nas verificações de duração, áudio e transições. Visualmente, não me agradou. Forneci uma imagem com o desenho que queria, aprovei uma prévia sobre um quadro real e o processo passou a alterar apenas os números.

A composição final levou aproximadamente quatro minutos para renderizar e verificar. Não foi necessário analisar toda a partida novamente.

Esse foi um dos melhores resultados da experiência: descobrir quais decisões precisavam de interpretação, quais dependiam de confirmação humana e quais deveriam ser executadas por um procedimento simples. Pedir inteligência a cada etapa teria tornado o trabalho mais caro e menos previsível.

Aproveitei o resultado excelente, e criei uma skill especialistada neste procedimento. Está [publicado no GitHub](https://github.com/larguesa/insta360-skills) para quem quiser usar. Se te ajudar, deixe uma estrinha lá. 😉

O vídeo final está publicado [aqui](https://youtu.be/FB2lcjdeBV4?si=VADX4Pil7PgAbamM).

## A demonstração que dá certo precisa contar o que ficou de fora

É aqui que minha experiência encontra um incômodo com parte do conteúdo sobre IA.

Vejo demonstrações extraordinárias: agentes criando sistemas, operando computadores e entregando trabalhos complexos a partir de uma frase. Muitas podem ser autênticas. O problema aparece quando o resultado escolhido é apresentado como se representasse uma execução comum, rápida e praticamente sem intervenção.

Quantas tentativas falharam antes? Quanto tempo foi gasto preparando o ambiente? Quantas correções vieram de uma pessoa? O vídeo foi acelerado? Houve troca de modelo? Quanto custaram as chamadas descartadas?

Não espero que cada publicação mostre horas de logs. Espero que informe essas condições quando elas mudam o significado da demonstração.

Omissões desse tipo prejudicam quem tenta reproduzir. Um profissional promete um prazo que a ferramenta não sustenta. Um gestor transforma uma amostra editada em meta de produtividade. Um iniciante conclui que é incompetente porque sua experiência não parece com a do influenciador.

No meu caso, eu poderia esconder a câmera apontando para o lugar errado, as dez horas sem entrega e o placar rejeitado. Ainda assim, o vídeo final seria verdadeiro. A impressão sobre a facilidade de produzi-lo seria falsa.

Eu continuo entusiasmado com o que consegui. Justamente por isso, prefiro mostrar o percurso. Não preciso exagerar a facilidade para reconhecer o valor do resultado.

## Resolvi medir também o tempo de uma resposta visual

A investigação continuou com um piloto de visão realizado no meu PC, documentado em 25 de setembro de 2026. Usei três capturas reais de monitores em Full HD, modelos locais e APIs remotas. Pedi identificação da tela, pequenos textos legíveis e um detalhe visual com sua posição.

O inventário final reuniu 73 execuções, incluindo diagnósticos e tentativas recusadas. Cinquenta concluíram tecnicamente, cinco ficaram vazias ou truncadas e dezoito terminaram em erro. Não fiz uma avaliação independente de acurácia dessas respostas. Só queria testar velocidade de leitura.

Os tempos ajudam a dimensionar a experiência, mas exigem cuidado:



*Duas execuções por condição nesta seleção. Médias de respostas completas, sem controle equivalente de cache, aquecimento e filas. A tabela não mede precisão nem velocidade interna do processamento visual.*

O fato de três imagens terem sido mais rápidas do que uma em algumas condições já impede uma regra de três ingênua. Raciocínio e tamanho da resposta variaram. Cache, rede e serviço também interferiram. O cronômetro mediu a requisição até o fim da resposta, não um exame isolado de quanto tempo o modelo levou para “ver”.

Também houve um caso revelador com Gemma 12B. Uma falha que poderia parecer falta de capacidade visual foi reproduzida com um batch físico de 512 e deixou de ocorrer, nas imagens testadas, com 2048. Não era razoável concluir que o modelo não enxergava. A configuração do motor impedia a execução.

Esse piloto custou cerca de US$ 0,0487 em uso remoto reportado, sem incluir custos locais ou cobranças eventualmente ausentes. Ele acrescentou evidência, mas também tornou mais difícil fazer afirmações simplistas sobre a velocidade da visão artificial.

## Minha hipótese dos 150 vezes e dos 50,6 meses

Ainda assim, quis construir uma referência numérica para pensar no problema.

Suponha um sistema que leve cinco segundos para produzir a interpretação útil de uma imagem. Se exigirmos o mesmo trabalho para cada quadro de um vídeo a 30 quadros por segundo, de maneira serial, ele precisaria aumentar sua taxa de processamento em 150 vezes para acompanhar o fluxo sem acumular atraso:

**5 segundos por imagem × 30 imagens por segundo = 150.**

Escolho 30 FPS porque é a taxa técnica dos vídeos finais desta experiência. Não estou atribuindo uma taxa de quadros ao olho humano nem afirmando que todos os vídeos tenham essa cadência. Quero fixar um requisito operacional verificável, deixando fora dessa conta as demais dimensões da percepção.

A conta seguinte é tentadora. Se essa taxa de processamento dobrasse a cada sete meses, quanto tempo levaria para crescer 150 vezes?

**7 × log₂(150) = aproximadamente 50,6 meses.**

A matemática está correta. A premissa sobre a evolução da velocidade permanece uma hipótese.

A referência conhecida dos sete meses vem do trabalho da METR sobre o horizonte de tarefas que agentes conseguem concluir. No estudo publicado em março de 2025, o que dobrava aproximadamente nesse intervalo era a duração das tarefas, medida pelo tempo que humanos levariam para executá-las, que os agentes conseguiam resolver com 50% de probabilidade. Isso não é uma medição de velocidade de inferência visual.

Não posso pegar essa tendência, trocar a grandeza medida e anunciar uma data para a IA enxergar como uma pessoa. Posso usá-la como inspiração para um cenário explicitamente condicional: se um avanço dessa ordem também ocorrer na capacidade útil de processar vídeo, o salto necessário nesse modelo simplificado caberia em pouco mais de quatro anos.

Os 50,6 meses são uma pergunta organizada por uma equação, não um prazo demonstrado. Apresentá-los como previsão garantida repetiria o problema das demonstrações sem contexto que acabei de criticar.

Além disso, os 150 vezes descrevem esse processamento serial hipotético. Não medem quanto a IA precisa ficar “mais inteligente”, nem a distância geral entre visão computacional e visão humana. Um sistema pode processar muitos quadros rapidamente e interpretar mal o que aconteceu. Pode também usar poucos quadros e acertar a decisão relevante.

## O movimento pode fornecer informação, em vez de apenas aumentar o trabalho

Minha hipótese mais interessante não é que precisamos repetir mais depressa a mesma análise de imagens isoladas. É que uma sequência pode tornar certas interpretações mais fáceis.

Uma bola parcialmente escondida em um quadro pode ter posição e trajetória inferíveis pelos instantes anteriores. A mudança de postura de um goleiro ajuda a distinguir espera de reação. Um jogador parado numa imagem pode estar desacelerando depois de um passe.

Foi por isso que acrescentei contexto temporal aos testes. Os resultados me animaram, embora a experiência não tenha isolado a contribuição de cada componente para provar quanto do ganho veio das miniaturas ou do histórico textual.

Imagino uma percepção cumulativa que preserve o estado da cena, acompanhe mudanças e reserve mais processamento para acontecimentos inesperados. Nesse arranjo, a IA não precisaria reconstruir a quadra inteira a cada quadro nem escrever uma explicação completa antes de atualizar uma trajetória.

É uma hipótese de arquitetura, não uma capacidade que aparece automaticamente quando aumentamos o número de imagens. O TemporalBench, por exemplo, foi criado para avaliar compreensão temporal fina em vídeo. Seus resultados históricos ajudam a lembrar que descrever objetos e entender a ordem ou a evolução de uma ação são exigências diferentes. Não uso aquela tabela de modelos antigos como retrato dos melhores sistemas de hoje.

Também não partimos de uma ausência completa de vídeo em tempo real. Existem sistemas especializados e pesquisas em modelos de fluxo contínuo, embora usem truques que degradam o raciocínio e a qualidade da visão computacional em prol da velocidade em tempo real. Minha dificuldade prática está na combinação de interpretação flexível, baixa latência e confiabilidade necessária para delegar uma tarefa inteira.

## A ligação com agentes que operam computadores

Vejo uma relação entre essas dificuldades e o comportamento dos agentes em interfaces gráficas. Uma captura mostra um estado. Uma interação exige perceber que o estado mudou e decidir quando agir novamente.

Uma janela pode estar abrindo. Um menu pode depender de manter o cursor sobre uma região. Um componente pode estar se deslocando numa animação. Há transições, vídeos e movimentos do mouse que desaparecem quando tratamos a interface como uma sequência esparsa de fotografias independentes.

Um agente lento pode tomar uma decisão sobre uma tela que já não existe. Um agente sem memória suficiente pode interpretar cada captura sem relacioná-la à ação anterior. Minha suspeita é que uma percepção temporal mais eficiente ajudará bastante nesses casos.

Mas não explicará todos os problemas de computer-use. Planejamento, localização precisa de elementos, uso de ferramentas, recuperação de erros e verificação de efeitos também contam. Muitas interfaces podem ser operadas por estrutura de acessibilidade ou pelo DOM, sem exigir análise visual contínua a 30 FPS.

Os outros fatores não são todos subjetivos; vários podem ser medidos. Apenas não cabem na conta simplificada que escolhi. Delimitar um cálculo é útil. Transformá-lo numa explicação completa seria exagerar seu alcance.

## No robô, a demora passa a ter consequências físicas

Na edição do jogo, uma câmera atrasada perde um lance. Num robô, uma decisão atrasada pode errar a posição de um objeto em movimento ou não reagir a alguém entrando no caminho.

A robótica acrescenta restrições de energia, dissipação de calor, memória e espaço. Não basta que o processamento funcione num servidor. Para autonomia local, a capacidade necessária precisa caber no equipamento e operar dentro de seu orçamento energético.

Isso não significa que ainda não existam modelos embarcados. O Gemini Robotics On-Device, anunciado pelo Google DeepMind em 2025, é um exemplo de sistema projetado para executar localmente e reduzir dependência de rede. É evidência de progresso nessa direção, não de equivalência geral à percepção humana.

Também não é obrigatório miniaturizar um modelo generalista inteiro dentro da cabeça de um humanoide. Uma arquitetura pode separar percepção rápida, controle motor e planejamento mais lento. Pode combinar modelos especializados e recorrer à nuvem onde a latência e a conectividade permitirem. O que não pode é depender dessa conexão para uma reação crítica sem tratar o risco de interrupção.

Por isso, mesmo que meu cenário de 50,6 meses se realizasse para processamento visual, ele não garantiria o mesmo avanço simultâneo em eficiência energética, hardware compacto e segurança física.

Há espaço para surpresa favorável. A própria IA já está ajudando a desenvolver chips, otimizações e algoritmos. Quantização, destilação e reaproveitamento temporal já oferecem caminhos; mecanismos futuros podem preservar informação relevante usando muito menos processamento. Comprimir um arquivo de vídeo, porém, não equivale automaticamente a baratear sua compreensão. O ganho precisa chegar ao modo como o modelo representa e utiliza a sequência.

Não sei quando essas frentes se encontrarão num sistema com a flexibilidade que atribuímos à visão humana. O que minha experiência permite dizer é mais modesto: tratar cada imagem como uma pergunta nova e demorada parece uma forma pouco eficiente de acompanhar um mundo que não para.

## O que eu publicaria junto com o vídeo

Terminei com vídeos que gosto de assistir, um procedimento mais econômico e lições incorporadas numa skill reutilizável. Isso tem valor concreto para mim. Na próxima partida, não preciso recomeçar toda a investigação.

Continuo otimista sobre a percepção artificial e sobre agentes capazes de agir com mais autonomia. Mas saí menos disposto a confundir um resultado impressionante com um processo confiável e imediato.

Se eu mostrar o vídeo do futsal, quero contar também que precisei mudar a pergunta, testar representações, corrigir ferramentas e supervisionar decisões. Quero dizer quanto custou a comparação, sem fingir que medi todos os custos. E quero deixar claro que modelos baratos, com uma tarefa bem formulada, entregaram resultados que modelos muito mais caros não tornaram automaticamente melhores.

Comecei querendo assistir melhor aos jogos do meu filho. Acabei com uma medida mais concreta do que minhas IAs conseguem fazer, do que ainda precisam de mim e do trabalho que uma demonstração bem editada pode esconder.

## Fontes e notas


- [METR: Measuring AI Ability to Complete Long Software Tasks](https://metr.org/blog/2025-03-19-measuring-ai-ability-to-complete-long-tasks/). Fonte histórica da duplicação aproximada de sete meses para horizonte de tarefas, não para velocidade visual.
- [TemporalBench](https://temporalbench.github.io/). Avaliação de compreensão temporal fina em vídeos, com resultados históricos.
- [Google DeepMind: Gemini Robotics On-Device](https://deepmind.google/blog/gemini-robotics-on-device-brings-ai-to-local-robotic-devices/). Exemplo de modelo de robótica com execução local.
- [Da automação à simbiose com a IA](https://aintuicao.scale.press/post/2026/08/30/da-automacao-a-simbiose-com-a-ia), meu ensaio anterior sobre possibilidades e limites da colaboração humano-IA.

*As três ilustrações são imagens reais da mesma gravação, extraídas dos artefatos da experiência. Não são imagens geradas por IA.*