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

Note

Les prévisions font partie de Cortex de Snowflake, le service AI et ML intelligent et entièrement géré de Snowflake. Cette fonction fait partie de la suite de fonctions optimisées par ML Snowflake Cortex.

La prévision emploie un algorithme de machine learning pour prédire les données futures en utilisant des données historiques de séries temporelles. Les prévisions de séries temporelles produisent des prédictions univariées de données futures sur la base de données historiques. Un cas d’utilisation courant consiste à prévoir les ventes en fonction de la saisonnalité et d’autres facteurs.

Les données historiques doivent comprendre les éléments suivants :

  • Une colonne d’horodatage, qui doit avoir une fréquence fixe (par exemple, toutes les heures, toutes les 5 minutes, etc.)

  • Une colonne cible représentant une certaine quantité d’intérêt à chaque horodatage.

Les données historiques peuvent également inclure des colonnes supplémentaires qui pourraient avoir influencé la cible (variables exogènes). Ces colonnes peuvent contenir des données numériques ou des caractères.

Les données historiques sont utilisées pour entraîner un modèle de machine learning qui produit une prévision de la valeur cible à des horodatages futurs. Le modèle est un objet de niveau schéma et peut être utilisé pour plusieurs prévisions après avoir été entraîné. (Le modèle ne peut pas être utilisé pour produire des prévisions dans la même fourchette que les données historiques).

La prévision fonctionne avec des données à série unique ou à séries multiples. Les données à séries multiples représentent plusieurs threads d’événements indépendants. Par exemple, si vous disposez de données de vente pour plusieurs magasins, les ventes de chaque magasin peuvent être prévues séparément par un seul modèle basé sur l’identificateur du magasin.

Pour produire des prévisions de données de séries temporelles, utilisez la classe intégrée de Snowflake FORECAST, et suivez ces étapes :

  1. Créez un objet de modèle de prévision, en lui transmettant une référence aux données d’entraînement. Cet objet ajustera (entraînera) un modèle aux données d’entraînement que vous lui fournissez. Le modèle est un objet de niveau schéma.

  2. En utilisant cet objet de modèle de prévision, appelez la méthode de prévision pour produire une prévision de la cible pour des horodatages futurs, en indiquant soit le nombre d’incréments temporels, soit, en cas d’utilisation de variables exogènes, les données exogènes évaluées en fonction de l’avenir.

Important

Mention légale. Cette fonction Snowflake Cortex basée sur le ML est alimentée par une technologie de machine learning. La technologie de machine learning et les résultats fournis peuvent être inexacts, incorrects ou biaisés. Les décisions basées sur les résultats du machine learning, y compris celles qui sont intégrées dans des pipelines automatiques, devraient être soumises à une supervision humaine et à des processus d’examen pour s’assurer que le contenu généré par le modèle est exact. Les requêtes de fonctions Snowflake Cortex basées sur le ML seront traitées comme toute autre requête SQL et peuvent être considérées comme des métadonnées.

Métadonnées. Lorsque vous utilisez des fonctions Snowflake Cortex basées sur le ML, Snowflake enregistre les messages d’erreur génériques renvoyés par une fonction ML, en plus de ce qui est mentionné dans les champs de métadonnées. Ces journaux d’erreurs nous aident à résoudre les problèmes qui surviennent et à améliorer ces fonctions pour mieux répondre à vos demandes.

Pour plus d’informations, voir la FAQ relative à la confiance et à la sécurité concernant l’AI de Snowflake.

À 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.

Important

De temps à autre, Snowflake peut affiner l’algorithme de prévision et déploiera ces améliorations par le biais du processus de publication de versions Snowflake habituel. Vous ne pouvez pas revenir à une version antérieure de la fonction, mais les modèles que vous avez créés avec une version antérieure continueront à utiliser cette version pour les prévisions.

Limites actuelles

