Diagramme d'architecture MLOps : des données d'entraînement à un modèle surveillé

Un modèle dans un notebook n'est pas un système. La célèbre figure de Hidden Technical Debt in Machine Learning Systems (Sculley et al., NeurIPS 2015) le montre avec des boîtes : seule une petite partie d'un système de ML réel est du code de ML. Le reste, c'est la collecte des données, l'extraction des caractéristiques, le service, la surveillance et la plomberie entre tout cela, et c'est de là que viennent les problèmes en production.

Un diagramme d'architecture MLOps dessine ce reste. Cet article en construit un pour un modèle de scoring de fraude, explique les deux boucles de tout modèle en production et liste ce qu'il faut étiqueter pour que le diagramme réponde aux questions qui surgissent quand un modèle se comporte mal.

Deux boucles et un déclencheur

Tout modèle en production a une boucle d'entraînement et une boucle de service :

• Boucle d'entraînement. Les données sont collectées, transformées en caractéristiques, utilisées pour entraîner un candidat, comparées au modèle actuel, puis enregistrées.
• Boucle de service. Une requête arrive, les caractéristiques sont lues, le modèle la note et la prédiction est journalisée.
• Le déclencheur relie les deux. La surveillance de la boucle de service, un planning ou de nouvelles données relancent la boucle d'entraînement.

Le guide MLOps de Google décrit trois niveaux de maturité : le niveau 0 est un processus manuel, le niveau 1 automatise le pipeline d'entraînement pour l'entraînement continu, et le niveau 2 ajoute le CI/CD pour le pipeline lui-même. Dessinez le niveau que vous avez, pas celui que vous prévoyez, et signalez les étapes manuelles.

Le décalage entre entraînement et service

Le bug qu'un diagramme MLOps évite le plus souvent est le décalage entre entraînement et service (training-serving skew) : une caractéristique calculée d'une façon dans le SQL d'entraînement et d'une autre dans le code de service. Le modèle paraît bon hors ligne et moins bon en production, et personne ne sait dire pourquoi. Le même guide de Google recommande un feature store comme source unique pour l'expérimentation, l'entraînement continu et le service en ligne, afin qu'une caractéristique n'ait qu'une seule définition.

Le second bug classique est la fuite dans le temps. Une ligne d'entraînement pour un paiement doit utiliser les valeurs des caractéristiques telles qu'elles étaient au moment de ce paiement, pas telles qu'elles sont aujourd'hui. Inscrivez cette exigence de point dans le temps (point-in-time) sur le lien entre le feature store et le pipeline d'entraînement.

L'exemple : scoring de fraude pour les paiements par carte

Une API de paiement demande un score de fraude à un modèle avant d'autoriser un paiement par carte. La conception :

1. Événements. L'API de paiement publie chaque paiement dans Kafka. Un job de streaming maintient des caractéristiques glissantes, comme le nombre de paiements par carte sur la dernière heure, dans un stockage en ligne. Les mêmes événements arrivent dans l'entrepôt de données.
2. Étiquettes. On apprend qu'un paiement était frauduleux grâce aux rétrofacturations, qui arrivent des semaines ou des mois plus tard. Elles sont chargées dans l'entrepôt et rattachées aux paiements d'origine.
3. Caractéristiques. Le feature store définit chaque caractéristique une fois, calcule les valeurs hors ligne à partir de l'entrepôt et matérialise les dernières valeurs dans le stockage en ligne.
4. Entraînement. Un pipeline orchestré construit un jeu d'entraînement à un instant donné, valide les données, entraîne un candidat, le compare au modèle en ligne sur le même jeu d'évaluation et l'enregistre avec ses métriques.
5. Mise en production. Une version approuvée est déployée sur le point de scoring, d'abord en mode fantôme, où elle note des copies du trafic réel sans influer sur les décisions, puis pour une petite part du trafic, puis pour la totalité.
6. Surveillance. Chaque score est journalisé avec ses caractéristiques. La surveillance compare les distributions des entrées et des scores aux données d'entraînement et, à mesure que les étiquettes arrivent, calcule la précision et le rappel. Une alerte de dérive ou de qualité lance le réentraînement.

Comment le lire :

• Rangée du haut, l'entraînement. Les étiquettes de rétrofacturation et l'historique des événements se rejoignent dans l'entrepôt. Le feature store construit les jeux d'entraînement pour le pipeline, qui enregistre les candidats dans le registre de modèles.
• Rangée du bas, le service. L'API de paiement publie les événements dans Kafka et appelle le point de scoring de façon synchrone. Le point de terminaison lit les caractéristiques dans le stockage en ligne et écrit chaque score dans le journal des prédictions.
• Le lien du registre est la seule voie par laquelle un modèle arrive en production : une version approuvée, jamais un fichier copié depuis un notebook.
• À droite, la boucle de retour. La surveillance lit les prédictions et les étiquettes tardives. Une dérive ou une baisse de qualité déclenche une alerte qui lance le pipeline d'entraînement.

