NLP no dispositivo: privacidade, velocidade e a fronteira do navegador

NLP no dispositivo: privacidade, velocidade e a fronteira do navegador

Aday
nlp on-device engineering

Quando um utilizador fala com um assistente virtual, o caminho mais rápido para uma resposta é aquele que nunca abandona o dispositivo. O NLP no dispositivo elimina a viagem de ida e volta a um servidor remoto, reduzindo a latência percebida de centenas de milissegundos para praticamente zero. Mais importante ainda, significa que as palavras que um utilizador escreve ou pronuncia são processadas localmente e descartadas localmente — nunca são transmitidas, nunca são registadas e nunca ficam à mercê da política de retenção de dados de um terceiro. Para aplicações que lidam com domínios sensíveis como saúde, finanças ou produtividade pessoal, isto não é uma funcionalidade opcional; é um requisito de base.

Executar modelos de inferência no navegador ou num dispositivo móvel é genuinamente difícil. O sandbox do navegador restringe o acesso a threads nativas, o cómputo em GPU está condicionado pela WebGL ou pela API WebGPU ainda em maturação, e os orçamentos de memória são limitados. No móvel, compete-se com o sistema operativo, os processos em segundo plano e o throttling térmico. As bibliotecas NLP tradicionais concebidas para Node.js ou Python do lado do servidor arrastam dependências transitivas que inflam o tamanho do bundle para além do que uma WebView móvel consegue carregar confortavelmente. O desafio de engenharia não é apenas fazer um modelo funcionar — é fazê-lo funcionar rápido o suficiente, pequeno o suficiente e de forma suficientemente fiável para que os utilizadores nunca deem por isso.

O motor NLP do Actor.dev, @noondra/nlp, foi concebido desde o início com estas restrições em mente. É um pacote TypeScript puro com uma única dependência em tempo de execução (budoux, para segmentação de limites de palavras em japonês). Não há nenhum addon nativo, nenhum blob WASM descarregado de uma CDN e nenhuma superfície de API Node.js — funciona de forma idêntica em V8, JavaScriptCore e Hermes. O motor gere a classificação de intenções, a extração de entidades, o preenchimento de slots e a gestão do estado do diálogo inteiramente em processo. Os pesos do modelo são serializados como estruturas JSON compactas que são carregadas uma vez e mantidas em memória durante a sessão, garantindo tempos de primeira resposta deterministas independentemente das condições de rede.

A troca honesta é precisão versus tamanho. Um classificador de intenções baseado em transformers superará um modelo TF-IDF com engenharia de características em entradas fora da distribuição, mas implica também entre 50 e 200 MB de pesos que têm inevitavelmente de ser descarregados e mantidos em RAM. Para a maioria dos casos de uso de assistentes conversacionais, a distribuição das entradas do utilizador é delimitada pelo domínio que o assistente cobre. Um modelo superficial bem treinado com boa cobertura desse domínio supera um modelo geral de grande dimensão que gasta a sua capacidade em tópicos que o utilizador nunca abordará. A abordagem do Actor.dev aposta precisamente nisso: os projetos NLP são treinados por agente, os modelos resultantes são pequenos e específicos do domínio, e a precisão em entradas dentro do domínio é competitiva com arquiteturas muito maiores. Quando uma consulta cai genuinamente abaixo do limiar de confiança do modelo, o runtime cede graciosamente a um LLM de fallback — mantendo o caminho rápido veloz enquanto preserva a qualidade onde importa.