Prévision de série chronologique (fonctions optimisées par ML Snowflake Cortex)¶

À propos de l’algorithme de prévision¶

L’algorithme de prévision est alimenté par une machine de renforcement du gradient (GBM). Comme un modèle ARIMA , il utilise une transformation de différenciation pour modéliser les données avec une tendance non stationnaire et utilise des temps de latence auto-régressifs des données cibles historiques comme variables du modèle.

En outre, l’algorithme utilise les moyennes glissantes des données cibles historiques pour aider à prédire les tendances et produit automatiquement des variables de calendrier cyclique (telles que le jour de la semaine et la semaine de l’année) à partir des données d’horodatage.

Vous pouvez ajuster des modèles avec uniquement des données historiques sur la cible et d’horodatage, ou vous pouvez inclure des données exogènes (variables) qui pourraient avoir influencé la valeur cible. Les variables exogènes peuvent être numériques ou catégorielles et peuvent être NULL (les lignes contenant des valeurs NULLs pour les variables exogènes ne sont pas supprimées).

L’algorithme ne repose pas sur l’encodage « one-hot » lors de l’entraînement sur des variables catégorielles, ce qui vous permet d’utiliser des données catégorielles comportant de nombreuses dimensions (cardinalité élevée).

Si votre modèle intègre des variables exogènes, vous devez, lors de la génération d’une prévision, fournir des valeurs pour ces variables à chaque horodatage de l’horizon prévisionnel complet. Les variables exogènes appropriées peuvent inclure des données météorologiques (température, précipitations), des informations spécifiques à l’entreprise (congés historiques et planifiés, campagnes publicitaires, programmes d’événements) ou tout autre facteur externe qui, selon vous, peut aider à prédire votre variable cible.

Cet algorithme génère également des intervalles de prédiction, en plus des prévisions. Un intervalle de prédiction est une plage estimée de valeurs comprises entre une limite supérieure et une limite inférieure dans laquelle un certain pourcentage de données est susceptible de se situer. Par exemple, une valeur de 0,95 signifie que 95 % des données sont susceptibles d’apparaître dans l’intervalle. Vous pouvez spécifier un pourcentage d’intervalle de prédiction ou utiliser la valeur par défaut, qui est de 0,95. Les limites inférieures et supérieures de l’intervalle de prédiction sont renvoyées dans le cadre de la sortie de prévision.

Préparer les prévisions¶

Avant de pouvoir utiliser les prévisions, vous devez…

• Sélectionner un entrepôt virtuel dans lequel vous entraînerez et exécuterez vos modèles.

• Attribuer les privilèges nécessaires à la création d’objets de prévision.

Vous pourriez également vouloir modifier votre chemin de recherche pour inclure SNOWFLAKE.ML.

USE ROLE admin;
GRANT USAGE ON admin_db TO ROLE analyst;
GRANT USAGE ON admin_schema TO ROLE analyst;
GRANT CREATE SNOWFLAKE.ML.FORECAST ON SCHEMA admin_db.admin_schema TO ROLE analyst;

USE ROLE analyst;
USE SCHEMA admin_db.admin_schema;

USE ROLE analyst;
CREATE SCHEMA analyst_db.analyst_schema;
USE SCHEMA analyist_db.analyist_schema;

REVOKE CREATE SNOWFLAKE.ML.FORECAST ON SCHEMA admin_db.admin_schema FROM ROLE analyst;

Configuration des données pour les exemples¶

L’exemple ci-dessous crée deux tables. Des vues de ces tables sont incluses dans les exemples plus loin dans cette rubrique.

La table sales_data contient des données sur les ventes. Chaque vente comprend un ID de magasin, un identificateur d’article, un horodatage et le montant de la vente. Les variables exogènes ou externes (température, humidité et vacances) sont également incluses.

La table future_features contient les valeurs futures des variables exogènes, qui sont nécessaires pour établir des prévisions avec de telles variables.

CREATE OR REPLACE TABLE sales_data (store_id NUMBER, item VARCHAR, date TIMESTAMP_NTZ,
  sales FLOAT, temperature NUMBER, humidity FLOAT, holiday VARCHAR);

