Resumo Técnico: STELLA – Tradução Eficiente de Sensor para LLM para Reconhecimento de Atividade Humana em Dispositivos

1. Declaração do Problema

O Reconhecimento de Atividade Humana (HAR) a partir de sensores de Unidade de Medição Inercial (IMU) é crítico para a computação móvel e ubíqua. Embora os Grandes Modelos de Linguagem (LLMs) ofereçam capacidades promissoras de raciocínio semântico e generalização, a implantação de HAR baseado em LLM em dispositivos de borda enfrenta três obstáculos principais:

1. Descompasso de Entrada e Custo: Os LLMs são projetados para sequências curtas de tokens de linguagem discretos. Dados brutos de sensores consistem em fluxos longos, multicanais, de valores de ponto flutuante contínuos. Serializar esses dados diretamente cria prompts excessivamente longos, inflando os custos de atenção quadrática e o uso de memória do cache KV além dos orçamentos de dispositivos de borda.
2. Perda de Generalidade: Realizar o ajuste fino (fine-tuning) ou reescrever um LLM para ingerir dados brutos de sensores diretamente transforma um modelo de propósito geral em um classificador específico para uma tarefa. Isso anula o propósito da implantação em borda, onde os dispositivos normalmente hospedam um único LLM compartilhado para múltiplas modalidades (texto, voz, visão) em vez de manter múltiplos modelos especializados.
3. Privacidade e Latência: O envio de dados de sensores para LLMs baseados em nuvem introduz dependência de rede, latência ilimitada e riscos significativos de privacidade ao transmitir dados comportamentais sensíveis para fora do dispositivo.

Abordagens existentes dependem de APIs na nuvem (sacrificando privacidade e garantias de tempo real) ou tentam comprimir/ajustar o próprio LLM (sacrificando reusabilidade e generalizabilidade). Há uma falta de uma interface eficiente que permita a um LLM de propósito geral e congelado raciocinar sobre dados de sensores sem modificações.

2. Metodologia: STELLA

STELLA (Sensor Tokenization for Edge LLM Activity Recognition) reformula o problema de "adaptação de LLM" para "tokenização de sensores". A arquitetura central consiste em três componentes:

2.1 Tokenizador de Sensores Hierárquico (STELLA-Tower)

Em vez de processar fluxos numéricos brutos, o STELLA emprega um codificador hierárquico leve que comprime uma janela inteira de sensores multicanais ($C \times T$) em um conjunto fixo de $N$ tokens de sensores latentes (padrão $N=16$).

• Pilha Convolucional: Convoluções iniciais de profundidade (depthwise) e de ponto (pointwise) extraem padrões temporais locais e misturam informações entre canais enquanto reduzem a resolução temporal.
• Estágios Hierárquicos: O codificador utiliza três estágios. Os estágios iniciais utilizam blocos RepMixer (misturadores reparametrizáveis baseados em convoluções) para extração eficiente de características locais. Uma camada final de Auto-Atenção de Múltiplas Cabeças (MHSA) captura dependências de longo alcance na sequência já reduzida.
• Agregação Multiescala: Características de três níveis hierárquicos (padrões de movimento local, dinâmica de atividade e contexto global) são agrupadas para um número fixo de tokens via interpolação linear e concatenadas.
• Propriedade Chave: A saída é uma sequência de tokens de comprimento fixo, independentemente do número de canais do sensor ou do comprimento da janela, garantindo que o custo do LLM subsequente permaneça invariante à configuração do sensor.

2.2 Projeção e Integração

Os tokens de sensores latentes são projetados no espaço de embedding de um LLM pré-treinado e congelado (ex: GPT-2) usando um MLP (Perceptron Multicamadas) raso. Esses tokens projetados são concatenados com um prompt de tarefa em linguagem natural (ex: "Preveja a atividade humana a partir dos dados do sensor"). O LLM permanece congelado; apenas o tokenizador e as camadas de projeção são treinados.

2.3 Inferência via Pontuação de Rótulo

Em vez de gerar texto livre, o STELLA trata a classificação como um problema de pontuação de rótulo. Para um conjunto fechado de rótulos de atividades candidatas, o sistema calcula a média da log-verossimilhança por token (Log-Verossimilhança Negativa) atribuída pela sequência de tokens do LLM congelado a cada sequência de candidato. O rótulo com a maior pontuação é selecionado. Esta abordagem evita a imprevisibilidade de saídas generativas e mantém o comprimento do prompt curto.

2.4 Personalização no Dispositivo

