Aprendizado Federado

Visão geral

Este documento apresenta interfaces que facilitam tarefas de aprendizado federado, como treinamento federado ou avaliação com modelos de aprendizado de máquina existentes implementados no TensorFlow. Ao projetar essas interfaces, nosso objetivo principal era tornar possível experimentar o aprendizado federado sem exigir o conhecimento de como ele funciona nos bastidores e avaliar os algoritmos de aprendizado federado implementados em uma variedade de modelos e dados existentes. Nós encorajamos você a contribuir de volta para a plataforma. TFF foi projetado com extensibilidade e composição em mente, e agradecemos contribuições; estamos ansiosos para ver o que você vai inventar!

As interfaces oferecidas por esta camada consistem nas três partes principais a seguir:

  • Modelos . Classes e funções auxiliares que permitem que você envolva seus modelos existentes para uso com o TFF. O encapsulamento de um modelo pode ser tão simples quanto chamar uma única função de encapsulamento (por exemplo, tff.learning.from_keras_model ), ou definir uma subclasse da interface tff.learning.Model para total personalização.

  • Construtores de Computação Federados . Funções auxiliares que constroem cálculos federados para treinamento ou avaliação, usando seus modelos existentes.

  • Conjuntos de dados. Coleções predefinidas de dados que você pode baixar e acessar em Python para uso na simulação de cenários de aprendizado federado. Embora o aprendizado federado seja projetado para uso com dados descentralizados que não podem ser simplesmente baixados em um local centralizado, nos estágios de pesquisa e desenvolvimento geralmente é conveniente realizar experimentos iniciais usando dados que podem ser baixados e manipulados localmente, especialmente para desenvolvedores que podem ser novo na abordagem.

Essas interfaces são definidas principalmente no namespace tff.learning , exceto para conjuntos de dados de pesquisa e outros recursos relacionados à simulação que foram agrupados em tff.simulation . Essa camada é implementada usando interfaces de nível inferior oferecidas pelo Federated Core (FC) , que também fornece um ambiente de tempo de execução.

Antes de prosseguir, recomendamos que você revise primeiro os tutoriais sobre classificação de imagens e geração de texto , pois eles apresentam a maioria dos conceitos descritos aqui usando exemplos concretos. Se você estiver interessado em aprender mais sobre como o TFF funciona, você pode dar uma olhada no tutorial de algoritmos personalizados como uma introdução às interfaces de nível inferior que usamos para expressar a lógica de computações federadas e estudar a implementação existente do interfaces tff.learning .

Modelos

Suposições arquitetônicas

Serialização

O TFF visa oferecer suporte a uma variedade de cenários de aprendizado distribuído nos quais o código do modelo de aprendizado de máquina que você escreve pode ser executado em um grande número de clientes heterogêneos com diversos recursos. Enquanto em uma extremidade do espectro, em algumas aplicações esses clientes podem ser poderosos servidores de banco de dados, muitos usos importantes que nossa plataforma pretende suportar envolvem dispositivos móveis e embutidos com recursos limitados. Não podemos presumir que esses dispositivos sejam capazes de hospedar runtimes do Python; a única coisa que podemos supor neste momento é que eles são capazes de hospedar um runtime local do TensorFlow. Assim, uma suposição de arquitetura fundamental que fazemos no TFF é que o código do seu modelo deve ser serializável como um gráfico do TensorFlow.

Você ainda pode (e deve) desenvolver seu código TF seguindo as práticas recomendadas mais recentes, como usar o modo ansioso. No entanto, o código final deve ser serializável (por exemplo, pode ser encapsulado como um tf.function para código de modo ansioso). Isso garante que qualquer estado do Python ou fluxo de controle necessário em tempo de execução possa ser serializado (possivelmente com a ajuda de Autograph ).

Atualmente, o TensorFlow não oferece suporte total à serialização e desserialização do TensorFlow no modo ansioso. Assim, a serialização no TFF atualmente segue o padrão TF 1.0, onde todo código deve ser construído dentro de um tf.Graph que o TFF controla. Isso significa que atualmente o TFF não pode consumir um modelo já construído; em vez disso, a lógica de definição do modelo é empacotada em uma função no-arg que retorna um tff.learning.Model . Essa função é então chamada pelo TFF para garantir que todos os componentes do modelo sejam serializados. Além disso, por ser um ambiente fortemente tipado, o TFF exigirá um pouco de metadados adicionais , como uma especificação do tipo de entrada do seu modelo.

