Pourquoi et comment évaluer la contributivité d’un partenaire dans un projet collaboratif de machine learning ?

Pour satisfaire aux exigences de sécurité relatives aux données dans certains domaines, une solution est de se diriger vers des approches d’apprentissage automatique distribué, collaboratif et multi-acteurs. Mais cela implique alors l'élaboration d'une notion de contributivité pour quantifier la participation d’un partenaire au modèle final. La définition d’une telle notion n’est pas immédiate : pouvoir implémenter facilement, expérimenter et comparer différentes approches demande un outil de simulation. C’est ce que nous avons entrepris de développer, sous la forme de la librairie Python open source mplc dans le cadre d’un groupe de travail réunissant plusieurs partenaires.

Article écrit par Arthur Pignet, stagiaire Machine Learning and Data Science chez Substra Foundation

Photo by Vladimir Proskurovskiy on Unsplash

Une révolution de l’IA ?

Difficile d'échapper au machine learning aujourd’hui. Et pour cause, les résultats absolument révolutionnaires que ces algorithmes ont permis d’atteindre dans certains domaines. 

Il suffit de données et d’une idée, plus ou moins bonne. Ajoutez un peu de Python, louez de la puissance de calcul en ligne, 5 minutes à feu vif et vous avez lancé avec succès un algorithme d’apprentissage dont la performance à venir n'aurait probablement pas été envisageable une décennie plus tôt !

“Il suffit d’avoir des données” : facile à dire, mais plus complexe à mettre en œuvre. Dans beaucoup de domaines, les données sont difficiles d’accès, éparpillées entre de nombreux acteurs, et/ou confidentielles. Pour ce type de données, adapter les techniques classiques de machine learning à des cas distribués permettrait d'élargir les cas d’usage et d’envisager des scénarios de machine learning collaboratifs, multi-acteurs, sur des données sensibles.

Toutes les données sont exploitables avec du machine learning... Toutes ? Non ! Un jeu de données peuplé de quelques données sensibles et privées résiste encore et toujours à l'envahisseur...

Un premier pas, l’apprentissage distribué…

C’est Google qui va introduire l’idée de machine learning distribuée en 2017 : comment entraîner un clavier de smartphone intelligent, sans demander aux utilisateurs d'envoyer toutes leurs données vers un serveur central Google ? Tout simplement en laissant les données sur l’appareil de l’utilisateur et en entraînant le modèle sur place. 

Voici le paradigme du machine learning distribué : les données ne sont pas déplacées, c’est l’apprentissage qui est distribué et qui va se produire itérativement chez les différents partenaires (data owner). Mais apprendre de manière décentralisée n’est pas immédiat et apporte son lot de questions et de défis. Le modèle va-t-il de partenaire en partenaire, ou bien fait-on de l’apprentissage en parallèle avec des modèles d’abord entraînés localement et ensuite fusionnés. Que veut alors dire fusionner : fusionne-t-on les gradients, les poids du modèle ? Comment gérer des données hétérogènes ? Chaque partenaire a-t-il le même “apport” ? Beaucoup de questions dont la réponse se trouve au cas par cas, ce qui nécessite des tests, des simulations. C’est d’ailleurs un premier objectif de notre librairie open source mplc introduite à la fin de cet article.

En ajoutant une couche de sécurité sur ce type d’algorithme, comme de la secure aggregation ou de la differential privacy, on obtient une recette quasiment miraculeuse où les données des utilisateurs ou des partenaires restent chez leurs propriétaires respectifs et ne sont jamais diffusées à l’extérieur. 
L’article Advances and Open Problems in Federated Learning fait état de deux catégories distinctes d’apprentissage distribué : cross devices et cross silos. Dans le premier cas, les partenaires ont peu de données et peu de puissance de calcul. Les données sont collectées par un utilisateur et conservées par celui-ci, sans qu’il soit acteur direct du projet. On a alors des centaines de milliers, voire millions de participants dans la coalition : des smartphones dans l’exemple précédent de Google, ou un parc de voitures connectées, etc.

Dans le second cas, les partenaires sont des institutions ou des entreprises qui ont à la fois des données et de la puissance de calcul. On a alors un nombre de partenaires compris entre deux et une centaine, et on parle de projet de machine learning collaboratif, où ces institutions vont s’associer pour constituer un jeu de données plus intéressant, tout en gardant leurs données localement. Cela permet de répondre à des exigences de sécurité sur lesdites données (par exemple avec des données onéreuses ou complexes à produire, dans un cas de concurrence forte, ou avec des données sensibles). Cela permet d'éviter une autre problématique, connue sous le nom de data gravity. Ce concept, assez intuitif, traduit le fait que déplacer des quantités de données importantes s’accompagne de beaucoup de contraintes et présente de nombreux risques.

