Résumé Technique : STELLA – Une traduction efficace Capteur-vers-LLM pour la reconnaissance d'activités humaines sur l'appareil

1. Énoncé du problème

La reconnaissance d'activités humaines (HAR - Human Activity Recognition) à partir de capteurs de mesure inertielle (IMU) est cruciale pour l'informatique mobile et ubiquitaire. Bien que les grands modèles de langage (LLM) offrent des capacités prometteuses de raisonnement sémantique et de généralisation, le déploiement de l'HAR basé sur les LLM sur les appareils de bord se heurte à trois obstacles majeurs :

1. Incompatibilité des entrées et coût : Les LLM sont conçus pour des séquences courtes de jetons (tokens) de langage discrets. Les données de capteurs brutes consistent en de longs flux multicanaux de valeurs flottantes continues. La sérialisation directe de ces données crée des prompts excessivement longs, gonflant les coûts d'attention quadratique du LLM et l'utilisation de la mémoire du cache KV au-delà des budgets des appareils de bord.
2. Perte de généralité : Le réglage fin (fine-tuning) ou la réécriture d'un LLM pour qu'il ingère directement des données de capteurs brutes transforme un modèle polyvalent en un classificateur spécifique à une tâche. Cela va à l'encontre de l'objectif du déploiement sur l'appareil, où les dispositifs hébergent généralement un seul LLM partagé pour plusieurs modalités (texte, voix, vision) plutôt que de maintenir plusieurs modèles spécialisés.
3. Confidentialité et latence : Le déchargement des données de capteurs vers des LLM basés sur le cloud introduit une dépendance au réseau, une latence non bornée et des risques importants pour la confidentialité en transmettant des données comportementales sensibles hors de l'appareil.

Les approches existantes reposent soit sur des API cloud (sacrifiant la confidentialité et les garanties de temps réel), soit tentent de compresser ou de procéder au réglage fin du LLM lui-même (sacrifiant la réutilisabilité et la généralisabilité). Il manque une interface efficace permettant à un LLM généraliste gelé de raisonner sur des données de capteurs sans modification.

2. Méthodologie : STELLA

STELLA (Sensor Tokenization for Edge LLM Activity Recognition) recadre le problème, passant de « l'adaptation du LLM » à la « tokenisation de capteurs ». L'architecture centrale se compose de trois composants principaux :

2.1 Tokeniseur de capteurs hiérarchique (STELLA-Tower)

Au lieu de traiter des flux numériques bruts, STELLA emploie un encodeur hiérarchique léger qui compresse l'intégralité d'une fenêtre de capteur multicanale ($C \times T$) en un ensemble fixe de $N$ jetons de capteurs latents (par défaut $N=16$).

• Pile de convolutions : Une pile initiale de convolutions de profondeur (depthwise) et de point (pointwise) extrait les motifs temporels locaux et mélange les informations inter-canaux tout en réduisant la résolution temporelle.
• Étapes hiérarchiques : L'encodeur utilise trois étapes. Les premières étapes utilisent des blocs RepMixer (des mélangeurs reparamétrisables basés sur des convolutions) pour une extraction efficace des caractéristiques locales. Une couche finale d'attention multi-têtes (Multi-Head Self-Attention - MHSA) capture les dépendances à longue portée sur la séquence déjà sous-échantillonnée.
• Agrégation multi-échelle : Les caractéristiques de trois niveaux hiérarchiques (motifs de mouvement locaux, dynamique de l'activité et contexte global) sont regroupées vers un nombre fixe de jetons via l'interpolation linéaire et la concaténation.
• Propriété clé : La sortie est une séquence de longueur fixe de jetons, quel que soit le nombre de canaux de capteurs ou la longueur de la fenêtre, garantissant que le coût du LLM en aval reste invariant à la configuration du capteur.

2.2 Projection et intégration

Les jetons de capteurs latents sont projetés dans l'espace d'embedding d'un LLM pré-entraîné et gelé (par exemple, GPT-2) à l'aide d'un perceptron multicouche (MLP) peu profond. Ces jetons projetés sont concaténés avec un prompt de tâche en langage naturel (par exemple, « Prédire l'activité humaine à partir des données du capteur »). Le LLM reste gelé ; seuls le tokeniseur et les couches de projection sont entraînés.

2.3 Inférence via le scoring de labels

Plutôt que de générer du texte libre, STELLA traite la classification comme un problème de scoring de labels. Pour un ensemble fermé de labels d'activités candidats, le système calcule la log-vraisemblance moyenne par jeton (Négative Log-Likelihood) attribuée par le LLM gelé à la séquence de jetons de chaque candidat. Le label ayant le score le plus élevé est sélectionné. Cette approche évite l'imprévisibilité des sorties génératives et maintient la longueur du prompt courte.

2.4 Personnalisation sur l'appareil

