Por que o detector roda no seu navegador

Para que suas imagens nunca saiam do seu dispositivo. O modelo baixa uma vez e roda na sua máquina, o que elimina o upload, o custo do servidor e a relação de processamento de dados ao mesmo tempo.

O que a arquitetura realmente é

Um vision transformer, convertido para ONNX e comprimido para cerca de 40 MB, dividido em duas partes para que cada uma fique abaixo do limite de tamanho de arquivo da plataforma de hospedagem. Ele é remontado no navegador e seu checksum verificado antes que qualquer coisa seja executada.

A inferência ocorre por meio do WebAssembly, que permite que um runtime compilado execute a uma velocidade próxima à nativa dentro de uma aba do navegador. O próprio runtime é um binário WASM comprimido, carregado junto com os pesos.

Nada disso é mais exótico. O que era uma demonstração de pesquisa em 2021 é agora uma forma normal de distribuir um modelo, e os navegadores fizeram a maior parte do trabalho.

O que ela compra

Propriedade	No navegador	No servidor
A imagem sai do seu dispositivo	No impossível	Yes obrigatório
Custo por verificação	Yes zero	No processamento real
Acordo de processamento de dados necessário	No	Yes
Funciona sem rede após o carregamento	Yes	No
O modelo pode ser mantido privado	No é baixado	Yes
A primeira verificação é instantânea	No o modelo baixa uma vez	Yes

O mesmo produto, construído de duas maneiras. As diferenças são escolhas arquiteturais, não de política.

A primeira linha é a razão pela qual as outras existem. Como não há endpoint de upload, não há repositório de fotografias de outras pessoas, nenhuma política de retenção para escrever, nenhuma violação para divulgar e nada para entregar mediante solicitação.

A segunda linha é o motivo pelo qual pode ser gratuito, sem um medidor de uso. Uma verificação não custa nada para atender, portanto, não há custo por imagem a recuperar, o que altera a aparência da precificação.

O que custa

Três compensações reais, declaradas claramente, porque uma página que lista apenas vantagens é publicidade.

A primeira verificação é lenta. Quarenta megabytes precisam chegar antes que qualquer coisa aconteça. Em uma conexão rápida, isso leva alguns segundos; em uma lenta, leva mais. Verificações subsequentes reutilizam o modelo em cache e iniciam imediatamente.
Dispositivos antigos têm dificuldade. A inferência precisa de memória e processamento que um telefone de cinco anos pode não ter confortavelmente. Um servidor não se importaria com o dispositivo que você está segurando.
O modelo é público. Qualquer coisa baixada para um navegador pode ser mantida. Um modelo no lado do servidor pode ser proprietário; este não pode, e os pesos são um checkpoint de pesquisa aberto de qualquer forma.

O terceiro ponto vale a pena ser direto. Distribuir um modelo para o cliente significa entregá-lo. Essa é uma troca aceitável aqui porque os pesos já estão publicados, e o trabalho que torna a ferramenta útil é a calibração, a divisão em blocos e a interpretação construída em torno deles.

Os problemas de engenharia que vale a pena conhecer

Dividir um arquivo grande

Plataformas de hospedagem estática limitam o tamanho individual dos arquivos. Um modelo de 40 MB excedeu o limite, por isso é distribuído como duas partes determinísticas que são remontadas no navegador e verificadas em relação a um hash de manifesto antes do uso. Uma parte corrompida ou substituída falha ruidosamente em vez de produzir silenciosamente pontuações erradas.

Não carregar nada até que seja necessário

O modelo, o runtime e o leitor de credenciais não são buscados no carregamento da página. Eles chegam no primeiro engajamento, então alguém lendo um artigo nunca baixa nada disso. Isso mantém as páginas rápidas para a grande maioria dos visitantes que nunca executam uma verificação.

Decodificar formatos complexos

HEIC de iPhones, AVIF, TIFF e JPEG XL precisam de decodificação antes da pontuação. Os navegadores agora lidam com a maioria deles nativamente, o que remove o que costumava ser a maior parte do trabalho do lado do cliente em uma ferramenta como esta.

Quando essa arquitetura é a escolha errada

Ela não é universalmente melhor. Um servidor faz mais sentido quando o modelo é proprietário e vale a pena ser protegido, quando é grande demais para ser distribuído, quando você precisa de resultados em um pipeline de backend em vez de na frente de uma pessoa, ou quando você precisa de um tempo de resposta garantido, independentemente do dispositivo.

Para uma ferramenta que alguém abre para verificar uma imagem suspeita, nada disso se aplica, e a propriedade de privacidade vale mais do que tudo o que um servidor adicionaria.

O que isso descarta

Escolher o cliente tem consequências além da privacidade, e algumas delas são limitações que vale a pena nomear, em vez de recursos.

Não há histórico. Um resultado existe apenas na aba que o produziu, então nada pode ser consultado mais tarde, a menos que tenha sido exportado. Esse é o custo direto de não ter uma conta, e é a única coisa mais solicitada que a arquitetura torna complicada.

Não há estado compartilhado. Duas pessoas não podem ver a mesma fila, e uma equipe não pode revisar as verificações uma da outra. Um link compartilhado carrega um único resultado, que cobre uma conversa e não um fluxo de trabalho.

Não há API. Qualquer coisa rodando em uma aba do navegador não pode ser chamada de um pipeline de backend, o que descarta totalmente os usos de maior volume. Essas são lacunas reais, e a posição honesta é que elas são o preço da propriedade que importa mais.

Perguntas que as pessoas fazem

Minha imagem realmente não é carregada?

Sim, e você não precisa aceitar isso por confiança. Abra a aba de rede nas ferramentas do desenvolvedor e execute uma verificação. Você verá o download do modelo e do runtime, e nenhuma solicitação carregando seu arquivo. É uma das poucas alegações de privacidade que um usuário pode verificar diretamente em cerca de trinta segundos.

Por que o modelo é tão grande?

É um vision transformer com milhões de parâmetros, comprimido o máximo possível sem perder a precisão. Modelos menores existem e apresentam um desempenho visivelmente pior, particularmente nas imagens comprimidas e cortadas que as pessoas realmente verificam. Quarenta megabytes é o preço da precisão.

Funciona offline?

Após o primeiro carregamento, em grande parte sim. Assim que o modelo é armazenado em cache, a pontuação é executada sem rede alguma. A única parte que precisa de uma conexão é buscar uma imagem de uma URL colada; verificar um arquivo local funciona sem ela.

Isso vai drenar a bateria do meu telefone?

Uma única verificação leva alguns segundos de processamento, comparável ao carregamento de uma página da web pesada. Executar um lote de vinte e cinco é mais perceptível. Não é algo que você deixaria rodando, e não é um custo significativo para uso ocasional.

Vocês não poderiam usar WebGPU para torná-lo mais rápido?

Para dispositivos que o suportam, sim, e o suporte ainda é desigual o suficiente para que um caminho WASM tenha que existir de qualquer maneira. Adicionar um segundo caminho de execução dobra a superfície onde os resultados podem divergir entre os usuários, o que é um custo real contra um ganho de velocidade que a maioria das pessoas não notaria.

O navegador envia algo sobre minha imagem?

Não. Não há telemetria sobre nomes de arquivo, dimensões ou pontuações, porque o resultado nunca existe em lugar nenhum, exceto na sua aba. Essa é uma consequência da arquitetura, e não uma configuração, o que é a parte que vale a pena entender.