Vers des scénarios de ML collaboratif

Dans un scénario collaboratif (cross silos), les challenges sont multiples. Les partenaires doivent trouver un terrain d’entente sur le pré-processing, la planification des calculs, notamment pour l'entraînement, la façon d’évaluer les modèles de sortie, etc.,  sans jamais dévoiler leurs données !  

De tels projets permettent d’exploiter toute la puissance que le machine learning a déjà démontrée par ailleurs. L’exemple le plus frappant est le domaine médical, science de la grande dimension et de l'expérimental par excellence, où le machine learning se montre déjà très prometteur. Ce domaine se démarque toutefois également par la sensibilité des données patients, ou le coût des données expérimentales. Les hôpitaux ne peuvent pas simplement mettre en commun les données de leurs patients, pas plus que les entreprises pharmaceutiques ne souhaitent partager leurs données expérimentales, très onéreuses à produire, dans un écosystème extrêmement concurrentiel. Substra Foundation est, par exemple, impliqué dans les projets HealtChain, et MELLODDY.

Le framework Substra apporte des solutions à une partie de ces problématiques, en permettant de faire des apprentissages distribués de manière privée. 

Avec un pré-processing convenu en amont, puis un entraînement utilisant le framework Substra, on obtient bien un modèle entraîné sans jamais remettre en cause la confidentialité des données des partenaires. Mais après ? Ce modèle est puissant et chaque partenaire en reçoit une copie. Mais que fait-on si un nouveau partenaire se présente ? Ou si l’un des partenaires souhaite commercialiser ce modèle ?

Finalement, on se rend compte que la production du modèle final représente un investissement conséquent et qu’il est indispensable de réussir à évaluer sa valeur. À la fois pour la répartir équitablement un “apport” parmi les partenaires, et pour permettre de pérenniser de tels projets. L’un des verrous techniques pour la construction d’un tel consortium est donc la définition du modèle économique, plus précisément de la répartition de la valeur d’un modèle construit, entraîné en commun mais de manière privée. Et en raison de la nature confidentielle des données, chiffrer la répartition de cette valeur est loin d’être simple.

Dans un contexte de ML collaboratif, comment évaluer et répartir la valeur créée par un modèle ?

Imaginons qu’une entreprise souhaite développer puis exploiter un modèle, par exemple aux fins de prédictions automatiques au sein d’un système informatique. Elle ne dispose pas de suffisamment de données elle-même et rejoint un consortium de fournisseurs de données. Les autres partenaires méritent alors rétribution pour au moins trois raisons : 

• l'acquisition et la préparation des données ;

• la mise à disposition de ces données pour un entraînement ;

• le fait de fournir localement la puissance de calcul pour ces entraînements.

On pourrait imaginer un fonctionnement où la valeur serait équi-répartie entre les différents partenaires. Mais cela ne serait pas véritablement équitable. En effet, les jeux de données des partenaires sont hétérogènes et probablement non équivalents. 

Nous sommes donc convaincus qu’il est intéressant d’explorer ce concept d’évaluation de la contribution d’un partenaire (fournisseur de données), de répartition de la valeur d’un modèle selon l’apport de chacun de ses co-constructeurs (notion que l’on nomme contributivité dans la suite de cet article). Cela permettra de définir les options possibles et d'accélérer les négociations entre les différents partenaires. Une telle mesure pourrait également permettre de s’adapter dynamiquement à la réalité et ouvrir une voie plus concrète à l’organisation de partenariats d’apprentissage distribués. 

Comment construire une telle mesure ? Que doit traduire ce concept de contributivité ?

L’objectif du projet collaboratif, et sa réussite, est étroitement lié à la performance du modèle final. Un bon point de départ pour notre notion de contributivité. 

Par exemple, la mesure de l’augmentation du score du modèle global pour l’ajout d’un partenaire dans notre hypothétique consortium semble un bon candidat. Comment lier cette augmentation à un jeu de données ? Un raccourci commun en machine learning stipule qu’il faut un maximum de données. Dans un scénario avec trois partenaires, l’un avec 10 000 exemples, 40 000 exemples et 50 000 exemples, on aurait alors des contributions respectives de 10 % , 40 %, et 50 %. Cela semble séduisant, mais... toutes les données ne se valent pas ! 

Si vous voulez développer un modèle de détection d’image de chat, et que l’on vous propose 10 000 fois l’image de Garfield, ou 10 000 images de chats très différents avec une grande variance, vous ne choisirez sûrement pas le premier jeu de données. 

