Vote utilisateur: 0 / 5

Jusqu'à tout récemment, la plupart des entreprises avaient constaté deux flux de travail distincts, qui ne se chevauchaient pas, lors de la création d'une application compatible avec l'IA: un chemin de développement et un chemin data sciences.

Souvent, les deux groupes construisent en fait des solutions fonctionnelles avec des scripts similaires en utilisant quelque chose comme Python ou C / F #. En outre, une fois qu'un data scientiste termine l'étape d'évaluation et de sélection du modèle du processus de sciences de données, il existait un «vide de confusion» en ce qui concerne les meilleures pratiques concernant l'intégration dans de nouveaux processus métier existants ou en augmentation, chaque partie ne comprend pas très bien comment soutenir l'autre / quand à s'engager. À mon avis, une grande partie de la convergence a été alimentée par la popularité et l'utilisation croissantes des services de conteneur comme  Docker et Kubernetes, en particulier dans le monde des DevOps.

Alors, comment ces couloirs convergent, demandez-vous ?

Vous pouvez planifier et créer un pipeline d'intégration continue pour une application d'IA pour les débutants. Le pipeline démarre à chaque nouvelle validation effectuée par le data scientiste, ce qui déclenche les cycles de tests. Si le test réussit, il utilise la dernière version, le regroupe dans un conteneur Docker, ainsi que tous les packages nécessaires et les dépendances / versions des packages pour une modélisation réussie.

Le conteneur est ensuite déployé à l'aide d'un service de conteneur hébergé dans le cloud, comme @Azure Container Service (ACS) et les images suivantes sont stockées de manière sécurisée dans le registre de conteneur associé (ACR). Ceci est très utile pour le développement à petite échelle, mais lorsque vous voulez opérationnaliser ou déployer en production, il faut s’orienter vers un service comme Kubernetes pour la gestion / orchestration des clusters de conteneurs (les autres alternatives de service sont  Docker-Swarm / Mesos). .

L’application extrait en toute sécurité le dernier modèle pré-entraîné ML  à partir d’un compte de stockage de blob basé sur le cloud et le regroupe dans l’application. L’application déployée contient le code de l’application et le modèle ML dans un conteneur unique et les actifs et sorties deviennent une partie du code d’archivage qui est renvoyé dans le référentiel de codes d’entreprise pour contrôle de version, etc.

Cela sépare les développeurs d'applications et data scientistes, afin de s'assurer que leur application de production exécutent toujours le dernier code avec le dernier modèle ML. 

Vote utilisateur: 0 / 5

Dans l'univers de la data science, les problèmes d'apprentissage avec des données étiquetées (pour lesquelles nous connaissons déjà la variable cible) sont facilement disponibles et accessibles. Leur résolution dépend souvent de leur niveau de difficulté et de la façon avec laquelle nous traitons les données. Dans ce cadre, l'algorithme enseigne à lui-même, pour apprendre à partir des données étiquetées fournies, afin de proposer des solutions pertinentes. Par exemple, la prédiction des clics et la classification des e-mails sont de bons cas de figure, car ils ont une distribution stable et des étiquettes collectées presque chaque jour. Cependant, chaque domaine a ses propres défis d'exploration et d'analyse de données. L'un de ces défis est lorsque nous ne possédons pas de données réelles sur la variable cible, et que malgré cela nous avons une problématique à résoudre. Ces cas sont les problèmes d'apprentissage non supervisés.

Ces problèmes d'apprentissage machine se classent parmi les big problèmes du ML où les données étiquetées sont rares ou même indisponibles. Néanmoins, nous procédons à la création de données personnalisées afin de résoudre les algorithmes de ce type, mais cela reste inefficace. Ce qui nous conduit à des erreurs embarrassantes résultant d’un surentraînement des algorithmes. Les processus actuels de création de ces systèmes d'apprentissage nécessitent un grand effort et des praticiens ayant une connaissance approfondie de l'apprentissage automatique. Cela limite considérablement le nombre de systèmes d'apprentissage automatique pouvant être créés et conduit à une inadéquation entre la demande de systèmes d'apprentissage automatique et la capacité des organisations à les créer. Aujourd’hui, au sein de notre direction au sein d'AXA France et de manière générale, nous pensons que pour répondre à cette demande croissante de systèmes d’apprentissage automatique, nous devons augmenter de manière significative le nombre de personnes capables d’enseigner des machines. Nous estimons que pour atteindre cet objectif, nous devrions rendre le processus d’enseignement des machines facile, rapide et surtout accessible à tous. Étant donné que l'apprentissage automatique repose sur la création des algorithmes et sur l'amélioration de la précision des « enseignants », l'enseignement des machines se concentre précisément sur l'efficacité des « enseignants ». De ce fait, nous considérons que l’enseignement des machines en tant que discipline est un changement de paradigme qui suit et étend les principes du génie logiciel et des langages de programmation. Nous mettons l'accent sur l'interaction de l'enseignant et de l'enseignant avec les données pour proposer des solutions adéquates au besoin et limiter le temps de traitement.

Auteur: 

Namaa GHASSAN

PhD condidat At Faculty of science Ben M'Sik Casablanca.