Deze blogpost is geschreven in samenwerking met Chaoyang He en Salman Avestimehr van FedML.

Het analyseren van real-world healthcare and life sciences (HCLS)-gegevens brengt verschillende praktische uitdagingen met zich mee, zoals gedistribueerde gegevenssilo's, gebrek aan voldoende gegevens op één enkele locatie voor zeldzame gebeurtenissen, wettelijke richtlijnen die het delen van gegevens verbieden, vereiste infrastructuur en kosten voor het maken van een gecentraliseerde databank. Omdat ze zich in een sterk gereguleerd domein bevinden, zoeken HCLS-partners en -klanten naar privacybeschermende mechanismen om grootschalige, gedistribueerde en gevoelige gegevens te beheren en te analyseren.

Om deze uitdagingen het hoofd te bieden, stellen we een federated learning (FL)-framework voor, gebaseerd op open-source FedML op AWS, waarmee gevoelige HCLS-gegevens kunnen worden geanalyseerd. Het omvat het trainen van een wereldwijd machine learning (ML)-model op basis van gedistribueerde gezondheidsgegevens die lokaal op verschillende locaties worden bewaard. Tijdens het trainingsproces van het model is het niet nodig om gegevens tussen sites of met een gecentraliseerde server te verplaatsen of te delen.