Récompenser le volume n’est donc ni suffisant, ni même souhaitable. En effet, une donnée énormément dupliquée aura tendance à générer du sur-apprentissage, diminuant la capacité de généralisation du modèle et en atténuera les performances.

Une suite logique à ces réflexions serait de récompenser un dataset avec une grande variance. Mais une grande variance ne garantit pas des données utiles, seulement variées. Par exemple, un dataset labellisé aléatoirement va avoir une variance très élevée, tout en diminuant les performances du modèle. On parle alors de données corrompues. Et effectivement, si pour l’instant nous n’avons parlé que de partenaires qui améliorent le modèle, rien n'empêche à l’inverse de considérer des partenaires amenant des datasets corrompus, par exemple avec une erreur dans les étapes de pré-processing. Comment repérer ce type de données ? 

Une mesure de contributivité idéale nous permettra de détecter ces jeux de données, avec une valeur de contributivité négative par exemple. 

Revenons à cette idée de regarder l’augmentation de performance généré par l’ajout d’un partenaire dans l’apprentissage. 

La théorie des jeux nous fournit un candidat pour cette notion de contributivité. La valeur de Shapley ayant été construite pour répartir les gains d’un collectif à partir d’une valeur de score, cette méthode semble parfaitement adaptée.

L’idée générale est de calculer les scores obtenus par toutes les coalitions possibles à partir d’un ensemble prédéterminé de partenaires, et de comparer ces scores entre eux.  

Par exemple, admettons que vous, Alice, souhaitiez construire par deep learning un modèle d’analyse de scanner médical. Ces données sont sensibles et vous n’en avez pas suffisamment à vous seul. Vous vous associerez donc avec deux autres laboratoires de radiographie, Bob et Eve. La valeur de Shapley pour chacun d’entre vous va s’obtenir à partir des scores de modèles entraînés sur toutes les combinaisons possibles de vos datasets.

Par exemple :

• Modèle entrainé sur votre dataset uniquement - > score de 98,1 %

• Modèle entraîné sur le dataset d’Eve uniquement -> score de 97,7 %

• Modèle entraîné sur le dataset de Bob uniquement -> score de 97,6 %

• Modèle entrainé sur votre dataset et celui d’Eve - > score de 98,8 %

• Modèle entrainé sur votre dataset et celui de Bob -> score de 73,0 % 

• Modèle entraîné sur les datasets de Bob et d’Eve -> score de 49,0 %

• Modèle entraîné sur vos trois datasets -> score de 97,4 % 

A partir de là, on peut calculer la valeur de Shapley.

Intéressant n’est ce pas ? On distingue clairement que le dataset du partenaire 3 apporte des informations contradictoires avec celles des deux autres datasets ! 

Finalement, Bob ne contribue pas au modèle… Pire, il l'empêche d’apprendre correctement. Et pourtant, un modèle entraîné sur le dataset de Bob va converger, en effet son score est alors de 97%. Comment expliquer ceci ? Le score pour les apprentissages “personnels”, c'est-à-dire pour un seul dataset, est calculé sur un jeu de donnée de validation local, contre les entraînements multi-partenaires, qui eux utilisent un jeu de donnée de validation global. C’est un choix contestable, d’autant que l’existence d’un jeu de validation global n’est pas immédiat dans bien des cas. Toujours est-il que l’on comprend que les données de Bob ont une cohérence interne, mais sont incohérentes avec les données d’Alice et d’Eve. Peut-être que les données de Bob sont utilisables, mais pas en l'état ? 

Typiquement, on peut s’attendre à ce qu'une erreur se soit glissée dans le pré-processing de Bob, et que par exemple tous les labels aient été permutés. Une erreur, ou alors Bob ne joue pas le jeu...

Finalement, cette valeur de Shapley n’a qu’un inconvénient, malheureusement rédhibitoire : le coût calculatoire. Pour un scénario à 3 partenaires, nous avons dû entraîner 7 modèles ! En pratique, le calcul de la valeur de Shapley a un coût exponentiel par rapport au nombre de partenaires, ce qui le rend infaisable en réalité. Dans un projet avec 10 partenaires, le calcul de la valeur de Shapley prendrait environ 1024 fois plus de temps que l'entraînement du modèle. 

Je pense qu’à ce stade vous êtes convaincu que cette notion de contributivité ne se construira pas facilement et va nécessiter de la réflexion, des tests, de la recherche. 

Nous avons donc entrepris chez Substra Foundation de construire un outil de simulation, qui prend la forme d’une librairie Python : mplc, pour Multi-Partner Learning and Contributivity. 

MPLC, une librairie python faite pour l'étude de la contributivité.  