Agregação

É altamente recomendável que a maioria dos usuários construa modelos usando Keras, consulte a seção Conversores para Keras abaixo. Esses wrappers lidam com a agregação de atualizações de modelo, bem como quaisquer métricas definidas para o modelo automaticamente. No entanto, ainda pode ser útil entender como a agregação é tratada para um tff.learning.Model geral.

Sempre há pelo menos duas camadas de agregação no aprendizado federado: agregação local no dispositivo e agregação entre dispositivos (ou federada):

  • Agregação local . Esse nível de agregação refere-se à agregação em vários lotes de exemplos pertencentes a um cliente individual. Aplica-se aos parâmetros do modelo (variáveis), que continuam a evoluir sequencialmente à medida que o modelo é treinado localmente, bem como às estatísticas que você calcula (como perda média, precisão e outras métricas), que seu modelo atualizará novamente localmente à medida que itera sobre o fluxo de dados local de cada cliente individual.

    A execução da agregação nesse nível é responsabilidade do código do seu modelo e é realizada usando construções padrão do TensorFlow.

    A estrutura geral do processamento é a seguinte:

    • O modelo primeiro constrói tf.Variable s para manter agregados, como o número de lotes ou o número de exemplos processados, a soma das perdas por lote ou por exemplo, etc.

    • O TFF invoca o método forward_pass em seu Model várias vezes, sequencialmente em lotes subsequentes de dados do cliente, o que permite atualizar as variáveis ​​que mantêm vários agregados como efeito colateral.

    • Por fim, o TFF invoca o método report_local_unfinalized_metrics em seu modelo para permitir que seu modelo compile todas as estatísticas de resumo coletadas em um conjunto compacto de métricas a serem exportadas pelo cliente. É aqui que o código do seu modelo pode, por exemplo, dividir a soma das perdas pelo número de exemplos processados ​​para exportar a perda média etc.

  • Agregação federada . Esse nível de agregação refere-se à agregação em vários clientes (dispositivos) no sistema. Novamente, ele se aplica aos parâmetros do modelo (variáveis), cuja média está sendo calculada entre os clientes, bem como às métricas que seu modelo exportou como resultado da agregação local.

    A execução da agregação neste nível é de responsabilidade da TFF. Como criador de modelos, no entanto, você pode controlar esse processo (mais sobre isso abaixo).

    A estrutura geral do processamento é a seguinte:

    • O modelo inicial e quaisquer parâmetros necessários para o treinamento são distribuídos por um servidor para um subconjunto de clientes que participarão de uma rodada de treinamento ou avaliação.

    • Em cada cliente, independentemente e em paralelo, seu código de modelo é invocado repetidamente em um fluxo de lotes de dados locais para produzir um novo conjunto de parâmetros de modelo (durante o treinamento) e um novo conjunto de métricas locais, conforme descrito acima (isto é local agregação).

    • O TFF executa um protocolo de agregação distribuído para acumular e agregar os parâmetros do modelo e as métricas exportadas localmente em todo o sistema. Essa lógica é expressa de maneira declarativa usando a própria linguagem de computação federada do TFF (não no TensorFlow). Consulte o tutorial de algoritmos personalizados para saber mais sobre a API de agregação.

Interfaces abstratas

Esse construtor básico + interface de metadados é representado pela interface tff.learning.Model , da seguinte forma:

  • Os métodos construtor, forward_pass e report_local_unfinalized_metrics devem construir variáveis ​​de modelo, passagem direta e estatísticas que você deseja relatar, de forma correspondente. O TensorFlow construído por esses métodos deve ser serializável, conforme discutido acima.

  • A propriedade input_spec , bem como as 3 propriedades que retornam subconjuntos de suas variáveis ​​treináveis, não treináveis ​​e locais representam os metadados. O TFF usa essas informações para determinar como conectar partes de seu modelo aos algoritmos de otimização federados e definir assinaturas de tipo interno para auxiliar na verificação da correção do sistema construído (para que seu modelo não possa ser instanciado em dados que não correspondam ao que o modelo é projetado para consumir).

