Skip to content
PlaidCloud

ML: Train Model

Description

Section titled “Description”

The ML: Train Model step fits a scikit-learn model on a source table and writes the result as a model table. The model table flows through the workflow like any other table — pass it to an ML: Score step to append predictions to a data table, or query it directly to inspect the training metrics. The step runs as a managed PlaidCloud job (like the LLM step), so training does not compete with the rest of the workflow for resources.

training rowsfeatures + known labelTrainfit an algorithmmodel artifactsaved, reusable→ used by ML Score
ML Train fits an algorithm on rows whose label is already known, producing a saved model artifact that ML Score applies to new rows.

Model Tab

Section titled “Model Tab”

Source and Output

Section titled “Source and Output”
  • Training Table — the table to train on. Rows with an empty target value are excluded from training.
  • Model Table — the output table that receives the model record.

Model

Section titled “Model”

  • Algorithm — the model to fit:

    Algorithm Value Family
    Logistic Regression logistic_regression Classification
    Decision Tree Classifier decision_tree Classification
    Random Forest Classifier random_forest Classification
    Gradient Boosting Classifier (XGBoost-style) xgb_classifier Classification
    Linear Regression linear_regression Regression
    Decision Tree Regressor decision_tree_regressor Regression
    Random Forest Regressor random_forest_regressor Regression

    The XGBoost-style algorithm is a scikit-learn HistGradientBoostingClassifier — a statistically equivalent stand-in for XGBoost, not a wrapper around it. See Limits and Caveats.

  • Target Column — the column to predict. Classification targets are treated as text labels; regression targets are coerced to numbers, and rows whose target does not parse as a number are excluded.

Hyperparameters

Section titled “Hyperparameters”

An optional JSON object of scikit-learn hyperparameters for the chosen algorithm — for example {"max_depth": 5, "n_estimators": 200}. Unknown keys are rejected when you save the step, so a mistyped parameter fails immediately instead of being silently ignored. Workflows converted from Alteryx may also carry Alteryx-style sentinel keys such as max_depth_none; these are translated for you.

A few legacy parameters that scikit-learn has removed are accepted but not applied (for example presort, or the XGBoost tree knobs listed under Limits and Caveats); anything dropped this way is recorded in the model table’s params_json under dropped_params, so nothing disappears silently.

Features Tab

Section titled “Features Tab”

The Features tab shows one row per source-table column:

  • Feature — check the columns to train on. Leave all boxes unchecked to train on every column except the target.
  • Type Override — force a column to Numeric or Categorical handling, or leave it at (infer) to derive the type from the table column type.

Feature preparation matches Alteryx Assisted Modeling: numeric features are coerced to numbers (unparseable values become missing) and missing values are imputed with the median; categorical features are treated as text, imputed with the most frequent value, and one-hot encoded. Values a categorical feature never saw during training are ignored at scoring time.

The Model Table

Section titled “The Model Table”

The model table has these columns:

Column Contents
model_pickle_b64 The fitted scikit-learn pipeline (pickled, compressed, base64-encoded). Large models are split across rows — see How the Model Is Stored.
chunk_index The position of this row’s piece of the model, counting from 0.
algorithm The algorithm value, for example logistic_regression.
params_json JSON: the applied scikit-learn parameters, the feature types used, and any dropped_params.
feature_names_json JSON array: the ordered feature columns the model expects at scoring time.
class_labels_json JSON array of class labels (classifiers) or null (regressors).
metrics_json JSON training metrics — see below.
trained_at UTC timestamp of the training run.

Because the model is an ordinary table, you can query it like one — for example, extract metrics_json in a downstream step to gate a workflow on model quality.

metrics_json contains a kind key (classification or regression), train_accuracy for classifiers or train_r2 and train_rmse for regressors, and n_training_rows.

How the Model Is Stored

Section titled “How the Model Is Stored”

A fitted model can be large — a random forest left at its default hundred trees can run to hundreds of megabytes — and that is more than a warehouse will accept as a single value. The model is therefore compressed and, if it is still too big for one row, split across as many rows as it needs. Every row repeats the columns above, so any one of them tells you the algorithm, parameters, features and metrics; only model_pickle_b64 and chunk_index differ between them.

This matters in two places:

  • Reading the metrics. A model table may hold more than one row, so read the metrics from a single row rather than assuming there is only one — for example with WHERE chunk_index = 0.
  • Reassembling the model yourself. If you read model_pickle_b64 outside PlaidCloud, concatenate the pieces in chunk_index order, base64-decode, then decompress before unpickling.

An ML: Score step does all of this for you. It also checks that every piece is present, and stops with an error if one is missing rather than scoring with an incomplete model.

Limits and Caveats

Section titled “Limits and Caveats”
  • Training metrics are computed on the training set — there is no holdout split or cross-validation in this release. Treat them as a fit check, not an estimate of out-of-sample performance.
  • In-memory working set — the training table is read into memory, so the step targets roughly one million rows. Sample or aggregate larger tables first.
  • Maximum model size — a fitted model is rejected if it comes to more than 128 MB once compressed, and the step stops as soon as training finishes with a message naming the size and the limit. For scale: a random forest of a hundred trees over 17,000 rows and 17 features comes to about 56 MB, so the limit is roughly twice that. If you reach it, train fewer trees (n_estimators) or cap max_depth.
  • XGBoost approximation — xgb_classifier trains a scikit-learn HistGradientBoostingClassifier. The XGBoost-specific tree parameters gamma, min_child_weight, subsample, and the colsample_* family have no equivalent and are dropped (recorded in dropped_params, and in the step’s mapping notes when the step was converted from Alteryx). Validate model metrics against your reference run before relying on parity.
Section titled “Related”