DEV Community: David Scanu

🚗👁️ Segmentation d'Images pour le système embarqué d’une voiture autonome

David Scanu — Wed, 25 Jun 2025 07:30:17 +0000

🌐 Introduction

Ce projet s'inscrit dans le développement d'un système embarqué de vision par ordinateur pour véhicules autonomes chez Future Vision Transport. L'entreprise conçoit des systèmes permettant aux véhicules autonomes de percevoir leur environnement grâce à l'analyse d'images en temps réel.

En tant qu'ingénieur IA dans l'équipe R&D, notre mission est de développer le module de segmentation d'images (composant 3) qui s'intègre entre le module de traitement d'images (2) et le système de décision (4). Ce module doit être capable d'identifier et de segmenter précisément 8 catégories principales d'objets dans des images de caméras embarquées.

Cette note technique présente la conception et l'implémentation d'un modèle de segmentation d'images optimisé pour la compréhension des scènes urbaines. Le système développé s'intègre dans une chaîne complète comprenant l'acquisition d'images en temps réel, le traitement des images, la segmentation sémantique (notre contribution) et le système de décision final.

🎯 Objectifs

Développer un modèle de segmentation d'images performant avec Keras/TensorFlow
Concevoir et déployer une API REST avec FastAPI
Créer une application web de démonstration avec Next.js
Documenter le processus et les résultats de façon claire et professionnelle

💾 Dépôt GitHub

L'intégralité du code du projet (notebook, backend et frontend) est disponible sur le dépôt GitHub : Projet 8 : Traitement d'images pour le système embarqué d'une voiture autonome.

👋 À propos

Projet développé par David Scanu dans le cadre du parcours AI Engineer d'OpenClassrooms : Projet 8 - Traitez les images pour le système embarqué d'une voiture autonome.

👁️ 1. Développement du Modèle de Segmentation

Le notebook complet de conception du modèle de segmentation d'image est disponible sur Colab.

1.1 Contexte et Enjeux

La segmentation sémantique d'image dans le contexte automobile représente un défi technique majeur. Contrairement à la classification d'images qui attribue une étiquette à une image entière, la segmentation sémantique doit identifier et catégoriser chaque pixel de l'image. Pour un véhicule autonome, cette capacité est cruciale : il faut distinguer la route des trottoirs, identifier les véhicules, détecter les piétons, reconnaître la végétation, etc.

La segmentation sémantique consiste à étiqueter chaque pixel d’une image avec une classe correspondante à ce qui est représenté. On parle aussi de "prédiction dense", car chaque pixel doit être prédit. Elle génère une image, sur laquelle chaque pixel est classifié.

1.2 Étude du jeu de données et préparation pour l'entraînement

1.2.1 Le jeu de données Cityscapes

Nous avons choisi le jeu de données Cityscapes, une référence dans le domaine de la segmentation urbaine. Ce dataset présente plusieurs avantages décisifs pour notre cas d'usage :

5 000 images avec annotations fines réparties en 2 975 images d'entraînement, 500 de validation et 1 525 de test
Diversité géographique : 50 villes européennes différentes
Conditions variées : Plusieurs saisons, conditions météorologiques bonnes à moyennes
Richesse des annotations : 30 classes détaillées avec des annotations polygonales précises
Réalisme : Images capturées depuis des véhicules en circulation réelle

1.2.2 Stratégie de Regroupement des Classes

L'une des décisions techniques les plus importantes a été le regroupement des 30+ classes originales de Cityscapes en 8 catégories pertinentes pour la navigation autonome. Cette simplification répond à plusieurs objectifs :

Pertinence fonctionnelle : Regrouper les éléments ayant la même importance pour la décision de navigation
Performance computationnelle : Réduire la complexité du modèle
Robustesse : Éviter la sur-spécialisation sur des classes très spécifiques

Notre mapping final :

class_groups = {
    'flat': ['road', 'sidewalk', 'parking', 'rail track'],
    'human': ['person', 'rider'], 
    'vehicle': ['car', 'truck', 'bus', 'motorcycle', 'bicycle', ...],
    'construction': ['building', 'wall', 'fence', 'bridge', ...],
    'object': ['pole', 'traffic sign', 'traffic light', ...],
    'nature': ['vegetation', 'terrain'],
    'sky': ['sky'],
    'void': ['unlabeled', 'out of roi', ...]
}

Cette approche nous permet de maintenir une granularité suffisante pour la prise de décision tout en gardant un modèle tractable.

1.2.3 Pipeline de Préparation des Données

Notre pipeline de préparation des données intègre plusieurs étapes :

Redimensionnement intelligent : Les images Cityscapes originales (2048×1024) sont redimensionnées à 224×224, un compromis entre qualité visuelle et performance computationnelle. Cette taille est également optimale pour l'utilisation de MobileNetV2 pré-entraîné.

Stratégie de validation : Pour éviter le "data leakage", nous avons adopté une approche rigoureuse :

Division du dataset 'train' original en 80% entraînement / 20% validation
Utilisation du dataset 'val' original comme dataset de test final : cette approche garantit que notre évaluation finale est réalisée sur des données jamais vues
Les masques du dataset 'test' étaient indisponibles (complètement noirs) : nous n'avons pas utilisé ce dossier

Augmentation de données : Nous avons implémenté des techniques d'augmentation adaptées à la segmentation :

Flip horizontal aléatoire (50% de probabilité)
- Appliqué de manière synchronisée sur l'image et le masque
Variation de luminosité aléatoire
- Appliquée uniquement sur l'image (pas sur le masque)
- Amplitude : ±0.1
- Avec clipping pour maintenir les valeurs dans [0,1]

def augment_data(image, mask):
    # Flip horizontal synchronisé image/masque
    if tf.random.uniform(()) > 0.5:
        image = tf.image.flip_left_right(image)
        mask = tf.image.flip_left_right(mask)

    # Variation de luminosité (image seulement)
    image = tf.image.random_brightness(image, 0.1)
    return image, mask

1.3 Architecture du Modèle : MobileNetV2-UNet

Nous avons développé une architecture qui combine la puissance de MobileNetV2 (un réseau léger et efficace) avec la structure en forme de U de l'architecture U-Net pour réaliser une segmentation d'images.

Architecture U-Net avec backbone MobileNetV2 pour segmentation sémantique d'images

1.3.1 Structure générale en forme de U

Notre modèle hybride combine la puissance de MobileNetV2 pour l'extraction de caractéristiques avec la capacité de U-Net à reconstruire des segmentations précises.

Forme en U : L'architecture suit une forme en "U" avec une partie descendante (encodeur) et une partie ascendante (décodeur).
Objectif : Attribuer une classe à chaque pixel de l'image (segmentation).

Partie encodeur (descendante)

Backbone MobileNetV2 : Utilisation de MobileNetV2 comme encodeur léger et optimisé pour les appareils mobiles.
Gel des poids : Avec base_model.trainable = False, les poids pré-entraînés sur ImageNet sont conservés, ce qui accélère l'entraînement et limite le surapprentissage.
Extraction multi-échelle : Les caractéristiques sont extraites à différents niveaux de résolution pour les connexions de saut :
- skip1 : 112×112
- skip2 : 56×56
- skip3 : 28×28
- skip4 : 14×14
- bottleneck : 7×7 (le niveau le plus profond du U-Net)

L'encodeur extrait des caractéristiques à cinq niveaux de résolution différents. Cette extraction multi-échelle est cruciale : les premières couches capturent des détails fins (textures, contours) tandis que les couches profondes encodent des informations sémantiques de haut niveau.

Stratégie de Transfer Learning : Nous avons opté pour une approche de "frozen encoder" (enoder gelé) dans notre configuration "baseline".

Cette décision présente plusieurs avantages :

Entraînement plus rapide (moins de paramètres à optimiser)
Stabilité accrue (les caractéristiques ImageNet sont déjà robustes)
Réduction du risque de sur-apprentissage
Possibilité d'entraînement avec des ressources limitées

Partie décodeur (ascendante)

Reconstruction progressive : À chaque étape, la résolution est doublée à l'aide de convolutions transposées :
- 7×7 → 14×14
- 14×14 → 28×28
- 28×28 → 56×56
- 56×56 → 112×112
- 112×112 → 224×224
Connexions de saut (Skip connections) : Chaque niveau du décodeur est enrichi par les caractéristiques du niveau correspondant de l’encodeur pour préserver les détails spatiaux.
Traitement post-upsampling : Chaque étape comprend :
- Convolution transposée
- BatchNormalization
- Activation ReLU
- Concaténation avec les features de l’encodeur
- Convolution 3×3 pour affiner

1.3.2 Construction et Entraînement du Modèle

Modèle U-Net personnalisé basé sur MobileNetV2, avec :
- Paramètres ajustables : nombre de classes, taille d'entrée, taux d'apprentissage, backbone gelé ou non.
- Sortie : carte de segmentation pixel-par-pixel via une convolution 1×1 suivie d'une activation softmax.
- Compilation : Optimiseur Adam, perte SparseCategoricalCrossentropy, et métrique SparseCategoricalAccuracy.

Le choix de SparseCategoricalCrossentropy est adapté car nos masques contiennent directement les indices des classes (format sparse) plutôt que des vecteurs one-hot.

