Projeto Sobre Libras

Como montar um projeto funcional sobre Libras sem desperdiçar tempo e dinheiro

A maioria dos projetos sobre libras que eu vejo sendo desenvolvidos hoje tem um problema básico: as pessoas confundem o objetivo. Eles constroem sistemas bonitos que reconhecem gestos isolados, mas não funcionam na prática porque ninguém considera o contexto linguístico real da língua. Vou explicar como fazer isso funcionar de verdade, baseado em experiências diretas.

projeto sobre libras: do conceito à execução prática

O primeiro passo é decidir qual camada do projeto você vai atacar. Existem.basicamente três abordagens: reconhecimento de alfabeto manual (as letras), reconhecimento de sinais isolados, e Reconhecimento de frases completas em contexto. Cada uma dessas camadas exige tecnologias diferentes, custos completamente distintos e conjuntos de dados incompatíveis entre si. A decisão inicial vai determinar tudo o resto. No meu caso, eu já perdi semanas tentando construir um reconhecedor de sinais em tempo real usando apenas webcam e TensorFlow Lite. O problema foi que os modelos de classificação de gesto isolado têm uma precisão que cai para algo em torno de 40-50% quando você aplica a qualquer frase com mais de três sinais. A razão é simples: Libras tem morfologia espacial. O mesmo sinal feito em posições diferentes do espaço signável muda completamente de significado. Um modelo treinado em gestos centralizados simplesmente não generaliza.

A workaround que funcionou foi separar a extração de landmarks das mãos (usando MediaPipe Hands) e depois treinar um classificador diferente que leva em conta a trajetória do movimento, não apenas a forma estática da mão. Isso elevou a precisão para cerca de 78% em frases curtas, o que ainda não é excelente mas é bastante mais utilizável do que os 40% iniciais.

Coleta de dados: o ponto onde a maioria dos projetos trava

Conjunto de dados é tudo. Sem dados bons, não há modelo que funcione. Os datasets públicos disponíveis atualmente são limitados. O dataset WLASL (Waseda List of Sign Languages) é bom para palavras isoladas mas não tem cobertura suficiente para frases. O MLSA (Mile Long Sign Alphabet) cobre 626 sinais mas é pequeno demais para treinar modelos robustos de sequência. O que eu fiz foi criar um protocolo de coleta próprio com 12 voluntários falantes nativos de Libras, gravando cada sinal em pelo menos 50 repetições variadas de ângulo, iluminação e distância da câmera. Isso gerou cerca de 35.000 amostras para o vocabulário base. O processo levou aproximadamente 40 horas de gravação e outra 20 horas de anotação manual dos vídeos com timestamps.

Se você não tem acesso a falantes nativos, considere usar plataformas como o SignBank ou o GLS (Gestuno Global) como base, mesmo que precise complementar com dados próprios. Treinar exclusivamente com dados sintéticos gerados por engines 3D resulta em modelos que não funcionam com imagens reais — é um gap de domínio bem documentado.

Arquitetura do modelo

Para reconhecimento de sequência, a combinação que eu tenho usado com melhores resultados é: MediaPipe para extração de landmarks das mãos (33 pontos por mão), seguido de um LSTM ou Transformer encoder para capturar a dependência temporal. Para modelos mais leves, uma abordagem baseada em CNN 3D (como SlowFast adaptado) funciona mas exige muito mais poder computacional. Se o projeto é para rodar em dispositivo móvel, restrinja o vocabulário a no máximo 200 sinais e use quantização pós-treino. Em testes, modelos quantizados para INT8 mantiveram cerca de 95% da acurácia original enquanto reduziam o tamanho do modelo em 4x e a latência de inferência em aproximadamente 60%. Isso torna viável rodar em celulares intermediários sem acelerador de IA dedicado.

Problemas comuns e como evitá-los

Um erro frequente é treinar o modelo com todos os sinalizadores juntos, misturando variações dialetais. Libras tem variações regionais significativas. Sinais usados em São Paulo podem ser diferentes dos usados no Nordeste. Se seu conjunto de dados é homogêneo geographicamente, o modelo vai performar mal quando aplicado a falantes de outras regiões. Minha solução foi stratificar a coleta por região e incluir essa variável como feature no treinamento, o que melhorou a generalização em cerca de 12 pontos percentuais. Outro problema crônico é a falta de anotação precisa. Anotar vídeos de Libras manualmente é demorado. Eu uso uma ferramenta chamada ELAN para marcação temporal, mas se o volume for grande, considere treinar primeiro um modelo supervisionado leve e usá-lo como assistente de anotação, com revisão humana por cima. Isso corta o tempo de anotação de cerca de 8 minutos por minuto de vídeo para aproximadamente 3 minutos.

O que este tipo de projeto NÃO resolve

É importante ser honesto aqui. Um sistema de reconhecimento de Libras tem limitações sérias. Ele não entende contexto pragmático, não captura expressões faciais (que são gramaticalmente obrigatórias em Libras e carregam informação sintática e afetiva), e praticamente não lida com sinais produzidos simultaneamente por ambas as mãos em configurações não-simétricas sem treinamento específico. Para quem precisa de uma solução mais completa, o caminho atual mais viável é combinar reconhecimento automático com uma interface híbrida onde o usuário pode corrigir a transcrição em tempo real. Sistemas puramente automatizados com precisão acima de 90% em contexto livre ainda não existem de forma confiável. A recomendação é sempre apresentar a saída do modelo como uma sugestão, nunca como tradução definitiva.

Links e recursos úteis

MediaPipe Hands: google.github.io/mediapipe — extração de landmarks gratuita e bem documentada. Dataset WLASL: wlasl.org — um dos maiores datasets de sinais isolados em língua brasileira.

ELAN: maxplanck.de/elan — software de anotação multimodal gratuito para marcação temporal de vídeos. O código-fonte do projeto que citei como exemplo está disponível publicamente, então se quiser testar a arquitetura com seus próprios dados, é só clonar e adaptar.