INSERT INTO sales_data VALUES
  (1, 'jacket', TO_TIMESTAMP_NTZ('2020-01-01'), 2.0, 50, 0.3, 'new year'),
  (1, 'jacket', TO_TIMESTAMP_NTZ('2020-01-02'), 3.0, 52, 0.3, NULL),
  (1, 'jacket', TO_TIMESTAMP_NTZ('2020-01-03'), 4.0, 54, 0.2, NULL),
  (1, 'jacket', TO_TIMESTAMP_NTZ('2020-01-04'), 5.0, 54, 0.3, NULL),
  (1, 'jacket', TO_TIMESTAMP_NTZ('2020-01-05'), 6.0, 55, 0.2, NULL),
  (1, 'jacket', TO_TIMESTAMP_NTZ('2020-01-06'), 7.0, 55, 0.2, NULL),
  (1, 'jacket', TO_TIMESTAMP_NTZ('2020-01-07'), 8.0, 55, 0.2, NULL),
  (1, 'jacket', TO_TIMESTAMP_NTZ('2020-01-08'), 9.0, 55, 0.2, NULL),
  (1, 'jacket', TO_TIMESTAMP_NTZ('2020-01-09'), 10.0, 55, 0.2, NULL),
  (1, 'jacket', TO_TIMESTAMP_NTZ('2020-01-10'), 11.0, 55, 0.2, NULL),
  (1, 'jacket', TO_TIMESTAMP_NTZ('2020-01-11'), 12.0, 55, 0.2, NULL),
  (1, 'jacket', TO_TIMESTAMP_NTZ('2020-01-12'), 13.0, 55, 0.2, NULL),
  (2, 'umbrella', TO_TIMESTAMP_NTZ('2020-01-01'), 2.0, 50, 0.3, 'new year'),
  (2, 'umbrella', TO_TIMESTAMP_NTZ('2020-01-02'), 3.0, 52, 0.3, NULL),
  (2, 'umbrella', TO_TIMESTAMP_NTZ('2020-01-03'), 4.0, 54, 0.2, NULL),
  (2, 'umbrella', TO_TIMESTAMP_NTZ('2020-01-04'), 5.0, 54, 0.3, NULL),
  (2, 'umbrella', TO_TIMESTAMP_NTZ('2020-01-05'), 6.0, 55, 0.2, NULL),
  (2, 'umbrella', TO_TIMESTAMP_NTZ('2020-01-06'), 7.0, 55, 0.2, NULL),
  (2, 'umbrella', TO_TIMESTAMP_NTZ('2020-01-07'), 8.0, 55, 0.2, NULL),
  (2, 'umbrella', TO_TIMESTAMP_NTZ('2020-01-08'), 9.0, 55, 0.2, NULL),
  (2, 'umbrella', TO_TIMESTAMP_NTZ('2020-01-09'), 10.0, 55, 0.2, NULL),
  (2, 'umbrella', TO_TIMESTAMP_NTZ('2020-01-10'), 11.0, 55, 0.2, NULL),
  (2, 'umbrella', TO_TIMESTAMP_NTZ('2020-01-11'), 12.0, 55, 0.2, NULL),
  (2, 'umbrella', TO_TIMESTAMP_NTZ('2020-01-12'), 13.0, 55, 0.2, NULL);

-- future values for exogenous variables (additional features)
CREATE OR REPLACE TABLE future_features (store_id NUMBER, item VARCHAR,
  date TIMESTAMP_NTZ, temperature NUMBER, humidity FLOAT, holiday VARCHAR);

INSERT INTO future_features VALUES
  (1, 'jacket', TO_TIMESTAMP_NTZ('2020-01-13'), 52, 0.3, NULL),
  (1, 'jacket', TO_TIMESTAMP_NTZ('2020-01-14'), 53, 0.3, NULL),
  (2, 'umbrella', TO_TIMESTAMP_NTZ('2020-01-13'), 52, 0.3, NULL),
  (2, 'umbrella', TO_TIMESTAMP_NTZ('2020-01-14'), 53, 0.3, NULL);

Entraînement, utilisation, vue, suppression et mise à jour des modèles¶

Utilisez CREATE SNOWFLAKE.ML.FORECAST pour créer et entraîner un modèle. Le modèle est entraîné sur l’ensemble de données que vous fournissez.

CREATE SNOWFLAKE.ML.FORECAST <name>(...);

