Neste post descrevo como arquitetei uma solução on-premise para lidar com vídeos que precisam ter cenas segmentadas, rostos identificados, legendas geradas, thumbs escolhidas, metadados puxados para o catálogo. É sobre como paramos de tentar vencer essa conta com pessoas e começamos a vencer com nossa própria AI.
TL;DR: Como a SOFA Digital construiu o MIDAS, evoluindo de APIs de cloud para infraestrutura on-premise com nossos próprios modelos de visão computacional (reconhecimento de elenco, detecção de nudez) e VLMs como BLIP-2, mais quatro lições que provavelmente se aplicam ao seu stack também.
Stack: Computer Vision, FaceNet, YOLO, CLIP, BLIP-2, Python, FFmpeg, workstations GPU on-premise
Nível: Avançado
Tempo de leitura: ~6 min
Mídia é uma carga brutal, e APIs de AI em cloud resolvem o lado técnico disso. Mas introduzem dois novos problemas: custo que escala linearmente com o volume, e dados que saem da sua infraestrutura para serem processados em outro lugar. Para um agregador que ingere milhares de horas de conteúdo licenciado de terceiros, nenhum dos dois é detalhe.
Isso tudo começou nas minhas horas de estudo, mais curiosidade que estratégia. A POC com VLMs (Visual Language Models) funcionou melhor do que eu esperava, o que diz menos sobre meu código do que sobre o quanto os modelos abertos ficaram generosos. O time de conteúdo adotou antes do time de engenharia terminar de discutir se aquilo estava pronto para produção. Foi o sinal de que ia virar coisa séria.
Comece na cloud (e não se sinta mal por isso)
A primeira versão do MIDAS rodava inteiramente em serviços gerenciados: Azure em algumas partes, AWS em outras, APIs de fornecedores coladas com Python. Foi a decisão certa, mesmo com o custo por vídeo desconfortavelmente alto desde o dia um. Você valida um pipeline contra conteúdo real primeiro, depois otimiza a conta. Inverter a ordem é como times constroem infraestrutura elegante para problemas que ainda não provaram que valem a pena resolver.
APIs de cloud também ensinaram onde estava a diferenciação real. Transcodificação e OCR eram commodity. Segmentação de cena ajustada para nosso catálogo e reconhecimento facial contra nossa base específica de elenco não eram. Quanto mais a gente se aprofundava no nosso conteúdo (novelas turcas, filmes latino-americanos, formatos regionais), maior ficava o gap entre modelos genéricos “bons o suficiente” e modelos “de fato úteis para o nosso negócio”.
Insight um: você não sai da cloud por causa do preço, sai por causa da inclinação
Se sua conta de AI em cloud é estável mês a mês, on-prem raramente compensa. Se sua conta está crescendo porque o uso está crescendo e cada nova feature multiplica chamadas de API por unidade de conteúdo, olhe para a inclinação, não para o número atual. A gente não migrou porque a conta estava alta. Migramos porque em doze meses ela seria punitiva, e a conta do hardware de repente fechava. Contas de cloud, como juros compostos, são mais simpáticas com quem está cobrando.
A outra metade do gatilho foi estratégica. Licenciadores se importam com onde o conteúdo deles é processado. Alguns explicitamente. Outros implicitamente, no tipo de cláusula que aparece em renovação de contrato. Possuir o caminho de inferência nos dava uma história que “usamos AWS para visão” nunca conseguiria.
Construindo o stack de visão: insight dois
A mudança para on-prem destravou a segunda fase do projeto: construir nossos próprios modelos para o trabalho que mais importava. Reconhecimento de elenco contra nosso catálogo. Pipelines de detecção de nudez para moderação de conteúdo. Entendimento de cena com VLMs como o BLIP-2, extraindo legendas, contexto e semântica visual que stacks só com CNN não alcançam.
A gente começou com arquiteturas abertas (FaceNet, YOLO, CLIP, BLIP-2) e fez fine-tuning contra nossos próprios dados. Os dados foram a parte difícil. Curar conjuntos limpos para nossos atores e apresentadores, anotar cenas contra nossa taxonomia editorial, construir benchmarks confiáveis para detecção de conteúdo sensível (sim, alguém precisa assistir cada frame que precisa do rótulo certo): esse trabalho é pouco glamouroso, e é exatamente onde o valor se acumula.
É aqui também que meu trabalho de doutorado em visão computacional começou a retornar para o trabalho do dia a dia de forma direta. Ler papers devagar, entender o que um benchmark publicado realmente te diz, escolher um backbone pelos motivos certos e não pelos da moda: acontece que hábitos de pesquisa são skill transferível, e ninguém me avisou disso durante os exames de qualificação.
O modelo é commodity. O dataset anotado é o moat. Todo mundo tem acesso às mesmas arquiteturas. Quase ninguém tem acesso ao seu catálogo, limpo e anotado, com casos de borda documentados. Gaste mais tempo em anotação do que em escolha de modelo. Você vai superar times que estão correndo atrás do último paper enquanto o dataset de treinamento deles ainda está uma bagunça.
O nome MIDAS acabou se encaixando melhor do que eu planejava: no mito original, tudo que o Rei Midas tocava virava ouro; no nosso pipeline, cada minuto de footage não processado que o sistema toca vira metadado estruturado, rostos reconhecidos, fronteiras de cena, e transcrições pesquisáveis. A metáfora é óbvia, e eu estou em paz com isso.
Insight três: escolha o modelo mais barato que passa na sua barra de qualidade
VLMs como o BLIP-2 são um bom exemplo da heurística que a gente acabou adotando. Para trabalho de alto volume e domínio estreito (tagging de cenas, classificação de frames, geração de legendas contra um vocabulário fixo), um modelo aberto fine-tunado rodando no seu hardware supera uma API de fronteira para esse trabalho, a uma fração do custo por inferência. Guarde o orçamento de API de fronteira para a long-tail de tarefas de baixo volume e alto raciocínio onde ela realmente vale o preço. Pagar por token a um modelo que sabe tudo sobre a internet mas nada sobre o seu catálogo é um lugar estranho para colocar dinheiro.
A próxima aposta nessa frente é um small language model treinado no catálogo da SOFA, rodando localmente ao lado do stack de visão. Ainda não construímos. O raciocínio é o mesmo de outros lugares no pipeline: um modelo de 7B treinado nos seus dados deve bater um modelo de fronteira treinado na internet aberta para o trabalho de linguagem de alto volume e domínio específico (sinopses, recomendações, classificação contra taxonomia), e a curva de custo deixa o trade-off confortável. Esse está no roadmap, não em produção. Ainda.
Insight quatro: a métrica que você não quer olhar é a que decide tudo
Pessoas amam benchmark. O modelo que ganha o leaderboard, o último salto em HumanEval, o screenshot de uma resposta esperta. Nada disso roda o seu negócio. Dois números chatos rodam: throughput (quanto trabalho por hora) e custo por inferência (quanto cada saída custa). Acompanhe os dois desde o dia um. Tome decisões contra os dois. Ignore o resto até esses dois estarem saudáveis.
A arquitetura que sobrevive é a que deixa você trocar modelos sem reescrever a lógica de negócio, porque o melhor modelo de hoje não vai ser o melhor modelo daqui a seis meses (e provavelmente nem o melhor modelo da próxima terça, do jeito que as coisas estão andando). Layer isso: ingestion normaliza o conteúdo bruto, inference roda os modelos, enrichment transforma saídas em entidades de negócio, orchestration coordena tudo. Cada camada é substituível. A única coisa que não deveria sair fácil é o seu dataset de treinamento.
Próximos passos
- Audite sua conta de AI contra sua trajetória: Compare os últimos doze meses com os próximos doze e decida se a inclinação ainda faz sentido.
- Gaste uma semana no seu pipeline de anotação: Quase ninguém faz isso de verdade, e é onde mora o moat.
- Escolha a métrica chata: Acompanhe throughput e custo por inferência desde o dia um. O resto é número vaidoso.
- Construa para trocar, não para o modelo: Um pipeline que deixa você substituir modelos sem reescrever a lógica de negócio vale mais do que uma integração esperta com o que estiver no topo do leaderboard.