def create_segmentation_model(num_classes=8, input_size=(224, 224, 3),
                            learning_rate=0.0001, base_trainable=False):
    """
    Create a segmentation model with configurable parameters
    """
    # Input tensor
    inputs = keras.layers.Input(shape=input_size)

    # Create MobileNetV2 base model
    base_model = keras.applications.MobileNetV2(
        input_shape=input_size,
        include_top=False,
        weights='imagenet'
    )

    # Configuration de l'entraînement du modèle de base
    base_model.trainable = base_trainable

    # Create encoder using MobileNetV2
    # Get outputs at different levels for skip connections
    skip1 = base_model.get_layer('block_1_expand_relu').output      # 112x112
    skip2 = base_model.get_layer('block_3_expand_relu').output      # 56x56
    skip3 = base_model.get_layer('block_6_expand_relu').output      # 28x28
    skip4 = base_model.get_layer('block_13_expand_relu').output     # 14x14

    # Get bottleneck
    bottleneck = base_model.get_layer('block_16_project').output    # 7x7

    # Use Model API to create encoder model
    encoder = keras.Model(inputs=base_model.input, outputs=[skip1, skip2, skip3, skip4, bottleneck])

    # Encoder part - use the encoder model
    x = inputs
    skips = encoder(x)

    # Bottleneck
    x = skips[4]  # Use the bottleneck from encoder

    # Decoder part - upsampling and skip connections
    # First upsampling: 7x7 -> 14x14
    x = keras.layers.Conv2DTranspose(256, 3, strides=2, padding='same')(x)
    x = keras.layers.BatchNormalization()(x)
    x = keras.layers.Activation('relu')(x)
    x = keras.layers.Concatenate()([x, skips[3]])
    x = keras.layers.Conv2D(256, 3, padding='same', activation='relu')(x)

    # Second upsampling: 14x14 -> 28x28
    x = keras.layers.Conv2DTranspose(128, 3, strides=2, padding='same')(x)
    x = keras.layers.BatchNormalization()(x)
    x = keras.layers.Activation('relu')(x)
    x = keras.layers.Concatenate()([x, skips[2]])
    x = keras.layers.Conv2D(128, 3, padding='same', activation='relu')(x)

    # Third upsampling: 28x28 -> 56x56
    x = keras.layers.Conv2DTranspose(64, 3, strides=2, padding='same')(x)
    x = keras.layers.BatchNormalization()(x)
    x = keras.layers.Activation('relu')(x)
    x = keras.layers.Concatenate()([x, skips[1]])
    x = keras.layers.Conv2D(64, 3, padding='same', activation='relu')(x)

    # Fourth upsampling: 56x56 -> 112x112
    x = keras.layers.Conv2DTranspose(32, 3, strides=2, padding='same')(x)
    x = keras.layers.BatchNormalization()(x)
    x = keras.layers.Activation('relu')(x)
    x = keras.layers.Concatenate()([x, skips[0]])
    x = keras.layers.Conv2D(32, 3, padding='same', activation='relu')(x)

    # Final upsampling: 112x112 -> 224x224
    x = keras.layers.Conv2DTranspose(16, 3, strides=2, padding='same')(x)
    x = keras.layers.BatchNormalization()(x)
    x = keras.layers.Activation('relu')(x)
    x = keras.layers.Conv2D(16, 3, padding='same', activation='relu')(x)

    # Output layer
    outputs = keras.layers.Conv2D(num_classes, 1, padding='same', activation='softmax')(x)

    # Create model
    model = keras.Model(inputs=inputs, outputs=outputs, name="MobileNetV2-UNet")

    # Compile model avec learning rate configurable
    model.compile(
        optimizer=keras.optimizers.Adam(learning_rate=learning_rate),
        loss=keras.losses.SparseCategoricalCrossentropy(),
        metrics=[
            keras.metrics.SparseCategoricalAccuracy(),
            # keras.metrics.MeanIoU(num_classes=num_classes)
        ]
    )

    return model

Détails des paramètres

Total des paramètres : 5,418,600
- Entraînables : 3,575,624 (décodeur et tête de segmentation)
- Non-entraînables : 1,842,976 (backbone gelé)
Si base_trainable=True, tous les paramètres deviennent entraînables, offrant plus de flexibilité au prix d'un entraînement plus long.

1.3.3 Justification du choix architectural

Le choix de l'architecture MobileNetV2-UNet résulte d'une analyse approfondie des contraintes de notre projet embarqué, combinant les avantages complémentaires de deux architectures éprouvées :

Pourquoi U-Net ?

Architecture de référence pour la segmentation sémantique avec structure encoder-decoder
Connexions résiduelles (skip connections) préservant les détails spatiaux fins lors de la reconstruction
Adaptée à la reconstruction de résolution complète depuis des caractéristiques compressées

Pourquoi MobileNetV2 ?

Conception spécifique pour les applications mobiles et embarquées avec ressources limitées
Optimisations avancées via les "depthwise separable convolutions" pour un rapport performance/efficacité optimal
Transfer learning efficace grâce aux poids pré-entraînés sur ImageNet
Vitesse d'exécution compatible avec les contraintes temps réel du véhicule autonome

Cette architecture hybride MobileNetV2-UNet présente des bénéfices uniques pour notre cas d'usage :

Efficacité computationnelle : Optimisée pour les environnements à ressources contraintes
Robustesse par transfer learning : Exploitation des représentations ImageNet pour une convergence rapide
Adaptabilité multi-tâches : Architecture générique applicable à diverses tâches de segmentation urbaine
Préservation de l'information : Maintien des détails spatiaux critiques pour la précision de segmentation

Cette combinaison offre le meilleur compromis entre précision de segmentation et efficacité embarquée, essentiel pour un système de vision automobile en temps réel.

1.4 Entraînement et optimisation

1.4.1 Stratégie d'entraînement

Notre approche d'entraînement intègre plusieurs techniques d'optimisation :

Callbacks Avancés

callbacks = [
    keras.callbacks.ReduceLROnPlateau(
        monitor='val_loss', factor=0.2, patience=2, min_lr=1e-6
    ),
    keras.callbacks.EarlyStopping(
        monitor='val_sparse_categorical_accuracy', 
        patience=5, restore_best_weights=True
    ),
    keras.callbacks.ModelCheckpoint(
        filepath='best_model.keras',
        save_best_only=True, mode='max'
    )
]

ReduceLROnPlateau : Réduction adaptative du taux d'apprentissage
EarlyStopping : Arrêt anticipé pour éviter le sur-apprentissage
ModelCheckpoint : Sauvegarde du meilleur modèle

Gestion des expériences de Machine Learning avec MLflow

Nous avons intégré MLflow pour le suivi des expériences, permettant :

Versioning des modèles et configurations
Traçabilité complète des hyperparamètres
Comparaison objective des performances
Reproductibilité des résultats

1.4.2 Configuration Baseline

Notre configuration "baseline" établit un point de référence solide :

EXPERIMENT_CONFIG = {
    "exp_name": "exp_001_baseline",
    "description": "Baseline MobileNetV2-UNet avec frozen encoder",
    "params": {
        "learning_rate": 0.0001,
        "batch_size": 8, 
        "epochs": 20,
        "base_model_trainable": False,
        "validation_split": 0.2,
        "augmentation": True
    }
}

Cette configuration privilégie la stabilité et la reproductibilité, servant de fondation pour les expérimentations futures.

1.4.3 Analyse de l'entraînement du modèle

L'entraînement de notre modèle MobileNetV2-UNet s'est déroulé sur 18 époques avec une convergence satisfaisante. Les graphiques d'évolution révèlent un comportement d'apprentissage sain et typique d'un modèle bien configuré.

Évolution de la Perte : La courbe de loss montre une décroissance rapide et régulière depuis des valeurs initiales élevées (≈1.4) vers une stabilisation autour de 0.25 pour l'entraînement et 0.4 pour la validation. Cette convergence rapide durant les 5 premières époques témoigne de l'efficacité du transfer learning avec MobileNetV2 pré-entraîné sur ImageNet. L'écart modéré entre les courbes train et validation (≈0.15) indique un niveau de sur-apprentissage acceptable, sans divergence critique.

Progression de l'Accuracy : L'évolution de la précision confirme l'apprentissage efficace avec une montée rapide de 55% à plus de 85% en quelques époques, puis une stabilisation progressive vers 91% pour l'entraînement et 87% pour la validation. Cette convergence démontre que le modèle a atteint sa capacité d'apprentissage optimale avec la configuration actuelle (encoder gelé). L'écart final de 4% entre train et validation reste dans une fourchette acceptable pour un modèle de production, suggérant une bonne généralisation sur des données non vues.

Cette dynamique d'entraînement valide notre approche conservative avec encoder gelé, offrant un modèle stable et performant en un temps d'entraînement réduit, parfaitement adapté aux contraintes de développement rapide d'un système embarqué.

1.5 Évaluation et Métriques

1.5.1 Métriques de Performance

L'évaluation de modèles de segmentation nécessite des métriques spécialisées. Nous utilisons principalement :

Intersection over Union (IoU)

Mesure le chevauchement entre la prédiction et la vérité terrain.

IoU = Intersection / Union

Cette métrique est particulièrement pertinente car elle pénalise à la fois les faux positifs et les faux négatifs.

Mean IoU (mIoU)

Moyenne des IoU de toutes les classes, offrant une vue d'ensemble des performances.

Précision Pixel-wise

Pourcentage de pixels correctement classifiés, métrique intuitive mais pouvant être biaisée par les classes majoritaires.

1.5.2 Résultats de la Configuration Baseline

Notre modèle baseline atteint des performances encourageantes :

Mean IoU : 63.25%
Précision globale : 87.95%
Perte finale : 0.4123

Analyse par Classe :

