Comparatif MLOps : Dataiku et DataRobot face aux alternatives open source

Comparatif MLOps : Dataiku et DataRobot face aux alternatives open source L'opérationnalisation des modèles de machine learning est portée par de nombreux éditeurs d'outils d'IA. Comparatif de leurs fonctionnalités.

Depuis environ deux ans, le MLOps ne cesse de faire parler de lui. "La popularité de cette notion a décollé en 2019 sur Twitter", se rappelle Clément Moutard eu sein de l'entreprises de services Saegus. Comment définir ce concept ? "Le MLOps a objectif de concevoir des modèles de machine learning (ML, ndlr) qui soient adaptés à leur déploiement en production. A l'instar du DevOps pour les applications, il vise aussi à piloter l'ensemble de leur cycle de vie", résume le lead data scientist.

Sur ce segment, on retrouve les ténors des plateformes d'IA au premier rang desquels le français DataiKu et l'américain DataRobot. Mais aussi des outils plus spécialisés le plus souvent open source, parmi lesquels MLFlow ou encore Kubeflow, la non moins célèbre brique conçue par Google pour déployer des modèles de ML sur une infrastructure Kubernetes.

Comparatifs des outils de MLOps
Techno Experiment tracking et versioning AutoML Orchestration et gestion des déploiement Monitoring Collaboration Licence
Dataiku x   x x x Propriétaire
Datarobot x x x x   Propriétaire
Domino Data  x   x x x Propriétaire
Kubeflow     x     Open source
Metaflow x         Open source
MLFlow x   x     Open source
Autres solutions souvent évoquées : Algorithmia (acquis par DataRobot), Cnvrg.io, Polyaxon, Valohai et plus récemment Comet, Landing AI ou encore Weights & Biases.

Comparé aux autres acteurs de ce comparatif, Dataiku affiche une longueur d'avance. "Le studio de data science est très fort pour démocratiser l'accès à la donnée et analyser l'explicabilité des modèles", argue Shriman Tiwari, tech lead et manager en data science au sein du cabinet Keyrus. Clément Moutard insiste : "Le pertinence de Dataiku réside surtout dans ses fonctionnalités de collaboration." Et l'expert de citer son wiki, sa console de partage de tableaux de bord de résultats ou encore son système de gestion des rôles et de traçabilité des actions. Des dispositifs qui permettront de lever les freins culturels entre les différentes parties prenantes d'un projet d'IA : data scientist, data ingeneer, business analyst et utilisateurs métier... Revers de la médaille : le coût du produit devient rapidement élevé sur de fortes échelles d'audience.

"DataRobot offre un cockpit d'industrialisation des modèles mieux conçu"

"A l'inverse, DataRobot offre un cockpit d'industrialisation des modèles mieux conçu. Il est à la fois simple et ouvert sur l'écosystème", estime Shriman Tiwari. "A la différence de Dataiku, il pourra aisément intégrer des algorithmes créés dans d'autres environnements de développement, avec un passage à l'échelle moins onéreux lors du passage en production." Parmi les plateformes d'IA généraliste, Domino Data est évoqué par les spécialistes comme alternative possible à Dataiku et DataRobot. "C'est une solution de MLOps très complète avec des possibilités de gestion d'infrastructure IT particulièrement matures", reconnait Shriman Tiwari.

Les nœuds d'automatisation de Dataiku automatisent le monitoring, la mise à jour des data sets d’apprentissage, le réentrainement des modèles... © Capture JDN

Qu'en est-il des outils de MLOps open source ? Sur ce terrain, Clément Moutard chez Saegus insiste notamment sur MLRun. "Cette solution est particulièrement intéressante en matière d'orchestration et d'automatisation des pipelines MLOps, avec une gestion du passage à l'échelle sur Kubernetes aussi bien horizontale que verticale", constate le lead data scientist, avant d'ajouter : "Les technologies open source permettent de créer une solution de best of breed." Partant de cette approche, les équipes de Saegus ont créé un kit de démarrage MLOps combinant trois briques open source :  MLFlow pour concevoir les modèles, Seldon pour gérer leur monitoring et leur explicabilité, et l'infrastructure Spark pour les déployer.

9 piliers fonctionnels

Pour Clément Moutard, le MLOps se décline en neuf piliers fonctionnels :

  1. L'experiment tracking pour gérer la phase d'entrainement des modèles et la manière de les comparer entre eux et/ou de comparer leurs résultats selon leurs différents paramètres.
  2. Le versioning d'artefacts pour gérer les versions des modèles et des données utilisées pour les entrainer, ainsi que des métriques de résultat associées.
  3. L'orchestration du pipeline MLOps qui recouvre l'apprentissage des modèles, leur mise en production, leur réentrainement, etc.
  4. Le déploiement pour gérer la mise en service des modèles.
  5. La supervision pour suivre les écarts avec les résultats attendus, monitorer les données entrantes en vue d'identifier les éventuelles dérives, décrypter l'explicabilité.
  6. Le registre de modèles (ou model store) pour stocker les modèles et leur historique de versions, en vue de faciliter leur maintenance et leur réutilisation.
  7. Le feature store pour stocker les data sets et documenter leur features d'entrainement, avec pour objectif, là encore, de faciliter maintenance et réutilisation.
  8. L'espace de collaboration pour rationaliser le partage d'informations entre data scientist(s), data ingeneer(s), business analyst(s) et expert(s) métier.  
  9. L'ITOps pour piloter le provisionnement des infrastructures d'entrainement et d'inférerence (ou déploiement) et d'optimiser les coûts associés.

La guerre des feature stores

Côté cloud providers, Google est le seul à présenter sa plateforme d'IA (Vertex) comme une offre orientée MLOps. Force est de reconnaitre qu'elle inclut la vaste majorité des piliers ci-dessus, jusqu'à un service managé de feature store (Vertex AI Feature Store). Une fonction rarissime dans le MLOps. L'un des seuls acteurs à intégrer ce volet n'est autre qu'AWS avec SageMaker Feature Store. "Sur le cloud de Microsoft, on pourra recourir au service managé reposant sur le delta lake de Databricks qui intègre cette dimension", précise Shriman Tiwari. Comme Google avec Vertex AI Model Monitoring, Amazon propose également une offre ad hoc pour monitorer les modèles via SageMaker Model Monitor. Là encore, ce n'est pas le cas d'Azure qui implique de passer par son service de monitoring global pour cette tâche (Azure Monitor). Pour la gestion d'artefacts, idem. Il faudra passer par Azure DevOps.