Reprise du message précédent :

Comme par exemple une certaine @urelie je@n?

Amis data scientist, ML engineer etc ... j'ai une question à vous poser.
 
Faites vous des daily tous les jours le matin ? Dans mon équipe on est une petite 20aine, de composition hétéroclite (DS, MLE, DE, devops, expert métier, stagiaire ...) et qui travaillent sur des projets qui n'ont parfois rien à avoir.
Tous les matins on passe 1h à débriefer ce qu'on a fait la veille, chacun son tour, sauf que 90% des interventions ne me concernent pas du tout et je trouve que c'est une grosse perte de temps.
Puis des fois j'ai pas été productif du tout la veille et je me retrouve à devoir broder pour dire quelque chose.
 
C'est comment chez vous ?

J'ai quasi toujours connu ça
Quand t'es dans une grosse équipe avec des compétences diverses c'est l'enfer ouais
Normalement au bout d'un moment ils s'en rendent compte et passent aux daily avec moins de gens quand même

L'enfer. C'est vraiment comme ça partout ? Moi qui pensais que changer de job allait peut être m'éviter ça.

Quand j'étais stagiaire et que je bossais dans mon coin et je faisais genre un point hebdo avec mes tuteurs quand j'avais des trucs à montrer et je me trouvais beaucoup plus productif, créatif et exploratoire.

Là je me contente de faire des trucs concrets pour pouvoir montrer que je fais qqchose.

Scrum mercredis et vendredis avec l'équipe IA
 
Chaque jour on rédige 1 daily sur notion avec les trucs qu'on a fait de la journée
 
Oué c l'enfer
 
Lundi on a le team meeting qui prends des plombes, en général je coupe cam et mic et je fais autre chose

Dans mon équipe on ne fait ça qu'une fois par semaine, et encore on est même pas 10, et on couple ça avec un update sur notre framework (on entraîne tous nos modèles avec la même librairie donc on discute des problèmes et des nouvelles Features)

 
C'est un sacré sujet et c'est une question qui me taraude depuis que je bosse en industrie.
Ca dépend de tellement de paramètres, la taille de la boite, la nature du business, la taille de l'équipe et ses profils, les types de projets, comment les gens bossent dessus, et la nature des tâches. Un gros paramètre aussi c'est si vous bosser verticalement (au sein d'une équipe de spécialiste) ou horizontallement ("cross functional" donc plus collaboratif sur des disciplines différentes).
 
En général je trouve que si les tâches sont plus liées à de l'ingénierie vaut mieux un daily (surtout si WFH/remote). Par contre si les taches sont plus recherche, un daily peut etre un enfer car certains manager-ingénieurs ne comprennent pas que faire une update tous les jours peut être plus nocif qu'autre chose, en sachant que certaines personnes ressentent le besoin de justifier leur productivité à tout prix, ce qui n'est pas évident quand tu bosses sur des sujets de recherche où il faut penser sur le long terme.
 
Pre pandémie, je bossais dans une équipe R&D avec nos projets perso et on faisait une update toutes les semaines d'1h ou 2h. Je voyais mes collègues tous les jours et on pouvait intéragir à n'importe quel moment de la journée pour discuter. C'était vraiment top. Post pandémie dans une autre boite, j'ai eu des daily en bossant sur des sujets très complexe de recherche, c'était un enfer.
 
Bref, le management c'est compliqué de base, quand ya une composante recherche encore plus, et la cerise sur le gateau c'est l'évolution récente du monde du travail avec l'hybride.

En cross fonctionnel aussi c'est l'enfer.
Se taper le daily des 4 dev front qui ragent sur tel aspect d'un framework que tu ne connais absolument pas etc

Ptites questions Deep Learning pour changer  
 
1) Classification de beaucoup de classes + ou - subtiles, par exemple toutes les differentes races de chiens et de chats. Est-ce que ca vaut le coup de grouper toutes les classes en simplement chien / chat et de train un modele sur ce probleme + simple puis de fine-tuner le modele obtenu sur le probleme plus complique originel ? Ou bien perte de temps ?
 
2) Quand je vois les implementations officielles tensorflow etc, la strategie d'entrainement est toujours complexe avec du weight decay / learning rate scheduling etc. Est-ce qu'il y a des "guidelines" pour l'entrainement d'un modele ? Comment on choisit ces trucs ? Vous faites comment vous ?  
 
Merci
 

