Savoir quand le jeu de données est prêt

Les huit vérifications#

La liste de contrôle regroupe en une seule décision go/no-go les mêmes points que le guide de collecte et d’annotation des données aborde un par un.

Automatiser les vérifications quantifiables#

Les vérifications 4, 7 et 8 reposent sur des calculs ; un script les évalue donc de la même façon à chaque fois. Celui-ci lit le jeu de pratique et les listes de découpages générés par group_split.py dans la leçon précédente :

from collections import Counter
from pathlib import Path

root = Path("datasets/practice")  # images/, labels/, and the train/val/test.txt lists from group_split.py
splits = {s: [Path(p).stem for p in (root / f"{s}.txt").read_text().split()] for s in ("train", "val", "test")}

def classes(stem):
    label = root / "labels" / f"{stem}.txt"
    return [int(r.split()[0]) for r in label.read_text().splitlines() if r.strip()] if label.exists() else []

stems = [s for split in splits.values() for s in split]
instances = Counter(c for s in stems for c in classes(s))
images = Counter(c for s in stems for c in set(classes(s)))
background = sum(not classes(s) for s in stems) / len(stems)
groups = {split: {s.rsplit("_", 1)[0] for s in names} for split, names in splits.items()}
per_split = {split: {c for s in names for c in classes(s)} for split, names in splits.items()}
shared = (groups["train"] & groups["val"]) | (groups["train"] & groups["test"]) | (groups["val"] & groups["test"])
weakest = min(instances, key=lambda c: (images[c], instances[c]))

checks = {
    "4 volume": (images[weakest] >= 1500 and instances[weakest] >= 10_000,
                 f"weakest class {weakest}: {images[weakest]} images, {instances[weakest]} instances"),
    "7 no shared groups": (not shared, f"{len(shared)} groups appear in more than one split"),
    "7 every class in every split": (all(per_split[s] == set(instances) for s in splits),
                                     ", ".join(f"{s} misses {len(set(instances) - per_split[s])}" for s in splits)),
    "8 background 0-10%": (background <= 0.10, f"{background:.1%} background images"),
}
for name, (ok, detail) in checks.items():
    print(f"{'PASS' if ok else 'FAIL'}  {name:<29} {detail}")

FAIL  4 volume                      weakest class 30: 1 images, 1 instances
PASS  7 no shared groups            0 groups appear in more than one split
FAIL  7 every class in every split  train misses 5, val misses 36, test misses 41
PASS  8 background 0-10%            1.6% background images

Le découpage par groupes a corrigé la fuite, mais le jeu de pratique est loin d’être prêt : sa classe la plus faible (30, skis) ne compte qu’une seule instance annotée, et l’évaluation ne peut pas mesurer la moitié des classes. C’est le verdict attendu pour 128 images de démonstration, et précisément celui que cette vérification doit fournir avant une semaine d’entraînement.

Décider : entraîner, livrer malgré une lacune ou corriger#

Lorsqu’une vérification échoue, l’étape suivante tentante consiste presque toujours à faire autre chose que corriger les données :

Trois situations où le jeu de données est presque prêt#

Déploie en connaissant les lacunes#

Souvent, le bon choix consiste à créer un premier modèle ciblé avant que tous les contrôles soient au vert : un pilote, un prototype ou une v1 sur un sous-ensemble de caméras. Un modèle en production révèle plus vite les vrais problèmes que le peaufinage des données dans le noir. Si tu déploies avec une lacune, consigne trois choses :

• Le contrôle qui a échoué.
• L'impact attendu, par exemple « aucune donnée de nuit ; attends-toi à un rappel plus faible après la tombée de la nuit ».
• Le plan de collecte qui permettra de combler la lacune pendant l'exécution de la v1.

Relance les contrôles avant chaque nouvel entraînement#

Un jeu de données prêt pour la v1 n'est pas automatiquement prêt pour la v3. De nouvelles classes, de nouvelles sources et de nouveaux annotateurs peuvent chacun faire échouer un contrôle qui réussissait auparavant, tandis que les données de production dérivent à mesure que les nouvelles annotations s'accumulent. Relance readiness.py et réévalue les contrôles manuels avant chaque nouvel entraînement ; cela prend quelques minutes, et sauter cette étape peut te coûter une semaine d'entraînement sur un jeu de données défectueux.