O STELLA suporta personalização sem realizar ajuste fino do LLM. Após a implantação, o tokenizador de sensores leve é adaptado aos dados de um usuário específico usando uma pequena quantidade de amostras rotuladas. Adicionalmente, um mecanismo de recuperação local aumenta a inferência:

• Uma base de conhecimento dos embeddings e rótulos históricos de sensores do usuário é mantida no dispositivo.
• Durante a inferência, os $k$ contextos históricos mais similares são recuperados e prefixados à entrada atual.
• Isso permite que o sistema se adapte ao estilo de marcha e movimento individual enquanto mantém todos os dados e contexto do usuário estritamente no dispositivo.

3. Principais Contribuições

1. Reformulação do Gargalo: O artigo argumenta que o gargalo de eficiência para o HAR baseado em LLM é a interface sensor-para-LLM, não o próprio LLM. Propõe resolver isso via um tokenizador de sensores aprendido em vez de comprimir o LLM.
2. Tokenização Invariante de Configuração: O STELLA-Tower comprime janelas de sensores multicanais de comprimento variável em um conjunto fixo de tokens latentes ($N=16$). Isso desacopla o custo de inferência do LLM da configuração do sensor, reduzindo a contagem de tokens em até $262,5\times$ em comparação com a codificação ao nível escalar.
3. Personalização Privada e Leve: O framework permite a adaptação no dispositivo atualizando apenas o tokenizador (aprox. 10% dos parâmetros) e utilizando um contexto de recuperação, preservando o LLM como um backend reutilizável e congelado.
4. Desempenho de Estado da Arte com um Pequeno LLM: O STELLA alcança novos resultados SOTA em sete conjuntos de dados públicos de HAR usando apenas um backbone GPT-2 congelado, superando métodos que dependem de LLMs muito maiores ou APIs baseadas em nuvem.

4. Resultados Experimentais

Os autores avaliaram o STELLA em sete conjuntos de dados (HHAR, PAMAP2, MHEALTH, GOTOV, SKODA, Opportunity, USC-HAD) cobrindo de 6 a 60 canais e de 6 a 18 classes de atividade.

• Acurácia: O STELLA alcançou novo desempenho SOTA em todos os oito cenários de benchmark. As melhorias sobre métodos anteriores variaram de marginais em benchmarks saturados a substanciais em conjuntos de dados de sensores esparsos (ex: +11,83% F1 no HHAR, +9,20% F1 no USC-HAD).
• Eficácia do Tokenizador: Quando comparado contra codificadores de séries temporais representativos (PatchTST, Chronos, TimesNet, etc.) sob o mesmo pipeline de LLM e orçamento de tokens, o tokenizador do STELLA consistentemente superou-os, confirmando que os ganhos derivam do design específico de tradução sensor-para-LLM.
• Viabilidade no Dispositivo:
  • Latência: A inferência é em tempo real em hardware comum. Em uma GPU de servidor, a latência é de ~9,7 ms; em um smartphone topo de linha (Samsung S23 Ultra) com aceleração de GPU, é de ~41,7 ms. Mesmo em uma CPU de thread única, atende às restrições de tempo real para orçamentos de passada padrão.
  • Memória: O modelo completo (FP32) requer ~555 MB, cabendo dentro das restrições de memória de GPUs móveis modernas (1 GB+ de VRAM).
• Personalização: Adaptar o tokenizador e usar aumento de recuperação melhorou o F1 score para os sujeitos mais difíceis em até 21,91% (ex: de 70,79% para 92,70% no USC-HAD) com menos de 1 ms de overhead de recuperação.

5. Significância e Alegações

O artigo alega que o STELLA fornece um caminho prático para um HAR baseado em LLM preciso, privado e personalizado em dispositivos de borda. Sua significância reside em:

• Preservação do LLM de Propósito Geral: Ao deslocar o ônus da adaptação para o lado do sensor, o STELLA permite que o HAR seja tratado como apenas mais uma modalidade de entrada para um LLM local compartilhado de nível de sistema, em vez de exigir uma pilha de modelos separada e ajustada.
• Privacidade e Eficiência: Permite o HAR contínuo e em tempo real inteiramente no dispositivo, eliminando a necessidade de transmitir dados comportamentais sensíveis para a nuvem.
• Escalabilidade: A interface de tokens fixos garante que a latência de inferência e o uso de memória permaneçam previsíveis, independentemente do número de sensores ou do comprimento da janela de dados, tornando o sistema robusto a variações de configurações de hardware.

Os autores concluem que a tokenização eficiente de sensores, em vez da compressão de LLM ou offloading para a nuvem, é a chave para desbloquear o potencial dos LLMs para sensoriamento baseado em borda.