La version actuelle présente les limitations suivantes :

  • Vous ne pouvez pas choisir ni ajuster l’algorithme de prévision.

  • Le nombre minimum de lignes pour l’algorithme de prévision principal est de 12 par série temporelle. Pour les séries temporelles comportant entre 2 et 11 observations, la prévision produit une prévision « naïve » dans laquelle toutes les valeurs prédites sont égales à la dernière valeur cible observée.

  • Les fonctions de prévision ne fournissent pas de paramètres permettant de remplacer la tendance, la saisonnalité ou les amplitudes saisonnières ; ces paramètres sont déduits des données.

  • La granularité minimale acceptable des données est d’une seconde. (Les horodatages ne doivent pas être espacés de moins d’une seconde.)

  • La granularité minimale des composantes saisonnières est d’une minute. (La fonction ne peut pas détecter de modèles cycliques à des deltas temporels plus petits.)

  • Les horodatages de vos données doivent représenter des intervalles de temps fixes. Si vos données d’entrée sont irrégulières, essayez d’utiliser DATE_TRUNC ou TIME_SLICE sur votre colonne d’horodatage lors de l’entraînement du modèle.

  • La « longueur de la saison » des fonctions autorégressives est liée à la fréquence d’entrée (24 pour des données horaires, 7 pour des données journalières, et ainsi de suite).

  • Les modèles de prévision, une fois entraînés, sont immuables. Vous ne pouvez pas mettre à jour les modèles existants avec de nouvelles données ; vous devez entraîner un modèle entièrement nouveau. Les modèles ne prennent pas en charge la gestion des versions. Snowflake recommande d’entraîner à nouveau un modèle à intervalles réguliers, par exemple une fois par jour, par semaine ou par mois, en fonction de la fréquence à laquelle vous recevez de nouvelles données, afin de permettre au modèle de s’adapter à l’évolution des modèles et des tendances.

  • Vous ne pouvez pas cloner de modèles ni les partager entre rôles ou comptes. Lors du clonage d’un schéma ou d’une base de données, les objets du modèle sont ignorés.

  • Vous ne pouvez pas répliquer une instance de la classe FORECAST.

Préparer les prévisions

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

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

Sélection d’un entrepôt virtuel

Un entrepôt virtuel Snowflake fournit les ressources de calcul nécessaires à l’entraînement et à l’utilisation des modèles de machine learning pour cette fonction. Cette section fournit des conseils généraux sur le choix de la meilleure taille et du meilleur type d’entrepôt à cette fin, en se concentrant sur l’étape d’entraînement (la partie du processus qui prend le plus de temps et qui mobilise le plus de mémoire).

Entraînement sur des données à série unique

Pour les modèles formés sur des données à série unique, choisissez le type d’entrepôt en fonction de la taille de vos données d’entraînement. Les entrepôts standard sont soumis à une limite de mémoire Snowpark inférieure et sont plus appropriés pour les tâches d’entraînement avec moins de lignes et de variables exogènes.

Si vos données d’entraînement ne contiennent pas de variables exogènes, vous pouvez vous entraîner sur un entrepôt standard si l’ensemble de données comporte 5 millions de lignes ou moins. Si vos données d’entraînement utilisent 5 ou plus de variables exogènes, le nombre maximal de lignes est inférieur. Dans le cas contraire, Snowflake suggère d’utiliser un entrepôt optimisé par Snowpark pour les tâches de formation plus importantes.

En général, pour les données à série unique, une taille d’entrepôt plus importante ne se traduit pas par un temps d’apprentissage plus rapide ou des limites de mémoire plus élevées. En règle générale, le temps de formation est proportionnel au nombre de lignes de votre série temporelle. Par exemple, sur un entrepôt standard XS, la formation sur un ensemble de données de 100 000 lignes prend environ 30 secondes. La formation sur un ensemble de données de 1 000 000 lignes prend environ 140 secondes.

Pour de meilleures performances, Snowflake recommande d’utiliser un entrepôt dédié sans autres charges de travail simultanées pour entraîner votre modèle.

Entraînement sur des données à séries multiples

