Book a Demo!
CoCalc Logo Icon
StoreFeaturesDocsShareSupportNewsAboutPoliciesSign UpSign In
tensorflow
GitHub Repository: tensorflow/docs-l10n
Path: blob/master/site/pt-br/federated/collaborations/notes/2022-02-16.md
25118 views

Notas do encontro dos colaboradores do TFF em 16/02/2022

  • Participantes:

    • Krzysztof Ostrowski (Google)

    • Alex Ingerman (Google)

    • DeWitt Clinton (Google)

    • Boyi Chen (LinkedIn)

    • Souvik Ghosh (LinkedIn)

    • Zheng Li (LinkedIn)

  • [Chen] Nosso uso atual, áreas de interesse para contribuições, processos de como contribuir; plano de desenvolvimento futuro

  • [Boyi] Como estamos usando o FL atualmente

    • Duas partes: uma é intersilos

      • Dados dos nossos usuários

      • Requisitos legais de restrição de acesso aos dados

      • O FL é útil para dados de terceiros

      • É possível usar os dados e permanecer em conformidade com as regulamentações

    • FL no dispositivo – interessante, mas funcionando principalmente em intersilos

    • Alguns projetos que poderíamos fazer

      • Temos criado protótipos

      • O TFF é útil

      • Comparação de FL com aprendizado por transferência personalizado

        • Uso dos dados de clientes para treinar um modelo personalizado para cada cliente versus aprendizado por transferência, comparar

        • Desafios de como o FL funciona

          • Alguns clientes maiores do que outros -> bias

          • Os clientes que mais contribuem estão preocupados o efeito carona; os clientes com menos dados estão preocupados em não influenciar o modelo o suficiente

        • Desafios de escalabilidade

          • No momento, para inferência (centenas de M)

          • Dados de treinamento não muito grandes atualmente (10s-100sK/silo)

          • Executar a inferência no lote acima de O(centenas de M) clientes

          • Volume total de dados como o principal desafio

            • Registros em todos os clientes

          • O tamanho do cluster é limitado no momento, o que limita a taxa de inferência

        • Cliente = silo que não pode ter os dados combinados com outros silos. Qual é a cardinalidade?

          • Fazendo experimentos atualmente, queremos dimensionar para centenas de silos no futuro

        • Qual o número de clientes do TFF observado?

          • No dispositivo: grande número de pequenos silos de dados; x-silo é um número pequeno de datasets grandes

        • Qual é o nível de similaridade entre os silos?

          • Os esquemas são os mesmos, mas a distribuição de dados difere bastante entre os silos. Participação desigual

      • [K] Você está pensando no TFF para inferência, bem como treinamento?

        • [B] No momento, usamos o TFF para treinamento; preferiríamos fazer o treinamento e a inferência no mesmo framework.

        • [K] Mesma infraestrutura ou mesmos modelos?

        • [B] No momento, mesmo modelo e mesmo cluster

      • [B] Queremos entender como treinar modelos e implantar em dispositivos.

      • [S] A necessidade de treinar modelos em um ambiente, pegar o resultado e usar em outro ambiente é importante. Apenas não com a primeira aplicação.

  • [B] O que queremos construir:

    • Uma ideia para contribuição: após fazermos comparativos da equidade, podemos adicionar ferramentas e referenciais ao TFF

      • Como o modelo se sai entre os silos (desempenho e bias desiguais)

    • [K] Você vê isso como um problema na prática? [B] Acreditamos que será um problema na prática.

    • [B] Pense nisso sob uma perspectiva adversária. As pessoas ficarão preocupadas em colocar os dados na solução. É uma preocupação geral, mas não temos uma métrica específica.

    • [K] O que estamos tratando? Você está falando da situação em que há silos + regulamentações sobre como processá-los – mas não é adversário, você apenas não quer criar bias versus outra situação em que há diversas instituições, partes mutuamente desconfiadas. Estamos pensando em um caso só ou nesses dois casos?

    • [B] Queremos avaliar os dois casos. No momento, estamos pensando só no segundo.

    • [D] Por exemplo: silo são as empresas, e os datasets são os dados carregados por cada empresa

    • [K] Você está realçando problemas sobre o efeito carona, mas também há partes mutuamente desconfiadas. Como as partes querem evitar que outros/você vejam os dados? Essas preocupações vieram à tona. Por um lado, queremos verificar a contribuição para impedir ataques e, por outro, não queremos ver o conteúdo por questões de privacidade.

    • [B] Veja isso de duas formas. Uma é a preservação da privacidade por meio de DP, etc. Outra parte, sob a perspectiva do desempenho do modelo quando treinado com dados de diversos silos, há uma preocupação de que diferentes silos se beneficiem de forma diferente. Achamos que há uma forma padrão de tratar o primeiro caso. Já o segundo caso é mais complicado.

    • [K] Equidade no sentido de que o modelo tem bom desempenho; outro pode ser o caso do efeito carona. É esse último caso com preocupações de privacidade. Você tem essa preocupação?

    • [B] Os dois casos são igualmente importantes. Queremos tanto proteger a privacidade dos dados quanto ter uma forma justa de distribuir os benefícios.

    • [S] Ainda não temos boas respostas. [K] Idem.

    • [D] Em que nível essas empresas confiam no LinkedIn para operar isso?

    • [S] A confiança não foi um problema até o momento, pelo menos nos exemplos que conheço. Tivemos algumas solicitações de restrição, mas nenhuma recusa total. As pessoas estão dispostas a compartilhar os dados com a gente para gerar um benefício comum.

    • [A] Preocupação com privacidade somente dos silos ou dos indivíduos dentro dos silos?

    • [S] O segundo caso.

  • [D] Isso está sendo construído no Azure? Precisamos pensar em algum outro aspecto do desenvolvimento?

    • [S] Uma hora, as GPUs entrarão em cena; os modelos iniciais serão menores e terão menos necessidades. Uma hora, isso vai evoluir para um grande número de membros e empresas e, portanto, os modelos ficarão bem maiores.

    • [D] É o mesmo Azure disponível publicamente? Ou é alguma infraestrutura interna, não visível para o mundo externo?

    • [S] É bem padrão.

    • [D] Facilita a colaboração, deixa o código aberto mais valioso, já que todos podem executá-lo no Azure público.

  • [K] Vamos criar alguma coisa! O que deve ser? Mencionamos um conjunto referencial e plataforma intersilos. O que vocês acham de criar um documento de requisitos de produto público, falar sobre recursos e casos de uso?

    • [Z] Qual é a especificação do produto? Pequenos componentes no TFF?

    • [K] Podemos falar sobre componentes ou um produto que pode ser construído com o TFF e disponibilizado para outras pessoas.

    • [Z] Quero entender uma coisa – esse é o processo de contribuição? Começar pelo produto?

    • [K] Estamos criando o processo aqui. Depende do que te deixa à vontade.

    • [Z] Você tem exemplos desse tipo de produto, talvez fora do TFF, mas no TF?

    • [K] O TF tem um processo para criar documentação. Podemos começar transformando estas notas em uma documentação. Por exemplo: silos, mutuamente desconfiados, queremos usar técnicas como DP, precisamos trabalhar no Azure.

    • [D] Ter um diretório de casos de uso seria interessante, sem revelar informações.

    • [K] Queremos desenvolver um roteiro futuro, documentações, exemplos de casos de uso que existirão no TFF de qualquer forma. Podemos começar juntos. Se começar devagar for mais fácil, vamos por esse caminho.

    • [B] Vejo muitas pesquisas sobre os desafios no FL. Talvez possamos pegar algumas ferramentas para lidar com esses desafios e começar por aí. Por exemplo: similar ao efeito carona, heterogeneidade dos dados – parece um desafio comum em ambientes federados. As ferramentas serão úteis universalmente.

      • [K] Ferramentas para avaliar desafios? Ou componentes do sistema.

      • [B] Funcionalidades que o TFF pode oferecer.

      • [K] Concordo. Começar pelo documento de requisitos de produto fornece contexto para falar sobre recursos, mas também podemos falar sobre recursos isoladamente. Talvez possamos começar com um documento que descreva o desafio do efeito carona e depois trabalhar com ferramentas para lidar com isso.

      • [D] Também podemos trabalhar com pesquisadores. O LinkedIn tem o objetivo de gerar resultados de pesquisa, além do produto em si?

      • [Z] No curto prazo, ainda não para pesquisa.

  • [K] Parece que podemos começar com alguns documentos compartilhados para descrever alguns recursos ou componentes? Uma das partes pode começar. Podemos usar o Documentos Google e e-mails. Vamos definir o padrão como público.

  • [ostrowski] O que gostaríamos de construir e quais são os primeiros passos concretos que podemos dar

    • O objetivo é mais de um outro encontro – IAs para nós mesmos?

    • Começamos a descrever alguns produtos/projetos específicos

      • Pacote referencial

      • Plataforma intersilos com DP, equidade, proteções contra o efeito carona

    • Possíveis próximos passos

      • Criar um documento inicial de requisitos de produto e detalhar tudo abertamente em conjunto para cada tópico acima?

      • Começar a trocar ideias de design?

      • Planos potenciais para contribuições de desenvolvimento?

        • Componentes/recursos específicos que vocês gostariam de desenvolver?

    • Documentos específicos a serem criados:

      • Documento compartilhado que descreve o problema do efeito carona e requisitos de uma ferramenta ou recurso no TFF que possa tratá-lo.

      • Documento compartilhado que descreve os referenciais para bias entre silos com quantidades desiguais de dados, o que gostaríamos que o referencial mensurasse.

      • Documento compartilhado que define um novo componente que permitiria ao TFF funcionar em um ambiente Azure (a definir com qual camada ele precisará se integrar).

  • [Ostrowski] Comunicação aberta

    • O que disponibilizar publicamente (na página de destino do GitHub).

    • Resumo das conversas e decisões, além de encontros futuros a serem disponibilizados em alguns dias após cada encontro na página do GitHub.

    • Links para documentações (planos, roteiros futuros, documentos de design, etc. a serem criados), que também serão publicadas no GitHub.

    • Conversas (bate-papo?)

      • Slack

    • Objetivos em comum:

      • Produtos/componentes específicos no escopo?

      • Estatuto para um grupo de trabalho mais específico/com escopo mais delimitado para embasar o desenvolvimento de tudo isso?

  • [B] O que fazer com pequenos problemas operacionais?

    • [K] O Slack ou os issues no GitHub podem servir. O que seria mais produtivo para vocês?

  • [Ostrowski] Podemos nos comprometer conjuntamente com uma programação recorrente de encontros?

    • Mensal