Aller au contenu principal
Construire un pipeline de machine learning en production avec ZenML : matérialiseurs, métadonnées et hyperparamètres
OutilsMarkTechPost · 2 min de lecture

Construire un pipeline de machine learning en production avec ZenML : matérialiseurs, métadonnées et hyperparamètres

Source originale ↗·

ZenML, framework open-source dédié à l'orchestration de pipelines de machine learning, propose une approche structurée pour construire des pipelines de bout en bout de niveau production. Un tutoriel détaillé publié récemment illustre comment assembler un système complet incluant des matérialiseurs personnalisés, un suivi de métadonnées et une optimisation d'hyperparamètres, en s'appuyant sur Python 3, scikit-learn, pandas et PyArrow. Le pipeline construit charge des données depuis le dataset Breast Cancer de scikit-learn, les prétraite via un StandardScaler, puis lance une recherche parallèle sur trois architectures de modèles, RandomForest, GradientBoosting et LogisticRegression, avant de sélectionner et promouvoir automatiquement le meilleur modèle selon ses métriques d'évaluation (accuracy, F1-score, AUC-ROC).

Ce type de pipeline répond à un besoin concret des équipes data : garantir la reproductibilité complète des expériences ML sans intervention manuelle. Le mécanisme de cache de ZenML évite de réexécuter des étapes coûteuses si les données ou le code n'ont pas changé, ce qui réduit significativement les temps de cycle en production. Le suivi automatique des artefacts, chaque dataset, modèle intermédiaire et métrique est versionné, permet à une équipe de remonter précisément à quelle version des données correspond quel modèle déployé. La stratégie fan-out/fan-in, où plusieurs modèles sont entraînés en parallèle puis comparés dans une étape de synthèse, est particulièrement utile pour les équipes qui veulent industrialiser la sélection de modèles sans scripts ad hoc.

ZenML s'inscrit dans un écosystème d'outils MLOps en pleine consolidation, aux côtés de MLflow, Kubeflow et Metaflow. Sa particularité est de proposer un "model control plane" centralisé qui abstrait le stockage des artefacts et l'exécution des étapes, quel que soit l'infrastructure sous-jacente, local, cloud, ou Kubernetes. La notion de matérialiseur personnalisé, illustrée ici avec un objet DatasetBundle sérialisant séparément les arrays NumPy et les métadonnées JSON, est au cœur de son extensibilité : elle permet d'intégrer n'importe quel type de données métier dans le système de tracking. Avec la montée en complexité des projets ML en entreprise, ce type d'approche normalisée devient un standard de fait pour les équipes qui cherchent à passer du notebook expérimental au déploiement répétable en production.

Cet article vous a été utile ?

Vu une erreur factuelle dans cet article ? Signalez-la. Toutes les corrections valides sont publiées sur /corrections.

À lire aussi

Construire un pipeline d'optimisation bayésienne conditionnelle des hyperparamètres avec Hyperopt, TPE et arrêt anticipé
1MarkTechPost 

Construire un pipeline d'optimisation bayésienne conditionnelle des hyperparamètres avec Hyperopt, TPE et arrêt anticipé

