Sintesi Tecnica: STELLA – Traduzione Efficiente da Sensore a LLM per il Riconoscimento dell'Attività Umana su Dispositivi Edge

1. Definizione del Problema

Il Riconoscimento dell'Attività Umana (HAR) tramite sensori IMU (Inertial Measurement Unit) è fondamentale per l'informatica mobile e ubiqua. Sebbene i Large Language Models (LLM) offrano capacità promettenti di ragionamento semantico e generalizzazione, l'implementazione di un HAR basato su LLM su dispositivi edge affronta tre ostacoli primari:

1. Discrepanza di Input e Costi: Gli LLM sono progettati per sequenze brevi di token linguistici discreti. I dati grezzi dei sensori consistono in flussi continui di valori in virgola mobile multi-canale e di lunga durata. Serializzare questi dati direttamente crea prompt eccessivamente lunghi, gonfiando i costi di attenzione quadratica dell'LLM e l'uso della memoria KV-cache oltre i budget dei dispositivi edge.
2. Perdita di Generalità: Il fine-tuning o la riscrittura di un LLM per ingerire direttamente i dati grezzi dei sensori trasforma un modello general-purpose in un classificatore specifico per un compito. Ciò vanifica lo scopo del deployment edge, dove i dispositivi ospitano tipicamente un singolo LLM condiviso per molteplità di modalità (testo, voce, visione) piuttosto che mantenere molteplici modelli specializzati.
3. Privacy e Latenza: L'invio dei dati dei sensori a LLM basati su cloud introduce dipendenza dalla rete, latenza illimitata e significativi rischi per la privacy, trasmettendo dati comportamentali sensibili fuori dal dispositivo.

Gli approcci esistenti si affidano o ad API cloud (sacrificando privacy e garanzie in tempo reale) o tentano di comprimere/effettuare il fine-tuning dell'LLM stesso (sacrificando riutilizzabilità e generalizzabilità). Manca un'interfaccia efficiente che permetta a un LLM general-purpose congelato di ragionare sui dati dei sensori senza modifiche.

2. Metodologia: STELLA

STELLA (Sensor Tokenization for Edge LLM Activity Recognition) inquadra il problema non come "adattamento dell'LLM", ma come "tokenizzazione del sensore". L'architettura core consiste in tre componenti principali:

2.1 Tokenizzatore Sensoriale Gerarchico (STELLA-Tower)

Invece di elaborare flussi numerici grezzi, STELLA impiega un encoder gerarchico leggero che comprime un intero window multi-canale di sensori ($C \times T$) in un set fisso di $N$ token sensoriali latenti (default $N=16$).

• Stack Convoluzionale: Convoluzioni iniziali depthwise e pointwise estraggono pattern temporali locali e mescolano le informazioni cross-channel riducendo la risoluzione temporale.
• Stadi Gerarchici: L'encoder utilizza tre stadi. Gli stadi iniziali utilizzano blocchi RepMixer (mixer riparametrizzabili basati su convoluzioni) per un'estrazione efficiente delle feature locali. Un livello finale di Multi-Head Self-Attention (MHSA) cattura le dipendenze a lungo raggio sulla sequenza già sottocampionata.
• Aggregazione Multi-Scala: Le feature di tre livelli gerarchici (pattern di movimento locale, dinamiche di attività e contesto globale) vengono aggregate in un numero fisso di token tramite interpolazione lineare e concatenazione.
• Proprietà Chiave: L'output è una sequenza di lunghezza fissa di token indipendentemente dal numero di canali dei sensori o dalla lunghezza della finestra, garantendo che il costo dell'LLM a valle rimanga invariante rispetto alla configurazione del sensore.

2.2 Proiezione e Integrazione

I token sensoriali latenti sono proiettati nello spazio di embedding di un LLM pre-addestrato e congelato (es. GPT-2) utilizzando un MLP (Multi-Layer Perceptron) superficiale. Questi token proiettati vengono concatenati con un prompt di task in linguaggio naturale (es. "Predict the human activity from the sensor data"). L'LLM rimane congelato; solo il tokenizzatore e i livelli di proiezione vengono addestrati.

2.3 Inferenza tramite Scoring delle Etichette

Invece di generare testo a forma libera, STELLA tratta la classificazione come un problema di scoring delle etichette. Per un set chiuso di etichette di attività candidate, il sistema calcola la media della log-likelihood per token (Negative Log-Likelihood) assegnata dalla sequenza di token di ogni candidato da parte dell'LLM congelato. L'etichetta con il punteggio più alto viene selezionata. Questo approccio evita l'imprevedibilità degli output generativi e mantiene breve la lunghezza del prompt.

2.4 Personalizzazione On-Device

