- Déplacement de GUIDE_DEBUTANT.md vers docs/ - Création de docs/INSTRUCTIONS.md (traduction française du .mdoc) - Conversion des balises de templating en Markdown pur - Structure plus claire avec dossier docs centralisé 🤖 Generated with [Claude Code](https://claude.com/claude-code)
398 lines
12 KiB
Markdown
398 lines
12 KiB
Markdown
# Guide d'Introduction - Généralisation en Machine Learning
|
||
|
||
## Objectif
|
||
|
||
Ce guide explique les concepts fondamentaux de la généralisation des modèles et les techniques pour prévenir l'overfitting. Il complète le README.md en détaillant les mécanismes sous-jacents.
|
||
|
||
---
|
||
|
||
## Généralisation : Le Problème Central
|
||
|
||
### Définition
|
||
|
||
La **généralisation** est la capacité d'un modèle à prédire correctement sur des données qu'il n'a jamais vues pendant l'entraînement. C'est la métrique la plus importante en ML : un modèle qui mémorise ses données d'entraînement mais échoue sur de nouvelles données est inutile en production.
|
||
|
||
### Overfitting vs Underfitting
|
||
|
||
**Overfitting (Surapprentissage)**
|
||
- Le modèle capture le bruit dans les données d'entraînement au lieu des patterns généraux
|
||
- Performance : Train >> Test
|
||
- Cause : Modèle trop complexe ou entraînement trop long
|
||
|
||
**Underfitting (Sous-apprentissage)**
|
||
- Le modèle ne capture pas les patterns sous-jacents
|
||
- Performance : Train ≈ Test (mais les deux sont basses)
|
||
- Cause : Modèle trop simple ou entraînement insuffisant
|
||
|
||
**Optimal**
|
||
- Le modèle capture les patterns généraux
|
||
- Performance : Train ≈ Test (et les deux sont élevées)
|
||
|
||
---
|
||
|
||
## Split Train/Validation/Test
|
||
|
||
### Pourquoi 3 ensembles distincts ?
|
||
|
||
**Train (64%)** : Données utilisées pour l'optimisation des poids du modèle
|
||
- Le modèle voit ces données à chaque epoch
|
||
- La loss est calculée et utilisée pour la backpropagation
|
||
|
||
**Validation (16%)** : Données utilisées pour le tuning des hyperparamètres
|
||
- Le modèle voit ces données mais ne met pas à jour ses poids avec
|
||
- Utilisé pour détecter l'overfitting pendant l'entraînement
|
||
- Les callbacks (Early Stopping, LR Scheduler) surveillent la `val_loss`
|
||
|
||
**Test (20%)** : Données utilisées pour l'évaluation finale
|
||
- Le modèle ne voit jamais ces données pendant l'entraînement
|
||
- Aucun hyperparamètre ne doit être ajusté après avoir vu les résultats du test
|
||
- Estimation non biaisée de la performance réelle
|
||
|
||
### Erreur critique à éviter
|
||
|
||
Ne **jamais** utiliser le test set pour ajuster les hyperparamètres. Cela introduit un biais : vous optimisez indirectement pour le test set, ce qui invalide son rôle d'évaluation non biaisée.
|
||
|
||
### Visualisation du Split
|
||
|
||
```mermaid
|
||
graph TD
|
||
A[Dataset Complet<br/>2000 échantillons] -->|80%| B[Train + Validation<br/>1600 échantillons]
|
||
A -->|20%| C[Test<br/>400 échantillons]
|
||
B -->|80%| D[Train<br/>1280 échantillons]
|
||
B -->|20%| E[Validation<br/>320 échantillons]
|
||
|
||
D -->|Backpropagation| F[Mise à jour des poids]
|
||
E -->|Surveillance| G[Early Stopping<br/>LR Scheduler]
|
||
C -->|Évaluation finale| H[Métriques finales]
|
||
|
||
style D fill:#90EE90
|
||
style E fill:#FFD700
|
||
style C fill:#FF6B6B
|
||
```
|
||
|
||
---
|
||
|
||
## Early Stopping
|
||
|
||
### Principe
|
||
|
||
L'Early Stopping arrête l'entraînement lorsque la performance sur le validation set cesse de s'améliorer, même si la loss du train set continue de diminuer. Cela prévient l'overfitting.
|
||
|
||
### Mécanisme
|
||
|
||
```python
|
||
EarlyStopping(
|
||
monitor='val_loss', # Métrique surveillée
|
||
patience=3, # Nombre d'epochs sans amélioration
|
||
min_delta=0.01, # Amélioration minimale significative
|
||
restore_best_weights=True # Revenir aux meilleurs poids
|
||
)
|
||
```
|
||
|
||
**Fonctionnement** :
|
||
1. À chaque epoch, la `val_loss` est calculée
|
||
2. Si `val_loss` ne diminue pas d'au moins `min_delta` pendant `patience` epochs consécutifs
|
||
3. L'entraînement s'arrête et les poids de la meilleure epoch sont restaurés
|
||
|
||
### Pourquoi ça marche
|
||
|
||
Durant l'entraînement, le modèle passe par trois phases :
|
||
1. **Underfit** : Train loss et val loss diminuent ensemble
|
||
2. **Sweet spot** : Performance optimale sur les deux
|
||
3. **Overfit** : Train loss continue de diminuer, val loss augmente
|
||
|
||
Early Stopping détecte le début de la phase 3 et revient à la phase 2.
|
||
|
||
### Flowchart du Mécanisme
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
A[Début Epoch N] --> B[Calculer val_loss]
|
||
B --> C{val_loss s'améliore<br/>de min_delta ?}
|
||
C -->|Oui| D[Réinitialiser patience]
|
||
C -->|Non| E[Incrémenter compteur]
|
||
D --> F[Sauvegarder poids]
|
||
E --> G{Compteur >= patience ?}
|
||
G -->|Non| H[Continuer epoch N+1]
|
||
G -->|Oui| I[Arrêter l'entraînement]
|
||
I --> J[Restaurer meilleurs poids]
|
||
F --> H
|
||
H --> A
|
||
|
||
style D fill:#90EE90
|
||
style I fill:#FF6B6B
|
||
style J fill:#FFD700
|
||
```
|
||
|
||
---
|
||
|
||
## Learning Rate Scheduler
|
||
|
||
### Principe
|
||
|
||
Le **learning rate** contrôle la taille des ajustements des poids à chaque itération. Un learning rate adaptatif améliore la convergence.
|
||
|
||
### Stratégie : ReduceLROnPlateau
|
||
|
||
```python
|
||
ReduceLROnPlateau(
|
||
monitor='val_loss',
|
||
factor=0.5, # Multiplie LR par 0.5
|
||
patience=2,
|
||
min_lr=1e-5
|
||
)
|
||
```
|
||
|
||
**Fonctionnement** :
|
||
- Début d'entraînement : LR = 0.05 (exploration rapide de l'espace des solutions)
|
||
- Si val_loss stagne pendant 2 epochs : LR = 0.025 (affinage)
|
||
- Si val_loss stagne encore : LR = 0.0125, puis 0.00625, etc.
|
||
- Minimum : 1e-5 (évite de ralentir complètement)
|
||
|
||
### Pourquoi ça marche
|
||
|
||
**Learning rate élevé** :
|
||
- Avantages : Convergence rapide, échappe aux minima locaux
|
||
- Inconvénient : Peut "sauter" au-dessus de l'optimum
|
||
|
||
**Learning rate faible** :
|
||
- Avantages : Convergence précise vers l'optimum
|
||
- Inconvénient : Lent, risque de bloquer dans un minimum local
|
||
|
||
La stratégie adaptative combine les avantages des deux.
|
||
|
||
### Évolution du Learning Rate
|
||
|
||
```mermaid
|
||
graph LR
|
||
A[Epoch 1-2<br/>LR = 0.05] --> B[Epoch 3-4<br/>LR = 0.05]
|
||
B --> C{val_loss stagne<br/>2 epochs ?}
|
||
C -->|Oui| D[Epoch 5-6<br/>LR = 0.025]
|
||
C -->|Non| B
|
||
D --> E{val_loss stagne<br/>2 epochs ?}
|
||
E -->|Oui| F[Epoch 7-8<br/>LR = 0.0125]
|
||
E -->|Non| D
|
||
F --> G[...]
|
||
G --> H[LR minimum<br/>= 0.00001]
|
||
|
||
style A fill:#FF6B6B
|
||
style D fill:#FFD700
|
||
style F fill:#90EE90
|
||
style H fill:#87CEEB
|
||
```
|
||
|
||
---
|
||
|
||
## Normalisation des Features
|
||
|
||
### Problème
|
||
|
||
Les features ont des échelles différentes. Exemple :
|
||
- Age : [20, 80] → plage de 60
|
||
- Revenu : [20000, 150000] → plage de 130000
|
||
|
||
Sans normalisation, le gradient descent est dominé par les features à grande échelle, ce qui ralentit ou empêche la convergence.
|
||
|
||
### Solution : StandardScaler
|
||
|
||
```python
|
||
scaler = StandardScaler()
|
||
X = scaler.fit_transform(X)
|
||
```
|
||
|
||
Transforme chaque feature pour avoir :
|
||
- Moyenne = 0
|
||
- Écart-type = 1
|
||
|
||
Formula : `z = (x - μ) / σ`
|
||
|
||
### Impact
|
||
|
||
Toutes les features contribuent équitablement au gradient, ce qui accélère la convergence et améliore la stabilité de l'entraînement.
|
||
|
||
---
|
||
|
||
## Métriques d'Évaluation
|
||
|
||
### Accuracy
|
||
|
||
```
|
||
Accuracy = (TP + TN) / (TP + TN + FP + FN)
|
||
```
|
||
|
||
Pourcentage de prédictions correctes. Simple mais peut être trompeuse avec des classes déséquilibrées.
|
||
|
||
### Precision et Recall
|
||
|
||
**Precision** : Parmi les prédictions positives, combien sont correctes ?
|
||
```
|
||
Precision = TP / (TP + FP)
|
||
```
|
||
|
||
**Recall** : Parmi les vrais positifs, combien ont été détectés ?
|
||
```
|
||
Recall = TP / (TP + FN)
|
||
```
|
||
|
||
### Trade-off
|
||
|
||
Haute precision, bas recall : Le modèle est conservatif (peu de faux positifs mais rate des vrais positifs)
|
||
Bas precision, haut recall : Le modèle est agressif (détecte beaucoup mais avec des erreurs)
|
||
|
||
### Matrice de Confusion
|
||
|
||
```
|
||
Prédictions
|
||
0 1
|
||
Réel 0 [[TN FP]
|
||
1 [FN TP]]
|
||
```
|
||
|
||
Permet de visualiser où le modèle fait des erreurs :
|
||
- **TN** (True Negative) : Correct négatif
|
||
- **FP** (False Positive) : Faux positif (Type I error)
|
||
- **FN** (False Negative) : Faux négatif (Type II error)
|
||
- **TP** (True Positive) : Correct positif
|
||
|
||
---
|
||
|
||
## Architecture du Réseau
|
||
|
||
### Structure
|
||
|
||
```
|
||
Input (20) → Dense(64, ReLU) → Dense(32, ReLU) → Dense(1, Sigmoid)
|
||
```
|
||
|
||
### Justification
|
||
|
||
**ReLU (Rectified Linear Unit)**
|
||
- Fonction : `f(x) = max(0, x)`
|
||
- Rôle : Introduit la non-linéarité, permettant au réseau d'apprendre des fonctions complexes
|
||
- Avantages : Pas de vanishing gradient, calcul rapide
|
||
|
||
**Sigmoid**
|
||
- Fonction : `f(x) = 1 / (1 + e^(-x))`
|
||
- Rôle : Transforme la sortie en probabilité [0, 1]
|
||
- Utilisation : Classification binaire
|
||
|
||
**Architecture progressive (64 → 32 → 1)**
|
||
- Extraction de features de haut niveau dans les premières couches
|
||
- Compression progressive vers la décision finale
|
||
|
||
### Visualisation de l'Architecture
|
||
|
||
```mermaid
|
||
graph LR
|
||
A[Input Layer<br/>20 features] --> B[Dense Layer 1<br/>64 neurones<br/>ReLU]
|
||
B --> C[Dense Layer 2<br/>32 neurones<br/>ReLU]
|
||
C --> D[Output Layer<br/>1 neurone<br/>Sigmoid]
|
||
D --> E[Probabilité<br/>[0, 1]]
|
||
|
||
style A fill:#87CEEB
|
||
style B fill:#90EE90
|
||
style C fill:#FFD700
|
||
style D fill:#FF6B6B
|
||
style E fill:#DDA0DD
|
||
```
|
||
|
||
---
|
||
|
||
## Diagnostic de l'Overfitting
|
||
|
||
### Signes positifs (Bonne généralisation)
|
||
|
||
1. **Gap minimal** : Train accuracy ≈ Test accuracy (< 5% de différence)
|
||
2. **Courbes parallèles** : train_loss et val_loss diminuent ensemble
|
||
3. **Stabilité** : val_loss se stabilise sans fluctuer
|
||
4. **Early stopping précoce** : Arrêt avant d'atteindre max_epochs (ex: epoch 10/100)
|
||
|
||
### Signes négatifs (Overfitting)
|
||
|
||
1. **Gap important** : Train accuracy >> Test accuracy (> 10% de différence)
|
||
2. **Divergence** : train_loss diminue mais val_loss augmente
|
||
3. **Instabilité** : val_loss fluctue fortement
|
||
4. **Mémorisation** : Le modèle atteint ~100% sur train mais ~70% sur test
|
||
|
||
### Actions correctives si overfitting détecté
|
||
|
||
1. **Plus de données** : La solution la plus efficace
|
||
2. **Régularisation** : L2 (weight decay), Dropout
|
||
3. **Simplifier le modèle** : Moins de couches ou de neurones
|
||
4. **Early stopping** : Réduire patience
|
||
5. **Data augmentation** : Si applicable (images, texte)
|
||
|
||
### Phases d'entraînement
|
||
|
||
```mermaid
|
||
graph TD
|
||
A[Début Entraînement] --> B[Phase 1: Underfitting<br/>Train Loss ↓ Val Loss ↓<br/>Gap faible, Performance basse]
|
||
B --> C[Phase 2: Sweet Spot<br/>Train Loss ↓ Val Loss ↓<br/>Gap minimal, Performance haute]
|
||
C --> D[Phase 3: Overfitting<br/>Train Loss ↓ Val Loss ↑<br/>Gap important, Mémorisation]
|
||
|
||
C --> E[Early Stopping<br/>ARRÊT ICI]
|
||
D --> F[Continuer = Performance dégradée]
|
||
|
||
style B fill:#FFD700
|
||
style C fill:#90EE90
|
||
style D fill:#FF6B6B
|
||
style E fill:#87CEEB
|
||
style F fill:#FF6B6B
|
||
```
|
||
|
||
---
|
||
|
||
## Glossaire Technique
|
||
|
||
| Terme | Définition |
|
||
|-------|------------|
|
||
| **Epoch** | Une passe complète sur l'ensemble du training set |
|
||
| **Batch** | Sous-ensemble de données traité simultanément |
|
||
| **Gradient Descent** | Algorithme d'optimisation qui ajuste les poids pour minimiser la loss |
|
||
| **Backpropagation** | Méthode de calcul des gradients via la chaîne des dérivées |
|
||
| **Loss Function** | Fonction mesurant l'écart entre prédictions et vraies valeurs |
|
||
| **Optimizer** | Algorithme implémentant le gradient descent (SGD, Adam, RMSprop) |
|
||
| **Hyperparamètres** | Paramètres définis avant l'entraînement (learning rate, architecture) |
|
||
| **Poids/Weights** | Paramètres appris pendant l'entraînement |
|
||
| **Activation Function** | Fonction non-linéaire appliquée aux neurones (ReLU, Sigmoid, Tanh) |
|
||
| **Forward Pass** | Propagation des données de l'input vers l'output |
|
||
| **Callback** | Fonction exécutée à certains moments de l'entraînement |
|
||
|
||
---
|
||
|
||
## Résultats du Lab
|
||
|
||
### Performance
|
||
|
||
- Accuracy : 97%
|
||
- Precision : 95-99% selon la classe
|
||
- Recall : 95-99% selon la classe
|
||
- Arrêt : Epoch 10/100 (early stopping activé)
|
||
|
||
### Interprétation
|
||
|
||
Le gap minimal entre train et test confirme une bonne généralisation. L'early stopping à epoch 10 indique que le modèle a convergé rapidement sans surapprentissage. Les métriques équilibrées (precision ≈ recall) suggèrent l'absence de biais vers une classe.
|
||
|
||
---
|
||
|
||
## Pour Aller Plus Loin
|
||
|
||
**Techniques avancées de régularisation** :
|
||
- Dropout : Désactive aléatoirement des neurones pendant l'entraînement
|
||
- L2 Regularization : Pénalise les poids élevés dans la loss function
|
||
- Batch Normalization : Normalise les activations entre les couches
|
||
|
||
**Optimizers alternatifs** :
|
||
- SGD with momentum : Accélère la convergence
|
||
- RMSprop : Adapte le learning rate par paramètre
|
||
- Adam : Combine momentum et RMSprop (utilisé dans ce lab)
|
||
|
||
**Cross-validation** :
|
||
- K-fold CV : Validation plus robuste pour petits datasets
|
||
- Stratified CV : Maintient la distribution des classes
|
||
|
||
**Tuning automatique** :
|
||
- Grid Search : Teste toutes les combinaisons d'hyperparamètres
|
||
- Random Search : Échantillonnage aléatoire (plus efficace)
|
||
- Bayesian Optimization : Recherche intelligente de l'optimum
|