Comme pour les données à série unique, Snowflake recommande de choisir le type d’entrepôt en fonction du nombre de lignes de votre série temporelle la plus importante. Si votre plus grande série temporelle contient plus de 5 millions de lignes, la tâche de formation risque de dépasser les limites de mémoire d’un entrepôt standard.

Contrairement aux données à série unique, l’entraînement sur des données à séries multiples est beaucoup plus rapide dans des entrepôts de grande taille. Les points suivants sur les données peuvent vous guider dans votre choix.

Le type d’entrepôt

Nombre de séries temporelles

Nombre de lignes par série temporelle

Taille d’entrepôt

Durée d’entraînement

Standard

1

100,000

XS

38 secondes

10

100,000

XS

112 secondes

100

100,000

XS

594 secondes

10

100,000

XL

34 secondes

100

100,000

XL

114 secondes

1000

100,000

XL

572 secondes

Optimisé pour Snowpark

10

100,000

XL

74 secondes

100

100,000

XL

215 secondes

1000

100,000

XL

1 429 secondes

Octroi de privilèges pour la création d’objets de prévision

L’entraînement d’un modèle de prévision se traduit par un objet au niveau du schéma. Par conséquent, le rôle que vous utilisez pour créer des modèles doit avoir le privilège CREATE SNOWFLAKE.ML.FORECAST sur le schéma où le modèle sera créé, ce qui permet au modèle d’y être stocké. Ce privilège est similaire à d’autres privilèges de schéma tels que CREATE TABLE ou CREATE VIEW.

Snowflake vous recommande de créer un rôle nommé analyst qui sera utilisé par les personnes qui doivent créer des prévisions.

Dans l’exemple suivant, le rôle admin est le propriétaire du schéma admin_db.admin_schema. Le rôle analyst doit créer des modèles dans ce schéma.

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;
Copy

Pour utiliser ce schéma, un utilisateur assume le rôle analyst :

USE ROLE analyst;
USE SCHEMA admin_db.admin_schema;
Copy

Si le rôle analyst dispose des privilèges CREATE SCHEMA dans la base de données analyst_db, il peut créer un nouveau schéma analyst_db.analyst_schema et créer des modèles de prévision dans ce schéma :

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

Pour révoquer le privilège de création de modèle de prévision d’un rôle sur le schéma, utilisez REVOKE <privilèges> :

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

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);
Copy

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>(...);
Copy

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.

Note

SNOWFLAKE.ML.FORECAST s’exécute avec des privilèges limités ; par défaut, il n’a donc pas accès à vos données. Vous devez donc transmettre les tables et les vues en tant que références, qui transmettent les privilèges de l’appelant. Vous pouvez également fournir une référence de requête au lieu d’une référence à une table ou à une vue.

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

CALL <name>!FORECAST(...)
Copy

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

SHOW SNOWFLAKE.ML.FORECAST;
Copy

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

DROP SNOWFLAKE.ML.FORECAST <name>;
Copy

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.

Astuce

Pour utiliser un modèle avec un ensemble de données dont les noms de colonnes sont différents de ceux de l’ensemble de données utilisé pour entraîner le modèle, créez une vue ou une requête qui renomme les colonnes (à l’aide de AS) avec les noms attendus par le modèle. Utilisez cette vue ou cette requête comme entrée de la méthode FORECAST.

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.

Prévision sur une série unique

Cet exemple utilise une seule série temporelle (c’est-à-dire que toutes les lignes font partie d’une seule série) qui comporte deux colonnes, une colonne d’horodatage et une colonne de valeur cible, sans fonctions supplémentaires. Tout d’abord, préparez l’ensemble de données à partir de sales_data pour entraîner le modèle. Le code suivant crée une vue nommée v1 :

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

L’instruction SELECT affiche :

+-------------------------+-------+
| 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     |
+-------------------------+-------+

L’instruction suivante entraîne un modèle de prévision utilisant l’ensemble de données ci-dessus :

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

Le message suivant apparaît après l’entraînement du modèle :

Instance MODEL1 successfully created.