Un tutoriel publié récemment détaille l'implémentation complète d'un pipeline d'optimisation bayésienne des hyperparamètres en Python, en combinant la bibliothèque Hyperopt et l'algorithme TPE (Tree-structured Parzen Estimator). L'objectif est de construire un espace de recherche conditionnel qui bascule dynamiquement entre deux familles de modèles (régression logistique et machines à vecteurs de support SVM), en explorant des plages de paramètres distinctes pour chacune. Le code s'appuie sur scikit-learn pour la construction de pipelines et l'évaluation par validation croisée stratifiée en 5 plis, appliquée au jeu de données Breast Cancer. Pour la régression logistique, les paramètres explorés incluent le coefficient de régularisation C sur une plage logarithmique de 1e-4 à 1e2, le solveur (lbfgs ou liblinear) et le nombre d'itérations maximum entre 200 et 2000. Pour le SVM, l'algorithme explore les noyaux rbf et polynomial, ainsi que les paramètres C et gamma. Le tutoriel intègre également un arrêt précoce déclenché dès que les améliorations de la fonction de perte stagnent, ainsi qu'une analyse complète de l'objet Trials, qui consigne l'historique de chaque évaluation effectuée. Pour les praticiens du machine learning, l'optimisation manuelle des hyperparamètres reste coûteuse en temps et peu reproductible. L'approche bayésienne présentée dépasse les méthodes classiques comme la recherche par grille ou la recherche aléatoire : au lieu d'explorer l'espace de paramètres de façon exhaustive ou aveugle, TPE modélise la distribution des configurations performantes et oriente intelligemment les essais suivants. La structure conditionnelle de l'espace de recherche, rendue possible par hp.choice dans Hyperopt, évite de tester des paramètres non pertinents pour une architecture donnée, réduisant ainsi le nombre d'évaluations inutiles. L'intégration du mécanisme d'arrêt précoce basé sur la stagnation des résultats permet en outre d'économiser des ressources de calcul significatives, un avantage concret dès que les modèles deviennent coûteux à entraîner. Hyperopt est une bibliothèque Python open source dont les bases théoriques remontent aux travaux de James Bergstra et ses collaborateurs sur les estimateurs de Parzen et l'optimisation bayésienne. Dans un contexte où l'entraînement de grands modèles mobilise des budgets considérables, l'optimisation efficace des hyperparamètres est devenue un enjeu industriel de premier plan. Des outils concurrents comme Optuna, Ray Tune ou Weights & Biases Sweeps proposent des fonctionnalités similaires voire plus avancées, mais Hyperopt conserve une base d'utilisateurs fidèle pour sa simplicité et son intégration directe dans des pipelines scikit-learn. Le framework présenté est conçu pour être étendu à l'apprentissage profond et aux environnements distribués, ce qui en fait un point d'entrée solide pour des équipes souhaitant industrialiser leur processus de tuning sans repartir de zéro.

OutilsTuto
1 source
Guide complet pour construire un pipeline de détection et suppression des données personnelles avec OpenAI Privacy Filter
2MarkTechPost 

Guide complet pour construire un pipeline de détection et suppression des données personnelles avec OpenAI Privacy Filter

OpenAI a mis à disposition sur HuggingFace un modèle de classification de tokens baptisé openai/privacy-filter, conçu pour détecter et masquer automatiquement les données personnelles dans des textes. Un tutoriel détaillé publié cette semaine montre comment construire, étape par étape, un pipeline complet de détection et de rédaction des informations personnellement identifiables (PII) prêt pour la production. Le système, implémenté en Python avec les bibliothèques Transformers d'HuggingFace, PyTorch et pandas, identifie huit catégories de données sensibles : noms de personnes, adresses e-mail, numéros de téléphone, adresses physiques, URL privées, dates, numéros de compte et secrets. Chaque entité détectée est remplacée par un marqueur typé comme [PRIVATEPERSON] ou [PRIVATEEMAIL], ce qui préserve la lisibilité du texte tout en occultant les informations sensibles. Le pipeline fonctionne aussi bien sur GPU que sur CPU, avec un seuil de confiance configurable fixé par défaut à 0,50 pour filtrer les faux positifs. L'intérêt concret de ce type de pipeline est considérable pour les entreprises qui manipulent des données clients avant de les envoyer vers des LLM externes ou des systèmes de journalisation. En substituant les entités sensibles par des placeholders sémantiquement clairs plutôt qu'un simple [REDACTED] générique, le texte reste exploitable par des modèles en aval sans exposer de données privées. Cette approche répond directement aux exigences du RGPD et aux politiques d'utilisation des API d'IA, qui interdisent souvent l'envoi de données personnelles non anonymisées. Le pipeline inclut également un système de rapport structuré convertissant les résultats en dataframes pandas, ce qui facilite l'audit et le traitement par lots à grande échelle. La protection des données personnelles dans les flux d'ingestion vers les LLM est devenue un enjeu critique depuis que des entreprises comme Samsung ont interdit l'usage de ChatGPT en interne après des fuites accidentelles de code source confidentiel. La mise à disposition d'un modèle dédié par OpenAI sur HuggingFace marque une évolution : plutôt que de laisser chaque organisation bricoler sa propre solution d'anonymisation, un modèle de référence mutualisé, entraîné spécifiquement sur cette tâche, peut s'intégrer directement dans les pipelines existants. Le choix d'une architecture de classification de tokens, plus précise que les approches par expressions régulières, permet de gérer les ambiguïtés contextuelles, comme distinguer une date de naissance privée d'une date de publication publique. Les prochaines étapes naturelles pour ce type de système incluent le support multilingue, l'ajout de catégories sectorielles (numéros de sécurité sociale, données médicales), et l'intégration dans des frameworks d'orchestration comme LangChain ou LlamaIndex.

