Habr AI et Spar : comment tester des systèmes de ML quand les données dérivent et cassent les prévisions

Habr AI a publié un guide pratique pour tester les systèmes de ML—non pas en théorie, mais sur un projet en direct de commande automatique pour la chaîne de distribution Spar. L'auteur démontre que ces produits ne se cassent pas seulement dans les modèles eux-mêmes : les erreurs se cachent dans les données, la saisonnalité, les intégrations et même dans la sélection des métriques.

Pourquoi C'est Difficile

En QA classique, vous pouvez prendre les exigences, préparer les cas de test et comparer le résultat réel avec le résultat attendu. En ML, cette approche ne fonctionne que partiellement. Le modèle ne produit pas une "bonne réponse" selon une règle rigide ; il construit une prévision probabiliste.

Ainsi, le testeur ne vérifie pas un nombre spécifique, mais une plage d'erreur acceptable, la robustesse sur différentes tranches de données et l'impact d'une erreur sur l'entreprise. La complexité est amplifiée par le fait que l'objet testé n'est pas seulement du code. Si un modèle a été entraîné sur des données incomplètes, sales ou obsolètes, un bon algorithme produira toujours de mauvais résultats.

Pour le commerce de détail, c'est particulièrement critique : la demande change en raison de la météo, des vacances, des événements locaux et des nouvelles habitudes d'achat des clients. Ce qui fonctionnait précisément hier peut échouer systématiquement demain en raison de la dérive des données et des changements du comportement réel des clients.

Comment Ils Construisent le Contrôle

Dans le cas de Spar, l'équipe s'est éloignée de l'idée de "trouver une bonne réponse" et s'est appuyée sur des métriques techniques et commerciales. Au stade des exigences, ils conviennent d'abord de ce qui constitue une qualité acceptable : par exemple, de combien une prévision par catégorie peut s'écarter des résultats réels sans dommage réel aux ventes et aux amortissements. Ensuite, les tests sont construits autour de plages plutôt que de pass/fail binaire. En parallèle, ils vérifient non seulement les scénarios normaux, mais aussi les données anormales qui ne devraient pas casser la prévision. En pratique, le contrôle est assemblé à partir de plusieurs couches :

• versions fixes des bibliothèques et containerisation via Docker ;
• anonymisation des données pour utiliser des ventes réalistes sans fuite d'informations personnelles ;
• tests ciblés dans différents magasins, formats et catégories de produits, pas seulement les métriques moyennes ;
• régression du nouveau modèle par rapport à l'ancien pour que l'amélioration d'une métrique ne casse pas les autres ;
• surveillance de l'infrastructure et des échanges de données nocturnes, car l'entreprise a besoin de prévisions non seulement précises mais aussi opportunes.

Une conclusion séparée de l'article est que tester ML "en moyenne à l'hôpital" est inutile. Un modèle peut bien paraître sur le chocolat mais échouer sur une marque spécifique, compter le pain avec précision tout en se trompant simultanément sur les sauces. Donc les tests vont plus loin : par catégorie, par niveaux de détail et par un échantillon représentatif de magasins. Cette approche coûte plus cher, mais elle fournit une image réelle avant le lancement plutôt qu'après les plaintes du métier.

Pannes en Production

La partie la plus instructive du matériau est les vrais défaillances. Dans un cas, l'équipe a confondu deux paramètres presque identiques d'un algorithme saisonnier : prediction_share et predict_share. C'était suffisant pour que le système surévalue drastiquement la prévision pour le beurre, la crème sure et le fromage blanc.

Des produits laitiers excédentaires sont arrivés dans les magasins, et une partie de l'inventaire a dû être rapidement remisée en raison de la courte durée de conservation. L'erreur était petite au niveau du code, mais chère au niveau du métier opérationnel. Il y avait aussi le cas inverse—une sous-estimation pour le lavash après le lancement.

La saisonnalité hebdomadaire a commencé à être calculée incorrectement, et le pic de demande "s'est déplacé" des fins de semaine vers le milieu de la semaine. En raison des faibles volumes de ventes, le problème n'a pas été remarqué immédiatement, mais pour les clients, l'effet était simple : le produit disparaissait des rayons exactement quand ils en avaient besoin. Une autre panne s'est produite au début de 2025 : le modèle a mal interprété le champ year et essentiellement "n'a pas compris" qu'une nouvelle année était arrivée, et le système de détection d'anomalies ne l'a pas détecté.

La conclusion est dure : ML doit être testé non seulement sur des données connues, mais aussi sur des périodes futures, de nouvelles plages de valeurs et des défaillances des mécanismes de protection.

Ce Que Cela Signifie

L'article de Habr AI démontre clairement un changement dans la manière dont le QA pour ML est compris. Ici, exécuter des cas de test contre le code ne suffit pas : vous avez besoin d'une combinaison de métriques, de données, de surveillance et de contexte métier. Pour les équipes qui déploient des prévisions dans le commerce de détail, la logistique ou la fintech, ce n'est plus une discipline supplémentaire, mais une couche obligatoire de protection contre les erreurs coûteuses et silencieuses.