Industrialisation - Tech Radar

Adopt

Airflow

Gérer des flux de données fait partie des tâches du data scientist (préparation de données, lancement de construction de modèle). Or cette gestion est devenue complexe, montrant les limites des outils classiques d’orchestration comme CRON. En 2014, Airbnb a créé Airflow en réponse à cette complexité croissante. Airflow est une librairie Python open-source pour l’orchestration de tâches qui permet la création, le déploiement et le suivi de workflows.

Airflow modélise les flux de données complexes sous forme de graphe de tâches. Un ordonnanceur planifie l’exécution des tâches en fonction de leurs dépendances. Une interface web offre une vue d’ensemble, et la multitude de types de tâche qu’il est possible d’exécuter offre une flexibilité manifeste. Toutes ces fonctionnalités contribuent à simplifier l’automatisation des processus de traitement des données, faisant d’Airflow une technologie très utilisée aujourd’hui.

En data science, on pourrait être tenté de mettre en place un enchaînement d’étapes tel que pré-traiter un dataset, lancer l’entraînement d’un modèle, évaluer ses performances, et envoyer les résultats avec des scripts Bash, complexes à maintenir et utiliser. L’utilisation d’Airflow pour un tel cas d’usage offre une meilleure maintenabilité par les outils de monitoring et de gestion des erreurs disponibles.

Il existe plusieurs alternatives à Airflow pour des problématiques plus spécifiques. Par exemple, Dagster permet de communiquer de la donnée entre deux tâches sans passer par un service de sauvegarde de données externes (table, bucket). Kubeflow Pipelines est aussi une alternative intéressante, car elle vient avec des opérateurs pré-configurés pour le Machine Learning (un pour l’entraînement des modèles et un pour leur déploiement sur Kubernetes), mais son focus sur les problématiques de ML induit une communauté plus réduite. Enfin, la librairie DVC offre une brique pour définir et exécuter des pipelines, très pratique dans un contexte d’expérimentation pour son intégration avec le tracking d’expériences, mais pas adaptée à une exécution en production.

NOTRE POINT DE VUE

Aujourd’hui, nous recommandons Airflow pour une orchestration robuste de tâches hétérogènes, incluant des pipelines de Machine Learning en production. Lors de l’itération sur le modèle pendant le développement, nous préférons des outils comme DVC qui apportent de meilleures features pour le suivi des expérimentations.

Infrastructure as Code

Développer des solutions de Machine Learning nécessite de provisionner des resources (base de données, cluster de calculs...). Traditionnellement, cela était fait manuellement, créant un risque d’erreur humaine et ne permettant pas de redéployer rapidement une infrastructure.

L’Infrastructure as Code (IaC) est une approche pour créer et manager les ressources d’infrastructure d’un projet. Définie par des fichiers, l’infrastructure est versionnée et automatisée. Cette pratique permet de diminuer le nombre d’erreurs et offre aussi la possibilité de répliquer des environnements rapidement, de manière cohérente tout en pouvant les faire évoluer facilement.

L’Infrastructure as Code est une pratique assez standard sur les projets Web et Data Engineering mais elle est beaucoup moins répandue en Machine Learning. Définir au moyen de code les différents services de stockage de vos données, les environnements pour entraîner vos modèles, et l’infrastructure scalable pour la mise à disposition de vos modèles ou des environnements d’entraînements assure une maîtrise des composants, des coûts et surtout de leur évolutivité et leur mise à l’échelle.

Cette approche nécessite de maîtriser un outil comme Terraform et les bonnes pratiques associées. En effet, le code de l’infrastructure doit être maintenu avec la même rigueur et la même qualité que le code traditionnel.

NOTRE POINT DE VUE

Nous recommandons l’adoption de l’Infrastructure as Code (IaC) pour les projets de Machine Learning. Cette approche garantit une gestion d’infrastructure plus agile, scalable et efficiente, permettant des déploiements rapides et une meilleure cohérence. L’IaC renforce également la sécurité et la maintenance, essentielles dans des projets de ML.