Ce qu'il faut étiqueter

• Les règles de point dans le temps sur le lien du jeu d'entraînement.
• La version et le stade du modèle sur le point de terminaison et le registre.
• Les budgets de latence pour la lecture des caractéristiques et le scoring, car le paiement les attend.
• Le délai des étiquettes. Si les étiquettes prennent des semaines, dites-le : c'est ce qui fixe la vitesse à laquelle vous pouvez mesurer la qualité.
• Les déclencheurs de réentraînement : planning, seuil de dérive, volume de données.
• Les responsables. Données, caractéristiques, modèles et point de terminaison appartiennent souvent à des équipes différentes.

Erreurs courantes

• Une seule boîte appelée « modèle de ML ». Elle cache le feature store, le registre et la boucle de surveillance, c'est-à-dire l'endroit où les incidents commencent.
• Aucun chemin de retour. Si les étiquettes ne reviennent jamais, personne ne sait quand le modèle s'est dégradé.
• Des notebooks dans le chemin de production. Un modèle ne doit atteindre le service que par le pipeline et le registre.
• Deux implémentations d'une même caractéristique. Un SQL d'entraînement et un code de service qui calculent « la même » valeur différemment provoquent un décalage.
• Pas de retour arrière. Gardez la version précédente dans le registre et dessinez comment le point de terminaison y revient.
• Une surveillance limitée à l'infrastructure. La latence et le taux d'erreurs peuvent être parfaits alors que le modèle se trompe ; surveillez aussi les entrées, les scores et les résultats.

Le côté service relève du travail ordinaire sur les systèmes distribués. Le diagramme d'architecture orientée événements couvre la partie Kafka et, pour les modèles de langage avec recherche, le diagramme d'architecture RAG couvre l'indexation et le service.

Le construire dans Archboard

1. Connectez-vous avec Google ou GitHub et créez un diagramme.
2. Depuis le pack ML, ajoutez un Magasin de caractéristiques, un Modèle pour le registre et un Point de terminaison pour le scoring.
3. Depuis le pack Données, ajoutez Kafka, un Entrepôt de données, Redis pour le stockage en ligne et un Sujet pour le journal des prédictions.
4. Depuis le pack DevOps, ajoutez un Pipeline CI/CD pour l'entraînement, un nœud Métriques pour la surveillance du modèle et une Alerte pour le déclencheur de réentraînement.
5. Ajoutez un Conteneur du pack Modèle C4 pour l'API de paiement et un Système externe pour les rétrofacturations du réseau de cartes.
6. Reliez-les, étiquetez chaque lien avec les données qu'il transporte et dessinez en pointillé les étiquettes tardives et le déclencheur de réentraînement. Ajoutez un bloc Markdown du pack Base avec les étapes de mise en production.

L'exemple utilise 13 nœuds de diagramme et reste dans les limites de l'offre Free. Avec un agent IA connecté via MCP, vous pouvez décrire le pipeline, le laisser placer les nœuds, puis ajuster les étiquettes.

FAQ

Ai-je besoin d'un feature store ? Pas dès le premier jour. Il vous faut une seule définition par caractéristique, utilisée à la fois par l'entraînement et par le service. Un feature store est la façon habituelle d'y parvenir quand plusieurs modèles partagent des caractéristiques ou que vous avez besoin de caractéristiques fraîches en ligne.

Quelle différence entre un registre de modèles et un stockage d'artefacts ? Un stockage d'artefacts conserve des fichiers. Un registre y ajoute les versions, les métriques, la traçabilité et un statut d'approbation, pour que l'étape de déploiement puisse demander la version approuvée plutôt qu'un chemin.

À quelle fréquence réentraîner un modèle ? Aussi souvent que les données changent de façon significative. Commencez par un planning, ajoutez des déclencheurs de dérive et de qualité une fois la surveillance en place, et notez pourquoi chaque réentraînement a eu lieu.

Comment surveiller un modèle quand les étiquettes arrivent tard ? Observez ce que vous voyez dès maintenant, comme la distribution des entrées, celle des scores et la part de paiements signalés, et calculez la précision et le rappel quand les étiquettes arrivent. Dessinez les deux chemins.

L'entraînement et le service doivent-ils partager l'infrastructure ? Ils peuvent partager les définitions des caractéristiques et le registre, mais leurs profils de charge diffèrent. Dessinez-les comme deux chemins distincts qui se rejoignent dans le feature store et le registre.

Commencez gratuitement — un siège, sans carte bancaire.