Classe	IoU	Commentaire
flat	0.9084	🟢 Excellent (routes bien détectées)
human	0.3196	🔴 Difficile (objets petits/variables)
vehicle	0.7469	🔵 Bon (formes caractéristiques)
construction	0.7454	🔵 Bon (structures larges)
object	0.0648	🔴 Très difficile (objets fins)
nature	0.7983	🔵 Bon (textures distinctives)
sky	0.8339	🟢 Excellent (région homogène)
void	0.6425	🟠 Acceptable

Matrice de confusion

La matrice de confusion constitue un outil d'évaluation pour les modèles de classification, particulièrement crucial en segmentation sémantique où chaque pixel doit être correctement assigné à sa classe.

Dans le contexte de la classification et de la segmentation sémantique, chaque prédiction peut être catégorisée selon quatre types fondamentaux qui déterminent la qualité du modèle :

Vrai positif (VP) : Le modèle détecte correctement la présence d'une classe là où elle existe réellement
Vrai négatif (VN) : Le modèle rejette correctement une classe là où elle n'existe pas
Faux positif (FP) : Le modèle génère une fausse alerte en détectant une classe absente (surestimation)
Faux négatif (FN) : Le modèle manque une classe présente, échouant à la détecter (sous-estimation)

Pour un système de vision automobile, cette analyse est importante car elle révèle quelles confusions pourraient compromettre la sécurité (ex: confondre un piéton avec un objet statique).

1.5.3 Analyse des Performances

Points Forts :

Excellente détection des surfaces planes (routes, ciel)
Bonne segmentation des grandes structures (bâtiments, végétation)

Points d'Amélioration :

Détection des objets fins (poteaux, panneaux) perfectible
Segmentation des humains variable (due à leur taille et variabilité)
Besoin d'optimisation pour les petits objets

1.6 Pipeline de Prédiction

Pour valider les performances de notre modèle en conditions réelles, nous avons développé un pipeline de prédiction complet permettant de traiter aussi bien des images du jeu de données de test que des images externes. Ce pipeline intègre toutes les étapes nécessaires depuis le chargement du modèle jusqu'à l'analyse statistique des résultats.

def predict_single_image(model, config, image_path=None, image_array=None, img_size=(224, 224)):
    """Réalise une prédiction complète avec préprocessing et post-analyse"""

    # Chargement et préprocessing adaptatif
    if image_path is not None:
        image_pil = Image.open(image_path).convert('RGB')
        image_array = np.array(image_pil)

    # Pipeline de normalisation identique à l'entraînement
    image_resized = tf.image.resize(image_array, img_size, method='bilinear')
    image_normalized = tf.cast(image_resized, tf.float32) / 255.0
    image_batch = tf.expand_dims(image_normalized, axis=0)

    # Prédiction et conversion en masque de classes
    predictions = model.predict(image_batch, verbose=0)
    pred_mask = tf.argmax(predictions, axis=-1)[0].numpy()

    # Analyse statistique automatique par classe
    unique_classes, counts = np.unique(pred_mask, return_counts=True)
    total_pixels = pred_mask.size

    class_stats = []
    for class_id, count in zip(unique_classes, counts):
        class_name = config['group_names'][class_id]
        percentage = (count / total_pixels) * 100
        class_stats.append({
            'class_id': int(class_id),
            'class_name': class_name,
            'pixel_count': int(count),
            'percentage': percentage
        })

    return {
        'prediction_mask': pred_mask,
        'class_statistics': class_stats,
        'predictions_raw': predictions[0]
    }

1.6.1. Résultats de prédiction

Les résultats de prédiction se présentent sous la forme suivante :

Masque de Segmentation (pixels) : Le résultat principal est un masque 224×224 où chaque pixel contient l'ID de la classe prédite (0-7). Cette représentation permet une analyse spatiale précise de la scène.

Distribution Statistique des Classes : Pour chaque prédiction, nous générons automatiquement un tableau statistique détaillant la répartition des classes :

📊 Classes détectées:
           flat:    19536 pixels ( 38.9%)  # Routes et surfaces de circulation
   construction:    14510 pixels ( 28.9%)  # Bâtiments et infrastructures  
         nature:     8285 pixels ( 16.5%)  # Végétation et terrain naturel
           void:     5459 pixels ( 10.9%)  # Zones non classifiées
        vehicle:     1630 pixels (  3.2%)  # Véhicules en circulation
          human:      594 pixels (  1.2%)  # Piétons et cyclistes
            sky:       98 pixels (  0.2%)  # Ciel visible
         object:       64 pixels (  0.1%)  # Signalisation et mobilier urbain

Visualisation Tripartite : Notre système génère systématiquement trois vues : l'image originale, la vérité terrain (quand disponible), et la prédiction colorisée selon notre palette de couleurs spécifique au domaine automobile.

4.3 Analyse qualitative des performances

L'évaluation sur des images réelles révèle des performances encourageantes avec des points forts et des axes d'amélioration clairement identifiés :

Excellente Détection des Structures Dominantes : Notre modèle démontre une capacité remarquable à identifier les éléments structurants de la scène urbaine. La segmentation des surfaces planes (routes, trottoirs) atteint 38.9% de couverture dans l'exemple analysé, avec des contours nets et une classification cohérente. Les bâtiments et constructions (28.9%) sont également très bien délimités, ce qui est crucial pour la navigation autonome.

Robustesse sur la végétation et l'environnement : La détection de la végétation (16.5%) montre une bonne capacité de généralisation du modèle. Les arbres, buissons et espaces verts sont correctement identifiés malgré leur variabilité de texture et de forme, témoignant de l'efficacité du transfer learning depuis ImageNet.

Défis sur les objets de petite taille : L'analyse révèle des difficultés attendues sur les éléments fins et de petite taille. Les objets de signalisation ne représentent que 0.1% des pixels détectés, ce qui correspond à la fois à leur faible représentation spatiale réelle et aux limitations du modèle sur ces éléments critiques.

Gestion Intelligente des Zones Ambiguës : La catégorie "void" (10.9%) capture efficacement les zones d'incertitude et les éléments non classifiables, évitant les fausses classifications qui pourraient être dangereuses. Cette approche conservative est préférable dans un contexte automobile.

Cette analyse confirme que notre architecture MobileNetV2-UNet offre un équilibre optimal pour les contraintes d'un système de vision embarqué, avec des performances robustes sur les éléments critiques pour la prise de décision de navigation tout en maintenant une efficacité computationnelle compatible avec les ressources limitées d'un véhicule autonome.

1.7 Innovations et optimisations futures

1.7.1 Pistes d'amélioration identifiées

Entraînement Progressif
Stratégie en deux phases :

Phase 1 : Encoder gelé (configuration actuelle)
Phase 2 : Fine-tuning avec encoder dégelé et taux d'apprentissage réduit

Augmentation de données avancée

Simulation de conditions météorologiques (pluie, brouillard)
Variations d'éclairage plus poussées
Transformations géométriques adaptées au contexte automobile

Architecture Hybride
Exploration de techniques comme :

Attention mechanisms pour améliorer la détection des petits objets
Multi-scale training pour robustesse aux variations d'échelle
Ensembling de modèles pour améliorer la robustesse

1.8 Conclusion de la partie modélisation

Le développement de notre modèle de segmentation MobileNetV2-UNet représente un équilibre réussi entre performance et efficacité computationnelle. Avec un Mean IoU de 63.25 % et une précision globale de 87.95 %, notre modèle "baseline" fournit une base solide pour le système de vision du véhicule autonome.

L'architecture choisie démontre sa pertinence pour les contraintes embarquées, et les résultats détaillés par classe révèlent des performances cohérentes avec les attentes pour un modèle de première génération. Les pistes d'amélioration identifiées offrent un roadmap clair pour les développements futurs.

La mise en place d'un pipeline MLOps avec MLflow et notre organisation modulaire garantissent la reproductibilité et facilitent l'itération continue sur les performances du modèle.

🔮 2. Développement du Backend FastAPI - API de Segmentation Sémantique

Le backend de l'application est une API REST développée avec FastAPI. Cette API expose notre modèle de deep learning (MobileNetV2-UNet) entraîné pour la segmentation sémantique d'images urbaines du dataset Cityscapes.

Architecture technique

app/backend/
├── main.py              # Point d'entrée FastAPI
├── config.py            # Configuration et variables d'environnement
├── models/
│   └── predictor.py     # Logique de prédiction et chargement du modèle
├── routers/
│   └── segmentation.py  # Endpoints de l'API
├── schemas/
│   └── prediction.py    # Modèles Pydantic pour validation
├── utils/
│   └── image_processing.py  # Utilitaires de traitement d'image
└── requirements.txt     # Dépendances Python

Fonctionnalités principales

1. Chargement du modèle depuis MLflow

Le modèle est hébergé sur MLflow et chargé dynamiquement au démarrage de l'API :

Modèle : MobileNetV2-UNet (format Keras 3.x)
Poids : ~25MB
Classes : 8 catégories (flat, human, vehicle, construction, object, nature, sky, void)

2. Prédiction avec génération d'artefacts

L'API génère pour chaque prédiction :

Masque de segmentation : Classification pixel par pixel
Visualisations : Images côte à côte et superposition
Statistiques : Distribution des classes détectée
Sauvegarde : Artefacts de prédiction sauvegardés dans le dossier /predictions

Endpoints de l'API

`POST /api/v1/segmentation/predict`

Notre endpoint principal pour la segmentation d'images.

Entrée : Image (PNG, JPEG) via multipart/form-data
Sortie : JSON contenant :

{
  "class_statistics": [...],
  "image_size": [largeur, hauteur],
  "dominant_class": "flat",
  "dominant_class_percentage": 42.5,
  "images": {
    "original": "data:image/png;base64,...",
    "prediction_mask": "data:image/png;base64,...",
    "overlay": "data:image/png;base64,...",
    "side_by_side": "data:image/png;base64,..."
  }
}