L’objectif de cette librairie est simple : apporter les outils nécessaires à la réflexion et aux recherches autour de la contributivité. C’est une démarche open source et collaborative.

Tenez, par exemple, d’où pensez vous que provienne l’exemple ci-dessus ? 

À l’heure actuelle, mplc, de son petit nom sur PyPi, met à disposition plusieurs briques indispensables pour faire des tests autour de la notion de contributivité. On y retrouve différentes approches d’apprentissage distribué et d'agrégation de modèle. Les plus connues, comme FedAvg ou Sequential, mais aussi des techniques plus expérimentales, adaptées à la mesure de contributivité, comme PVRL (méthode utilisant du reinforcement learning pour sélectionner les partenaires les plus intéressants du point de vue de leur contributivité). 

Vous aurez aussi à votre disposition des jeux de données pré-implémentés, parmi les plus connus (MNIST évidemment, mais aussi CIFAR10, Titanic, IMDB pour l’analyse de texte ou encore ESC50 pour de travailler avec de l’analyse sonore). Des méthodes pour artificiellement corrompre les jeux de données de certains partenaires sont même déjà intégrées. Vous pouvez ainsi artificiellement simuler une mauvaise labellisation des données (aléatoire, ou permuter des labels de manières déterministes), ou créer des duplicatas dans vos données. 

Et enfin, pour chaque scénario d’apprentissage, vous pourrez sélectionner les différentes mesures de contributivité que vous désirez calculer. 

Ainsi, l’exemple ci dessus se fait simplement de la manière suivant :

C’est aussi simple que cela !

La librairie se divise en 3 blocs :

• Les scénarios collaboratifs,

• Les approches d’apprentissages distribués,

• Les mesures de contributivité.

Les scénarios sont un objet central de cette bibliothèque. C’est à travers eux que l’on peut rapidement définir et simuler un… scénario d’apprentissage multi-partenaires. C’est à ce niveau que l’on va venir spécifier le dataset voulu (parmis ceux pré-implémentés ou pas, ajouter son propre dataset est très facile), le nombre de partenaires, la répartition du dataset parmi eux, l'éventuelle corruption artificielle de certains (et même le mode de corruption), et ainsi de suite.

Les approches d’apprentissages distribuées sont ensuite définies pour un scénario donné. Plusieurs approches ont été mises en place : la plus connue, Federated Averaging mais aussi des approches séquentielles ou mixtes.

On trouve aussi deux approches moins courantes, adaptées à la mesure de contributivité. On peut entre autre s’attarder sur un algorithme qui cherche pendant l’apprentissage à apprendre la corruption éventuelle des données, ou encore PVRL (Partner valuation by Reinforcement Learning), qui, à chaque epoch utilise un algorithme de reinforcement learning pour décider quels sont les partenaires qui participeront à l’apprentissage. 

Enfin, vous allez pouvoir spécifier pour un scénario donné, avec une méthode d’apprentissage définie, les mesures de contributivité que vous souhaitez calculer. 

Bien sûr la valeur de Shapley est implémentée mais elle est malheureusement très coûteuse en temps de calcul. Des méthodes statistiques, comme des calculs par méthodes de Monte Carlo, ou d’importance sampling permettent d’approximer Shapley tout en diminuant ce temps de calcul. Néanmoins, ces méthodes n’apportent une accélération significative qu’avec un nombre de partenaires importants, de l’ordre de la centaine, et seraient donc plus adapter au FL cross devices. D'autres méthodes ont été explorées, on peut en citer une basée sur un apprentissage par PVRL, où la probabilité d’être sélectionné pour la prochaine epoch en tant que partenaire est utilisée comme mesure de contributivité. 

Nous sommes donc toujours en phase exploratoire et nous nous efforçons de construire une librairie qui apporte tous les outils nécessaires à cette recherche, pour nous permettre, ainsi qu’à la communauté, d'expérimenter dans un maximum de cas d’usage.

Ce travail se poursuit et de nouvelles méthodes, datasets sont ajoutés en permanence à la bibliothèque.  

Si la lecture de cet article a soulevé chez vous des interrogations, des questions, ou plus simplement de la curiosité vis-à-vis de cette notion de contributivité, n'hésitez pas à essayer mplc et à venir nous raconter vos expériences et vos résultats sur notre channel Slack.

pip install mplc

Et si vous n’avez pas que des questions, mais aussi des idées, que vous trouvez que cette librairie a besoin d’une nouvelles fonctionnalités, que vous avez imaginé une nouvelle mesure révolutionnaire de contributivité, contactez-nous pour venir contribuer ! C’est un travail ouvert et collaboratif !