Retour d’expérience Challenge PKDD 2001-2003

Plan

• Types de données fournies lors des challenges

• Démarche suivie lors des 3 challenges

Données fournies

2001

• Données 2 bases issues d’un hôpital, d’un centre de

consultation et 1 banque d’examens biologiques

• Objectifs

Découvrir des facteurs favorisant les thromboses dans les collagénoses.

2002-2003

• Données 2 bases issues d’une étude de cohorte, l’une

mesurant divers paramètres à l’entrée des patients dans l’étude, la deuxième indiquant le suivi des patients durant les 20 ans qu’a duré l’étude.

• Objectifs Découvrir les facteurs favorisants et protecteurs de

l’athérosclérose ainsi que leurs éventuelles interactions.

Types de données

• Pour les 3 années, il s’agit de bases relationnelles ‘entité-relation’ simples avec une clef primaire reliant les tables (numéro de patient).

• Selon toute vraisemblance, il n’y a pas eu de coopération entre les concepteurs des bases et les informaticiens.

« stockage Excel »

Démarche commune pour les 3 ans

• A Nettoyage et normalisation• B Comprendre les données avec l’expert

– Définir les objectifs

– Reformulation des données en fonction des objectifs

• C Test et vérification du modèle choisi – Essai – erreur : modification du modèle

• D Validation classique

A Nettoyage et normalisation

2001

• Exemples (individus) dans 1,2 ou les 3 tables

+ : Utiles pour corriger des erreurs de saisie car infos

redondantes

- : Pas de recette pour éliminer les doubles, corriger…

– Expert ici peu ou pas utile (se renseigner sur Internet peut suffire !)

2002 / 2003

• Aucun nettoyage nécessaire : tables fournies avec explications claires et précises.

Conclusion

Quand cette phase est nécessaire :

– Pas de recette miracle : long, fastidieux, peu automatisable.

– Problèmes aisément prévisibles (et évitables) lors de la conception au départ de la base de données !

B Compréhension des données

B 1 Définir des objectifs

Comprendre les données2001

• Sujet de l’étude : collagénoses. Maladies compliquées, mal comprises y compris par les experts.

• Il en découle un manque de recul sur ce qui est découvert : L’expert ne sait pas et n’a ni recul ni

connaissances ni moyens pour vérifier la validité et la légitimité de la ‘pépite’ …

Comprendre les données2002 - 2003

• Sujet d’étude : l’athérosclérose. Domaine connu et bien balisé par la science médicale.

• Facilité pour l’expert pour trancher entre des résultats sans intérêt ou très intéressants.

Comprendre les données2002 - 2003

• Exemple

– 2002 : 160 attributs familiaux• Peu de contenu mais très précieux, l’expert le sait

– 2003 : remplacé par un indicateur de risque• Données plus facilement utilisables qu’en 2002 mais

moins précises. Concrètement, plus facile pour l’informaticien mais moins d’intérêt pour le médecin.

Conclusion B1

• Des objectifs doivent être donnés au projet, avant même d’envisager de répondre à une question sur le domaine ciblé.

• Ces objectifs dépendent par exemple de la disponibilité ou non d’un expert.

• Exemple : donner de nouvelles pistes révolutionnaires au domaine ? Préciser un point ? Prouver la validité de nouveaux outils ?

Conclusion B1

• Problème posé :

– Si le domaine fouillé est déjà bien connu, j’avance dans la lumière mais le risque est la ré-invention de la roue… La présence d’un expert semble inévitable.

– Si le domaine fouillé est largement incompris, je peux certes découvrir l’inespéré (et seul)

• mais ne pas le savoir !• ne pas être validé, les savoirs issus de l’informatique

n’étant pas validés par l’épidémiologie actuelle !

B 2 Reformulation des données en fonction des objectifs

Sélection des attributsRedescription des données

• En fonction des objectifs– Création d’attributs par combinaison, etc.– Suppression d’attributs inutiles ou peu

informatifs.

• Reformulation des données

• Définition d’un modèle par l’expert

C Test et vérification du modèle choisi

Test du modèle et modifications

• Confrontation du modèle avec l’expert– 2001 : utilisation de C4.5 pour filtrer les

attributs inutiles– 2002 : a priori sur l’activité physique

• Mauvaise modélisation

• Reformulation : on ne conserve que le sport

• Modèle plus fiable et validé par l’expert

D Validation croisée classique

• 2001 : protocole ‘5 CV’

• 2002 -2003– Utilisation d’une partie des données de Entry

pour valider l’estimateur de risque– Utilisation des données de Control pour

confirmer l’estimateur de risque et isoler des individus mal étiquetés dans Entry

Retour sur la démarche

• Originalité car présence permanente de l’expert

• Coopération efficace entre l’expert des données et le chercheur informatique : il faut rester dans les clous des deux domaines pour espérer des résultats reconnus ET intéressants.

Retour d’expérience

• Conception / manipulation des bases en commun indispensable.

• Le but du travail doit être connu : – Permettre une avancée dans le domaine de

recherche (ici médecine) ou en informatique ? – Mettre en avant l’efficacité de nouvelles

méthodes ? Prouver leur validité et donner une légitimité ?