UELe pipeline répond directement aux obligations du RGPD pour les entreprises européennes qui transmettent des données personnelles à des LLM externes, réduisant le risque de non-conformité.

OutilsOutil
1 source
Construire un pipeline de prévision avec TimeCopilot : modèles de fondation et détection automatique d'anomalies
3MarkTechPost 

Construire un pipeline de prévision avec TimeCopilot : modèles de fondation et détection automatique d'anomalies

TimeCopilot, une librairie Python open source dédiée à la prévision de séries temporelles, propose un pipeline complet combinant modèles statistiques classiques, modèles de fondation et détection automatique d'anomalies. Un tutoriel récent détaille comment construire un tel workflow de bout en bout : après installation via pip, l'utilisateur charge le jeu de données AirPassengers (série mensuelle historique de passagers aériens) et y adjoint une série synthétique saisonnière dans laquelle trois anomalies ont été artificiellement injectées aux indices 30, 75 et 120 en multipliant les valeurs par 2,2. Le panel ainsi constitué est soumis à une batterie de modèles : les statistiques AutoARIMA, AutoETS, Theta et SeasonalNaive, le modèle Prophet de Meta, et les modèles de fondation Chronos d'Amazon (versions chronos-bolt-small ou chronos-bolt-tiny selon la disponibilité d'un GPU) et TimesFM 2.0 de Google (500 millions de paramètres, activé uniquement en présence d'un GPU). Un agent LLM intégré à TimeCopilot peut ensuite sélectionner automatiquement le meilleur modèle et restituer les prédictions dans un format analytique accessible à un non-spécialiste. L'intérêt de cette approche réside dans la mise en compétition automatisée de plusieurs familles de modèles via une validation croisée glissante assortie de plusieurs métriques d'erreur, ce qui permet d'identifier objectivement le modèle le plus performant sur chaque série. TimeCopilot unifie dans une seule interface des approches radicalement différentes, des méthodes statistiques légères tournant sur CPU aux grands modèles de fondation pré-entraînés sur des milliards de points de données, sans obliger l'utilisateur à jongler entre bibliothèques hétérogènes. La génération d'intervalles de prédiction probabilistes et la visualisation des tendances futures permettent de quantifier l'incertitude, une exigence critique en planification opérationnelle. La détection d'observations inhabituelles intégrée au même pipeline réduit le risque de biais causé par des événements exceptionnels non filtrés. Ce tutoriel s'inscrit dans une tendance plus large : depuis 2023, les modèles de fondation pour séries temporelles cherchent à reproduire pour la prévision ce que les grands modèles de langage ont accompli pour le texte, c'est-à-dire des modèles pré-entraînés capables de généraliser sans réentraînement spécifique. Chronos d'Amazon, TimesFM de Google et Moirai de Salesforce se livrent une concurrence directe sur ce créneau. TimeCopilot se positionne comme une couche d'orchestration neutre, permettant de comparer ces nouveaux modèles aux méthodes classiques dans des conditions équivalentes. L'ajout d'un agent LLM capable d'interpréter les prévisions en langage naturel signale une convergence entre prévision quantitative et IA générative qui commence à séduire les équipes data souhaitant rendre leurs analyses accessibles à des décideurs non techniques.

💬 La course aux modèles de fondation pour séries temporelles, c'est le même film que pour les LLMs il y a deux ans : Chronos chez Amazon, TimesFM chez Google, Moirai chez Salesforce. C'est le genre de convergence que j'attendais, et TimeCopilot arrive au bon moment en permettant enfin de comparer ces nouveaux modèles aux méthodes classiques dans les mêmes conditions, sans jongler entre cinq bibliothèques différentes. Reste à voir si ces mastodontes pré-entraînés sortent gagnants face à un bon AutoARIMA sur de vraies séries métier.

OutilsOutil
1 source
Conception d'un pipeline d'extraction de factures guidé par schéma avec lift-pdf, pour la validation et la génération de grand livre en comptabilité fournisseurs
4MarkTechPost 

Conception d'un pipeline d'extraction de factures guidé par schéma avec lift-pdf, pour la validation et la génération de grand livre en comptabilité fournisseurs

Une équipe de développeurs a publié un tutoriel démontrant comment construire un pipeline complet d'extraction de factures fournisseurs à l'aide de la bibliothèque lift-pdf, associée à un schéma JSON structuré définissant les champs à extraire. Le système traite des factures PDF synthétiques générées pour l'occasion, avec des champs comme l'identité du vendeur, le tiers facturé, le numéro de bon de commande, les lignes de produits, la taxe, le montant total et le statut de paiement. La configuration par défaut fixe le traitement à trois documents (N_DOCS=3), avec des options pour forcer une précision complète du modèle ou une quantification en 4 bits, prévisualiser la première page du PDF généré, ou tester le pipeline sur un vrai document. L'installation repose sur des bibliothèques comme reportlab et pypdfium2 pour la génération et le rendu des PDF, pandas et matplotlib pour l'analyse, ainsi que lift-pdf avec son extension Hugging Face, bitsandbytes et accelerate pour l'inférence. Un détail technique notable: Pillow est volontairement figé à la version 11.3.0 pour contourner un problème de compatibilité connu entre cette bibliothèque, torchvision et Transformers sur Google Colab. Le script vérifie aussi la présence d'un GPU CUDA compatible, recommandant une carte A100 tout en acceptant des modèles L4 ou T4. L'intérêt de cette approche dépasse la simple reconnaissance de texte: au lieu d'un OCR brut, le modèle doit comprendre la structure et la logique métier d'une facture. Le tutoriel intègre volontairement des pièges réalistes rencontrés par les équipes comptables, comme la distinction entre l'adresse de facturation et l'adresse de livraison, la séparation entre le sous-total et le montant final après taxes, le renvoi d'une valeur nulle quand une information est absente, ou encore la classification correcte d'une facture partiellement payée comme non soldée tant qu'un solde reste dû. Cette rigueur rend l'extraction directement exploitable pour générer automatiquement des registres comptables fiables, un enjeu concret pour les équipes de comptabilité fournisseurs qui traitent des volumes importants de documents hétérogènes. Ce projet s'inscrit dans une tendance plus large de l'intelligence documentaire guidée par schéma, où les modèles de langage ne se contentent plus de lire du texte mais produisent des données structurées directement utilisables par des systèmes en aval. L'utilisation de la quantification en 4 bits via bitsandbytes permet de réduire les besoins en mémoire GPU, rendant ce type de pipeline accessible sur du matériel plus modeste comme les GPU L4 ou T4, et pas uniquement sur des cartes haut de gamme. Le choix de documents synthétiques comme base de test contrôlée, avec la possibilité d'étendre l'expérience à de vraies factures PDF, illustre une méthodologie de validation progressive avant déploiement en conditions réelles.

💬 Ce qui compte ici, ce n'est pas l'extraction de texte, c'est que le modèle doit piger qu'une facture partiellement payée reste une facture ouverte. Selon Le Fil IA, l'IA documentaire passe d'un problème d'OCR à un problème de logique métier, et c'est ça qui va décider si les équipes compta y touchent un jour. Après, le pipeline tourne sur un GPU L4 dans un tutoriel avec trois factures bidon, donc reste à voir si ça encaisse le bazar d'une vraie pile de PDF scannés de travers.

OutilsTuto
1 source

Recevez l'essentiel de l'IA chaque jour

Une sélection éditoriale quotidienne, sans bruit. Directement dans votre boîte mail.

Recevez l'essentiel de l'IA chaque jour

Gratuit · 1 email le matin, l'essentiel de l'IA · désinscription en un clic