Poetry

Pour gérer les dépendances sur un projet Python, on utilise traditionnellement Pip via le requirements.txt ou Conda qui gèrent seulement,
les dépendances primaires. Cela crée des problèmes de compatibilité, de dépendances, de versions différentes entre les différents environnements (dev, prod, etc...).

Poetry est un outil de gestion des dépendances et de packaging en Python qui permet de résoudre ces problèmes. Ses principales caractéristiques sont :

1. Résolutionnrobuste des dépendances : Poetry utilise un algorithme robuste de résolution de dépendances pour éviter les conflits
entre les bibliothèques. Cela évite ainsi des erreurs lors de l’installation et des résolutions manuelles de conflits.

2. Verrouillage des versions entre les développeurs : Poetry assure que tous les développeurs travaillant sur un projet utilisent exactement les mêmes versions des bibliothèques, éliminant les « pourtant ça marche sur ma machine » liés aux divergences de dépendances.

3. Facilité d’utilisation : Poetry offre une interface en ligne de commande intuitive et un fichier de configuration unique qui simplifie la gestion des dépendances et des configurations de projet. Cela rend Poetry accessible, y compris pour des data scientists moins expérimentés en gestion de packages Python.

Poetry permet aussi la gestion des environnements virtuels Python mais cette fonctionnalité est limitée, ne proposant pas d’activation automatique du bon répertoire de dépendances. Nous recommandons plutôt d’utiliser Poetry en tandem avec Pyenv et son plugin pyenv-virtualenv pour améliorer encore l’expérience de développement.

NOTRE POINT DE VUE

Nous recommandons fortement Poetry et le considérons comme un outil essentiel pour la gestion moderne des dépendances en Python grâce à son approche de résolution des dépendances, combinée à la facilité de synchronisation des environnements de développement.

Trial

LangChain

Les applications basées sur des Large Language Models (LLM) ont souvent de nombreuses briques fonctionnelles en commun. LangChain est un framework open source ayant pour but de simplifier leur mise en place et leur orchestration.
Il offre une interface haut niveau permettant de définir la logique des applications en étant agnostique du LLM et/ou du vector store utilisé. Malgré la promesse de LangChain de pouvoir facilement passer d’un LLM à l’autre, la migration entre différents LLM avec LangChain implique souvent d’ajuster les prompts et les paramètres pour maintenir une performance optimale de l’IA.

Actuellement en plein développement, LangChain présente encore quelques inconvénients :

• Une documentation complexe et parfois peu intuitive

• Les différents composants manquent de stabilité
- un problème qui peut être atténué, avec l’isolation récente des abstractions clés dans le module langchain-core

• L’intrication de son code et l’utilisation de callbacks peuvent complexifier la navigation dans le code et le debugging.

D’autres frameworks LLM comme LlamaIndex ou Haystack existent et présentent des avantages
et inconvénients similaires. Alternativement, il est possible de ne pas utiliser de framework et appeler les différentes briques (LLM, BDD vectorielle, ...) avec du code custom.

NOTRE POINT DE VUE

Nous recommandons l’utilisation de LangChain pour prototyper un projet LLM. Permettant d’abstraire l’appel aux LLMs et aux modèles d’embedding, il permet par exemple de développer une pipeline de RAG en quelques lignes de code. Au-delà du prototype, rentre en compte le trade-off entre valeur ajoutée du framework (souvent en fonction de la formation des développeurs) et complexité apportée.

LangChain est enfin un bon outil de formation sur les LLM, permettant d’explorer différents types d’application, de modèles, de stratégies de prompt engineering ou de BDD vectorielles.

Qarnot

Réduire sa consommation carbone devient un enjeux
pour les entreprises. Or les entrainements de modèles de machine learning sont de grands émetteurs de gaz à effet de serre.