Voir FORECAST pour plus de détails sur le constructeur SNOWFLAKE.ML.FORECAST. Pour des exemples de création d’un modèle, consultez Exemples.

Pour générer une prévision, appelez la méthode <nom>!FORECAST du modèle :

CALL <name>!FORECAST(...)

Pour voir la liste de vos modèles, utilisez la commande SHOW SNOWFLAKE.ML.FORECAST :

SHOW SNOWFLAKE.ML.FORECAST;

Pour supprimer un modèle, utilisez la commande DROP SNOWFLAKE.ML.FORECAST :

DROP SNOWFLAKE.ML.FORECAST <name>;

Pour mettre à jour un modèle, supprimez-le et entraînez-en un nouveau. Les modèles sont immuables et ne peuvent pas être mis à jour sur place.

Produire des prévisions¶

Après avoir créé votre modèle, vous pouvez produire une prévision à l’aide de name!FORECAST(...). Vous pouvez créer des prévisions à partir de plusieurs ensembles de données en utilisant le même modèle.

Les exemples suivants démontrent comment créer des modèles et produire des prévisions à partir de ceux-ci ; consultez <nom>!FORECAST pour obtenir plus de détails sur tous les paramètres.

Consultez FORECAST pour obtenir des informations sur les paramètres utilisés lors de la création et de l’utilisation d’un modèle.

Exemples¶

Les exemples suivants illustrent l’utilisation des prévisions de séries temporelles dans différents cas de figure.

CREATE OR REPLACE VIEW v1 AS SELECT date, sales
  FROM sales_data WHERE store_id=1 AND item='jacket';
SELECT * FROM v1;

+-------------------------+-------+
| DATE                    | SALES |
+-------------------------+-------+
| 2020-01-01 00:00:00.000 | 2     |
| 2020-01-02 00:00:00.000 | 3     |
| 2020-01-03 00:00:00.000 | 4     |
| 2020-01-04 00:00:00.000 | 5     |
| 2020-01-05 00:00:00.000 | 6     |
+-------------------------+-------+

CREATE SNOWFLAKE.ML.FORECAST model1(
  INPUT_DATA => SYSTEM$REFERENCE('VIEW', 'v1'),
  TIMESTAMP_COLNAME => 'date',
  TARGET_COLNAME => 'sales'
);

Instance MODEL1 successfully created.

call model1!FORECAST(FORECASTING_PERIODS => 3);

+-------------------------+-----------+--------------+--------------+
| TS                      | FORECAST  | LOWER_BOUND  | UPPER_BOUND  |
+-------------------------+-----------+--------------+--------------+
| 2020-01-13 00:00:00.000 | 14        | 14           | 14           |
| 2020-01-14 00:00:00.000 | 15        | 15           | 15           |
| 2020-01-15 00:00:00.000 | 16        | 16           | 16           |
+-------------------------+-----------+--------------+--------------+

CALL model1!FORECAST(FORECASTING_PERIODS => 3, CONFIG_OBJECT => {'prediction_interval': 0.8});

BEGIN
  CALL model1!FORECAST(FORECASTING_PERIODS => 3);
  LET x := SQLID;
  CREATE TABLE my_forecasts AS SELECT * FROM TABLE(RESULT_SCAN(:x));
END;

SELECT * FROM my_forecasts;

CREATE OR REPLACE VIEW v2 AS SELECT date, sales, temperature, humidity, holiday
  FROM sales_data WHERE store_id=1 AND item='jacket';
SELECT * FROM v2;

+-------------------------+--------+-------------+----------+----------+
| DATE                    | SALES  | TEMPERATURE | HUMIDITY | HOLIDAY  |
+-------------------------+--------+-------------+----------+----------+
| 2020-01-01 00:00:00.000 | 2      | 50          | 0.3      | new year |
| 2020-01-02 00:00:00.000 | 3      | 52          | 0.3      | null     |
| 2020-01-03 00:00:00.000 | 4      | 54          | 0.2      | null     |
| 2020-01-04 00:00:00.000 | 5      | 54          | 0.3      | null     |
| 2020-01-05 00:00:00.000 | 6      | 55          | 0.2      | null     |
+-------------------------+--------+-------------+----------+----------+

