Amazon MLS-C01: Séries temporelles et prévision — Guide d'étude

By Laurynas Brazys · 26 July 2026 · #amazon #mls-c01 #certification #exam-prep #study-guide

Fait partie du AWS Machine Learning Specialty MLS-C01 — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Amazon, ou passez des tests chronométrés sur ExamRoll.io.

Sélection de l’algorithme et quand utiliser chaque approche

Le choix du bon modèle de prévision commence par la forme des données et l’objectif. Les approches univariées classiques telles que ARIMA/SARIMA restent le bon choix lorsque vous avez une seule série bien structurée avec un long historique et des termes saisonniers interprétables ; vous pouvez les implémenter dans un script d’entraînement SageMaker en utilisant statsmodels ou mener des expériences de manière interactive dans SageMaker Studio. Les modèles décomposables de type Prophet sont précieux lorsque les effets des jours fériés liés à l’activité et les saisonnalités multiples (quotidienne/hebdomadaire/annuelle) doivent être modélisés et interprétés explicitement ; ceux-ci sont souvent prototypés dans des notebooks et peuvent être mis en production dans SageMaker. Pour la prévision probabiliste multi-séries à grande échelle, utilisez DeepAR (algorithme intégré de SageMaker ou DeepAR+ d’Amazon Forecast) qui apprend à travers des séries temporelles liées et produit des prévisions par quantiles. Les choix de configuration importants incluent le réglage de time_freq, prediction_length et context_length (context_length doit généralement être >= prediction_length), le choix d’une vraisemblance appropriée (studentT pour les queues de distribution épaisses, negative-binomial pour les décomptes/la demande intermittente), et l’activation de use_feat_dynamic_real ou use_feat_static_cat pour les covariables. Utilisez les modèles classiques lorsque l’interprétabilité et les diagnostics sur une seule série sont requis ; préférez DeepAR/Amazon Forecast lorsque vous avez de nombreuses séries liées et avez besoin de sorties probabilistes calibrées et d’une mise à l’échelle intégrée.

Préparation des données : saisonnalité, covariables et valeurs manquantes

De bonnes prévisions exigent un alignement minutieux des horodatages, de la fréquence et des covariables. Normalisez toujours les horodatages sur un fuseau horaire et une fréquence cohérents (définissez time_freq pour les modèles). Capturez la saisonnalité connue et les événements commerciaux en ajoutant des indicateurs de jours fériés et des caractéristiques d’événements spéciaux en tant que covariables statiques ou dynamiques ; incluez les promotions de prix, les ouvertures de magasins ou les indicateurs de campagne en tant que caractéristiques dynamiques. Les valeurs manquantes doivent être traitées avec soin : pour les courtes interruptions, utilisez l’interpolation ou le remplissage forward/backward ; pour les interruptions plus longues, utilisez l’imputation avec des approches basées sur des modèles ou masquez-les lorsque l’algorithme prend en charge les valeurs manquantes (DeepAR accepte les caractéristiques dynamiques masquées). Pour une demande intermittente avec de nombreux zéros ou des décomptes surdispersés, utilisez la vraisemblance binomiale négative (negative-binomial), expérimentez avec l’agrégation (par exemple, hebdomadaire) pour réduire la sparsité, ou appliquez un prétraitement basé sur la méthode de Croston lorsque les méthodes classiques sont appropriées. Évitez de fuiter des informations futures dans les covariables — les caractéristiques dynamiques doivent être connues ou prévisibles pour l’horizon de prévision. Stockez les métadonnées (item_id, category, store_id) en tant que caractéristiques catégorielles statiques pour permettre aux modèles multi-séries de partager les informations entre les articles.

Évaluation : métriques probabilistes, backtesting et calibration

La prévision probabiliste nécessite des critères d’évaluation différents de ceux des prévisions ponctuelles. Utilisez la perte quantile (quantile loss ou pinball loss) et le score de probabilité classé continu (CRPS) pour évaluer la qualité de la distribution, et rapportez la couverture pour les quantiles clés (par exemple, P50, P90) afin de vérifier la calibration des intervalles. Évitez de vous fier uniquement au MAPE pour les séries avec des zéros ou une demande intermittente ; utilisez l’erreur absolue moyenne mise à l’échelle (MASE) pour une comparaison indépendante de l’échelle ou les pertes quantiles pondérées pour prioriser les références (SKU) à revenus élevés. Implémentez une validation croisée à origine mobile (séries temporelles) avec plusieurs fenêtres de backtest pour capturer l’instabilité temporelle et la saisonnalité, en veillant à ce que chaque fenêtre respecte les cycles saisonniers afin que les ensembles de validation (holdouts) contiennent des périodes saisonnières complètes. Vérifiez la calibration avec les taux de réussite des intervalles de prédiction et des histogrammes de type PIT ; si les intervalles sont trop étroits, envisagez d’augmenter num_eval_samples dans DeepAR ou d’ajuster les hypothèses de vraisemblance. Les pièges courants incluent l’utilisation de covariables connues dans le futur qui ne seront pas disponibles lors de l’inférence, l’agrégation qui élimine une saisonnalité critique, et l’évaluation sur un seul ensemble de validation statique qui ne tient pas compte des changements de régime. Agrégez les métriques par série en fonction de l’importance commerciale plutôt que par de simples moyennes pour refléter l’impact sur les décisions.

