Diagnose and Improve Training
Identify a model quality or execution problem, choose one change, and check whether it helps on unchanged validation data. These examples use Kumo Engine in Python and the completed fit_result from Training. Detailed history requires the original scratch files. If training failed, start with Training Did Not Complete.
Start with the Symptom
Check the Evaluation Before Tuning
- Verify the target, population, time window, and label counts in each split. For temporal predictions, features must be available at prediction time. Unexpectedly high scores warrant checking duplicates and target-derived columns.
- Compare against a simple baseline on the same rows. For binary classification, check positive-class prevalence and precision/recall at the intended threshold. For ranking, compare the same cutoff; for regression, inspect errors in the target’s units.
- Use validation to choose settings and test data for the final assessment. If test errors guide further tuning, use a fresh untouched set for the final estimate.
Check Features and Graph Coverage
Before increasing model capacity, check whether useful information reaches the model:
- Compare label counts, timestamp ranges, and feature availability across training and validation. Inspect fitted encoders for missing or excluded features.
- Measure foreign-key match rates and related-record counts at each prediction time. Report the fraction of entities with no eligible history. A relationship that matches in the full source can still provide no usable history after temporal filtering.
- Compare eligible history with sampled graph context, when available. Increase neighbor sampling only when useful records are being omitted; it cannot repair missing relationships.
As a control, compare with a simple model using prediction-time-available aggregates on the same validation rows. If that control has signal and Kumo does not, investigate feature encoding, relationships, and sampling. If neither has signal, revisit the target and population before increasing capacity.
Check the Decision Threshold
For binary classification, compare average precision (AP) with positive-class prevalence on the same population. A high AUROC can coexist with poor precision at your alert budget. Measure precision, recall, and alert count at the intended threshold, or within the highest-scoring rows your team can review.
Choose the threshold or review budget using complete, aligned validation labels and positive-class scores, then freeze it before test evaluation. holdout_df() contains test rows and is not a threshold-tuning dataset. If no rows trigger an alert, precision is undefined, not perfect. Ranking quality also does not establish calibrated probabilities; compare predicted risk with observed positive rates before using scores as risk estimates.
Know Which Evidence You Have
Publishing a model does not retain the last two rows. Preserve needed files before scratch is removed; a notebook shutdown or machine replacement can delete them.
Read Retained Model Metrics
In the training process:
In a later process, read metrics.json from the complete retained bundle:
A full-data refit trains on the test split and has no independent test evaluation. Missing metrics are not zeros; check configured metrics, evaluated splits, and warnings about undefined values.
Read Holdout Predictions
These are test predictions from the train-and-validation refit when run, otherwise from the original fit. Use them to describe errors, not to repeatedly tune settings or thresholds.
holdout_df() reads the entire saved frame into memory and fails if scratch was deleted. The saved frame is capped at 1 GiB in memory. holdout_truncated=True means rows were omitted; None means completeness is unknown. Do not report truncated-frame metrics as full-holdout metrics. Link prediction does not produce this artifact.
For segment analysis, join attributes on the complete example key, including prediction time where applicable. Verify that the join preserves row count, and report segment size and class counts alongside scores.
To retain the rows, choose a new path on durable storage:
Select the Completed Fit
Continue in the process that produced fit_result. Its bundle identifies the exact fit run, even when scratch contains several trainers and repeated fits.
selected_trial_dir identifies the original winning search experiment. Its curves describe that experiment, not a subsequent refit. Use the bundle artifacts and metric prefixes to distinguish the final model from search history.
Record these paths before the Python objects disappear. If you inspect retained scratch in a later process, set automl_dir to the exact recorded directory and resolve selected_trial_dir from its best_trainer.json. Do not select a run only because it was modified most recently.
Inspect the Trained Configuration
Read the selected fit’s artifacts, not trainer.model_plan, which controls the next fit and may have changed:
Open the files for complete values. resolved_model_plan can retain candidate lists; trainer_config records the concrete settings selected for the trainer. Check the tuning metric, evaluation step limits, refit settings, and fitted feature encoders. Change future settings through the Model Plan Guide, not by editing artifact files.
Read Lineage in a Later Process
Use a complete retained bundle from a trusted publisher, such as the copy created in Publish and Retrieve Models. The publication manifest maps artifact roles to paths relative to that bundle:
The snapshot identifier records provenance; the bundle does not contain the graph data. Use Publish and Retrieve Models for validated loading.
Load Epoch and Experiment Metrics
Continue with selected_trial_dir from Select the Completed Fit. This loads one experiment’s epoch history and final validation results; install pandas and Matplotlib if needed.
To compare experiments, repeat for another recorded version_N directory. Compare the tuning metric in that experiment’s model_plan.json; auto_train_progress.json contains the combined history. Search curves describe the original experiment, not a subsequent refit.
Plot a Learning Curve
Choose a metric present in history, such as loss, auroc, or mae. Missing values remain gaps, not zeros:
Training-batch and validation metrics can use different sampling conditions. A gap alone does not prove overfitting.
Interpret the Curves
Run a Controlled Comparison
Change one setting, keeping the training table, snapshot, splits, evaluation limits, and environment fixed. Use the Model Plan Guide for supported settings. Retain the resolved plan, package versions, seed, validation score, and runtime. For a seed-only repeat, fix all candidate lists to the selected settings first; changing the seed can otherwise select a different configuration. Select on validation, then evaluate on test.
Training Did Not Complete
A failed fit may not return fit_result. Start with the exception and last logged stage, and preserve scratch before restarting.
Measure total fit time, not only epoch time: preprocessing, multiple experiments, refits, evaluation, and explanations also take time. Compare timing under similar cache state and concurrent load. Review Training Job Plan before reducing work.
Preserve the Selected History
Retain the complete automl_dir separately from the model bundle. It can contain checkpoints and source-derived values, so restrict access and allow space for the copy.
On Linux, use a filesystem that survives the machine. On Databricks, use a restricted Unity Catalog volume:
Archive history from a Snowflake notebook
Reuse session and SCRATCH_DIR from Snowflake Notebook Setup. Set ARCHIVE_STAGE to an existing writable restricted internal stage:
Record SAVED_ARCHIVE with the model version. This archive is separate from Snowflake Model Registry publication.
Find Model Explanation Files
The analyze/ directory describes AutoML search, not feature attribution. Use Model Explainability for supported column scores and sampled graph context.
Prepare a Support Request
Send the symptom, exact error and surrounding logs, package versions, hardware and scratch capacity, predictive query, snapshot and split details, selected experiment, resolved plan, and split-labelled metrics. Include what changed between attempts and whether holdout rows were truncated.
Share relevant excerpts through your agreed support channel. Remove credentials and sensitive values; retain full artifacts privately rather than attaching them by default.