CREATE SNOWFLAKE.ML.FORECAST model2(
  INPUT_DATA => SYSTEM$REFERENCE('VIEW', 'v2'),
  TIMESTAMP_COLNAME => 'date',
  TARGET_COLNAME => 'sales'
);

CREATE OR REPLACE VIEW v2_forecast AS select date, temperature, humidity, holiday
  FROM future_features WHERE store_id=1 AND item='jacket';
SELECT * FROM v2_forecast;

+-------------------------+-------------+----------+---------+
| DATE                    | TEMPERATURE | HUMIDITY | HOLIDAY |
+-------------------------+-------------+----------+---------+
| 2020-01-13 00:00:00.000 | 52          | 0.3      | null    |
| 2020-01-14 00:00:00.000 | 53          | 0.3      | null    |
+-------------------------+-------------+----------+---------+

CALL model2!FORECAST(
  INPUT_DATA => SYSTEM$REFERENCE('VIEW', 'v2_forecast'),
  TIMESTAMP_COLNAME =>'date'
);

+-------------------------+-----------+--------------+--------------+
| TS                      | FORECAST  | LOWER_BOUND  | UPPER_BOUND  |
+-------------------------+-----------+--------------+--------------+
| 2020-01-13 00:00:00.000 | 14        | 14           | 14           |
| 2020-01-14 00:00:00.000 | 15        | 15           | 15           |
+-------------------------+-----------+--------------+--------------+

CREATE OR REPLACE VIEW v3 AS SELECT [store_id, item] AS store_item, date, sales FROM sales_data;
SELECT * FROM v3;

+-------------------+-------------------------+-------+
| STORE_ITEM        | DATE                    | SALES |
+-------------------+-------------------------+-------+
| [ 1, "jacket" ]   | 2020-01-01 00:00:00.000 | 2     |
| [ 1, "jacket" ]   | 2020-01-02 00:00:00.000 | 3     |
| [ 1, "jacket" ]   | 2020-01-03 00:00:00.000 | 4     |
| [ 1, "jacket" ]   | 2020-01-04 00:00:00.000 | 5     |
| [ 1, "jacket" ]   | 2020-01-05 00:00:00.000 | 6     |
| [ 2, "umbrella" ] | 2020-01-01 00:00:00.000 | 2     |
| [ 2, "umbrella" ] | 2020-01-02 00:00:00.000 | 3     |
| [ 2, "umbrella" ] | 2020-01-03 00:00:00.000 | 4     |
| [ 2, "umbrella" ] | 2020-01-04 00:00:00.000 | 5     |
| [ 2, "umbrella" ] | 2020-01-05 00:00:00.000 | 6     |
+-------------------+-------------------------+-------+

CREATE SNOWFLAKE.ML.FORECAST model3(
  INPUT_DATA => SYSTEM$REFERENCE('VIEW', 'v3'),
  SERIES_COLNAME => 'store_item',
  TIMESTAMP_COLNAME => 'date',
  TARGET_COLNAME => 'sales'
);

CALL model3!FORECAST(FORECASTING_PERIODS => 2);

+-------------------+------------------------+----------+-------------+-------------+
| SERIES            | TS                     | FORECAST | LOWER_BOUND | UPPER_BOUND |
+-------------------+------------------------+----------+-------------+-------------+
| [ 1, "jacket" ]   | 2020-01-13 00:00:00.000 | 14      | 14          | 14          |
| [ 1, "jacket" ]   | 2020-01-14 00:00:00.000 | 15      | 15          | 15          |
| [ 2, "umbrella" ] | 2020-01-13 00:00:00.000 | 14      | 14          | 14          |
| [ 2, "umbrella" ] | 2020-01-14 00:00:00.000 | 15      | 15          | 15          |
+-------------------+-------------------------+---------+-------------+-------------+

CALL model3!FORECAST(SERIES_VALUE => [2,'umbrella'], FORECASTING_PERIODS => 2);

+-------------------+------------ ------------+-----------+-------------+-------------+
| SERIES            | TS                      | FORECAST  | LOWER_BOUND | UPPER_BOUND |
+-------------------+---------- --------------+-----------+-------------+-------------+
| [ 2, "umbrella" ] | 2020-01-13 00:00:00.000 | 14        | 14          | 14          |
| [ 2, "umbrella" ] | 2020-01-15 00:00:00.000 | 15        | 15          | 15          |
+-------------------+-------------------------+-----------+-------------+-------------+

