Mireille Blay-Fornarino

Eléménts à détailler….

Algorithmes : Il existe différentes sortes d'algorithmes impliqués dans un pipeline de ML. Certains préparent les données, nous les appellerons préprocesseurs et d'autres construisent des modèles de ML, nous les appellerons algorithmes d'apprentissage;

Méta-data : Les jeux de données utilisés en ML sont souvent identifiés par des méta-data, qui permettent de les caractériser. Les méta-données peuvent correspondre à des valeurs discrètes, continues ou des fonctions. Elles caractérisent les données (eg nombre d'instances, d'attributs), des attributs précis (eg. Valeur manquante par absence de relevés qui impliquent que la valeur pourra être extrapolée ou valeur manquante signifiant que l'on est dans un cas particulier, et dans ce cas l'absence de valeur est une information en soit : les 2 cas peuvent arriver dans le même jeu de données), sur la structuration des données (eg graphes, images, …). Pour les calculer, il est parfois nécessaire d'avoir recours à des algorithmes qui pour s'exécuter nécessitent beaucoup de temps et/ou de mémoires.

Préconditions : Les algorithmes de ML, comme tout algorithmes, ne sont applicables que sur des jeux de données qui respectent certaines préconditions. Celles-ci sont partiellement formalisées, en général en terme de méta-data sur les jeux de données (eg. Capabilities de weka). Certains algorithmes intègrent la vérification des pré-conditions et échouent avec des explications lorsqu'elles ne sont pas respectées (eg. Levée d'exceptions). D'autres échouent simplement sans qu'il soit toujours facile de caractériser l'erreur comme l'inadéquation du jeu de données et de l'algorithme.

Post-conditions : Les conséquences de l'application d'un algorithme ne sont pas formalisées, mais certaines propriétés sont déductibles par l'humain de la classe d'algorithme (eg remplacement des valeurs manquantes), ou de la description de l'algorithme lui-même. Les conséquences d'un préprocesseur peuvent être multiples sur le jeu de données (eg normalisation qui enlève tous les attributs nominaux).

Ordre des compositions : Il est courant d'utiliser des ordres pré-établis de composition des classes d'algorithmes, et la littérature expose de nombreuses bonnes pratiques. Néanmoins, (1) il reste de multiples choix possibles parmi tous les algorithmes dans chaque classe, (2) les choix faits pour une étape jouent sur les choix réalisés aux étapes suivantes, (3) l'optimisation locale, pour autant que l'on sache la calculer, n'a pas pour conséquence directe l'optimisation globale du pipeline, (4) les ordres peuvent varier en fonction du problème et des algorithmes utilisés.

Propriétés inter-algorithmes : Certains algorithmes sont “souvent/systématiquement” utilisés ensemble ou au contraire jamais. Cela rejoint les bonnes pratiques. L'ordre d'application de 2 algorithmes peut ou non avoir un impact sur le résultat. En identifiant, ces différentes propriétés, il est possible de réduire l'espace des compositions.

Bibliothèques d'algorithmes : Il existe un très grand nombre d'algorithmes. Certaines bibliothèques caractérisent certaines préconditions, mais les jeux de donnés variant beaucoup, et la caractérisation des méta-data restant un sujet d'études, ces préconditions quand elles sont explicites, restent partiellement définies. Les algorithmes sont classés différemment en fonction des bibliothèques.

Expérimentations : La littérature et les plateformes telles que OpenML regorgent d'expérimentations dont la reproductibilité est de plus en plus souvent possibles, de même que la caractérisation des pipelines utilisés. En disposant des expérimentations et de leur résultat, les DS trouvent des modèles de pipelines dont ils s'inspirent pour traiter de nouveaux problèmes.