Le modèle de prévision est désormais disponible en tant que model1. Pour prévoir les trois prochains horodatages :

call model1!FORECAST(FORECASTING_PERIODS => 3);
Copy

Sortie

Notez que le modèle a déduit l’intervalle entre les horodatages à partir des données d’entraînement.

+-------------------------+-----------+--------------+--------------+
| 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           |
+-------------------------+-----------+--------------+--------------+

Dans cet exemple, étant donné que la prévision est parfaitement linéaire et que les erreurs par rapport aux valeurs réelles sont nulles, l’intervalle de prévision (LOWER_BOUND, UPPER_BOUND) est identique à la valeur FORECAST.

Pour personnaliser la taille de l’intervalle de prédiction, transmettez prediction_interval dans un objet de configuration :

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

Pour enregistrer vos résultats directement dans une table, utilisez le code suivant :

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;
Copy

Bien que le code ci-dessus utilise RESULT_SCAN, il n’est pas soumis à des conditions de concurrence même si plusieurs processus s’exécutent en même temps. Les résultats de l’appel de modèle ci-dessus sont stockés de manière déterministe dans la table my_forecasts.

Prévision sur une série unique avec des variables exogènes

Si vous souhaitez que des caractéristiques supplémentaires (par exemple, les vacances ou la météo) influencent les prévisions, vous devez inclure ces caractéristiques dans vos données d’entraînement. Vous créez ici une vue contenant les champs de la table sales_data :

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;
Copy

Sortie

Il s’agit des cinq premières lignes du résultat de la requête SELECT.

+-------------------------+--------+-------------+----------+----------+
| 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     |
+-------------------------+--------+-------------+----------+----------+

Vous pouvez maintenant utiliser cette vue pour entraîner un modèle. Vous devez uniquement spécifier l’horodatage et les noms des colonnes cibles ; les colonnes supplémentaires dans les données d’entrée sont supposées être des variables exogènes.

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

Le nouveau modèle s’appelle model2. Pour effectuer des prévisions pour des horodatages futurs, vous devez fournir des valeurs futures pour les variables exogènes de votre modèle : dans le cas présent, TEMPERATURE, HUMIDITY et HOLIDAY. Cela vous permet de répondre à des questions du type « Que se passerait-il si les températures étaient plus fraîches que la normale ? ». À présent, créez une vue à partir de la table future_features contenant ces données pour des horodatages futurs.

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;
Copy

Sortie

+-------------------------+-------------+----------+---------+
| 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    |
+-------------------------+-------------+----------+---------+

Vous pouvez maintenant générer une prévision à partir de ces données :

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

Dans cette variante de la méthode FORECAST, vous ne spécifiez pas le nombre d’horodatages à prédire. Au lieu de cela, les horodatages des prévisions proviennent de la vue v2_forecast.

+-------------------------+-----------+--------------+--------------+
| 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           |
+-------------------------+-----------+--------------+--------------+

Prévision sur des séries multiples

Les prévisions précédentes portent sur une seule série : toutes les lignes des données d’entraînement représentent une seule séquence de valeurs. Vous pouvez également créer un modèle de prévision pour plusieurs séries à la fois.

L’échantillon de données contient les colonnes store_id et item. Pour prévoir les ventes séparément pour chaque combinaison magasin/article dans l’ensemble de données, créez une nouvelle colonne qui combine ces valeurs et la spécifier comme colonne de la série.

Par exemple, la requête suivante crée une nouvelle vue combinant store_id et item dans une nouvelle colonne nommée store_item :

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

Sortie

Les cinq premières lignes de chaque série de l’ensemble de données obtenu sont les suivantes :

+-------------------+-------------------------+-------+
| 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     |
+-------------------+-------------------------+-------+

L’instruction suivante entraîne un modèle de prévision utilisant l’ensemble de données précédent. Veillez à spécifier le nom de la colonne de la série, qui est store_item :

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

Après l’entraînement, vous pouvez prévoir deux incréments en avant sur toutes les séries à la fois (c’est-à-dire deux incréments par série) avec :