CREATE OR REPLACE VIEW v4 AS SELECT [store_id, item] AS store_item,
  date, sales, temperature FROM sales_data;
SELECT * FROM v4;

+-------------------+-------------------------+-------+-------------+
| STORE_ITEM        | DATE                    | SALES | TEMPERATURE |
+-------------------+-------------------------+-------+-------------+
| [ 1, "jacket" ]   | 2020-01-01 00:00:00.000 | 2     | 50          |
| [ 1, "jacket" ]   | 2020-01-02 00:00:00.000 | 3     | 52          |
| [ 1, "jacket" ]   | 2020-01-03 00:00:00.000 | 4     | 54          |
| [ 1, "jacket" ]   | 2020-01-04 00:00:00.000 | 5     | 54          |
| [ 1, "jacket" ]   | 2020-01-05 00:00:00.000 | 6     | 55          |
| [ 2, "umbrella" ] | 2020-01-01 00:00:00.000 | 2     | 50          |
| [ 2, "umbrella" ] | 2020-01-02 00:00:00.000 | 3     | 52          |
| [ 2, "umbrella" ] | 2020-01-03 00:00:00.000 | 4     | 54          |
| [ 2, "umbrella" ] | 2020-01-04 00:00:00.000 | 5     | 54          |
| [ 2, "umbrella" ] | 2020-01-05 00:00:00.000 | 6     | 55          |
+-------------------+-------------------------+-------+-------------+

CREATE SNOWFLAKE.ML.FORECAST model4(
  INPUT_DATA => SYSTEM$REFERENCE('VIEW', 'v4'),
  SERIES_COLNAME => 'store_item',
  TIMESTAMP_COLNAME => 'date',
  TARGET_COLNAME => 'sales'
);

CREATE SNOWFLAKE.ML.FORECAST model4(
  INPUT_DATA => SYSTEM$QUERY_REFERENCE('SELECT [store_id, item] AS store_item, date, sales, temperature FROM sales_data'),
  SERIES_COLNAME => 'store_item',
  TIMESTAMP_COLNAME => 'date',
  TARGET_COLNAME => 'sales'
);

CREATE OR REPLACE VIEW V4_FORECAST AS SELECT [store_id, item] AS store_item,
  date, temperature FROM future_features;
SELECT * FROM v4_forecast;

+-------------------+-------------------------+-------------+
| STORE_ITEM        | DATE                    | TEMPERATURE |
+-------------------+-------------------------+-------------+
| [ 1, "jacket" ]   | 2020-01-13 00:00:00.000 | 52          |
| [ 1, "jacket" ]   | 2020-01-14 00:00:00.000 | 53          |
| [ 2, "umbrella" ] | 2020-01-13 00:00:00.000 | 52          |
| [ 2, "umbrella" ] | 2020-01-14 00:00:00.000 | 53          |
+-------------------+-------------------------+-------------+

CALL model4!FORECAST(
  INPUT_DATA => SYSTEM$REFERENCE('VIEW', 'v4_forecast'),
  SERIES_COLNAME => 'store_item',
  TIMESTAMP_COLNAME =>'date'
);

+-------------------+-------------------------+----------+-------------+-------------+
| SERIES            | TS                      | FORECAST | LOWER_BOUND | UPPER_BOUND |
+-------------------+-------------------------+----------+-------------+-------------+
| [ 1, "jacket" ]   | 2020-01-13 00:00:00.000 | 14       | 14          | 14          |
| [ 1, "jacket" ]   | 2020-01-14 00:00:00.000 | 15       | 15          | 15          |
| [ 2, "umbrella" ] | 2020-01-13 00:00:00.000 | 14       | 14          | 14          |
| [ 2, "umbrella" ] | 2020-01-14 00:00:00.000 | 15       | 15          | 15          |
+-------------------+-------------------------+----------+-------------+-------------+

Visualisation des prévisions¶

Pour visualiser une prévision, utilisez la fonction graphique Snowsight. Après avoir généré une prévision, cliquez sur Charts au-dessus de la table des résultats de la requête.