Além disso, a interface abstrata tff.learning.Model expõe uma propriedade metric_finalizers que recebe os valores não finalizados de uma métrica (retornados por report_local_unfinalized_metrics() ) e retorna os valores finalizados da métrica. Os metric_finalizers e report_local_unfinalized_metrics() serão usados ​​juntos para construir um agregador de métricas entre clientes ao definir os processos de treinamento federados ou cálculos de avaliação. Por exemplo, um agregador tff.learning.metrics.sum_then_finalize simples somará primeiro os valores de métrica não finalizados dos clientes e, em seguida, chamará as funções do finalizador no servidor.

Você pode encontrar exemplos de como definir seu próprio tff.learning.Model personalizado na segunda parte de nosso tutorial de classificação de imagens , bem como nos modelos de exemplo que usamos para testar em model_examples.py .

Conversores para Keras

Quase todas as informações exigidas pelo TFF podem ser derivadas chamando as interfaces tf.keras , portanto, se você tiver um modelo Keras, poderá contar com tff.learning.from_keras_model para construir um tff.learning.Model .

Observe que o TFF ainda deseja que você forneça um construtor - uma função de modelo sem argumento, como a seguinte:

def model_fn():
  keras_model = ...
  return tff.learning.from_keras_model(keras_model, sample_batch, loss=...)

Além do próprio modelo, você fornece um lote de dados de amostra que o TFF usa para determinar o tipo e a forma da entrada do seu modelo. Isso garante que o TFF possa instanciar corretamente o modelo para os dados que realmente estarão presentes nos dispositivos clientes (já que presumimos que esses dados geralmente não estão disponíveis no momento em que você está construindo o TensorFlow a ser serializado).

O uso de wrappers Keras é ilustrado em nossos tutoriais de classificação de imagens e geração de texto .

Construtores de computação federada

O pacote tff.learning fornece vários construtores para tff.Computation s que executam tarefas relacionadas ao aprendizado; esperamos que o conjunto de tais cálculos se expanda no futuro.

Suposições arquitetônicas

Execução

Há duas fases distintas na execução de uma computação federada.

  • Compile : O TFF primeiro compila algoritmos de aprendizado federado em uma representação serializada abstrata de toda a computação distribuída. É quando a serialização do TensorFlow acontece, mas outras transformações podem ocorrer para dar suporte a uma execução mais eficiente. Referimo-nos à representação serializada emitida pelo compilador como uma computação federada .

  • Execute TFF fornece maneiras de executar esses cálculos. Por enquanto, a execução é suportada apenas por meio de uma simulação local (por exemplo, em um notebook usando dados descentralizados simulados).

Uma computação federada gerada pela API de aprendizado federado do TFF, como um algoritmo de treinamento que usa a média do modelo federado ou uma avaliação federada, inclui vários elementos, principalmente:

  • Uma forma serializada do código do seu modelo, bem como código TensorFlow adicional construído pela estrutura do Federated Learning para orientar o loop de treinamento/avaliação do seu modelo (como construir otimizadores, aplicar atualizações de modelo, iterar em tf.data.Dataset s e métricas de computação, e aplicando a atualização agregada no servidor, para citar alguns).

  • Uma especificação declarativa da comunicação entre os clientes e um servidor (geralmente várias formas de agregação entre os dispositivos do cliente e transmissão do servidor para todos os clientes) e como essa comunicação distribuída é intercalada com a execução local do cliente ou do servidor local do código TensorFlow.

Os cálculos federados representados neste formulário serializado são expressos em uma linguagem interna independente de plataforma distinta do Python, mas para usar a API de aprendizado federado, você não precisará se preocupar com os detalhes dessa representação. As computações são representadas em seu código Python como objetos do tipo tff.Computation , que na maioria das vezes você pode tratar como Python s callable opacos.

Nos tutoriais, você invocará essas computações federadas como se fossem funções regulares do Python, para serem executadas localmente. No entanto, o TFF foi projetado para expressar computações federadas de maneira agnóstica para a maioria dos aspectos do ambiente de execução, para que possam ser implantadas em, por exemplo, grupos de dispositivos executando Android ou clusters em um datacenter. Novamente, a principal consequência disso são fortes suposições sobre serialização . Em particular, quando você invoca um dos métodos build_... descritos abaixo, a computação é totalmente serializada.

Estado de modelagem

