Sobre a SynthVision
Começou com um projeto que não conseguia obter seus dados.
Não é uma tese de mercado. Um sistema de visão computacional estava pronto para lançar e o dado de que precisava estava sempre a meses de distância — repetidamente, toda vez que o produto mudava.
A origem
Uma geladeira inteligente que não conseguia ver os próprios produtos.
O projeto era um sistema de refrigeração inteligente: reconhecer quais produtos estavam presentes em cada prateleira, em tempo real, a partir da câmera dentro do gabinete. O hardware estava pronto. A arquitetura do modelo era sólida. O problema era que o modelo não tinha nada com que aprender.
Toda mudança de produto invalidava o dataset. As equipes de campo tinham que fotografar os novos SKUs em diferentes locais e condições de iluminação, com diferentes níveis de estoque na prateleira. Depois as imagens precisavam ser revisadas, rotuladas e validadas antes mesmo de o treinamento poder começar.
Uma atualização de catálogo — algo que acontecia várias vezes por ano — levava meses, da primeira captura até um modelo pronto para implantação. Numa frota grande de unidades, esse atraso não era um incômodo. Era o que estava travando o lançamento.
“Se eu conseguir reconstruir essa prateleira em 3D e trocar os produtos de forma paramétrica, consigo gerar o dataset inteiro em uma tarde.”
Essa foi a ideia, e ela se confirmou. O primeiro dataset sintético igualou o que semanas de captura em campo teriam produzido, e a próxima atualização de produto levou uma fração do tempo.
A SynthVision existe para tornar isso disponível para qualquer time cujo modelo seja limitado por dado, e não por arquitetura — agro, indústria, segurança, varejo, logística, automotivo, robótica e pesquisa.
Fundador · Visão Computacional
Guilherme Bileki
Engenheiro de visão computacional com experiência prática construindo sistemas de CV em produção nos setores de agro, varejo e indústria — de dispositivos inteligentes a pipelines completos de machine learning.
Ele fundou a SynthVision depois de bater na mesma parede repetidamente: conseguir o dado de treinamento certo leva mais tempo do que construir o modelo. Todo projeto é conduzido de ponta a ponta, do diagnóstico à iteração, o que também é o motivo de você estar falando com a pessoa que constrói o seu pipeline, e não com uma fila de suporte.
Acesso direto
Tecnologia sofisticada, sem a distância de um grande fornecedor.
Grandes plataformas têm escala, ecossistema e recursos de engenharia enormes. O que também têm é um limite: se o seu requisito não está no roadmap, o seu caminho até ele passa por uma fila de suporte, um time de produto e um ciclo de release.
Tecnologia de nível enterprise.
Acesso direto às pessoas que a constroem.
Aqui, um requisito vira uma mudança de engenharia que vira um novo dataset. Esse é o loop inteiro — e ele é curto de propósito.
→
→
→
→
Como pensamos
Posições que moldam todo projeto.
Algumas delas tornam o nosso trabalho mais difícil. Mesmo assim, são as que mantemos.
O gargalo de dado é um problema de modelo
Quando um modelo falha em produção, a causa raiz geralmente é uma lacuna no dado — uma condição nunca representada, uma classe nunca balanceada, um rótulo que nunca foi exato. Resolver isso é resolver o modelo.
Controlado por design vence gerado
Amostrar de um modelo te dá uma imagem que você não especificou. Declarar uma cena te dá uma imagem cujo conteúdo e rótulos você consegue descrever exatamente. Essa diferença é o produto inteiro.
Dado sintético e real são complementares
Não é uma história de substituição. Dado sintético estende a cobertura para condições que a coleta real não alcança; dado real mantém o modelo com os pés no chão e continua sendo o único conjunto de validação honesto.
Controle e rastreabilidade não são negociáveis
Toda amostra remete de volta aos parâmetros que a produziram. Reproduzível, auditável e explicável — não aproximadamente, e não de forma estocástica.
Um parceiro técnico, não um fornecedor de dados
Entregar uma especificação e devolver um arquivo zip não funciona, porque o próximo lote certo depende do que o modelo ainda está errando. O loop precisa continuar fechado.
A velocidade de iteração se acumula
Um dia entre a avaliação do modelo e o próximo lote de treinamento, em vez de duas semanas, é cerca de quinze vezes mais ciclos de iteração na mesma janela de projeto. É nesse acúmulo que o valor se concentra.
Rotulagem fica mais fácil. Captura, não.
Modelos generalistas continuam ficando melhores em anotar imagens que já existem, e esperamos que essa tendência continue — é progresso de verdade, e continua encolhendo metade desse problema. Ela não toca a outra metade: uma condição que ninguém fotografou ainda não está no dataset de ninguém, não importa quão boa a ferramenta de rotulagem fique. Essa é a metade para a qual construímos, e ela não é função do tamanho do modelo.
Quer saber como isso se aplica ao seu projeto?
Começamos com uma call de diagnóstico. Sem apresentação, sem compromisso — uma conversa técnica sobre o seu problema de dados.