Pour le 1) c'est une question classique d'évaluation/comparaison de performance entre deux méthodes/modèles A et B.
Tu établis un protocole expérimental (train/validation/test ou validation croisée, la mesure d'évaluation qui t'intéresse) et tu compares A et B ? Non ?

1. Classification de classes subtiles

Lorsque vous abordez un problème de classification avec un grand nombre de classes, le transfert d'apprentissage peut être une approche puissante pour améliorer les performances de votre modèle.

Vous pouvez d'abord entraîner un modèle sur un problème de classification binaire (chien/chat) pour obtenir des représentations générales des caractéristiques des chiens et des chats. Une fois que le modèle a appris ces représentations, vous pouvez effectuer un fine-tuning sur le problème multiclasse plus complexe, qui consiste à classer les différentes races de chiens et de chats.

Le transfert d'apprentissage est particulièrement utile lorsque vous disposez de données limitées pour certaines classes dans le problème multiclasse. En exploitant les connaissances acquises sur le problème binaire, le modèle peut mieux généraliser sur le problème plus complexe.

Cependant, il est crucial d'évaluer si cette approche est appropriée pour votre cas spécifique en tenant compte de facteurs tels que la distribution des données, la diversité des classes et la capacité du modèle à généraliser.

Voici quelques éléments supplémentaires à prendre en compte :

- Pré-entraînement sur une tâche connexe : Si vous disposez d'un ensemble de données étiquetées pour une tâche connexe (par exemple, la classification chien/chat), vous pouvez pré-entraîner votre modèle sur cette tâche pour apprendre des caractéristiques générales. Cette étape peut être particulièrement utile si vous avez peu de données pour le problème de classification des races de chiens et de chats.

- Utilisation de modèles pré-entraînés : Une autre approche consiste à utiliser des modèles pré-entraînés sur de grandes bases de données, comme ImageNet. Ces modèles ont déjà appris des caractéristiques visuelles générales qui peuvent être transférées à votre problème de classification des races. Vous pouvez fine-tuner ces modèles pré-entraînés en remplaçant les couches supérieures (par exemple, les couches entièrement connectées) par des couches adaptées à votre problème spécifique et en entraînant ces nouvelles couches avec vos données.

- Entraînement par étapes : Lorsque vous fine-tunez un modèle pré-entraîné, il peut être utile d'entraîner d'abord les nouvelles couches supérieures pendant quelques époques, puis d'entraîner l'ensemble du modèle en utilisant un taux d'apprentissage plus faible. Cette approche permet d'éviter de perturber les caractéristiques apprises lors du pré-entraînement.

- Attention aux classes déséquilibrées : Si certaines races de chiens et de chats sont sous-représentées dans vos données, cela peut affecter les performances du modèle. Vous pouvez utiliser des techniques de rééchantillonnage, telles que le suréchantillonnage des classes minoritaires ou le sous-échantillonnage des classes majoritaires, pour équilibrer la distribution des classes. De plus, vous pouvez ajuster les poids de classe lors de l'entraînement pour donner plus d'importance aux classes sous-représentées.

- Exploiter les similarités entre les classes : Certaines races de chiens et de chats peuvent avoir des caractéristiques visuelles similaires. Vous pouvez utiliser des techniques de clustering, comme t-SNE ou UMAP, pour visualiser la distribution des caractéristiques extraites par le modèle et identifier les groupes de classes similaires. Cette information peut vous aider à ajuster l'architecture du modèle ou à concevoir des stratégies d'entraînement spécifiques pour améliorer la séparation entre les classes similaires.

En résumé, la clé pour réussir la classification de classes subtiles réside dans l'adaptation de l'approche de transfert d'apprentissage à votre problème spécifique, en tenant compte de la distribution des données, de la capacité du modèle à généraliser et des relations entre les classes.

2. Stratégie d'entraînement et meilleures pratiques

Les stratégies d'entraînement complexes, telles que le weight decay et le learning rate scheduling, sont conçues pour améliorer la convergence du modèle et sa capacité à généraliser. Bien qu'il n'y ait pas de règles strictes pour choisir ces hyperparamètres, voici quelques conseils et meilleures pratiques pour un data scientist :

- Weight decay: Le weight decay est utilisé pour régulariser le modèle en ajoutant une pénalité L2 aux poids, ce qui aide à prévenir le surapprentissage. Une valeur de départ couramment utilisée est 1e-4, mais vous pouvez ajuster cette valeur en fonction de la sensibilité de votre modèle à la régularisation.

