Resumo Técnico: Aprendizado Federado Robusto sob Rotatividade de Clientes no Mundo Real

Declaração do Problema

Os sistemas atuais de Aprendizado Federado (FL - Federated Learning) em produção são limitados por ciclos de atualização lentos, de vários dias, tornando-os inadequados para aplicações de streaming modernas (ex: ranking de feeds, direcionamento de anúncios) que exigem adaptação de modelos de hora em hora. As arquiteturas de FL existentes falham em configurações de produção do mundo real devido a três restrições interligadas:

1. Disponibilidade Transitória de Clientes: Dispositivos móveis e de borda exibem uma alta rotatividade (churn) em nível de minutos devido à bateria, rede e comportamento do usuário. Traços de produção indicam que a disponibilidade média frequentemente varia entre 15% e 50%. Estratégias de mitigação existentes (sobre-seleção, bloqueio de sincronia ou sondagem grosseira) ou desperdiçam recursos, ou travam o treinamento, ou perdem janelas de disponibilidade de curta duração.
2. Utilidade e Heterogeneidade Evolutivas dos Clientes: A utilidade do cliente é variável no tempo, combinando a informatividade dos dados com as capacidades de hardware. Algoritmos de seleção existentes dependem de conhecimento "oracular" da disponibilidade ou de traços históricos obsoletos, levando a uma seleção sistematicamente errônea (ex: priorizando dispositivos rápidos com dados irrelevantes enquanto negligencia dispositivos lentos com sinais recentes e informativos).
3. Frescor do Modelo vs. Atualizações Atrasadas: Em tarefas de produção, os rótulos de verdade fundamental (ground-truth labels, ex: conversões) frequentemente chegam horas após a interação inicial. As estratégias existentes forçam um compromisso: atualizar imediatamente com feedback de proxy ruidoso maximiza o frescor, mas introduz ruído; enquanto esperar pelo feedback completo melhora a qualidade do rótulo ao custo da obsolescência. Esquemas atuais de tratamento de obsolescência muitas vezes descartam atualizações atrasadas valiosas, desestabilizando a convergência.

Essas restrições fazem com que os sistemas de FL síncronos e assíncronos existentes travem, acumulem obsolescência ou falhem em convergir em configurações de streaming, conforme ilustrado pelo alargamento da lacuna de desempenho entre as suposições idealizadas e as implementações realistas.

Metodologia: O Sistema FeLiX

Os autores apresentam o FeLiX, um framework de orquestração de FL redesenhado que otimiza o tempo para atingir a precisão alvo em fluxos de interação ao vivo sem assumir conhecimento oracular do comportamento do cliente. O FeLiX trata a disponibilidade e a utilidade como entradas de controle de baixa latência através de três primitivas inovadoras:

1. Camadas de Disponibilidade Sensíveis ao Streaming (TierTrack)

O FeLiX introduz um protocolo leve, orientado pelo cliente, para segregar dinamicamente os clientes em três grupos baseados no estado em tempo real:

• AVL_TRAIN: Clientes disponíveis para treinamento e avaliação completos (ex: em Wi-Fi e carregando).
• AVL_EVAL: Clientes disponíveis apenas para avaliação leve (ex: bateria suficiente, mas não em Wi-Fi).
• UN_AVL: Clientes indisponíveis.
  Em vez de heartbeats periódicos e pesados, os clientes notificam proativamente o plano de controle ao ocorrerem mudanças de estado. Um mecanismo de temporizador leve de 90 segundos marca os clientes como indisponíveis se eles não responderem a uma atribuição de tarefa, garantindo que o servidor mantenha uma visão de alta fidelidade e em tempo real da população de clientes com overhead mínimo.

2. Seleção de Utilidade Fresca (TierSelect)

Para abordar a obsolescência das estimativas de utilidade, o FeLiX emprega um mecanismo de seleção de dois níveis:

• TrainSelector: Seleciona clientes do grupo AVL_TRAIN para maximizar o progresso esperado de aprendizado por rodada.
• EvalSelector: Envia proativamente avaliações de passagem direta (forward-pass) leves para clientes nos grupos AVL_TRAIN e AVL_EVAL, priorizando aqueles com estimativas de utilidade obsoletas.
  Essas avaliações são significativamente mais rápidas (até 20×) do que as execuções de treinamento completo. As utilidades retornadas atualizam um ClientMap central, permitindo que o TrainSelector priorize clientes que são tanto performantes em hardware quanto que refletem as mudanças recentes de distribuição mais relevantes. Esse mecanismo de "exploração" (scouting) garante que o sistema não dependa de dados históricos desatualizados.