CALL model3!FORECAST(FORECASTING_PERIODS => 2);
Copy

Sortie

+-------------------+------------------------+----------+-------------+-------------+
| 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          |
+-------------------+-------------------------+---------+-------------+-------------+

Vous pouvez également prévoir uniquement une série spécifique avec :

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

Sortie

Le résultat ne montre que les deux incréments suivants pour les ventes de parapluies du magasin 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          |
+-------------------+-------------------------+-----------+-------------+-------------+

Astuce

La spécification d’une série avec la méthode FORECAST est plus efficace que le filtrage des résultats d’une prévision multi-séries pour n’inclure que la série qui vous intéresse, car la prévision n’est générée que pour une seule série.

Prévision sur des séries multiples avec des variables exogènes

Pour entraîner et prévoir plusieurs séries temporelles en parallèle avec des variables exogènes, en combinant essentiellement les deux exemples précédents, préparez vos données de la manière suivante, en incorporant à la fois une colonne de séries (store_item dans ce cas) et au moins une colonne exogène (temperature ici) :

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

Sortie

Les cinq premières lignes de chaque série de l’ensemble de données obtenu ressemblent à ceci.

+-------------------+-------------------------+-------+-------------+
| 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          |
+-------------------+-------------------------+-------+-------------+

L’instruction suivante entraîne un modèle de prévision utilisant l’ensemble de données précédent. Veillez à spécifier le nom de la colonne de la série, store_item :

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

Astuce

Vous pouvez transmettre une référence de requête pour input_data au lieu de créer une vue intermédiaire. L’instruction suivante crée un modèle avec les mêmes données d’entrée que l’instruction précédente :

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'
);
Copy

Comme précédemment, lors de la prévision, vous devez transmettre les valeurs futures des variables exogènes, mais cette fois-ci pour chaque série. Préparez la valeur future des variables exogènes :

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

Sortie

+-------------------+-------------------------+-------------+
| 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          |
+-------------------+-------------------------+-------------+

Vous pouvez à présent établir des prévisions sur la base des horodatages précédents :

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

Sortie

+-------------------+-------------------------+----------+-------------+-------------+
| 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));
Copy

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 :

Exemple de création d'un graphique à partir d'une prévision de série chronologique

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.

Limitations

  • Vous ne pouvez pas choisir la technique utilisée pour calculer l’importance des fonctions.

  • Les scores d’importance des fonctions peuvent être utiles pour obtenir une intuition sur les fonctions qui sont importantes pour la précision de votre modèle ; mais les valeurs réelles doivent être considérées comme des estimations.

Exemple

Pour comprendre l’importance relative de vos fonctions pour votre modèle, entraînez un modèle, puis appelez <nom>!EXPLAIN_FEATURE_IMPORTANCE. Dans cet exemple, vous allez d’abord créer des données aléatoires avec deux variables exogènes, l’une qui est aléatoire et donc peu susceptible d’être très importante pour votre modèle, et l’autre qui est une copie de votre cible, et donc susceptible d’avoir une plus grande importance pour votre modèle.

Exécutez les instructions suivantes pour générer les données, entraîner un modèle sur celles-ci et obtenir l’importance des fonctions :

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();
Copy

Sortie

+------+--------------------------------------+-------+-------------------------+
| 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.

Limitations

  • Le paramètre n_splits doit être défini sur au moins 2.

  • Les petits ensembles de données peuvent ne pas contenir suffisamment de données pour effectuer une évaluation. Le nombre total de lignes d’entraînement doit être égal ou supérieur à (n_splits * test_size) + gap. Si les données disponibles ne sont pas suffisantes pour former un modèle d’évaluation, aucune mesure d’évaluation n’est disponible même si evaluate est TRUE.

Exemple

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();
Copy

Sortie

+--------------------------+--------------+--------------------+------+
| 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.

Exemple

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();
Copy

Sortie

+--------+-------------------------------------------------------------------------------------------------+
| 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()
Copy