NLP on-device: privacy, velocità e la frontiera del browser
Quando un utente parla con un assistente virtuale, il percorso più rapido verso una risposta è quello che non abbandona mai il dispositivo. L’NLP on-device elimina il viaggio di andata e ritorno verso un server remoto, riducendo la latenza percepita da centinaia di millisecondi a quasi zero. Ancor più importante, significa che le parole che un utente digita o pronuncia vengono elaborate localmente e scartate localmente — non vengono mai trasmesse, mai registrate e mai lasciate alla mercé della politica di conservazione dei dati di terze parti. Per le applicazioni che trattano domini sensibili come la salute, la finanza o la produttività personale, questo non è un optional: è un requisito di base.
Eseguire modelli di inferenza nel browser o su un dispositivo mobile è genuinamente difficile. Il sandbox del browser limita l’accesso ai thread nativi, il calcolo su GPU è vincolato da WebGL o dalla ancora immatura API WebGPU, e i budget di memoria sono ridotti. Su mobile, si compete con il sistema operativo, i processi in background e il throttling termico. Le librerie NLP tradizionali progettate per Node.js o Python lato server trascinano dipendenze transitive che fanno esplodere la dimensione del bundle oltre quanto una WebView mobile possa caricare comodamente. La sfida ingegneristica non è solo far girare un modello, ma farlo girare abbastanza velocemente, abbastanza in piccolo e in modo sufficientemente affidabile da far sì che gli utenti non se ne accorgano mai.
Il motore NLP di Actor.dev, @noondra/nlp, è stato progettato fin dall’inizio tenendo conto di questi vincoli. È un pacchetto TypeScript puro con un’unica dipendenza a runtime (budoux, per la segmentazione dei confini di parola in giapponese). Non c’è nessun addon nativo, nessun blob WASM scaricato da una CDN e nessuna superficie di API Node.js — funziona in modo identico su V8, JavaScriptCore e Hermes. Il motore gestisce la classificazione degli intent, l’estrazione delle entità, il riempimento degli slot e la gestione dello stato del dialogo interamente in-process. I pesi del modello sono serializzati come strutture JSON compatte, caricate una volta in memoria per l’intera sessione, garantendo tempi di prima risposta deterministici indipendentemente dalle condizioni di rete.
Il compromesso onesto è precisione contro dimensione. Un classificatore di intent basato su transformer supererà un modello TF-IDF con feature engineering su input fuori distribuzione, ma richiede anche tra 50 e 200 MB di pesi che è inevitabile scaricare e mantenere in RAM. Per la maggior parte dei casi d’uso di assistenti conversazionali, la distribuzione degli input degli utenti è delimitata dal dominio che l’assistente copre. Un modello leggero ben addestrato con buona copertura di quel dominio supera un grande modello generalista che spreca la propria capacità su argomenti che l’utente non affronterà mai. L’approccio di Actor.dev punta proprio su questo: i progetti NLP vengono addestrati per agente, i modelli risultanti sono piccoli e specifici del dominio, e la precisione sugli input in-domain è competitiva con architetture molto più grandi. Quando una query cade genuinamente al di sotto della soglia di confidenza del modello, il runtime cede elegantemente il controllo a un LLM di fallback — mantenendo il percorso veloce rapido e preservando la qualità dove conta.