STELLA permet la personnalisation sans réglage fin du LLM. Après le déploiement, le tokeniseur de capteurs léger est adapté aux données d'un utilisateur spécifique à l'aide d'un petit nombre d'échantillons étiquetés. De plus, un mécanisme de récupération locale augmente l'inférence :

• Une base de connaissances des embeddings et des labels passés du capteur de l'utilisateur est maintenue sur l'appareil.
• Lors de l'inférence, les $k$ contextes historiques les plus similaires sont récupérés et prépendus à l'entrée actuelle.
• Cela permet au système de s'adapter à la démarche et aux styles de mouvement individuels tout en gardant toutes les données et le contexte strictement sur l'appareil.

3. Contributions clés

1. Recadrage du goulot d'étranglement : L'article soutient que le goulot d'étranglement de l'efficacité pour l'HAR basé sur les LLM est l'interface capteur-vers-LLM, et non le LLM lui-même. Il propose de résoudre cela via un tokeniseur de capteurs appris plutôt que par la compression du LLM.
2. Tokenisation invariante à la configuration : La STELLA-Tower compresse des fenêtres de capteurs multicanaux de longueur variable en un ensemble fixe de jetons latents ($N=16$). Cela découple le coût d'inférence du LLM de la configuration du capteur, réduisant le nombre de jetons jusqu'à $262,5\times$ par rapport à un encodage au niveau scalaire.
3. Personnalisation privée et légère : Le framework permet l'adaptation sur l'appareil en mettant à jour uniquement le tokeniseur (environ 10 % des paramètres) et en utilisant un contexte de récupération, préservant le LLM comme un backend réutilisable et gelé.
4. Performance de pointe avec un petit LLM : STELLA atteint de nouveaux résultats SOTA sur sept jeux de données publics en utilisant uniquement un backbone GPT-2 gelé, surpassant les méthodes qui reposent sur des LLM beaucoup plus grands ou des API basées sur le cloud.

4. Résultats expérimentaux

Les auteurs ont évalué STELLA sur sept jeux de données (HHAR, PAMAP2, MHEALTH, GOTOV, SKODA, Opportunity, USC-HAD) couvrant de 6 à 60 canaux et de 6 à 18 classes d'activités.

• Précision : STELLA a atteint de nouveaux résultats SOTA sur les huit configurations de référence. Les améliorations par rapport aux méthodes précédentes vont d'un gain marginal sur les benchmarks saturés à un gain substantiel sur les jeux de données à capteurs clairsemés (par exemple, +11,83 % de F1 sur HHAR, +9,20 % de F1 sur USC-HAD).
• Efficacité du tokeniseur : Comparé à des encodeurs de séries temporelles représentatifs (PatchTST, Chronos, TimesNet, etc.) sous le même pipeline LLM et le même budget de jetons, le tokeniseur de STELLA a systématiquement surpassé les autres, confirmant que les gains proviennent de la conception spécifique de la traduction capteur-vers-LLM.
• Faisabilité sur l'appareil :
  • Latence : L'inférence est en temps réel sur du matériel courant. Sur un GPU serveur, la latence est d'environ 9,7 ms ; sur un smartphone haut de gamme (Samsung S23 Ultra) avec accélération GPU, elle est d'environ 41,7 ms. Même sur un CPU mono-thread, elle respecte les contraintes de temps réel pour les budgets de foulée standards.
  • Mémoire : Le modèle complet (FP32) nécessite environ 555 Mo, ce qui s'inscrit dans les contraintes de mémoire des GPU mobiles modernes (1 Go+ de VRAM).
• Personnalisation : L'adaptation du tokeniseur et l'utilisation de l'augmentation par récupération ont amélioré le score F1 pour les sujets les plus difficiles jusqu'à 21,91 % (par exemple, de 70,79 % à 92,70 % sur USC-HAD) avec un surcoût de récupération de moins de 1 ms.

5. Signification et affirmations

L'article affirme que STELLA offre une voie pratique vers une HAR basée sur les LLM précise, privée et personnalisée sur les appareils de bord. Sa signification réside dans :

• Préservation du LLM polyvalent : En déplaçant la charge d'adaptation vers le côté capteur, STELLA permet à l'HAR d'être traitée comme une simple autre modalité d'entrée pour un LLM local partagé au niveau du système, plutôt que de nécessiter une pile de modèles distincts et ajustés.
• Confidentialité et efficacité : Elle permet une HAR continue et en temps réel entièrement sur l'appareil, éliminant le besoin de diffuser des données comportementales sensibles vers le cloud.
• Évolutivité : L'interface à jetons fixes garantit que la latence d'inférence et l'utilisation de la mémoire restent prévisibles quel que soit le nombre de capteurs ou la longueur de la fenêtre de données, rendant le système robuste aux variations de configurations matérielles.

Les auteurs concluent qu'une tokenisation efficace des capteurs, plutôt que la compression du LLM ou le déchargement vers le cloud, est la clé pour libérer le potentiel des LLM pour la détection sur l'appareil.