Detecção de Objetos do Zero: Parte 6 - Colocando o Sistema no Ar

Quase todo projeto de ML parece pronto quando o modelo funciona. Quase todo usuário discorda.

O trabalho final não é treinar. É colocar o sistema no ar com fronteiras claras, UX coerente, tratamento de falhas e um caminho real de melhoria depois do lançamento.

A Camada Web É Onde o Projeto Vira Produto

O diretório web/ é a ponte entre scripts internos e uma superfície utilizável:

web/app.py organiza a API
web/services/ encapsula as dependências do pipeline
web/static/ oferece a interface do navegador

Essa separação importa porque deixa explícita a fronteira do produto. Scripts de treino podem evoluir sem quebrar a camada servida, desde que o contrato do modelo continue estável.

FastAPI Como Casca do Sistema

FastAPI é uma escolha prática aqui porque oferece:

fronteiras claras de request e response
integração simples com dependências Python
composição limpa entre serviços
espaço para validação, logging e observabilidade no futuro

O ponto mais importante é que a API não expõe apenas um detector. Ela expõe o resultado orquestrado de todo o pipeline. Isso reduz complexidade no frontend e concentra a lógica onde ela pode ser observada e testada.

Shipping significa permitir que o usuário saia de uma imagem crua e chegue a uma resposta confiável em uma única superfície de produto, não em scripts desconectados.

O Frontend Tem Dois Trabalhos

O frontend precisa servir bem tanto o fluxo de upload quanto o fluxo de webcam.

Esses modos têm exigências diferentes:

upload prioriza clareza e reprodutibilidade
webcam prioriza responsividade e confiança

Em visão computacional, confiança do usuário cresce quando ele enxerga evidências intermediárias. Bounding boxes, crops e painéis de detalhe ajudam a explicar por que o sistema respondeu daquele jeito.

Um unico frame real da webcam com regioes detectadas ja prova a exigencia de UI: o usuario confia mais quando enxerga evidencias intermediarias em vez de apenas uma resposta final silenciosa.

Limites Operacionais Precisam Ficar Claros

Esse sistema depende de componentes diferentes:

inferência do detector
runtime de OCR
disponibilidade do Scryfall
comparações de embedding com DINOv2

Isso transforma shipping em uma conversa operacional:

o que acontece se a busca no Scryfall falhar?
quais etapas são locais e quais dependem de rede?
como timeouts e falhas parciais devem aparecer para o usuário?
o que ainda pode ser mostrado mesmo quando a resolução completa falha?

Essas não são questões acadêmicas. São parte do produto.

O Loop de Correção Faz Parte da Operação

Um dos melhores elementos do repositório é o workflow de correção de anotações. Ele não deveria ser visto como apêndice. É o mecanismo pelo qual o sistema aprende com o próprio uso.

O loop de correção não é um detalhe lateral. Erros de produção são coletados, reanotados e reincorporados ao treino para fortalecer o sistema exatamente onde ele falha no mundo real.

Essa é a resposta madura para drift, casos de borda e lacunas do dataset inicial. O produto ensina o dataset onde ele ainda é fraco.

Limitações Precisam Ser Ditas em Voz Alta

O próprio projeto já oferece informação suficiente para assumir algumas limitações reais:

regiões pequenas são mais difíceis de localizar com precisão
qualidade de anotação ainda parece limitar métricas mais estritas
OCR depende fortemente de crops limpos
desambiguação de impressão depende tanto de recuperação de candidatos quanto de similaridade visual
escalar hardware não resolve automaticamente um teto imposto pelos dados

Esse tipo de honestidade aumenta confiança. Um sistema fica mais forte quando seus limites são legíveis.

Onde Estão as Próximas Melhorias

Se eu continuasse este projeto, as melhorias mais promissoras estariam aqui:

labels melhores para classes pequenas e difíceis
mais casos reais de webcam
métricas end-to-end por etapa do pipeline
medição dos erros reais do usuário
instrumentação de latência e falha em OCR, Scryfall e matching

Perceba que poucas dessas ideias começam com "treinar um modelo muito maior". Isso é deliberado.

Os passos futuros de maior valor se agrupam em dados melhores, loops de avaliação mais fortes e melhores superfícies de produto, não apenas em um checkpoint maior.

Conclusão

Colocar um sistema de visão computacional no ar significa aceitar que o modelo é apenas uma camada de um contrato maior com o usuário.

Este projeto acerta justamente nisso. Ele treina um detector forte, mas também constrói scripts, API, serviços, frontend e workflow de correção para transformar esse detector em algo realmente utilizável.

É isso que o torna um projeto de engenharia interessante, e não só uma entrada de benchmark.

Leituras adicionais

Solução completa: docs/solution.md
Workflow de correção: docs/annotation-correction.md
Arquitetura: docs/architecture.md