O TFF é um ambiente de programação funcional, mas muitos processos de interesse em aprendizado federado são stateful. Por exemplo, um loop de treinamento que envolve várias rodadas de média de modelo federado é um exemplo do que poderíamos classificar como um processo com estado . Nesse processo, o estado que evolui de rodada para rodada inclui o conjunto de parâmetros do modelo que estão sendo treinados e, possivelmente, o estado adicional associado ao otimizador (por exemplo, um vetor de momento).

Como o TFF é funcional, os processos com estado são modelados no TFF como cálculos que aceitam o estado atual como entrada e, em seguida, fornecem o estado atualizado como saída. Para definir completamente um processo com estado, também é necessário especificar de onde vem o estado inicial (caso contrário, não podemos inicializar o processo). Isso é capturado na definição da classe auxiliar tff.templates.IterativeProcess , com as 2 propriedades initialize e next correspondendo à inicialização e iteração, respectivamente.

Construtores disponíveis

No momento, o TFF fornece várias funções do construtor que geram cálculos federados para treinamento e avaliação federados. Dois exemplos notáveis ​​incluem:

Conjuntos de dados

Suposições arquitetônicas

Seleção do cliente

No cenário de aprendizado federado típico, temos uma grande população de potencialmente centenas de milhões de dispositivos clientes, dos quais apenas uma pequena parte pode estar ativa e disponível para treinamento a qualquer momento (por exemplo, isso pode ser limitado a clientes que são conectado a uma fonte de alimentação, não em uma rede limitada e, de outra forma, ocioso). Geralmente, o conjunto de clientes disponíveis para participar de treinamento ou avaliação está fora do controle do desenvolvedor. Além disso, como é impraticável coordenar milhões de clientes, uma rodada típica de treinamento ou avaliação incluirá apenas uma fração dos clientes disponíveis, que podem ser amostrados aleatoriamente .

A principal consequência disso é que os cálculos federados, por design, são expressos de uma maneira que ignora o conjunto exato de participantes; todo o processamento é expresso como operações agregadas em um grupo abstrato de clientes anônimos, e esse grupo pode variar de uma rodada de treinamento para outra. A ligação real da computação aos participantes concretos e, portanto, aos dados concretos que eles alimentam na computação, é modelada fora da própria computação.

Para simular uma implantação realista de seu código de aprendizado federado, você geralmente escreverá um loop de treinamento semelhante a este:

trainer = tff.learning.algorithms.build_weighted_fed_avg(...)
state = trainer.initialize()
federated_training_data = ...

def sample(federate_data):
  return ...

while True:
  data_for_this_round = sample(federated_training_data)
  result = trainer.next(state, data_for_this_round)
  state = result.state

Para facilitar isso, ao usar o TFF em simulações, os dados federados são aceitos como list do Python, com um elemento por dispositivo cliente participante para representar o tf.data.Dataset local desse dispositivo.

Interfaces abstratas

Para padronizar o tratamento com conjuntos de dados federados simulados, o TFF fornece uma interface abstrata tff.simulation.datasets.ClientData , que permite enumerar o conjunto de clientes e construir um tf.data.Dataset que contém os dados de um determinado cliente. Esses tf.data.Dataset s podem ser alimentados diretamente como entrada para os cálculos federados gerados no modo ansioso.

Deve-se notar que a capacidade de acessar identidades de clientes é um recurso fornecido apenas pelos conjuntos de dados para uso em simulações, onde a capacidade de treinar em dados de subconjuntos específicos de clientes pode ser necessária (por exemplo, para simular a disponibilidade diurna de diferentes tipos de clientes). Os cálculos compilados e o tempo de execução subjacente não envolvem nenhuma noção de identidade do cliente. Depois que os dados de um subconjunto específico de clientes são selecionados como entrada, por exemplo, em uma chamada para tff.templates.IterativeProcess.next , as identidades dos clientes não aparecem mais nele.

Conjuntos de dados disponíveis

Dedicamos o namespace tff.simulation.datasets para conjuntos de dados que implementam a interface tff.simulation.datasets.ClientData para uso em simulações e o semeamos com conjuntos de dados para suportar os tutoriais de classificação de imagens e geração de texto . Gostaríamos de incentivá-lo a contribuir com seus próprios conjuntos de dados para a plataforma.