Vous pouvez joindre vos prévisions à votre ensemble de données original à l’aide de UNION ALL pour combiner SELECTs sur les données originales et les résultats des prévisions, afin de pouvoir visualiser les deux ensemble. Par exemple :

CALL model4!FORECAST(FORECASTING_PERIODS => 3);

SELECT date AS ts, sales AS actual, NULL AS forecast, NULL AS lower_bound, NULL AS upper_bound
  FROM sales_data
UNION ALL
SELECT ts, NULL AS actual, forecast, lower_bound, upper_bound
  FROM TABLE(RESULT_SCAN(-1));

Renommez les colonnes de l’horodatage et des variables exogènes si nécessaire afin qu’elles correspondent à l’ensemble de données original et à la prévision. Utilisez NULL pour représenter la valeur cible de la prévision dans les données d’entraînement et, inversement, pour représenter la valeur cible historique dans les résultats de la prévision. Dans l’exemple précédent, la colonne de l’objectif réel (historique) est renommée actual et l’objectif prévisionnel forecast.

Après avoir préparé vos données de cette manière, suivez les étapes suivantes dans la section Data à droite du graphique :

1. Sélectionnez la colonne ACTUAL et sous Aggregation, sélectionnez None.

2. Sélectionnez la colonne TS et sous Bucketing, sélectionnez None.

3. Ajoutez la colonne FORECAST en sélectionnant Use as Line, puis sous Aggregation, sélectionnez None.

4. Ajoutez les colonnes LOWER_BOUND et UPPER_BOUND de la même manière.

Le graphique obtenu devrait ressembler à celui-ci :

Présentation de l’importance des fonctions¶

Un modèle de prévision peut expliquer l’importance relative de toutes les fonctions utilisées dans votre modèle, y compris les variables exogènes que vous avez choisies ainsi que les caractéristiques temporelles générées automatiquement (telles que le jour de la semaine ou la semaine de l’année) et les transformations de votre variable cible (telles que les moyennes glissantes et les temps de latence autorégressifs). Ces informations sont utiles pour comprendre quels sont les facteurs qui influencent réellement vos données.

La méthode <nom>!EXPLAIN_FEATURE_IMPORTANCE compte le nombre de fois où les arborescences du modèle ont utilisé chaque fonction pour prendre une décision. Ces scores d’importance des fonctions sont ensuite normalisés à des valeurs comprises entre 0 et 1, de sorte que leur somme soit égale à 1. Les scores obtenus représentent un classement approximatif des fonctions de votre modèle entraîné.

Les fonctions dont le score est proche ont une importance similaire. Pour les séries extrêmement simples (par exemple, lorsque la colonne cible a une valeur constante), tous les scores d’importance des fonctions peuvent être nuls.

L’utilisation de plusieurs fonctions très similaires les unes aux autres peut entraîner une réduction des scores d’importance pour ces fonctions. Par exemple, si une fonction est la quantité d’articles vendus et une autre la quantité d’articles en stock, les valeurs peuvent être corrélées parce que vous ne pouvez pas vendre plus que vous n’avez, et parce que vous essayez de gérer les stocks de manière à ne pas avoir plus en stock que ce que vous allez vendre. Si deux fonctions sont exactement identiques, le modèle peut les considérer comme interchangeables lors de la prise de décision, ce qui se traduit par des scores d’importance des fonctions inférieurs de moitié à ce qu’ils seraient si une seule des fonctions identiques était incluse.

L’importance des fonctions signale également les fonctions de latence. Au cours de la formation, le modèle déduit la fréquence (horaire, quotidienne ou hebdomadaire) de vos données d’entraînement. La fonction lagx (par exemple lag24) est la valeur de la variable cible il y a x [unités de temps]. Par exemple, si vos données sont déduites comme étant horaires, lag24 représente votre variable cible il y a 24 heures.

Toutes les autres transformations de votre variable cible (moyennes glissantes, etc.) sont résumées dans la table de résultats sous le nom de aggregated_endogenous_features.

CREATE OR REPLACE VIEW v_random_data AS SELECT
  DATEADD('minute', ROW_NUMBER() over (ORDER BY 1), '2023-12-01')::TIMESTAMP_NTZ ts,
  MOD(SEQ1(),10) y,
  UNIFORM(1, 100, RANDOM(0)) exog_a