Mise à l’échelle, modèles de déploiement et critères de décision

La mise à l’échelle de la prévision pour des milliers ou des millions de séries et le déploiement des prévisions en production impliquent des compromis architecturaux. Pour une solution gérée et axée sur la mise à l’échelle, Amazon Forecast gère les groupes de jeux de données (séries temporelles cibles, séries temporelles associées, métadonnées d’articles), l’ingénierie des caractéristiques automatisée, le backtesting intégré et les prédicteurs hébergés élastiques pour les prévisions par lots ou exportables ; il est bien adapté lorsque vous souhaitez un service qui gère de nombreuses séries sans entraînement de modèle sur mesure. Pour des besoins de modélisation personnalisée, utilisez SageMaker avec DeepAR (ou des modèles PyTorch/TF personnalisés) où vous contrôlez les hyperparamètres, les choix de vraisemblance et l’ingénierie des caractéristiques ; entraînez sur des instances GPU pour la vitesse et utilisez SageMaker Batch Transform pour l’inférence en masse ou des points de terminaison en temps réel pour un service à faible latence. Pour une meilleure rentabilité avec de nombreuses versions de modèles, envisagez des points de terminaison multi-modèles ou des pipelines de traitement par lots asynchrones déclenchés par des événements S3 ou des Step Functions. Les critères de décision incluent le besoin d’architectures personnalisées (choisissez SageMaker), le besoin d’apprentissage sur plusieurs séries avec un minimum d’opérations (choisissez Forecast), et la nécessité de prédictions sur une seule série à faible latence (privilégiez les points de terminaison en temps réel de SageMaker). Pièges courants : sous-provisionner context_length, mal configurer les sorties de quantiles, et ne pas pondérer l’évaluation par l’impact métier.

Problème pratique : Scénario de cas d’usage

Scénario : Acme Retail exploite 5 000 magasins et conserve les journaux quotidiens des ventes et des promotions dans Amazon S3. Ils utilisent SageMaker Studio pour la science des données et ont besoin de prévisions de production évolutives pour piloter les stocks et les promotions.

Défi : Produire des prévisions de demande probabilistes calibrées à 30 jours par paire SKU-magasin qui tiennent compte des jours fériés et des promotions, gèrent les ventes nulles intermittentes pour de nombreux SKU, et peuvent être mises à l’échelle pour une production nocturne par lots.

Approche recommandée :

1. Configurer les pipelines de données : ingérer les ventes et promotions quotidiennes dans S3, les cataloguer avec AWS Glue et les exposer via Athena ; créer des fichiers de jeu de données avec timestamp, item_id, store_id, target_value et des caractéristiques dynamiques.
2. Prototyper les modèles dans SageMaker Studio : essayer une décomposition de type Prophet pour quelques SKU représentatifs, puis entraîner SageMaker DeepAR (définir time_freq='D', prediction_length=30, context_length=30–90, likelihood='negative-binomial' pour les décomptes, num_eval_samples=100).
3. Pour la mise à l’échelle et la production : planifier un entraînement nocturne par lots ou un réentraînement incrémentiel dans SageMaker (ou utiliser optionnellement Amazon Forecast avec des groupes de jeux de données et des prédicteurs si vous préférez des prévisions gérées), et utiliser SageMaker Batch Transform ou l’exportation par lots de Forecast pour l’inférence en masse nocturne.
4. Évaluer avec des backtests à origine mobile en utilisant la perte de quantile et les métriques de couverture (P50/P90), et surveiller la calibration en direct ; si les intervalles sous-estiment la couverture, ajuster la vraisemblance ou augmenter num_eval_samples.

Justification : L’utilisation de Glue/Athena et S3 standardise l’accès aux données, DeepAR (ou Forecast) modélise nativement de nombreuses séries associées et produit les quantiles nécessaires aux décisions de stock, la loi binomiale négative gère les décomptes intermittents, et la transformation par lots permet une mise à l’échelle nocturne rentable.

← Traitement du langage naturel et parole · Tous les domaines · Entraînement →

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →

Parcourir Amazon →