- Learning rate scheduling: Le learning rate scheduling permet d'ajuster le taux d'apprentissage au cours de l'entraînement, ce qui peut aider le modèle à converger plus rapidement et à éviter les minima locaux. Certaines stratégies courantes sont le "step decay", le "cosine annealing" et le "cyclic learning rate". Vous pouvez commencer par une stratégie de base, puis affiner en fonction des performances de votre modèle.

- Architecture du modèle: Utilisez des architectures de modèle éprouvées et adaptées à votre problème spécifique comme point de départ. Consultez les articles de recherche et les implémentations open source pour trouver des modèles et des stratégies d'entraînement qui ont réussi sur des problèmes similaires.

- Validation croisée: Pour évaluer les performances de votre modèle et estimer l'effet des hyperparamètres, utilisez la validation croisée (k-fold cross-validation). Cela vous aidera à choisir les meilleures valeurs d'hyperparamètres pour votre problème.

- Grid search et random search: Pour explorer l'espace des hyperparamètres, vous pouvez utiliser des techniques de recherche telles que la recherche exhaustive (grid search) et la recherche aléatoire (random search). Ces méthodes permettent d'évaluer différentes combinaisons d'hyperparamètres pour identifier celles qui fonctionnent le mieux pour votre modèle.

Voici quelques autres conseils pour vous aider dans ce processus :

- Suivi des expériences : Utilisez des outils de suivi d'expériences tels que TensorBoard, Weights & Biases ou MLflow pour surveiller et comparer les performances de différentes configurations d'hyperparamètres. Cela vous permettra de comprendre l'effet des changements apportés aux hyperparamètres et de choisir la meilleure configuration pour votre modèle.

- Early stopping : Pour éviter le surapprentissage et réduire le temps d'entraînement, utilisez la technique d'early stopping. L'early stopping arrête l'entraînement lorsque les performances de validation ne s'améliorent plus pendant un certain nombre d'époques consécutives. Cela permet de réduire les ressources de calcul nécessaires et d'éviter de surentraîner le modèle.

- Augmentation des données : Si vous travaillez avec des données limitées ou déséquilibrées, l'augmentation des données peut aider à améliorer la performance du modèle. L'augmentation des données consiste à générer de nouvelles instances de données en appliquant des transformations aléatoires aux données existantes. Pour les images, cela peut inclure des opérations telles que la rotation, le retournement, le recadrage et l'ajustement de la luminosité. L'augmentation des données permet au modèle d'apprendre à reconnaître les classes malgré les variations et d'éviter le surapprentissage.

- Métriques d'évaluation : Choisissez des métriques d'évaluation appropriées pour votre problème spécifique. Par exemple, si vous travaillez avec des données déséquilibrées, il peut être préférable d'utiliser des métriques telles que la précision pondérée, le rappel, le score F1 ou l'AUC-ROC, plutôt que la précision globale.

Pour le 2)
 
