Por que um modelo pronto não é suficiente? Uma lição prática sobre o ajuste fino de modelos de detecção de objetos em dados reais

A JetBrains apresenta um experimento prático para testar três modelos modernos de detecção de objetos — YOLO12, YOLO26 e RF-DETR — não apenas em dados padronizados, mas em imagens que representam situações mais próximas do uso real: danos em cabos, fraturas ósseas em radiografias e garrafas de bebidas empilhadas. A principal conclusão é clara: um modelo pré-treinado não é necessariamente um modelo pronto para implantação.

Os modelos foram baseados principalmente nos dados do COCO, que incluem cerca de 118 mil imagens de treinamento e 80 classes comuns, como pessoas, carros, cães e cadeiras. No entanto, alguns alvos práticos, como uma fratura óssea, nem sequer pertencem ao vocabulário dessas classes, enquanto radiografias, imagens industriais e cenas visualmente congestionadas diferem das imagens naturais às quais os modelos estão acostumados.

Verificação da linha de base antes do treinamento

Antes de passar ao ajuste fino, a JetBrains avaliou seis pontos de verificação, com dois tamanhos para cada uma das três famílias, no conjunto de validação do COCO val2017, composto por 5.000 imagens. O RF-DETR Base obteve o maior resultado de mAP50-95, de 0.5325, enquanto os dois modelos YOLO médios ficaram próximos, com 0.5259 e 0.5181, usando cerca de 10 milhões de parâmetros a menos.

A comparação também mostrou diferenças práticas de velocidade. O YOLO26-N registrou um tempo de 12.3 milissegundos, com um resultado de mAP50-95 próximo ao do YOLOv12-N, que registrou 23.9 milissegundos apesar de ser o menor modelo do experimento. Já o RF-DETR Nano apresentou um tempo de 12.4 milissegundos, embora tivesse quase 30 milhões de parâmetros, número superior ao do YOLO26-M.

Esses números não correspondem necessariamente aos publicados nos artigos dos modelos, porque o experimento usou hardware diferente da unidade NVIDIA T4 comum nas comparações e executou os modelos em suas estruturas originais, sem convertê-los para TensorRT. A JetBrains explica que o TensorRT pode reduzir o tempo de inferência ao fundir camadas e selecionar kernels otimizados para o hardware, mas exige uma etapa adicional de compilação e produz um mecanismo vinculado a uma unidade de processamento gráfico específica. Portanto, os números do experimento refletem um desempenho mais próximo da execução direta, e não o desempenho máximo possível após a otimização.

O teste fora do escopo do treinamento

O experimento utilizou três conjuntos do RF100-VL, uma coleção que reúne 100 conjuntos de dados multimodais projetados para abranger alvos raros nos dados de treinamento habituais. Os conjuntos selecionados foram bone-fracture-7fylg, cable-damage e soda-bottles.

Quando os pontos de verificação treinados no COCO foram executados diretamente nesses dados, o resultado foi praticamente nulo. A JetBrains explica isso pelo fato de os modelos utilizados serem detectores de vocabulário fechado: eles possuem um número definido de classes e não conseguem produzir uma classe como fracture se ela não estiver presente no cabeçalho do modelo, composto por 80 classes. Portanto, o fato de um modelo obter mAP50 de 0.72 no COCO não significa que ele reconhecerá automaticamente fraturas ósseas.

O que o ajuste fino muda?

A JetBrains ajustou os três modelos em cada conjunto de dados durante 10 épocas de treinamento, usando uma única unidade A100 e os fluxos de treinamento habituais do Ultralytics e do RF-DETR. Após o treinamento, os resultados melhoraram claramente nas tarefas de danos em cabos e garrafas de bebidas, enquanto a tarefa de fraturas ósseas permaneceu mais difícil.

As garrafas de bebidas foram o caso mais fácil: o resultado de mAP50 de todos os modelos ficou entre 0.91 e 0.97, e o YOLOv12-M obteve o melhor mAP50-95, de 0.6422. A JetBrains sugere que a razão é a proximidade das imagens de produtos com algumas classes presentes no COCO, o que torna o problema mais parecido com a adição de um novo vocabulário do que com uma transferência completa entre dois domínios visuais.

Na tarefa de danos em cabos, o mAP50 chegou a 0.93, mas o maior mAP50-95 não ultrapassou 0.446. Isso significa que os modelos conseguem localizar os danos com bom desempenho, mas têm dificuldade para desenhar caixas delimitadoras precisas ao redor de defeitos finos e alongados. Já nas imagens de fraturas ósseas, o melhor mAP50, registrado pelo RF-DETR Base, foi de apenas 0.447, com grande variação entre os modelos. A inspeção visual também mostrou que menos da metade das imagens continha uma fratura detectada em alguns resultados.

O que a equipe de desenvolvimento deve revisar?

• Comece com uma linha de base reproduzível: verifique o desempenho dos pontos de verificação em seu ambiente e hardware antes de comparar os resultados com os números publicados.
• Separe os ambientes de software: a JetBrains utilizou três ambientes uv isolados dentro de um único projeto do PyCharm, porque as versões da biblioteca ultralytics exigidas pelas gerações YOLO não são compatíveis. O uso do interpretador remoto no PyCharm requer a versão Professional, enquanto o Community Edition oferece suporte apenas a ambientes locais.
• Não se limite a uma única métrica: a diferença entre mAP50 e mAP50-95 nos danos em cabos revela um problema de posicionamento preciso que pode não aparecer ao observar apenas o mAP50.
• Relacione a escolha do modelo à tarefa: o RF-DETR Base apresentou maior consistência e venceu em dois dos três conjuntos de dados, mas isso não o torna o melhor para todos os casos.
• Planeje os dados quando a mudança for grande: os resultados das radiografias indicam que o ajuste fino sozinho pode não ser suficiente, e pode haver necessidade de mais dados, treinamento mais longo ou pré-treinamento especializado no domínio — opções apresentadas pelo material sem demonstrar a superioridade de nenhuma delas neste experimento.

O experimento confirma que os termos “avançado” ou “pré-treinado” não resumem a adequação de um modelo de detecção de objetos ao ambiente de implantação. A decisão prática deve equilibrar precisão, tempo de inferência, tamanho do modelo, requisitos de licenciamento e, sobretudo, o grau de semelhança entre os dados de treinamento e o domínio-alvo. Além disso, os resultados da JetBrains continuam vinculados aos três conjuntos e às configurações de treinamento utilizadas e, portanto, não devem ser generalizados como uma classificação definitiva para todas as tarefas de detecção.