Detecção de Objetos do Zero: Parte 2 - Dataset, Labels e a Realidade dos Dados

Em machine learning, dataset não é apenas "entrada". Ele é a primeira versão da verdade operacional do sistema.

É por isso que gosto da forma como este projeto documenta os dados. O dataset não fica escondido atrás de um comando genérico de treino. O repositório explica de onde ele vem, como os splits funcionam e o que os labels significam na prática.

A Fonte dos Dados

O projeto usa um dataset do Roboflow Universe voltado para regiões de cartas de Magic: The Gathering. O detalhe importante não é só a quantidade de imagens, mas o fato de as anotações serem regionais, e não apenas no nível da carta inteira.

Isso significa que o modelo está aprendendo a estrutura visual do objeto, não apenas a presença de uma carta em cena.

A página real do projeto MTG detection no Universe mostra os chips de classes, a contagem de imagens e as métricas do modelo que o artigo discute. Assim o resto do texto permanece ancorado em uma fonte específica e inspecionável.

A Estratégia de Splits

O repositório segue a divisão clássica em três subconjuntos:

train: onde o modelo aprende
valid: onde o progresso de treino é acompanhado
test: onde a avaliação final precisa permanecer honesta

Train, validation e test não são burocracia. Eles separam aprendizado, seleção de modelo e avaliação honesta.

Essa separação importa porque um detector que performa bem em imagens que praticamente memorizou não tem utilidade como produto.

As Sete Classes

O conjunto de classes é simples, mas revela muito sobre o desenho do sistema:

art
card
description
mana-cost
power
tags
title

Isso não é um detector genérico de cartas. É um detector desenhado para servir um pipeline posterior. title existe porque o OCR precisa de um crop limpo. art existe porque a desambiguação visual de impressões depende de uma região específica. As classes refletem as necessidades do produto, e não uma organização arbitrária.

A legenda de classes torna a tarefa concreta: o detector está aprendendo um documento estruturado com sete regiões semânticas, e não apenas um rótulo global.

No editor do Universe, as mesmas sete classes aparecem como regiões preenchidas sobre a carta. É exatamente essa geometria que o detector precisa reproduzir em inferência, uma caixa de cada vez.

O Que Um Label YOLO Guarda

O formato de label é enxuto:

class_id center_x center_y width height

Todas as coordenadas são normalizadas para o intervalo [0, 1].

Essa simplicidade é uma vantagem prática. O mesmo formato também é impiedoso com labels ruins. Se a caixa estiver inconsistente, o modelo vai aprender exatamente essa inconsistência.

O arquivo de labels é compacto no disco, mas cada coordenada normalizada passa a fazer parte da verdade operacional do detector.

Dentro da plataforma cada caixa é um registro JSON com rótulo e coordenadas em pixel. A linha YOLO acima é apenas uma projeção normalizada dessa mesma estrutura.

Ruído de Anotação É Gargalo de Verdade

Um dos sinais mais úteis deste projeto está no desnível entre métricas relaxadas e métricas estritas. Quando mAP50 é forte, mas mAP50-95 cai de forma relevante, isso costuma indicar que o detector encontra a região correta de forma geral, mas não consegue manter caixas muito precisas sob critérios mais rigorosos.

Esse efeito pesa ainda mais em regiões pequenas como mana-cost e power. Em caixas grandes, um pequeno erro de coordenada mal aparece. Em caixas pequenas, o mesmo erro muda muito o IoU.

Uma grade real de amostras e o que transforma "o dataset parece bom" em algo que pode ser inspecionado antes de gastar computacao em treino.

Uma unica carta ja mostra o custo de precisao da tarefa: varias regioes semanticas pequenas precisam de caixas bem ajustadas para sustentar OCR e matching depois.

É por isso que modelos maiores nem sempre resolvem o problema certo. Se o limite estiver nos labels, aumentar a capacidade do modelo pode apenas fazê-lo memorizar melhor um alvo imperfeito.

Checagens de Qualidade Valem Mais do Que Parece

Os scripts de exploração deste repositório não são acessórios. Eles ajudam a responder perguntas fundamentais:

há labels faltando?
algumas classes aparecem pouco demais?
as caixas pequenas estão soltas ou apertadas demais?
treino e validação representam o mesmo mundo?

Sem esse tipo de checagem, tuning vira superstição cara.

O Loop de Correção É Parte da Arquitetura

Outro acerto do projeto é explicitar o ciclo de melhoria dos dados:

exportar predições
revisar exemplos
corrigir labels
reincorporar os dados corrigidos
retreinar

Isso mostra maturidade. O modelo não é treinado uma vez e abandonado. Dataset e detector evoluem juntos.

O editor Annotate é onde a pessoa que mantém o dataset realmente passa o tempo. Cada classe na barra lateral é uma caixa posicionada, conferida e ajustada carta por carta, e é por isso que qualidade de label vira custo real de engenharia.

Esse é o custo de base. Ele explica por que ferramentas assistidas são valiosas, mas também por que confiar cedo demais em automação costuma sair caro depois.

O painel de analytics expõe contagem de anotações, balanceamento de classes e distribuições por imagem. Automação comprime a primeira passada, mas um dashboard assim é o que deixa claro se o resultado continua confiável.

A leitura correta não é "automação substitui julgamento". É "automação comprime a primeira passada, para que a revisão humana se concentre nos casos difíceis".

A comparacao lado a lado deixa o trade-off claro: a velocidade melhora com automacao, mas a correcao continua dependendo de revisao e loops de ajuste.

Conclusão

Um detector aprende a definição de realidade que o dataset impõe. Se os labels forem consistentes e alinhados ao problema, o modelo tem chance de ficar forte. Se os labels forem ruidosos, a evolução vai estagnar mais cedo do que parece.

Este repositório acerta ao tratar dataset e labels como artefatos de engenharia de primeira classe.

Na próxima parte, saímos dos dados e entramos no treinamento: transfer learning, augmentations, otimização e os experimentos que empurraram o detector até o melhor resultado.

Leituras adicionais

Arquitetura e formatos de dados: docs/architecture.md
Conceitos e divisão dos dados: docs/concepts.md
Guia de métricas: docs/metrics-guide.md
Documentação do Roboflow: https://docs.roboflow.com/