projet-8-api / resume_execution_notebook.md
JeanProjets's picture
Upload folder using huggingface_hub
1a8e402 verified
|
Raw
History Blame Contribute Delete
4.04 kB

Synthèse de l'Exécution du Notebook (MobileNetV2-UNet)

Ce document résume les actions effectuées par Gemini CLI pour adapter et exécuter localement le notebook Colab trouvé sur internet (Copie_de_p08_david_scanu_notebook_MobileNetV2_UNet.ipynb), ainsi que les résultats produits par cette exécution.

1. Contexte et Objectif

Le but était de prendre un notebook Google Colab conçu pour l'entraînement d'un modèle de segmentation sémantique (architecture MobileNetV2-UNet sur le jeu de données Cityscapes) et de l'exécuter de bout en bout sur l'environnement local.

2. Fichiers de configuration et d'adaptation créés

Pour rendre le notebook exécutable localement (hors de l'environnement Google Colab) et de manière automatisée, Gemini CLI a généré plusieurs scripts Python "patch" pour modifier le code du notebook à la volée :

  • fix_colab.py : A commenté toutes les lignes spécifiques à Google Colab (comme import google.colab ou drive.mount), qui auraient provoqué des erreurs en local.
  • patch_notebook.py : A remplacé le long processus de téléchargement du véritable jeu de données Cityscapes par une fonction générant un jeu de données fictif (mock). Cela a permis de tester l'intégralité du pipeline (de l'entraînement à l'évaluation) très rapidement sans devoir télécharger des gigaoctets de données.
  • fix_epochs.py : A probablement réduit le nombre d'époques d'entraînement (epochs) pour accélérer l'exécution du test de bout en bout.
  • fix_paths.py / patch_train.py / patch_image.py : Ont servi à corriger les chemins de fichiers et d'autres petits détails d'implémentation pour s'assurer que le notebook puisse tourner correctement sur votre machine.
  • notebook_script.py : Le code Python final, extrait du notebook, prêt à être exécuté.

3. Résultats et Fichiers Générés (Outputs)

L'exécution du notebook a généré une arborescence complète de résultats, principalement documentée dans le fichier outputs_summary.md :

  • Modèles Entraînés (content/experiments/.../models/) :
    • cityscapes_segmentation_model.keras : Le modèle complet de fin d'entraînement.
    • checkpoints/best_model.keras : Le meilleur modèle sauvegardé en cours de route (celui à utiliser pour les prédictions).
    • class_mapping.json : Le dictionnaire qui associe les classes prédites (IDs) à leurs couleurs et noms (ex: "route", "voiture").
  • Métriques et Évaluation (content/experiments/.../results/) :
    • Des fichiers CSV et JSON contenant l'IoU par classe, la matrice de confusion, le rapport de classification et l'historique d'entraînement.
  • Visualisations (content/experiments/.../visualizations/) :
    • Des graphiques de l'historique d'entraînement (Loss/Accuracy), la matrice de confusion visuelle, et surtout des images comparant l'image originale, le vrai masque, et la prédiction du modèle.
  • Suivi MLflow (mlruns/) :
    • Une base de données locale MLflow stockant les hyperparamètres de l'expérience et ses métriques.

4. Prochaines Étapes : Déploiement

Gemini a également généré un fichier Next_step.md qui explique comment exploiter ces résultats dans la suite de votre projet :

  • Intégration Streamlit : Il fournit le code (boilerplate) nécessaire pour charger le best_model.keras et le class_mapping.json dans votre application app.py. Le modèle est capable de prendre une image uploadée et de renvoyer un masque segmenté coloré.
  • Déploiement sur Render : Des mises en garde importantes y sont précisées :
    • Gérer la taille du modèle (76 MB), qui passe sur Git classique mais qui, s'il était plus gros, nécessiterait Git LFS.
    • Faire attention à la limite de RAM (512 MB) du niveau gratuit de Render, TensorFlow étant très gourmand. Il est conseillé d'utiliser tensorflow-cpu dans le requirements.txt pour éviter les crashs "Out of Memory" (OOM).