Qarnot propose de limiter ces émissions et fournit du cloud computing “bas-carbone” conçu pour les jobs de rendering graphiques et les entrainements de modèles de Deep Learning. Début 2024, Qarnot promet une réduction de 50% de l’empreinte carborne par rapport aux autres centres de données en France et de 90% par rapport à ceux aux États-Unis, grâce à une approche de décentralisation et à la réutilisation presque totale de la chaleur produite. Pour un entrainement d’une heure l’économie d’empreinte carbone est d’environ 1kg CO2eq par rapport à des fournisseurs traditionnels comme AWS/GCP.

Qarnot a cependant des limitations en comparaison à ces fournisseurs :

Il y a un seul type de GPU disponible contrairement au catalogue proposé par AWS ou GCP qui en contiennent plusieurs dizaines.
Les instances ne sont pas connectées à internet, ce qui oblige à utiliser des Buckets Qarnot d’input / output (I/O) pour le transfert de données. Un SDK Python (open-source) est disponible pour le transfert de données et le déploiement de tâches sur Qarnot, cependant le transfert est relativement lent. La mutualisation permet de régler ce problème mais en apporte de nouveaux, notamment sur concurrence des jobs. Par ailleurs, les possibilités de collaboration au niveau de l’équipe / l’organisation sont limitées, seule la facturation est commune...

NOTRE POINT DE VUE

Face à la crise climatique, nous soutenons la démarche de Qarnot de réduction d’empreinte carbone des entraînements. L’utilisation de buckets d’I/O, l’automatisation de tâches via Python et la gestion des workflows avec DVC
ont été suffisantes pour contourner la plupart de ses limitations. Nous vous recommandons donc de tester l’outil par vous- même. Il est cependant prudent de continuer à évaluer Qarnot dans des contextes plus variés avant de l’utiliser à grande échelle.

vLLM

Gérer l’inférence et le servingde modèles de Deep Learning de manière optimisée est une problématique complexe, et c’est d’autant plus le cas pour les Large Language Models (LLM), très gourmands en ressources du fait de leur taille.

vLLM a été créé en 2023 pour permettre de servir un LLM et d’optimiser son inférence. Il permet de déployer un service dédié accessible par une API en configurant une image Docker. vLLM utilise un algorithme d’attention efficace, PagedAttention, qui permet un rendement jusqu’à 24x meilleur qu’avec une approche classique. De plus, vLLM implémente de nombreuses fonctionnalités facilitant l’utilisation des LLM en production, comme le continuous batching, permettant de batcher les requêtes des différents appels reçus, afin d’utiliser efficacement les ressources mises à disposition. Cet outil encore très jeune gagne rapidement en popularité, la preuve étant ses 13k étoiles sur GitHub (début 2024) ou le fait que Mistral mette à disposition une image vLLM pour son modèle Mixtral.

Il existe plusieurs alternatives à vLLM :

• llama.cpp : cette librairie permet de faire tourner des LLMs en pur C/C++, ce qui a l’avantage de rendre possible l’inférence de modèles sur de petits CPUs. Cependant, cette librairie a été conçue comme un playground et n’est pas faite pour une utilisation en production.

• D’autres outils plus généralistes qui existaient avant vLLM comme Triton inference server ou Tensorflow serving permettent de servir tout type de modèle. Tout comme vLLM, ces outils sont configurables via Docker et implémentent du continous batching. Plus anciens, ils ont pu être testés et approuvés sur beaucoup de cas d’usage mais ne sont cependant pas aussi efficaces que vLLM pour le serving de LLMs.

NOTRE POINT DE VUE

Nous suivons cette technologie depuis sa sortie et l’avons utilisée pour faire tourner l’inférence de LLM sur des projets internes. Utilisez-la sans crainte dans un contexte d’expérimentation pour éviter les coûts de hardware trop élevés (notamment grâce à PagedAttention).
Pour une utilisation en production, nous la recommandons aussi, mais gardez en tête que la technologie est encore jeune et utilisez-la avec précaution..