`GET /api/v1/segmentation/health`

Ce endpoint vérifie l'état de santé de l'API.

{
  "status": "healthy",
  "model_loaded": true
}

`GET /api/v1/segmentation/model/info`

Ce endpooint renvoie des informations détaillées sur le modèle chargé.

{
  "model_name": "MobileNetV2-UNet",
  "input_shape": [null, 224, 224, 3],
  "num_classes": 8,
  "class_names": ["flat", "human", "vehicle", ...],
  "tensorflow_version": "2.18.0"
}

`GET /docs`

Documentation interactive Swagger UI générée automatiquement par FastAPI. Ce endpoint est très utile pour effectuer des requêtes de tests vers notre API, en attendant de développer le frontend.

Technologies utilisées

FastAPI : Framework web asynchrone haute performance
TensorFlow 2.18 (CPU) : Inférence du modèle
Gunicorn + Uvicorn : Serveur ASGI pour la production
Pillow : Manipulation d'images
MLflow : Gestion et versioning du modèle

Optimisations pour la production

TensorFlow CPU : Version allégée sans GPU (250MB vs 500MB)
Workers limités : 1 worker pour économiser la RAM
Timeout ajusté : 120s pour les prédictions complexes
Stockage temporaire : Utilisation de /tmp sur Railway

Déploiement sur Railway

Notre backend FastAPI est déployée sur Railway qui offre des ressources suffisante pour déployer un modèle de segmentation d'image, gratuitement.

Configuration Railway

Le déploiement sur Railway utilise un fichier railway.json :

{
  "$schema": "https://railway.app/railway.schema.json",
  "build": {
    "builder": "NIXPACKS",
    "buildCommand": "pip install -r requirements.txt"
  },
  "deploy": {
    "startCommand": "uvicorn main:app --host 0.0.0.0 --port $PORT",
    "restartPolicyType": "ON_FAILURE",
    "restartPolicyMaxRetries": 10
  }
}

Variables d'environnement

Les "credentials" sont configurés via le dashboard Railway :

MLFLOW_TRACKING_URI : URL du serveur MLflow
AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY : Accès S3 pour MLflow
RUN_ID : Identifiant de l'expérience MLflow
PORT : Port d'écoute (géré automatiquement)
FRONTEND_URL : URL de l'interface frontend (pour éviter les erreurs CORS)

Processus de déploiement

Initialisation : railway init pour créer le projet
Configuration : Ajout des variables via le dashboard
Déploiement : railway up pour déployer le code
Domaine : railway domain pour générer l'URL publique

URL de production

L'API est accessible à : https://future-vision-api-*******.up.railway.app (URL masquée car non protégée par un mécanisme d'authentification)

Cette architecture permet un déploiement rapide et scalable d'un modèle de deep learning, avec une API REST moderne et bien documentée, idéale pour être consommée par une application frontend.

⚡ 3. Développement de l'interface frontend Next.js

3.1 Architecture et choix techniques

L'interface utilisateur a été développée avec Next.js 15.3 en JavaScript, privilégiant la simplicité et la performance. Le framework React permet de développer une interface adaptée aux besoins de visualisation des résultats de segmentation.

Stack technique

Next.js 15.3 : Framework React pour le développement frontend
Bootstrap 5.3 : Framework CSS pour un design responsive et professionnel
Fetch API : Communication avec l'API FastAPI de prédiction
Base64 : Gestion des images encodées retournées par l'API

3.2 Fonctionnalités principales

L'application propose une interface intuitive pour tester le modèle de segmentation sémantique :

Upload d'images : Sélection et prévisualisation des images (formats JPEG, PNG, GIF)
Validation : Contrôle de la taille maximale (4096x4096px) et du format
Prédiction en temps réel : Appel à l'API avec feedback visuel de progression
Visualisation multi-format :
- Image avec overlay de segmentation semi-transparent
- Comparaison côte à côte (originale vs prédiction)
- Masque de segmentation isolé
Statistiques détaillées : Distribution des classes, classe dominante, métadonnées

3.3 Interface utilisateur

L'interface suit les principes de design UX/UI pour une utilisation professionnelle :

État initial

Formulaire d'upload central avec instructions claires
Validation en temps réel du fichier sélectionné
Boutons d'action désactivés tant qu'aucune image n'est sélectionnée

Résultats de prédiction

Affichage principal de l'image avec overlay de segmentation
Panneau latéral avec statistiques et distribution des classes
Section de comparaison détaillée avec visualisations multiples
Design responsive adapté aux différentes tailles d'écran

3.4 Déploiement et Accessibilité

L'application est déployée sur Vercel :

URL de production : https://oc-ai-engineer-p08-*******.vercel.app/ (URL masquée car non protégée par un mécanisme d'authentification)
Déploiement automatique : Intégration continue depuis le repository Git
Configuration : Variables d'environnement pour l'URL de l'API backend
- NEXT_PUBLIC_API_URL : URL de l'API REST de prédiction

3.5 Intégration API

L'interface communique avec l'API FastAPI de ségmentation sémantique d'images via des requêtes HTTP :

Endpoint : POST /predict pour l'analyse d'images
Format : Multipart/form-data pour l'upload de fichiers
Réponse : JSON contenant les images encodées et statistiques

Cette architecture facilite la maintenance et permet une évolution future vers des fonctionnalités avancées comme la gestion de lots d'images ou l'historique des prédictions.

📋 Conclusion

Ce projet de développement d'un système de segmentation d'images pour véhicule autonome a permis de concevoir une solution complète, de la modélisation au déploiement en production.

Réalisations techniques

Modélisation IA : Nous avons développé un modèle MobileNetV2-UNet atteignant 63.25% de Mean IoU sur 8 catégories d'objets urbains. L'architecture hybride combine l'efficacité de MobileNetV2 pour les contraintes embarquées avec la précision de U-Net pour la reconstruction spatiale.

Pipeline MLOps : L'intégration de MLflow a permis un suivi rigoureux des expériences et le versioning des modèles, garantissant la reproductibilité et la traçabilité des développements.

Architecture API : Le backend FastAPI expose le modèle via une API REST moderne avec génération automatique de visualisations et statistiques détaillées, optimisée pour un déploiement efficient.

Interface Utilisateur : L'application Next.js offre une interface intuitive pour tester le modèle avec visualisations multi-formats (overlay, comparaison, masques) et facilement déployée sur Vercel.

Axes d'Amélioration

Les principales pistes d'optimisation incluent un entraînement progressif (encoder dégelé en phase 2), une augmentation de données avancée simulant conditions météorologiques et variations d'éclairage, l'intégration d'attention mechanisms pour améliorer la détection des petits objets (panneaux, poteaux). Également, l'ajout d'un système d'authentification API, d'un cache de prédictions et de métriques de monitoring en production compléterait l'industrialisation du système.

A propos de ce projet

Ce projet démontre la faisabilité technique d'un module de segmentation pour Future Vision Transport, avec une base solide pour l'évolution vers un système de production robuste.

💬❤️ Analyse de Sentiments de Tweets grâce au Deep Learning : Une Approche MLOps

David Scanu — Fri, 11 Apr 2025 19:45:25 +0000

Cet article a été rédigé dans le cadre du projet : Réalisez une analyse de sentiments grâce au Deep Learning du parcours AI Engineer d'OpenClassrooms. Les données utilisées sont issues du jeu de données open source Sentiment140. Le code source complet est disponible sur GitHub.

🎓 OpenClassrooms • Parcours AI Engineer | 👋 Étudiant : David Scanu

🌐 Contexte et problématique métier

Dans le cadre de ma formation d'AI Engineer chez OpenClassrooms, ce projet s'inscrit dans un scénario professionnel où j'interviens en tant qu'ingénieur IA chez MIC (Marketing Intelligence Consulting), entreprise de conseil spécialisée en marketing digital.

Notre client, ✈️ Air Paradis (compagnie aérienne), souhaite anticiper les bad buzz sur les réseaux sociaux. La mission consiste à développer un produit IA permettant de prédire le sentiment associé à un tweet, afin d'améliorer la gestion de sa réputation en ligne.

⚡ Mission

Développer un modèle d'IA permettant de prédire le sentiment associé à un tweet.

Créer un prototype fonctionnel d'un modèle d'analyse de sentiments pour tweets selon trois approches différentes :

Modèle sur mesure simple : Approche classique (régression logistique) pour une prédiction rapide
Modèle sur mesure avancé : Utilisation de réseaux de neurones profonds avec différents word embeddings
Modèle avancé BERT : Exploration de l'apport en performance d'un modèle BERT

Cette mission implique également la mise en œuvre d'une démarche MLOps complète :

Utilisation de MLFlow pour le tracking des expérimentations et le stockage des modèles.
Création d'un pipeline de déploiement continu (Git + Github + plateforme Cloud).
Intégration de tests unitaires automatisés.
Mise en place d'un suivi de performance en production via Azure Application Insight.

🔧 Technologies utilisées

Langages : Python
Bibliothèques ML/DL : Scikit-learn, TensorFlow/Keras, Transformers (BERT)
MLOps : MLFlow, Git, GitHub Actions
Backend : FastAPI, Heroku
Frontend : Next.js / React
Monitoring : Azure Application Insight
Traitement texte : NLTK, Word Embeddings

🏛️ Structure du projet

