La méthode de design (et le feature store)

Le canevas en 6 étapes

Face à « concevez un système de X », déroule toujours :

1. Cadrer le produit : quelle décision, pour qui, à quelle fréquence, avec quel coût d'erreur ? (le seuil précision/rappel est un choix produit — module 5) ;
2. Formuler le ML : classification ? ranking ? régression ? Quel label, disponible quand (feedback delay !) ;
3. Données & features : sources, fraîcheur nécessaire, volumétrie ;
4. Modèle : baseline d'abord (règles ! popularité !), puis le modèle justifié ;
5. Serving : batch ou online (module 8.2), budget latence, échelle ;
6. Boucle de vie : monitoring, drift, réentraînement, A/B test.

L'erreur d'entretien classique : sauter à l'étape 4. Les intervieweurs (et la réalité) valorisent 1, 3 et 6.

Le piège structurel : le train/serve skew

Tes features d'entraînement sont calculées en SQL sur l'entrepôt (batch, module 4). En prod, l'API doit calculer les mêmes en 10 ms. Deux implémentations de « total dépensé sur 30 jours » = deux sémantiques qui divergent un jour ou l'autre → le modèle reçoit en prod des features différentes de celles de son entraînement. C'est le train/serve skew, cause majeure de « ça marchait en offline ».

Le feature store (Feast et cousins) résout ça : définition unique de chaque feature, matérialisée deux fois — en batch vers l'entrepôt (entraînement) et en online vers un KV rapide (Redis) pour le serving. Même code, deux vitesses.

Les chiffres à avoir en tête (ordres de grandeur)

• Lookup Redis : < 1 ms | inférence boosting : ~1-5 ms | petit réseau : ~5-20 ms | LLM : 100 ms-5 s ;
• Budget latence type d'une page produit : 100-200 ms tout compris → la reco a droit à ~30 ms ;
• D'où le pattern dominant : précalculer un maximum (candidats, embeddings) et ne garder en ligne que le scoring léger.