LangSmith

Les spécificités des Large Language Models (LLM) se sont accompagnés de besoins spécifiques de monitoring et
de collection de la donnée. LangSmith, développé par LangChain, propose de répondre à ces enjeux en loggant les différentes interactions avec les LLMs.

Il intègre de nombreux features autour de ce logging, comme la possibilité de modifier et réexécuter les prompts via une interface de “playground”, suivre les performances et les coûts ou créer des datasets à partir des logs. Initialement développer pour s’intégrer à LangChain, il peut aussi être utilisé indépendamment via un sdk.

Cependant, LangSmith est encore en version beta et l’utilisateur n’a pas de contrôle sur les versions (l’outil est mis à jour automatiquement): des instabilités sont donc parfois notées (par exemple une régression sur la feature
de playground). De plus, la transition vers un modèle payant, potentiellement onéreux, pourrait restreindre son accessibilité pour certains utilisateurs ou organisations. Face à ces limitations, LangFuse offrant des fonctionnalités similaires, émerge comme une alternative open-source intéressante.

NOTRE POINT DE VUE

Nous avons utilisé langsmith (via son sdk) sur un projet de Retrieval Augmented Generation.
Son intégration s’est faite sans souci et nous l’utiliserons sur de prochain projets (la question se posera de migrer vers Langfuse s'il devient payant). Le “playground” a notamment permis d’intégrer le product owner et son savoir métier dans les itérations de prompt engineering. Nous vous recommandons donc d’utiliser langsmith, tout en prenant en compte les limitations spécifiées.

Assess

Guidance

Avec l’avènement récent des Large Language Models (LLM),le besoin en outillage a augmenté pour intégrer de manière robuste ces solutions dans nos applications. Le framework open-source Guidance a été créé par Microsoft pour permettre un templating complexe de prompts. Il permet de s’interfacer avec plusieurs LLM (open-source ou non) en plus d’ajouter une boite à outils autour de l’inférence de ces modèles au niveau du token (grammaires, token healing, etc.)

Il se différencie du framework LangChain (dont la communauté est bien plus grande) par les points suivants :

Une emphase particulière sur le contrôle de la sortie du modèle, c’est-à-dire la possibilité de le contraindre à une structure de sortie (ou “grammaire”). Néanmoins, cette fonctionnalité clé n’est disponible que pour les modèles open-source, car les modèles disponibles via API ne fournissent pas les détails nécessaires pour appliquer ce post-traitement.
Il est très facile de définir des fonctions pouvant être appelées par le modèle (à la manière du “Function Calling” d’OpenAI (voir OpenAI Assistants API )

Le framework est beaucoup moins tourné vers l’utilisation de templates et de
chaines pré-construites comme LangChain (la vision semble plus tournée vers le sur-mesure).

La formulation des prompts se veut très simple d’accès mais nous trouvons que le changement de syntaxe opéré récemment, utilisant maintenant une surcharge de l’opérateur d’addition, peut s’avérer assez dur à lire et à écrire.

Le repository GitHub de Guidance compte plusieurs notebooks d’exemples à suivre, mais vous
en trouverez moins que pour un framework plus dominant comme LangChain.

NOTRE POINT DE VUE

Guidance est particulièrement puissant pour le templating et la génération de prompts. Encore en version bêta, sa communauté est encore réduite. De majeurs changements réguliers sont donc à attendre.

Pour des cas d’usage plus généraux, nous recommandons LangChain. Davantage clé en main, il offre des fonctionnalités plus développées pour la gestion de la mémoire ou les intégrations avec des vector stores.

Plateforme de ML end-to-end

Jusqu’au milieu des années 2010, les projets de Machine Learning étaient une succession d’opérations manuelles. Les outils de MLOps qui sont progressivement apparus depuis ont permis de structurer et de fluidifier une partie croissante de ces tâches, jusqu’à des plateformes complètes intervenant sur l’ensemble du cycle de vie des modèles.

On peut citer Databricks, disponible depuis 2015, comme l’un des précurseurs de ces plateformes, ou les services de ML des 3 principaux fournisseurs cloud : Google VertexAI, Amazon Sagemaker et Azure ML.

Celles-ci permettent une mise en œuvre rapide des principaux composants d’un projet :
une infrastructure pour les entraînements et prédictions, un model registry, l’orchestration de pipelines, le tracking d’expériences, etc.

Sans rentrer dans le détail de chaque plateforme, on peut identifier plusieurs problèmes-types communs à celles-ci :

Coût des resources : Il est toujours plus élevé qu’avec des solutions moins managées. Par exemple, un entraînement sur Vertex AI coûte ~15% plus cher que via Compute Engine.
Rigidité : Les services de ML tout intégrés sont limités en termes de personnalisation et d’intégration avec des outils n’appartenant pas à leur écosystème. Par exemple, on pourra difficilement utiliser DVC pour versionner ses données ou lancerdes entraînements bas- carbone sur Qarnot.
Vendor lock-in : Une dépendance à un fournisseur spécifique peut s’avérer d’autant plus frustrante dans le domaine de l’IA, où les technologies évoluent très rapidement.

L’alternative principale est de combiner des technologies spécifiques et moins managées, comme DVC, Streamlit, Airflow, ce qui représente un investissement non négligeable en coût de mise en place.

NOTRE POINT DE VUE

Chez Sicara, notre stack par défaut n’utilise pas de plateforme ML end- to-end. Nous privilégions la combinaison d’outils open-source adaptés au besoin, minimisant les coûts et évitant le vendor lock-in. Sicarator, notre générateur de projet ML open-source, permet d’accélérer leur mise en place.

Une solution end-to-end reste préférable si l’on ne dispose pas du temps ou des compétences nécessaires pour une stack sur-mesure, ou pour une entreprise qui n’a prévu de développer que quelques projets de ML sur le court terme.

Hold

Dataiku for industrialized tech teams

La création de pipelines de Data Science nécessite beaucoup de temps et plusieurs équipes pour traiter et rendre la donnée disponible. Dataiku, plateforme propriétaire, émerge comme un accélérateur dans l’univers Data et Machine Learning (ML), en s’appuyant sur une interface low-code pour simplifier ces étapes.

Dataiku propose une boîte à outils assez large, interfacée à de nombreuses sources de données. La plateforme permet d’automatiser des pipelines de transformation de données, des entrainements de modèles, ainsi que des déploiements de modèles en production. Il est également possible de visualiser les données à travers des tableaux de bords personnalisés.

Bien que le no-code facilite la création de projets ML à court terme, cela crée également de nouveaux défis en termes de maintenabilité sur les projets sophistiqués. Par exemple, la contribution de plusieurs équipes sur la même pipeline est difficile : impossibilité de modifier au même moment, versionnage des changements au stade embryonnaire (rendant difficiles les revues de code, un standard chez Sicara). De plus, élargir l’accès à la plateforme est tentant, car elle est intuitive, mais cela peut nécessiter des coûts de licence importants.

NOTRE POINT DE VUE

Dataiku est une excellente solution pour explorer puis déployer rapidement des use cases Data Science. Nous avons trouvé que la solution complexifie collaboration et maîtrise de la qualité pour des contextes d’industrialisation avec un fort besoin de collaboration et un bon bagage technique de l’équipe. Nous recommandons alors de se baser sur une stack modulaire avec un investissement plus élevé au départ, mais une meilleure évolutivité et flexibilité.Streamlit, etc.) ce qui nécessite certes un investissement plus important au début du projet, mais permet une meilleure évolutivité et flexibilité.