Het implementeren van een FL-framework in de cloud brengt verschillende uitdagingen met zich mee. Het automatiseren van de client-serverinfrastructuur ter ondersteuning van meerdere accounts of virtual private clouds (VPC's) vereist VPC-peering en efficiënte communicatie tussen VPC's en instances. In een productieworkload is een stabiele implementatiepijplijn nodig om naadloos clients toe te voegen en te verwijderen en hun configuraties bij te werken zonder veel overhead. Bovendien kunnen clients in een heterogene opstelling verschillende vereisten hebben voor rekenkracht, netwerk en opslag. In deze gedecentraliseerde architectuur kan het moeilijk zijn om fouten op te sporen en te debuggen tussen clients. Ten slotte is het een zware taak om de optimale benadering te bepalen voor het aggregeren van modelparameters, het onderhouden van modelprestaties, het waarborgen van gegevensprivacy en het verbeteren van de communicatie-efficiëntie. In dit bericht pakken we deze uitdagingen aan door een federated learning operations (FLOps)-sjabloon te bieden die een HCLS-oplossing host. De oplossing is agnostisch voor use cases, wat betekent dat u deze kunt aanpassen voor uw use cases door het model en de gegevens te wijzigen.

In deze tweedelige serie laten we zien hoe u een cloudgebaseerd FL-framework op AWS kunt implementeren. In de eerste berichthebben we FL-concepten en het FedML-framework beschreven. In dit tweede deel presenteren we een proof-of-concept gebruiksscenario voor gezondheidszorg en levenswetenschappen van een real-world dataset eICU. Deze dataset bestaat uit een database voor kritieke zorg in meerdere centra, verzameld uit meer dan 200 ziekenhuizen, wat het ideaal maakt om onze FL-experimenten te testen.

HCLS-gebruikscasus

Voor demonstratiedoeleinden hebben we een FL-model gebouwd op een openbaar beschikbare dataset om ernstig zieke patiënten te behandelen. Wij gebruikten de eICU Collaboratieve onderzoeksdatabase, een multi-center intensive care unit (ICU) database, bestaande uit 200,859 ontmoetingen met patiëntenunits voor 139,367 unieke patiënten. Ze werden tussen 335 en 208 opgenomen in een van de 2014 afdelingen van 2015 ziekenhuizen in de VS. Vanwege de onderliggende heterogeniteit en gedistribueerde aard van de gegevens, biedt het een ideaal praktijkvoorbeeld om dit FL-framework te testen. De dataset omvat laboratoriummetingen, vitale functies, informatie over het zorgplan, medicatie, patiëntgeschiedenis, opnamediagnose, diagnoses met tijdstempel uit een gestructureerde probleemlijst en vergelijkbare gekozen behandelingen. Het is beschikbaar als een set CSV-bestanden, die in elk relationeel databasesysteem kunnen worden geladen. De tabellen zijn geanonimiseerd om te voldoen aan de wettelijke vereisten van de Amerikaanse Health Insurance Portability and Accountability Act (HIPAA). De gegevens zijn toegankelijk via een PhysioNet-repository en details van het gegevenstoegangsproces zijn hier te vinden [1].

De eICU-gegevens zijn ideaal voor het ontwikkelen van ML-algoritmen, beslissingsondersteunende hulpmiddelen en het bevorderen van klinisch onderzoek. Voor benchmarkanalyse hebben we gekeken naar de taak om de sterfte van patiënten in het ziekenhuis te voorspellen [2]. We hebben het gedefinieerd als een binaire classificatietaak, waarbij elk gegevensmonster een venster van 1 uur beslaat. Om een ​​cohort voor deze taak te creëren, hebben we patiënten geselecteerd met een ontslagstatus uit het ziekenhuis in het patiëntendossier en een verblijfsduur van ten minste 48 uur, omdat we ons richten op voorspellende sterfte gedurende de eerste 24 en 48 uur. Hierdoor ontstond een cohort van 30,680 patiënten met 1,164,966 records. We hebben domeinspecifieke gegevensvoorverwerking en methoden gebruikt die worden beschreven in [3] voor sterftevoorspelling. Dit resulteerde in een geaggregeerde dataset met meerdere kolommen per patiënt per record, zoals weergegeven in de volgende afbeelding. De volgende tabel biedt een patiëntendossier in een interface in tabelvorm met tijd in kolommen (5 intervallen over 48 uur) en waarnemingen van vitale functies in rijen. Elke rij vertegenwoordigt een fysiologische variabele en elke kolom vertegenwoordigt de waarde die is geregistreerd gedurende een tijdvenster van 48 uur voor een patiënt.

We gebruikten zowel numerieke als categorische kenmerken en groepeerden alle records van elke patiënt om ze af te vlakken tot een tijdreeks met één record. De zeven categorische kenmerken (Toelatingsdiagnose, Etniciteit, Geslacht, Glasgow Coma Score Total, Glasgow Coma Score Eyes, Glasgow Coma Score Motor en Glasgow Coma Score Verbal werden omgezet in one-hot coderingsvectoren) bevatten 429 unieke waarden en werden omgezet in één -hete inbeddingen. Om het lekken van gegevens tussen trainingsknooppuntservers te voorkomen, hebben we de gegevens gesplitst op ziekenhuis-ID's en hebben we alle records van een ziekenhuis op één enkel knooppunt bewaard.

Overzicht oplossingen

Het volgende diagram toont de architectuur van de implementatie van FedML op AWS met meerdere accounts. Dit omvat twee klanten (Deelnemer A en Deelnemer B) en een modelaggregator.

De architectuur bestaat uit drie afzonderlijke Amazon Elastic Compute-cloud (Amazon EC2)-instanties die worden uitgevoerd in een eigen AWS-account. Elk van de eerste twee instanties is eigendom van een klant en de derde instantie is eigendom van de modelaggregator. De accounts zijn verbonden via VPC-peering zodat ML-modellen en gewichten kunnen worden uitgewisseld tussen de clients en aggregator. gRPC wordt gebruikt als communicatie-backend voor communicatie tussen modelaggregator en klanten. We hebben een enkele accountgebaseerde gedistribueerde computerconfiguratie getest met één server en twee clientknooppunten. Elk van deze instanties is gemaakt met behulp van een aangepaste Amazon EC2 AMI met FedML-afhankelijkheden geïnstalleerd volgens de FedML.ai installatiegids.

VPC-peering instellen

Nadat u de drie instanties in hun respectievelijke AWS-accounts hebt gestart, brengt u VPC-peering tot stand tussen de accounts via Amazon virtuele privécloud (Amazone VPC). Om een ​​VPC-peeringverbinding in te stellen, maakt u eerst een verzoek om te peeren met een andere VPC. U kunt een VPC-peeringverbinding aanvragen met een andere VPC in uw account of met een VPC in een ander AWS-account. Om het verzoek te activeren, moet de eigenaar van de VPC het verzoek accepteren. Voor deze demonstratie hebben we de peering-verbinding opgezet tussen VPC's in verschillende accounts maar in dezelfde regio. Raadpleeg voor andere configuraties van VPC-peering Maak een VPC-peeringverbinding.

Voordat u begint, moet u ervoor zorgen dat u het AWS-accountnummer en de VPC-ID van de VPC hebt om mee te peeren.

Vraag een VPC-peeringverbinding aan

Voer de volgende stappen uit om de VPC-peeringverbinding tot stand te brengen:

1. Kies op de Amazon VPC-console in het navigatievenster Peering-verbindingen.
2. Kies Peeringverbinding maken.
3. Voor Naamlabel voor peeringverbinding, kunt u uw VPC-peeringverbinding optioneel een naam geven. Als u dit doet, wordt een tag gemaakt met een sleutel van de naam en een waarde die u opgeeft. Deze tag is alleen zichtbaar voor jou; de eigenaar van de peer-VPC kan zijn eigen tags maken voor de VPC-peeringverbinding.
4. Voor VPC (aanvrager), kies de VPC in uw account om de peering-verbinding tot stand te brengen.
5. Voor Account, kiezen Een ander account.
6. Voor Account ID, voer de AWS-account-ID in van de eigenaar van de accepterende VPC.
7. Voor VPC (Accepteren), voert u de VPC-ID in waarmee u de VPC-peeringverbinding wilt maken.
8. Kies in het bevestigingsvenster OK.
9. Kies Peeringverbinding maken.

Accepteer een VPC-peeringverbinding

Zoals eerder vermeld, moet de VPC-peeringverbinding worden geaccepteerd door de eigenaar van de VPC waarnaar het verbindingsverzoek is verzonden. Voer de volgende stappen uit om het peering-verbindingsverzoek te accepteren:

1. Gebruik op de Amazon VPC-console de regiokiezer om de regio van de accepterende VPC te kiezen.
2. Kies in het navigatievenster Peering-verbindingen.
3. Selecteer de in behandeling zijnde VPC-peeringverbinding (de status is pending-acceptance), en op de Acties menu, kies Accepteer verzoek.
4. Kies in het bevestigingsvenster Ja, accepteren.
5. Kies in het tweede bevestigingsvenster Wijzig nu mijn routetabellen om direct naar de routetabellen pagina te gaan, of kies Sluiten om dit achteraf te doen.

Update routetabellen

Om privé IPv4-verkeer tussen instanties in peered VPC's mogelijk te maken, voegt u een route toe aan de routetabellen die zijn gekoppeld aan de subnetten voor beide instanties. De routebestemming is het CIDR-blok (of een deel van het CIDR-blok) van de peer-VPC en het doel is de ID van de VPC-peeringverbinding. Voor meer informatie, zie Routetabellen configureren.

Werk uw beveiligingsgroepen bij om te verwijzen naar peer-VPC-groepen

Werk de inkomende of uitgaande regels voor uw VPC-beveiligingsgroepen bij om te verwijzen naar beveiligingsgroepen in de peered VPC. Hierdoor kan verkeer stromen tussen instanties die zijn gekoppeld aan de beveiligingsgroep waarnaar wordt verwezen in de peered VPC. Raadpleeg voor meer informatie over het instellen van beveiligingsgroepen Werk uw beveiligingsgroepen bij om te verwijzen naar peer-beveiligingsgroepen.

Configureer FedML

Nadat u de drie EC2-instanties hebt uitgevoerd, maakt u verbinding met elk van hen en voert u de volgende stappen uit:

1. Kloon het FedML-opslagplaats.
2. Geef topologiegegevens over uw netwerk op in het configuratiebestand grpc_ipconfig.csv.

Dit bestand is te vinden op FedML/fedml_experiments/distributed/fedavg in de FedML-repository. Het bestand bevat gegevens over de server en clients en hun toegewezen knooppunttoewijzing, zoals FL Server - Node 0, FL Client 1 - Node 1 en FL Client 2 - Node2.

3. Definieer het configuratiebestand voor GPU-toewijzing.

Dit bestand is te vinden op FedML/fedml_experiments/distributed/fedavg in de FedML-repository. Het bestand gpu_mapping.yaml bestaat uit configuratiegegevens voor clientservertoewijzing aan de overeenkomstige GPU, zoals weergegeven in het volgende fragment.

Nadat u deze configuraties hebt gedefinieerd, bent u klaar om de clients uit te voeren. Merk op dat de clients moeten worden uitgevoerd voordat de server wordt gestart. Laten we, voordat we dat doen, de gegevensladers voor de experimenten instellen.

Pas FedML aan voor eICU

Om de FedML-repository voor de eICU-gegevensset aan te passen, brengt u de volgende wijzigingen aan in de gegevens en de gegevenslader.

Data

Voeg gegevens toe aan de vooraf toegewezen gegevensmap, zoals weergegeven in de volgende schermafbeelding. U kunt de gegevens in elke gewenste map plaatsen, zolang er maar consistent naar het pad wordt verwezen in het trainingsscript en toegang is ingeschakeld. Om een ​​real-world HCLS-scenario te volgen, waarbij lokale gegevens niet worden gedeeld tussen locaties, splitst u de gegevens op en neemt u steekproeven zodat er geen overlapping is van ziekenhuis-ID's tussen de twee klanten. Dit zorgt ervoor dat de gegevens van een ziekenhuis op een eigen server worden gehost. We hebben ook dezelfde beperking afgedwongen om de gegevens op te splitsen in trein-/testsets binnen elke klant. Elk van de trein-/testsets bij de klanten had een verhouding van 1:10 van positieve tot negatieve labels, met ongeveer 27,000 monsters in training en 3,000 monsters in test. We behandelen de data-onbalans in modeltraining met een gewogen verliesfunctie.

Gegevenslader

Elk van de FedML-clients laadt de gegevens en zet deze om in PyTorch-tensoren voor efficiënte training op GPU. Breid de bestaande FedML-nomenclatuur uit om een ​​map voor eICU-gegevens toe te voegen in de data_processing map.

Het volgende codefragment laadt de gegevens uit de gegevensbron. Het verwerkt de gegevens voor en retourneert één item tegelijk via de __getitem__ functie.

import logging
import pickle
import random
import numpy as np
import torch.utils.data as data class eicu_truncated(data.Dataset): def __init__(self, file_path, dataidxs=None, transform=None, target_transform=None, task='mort', ohe=True, cat=True, num=True, n_cat_class=429): <code to initialize class variables> def _load_data(self, file_path): <code to load data files for each client> def __getitem__(self, index): <code to process data and return input and labels> return x.astype(np.float32), y def __len__(self): return len(self.data)

Het trainen van ML-modellen met één datapunt tegelijk is vervelend en tijdrovend. Modeltraining wordt meestal gedaan op een reeks datapunten bij elke klant. Om dit te implementeren, is de datalader in de data_loader.py script zet NumPy-arrays om in Torch-tensors, zoals weergegeven in het volgende codefragment. Merk op dat FedML biedt dataset.py en data_loader.py scripts voor zowel gestructureerde als ongestructureerde gegevens die u kunt gebruiken voor gegevensspecifieke wijzigingen, zoals in elk PyTorch-project.

import logging
import numpy as np
import torch
import torch.utils.data as data
import torchvision.transforms as transforms
from .dataset import eicu_truncated #load the dataset.py file mentioned above
.
.
.
.
# Use standard FedML functions for data distribution and split here
.
.
.
.
# Invoke load_partition_data function for model training. Adapt this function for your dataset
def load_partition_data_eicu(dataset, train_file, test_file, partition_method, partition_alpha, client_number, batch_size): <code to partition eicu data and its aggregated statistics> return train_data_num, test_data_num, train_data_global, test_data_global, data_local_num_dict, train_data_local_dict, test_data_local_dict, class_num, net_dataidx_map

Importeer de gegevenslader in het trainingsscript

Nadat u de gegevenslader hebt gemaakt, importeert u deze in de FedML-code voor ML-modeltraining. Net als elke andere dataset (bijvoorbeeld CIFAR-10 en CIFAR-100), laadt u de eICU-gegevens naar main_fedavg.py script in het pad FedML/fedml_experiments/distributed/fedavg/. Hier gebruikten we de gefedereerde middeling (fedavg) aggregatiefunctie. U kunt een vergelijkbare methode volgen om het in te stellen main bestand voor elke andere aggregatiefunctie.

from fedml_api.data_preprocessing.cifar100.data_loader import load_partition_data_cifar100
from fedml_api.data_preprocessing.cinic10.data_loader import load_partition_data_cinic10 # For eicu
from fedml_api.data_preprocessing.eicu.data_loader import load_partition_data_eicu

We noemen de functie voor het laden van gegevens voor eICU-gegevens met de volgende code:

 elif dataset_name == "eicu": logging.info("load_data. dataset_name = %s" % dataset_name) args.client_num_in_total = 2 train_data_num, test_data_num, train_data_global, test_data_global, train_data_local_num_dict, train_data_local_dict, test_data_local_dict, class_num, net_dataidx_map = load_partition_data_eicu(dataset=dataset_name, train_file=args.train_file, test_file=args.test_file, partition_method=args.partition_method, partition_alpha=args.partition_alpha, client_number=args.client_num_in_total, batch_size=args.batch_size)

Definieer het model

FedML ondersteunt verschillende out-of-the-box deep learning-algoritmen voor verschillende gegevenstypen, zoals gegevens in tabelvorm, tekst, afbeeldingen, grafieken en Internet of Things (IoT). Laad het model specifiek voor eICU met input- en outputdimensies die zijn gedefinieerd op basis van de dataset. Voor deze proof of concept-ontwikkeling hebben we een logistisch regressiemodel gebruikt om het sterftecijfer van patiënten met standaardconfiguraties te trainen en te voorspellen. Het volgende codefragment toont de updates die we hebben aangebracht in het main_fedavg.py script. Merk op dat u ook aangepaste PyTorch-modellen kunt gebruiken met FedML en deze kunt importeren in de main_fedavg.py scripts.

if model_name == "lr" and args.dataset == "mnist": logging.info("LogisticRegression + MNIST") model = LogisticRegression(28 * 28, output_dim)
elif model_name == "lr" and args.dataset == "eicu": logging.info("LogisticRegression + eicu") model = LogisticRegression(22100, output_dim)
elif model_name == "rnn" and args.dataset == "shakespeare": logging.info("RNN + shakespeare") model = RNN_OriginalFedAvg()

Voer FedML-training uit en volg deze op AWS

De volgende video laat zien hoe het trainingsproces wordt geïnitialiseerd in elk van de clients. Nadat beide clients voor de server zijn vermeld, maakt u het servertrainingsproces dat federatieve aggregatie van modellen uitvoert.

Voer de volgende stappen uit om de FL-server en clients te configureren:

1. Voer Client 1 en Client 2 uit.

Voer de volgende opdracht in met het bijbehorende knooppunt-ID om een ​​client uit te voeren. Om bijvoorbeeld Client 1 uit te voeren met knooppunt-ID 1, voert u uit vanaf de opdrachtregel:

> sh run_fedavg_cross_zone_eICU.sh 1

2. Nadat beide clientinstanties zijn gestart, start u de serverinstantie met dezelfde opdracht en de juiste knooppunt-ID volgens uw configuratie in de grpc_ipconfig.csv file. U kunt zien dat de modelgewichten worden doorgegeven aan de server vanuit de clientinstanties.

3. We trainen het FL-model voor 50 tijdperken. Zoals je kunt zien in de onderstaande video, worden de gewichten overgedragen tussen knooppunten 0, 1 en 2, wat aangeeft dat de training verloopt zoals verwacht op een gefedereerde manier.

4. Bewaak en volg ten slotte de trainingsvoortgang van het FL-model op verschillende knooppunten in het cluster met behulp van de gewichten en vooroordelen (wandb) tool, zoals weergegeven in de volgende schermafbeelding. Volg de vermelde stappen hier om wandb te installeren en monitoring voor deze oplossing in te stellen.
   

De volgende video legt al deze stappen vast om een ​​end-to-end demonstratie van FL op AWS te geven met behulp van FedML:

Conclusie

In dit bericht hebben we laten zien hoe u een FL-framework, gebaseerd op open-source FedML, op AWS kunt implementeren. Hiermee kunt u een ML-model trainen op gedistribueerde gegevens, zonder dat u deze hoeft te delen of te verplaatsen. We hebben een architectuur met meerdere accounts opgezet, waarbij ziekenhuizen of zorgorganisaties zich in een real-world scenario kunnen aansluiten bij het ecosysteem om te profiteren van samenwerkend leren met behoud van gegevensbeheer. We hebben de eICU-dataset van meerdere ziekenhuizen gebruikt om deze implementatie te testen. Dit raamwerk kan ook worden toegepast op andere use cases en domeinen. We zullen dit werk blijven uitbreiden door de implementatie te automatiseren via infrastructuur als code (met behulp van AWS CloudFormatie), verdere integratie van mechanismen voor privacybehoud en verbetering van de interpreteerbaarheid en eerlijkheid van de FL-modellen.

Bekijk de presentatie op re:MARS 2022 gericht op “Managed Federated Learning op AWS: een casestudy voor de gezondheidszorg” voor een gedetailleerde uitleg van deze oplossing.

Referentie

[1] Pollard, Tom J., et al. "De eICU Collaborative Research Database, een gratis beschikbare multi-center database voor onderzoek in kritieke zorg." Wetenschappelijke gegevens 5.1 (2018): 1-13.

[2] Yin, X., Zhu, Y. en Hu, J., 2021. Een uitgebreid overzicht van gefedereerd leren met behoud van privacy: een taxonomie, beoordeling en toekomstige richtingen. ACM Rekenenquêtes (CSUR), 54(6), pp.1-36.

[3] Sheikhalishahi, Seyedmostafa, Vevake Balaraman en Venet Osmani. "Benchmarking van machine learning-modellen op multi-center eICU-dataset voor kritieke zorg." Plos een 15.7 (2020): e0235424.

Over de auteurs

Vidya Sagar Ravipati is manager bij de Amazon ML Solutions-lab, waar hij gebruikmaakt van zijn uitgebreide ervaring in grootschalige gedistribueerde systemen en zijn passie voor machine learning om AWS-klanten in verschillende branche-branches te helpen hun AI- en cloud-acceptatie te versnellen. Eerder was hij Machine Learning Engineer in Connectivity Services bij Amazon, die hielp bij het bouwen van personalisatie- en voorspellende onderhoudsplatforms.

Olivia Choudhury, PhD, is een Senior Partner Solutions Architect bij AWS. Ze helpt partners in het domein van de gezondheidszorg en de levenswetenschappen bij het ontwerpen, ontwikkelen en schalen van state-of-the-art oplossingen die gebruikmaken van AWS. Ze heeft een achtergrond in genomics, gezondheidszorganalyse, gefedereerd leren en privacybeschermende machine learning. Buiten haar werk speelt ze bordspellen, schildert ze landschappen en verzamelt ze manga.

Wajahat Aziz is een Principal Machine Learning en HPC Solutions Architect bij AWS, waar hij zich richt op het helpen van klanten in de gezondheidszorg en life sciences om AWS-technologieën te benutten voor het ontwikkelen van ultramoderne ML- en HPC-oplossingen voor een breed scala aan use cases, zoals medicijnontwikkeling, Klinische proeven en privacybehoud door machinaal leren. Buiten zijn werk verkent Wajahat graag de natuur, wandelen en lezen.

Divya Bhargavi is Data Scientist en Media en Entertainment Vertical Lead bij de Amazon ML Solutions-lab, waar ze hoogwaardige zakelijke problemen voor AWS-klanten oplost met behulp van Machine Learning. Ze werkt aan het begrijpen van afbeeldingen/video's, aanbevelingssystemen voor kennisgrafieken en gebruiksscenario's voor voorspellende advertenties.

Ujjwal Ratan is de leider voor AI/ML en Data Science in de AWS Healthcare en Life Science Business Unit en is ook een Principal AI/ML Solutions Architect. Door de jaren heen is Ujjwal een toonaangevend leider geweest in de gezondheidszorg en life sciences-industrie en heeft hij meerdere Global Fortune 500-organisaties geholpen hun innovatiedoelen te bereiken door machine learning toe te passen. Zijn werk met de analyse van medische beeldvorming, ongestructureerde klinische tekst en genomics heeft AWS geholpen bij het bouwen van producten en diensten die zeer gepersonaliseerde en nauwkeurig gerichte diagnostiek en therapieën bieden. In zijn vrije tijd luistert (en speelt) hij graag naar muziek en maakt hij graag ongeplande roadtrips met zijn gezin.

Chaoyang Hij is mede-oprichter en CTO van FedML, Inc., een start-up die zich inzet voor een community die overal en op elke schaal open en collaboratieve AI bouwt. Zijn onderzoek richt zich op gedistribueerde/gefedereerde algoritmen, systemen en toepassingen voor machine learning. Hij behaalde zijn Ph.D. in de informatica van de University of Southern California, Los Angeles, VS.

Salman Avesttimehr is mede-oprichter en CEO van FedML, Inc., een start-up die zich inzet voor een community die overal en op elke schaal open en collaboratieve AI opbouwt. Salman Avestimehr is een wereldberoemde expert op het gebied van gefedereerd leren met meer dan 20 jaar R&D-leiderschap in zowel de academische wereld als de industrie. Hij is een Dean's Professor en de inaugurele directeur van het USC-Amazon Center on Trustworthy Machine Learning aan de University of Southern California. Hij is ook een Amazon Scholar in Amazon geweest. Hij is een Amerikaanse presidentiële prijswinnaar voor zijn diepgaande bijdragen op het gebied van informatietechnologie, en een Fellow van IEEE.

• Door SEO aangedreven content en PR-distributie. Word vandaag nog versterkt.
• Platoblockchain. Web3 Metaverse Intelligentie. Kennis versterkt. Toegang hier.
• Bron: https://aws.amazon.com/blogs/machine-learning/part-2-federated-learning-on-aws-with-fedml-health-analytics-without-sharing-sensitive-data/