21 pontos por narubrown 2026-01-01 | 9 comentários | Compartilhar no WhatsApp

Redução de 96% no custo de rotulagem de imagens: um caso prático de engenharia que mostra como implementar funcionalidades centrais substituindo o trabalho repetitivo humano por um pipeline de software, mesmo em ambientes com pouco orçamento e tempo insuficiente

Resumo principal
• Identificação do problema: não existia um modelo pronto adequado para a função de reconhecer e registrar automaticamente bonecos de personagens famosos, e a rotulagem manual tinha limites claros de custo, velocidade e escalabilidade.
• Abordagem: em vez de perguntar “devemos colocar mais pessoas nisso?”, o processo de julgamento humano foi decomposto em um sistema e transformado em pipeline.

Projeto de pipeline de automação em 4 etapas
1. Filtragem com CLIP – remoção em massa de imagens sem significado para reduzir o custo com LLM
2. Detecção com YOLO – recorte apenas do objeto principal para reduzir o escopo da análise
3. Rotulagem com LVM – aplicação de VLM de alto desempenho apenas aos dados refinados
4. Validação com LVM – validação condicional baseada em confiança para reduzir ainda mais o número de chamadas

Resultados:
• custo de rotulagem humana de cerca de R$ 2,16 milhões → R$ 90 mil
• redução de custos de cerca de 95,7%, e o tempo de trabalho caiu de vários dias para poucas horas
• valor essencial: não foi apenas uma economia pontual, mas a obtenção de um sistema reutilizável

Os limites do capital podem ser superados com tecnologia, e isso demonstra que o software é uma ferramenta capaz de transformar um problema de custo em um problema estrutural

9 comentários

 
chickendreamtree 2026-01-09

Obrigado por compartilhar um conteúdo tão bom.

 
winterjung 2026-01-02

Ah, li com bastante interesse. Você disse que a necessidade de validação adicional é determinada com base na confiabilidade; também fiquei curioso para saber como esse valor de confiabilidade foi medido.

Como referência, o modelo gpt-4o-mini tem um custo excessivamente alto de tokens de entrada ao processar imagens, então recomendo considerar também outros modelos leves!

 
narubrown 2026-01-04

Olá, winterjung, obrigado pelo interesse no meu trabalho. Para a confiabilidade, uso o valor de confidence retornado diretamente pelo VLM (GPT-4o). Como você mencionou, existe a limitação de que a base de cálculo do confidence do GPT-4o é pouco clara e não pode ser reproduzida. Ainda assim, de uma perspectiva prática, parti da premissa de que o confidence retornado pelo VLM é razoavelmente preciso e implementei a etapa final de verificação (Verifier) para decidir, com base em um threshold, se a validação deve ou não ser realizada.

Eu realmente não fazia ideia de que os tokens de entrada de imagem do modelo got-4o-mini eram caros demais. Obrigado por me avisar. Já apliquei isso no código na hora haha

 
yeorinhieut 2026-01-03

Também fico me perguntando por que o 4o mini custa isso; pelo que eu sei, o 4o normal é mais barato kkk

 
crawler 2026-01-02

Parece um texto que resolveu bem o problema usando VLM, gostei bastante de ler.

Mas fiquei com uma dúvida ao ler o texto:

  1. Detecção com YOLO – recortar apenas o objeto principal para reduzir a área de análise

Gostaria de saber como vocês incluíram esse processo.

Enquanto eu lia, pensei que o VLM provavelmente teria desempenho melhor que o YOLO; então, ao recortar, não existiria o risco de o modelo YOLO julgar errado e informações importantes se perderem antes mesmo de serem passadas ao VLM?

O que levou vocês a pensar nesse recorte como solução, e como validaram a precisão antes de adotá-lo?

 
narubrown 2026-01-04

Olá, obrigado por ler o texto com interesse!

Concordo com o ponto que você mencionou. É uma observação válida que um VLM tem desempenho melhor que o YOLO, mas informações importantes podem se perder por causa de erros de julgamento do YOLO. Ainda assim, incluímos a etapa de recorte pelos motivos abaixo.

Primeiro, a questão do custo. Se usarmos a imagem inteira diretamente no VLM, o custo aumenta rapidamente por causa do processamento de imagens em alta resolução. Esse foi o principal motivo para introduzir o recorte.

Segundo, a questão da velocidade de processamento.
Para processar um dataset de grande volume em um tempo viável, esse ganho de velocidade era indispensável.

Terceiro, a melhoria de precisão.
O recorte, na verdade, aumenta a precisão de julgamento do VLM. Na imagem completa, podem aparecer juntos fundos complexos, vários personagens, textos, enfeites etc., o que pode confundir o VLM sobre qual objeto ele deve avaliar. Por exemplo, pode surgir a ambiguidade entre um personagem em um pôster no fundo, a boneca principal ou outro personagem ao lado. Já com o recorte, apenas o objeto-alvo fica claramente isolado, permitindo que o VLM se concentre somente nele ao fazer a avaliação.

Claro, isso não resolve completamente os problemas de falsos negativos e falsos positivos do YOLO. Mas mitigamos isso definindo o confidence threshold do YOLO em 0.5 para aumentar o recall e, depois, filtrando os falsos positivos nas etapas de filtragem com CLIP e verificação com o Verifier. Além disso, como lidamos com dados em grande volume, mesmo que ocorram alguns falsos negativos, ainda conseguimos garantir estatisticamente uma quantidade suficiente de dados de alta qualidade.

No fim, o objetivo era construir um pipeline prático encontrando um ponto de equilíbrio entre custo, velocidade e precisão, e a etapa de recorte trouxe efeitos positivos em todos esses três aspectos.

 
crawler 2026-01-05

Obrigado pela resposta.

Eu também pensei na questão do custo, e pelo visto ele realmente varia bastante conforme a resolução da imagem de entrada. E eu nem tinha pensado na relação entre o tamanho da imagem de entrada e a velocidade de processamento, então achei isso bem interessante. Ao fazer o crop, a velocidade de processamento também aumenta.

E o ganho de precisão é realmente impressionante!
O desempenho dos VLMs melhorou muito, mas mesmo assim eles ainda não conseguem superar o desempenho de um modelo YOLO treinado para um único objetivo?

Obrigado por registrar em texto o know-how que você adquiriu em situações reais.
Se eu me deparar com um problema parecido, com certeza vou consultar os métodos que você usou.

 
skageektp 2026-01-02

Parece que, em vez de resolver ao converter para um problema estrutural, vocês acabaram criando um novo modelo, não é?

 
narubrown 2026-01-04

Ótima observação, obrigado!

Acho que a expressão "transformar em um problema estrutural" pode ter soado um pouco abstrata.
O que eu quis dizer no texto foi:

Before: "rotulagem = entrada de pessoas = custo proporcional"
After: "rotulagem = pipeline = custo variável minimizado após a construção inicial"

Ou seja, o problema deixou de ser um custo pontual e passou a ser um problema de construção de sistema.
A expressão "criamos um novo modelo de trabalho" também está correta!
Mais precisamente, acho que dá para dizer que "substituímos o trabalho humano por um pipeline de software" rsrs