STELLA supporta la personalizzazione senza effettuare il fine-tuning dell'LLM. Dopo il deployment, il leggero tokenizzatore sensoriale viene adattato ai dati di un utente specifico utilizzando una piccola quantità di campioni etichettati. Inoltre, un meccanismo di recupero locale aumenta l'inferenza:

• Viene mantenuta on-device una base di conoscenza degli embedding e delle etichette dei sensori passati dell'utente.
• Durante l'inferenza, i top-$k$ contesti storici più simili vengono recuperati e preposti all'input corrente.
• Ciò consente al sistema di adattarsi allo stile di deambulazione e di movimento individuale mantenendo tutti i dati e il contesto dell'utente strettamente on-device.

3. Contributi Chiave

1. Riformulazione del Collo di Bottiglia: Il paper sostiene che il collo di bottiglia dell'efficienza per l'LLM-based HAR sia l'interfaccia sensore-LLM, non l'LLM stesso. Propone di risolverlo tramite un tokenizzatore sensoriale appreso piuttosto che comprimendo l'LLM.
2. Tokenizzazione Invariante alla Configurazione: La STELLA-Tower comprime finestre di sensori multi-canale di lunghezza variabile in un set fisso di token latenti ($N=16$). Questo decoppia il costo di inferenza dell'LLM dalla configurazione del sensore, riducendo il conteggio dei token fino a $262.5\times$ rispetto alla codifica a livello scalare.
3. Personalizzazione Leggera e Privata: Il framework consente l'adattamento on-device aggiornando solo il tokenizzatore (circa il 10% dei parametri) e utilizzando un contesto di recupero locale, preservando l'LLM come backend riutilizzabile e congelato.
4. Performance State-of-the-Art con un Piccolo LLM: STELLA raggiunge nuovi risultati SOTA su sette dataset pubblici di HAR utilizzando solo un backbone GPT-2 congelato, superando metodi che si affidano a LLM molto più grandi o API basate su cloud.

4. Risultati Sperimentali

Gli autori hanno valutato STELLA su sette dataset (HHAR, PAMAP2, MHEALTH, GOTOV, SKODA, Opportunity, USC-HAD) coprendo da 6 a 60 canali e da 6 a 18 classi di attività.

• Accuratezza: STELLA ha raggiunto nuove performance SOTA su tutti gli otto setting di benchmark. I miglioramenti rispetto ai metodi precedenti variano da marginali su benchmark saturi a sostanziali su dataset con sensori sparsi (es. +11.83% F1 su HHAR, +9.20% F1 su USC-HAD).
• Efficacia del Tokenizzatore: Confrontato con rappresentativi encoder di serie temporali (PatchTST, Chronos, TimesNet, ecc.) sotto lo stesso pipeline LLM e budget di token, il tokenizzatore di STELLA ha costantemente superato i precedenti, confermando che i guadagni derivano dal design specifico della traduzione sensore-LLM.
• Fattibilità On-Device:
  • Latenza: L'inferenza è in tempo reale su hardware comune. Su una GPU server, la latenza è di circa 9.7 ms; su uno smartphone flagship (Samsung S23 Ultra) con accelerazione GPU, è di circa 41.7 ms. Anche su una CPU a singolo thread, soddisfa i vincoli in tempo reale per gli standard di stride.
  • Memoria: Il modello completo (FP32) richiede circa 555 MB, rientrando nei vincoli di memoria delle moderne GPU mobili (1 GB+ VRAM).
• Personalizzazione: L'adattamento del tokenizzatore e l'uso del recupero aumentano l'F1 score per i soggetti più difficili fino al 21.91% (es. da 70.79% a 92.70% su USC-HAD) con un overhead di recupero inferiore a 1 ms.

5. Significato e Claim

Il paper sostiene che STELLA fornisca una via pratica verso un HAR basato su LLM accurato, privato e personalizzato su dispositivi edge. La sua importanza risiede nel:

• Preservare l'LLM General-Purpose: Spostando l'onere dell'adattamento sul lato sensore, STELLA permette all'HAR di essere trattato come un'altra modalità di input per un LLM locale condiviso a livello di sistema, invece di richiedere uno stack di modelli separati e sottoposti a fine-tuning.
• Privacy ed Efficienza: Permette un HAR continuo, in tempo reale e interamente on-device, eliminando la necessità di trasmettere dati comportamentali sensibili al cloud.
• Scalabilità: L'interfaccia a token fissi assicura che la latenza di inferenza e l'uso della memoria rimangano prevedibili indipendentemente dal numero di sensori o dalla lunghezza della finestra di dati, rendendo il sistema robusto a diverse configurazioni hardware.

Gli autori concludono che la tokenizzazione efficiente dei sensori, piuttosto che la compressione dell'LLM o l'offloading in cloud, è la chiave per sbloccare il potempo degli LLM per il sensing basato su edge.