J'utilise un cocktail de dropout, weight decay, label smoothing, gradient clipping, et learning rate scheduler avec warmup sur les 30 premiers % de l'entrainement ( ex https://openreview.net/forum?id=H1A5ztj3b )
Toutes les options sont dispos dans le Trainer d'hugging face, il gère aussi parfaitement le distributed training (DDP) sur tout type d'archi / backend (cuda / mps / tpu / fairscale / deepspeed...), plein d'API pour log, c'est un gain monumental de temps
C'est initialement prévu pour leur transformer, mais je crois que ça fonctionne avec n'importe quel modèle à partir du moment on il retourne la loss et les bonnes valeurs, que les métriques / datasets / data collators sont bien interfacés.
 

 
Ça me fait grandement penser au Playbook publié par Google il y a quelques mois    
 
https://github.com/google-research/tuning_playbook

 
Ouaip je pourrais mais ma question etait plus theorique ie: si c'etait une pratique courante ou pas  
 
J'ai eu une bonne idee la je pense, on a quelques gros datasets sans labels precis (donc juste chien / chat) donc jvais pre-entrainer un reseau dessus et finetuner sur mon autre gros dataset finement labelé. Intuitevement ca devrait aider :  
- J'entraine sur beaucoup plus de données dont plein de maladies diverses et variées
- J'attaque le probleme plus complique en ayant deja un modele qui sait extraire les features pour les classes meres
 
 

 
Merci a Mr Chat, ce GPT
 

 
Justement, y'a une raison theorique / empirique derriere ? Est-ce qu'on a des pratiques communement admise par la communaute (comme l'utilisation d'Adam par defaut) ou bien c'est completement random ? Par ex, est-ce que ton protocole est vraiment meilleur que juste faire tourner adam + early stopping ?  
 

 
Super merci beaucoup, j'ai regarde vite fait, ca a l'air top par contre pas de code ? Dommage ils auraient pu inclure un use case avec le code associe (ou ptet que je suis juste une feignasse et jveux copier coller )

Pas de code, c’est plutôt une manière générale d’aborder l’entraînement / fine-tuning de modèles.  
Tout est facilement accessible via des libs ou bien ça se code facilement.  
 
 
Pour la question 1, ça peut faire sens. Comme souvent, à tester.  
Allant dans ce sens, il y avait un papier qui utilisait des augmentations de plus en plus « fortes » au fil de l’apprentissage (i.e. on complexifie le problème au fur et à mesure).  
À noter que pour ton cas il te faudra utiliser un nouveau layer de classification (à moins de faire du hiérarchique), le nombre de classes changeant. Dès lors, peut-être utiliser un lr plus faible pour le reste du réseau.

Bonjour,
 
Je suis data scientist avec 3 ans d'XP et un background plutôt orienté stats/ML/DL. J'ai eu très peu de formation informatique dans mon parcours académique (prépa maths + école d'ingé généraliste).
 
Bien qu'un outil essentiel dans mon travail quotidien, le code n'a jamais été ma priorité. Cependant, depuis quelque temps je me rends compte que le job de data scientist devient de plus en plus saturé, et pour se démarquer il faut maintenant avoir un profil beaucoup plus orienté informatique, type ML Engineer ou même Data Engineer.
 
De plus, jusque là, j'ai bossé pour une boîte où la data science est plutôt vu comme un truc fantaisiste pour faire plaisir aux actionnaires (et accessoirement, l'informatique est une fonction support, donc pas une grande culture de ce côté là non plus). Pire encore, je ne suis pas dans une équipe de data scientists, mais intégré dans une BU marketing et mon manager est un pur commercial et mes collègues sont plutôt des product owners. Au final j'ai beaucoup travaillé en complète autonomie alors que j'aurais préféré avoir un peu de mentoring de ce côté là.
 
Je change d'employeur prochainement, du coup j'aimerais laisser cette expérience derrière moi et repartir sur de nouvelles bases mais je sais pas trop par où commencer. Il est possible que ça soit la même chose chez ce nouvel employeur (plutôt orienté R&D en ML/DL, les entretiens techniques étaient purement focalisés sur l'aspect data science/stats/ML, aucun code), mais je voudrais ne pas faire la même erreur qu'avant et apprendre à produire du code de qualité pour ne pas passer pour un guignol.
 
Avez vous des suggestions, un bible de référence, un MOOC ? J'aimerais rester uniquement sur du Python.

La bible IMHO c'est "learning python" (o reilly)
Sinon j'aime bien ce site: https://roadmap.sh/python
Qui répertorie pas mal de trucs à connaître (très complet)

Pas spécifique à python mais au dev en général il y a aussi des bouquins comme "coder proprement" ou encore des trucs sur les design patterns.

Pour appliquer tout ça et voir un peu l'état de l'art le mieux c'est d'aller sur un repo open source connu (PRAW par exemple est très clean) et essayer de comprendre tout ce qui s'y trouve (ex: c'est quoi ce fichier pre-commit-config?)

Bonjour,
 
• 3 ans dans une petite multinationale A en tant que data scientist (même si je vais beaucoup de choses qui sortent du contexte de la data science)
• dans cette boîte, j'ai été à l'origine d'un projet de DL de la prise d'initiative à la mise en prod avec succès,  
et sur lequel j'ai travaillé seul et je maitrise donc très bien l'outil que j'ai développé
 
• fin 2022, je décide de postuler ailleurs pour diverses raisons, envie de faire que de la data science (et pas du dev ou du data engineering/analysis ou du devops) et pour des raisons financières
• je reçois différentes offres d'embauche dont une grosse multinationale B dans un tout autre secteur d'activité que A et une start-up C qui cherche quelqu'un pour développer une solution identique en tout point à l'outil que j'avais développé chez A.
 
En terme de package annuel brut (salaire fixe + variable), ça donnait :
 
- A : 58k (même s'ils ont fini par faire une contre offre à 80k)
- B : 80k
- C : 60k
 
J'ai donc fait mon choix facilement en me tournant vers B puisqu'en plus du salaire, les primes et avantages sociaux étaient juste hallucinants.
 
 
• démission posée et préavis terminé, j'ai récemment pris poste chez B
• j'halucine toujours en découvrant tous les avantages qu'il y'a même si je déchante un peu plus côté épanouissement pro (un mec qui s'apprête à partir de la boîte me dit grossomodo qu'il y'a du taff bien chiant non-DS, par contre qu'en charge de travail c'est très light)
• quelques jours plus tard à peine, l'entreprise C me recontacte pour voir si je suis toujours en recherche (je leur avait dit à l'époque que le salaire était trop bas)
• je leur dis que non, j'ai déjà commencé un CDI, mais un peu comme ça, je leur demande s'ils seraient intéressés pour un contrat de freelance pour travailler sur le fameux projet que j'avais déjà développé chez A.
• surprise, le mec (cofondateur de la boîte) me dit qu'il est extrêment intéressé et on a schédulé un call prochainement pour en parler
 
 
 
