ML : entraîner un modèle
Description
Section intitulée « Description »L’étape ML : entraîner un modèle ajuste un modèle scikit-learn sur une table source et écrit le résultat sous forme de table de modèle. La table de modèle circule dans le workflow comme n’importe quelle autre table : transmettez-la à une étape ML : scorer pour ajouter des prédictions à une table de données, ou interrogez-la directement pour consulter les métriques d’entraînement. L’étape s’exécute comme un job PlaidCloud géré (comme l’étape LLM) : l’entraînement n’entre donc pas en concurrence avec le reste du workflow pour les ressources.
Onglet Modèle
Section intitulée « Onglet Modèle »Source et sortie
Section intitulée « Source et sortie »- Table d’entraînement : la table sur laquelle entraîner le modèle. Les lignes dont la valeur cible est vide sont exclues de l’entraînement.
- Table du modèle : la table de sortie qui reçoit l’enregistrement du modèle.
-
Algorithme : le modèle à ajuster :
Algorithme Valeur Famille Régression logistique logistic_regressionClassification Classifieur par arbre de décision decision_treeClassification Classifieur par forêt aléatoire random_forestClassification Classifieur à gradient boosting (de type XGBoost) xgb_classifierClassification Régression linéaire linear_regressionRégression Régresseur par arbre de décision decision_tree_regressorRégression Régresseur par forêt aléatoire random_forest_regressorRégression L’algorithme de type XGBoost est un
HistGradientBoostingClassifierde scikit-learn : un équivalent statistique de XGBoost, et non une surcouche de celui-ci. Consultez Limites et réserves. -
Colonne cible : la colonne à prédire. Elle est obligatoire, sauf pour les algorithmes non supervisés et
sota, dont la colonne de classe est facultative. Les cibles de classification sont traitées comme des étiquettes textuelles ; les cibles de régression sont converties en nombres, et les lignes dont la cible ne peut pas être interprétée comme un nombre sont exclues.
Autres algorithmes
Section intitulée « Autres algorithmes »La liste Algorithme propose également les algorithmes suivants. Les workflows KNIME convertis les utilisent aussi.
| Algorithmes | Description |
|---|---|
xgboost_classifier, xgboost_regressor, xgboost_linear_classifier, xgboost_linear_regressor |
XGBoost lui-même, avec le booster à arbres ou linéaire |
gradient_boosting_classifier, gradient_boosting_regressor |
Gradient boosting de scikit-learn |
svm, svm_regressor, mlp, mlp_regressor, dummy, dummy_regressor |
Machines à vecteurs de support, perceptrons multicouches et modèles de référence de scikit-learn |
knime_decision_tree, knime_tree_ensemble, naive_bayes, knn, lda, pnn_dda, fuzzy_rules, sota |
Les propres apprenants de KNIME, qui donnent les résultats de KNIME ; leurs hyperparamètres correspondent aux paramètres de KNIME |
kmeans, dbscan, optics, pca, mds, tsne, isolation_forest, apriori, fp_growth |
Les algorithmes non supervisés de KNIME : aucune colonne cible, et les colonnes de caractéristiques sont les colonnes numériques (pour apriori et fp_growth, l’unique colonne de listes d’éléments) |
kmedoids, fuzzy_cmeans, hierarchical, hierarchical_tree, silhouette, h2o_pca, mds_projection, smote, target_shuffling, knn_distance, prediction_fusion, al_uncertainty, al_combiner, al_selector, al_density, al_density_table, distribution_creator, distribution_splitter, weak_label, als, rule_table, optics_table, dose_response |
Les nœuds KNIME de clustering, d’échantillonnage, d’apprentissage actif, de recommandation (als : les colonnes de caractéristiques sont l’utilisateur et le produit, la cible est la note), de règles d’association et de dose-réponse |
dbscan, mds, tsne et les autres algorithmes qui n’ont pas de modèle distinct de leurs données conservent leurs paramètres dans la table de modèle, et ML : scorer restitue la table qui lui est fournie.
Hyperparamètres
Section intitulée « Hyperparamètres »Un objet JSON facultatif d’hyperparamètres scikit-learn pour l’algorithme choisi, par exemple {"max_depth": 5, "n_estimators": 200}. Les clés inconnues sont rejetées à l’enregistrement de l’étape : un paramètre mal saisi échoue donc immédiatement au lieu d’être ignoré en silence. Les workflows convertis depuis Alteryx peuvent aussi contenir des clés sentinelles de style Alteryx, comme max_depth_none ; elles sont traduites automatiquement.
Quelques paramètres historiques que scikit-learn a supprimés sont acceptés mais non appliqués (par exemple presort, ou les paramètres d’arbre XGBoost énumérés sous Limites et réserves) ; tout ce qui est abandonné de cette façon est consigné dans params_json de la table de modèle, sous dropped_params : rien ne disparaît donc silencieusement.
Onglet Caractéristiques
Section intitulée « Onglet Caractéristiques »L’onglet Caractéristiques affiche une ligne par colonne de la table source :
- Caractéristique : cochez les colonnes sur lesquelles entraîner le modèle. Laissez toutes les cases décochées pour entraîner le modèle sur toutes les colonnes, sauf la cible. Lorsque aucune case n’est cochée, l’étape s’entraîne sur les colonnes que la table contient au moment de l’exécution ; indiquez des colonnes dans Exclure des colonnes (
exclude_columns) pour en écarter certaines. - Remplacement de type : forcez le traitement d’une colonne en Numérique ou Catégoriel, ou laissez (déduire) pour déduire le type à partir du type de la colonne de la table.
La préparation des caractéristiques correspond à Alteryx Assisted Modeling : les caractéristiques numériques sont converties en nombres (les valeurs non interprétables deviennent manquantes) et les valeurs manquantes sont imputées par la médiane ; les caractéristiques catégorielles sont traitées comme du texte, imputées par la valeur la plus fréquente, puis encodées en one-hot. Les valeurs qu’une caractéristique catégorielle n’a jamais rencontrées pendant l’entraînement sont ignorées lors du scoring.
La table du modèle
Section intitulée « La table du modèle »La table du modèle contient les colonnes suivantes :
| Colonne | Contenu |
|---|---|
model_pickle_b64 |
Le pipeline scikit-learn ajusté (sérialisé avec pickle, compressé et encodé en base64). Les modèles volumineux sont répartis sur plusieurs lignes ; consultez Stockage du modèle. |
chunk_index |
La position du fragment de modèle de cette ligne, en comptant à partir de 0. |
algorithm |
La valeur de l’algorithme, par exemple logistic_regression. |
params_json |
JSON : les paramètres scikit-learn appliqués, les types de caractéristiques utilisés et les éventuels dropped_params. |
feature_names_json |
Tableau JSON : les colonnes de caractéristiques ordonnées que le modèle attend lors du scoring. |
class_labels_json |
Tableau JSON des étiquettes de classe (classifieurs) ou null (régresseurs). |
metrics_json |
Métriques d’entraînement au format JSON ; voir ci-dessous. |
trained_at |
Horodatage UTC de l’exécution de l’entraînement. |
Comme le modèle est une table ordinaire, vous pouvez l’interroger comme telle : par exemple, extrayez metrics_json dans une étape en aval pour conditionner un workflow à la qualité du modèle.
metrics_json contient une clé kind (classification ou regression), train_accuracy pour les classifieurs ou train_r2 et train_rmse pour les régresseurs, ainsi que n_training_rows.
Stockage du modèle
Section intitulée « Stockage du modèle »Un modèle ajusté peut être volumineux (une forêt aléatoire conservant ses cent arbres par défaut peut atteindre plusieurs centaines de mégaoctets), ce qui dépasse ce qu’un entrepôt de données accepte comme valeur unique. Le modèle est donc compressé et, s’il reste trop gros pour une seule ligne, réparti sur autant de lignes que nécessaire. Chaque ligne répète les colonnes ci-dessus : n’importe laquelle vous indique donc l’algorithme, les paramètres, les caractéristiques et les métriques ; seules model_pickle_b64 et chunk_index diffèrent d’une ligne à l’autre.
Cela a des conséquences à deux endroits :
- Lecture des métriques. Une table de modèle peut contenir plusieurs lignes ; lisez donc les métriques à partir d’une seule ligne au lieu de supposer qu’il n’y en a qu’une, par exemple avec
WHERE chunk_index = 0. - Réassemblage du modèle par vos soins. Si vous lisez
model_pickle_b64en dehors de PlaidCloud, concaténez les fragments dans l’ordre dechunk_index, décodez le base64, puis décompressez avant de désérialiser avec pickle.
Une étape ML : scorer fait tout cela pour vous. Elle vérifie aussi que chaque fragment est présent et s’arrête avec une erreur si l’un d’eux manque, plutôt que de scorer avec un modèle incomplet.
Limites et réserves
Section intitulée « Limites et réserves »- Les métriques d’entraînement sont calculées sur le jeu d’entraînement : cette version ne propose ni découpage de réserve (holdout) ni validation croisée. Considérez-les comme un contrôle d’ajustement, et non comme une estimation de la performance hors échantillon.
- Jeu de travail en mémoire : la table d’entraînement est lue en mémoire ; l’étape vise donc environ un million de lignes. Échantillonnez ou agrégez d’abord les tables plus volumineuses.
- Taille maximale du modèle : un modèle ajusté est rejeté s’il dépasse 128 Mo une fois compressé, et l’étape s’arrête dès la fin de l’entraînement avec un message indiquant la taille et la limite. À titre de repère : une forêt aléatoire de cent arbres sur 17 000 lignes et 17 caractéristiques représente environ 56 Mo ; la limite est donc à peu près le double. Si vous l’atteignez, entraînez moins d’arbres (
n_estimators) ou plafonnezmax_depth. - Approximation de XGBoost :
xgb_classifierentraîne unHistGradientBoostingClassifierde scikit-learn ; les algorithmesxgboost_*exécutent XGBoost lui-même. Les paramètres d’arbre propres à XGBoostgamma,min_child_weight,subsampleet la famillecolsample_*n’ont pas d’équivalent et sont abandonnés (consignés dansdropped_params, ainsi que dans les notes de mappage de l’étape lorsqu’elle a été convertie depuis Alteryx). Validez les métriques du modèle par rapport à votre exécution de référence avant de vous fier à la parité. - La conversion AutoML choisit un seul algorithme, sans recherche : un outil Alteryx AutoML fusionne vers cette étape de la même manière que Classification et Regression, mais AutoML n’enregistre jamais lequel de ses algorithmes candidats l’a réellement emporté lors de l’exécution dans Alteryx. La conversion retient le premier algorithme coché que cette étape prend en charge et consigne ce choix, au lieu de reproduire une recherche automatisée : aucune boucle de sélection de modèle ne s’exécute ici. Comparez une étape AutoML convertie à vos propres résultats Alteryx.
Voir aussi
Section intitulée « Voir aussi »- ML : scorer : scorer une table de données avec le modèle entraîné.
- Migrate Alteryx Workflows : comment les pipelines Alteryx Assisted Modeling, AutoML compris, sont convertis vers cette étape.