📦 oc-ai-engineer-p07-analyse-sentiments-deep-learning/
┣━━ 📂 app/
┃   ┣━━ 📂 fastapi/                         # Backend API de prédiction
┃   ┗━━ 📂 frontend/                        # Application Next.js
┃
┣━━ 📂 documentation/                       # Documentation du projet
┃   ┗━━ 📃 guide-app-insights.md            # Guide de suivi des feedback utilisateur et des alertes avec Azure Application insights
┃
┗━━ 📂 notebooks/                           # Notebooks Jupyter pour l'analyse et modèles
    ┣━━ 📝 01_Analyse_exploratoire.ipynb     # Exploration et visualisation des données
    ┣━━ 📝 02_Modele_simple.ipynb            # Bag of Words et classificateurs classiques
    ┣━━ 📝 03_Modele_avance_Word2Vec.ipynb   # LSTM avec Word2Vec
    ┗━━ 📝 04_Modele_BERT.ipynb              # DistilBERT pour analyse de sentiment

📔 Notebooks du projet

📊 Notebook 1 : Analyse exploratoire des données - Exploration du dataset Sentiment140 et visualisations
🔍 Notebook 2 : Modèle classique (TF-IDF + Regression Logistique) - Implémentation de l'approche "sur mesure simple"
🧠 Notebook 3 : Modèle avancé (Word2Vec + LSTM) - Réseau de neurones avec word embeddings
🚀 Notebook 4 : Modèle BERT pour l'analyse de sentiment - Fine-tuning de DistilBERT (Google Colab)

🧭 Guides

Guide d'utilisation de l'API FastAPI : API FastAPI qui expose un modèle de deep learning pour l'analyse de sentiment
Guide d'utilisation du frontend Next.JS : Application Next.js avec Bootstrap pour l'interface utilisateur
Guide de Monitoring pour Air Paradis : Mise en place du feedback utilisateur et des alertes avec Azure Application insights

📑 Méthodologie et données

Le jeu de données Sentiment140

Pour ce projet, nous avons utilisé le jeu de données open source Sentiment140, qui contient 1,6 million de tweets annotés selon leur polarité (négative ou positive). Ce dataset comprend six champs principaux :

target : la polarité du tweet (0 = négatif, 4 = positif)
ids : l'identifiant du tweet
date : la date du tweet
flag : une requête éventuelle
user : l'utilisateur ayant posté le tweet
text : le contenu textuel du tweet

Nous avons choisi ce jeu de données pour sa taille conséquente et sa pertinence vis-à-vis de notre objectif d'analyse de sentiments sur Twitter. Sa structure binaire (positif/négatif) correspond parfaitement à notre besoin de détecter les opinions négatives pouvant potentiellement nuire à l'image d'Air Paradis.

Analyse exploratoire des données Sentiment140

Notre analyse exploratoire a révélé des caractéristiques distinctives importantes entre les tweets positifs et négatifs :