Précision :  
• Mon contrat chez B, en forfait jour, ne contient pas de clause d'exclusivité.
• A, B et C sont tous dans des secteurs différents, même si forcément de par la nature de la data science, on peut retrouver des sujets similaires, notamment entre A et C, pas vraiment B. Ils sont d'ailleurs complètement différents en taille.
• le freelance m'intéressait mais j'osais pas trop me lancer vu que je suis encore en début de carrière. La proposition de C pourrait me permettre de mettre un premier pied à l'étrier sans risque.
 
 
Est-ce que certains ont été dans une situation similaire ? J'ai l'impression que toutes les étoiles sont alignées pour que je cumule à la fois le CDI chez B et le contrat freelance chez C.
 
Que me suggérez vous comme TJM ? 600€ ?
Quels sont les points d'attention à prendre en compte et à discuter avec C ?

C'est plutôt avec B que tu dois discuter, pour être sûr que tout est OK.  
Avec C vérifier que la charge de travail et les échéances sont compatibles avec ton taf chez B, a moins qui ça ne te dérange pas de faire 80 heures semaine
 
J'ai fait ça à un moment, grosse cogip a accepté que je fasse du freelance pour mon ancienne boite (secteurs complètements différents).
 
Pour le TJM la comparaison n'est surement pas interessante, je laisse des DS avec la même experience te répondre

OLALA COMMENT CA ME CASSE LES COUILLES
 
2 ans qu'on se fait martyriser avec des deadlines et des expectations irreelles genre "Ouai Corentin DSL mais faut que notre pipeline marche pour X nouvelle maladie qu'on avait pas anticipee et faut presenter ca au board meeting lundi dsl mdr" et la ces gros fils de pute chouinent car le training code est pas factorise et optimise
 
BAH OUI J'AI PAS EU LE TEMPS DE RE-ECRIRE DETECTRON2 PAR MOI MEME DESOLE HEINNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN

Faut embaucher des MLeng pour récrire le code dégueulasse des DS

+1

Déjà il est pas dégueulasse hein

Et faut savoir ce qu'on veut hein, soit créer des features FAST pour griller la concurrence et lever un max de fonds soit faire un truc super propre et devenir le référent open source de X industrie

Mais les 2 c pas possible

Sinon le big boss m'a dit qu'il allait mettre mon nom sur un brevet qu'on depose car "j'ai fait la majorite du taf", sans deconner je sais mm pas a quoi il fait reference    
 
Faut vraiment que je me barre et que je fasse un vrai taf qui fait du vrai sens dans la vraie vie (Servir des cafes, ouvrier du batiment, eleveur de chevre etc)  

Je débarque sur le thread, t'es dans une startoupe française ?  

 
 
Startup en effet (je me sens ENTREPRENEUR, jeune et DYNAMIQUE ), à l'étranger nonobstant (Asie)

Les brevets c'est cool, mais si vous pouviez en faire un (des) papier ou de l'open source vous récupèreriez plus de reconnaissance.
Tu vas me dire que la boîte a pas intérêt à balancer toute son IP gratos, sauf qu'aujourd'hui en DL les avantages compétitifs sont tellement minces que n'importe qui peut les reproduire sans grande difficulté. Surtout quand des mecs comme lucidrains sortent le code de n'importe quel papier closed-source moins de 24h après sa sortie

 
Pleinement d'accord
 
