Cartões de visita sem nuvem: PaddleOCR no React Native acelerou de 7,8 para 3 segundos

Um scanner de cartões de visita parece uma tarefa de uma noite: fotografar, enviar para uma API e receber nome e telefone. Mas o cartão não é seu, e sim de um terceiro. O nome, o número e o cargo dessa pessoa vão parar num servidor sem o conhecimento dela, e na prática russa isso esbarra na lei 152-FZ. A equipe de que fala o autor de um artigo no Habr resolveu o problema de forma radical: a foto nunca sai do celular.

O que foi montado e por que sem LLM

A pilha é o PaddleOCR v5, executado via ONNX Runtime dentro de um aplicativo React Native para Android. Ou seja, o modelo de reconhecimento fica no dispositivo, e não é preciso rede para processar a imagem.

O autor menciona expressamente que o LLM foi descartado. O anúncio não traz detalhes, mas os motivos costumam ser claros. Um modelo grande no celular é pesado e lento. Se for chamado na nuvem, voltamos ao problema original: a foto sai do dispositivo. Para um cartão de visita, em que basta extrair alguns campos curtos, um OCR clássico com regras de análise costuma ser mais prático. Isso não é conclusão do artigo, mas uma referência geral de engenharia, que explica bem a escolha.

Um exemplo simples. O usuário fotografa o cartão, o OCR encontra os blocos de texto e os lê, e o aplicativo decide por modelos qual é o telefone, qual é o e-mail e qual é o nome. Tudo acontece localmente, e no fim a pessoa vê o cartão de contato preenchido.

De 7,8 para 3 segundos

O número mais expressivo do anúncio: o processamento da imagem acelerou de 7,8 para 3 segundos. A diferença é fundamental para o produto. Quase oito segundos de espera após a foto são percebidos pelo usuário como um aplicativo travado. Três segundos ainda são toleráveis, embora longe de uma resposta instantânea.

Como exatamente a aceleração foi obtida, o anúncio não diz; para os detalhes será preciso ler o texto completo. Mas o OCR local no celular tem os pontos habituais de otimização: o tamanho da imagem de entrada, o número de execuções de modelos na cadeia, o formato dos pesos e a forma de passar dados entre JavaScript e código nativo. No React Native, esse último costuma ser o gargalo.

A telemetria oculta do ONNX Runtime

O detalhe mais útil para quem trabalha na prática não é sobre velocidade, mas sobre privacidade. O autor escreve que o ONNX Runtime envia algo à Microsoft por padrão. O anúncio não especifica o quê nem em quais builds, então não é possível avaliar a escala exata do vazamento. Mas a lição importa: dizer que «o modelo funciona localmente» não garante que o aplicativo não acesse a rede.

Para um produto construído sobre o argumento de que «os dados não saem do dispositivo», isso é crítico. Se a política de privacidade promete uma coisa e uma biblioteca faz outra em silêncio, o resultado é risco jurídico e perda de confiança.

O que fazer como desenvolvedor e gerente de produto

• Verifique o tráfego de rede do aplicativo em um dispositivo real, e não apenas o código. Um proxy como o mitmproxy mostra para onde vão as requisições.
• Estude as configurações e os builds de cada dependência que lida com dados do usuário, sobretudo fotos e documentos. Desative tudo o que não for necessário.
• Inclua a velocidade nas métricas do produto. O processamento local quase sempre é mais lento que o da nuvem, e a diferença entre 7,8 e 3 segundos decide se a função será usada.
• Não adote um LLM por padrão. Para uma tarefa restrita e de estrutura clara, um OCR leve no dispositivo pode vencer em privacidade, custo e previsibilidade.

Limitações

Vimos apenas o anúncio: ele não traz medições completas, modelos de celular, precisão de reconhecimento nem comparação com soluções em nuvem. Os números de 7,8 e 3 segundos referem-se à configuração específica da equipe e podem variar em outro hardware. A interpretação jurídica da lei 152-FZ também depende do seu caso, então vale discutir a questão com um advogado.

Ainda assim, o caso mostra um caminho viável: perímetro de dados fechado, OCR aberto e maduro e verificação cuidadosa do que as dependências realmente fazem. Para equipes que desenvolvem aplicativos com dados pessoais, é um bom checklist para o próximo sprint.