3. Agregação Consciente de Informatividade e Robusta a Atrasos (TierFuse)

O FeLiX substitui a simples ponderação baseada em obsolescência por uma métrica híbrida que equilibra a idade da atualização com a utilidade estatística. O peso $w_i$ para uma atualização $u_i$ é calculado como:
$$w_i = \sigma \alpha(T_i) + (1 - \sigma) \beta(L_i)$$
Onde $T_i$ é a obsolescência, $L_i$ é a perda local (indicando informatividade) e $\sigma$ é um parâmetro de compromisso (tradeoff).

• Perda Alta ($L_i$): Indica que o modelo está mal alinhado com os dados do cliente; a atualização é valiosa mesmo se atrasada.
• Perda Baixa: Sugere que a atualização é menos crítica e pode ser reduzida em peso pelo tempo de idade.
  Esta abordagem permite que o FeLiX incorpore com segurança atualizações tardias e de alto valor que contêm resultados de verdade fundamental sem enviesar o modelo global para distribuições obsoletas ou descartar sinais de cauda longa valiosos.

Principais Resultados

O FeLiX foi avaliado em múltiplas modalidades (CIFAR-10 e Google Speech Commands) usando traços de baixa disponibilidade realistas (MobiPerf) e cenários sintéticos com graus variados de heterogeneidade de dados ($\alpha \in \{0.1, 1, 10, 100\}$) e disponibilidade (100%, 90%, 50% e traços do mundo real).

• Tempo para Precisão Alvo: O FeLiX reduz o tempo de relógio (wall-clock time) para atingir 70% de precisão em até 2.37× comparado às baselines Síncronas (OORT, REFL) e Assíncronas de última geração. Nos cenários mais desafiadores de baixa disponibilidade (50%) e alta heterogeneidade, o FeLiX supera a melhor baseline não-oracular em mais de 4×.
• Eficiência de Comunicação: O FeLiX economiza 1.30× de largura de banda total de comunicação em comparação com as baselines. Ao selecionar atualizações mais úteis precocemente e evitar a transmissão de atualizações que são posteriormente descartadas devido à obsolescência (um problema comum em esquemas assíncronos com buffer), o FeLiX garante que cada byte transmitido contribua para a convergência.
• Desempenho Oracular: Notavelmente, o FeLiX atinge um desempenho próximo ao oracular em configurações do mundo real sem acesso a traços futuros de clientes, superando baselines assistidas por oráculo em regimes específicos de baixa disponibilidade ao reagir reativamente a quedas no meio da rodada.
• Impacto dos Componentes:
  • TierTrack reduziu a duração mediana da rodada de ~259s para ~4.9s ao permitir a re-amostragem imediata de clientes que caíram.
  • TierSelect melhorou a seleção de clientes de alta utilidade, reduzindo o erro de seleção mesmo quando os clientes eram marginalmente mais lentos.
  • TierFuse preservou a contribuição de atualizações tardias (atribuindo pesos altos a mais de 90% das atualizações), enquanto esquemas padrão as descartavam ou penalizavam severamente.

Significância e Alegações

O artigo alega que o FeLiX altera fundamentalmente o paradigma da orquestração de FL de observação passiva para controle ativo de baixa latência. Ao preencher a lacuna entre as suposições teóricas idealizadas e a realidade "desordenada" dos ecossistemas de borda/móvel, o FeLiX permite:

1. Adaptação Rápida: Aplicações de streaming podem agora se adaptar a distribuições de dados voláteis (ex: tendências virais) em escalas de tempo de hora em hora, em vez de ciclos de vários dias.
2. Robustez: O sistema permanece eficaz sob condições adversas (alta rotatividade, heterogeneidade de dados, feedback atrasado) onde sistemas existentes travam ou falham em convergir.
3. Viabilidade Prática: O FeLiX demonstra que o desempenho "oracular" é alcançável em produção sem previsão irrealista, baseando-se em telemetria leve e lógica de seleção adaptativa.

Os autores posicionam o FeLiX como um framework necessário para que aplicações de alta escala e preservação de privacidade operem na velocidade da interação do usuário, garantindo que os modelos permaneçam sincronizados com os comportamentos mais recentes dos usuários.