FROM TABLE(GENERATOR(ROWCOUNT => 500));

CREATE OR REPLACE SNOWFLAKE.ML.FORECAST forecast_feature_importance_demo(
  INPUT_DATA => SYSTEM$REFERENCE('VIEW', 'v_random_data'),
  TIMESTAMP_COLNAME => 'ts',
  TARGET_COLNAME => 'y'
);

CALL forecast_feature_importance_demo!EXPLAIN_FEATURE_IMPORTANCE();

+------+--------------------------------------+-------+-------------------------+
| RANK | FEATURE_NAME                         | SCORE | FEATURE_TYPE            |
+------+--------------------------------------+-------+-------------------------+
|    1 | aggregated_endogenous_trend_features |  0.36 | derived_from_endogenous |
|    2 | exog_a                               |  0.22 | user_provided           |
|    3 | epoch_time                           |  0.15 | derived_from_timestamp  |
|    4 | minute                               |  0.13 | derived_from_timestamp  |
|    5 | lag60                                |  0.07 | derived_from_endogenous |
|    6 | lag120                               |  0.06 | derived_from_endogenous |
|    7 | hour                                 |  0.01 | derived_from_timestamp  |
+------+--------------------------------------+-------+-------------------------+

Compréhension des mesures d’évaluation¶

Par défaut, chaque modèle de prévision fait l’objet d’une validation croisée. Outre la formation d’un modèle sur toutes les données de formation fournies, un ou plusieurs modèles sont formés sur des sous-ensembles de données d’entraînement, puis utilisés pour « prédire » les données retenues. Les valeurs cibles prédites sont ensuite comparées aux valeurs cibles réelles. Si vous n’avez pas besoin de métriques d’évaluation ou si vous ne souhaitez pas y consacrer des ressources de calcul, définissez evaluate sur FALSE lors de l’instanciation du modèle.

CREATE OR REPLACE VIEW v_random_data AS SELECT
  DATEADD('minute', ROW_NUMBER() over (ORDER BY 1), '2023-12-01')::TIMESTAMP_NTZ ts,
  MOD(SEQ1(),10) y,
  UNIFORM(1, 100, RANDOM(0)) exog_a
FROM TABLE(GENERATOR(ROWCOUNT => 500));

CREATE OR REPLACE SNOWFLAKE.ML.FORECAST model(
  INPUT_DATA => SYSTEM$REFERENCE('VIEW', 'v_random_data'),
  TIMESTAMP_COLNAME => 'ts',
  TARGET_COLNAME => 'y'
);

CALL model!SHOW_EVALUATION_METRICS();

+--------------------------+--------------+--------------------+------+
| ERROR_METRIC             | METRIC_VALUE | STANDARD_DEVIATION | LOGS |
+--------------------------+--------------+--------------------+------+
| "MAE"                    |        7.107 |              1.998 | NULL |
| "MAPE"                   |        0.475 |              0.237 | NULL |
| "MDA"                    |        0.920 |              0.025 | NULL |
| "MSE"                    |       86.020 |             66.798 | NULL |
| "SMAPE"                  |        0.241 |              0.047 | NULL |
| "COVERAGE_INTERVAL=0.95" |        0.981 |              0.025 | NULL |
| "WINKLER_ALPHA=0.05"     |       56.697 |             45.199 | NULL |
+--------------------------+--------------+--------------------+------+

Inspection des journaux d’entraînement¶

Lorsque vous entraînez plusieurs séries avec CONFIG_OBJECT => 'ON_ERROR': 'SKIP', les modèles de séries temporelles individuels peuvent échouer sans que le processus d’entraînement global n’échoue. Pour comprendre quelle série temporelle a échoué et pourquoi, appelez <model_instance>!SHOW_TRAINING_LOGS.

