2019.12.18_workshop-1_notes.md

Atelier du 18 décembre 2019

Présents : @ClementMayer, @bowni, @SaboniAmine, Jeverson Moreira, @celinejacques, Grégory Chatel, Annass Mahar, Mouad Fettachi, Romain Boidin, @RomainBey
Merci d'avoir bravé les difficultés de transport 💪 !

Excusés : Nabil Rachdi, Timothée Faucon, Marco Fiorini, Marie Langé, Grégoire Mialet, Mélodie Bernaux, Mélanie Didier, Marie Ngo Loog Kingand, Laurent Labous, Hassanatou Thiam, Cédric Meurée, Chengheri Bao, Franck Halegoi, Ahmed Nomaine, Sohreab Deljavan, Clara Chaouat, Cindy Lhermite, Mostapha Benhenda, @DaBoos, @mattthieu
Navré que vous ayez été empêchés mais au plaisir de vous retrouver lors du 2nd atelier 🤞

Notes / Matière brute

(à lire en regard du contenu contexte, risques, mesures rédigés dans README.md en date du 18/12/2019, commit 7d6c77fc56747078e79eba250a5ce04f2fd02943)

• Périmètre de l’initiative :

  • comprendre “data science” avec un sens large (y compris les systèmes experts par exemple)
  • cible : l’activité data science d’une organisation. Question sur l’opportunité de présenter également une version light / quelques questions ciblant un projet spécifique

• Organisation du contenu :

  • Ajouter aux référentiels des exemples positifs / bonnes pratiques
  • Section "à creuser / théorique"
  • Documenter des exemples iconiques

• Risques et mesures / bonnes pratiques :

  • Conformité :

    • Veille juridique nécessaire notamment données personnelles
    • Ne pas voler, empoisonner...

  • Données :

    • Lorsque données synthétiques, le préciser
    • L'hébergement est sensible, notamment avec le Cloud Act. Risque juridique : où se trouve la donnée ? AWS publie chaque mois les demandes de la justice américaine
    • Biais données de tests, déséquilibres de représentation
    • Choix du dataset d’entraînement vs. contexte d’usage d’un modèle : exemple des photos de personnes positionnés devant une porte à l’hôpital

  • Modélisation :

    • Biais dû à l'architecture d'un modèle et/ou de l’algorithme d’apprentissage et pas que des données → exemple du vecteur qui genre une profession dans les systèmes d’apprentissage (cas à creuser)
    • Prendre en compte les modèles qui apprennent en continu, apprentissage par renforcement
      • Dispositif médicaux : validation sur le modèle existant mais pas d’apprentissage continu → questionner la validation d’un modèle à travers le temps

  • Validation, performance :

    • RC2-01 : dédoubler avec les données de tests (pas que données d'entraînement)
    • Un modèle doit avoir une plage de prédictions "indéfinies", expliciter les seuils
    • Drift du domaine d'application et donc du modèle par rapport à celui-ci. Dégénérescence des modèles (condition de mesure qui change, apprentissage renforcé qui fait dévier le modèle…)
    • Niveaux d'interprétabilité : en fonction de ce que le modèle fournit : prediction, proba / niveau de confiance, Features explicatives globales, Features explicatives pour chaque prédiction, Preuve / vérité
    • Trade-off entre la complexité d’un modèle et sa performance → cas concret à identifier (solutions existantes tel que LIME à creuser)

  • Historique, généalogie :

    • ? quels sont les risques induits par la perte d'historique

  • Responsabilités :

    • Proposition : expliciter les contextes d’utilisation, le "domaine de vol" pour chaque étape (données, modélisation...)
    • Limiter les outputs exploités à ceux sur lesquels on maîtrise l'usage et les conséquences
    • Comportement responsable si on se rend compte qu'un modèle qu'on utilise a un problème
    • Utilisation d’un modèle standard, conséquence d’une éventuelle faille révélée
    • Nécessité de mettre en place des processus manuels dégradés en cas de faillite d’un modèle + processus pour stopper un modèle
    • Prévoir un check / validation humaine régulier
    • Avoir des certifs sur la SSI ?
    • Gouvernance globale, chaine de responsabilité données - conception - exploitation.
    • Question des assurances autour de modèles prédictifs / systèmes automatiques
    • Inclure dans les formations des employés une rubrique sur la data science

  • Attaques :

    • Model poisoning
    • Failles 0-day dans un modèle --> faire de la veille, savoir réagir
    • Vol de modèle par inférences : 'model stealing'
    • Vol de temps de calcul : 'adversarial reprogramming'

  • Externalités :

    • Bienfaisance et non-malfaisance
      • Modèle qui pourrait être utilisé pour de mauvaises fins
      • Modèle qui a des effets positifs et des effets négatifs non désirés
    • Automatisation de tâches et/ou d'emploi → besoin de réaliser des études d’impacts
    • Externalité : étendre à d’autres qu’environnemental