Les tweets positifs contiennent 93% plus d'URLs que les négatifs
Les tweets positifs contiennent 48% plus de mentions (@)
Les tweets positifs utilisent 39% plus de hashtags (#)
Les tweets positifs utilisent 39% plus de points d'exclamation (!)
Les tweets négatifs contiennent 24% plus d'ellipses (...)
Les tweets négatifs sont légèrement plus longs et contiennent plus de mots

Cette analyse nous a permis de mieux comprendre les spécificités du langage sur Twitter et d'identifier des éléments discriminants entre sentiments positifs et négatifs. Ces observations ont directement influencé notre stratégie de prétraitement et la conception de nos modèles.

Prétraitement des données textuelles

En nous basant sur l'analyse exploratoire, nous avons développé une fonction de prétraitement spécifique pour les tweets :

def preprocess_tweet(tweet):
    """
    Prétraite un tweet en appliquant plusieurs transformations :
    - Conversion en minuscules
    - Remplacement des URLs, mentions et hashtags par des tokens spéciaux
    - Suppression des caractères spéciaux
    - Tokenisation et lemmatisation
    - Suppression des stopwords
    """
    # Vérifier si le tweet est une chaîne de caractères
    if not isinstance(tweet, str):
        return ""

    # Convertir en minuscules
    tweet = tweet.lower()

    # Remplacer les URLs par un token spécial
    tweet = re.sub(r'https?://\S+|www\.\S+', '<URL>', tweet)

    # Remplacer les mentions par un token spécial
    tweet = re.sub(r'@\w+', '<MENTION>', tweet)

    # Traiter les hashtags (conserver le # comme token séparé et le mot qui suit)
    tweet = re.sub(r'#(\w+)', r'# \1', tweet)

    # Supprimer les caractères spéciaux et les nombres, mais garder les tokens spéciaux
    tweet = re.sub(r'[^\w\s<>@#!?]', '', tweet)

    # Tokenisation
    tokens = word_tokenize(tweet)

    # Lemmatisation
    lemmatizer = WordNetLemmatizer()
    tokens = [lemmatizer.lemmatize(token) for token in tokens]

    # Supprimer les stopwords, mais conserver les négations importantes
    stop_words = set(stopwords.words('english'))
    important_words = {'no', 'not', 'nor', 'neither', 'never', 'nobody', 'none', 'nothing', 'nowhere'}
    stop_words = stop_words - important_words
    tokens = [token for token in tokens if token not in stop_words]

    # Rejoindre les tokens en une chaîne
    return ' '.join(tokens)

Notre stratégie de prétraitement s'est concentrée sur trois aspects clés :

Traitement des éléments spéciaux : Plutôt que de simplement supprimer les URLs, mentions et hashtags, nous les avons remplacés par des tokens spéciaux (<URL>, <MENTION>) afin de préserver l'information de leur présence, tout en séparant les hashtags pour conserver leur contenu sémantique.
Conservation des négations : Nous avons exclu les mots de négation de la liste des stopwords pour préserver le sens du sentiment exprimé.
Lemmatisation plutôt que stemming : Après avoir testé les deux approches, nous avons privilégié la lemmatisation qui préserve mieux le sens des mots tout en réduisant la dimensionnalité du vocabulaire.

🧠 Approches de modélisation

Pour répondre à la demande d'Air Paradis, nous avons développé et comparé trois approches de modélisation distinctes, de la plus simple à la plus avancée.

Modèle sur mesure simple (approche classique)

Notre première approche s'est appuyée sur des techniques classiques de machine learning, combinant une vectorisation des tweets avec des algorithmes de classification.

Nous avons d'abord exploré deux méthodes de représentation vectorielle de texte :

Bag of Words : transformation des tweets en vecteurs numériques basés sur la fréquence d'apparition de chaque mot
TF-IDF : pondération des mots selon leur importance relative dans le tweet et leur rareté dans l'ensemble du corpus

Pour la phase de classification, nous avons testé quatre algorithmes différents :

Régression Logistique : modèle linéaire adapté aux problèmes de classification binaire
SVM Linéaire : recherche d'un hyperplan optimal séparant les sentiments positifs et négatifs
Random Forest : ensemble d'arbres de décision offrant robustesse et réduction du surapprentissage
Naive Bayes : classifieur probabiliste particulièrement adapté aux données textuelles

Après optimisation des hyperparamètres via validation croisée, le SVM Linéaire combiné au Bag of Words s'est révélé être la solution la plus performante avec les hyperparamètres suivants :

Coefficient de régularisation :C=0.01
Configuration :dual=True
Nombre maximal d'itérations : max_iter=1000

Les métriques d'évaluation confirment l'efficacité de ce modèle :

F1 Score : 0.785 (équilibre entre précision et rappel)
F2 Score : 0.798 (privilégiant le rappel pour minimiser les faux négatifs)
ROC AUC : 0.852 (bonne capacité discriminative)
Précision globale : 79,8% sur notre jeu de test

Cette approche, malgré sa relative simplicité, fournit déjà une base solide pour la détection des sentiments négatifs dans les tweets concernant Air Paradis. Elle constitue une référence précieuse pour évaluer les gains potentiels des modèles plus sophistiqués que nous avons développés par la suite.

Modèle sur mesure avancé (réseaux de neurones avec word embeddings)

Pour notre deuxième approche, nous avons exploré les techniques de deep learning avec des embeddings de mots et des réseaux de neurones récurrents. Nous avons d'abord optimisé notre environnement pour utiliser efficacement le GPU disponible (GTX 1060 3GB) :

Optimisations matérielles :
- Désactivation du recurrent_dropout pour permettre l'utilisation de CuDNNLSTM optimisé
- Activation de XLA (Accelerated Linear Algebra) pour optimiser les graphes d'opérations
- Utilisation de la précision mixte (float16/float32)
- Augmentation de la taille du batch à 256 pour exploiter le parallélisme
- Optimisation du pipeline de données avec tf.data.Dataset et prefetch
Word Embeddings : nous avons comparé deux techniques d'embeddings pour représenter les mots dans un espace vectoriel dense :
- Word2Vec pré-entraîné sur un large corpus de tweets
- GloVe (Global Vectors for Word Representation)
Architecture du réseau : nous avons implémenté un réseau de neurones bidirectionnel avec plusieurs couches LSTM et des mécanismes de régularisation :

def create_optimized_lstm_model(embedding_matrix, max_seq_length=MAX_SEQUENCE_LENGTH, trainable=False):
    vocab_size, embedding_dim = embedding_matrix.shape

    # Entrée du modèle
    input_layer = tf.keras.layers.Input(shape=(max_seq_length,))

    # Couche d'embedding avec des poids pré-entraînés
    embedding_layer = tf.keras.layers.Embedding(
        input_dim=vocab_size,
        output_dim=embedding_dim,
        weights=[embedding_matrix],
        input_length=max_seq_length,
        trainable=trainable
    )(input_layer)

    # Dropout spatial
    dropout_1 = tf.keras.layers.SpatialDropout1D(0.3)(embedding_layer)

    # Couche LSTM bidirectionnelle optimisée pour GPU
    lstm_layer = tf.keras.layers.Bidirectional(
        tf.keras.layers.LSTM(
            units=128,
            dropout=0.2,
            recurrent_dropout=0.0,  # Optimisation GPU
            return_sequences=True
        )
    )(dropout_1)

    # Deuxième couche LSTM
    lstm_layer_2 = tf.keras.layers.Bidirectional(
        tf.keras.layers.LSTM(
            units=64,
            dropout=0.2,
            recurrent_dropout=0.0  # Optimisation GPU
        )
    )(lstm_layer)

    # Couche dense avec activation ReLU
    dense_1 = tf.keras.layers.Dense(64, activation='relu')(lstm_layer_2)
    dropout_2 = tf.keras.layers.Dropout(0.4)(dense_1)

    # Couche de sortie
    output_layer = tf.keras.layers.Dense(1, activation='sigmoid')(dropout_2)

    # Créer et compiler le modèle
    model = tf.keras.Model(inputs=input_layer, outputs=output_layer)

    model.compile(
        optimizer=tf.keras.optimizers.Adam(learning_rate=0.001),
        loss='binary_crossentropy',
        metrics=['accuracy']
    )

    return model

L'architecture de notre modèle LSTM comprend :

Une couche d'embedding initialisée avec les poids pré-entraînés Word2Vec
Un dropout spatial pour réduire la corrélation entre les features consécutives
Deux couches LSTM bidirectionnelles (128 puis 64 unités) pour capturer les dépendances contextuelles
Des couches de dropout pour la régularisation et éviter le surapprentissage
Une couche dense intermédiaire avec activation ReLU
Une couche de sortie avec activation sigmoïde pour la classification binaire

Les résultats de l'entraînement montrent une progression constante de l'accuracy, comme on peut le voir sur les graphiques ci-dessous :

Cette approche plus sophistiquée nous a permis d'atteindre une précision de 81,8% sur l'ensemble de validation, avec un score de 85,2% sur le jeu d'entraînement, surpassant ainsi le modèle simple.

Modèle BERT (approche transformer)

Pour notre troisième approche, nous avons exploré l'état de l'art en NLP en utilisant BERT (Bidirectional Encoder Representations from Transformers) :

Modèle pré-entraîné : nous avons utilisé DistilBERT, une version allégée et distillée de BERT, pour réduire les coûts de calcul tout en maintenant des performances élevées
Fine-tuning : nous avons affiné le modèle sur notre jeu de données spécifique d'analyse de sentiments

Pour cette approche, nous avons utilisé le modèle DistilBertForSequenceClassification de la bibliothèque Hugging Face, qui est spécifiquement conçu pour les tâches de classification de séquences textuelles :

def train_bert_sentiment(data_path, model_name="distilbert-base-uncased", batch_size=4, epochs=3, sample_size=20000):
    """
    Fonction principale pour l'entraînement du modèle DistilBERT sur une tâche d'analyse de sentiments.
    """

    # Définir les paramètres
    params = {
        'model_name': model_name,
        'batch_size': batch_size,
        'learning_rate': 2e-5,
        'epochs': epochs,
        'max_length': 128,
        'sample_size': sample_size
    }

    # Charger les données
    print("Chargement du dataset...")
    column_names = ['target', 'ids', 'date', 'flag', 'user', 'text']
    raw_data = pd.read_csv(data_path, encoding='utf-8', names=column_names)

    # Préparer les données
    print("Préparation des données...")
    data_splits = prepare_data(raw_data, sample_size=sample_size)

    # Initialiser le tokenizer et le modèle
    print("Initialisation du modèle DistilBERT...")
    tokenizer = DistilBertTokenizer.from_pretrained(model_name)
    model = DistilBertForSequenceClassification.from_pretrained(
        model_name,
        num_labels=2  # Sentiment binaire (0 = négatif, 1 = positif)
    )

    # Ajustement du batch size selon la mémoire GPU
    adjusted_batch_size = min(8, batch_size)

    # Création des datasets et des dataloaders
    train_dataset = TweetDataset(data_splits['train']['texts'], data_splits['train']['labels'], tokenizer)
    val_dataset = TweetDataset(data_splits['val']['texts'], data_splits['val']['labels'], tokenizer)
    test_dataset = TweetDataset(data_splits['test']['texts'], data_splits['test']['labels'], tokenizer)

    train_loader = DataLoader(train_dataset, batch_size=adjusted_batch_size, shuffle=True)
    val_loader = DataLoader(val_dataset, batch_size=adjusted_batch_size * 2)
    test_loader = DataLoader(test_dataset, batch_size=adjusted_batch_size * 2)

    # Détection du device (GPU/CPU)
    device = torch.device('cuda' if torch.cuda.is_available() else 'cpu')
    model.to(device)

    # Entraînement du modèle avec accumulation de gradients pour optimiser l'utilisation mémoire
    gradient_accumulation_steps = max(1, 16 // adjusted_batch_size)
    history, metrics = train_model(
        model,
        train_loader,
        val_loader,
        test_loader,
        device,
        epochs=epochs,
        gradient_accumulation_steps=gradient_accumulation_steps
    )

    # Enregistrement du modèle dans MLflow
    run_id = log_model_to_mlflow(model, tokenizer, model_name, metrics, params)

    return {
        'model': model,
        'tokenizer': tokenizer,
        'metrics': metrics,
        'run_id': run_id
    }

DistilBERT est particulièrement adapté à notre tâche car il :

Utilise une architecture transformer bidirectionnelle pour capturer le contexte dans les deux directions
A été pré-entraîné sur un large corpus de textes, ce qui lui permet de comprendre les nuances linguistiques
Est 40% plus léger que BERT tout en conservant 97% de ses performances
S'intègre parfaitement dans un pipeline MLOps grâce à son API standardisée

Cette approche transformers nous a permis d'atteindre une précision de 91,3 %, démontrant la puissance des architectures basées sur l'attention pour la compréhension du langage naturel.

Comparaison des performances des modèles

Voici un récapitulatif des performances obtenues avec nos différentes approches :

Modèle	Précision (Accuracy)	F1-Score	Temps d'entraînement	Taille du modèle
Régression Logistique + TF-IDF	79,8%	0,797	~5 minutes	~15 MB
LSTM + Word2Vec	85,2%	0,851	~2 heures	~90 MB
LSTM + GloVe	84,7%	0,846	~2 heures	~88 MB
DistilBERT fine-tuné	91,3%	0,912	~4 heures (GPU)	~250 MB

Pour le déploiement en production, nous avons retenu le modèle LSTM avec Word2Vec, qui offre le meilleur compromis entre performance et ressources requises. Bien que DistilBERT ait obtenu de meilleurs résultats, sa taille et ses exigences en termes de ressources de calcul le rendaient moins adapté à un déploiement sur une infrastructure Cloud gratuite.

⚙️ Mise en œuvre du MLOps

Principes du MLOps

Le MLOps (Machine Learning Operations) est une méthodologie qui vise à standardiser et à automatiser le cycle de vie des modèles de machine learning, de leur développement à leur déploiement en production. Pour ce projet, nous avons mis en œuvre plusieurs principes clés du MLOps :

Reproductibilité : environnement de développement versionné et documenté
Automatisation : pipeline de déploiement continu
Monitoring : suivi des performances du modèle en production
Amélioration continue : collecte de feedback et réentraînement périodique

Cette approche nous a permis de créer une solution robuste et évolutive pour Air Paradis.

Tracking des expérimentations avec MLFlow

Pour assurer une gestion efficace des expérimentations, nous avons utilisé MLFlow, un outil open-source spécialisé dans le suivi et la gestion des modèles de machine learning :

Tracking des métriques : pour chaque expérimentation, nous avons enregistré automatiquement les paramètres du modèle, les métriques de performance (accuracy, F1-score, précision, rappel) et les artefacts générés
Centralisation des modèles : tous les modèles entraînés ont été stockés de manière centralisée avec leurs métadonnées
Visualisation : l'interface utilisateur de MLFlow nous a permis de comparer visuellement les différentes expérimentations

Cette approche nous a permis de garder une trace claire de l'évolution de nos modèles et de sélectionner objectivement le plus performant pour le déploiement.

💻 Interface utilisateur

Architecture de l'application

Notre solution se compose de deux parties principales :

Backend (FastAPI) :
- API REST exposant le modèle d'analyse de sentiments
- Endpoints pour la prédiction individuelle et par lots
- Système de feedback et de monitoring
- Téléchargement automatique des artefacts du modèle depuis MLFlow

Frontend (Next.js) :
- Interface utilisateur intuitive et responsive
- Mode clair/sombre pour le confort visuel
- Visualisation des résultats de prédiction
- Système de collecte de feedback
- Widget d'indication de connexion avec l'API

Fonctionnalités de l'interface utilisateur

L'interface utilisateur offre plusieurs fonctionnalités clés pour faciliter l'analyse de sentiments :

Analyse individuelle : prédiction du sentiment d'un tweet unique
Exemples prédéfinis : tweets d'exemple positifs et négatifs
Historique : conservation des analyses précédentes
Feedback : possibilité de signaler des prédictions incorrectes

Cette interface a été conçue pour être intuitive et accessible aux équipes marketing d'Air Paradis, sans nécessiter de connaissances techniques approfondies.

🔄 Pipeline de déploiement continu

Pour automatiser le déploiement de notre modèle, nous avons mis en place un pipeline CI/CD (Intégration Continue / Déploiement Continu) avec les composants suivants :

Versionnement du code : utilisation de Git pour le contrôle de version
GitHub Actions : automatisation des tests et du déploiement à chaque push sur la branche principale
Déploiement sur Heroku : plateforme Cloud pour héberger notre API de prédiction

Tests unitaires automatisés

Pour garantir la fiabilité de notre solution, nous avons implémenté des tests unitaires automatisés couvrant les aspects critiques :

Test du endpoint de santé : Vérifie que l'API répond correctement sur /health avec un code 200 et confirme que le statut retourné est "ok". Le modèle est chargé correctement.
Test du endpoint de prédiction : S'assure que l'API traite correctement les requêtes POST sur /predict, accepte un texte à analyser et renvoie un résultat contenant les champs "sentiment" et "confidence".

def test_health_endpoint(client):
    response = client.get("/health")
    assert response.status_code == 200
    assert response.json()["status"] == "ok"

def test_predict_endpoint(client):
    response = client.post("/predict", json={"text": "I love flying with this airline!"})
    assert response.status_code == 200
    result = response.json()
    assert "sentiment" in result
    assert "confidence" in result

GitHub Actions

Le déploiement est entièrement automatisé grâce à GitHub Actions :

Déclenchement : À chaque commit/push sur la branche principale, GitHub Actions lance le workflow.
Tests automatisés : Le workflow exécute tous les tests unitaires.
Déploiement conditionnel : Uniquement si les tests réussissent, l'application est déployée automatiquement sur Heroku.

Création du workflow GitHub Actions

Pour la création du workflow GitHub Actions, nous créons un fichier .github/workflows/heroku-deploy.yml à la racine dont voici le contenu :

name: Deploy to Heroku

on:
  push:
    branches:
      - main
    paths:
      - 'app/fastapi/**'

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Set up Python
        uses: actions/setup-python@v2
        with:
          python-version: '3.10'
      - name: Install dependencies
        working-directory: ./app/fastapi
        run: |
          python -m pip install --upgrade pip
          pip install -r requirements.txt
      - name: Run tests
        working-directory: ./app/fastapi
        run: |
          python -m pytest tests/test_api.py -v
        env:
          MLFLOW_TRACKING_URI: ${{ secrets.MLFLOW_TRACKING_URI }}
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          RUN_ID: ${{ secrets.RUN_ID }}
          APPINSIGHTS_INSTRUMENTATION_KEY: ${{ secrets.APPINSIGHTS_INSTRUMENTATION_KEY }}

  deploy:
    needs: test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Install Heroku CLI
        run: |
            curl https://cli-assets.heroku.com/install.sh | sh
      - name: Deploy to Heroku
        uses: akhileshns/heroku-deploy@v3.12.12
        with:
          heroku_api_key: ${{ secrets.HEROKU_API_KEY }}
          heroku_app_name: "air-paradis-sentiment-api"
          heroku_email: ${{ secrets.HEROKU_EMAIL }}
          appdir: "app/fastapi"
          region: "eu"

Configuration des secrets GitHub

Le workflow GitHub Actions a besoin d'accéder aux variables d'environnement. Nous avons donc renseigner les "secrets" nécessaires. Dans notre dépôt GitHub, nous allons dans "Settings" > "Secrets and variables" > "Actions", puis nous cliquons sur "New repository secret". Nous ajoutons les secrets suivants:

Nom du secret	Description
`HEROKU_API_KEY`	Clé API Heroku
`HEROKU_EMAIL`	Email du compte Heroku
`MLFLOW_TRACKING_URI`	URI du serveur MLflow
`RUN_ID`	ID du run MLflow
`APPINSIGHTS_INSTRUMENTATION_KEY`	Clé Application Insights

Déploiement sur Heroku

Pour le déploiement de notre solution, nous avons choisi Heroku pour plusieurs raisons :

Plan gratuit : conforme à la demande de limiter les coûts pour ce prototype
Intégration avec GitHub : facilite le déploiement continu avec GitHub Actions
Scalabilité : possibilité d'évoluer si le projet est approuvé pour la production
Région Europe : conformité avec les exigences de localisation des données

Configuration Heroku

Notre application utilise les fichiers de configuration suivants pour Heroku :

Procfile : web: uvicorn main:app --host=0.0.0.0 --port=${PORT:-8000}
runtime.txt : python-3.10.12
requirements.txt : Liste de toutes les dépendances nécessaires

Les variables d'environnement sur Heroku incluent :

MLFLOW_TRACKING_URI : URI du serveur MLflow
RUN_ID : Identifiant du run MLflow du modèle déployé
APPINSIGHTS_INSTRUMENTATION_KEY : Clé pour Azure Application Insights

Exemple d'exécution et déploiement réussis

La capture d'écran suivante indique les tests ont été passés avec succès et que le déploiement est réussi sur Heroku.

Avantages de notre pipeline CI/CD

Notre pipeline de déploiement continu offre plusieurs avantages significatifs :

Automatisation complète : Aucune intervention manuelle nécessaire
Fiabilité accrue : Tests systématiques réduisant les risques
Traçabilité : Chaque déploiement lié à un commit Git spécifique
Feedback rapide : Information immédiate en cas de problème

Cette approche MLOps moderne nous permet de nous concentrer sur l'amélioration de notre modèle d'analyse de sentiment plutôt que sur les aspects opérationnels, tout en garantissant que chaque nouvelle version est correctement validée avant la mise en production.

📡 Suivi de la performance en production

Mise en place d'Azure Application Insights

Pour assurer un suivi efficace des performances du modèle en production, nous avons intégré Azure Application Insights, un service d'analyse des performances applicatives :

Télémétrie : collecte automatique des données de performance de l'API
Événements personnalisés : enregistrement d'événements spécifiques liés au modèle
Visualisation : tableaux de bord pour suivre l'évolution des performances

Cette intégration nous permet de disposer d'une vision complète du comportement de notre modèle en situation réelle.

Système de feedback utilisateur

Un élément clé de notre approche MLOps est la collecte de feedback utilisateur sur les prédictions du modèle :

Interface de validation : pour chaque prédiction, l'utilisateur peut indiquer si elle est correcte ou non
Collecte structurée : enregistrement du tweet, de la prédiction initiale et de la correction éventuelle
Stockage centralisé : toutes les données de feedback sont centralisées dans Azure Application Insights

Dans Azure Application Insights, pour consulter les feedbacks de tweets incorrectement prédits, il suffit d'exécuter la commande suivante :

customEvents
| where name == "model_feedback" and customDimensions.is_correct == "False"
| sort by timestamp desc
| project timestamp, 
        tweet = tostring(customDimensions.tweet), 
        prediction = tostring(customDimensions.prediction), 
        corrected_sentiment = tostring(customDimensions.corrected_sentiment)

Ce système permet de constituer progressivement un corpus d'exemples difficiles qui serviront à améliorer le modèle. Ces exemples difficiles sont particulièrement précieux car ils représentent les cas limites où le modèle actuel échoue, révélant ainsi ses points faibles spécifiques.

En collectant systématiquement ces tweets mal classifiés, nous créons un dataset enrichi qui cible précisément les lacunes du modèle. Cette approche d'apprentissage actif (active learning) est beaucoup plus efficace qu'une simple augmentation de données aléatoire, car elle concentre les efforts d'amélioration sur les zones problématiques.

Configuration des alertes automatiques

Pour détecter rapidement les problèmes potentiels, nous avons configuré un système d'alertes automatiques :

Définition du seuil : déclenchement d'une alerte si 3 prédictions incorrectes sont signalées dans un intervalle de 5 minutes.
Notification : envoi d'un email aux responsables du projet.
Suivi : journalisation des alertes pour analyse ultérieure.

Ce mécanisme proactif permet à l'équipe d'intervenir rapidement en cas de dégradation des performances du modèle.

Stratégie d'amélioration continue du modèle

Pour garantir la pertinence du modèle dans le temps, nous définissons une stratégie d'amélioration continue :

Analyse périodique : examen mensuel des tweets mal prédits pour identifier des patterns
Enrichissement des données : ajout des exemples difficiles au jeu d'entraînement
Réentraînement : mise à jour trimestrielle du modèle avec les nouvelles données
Déploiement automatisé : mise en production de la nouvelle version via le pipeline CI/CD

Cette approche cyclique permet d'adapter le modèle à l'évolution du langage sur Twitter et aux spécificités des conversations concernant Air Paradis.

🏁 Conclusion

Résultats obtenus

Ce projet nous a permis de développer un prototype fonctionnel d'analyse de sentiments pour tweets, répondant pleinement aux attentes d'Air Paradis :

Performance : notre modèle LSTM avec Word2Vec atteint une précision de 85,2%, offrant une détection fiable des sentiments négatifs.
Déploiement : la solution est accessible via une API REST déployée sur Heroku.
Interface : une application ergonomique permet aux équipes marketing d'utiliser facilement le modèle.
Monitoring : un système complet de suivi et d'alertes garantit la détection rapide des problèmes potentiels.

Perspectives d'évolution

Si ce prototype est validé par Air Paradis, plusieurs axes d'amélioration pourraient être explorés :

Déploiement du modèle BERT : migration vers une infrastructure permettant d'exploiter les performances supérieures de BERT
Analyse en temps réel : intégration avec l'API Twitter pour une surveillance continue
Classification multi-classes : distinction entre sentiments négatifs, neutres et positifs
Analyse thématique : identification des sujets spécifiques générant des sentiments négatifs

Avantages pour Air Paradis

Cette solution d'analyse de sentiments offre plusieurs avantages stratégiques pour Air Paradis :

Détection précoce : identification des bad buzz potentiels avant qu'ils ne prennent de l'ampleur
Réactivité : capacité à intervenir rapidement sur les problèmes signalés
Intelligence client : meilleure compréhension des préoccupations et des attentes des clients
Protection de l'image : préservation de la réputation de la compagnie sur les réseaux sociaux

En conclusion, ce projet illustre comment les technologies d'IA, combinées à une approche MLOps structurée, peuvent apporter une réelle valeur ajoutée dans la gestion de la réputation en ligne d'une entreprise. Air Paradis dispose désormais d'un outil puissant pour anticiper et gérer efficacement sa présence sur les réseaux sociaux.

🌊 Déployer un serveur MLflow dans un Codespace Github

David Scanu — Wed, 20 Mar 2024 11:42:36 +0000

Voici toutes les étapes pour lancer un serveur MLflow directement dans une machine virtuelle GitHub Codespace. Le gros avantage de cette méthode est quelle permet de lancer rapidement et gratuitement un serveur MLflow pour suivre vos expériences de machine learning. Voici le dépôt GitHub dont vous aurez besoin :

Lancer un serveur MLflow dans un codespace (GitHub)

Les codespaces sont des environnements de développement hébergés sur GitHub. Ils offrent un environnement de développement ou que vous soyez, depuis votre navigateur.

🚀 Partie 1 : Lancer un serveur MLflow dans codespace

Vous avez besoin d'un serveur MLflow hébergé gratuitement ? Suivez les étapes suivantes.

1. Dupliquez (fork) ce dépôt

Dupliquez (fork) le dépôt suivant : Lancer un serveur MLflow dans un codespace (GitHub)

2. Renseignez les variables d'environnement

Allez à la page de configuration des variables d'environnement pour Codespaces du dépôt, à l'adresse suivante : https://github.com/[votre-nom-utilisateur]/mlflow-server-devcontainer/settings/secrets/codespaces. Renseignez les variables suivantes :

ARTIFACT_STORE_URI : L'URI de stockage des artéfacts (Amazon S3).
AWS_ACCESS_KEY_ID et AWS_SECRET_ACCESS_KEY : Les identifiants de connexion à l'espace de stockage Amazon S3.
BACKEND_STORE_URI : L'URI de votre base de donnée. Pour une base de donnée PostgreSQL, l'URI se présente au format : postgresql://[username]:[password]@[host]:[port]/[database]

Plus de renseignements sur la configuration d'un serveur de tracking MLflow : Set up the MLflow Tracking Environment.

3. Lancez un nouveau codespace

Lancez un nouveau codespace à partir de votre dépôt (UI de GitHub: Code / Codespaces / +)

4. Ouvrez le port 5001

Dans le Terminal, onglet "Ports", définissez l'URL du port 5001 comme public.

5. Accédez à l'UI MLflow

Accéder à l'UI MLflow en accédant à l'URL public exposée par codespace.

Utilisez cette URL pour le tracking de vos travaux de machine learning depuis un notebook Colab ou notebook local, soit en définissant la variable d'environnement MLFLOW_TRACKING_URI, soit en exécutant le code Python suivant dans votre notebook :

mlflow.set_tracking_uri(uri="http://<host>:<port>")

6. (Optionnel) Testez votre serveur MLflow

A l'intérieur de votre codespace, exécutez les étapes suivantes :

Entrainez un modèle : python3 demo/train.py. Vous devez voir apparaître un nouveau run dans l'UI MLflow et dans le Terminal.
Copiez le numéro de Run : Copiez le numéro de run (run id) qui apparaît dans le Terminal.
Utilisez un modèle : python3 demo/try-model.py. Entrez le numero de run (run id) dans le Terminal. Cette commande retourne un modèle dans le Terminal, cela signifie que vos modèle trackés par votre serveur MLflow sont disponibles à l'utilisation.

7. Utilisation depuis un notebook Colab

Démonstration de l'utilisation du serveur de tracking depuis ce notebook Colab.

Modifiez les variables d'environnement suivantes dans l'onglet "🔑 Secrets" :
- MLFLOW_TRACKING_URI
- AWS_ACCESS_KEY_ID
- AWS_SECRET_ACCESS_KEY

Votre serveur MLflow fonctionne maintenant depuis votre codespace et vous pouvez trackez vos expériences de machine learning. N'oubliez pas de lancer et d'éteindre votre codespace à chaque utilisation. Sans quoi, du temps d'utilisation vous sera décompté.

Partie 2 : Comment ça marche ?

Si vous souhaitez simplement et rapidement lancer un serveur MLflow dans un codespace, seule la première partie de cet article vous est utile. Cette deuxième partie n'est utile que si vous souhaitez comprendre comment fonctionne la configuration d'un conteneur de développement (Dev Container) dans un codespace.

Les machines virtuelles codespace sont en réalité des conteneurs de développement (Dev Container), basés sur des images Docker. Pour créer notre serveur MLflow personnalisé qui fonctionne dans un codespace, nous avons créé une configuration de conteneur de développement (Dev Container) à partir d'une image Docker et d'un docker-compose.yaml.

Configuration d'un conteneur de développement

Pour configurer un conteneur de développement (Dev Container), nous créons les fichiers suivants :

Un dossier .devcontainer/ : dossier de stockage de tous les fichiers de configuration du codespace.
un fichier devcontainer.json : stocke les paramètres spécifiques à notre conteneur de développement (Dev container).
un fichier Dockerfile : la configuration de l'image Docker qui configure le conteneur de développement avec les logiciels Python 3.10, Docker et GIT.
un fichier docker-compose.yaml (Docker Compose) : permet de construire l'image Docker à partir du Dockerfile et de configurer les variables d'environnement dans le conteneur
un fichier requirements.txt : permet d'installer les bibliothèques Python
un fichier .dockerignore : permet d'ignorer certains dossier qu'on souhaite ignorer dans l'image finale.

Passons en revue les différents fichiers de configuration.

devcontainer.json

C'est le fichier principal de configuration du conteneur de développement. Il permet de :

Créer un environnement de développement à partir du fichier docker-compose.yaml. Le paramètre "dockerComposeFile" indique le chemin vers le fichier docker-compose.yaml (qui lui-même utilise le Dockerfile). "service" indique quel service dans le fichier docker-compose.yaml doit être utilisé comme conteneur principal pour le codespace. "workspaceFolder" indique le dossier principal de travail à ouvrir dans le codespace.
Rediriger le port sur lequel le serveur écoute, c-à-d 5001 pour notre cas avec le paramètre "forwardPorts". Le paramètre "onAutoForward": "openBrowser" indique au conteneur d'ouvrir l'URL public sur le port 5001 à chaque lancement du codespace.
Ajouter des "features" avec le paramètre "features": Les "features" permettent d'ajouter rapidement et facilement davantage d’outils supplémentaires à notre conteneur de développement. Ici , nous avons ajouté Git et Docker (Docker est inutile pour notre cas d'utilisation).
Personnaliser VS Code à l'intérieur du codespace "customizations": installer des extensions et customiser la présentation.

{
    "name": "MLflow Server",
    "dockerComposeFile": "../docker-compose.yaml",
    "service": "mlflow-server",
    "workspaceFolder": "/mlflow",

    // Use 'forwardPorts' to make a list of ports inside the container available locally.
    "forwardPorts": [5001],

    "portsAttributes": {
        "5001": {
            "label": "MLflow server port",
            "onAutoForward": "openBrowser"
        }
    },

    // Features to add to the dev container. More info: https://containers.dev/features.
    "features": {
        "ghcr.io/devcontainers/features/docker-in-docker:2": {},
        "ghcr.io/devcontainers/features/git:1": {}
    },

    // VS Code customization inside the container
    "customizations": {
        "vscode": {
            "settings": {
                "workbench.colorTheme": "Default Dark Modern"
            },
            "extensions": [
                "ms-vscode-remote.vscode-remote-extensionpack",
                "ms-azuretools.vscode-docker",
                "ms-python.vscode-pylance",
                "ms-python.python",
                "ms-vscode-remote.remote-containers",
                "GitHub.codespaces",
                "ms-toolsai.jupyter",
                "bierner.markdown-preview-github-styles"
            ]
        }
    }
}

Dockerfile

Le reste de la configuration est un peu plus simple. Nous créons une image docker avec un Dockerfile à partir d'une image Python 3.10, dans laquelle nous installons MLflow, Boto3, Psycopg et Scikit-learn avec le fichier requirements.txt. Puis nous lançons le serveur MLflow en utilisant les variables d'environnement du conteneur, définies dans le docker-compose.yaml.

FROM python:3.10-slim

WORKDIR /mlflow/mlflow-data

RUN python -m pip install --upgrade pip

COPY requirements.txt .

RUN pip install -r requirements.txt

CMD mlflow server --port $PORT --host 0.0.0.0 --backend-store-uri $BACKEND_STORE_URI --default-artifact-root $ARTIFACT_STORE_URI

Docker Compose (compose.yaml)

Enfin, nous créons un conteneur à partir de l'image définie dans le Dockerfile (build : .). Nous exposons le port 5001. Nous définissons les variables d'environnement qui provienne des réglages des secrets du codespace.

version: '3'
services:
  mlflow-server:
    build : .
    ports:
      - "5001:5001"
    environment:
      - PORT=5001
      - BACKEND_STORE_URI=$BACKEND_STORE_URI
      - ARTIFACT_STORE_URI=$ARTIFACT_STORE_URI
      - AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
      - AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
    volumes:
      - .:/mlflow
    restart: always

Et voilà ! Vous savez maintenant configurez votre propre conteneur de développement avec les outils et "features" dont vous avez besoin !