CREATE TABLE t_error(date TIMESTAMP_NTZ, sales FLOAT, series VARCHAR);
INSERT INTO t_error VALUES
  (TO_TIMESTAMP_NTZ('2019-12-20'), 1.0, 'A'),
  (TO_TIMESTAMP_NTZ('2019-12-21'), 2.0, 'A'),
  (TO_TIMESTAMP_NTZ('2019-12-22'), 3.0, 'A'),
  (TO_TIMESTAMP_NTZ('2019-12-23'), 2.0, 'A'),
  (TO_TIMESTAMP_NTZ('2019-12-24'), 1.0, 'A'),
  (TO_TIMESTAMP_NTZ('2019-12-25'), 2.0, 'A'),
  (TO_TIMESTAMP_NTZ('2019-12-26'), 3.0, 'A'),
  (TO_TIMESTAMP_NTZ('2019-12-27'), 2.0, 'A'),
  (TO_TIMESTAMP_NTZ('2019-12-28'), 1.0, 'A'),
  (TO_TIMESTAMP_NTZ('2019-12-29'), 2.0, 'A'),
  (TO_TIMESTAMP_NTZ('2019-12-30'), 3.0, 'A'),
  (TO_TIMESTAMP_NTZ('2019-12-31'), 2.0, 'A'),
  (TO_TIMESTAMP_NTZ('2020-01-01'), 2.0, 'A'),
  (TO_TIMESTAMP_NTZ('2020-01-02'), 3.0, 'A'),
  (TO_TIMESTAMP_NTZ('2020-01-03'), 3.0, 'A'),
  (TO_TIMESTAMP_NTZ('2020-01-04'), 7.0, 'A'),
  (TO_TIMESTAMP_NTZ('2020-01-05'), 10.0, 'B'),
  (TO_TIMESTAMP_NTZ('2020-01-06'), 13.0, 'B'),
  (TO_TIMESTAMP_NTZ('2020-01-06'), 12.0, 'B'), -- duplicate timestamp
  (TO_TIMESTAMP_NTZ('2020-01-07'), 15.0, 'B'),
  (TO_TIMESTAMP_NTZ('2020-01-08'), 14.0, 'B'),
  (TO_TIMESTAMP_NTZ('2020-01-09'), 18.0, 'B'),
  (TO_TIMESTAMP_NTZ('2020-01-10'), 12.0, 'B');

CREATE SNOWFLAKE.ML.FORECAST model(
  INPUT_DATA => SYSTEM$QUERY_REFERENCE('SELECT date, sales, series FROM t_error'),
  SERIES_COLNAME => 'series',
  TIMESTAMP_COLNAME => 'date',
  TARGET_COLNAME => 'sales',
  CONFIG_OBJECT => {'ON_ERROR': 'SKIP'}
);

CALL model!SHOW_TRAINING_LOGS();

+--------+-------------------------------------------------------------------------------------------------+
| SERIES | LOGS                                                                                            |
+--------+-------------------------------------------------------------------------------------------------+
| "B"    | {   "Errors": [     "Frequency cannot be inferred when duplicate timestamps are present."   ] } |
| "A"    | NULL                                                                                            |
+--------+-------------------------------------------------------------------------------------------------+

Considérations relatives aux clients¶

L’entraînement et l’utilisation de modèles de prévision entraînent des coûts de stockage et de calcul.

Comme décrit dans Sélection d’un entrepôt virtuel, l’entraînement consomme plus de temps de calcul que la prévision à partir d’un modèle entraîné. Cependant, les coûts de la prévision peuvent s’accumuler en cas d’utilisation répétée du modèle. Consultez Comprendre le coût du calcul pour obtenir des informations générales sur les coûts de calcul de Snowflake.

Les coûts de stockage que vous supportez reflètent le stockage des instances du modèle ML créées au cours de l’étape de formation. Pour voir les objets associés à votre instance de modèle, accédez aux vues Account Usage (par exemple, ACCOUNT_USAGE.TABLES et ACCOUNT_USAGE.STAGES). Ces objets apparaîtront avec des colonnes de base de données et de schéma NULL. La colonne instance_id en revanche sera remplie et indiquera que ces objets sont contenus dans une instance de modèle. Ces objets sont entièrement gérés par l’instance de modèle, et vous ne pouvez pas y accéder ou les supprimer séparément. Pour réduire les coûts de stockage associés à vos modèles, supprimez les modèles inutilisés ou obsolètes.

Utilisation des prévisions dans Snowpark¶

session.call n’est pas encore compatible avec les modèles de prévision. Pour appeler un modèle de prévision dans Snowpark, utilisez plutôt session.sql, comme indiqué ici.

session.sql('call my_model!forecast(...)').collect()