Je sais pas comment ils pourraient le faire appliquer mais bon osef franchement. On a qq publis sympas en effet
 
Lucidrains c'est une machine, je sais pas comment il fait. En plus son code est vraiment simple et propre

Je connaissais pas lucidrains mais apparemment tu peux l'embaucher en tant que consultant pour qu'il reimplemente un code en particulier
Vous avez qu'à faire ça pour ta codebase

 
 
Il doit être dans son code tout le temps depuis des années.
A la fin tu connais PyTorch et le sota par coeur
Et comme on fond chaque papier apporte souvent juste une nouvelle méthode, c'est pas trop long à traduire en code
 
Mais lui le fait pour tout ce qui sort. Des fois je me demande si c'est vraiment une seule et même personne derrière tout ça  

c'est la jungle les formations data    
y'en a des valables en 100% distanciel ?

Des gens qui font du federated learning avec succès ici ?
 
On se fait soulever par la régulation faut qu'on s'y mette

hello, est ce que des gens pratiquent ou on pratiqué la data dans la chimie ou la bio info ? En particulier les interactions ligands protéines.  

 
Hmmmmmmmmmmmmm
 
Dans quel but ? Ajouter une ligne au CV pour booster ses chances d'obtenir un entretien ? Sans etre mechant le marche est assez sature ca me parait un peu foireux comme plan
 
Si c'est pour acquerir des competences, pas besoin de formation en ligne, prends juste un projet qui te plait et fais le en autoformation (chatgpt est un excellent moyen) et mets sur github

C'est quoi le problème avec la régulation ?

Puisque le topic est un peu mort je me permets une anecdote marrante  
 
Notre boss s'est transformé en boomer évangéliste IA et passe son temps à dire à quel point chatgpt a changé le monde etc blabla si bien qu'utiliser chatgpt / LLMs ça fait parti de nos objectifs de perf (d'où découlent nos bonus). Meilleur, il veut que tous nos trucs passent par GPT d'abord (mails partenaires, code etc) et qu'on doit être capable de lui montrer le prompt en permanence pour justifier l'utilisation de GPT
 
Il a aussi créer une board "les super pouvoirs de l'IA" avec des exemples de prompts GPT et des screenshots de résultats.
 
Pour déconner avec un collègue on a fact checké en détails cette board; tous les résultats avaient des problèmes majeurs voir des trucs totalement inventés
 
Un des boomers du bizdev avait demandé à google bard de faire un tableau comparatif entre nous et les concurrents, bien entendu il était content de montrer à quel point on était meilleurs selon l'IA. Pour troller j'ai repris le même prompt en changeant l'ordre des entreprises et là pas de chance Google Bard nous chiait dessus comparé à la concurrence
 
Le shitstorm dans le chat group était succulent mais jpense maintenant je suis sur la sellette
 
D'ailleurs je trouve Bard nul à chier, c'est objectivement beaucoup moins fiable que GPT nonobstant le fait que les réponses arrivent beaucoup plus rapidement. Google c'est vraiment surcoté cette entreprise, même leur moteur de recherche est archi censuré et est bien daubé maintenant
 
 
 

 
On a des données sensibles qui sont pas censées bouger de leur serveur donc federated learning obligatoire. À tous les coups c'est encore 1 putain de buzzword et ça va pas marcher

JPP de la hype sur chatgpt. Dès qu'un truc fait le buzz chez les journalistes t'en entends parler tout le temps peut importe l'intérêt réel sur le fond

J'avais jamais entendu parler du federated learning par contre.
Mais pour avoir bossé sur des données sensibles je suis un peu dégoûté par l'aspect régulation qui est hyper lourd. C'est dommage parce que c'est là qu'il y a les applications les plus utiles.

Le federating learning ça a l'air bien sur le papier
En pratique ça doit être ultra casse couille à gérer autant en technique que juridique etc
 
Sinon NC je compatis  
De toute façon t'avais pas un peu envie de te barrer non ?

Bon courage avec les départements IT des hôpitaux pour installer des trucs de federated learning
J'ai déjà eu des projets complètement annulés à cause de ça (même pas federated learning, juste pour faire tourner des scripts sur leur système)

Vu comment c'est parti je sens que jvais faire du federated learning du bled à coup de tout télécharger localement et hop

C'est très bien le FL

On a du se croiser