Déployer un nouveau modèle de machine learning directement à 100% du trafic est une recette pour le désastre. La performance offline ne garantit jamais le comportement en production. Pour dérisquer ce processus, trois stratégies de déploiement progressives sont essentielles. Elles permettent d’observer, de mesurer et de valider un nouveau modèle dans des conditions réelles avant de l’exposer à tous les utilisateurs.
prérequis
- Un routeur de trafic (API Gateway, service mesh comme Istio) capable de diriger les requêtes vers différentes versions de modèles.
- Une journalisation (logging) centralisée qui capture chaque requête, la version du modèle qui a répondu, et la réponse elle-même.
- Des métriques de performance (latence, taux d’erreur) et de qualité métier (taux de clic, conversion, etc.) clairement définies.
idées clefs
Le déploiement d’un modèle est un processus scientifique, pas un acte de foi. Il repose sur des principes de validation continue.
pas à pas
étape 1: le canary, pour la sécurité technique
Le but du canary est de vérifier que le nouveau modèle (v2) ne casse rien sur le plan technique (bugs, latence, erreurs) avec un impact limité. On lui envoie une petite fraction du trafic réel.
# Exemple de configuration de routage de trafic (ex: Istio)
# 95% du trafic va vers le modèle v1, 5% vers le nouveau modèle v2.
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
spec:
hosts:
- model-serving-api
http:
- route:
- destination:
host: model-serving-api
subset: v1
weight: 95
- destination:
host: model-serving-api
subset: v2
weight: 5
étape 2: le shadow, pour la comparaison fonctionnelle
Le mode shadow (ou “miroir”) permet de tester le modèle v2 sur 100% du trafic de production sans qu’il n’ait d’impact. Le trafic est envoyé au modèle v1 (qui retourne la réponse à l’utilisateur), et une copie de ce trafic est envoyée en parallèle au modèle v2. On compare ensuite les prédictions et la latence des deux versions.
étape 3: l’a/b test, pour la mesure de valeur
Une fois la stabilité technique et fonctionnelle validée, l’A/B test mesure si le modèle v2 est réellement meilleur que le v1 sur des métriques métier. Le trafic est divisé en deux groupes, chacun voyant une seule version. On compare ensuite les résultats business des deux groupes.
-- Requête pour comparer le taux de conversion entre les deux versions
SELECT
model_variant, -- 'v1' ou 'v2'
COUNT(DISTINCT user_id) AS users,
COUNT(DISTINCT CASE WHEN converted = true THEN user_id END) AS converted_users,
ROUND(100.0 * converted_users / users, 2) AS conversion_rate
FROM
experiment_outcomes
WHERE
experiment_name = 'new_recommendation_model_202212'
GROUP BY 1;
erreurs courantes et solutions
-
Symptôme: On déploie un nouveau modèle directement à 100% et le site tombe en panne.
- Cause: Pas de déploiement progressif.
- Correctif: Toujours commencer par un canary, même à 1% du trafic, pour valider la stabilité technique.
-
Symptôme: On a déployé un nouveau modèle mais on ne sait pas s’il est meilleur que l’ancien.
- Cause: Absence de mesure d’impact.
- Correctif: Mettre en place un A/B test avec des KPIs métier clairs. La performance offline (AUC, F1-score) ne suffit pas.
-
Symptôme: Un nouveau modèle a un problème, et il faut 2 heures pour revenir en arrière.
- Cause: Pas de plan de rollback.
- Correctif: Le processus de rollback doit être documenté et automatisé. Il doit s’agir d’une commande unique pour rebasculer 100% du trafic sur l’ancienne version stable.
faq
-
Quelle stratégie choisir ? Elles ne sont pas mutuellement exclusives, elles sont complémentaires et séquentielles. Un déploiement mature suit souvent cet ordre : Canary (pour la sécurité) -> Shadow (pour la parité technique) -> A/B Test (pour la valeur métier).
-
Combien de temps doit durer chaque étape ? Ça dépend. Un canary peut durer quelques heures, le temps de détecter des erreurs techniques. Un A/B test doit durer assez longtemps pour atteindre la significativité statistique, ce qui peut prendre de quelques jours à plusieurs semaines.