Experiment Tracking
Intermediate 14 min read Experiment Tracking

Artifact and Code Tracking

The proof behind the scoreboard

Metrics promise a result; artifacts deliver the proof. Tracking stores the model binaries, plots and data previews a run produced, linked to the code commit that created them.

artifactsmodel filescode trackinggitlineageartifact store
Before we start

What you will learn

  • Log model, plots and reports as run artifacts
  • Link each artifact to the exact code commit
  • Use artifact lineage to rebuild or replay any run
Introduction

What is this?

Artifact and code tracking stores the files a run produced — serialized models, evaluation plots, feature importance, configs — in an artifact store, and records the git commit plus environment so the byte-level recipe is recoverable. Metrics tell you which run won; artifacts let you deploy and audit it.

Motivation

Why do you need it?

  • A metric is a summary; auditors, serving and rollback need the actual bytes.
  • Plots and reports become reviewable evidence without re-running the model.
  • Linking code commit to artifact makes 'what shipped' answerable from one record.
  • Replayability: a data scientist can rebuild any past run from tracked code and artifacts.
Think about it

Mental model

Imagine

A photo finishing lab

Think of

Artifact tracking

The lab number on the print tells the technician which negative, what paper, what chemicals produced that photo. Artifacts + code hash are the negative and the chemistry; the print is the served model.

Mechanics

How it works

  • During a run, the code calls mlflow.log_artifact (or log_model) to upload files into the artifact store.
  • MLflow auto-snapshots git commit and environment for each run when code is attached to a repo.
  • Artifact URIs become part of the run record; the registry references them later for serving.
  • Content-addressed or versioned storage keeps files immutable.
  • Serving and review tools pull artifacts by URI with the run ID as the key.

Artifact lineage from run to deployment.

Training commits
Log artifacts
Artifact store
Run record
Serve / review
Hands-on

Examples

Log everything a reviewer needs

Log everything a reviewer needs
with mlflow.start_run():
mlflow.sklearn.log_model(model, "model") # the deployable
mlflow.log_artifact("plots/pr_curve.png") # evidence
mlflow.log_artifact("reports/eval.html") # report
mlflow.log_artifact("confusion_matrix.png")
# commit + env are snapshotted automatically in a git repo

Model, plots and report all ride the same run so one URI gives you everything for review, audit and serving.

Real world

In production

  • Serving pulls the artifact URI from the winning run, so production bytes == reviewed bytes.
  • A model review board opens the run's plots and reports without re-running training.
  • A rollback loads the archived run's artifact because the old binary is still addressable.
Guidelines

Best practices

  • Attach the deployable model to every run that logs a relevant metric.
  • Name artifacts consistently so automation can find them ('model', 'eval_report').
  • Store plots (PR curve, confusion matrix) — they are the reviewable proof.
  • Version the artifact store and apply retention policies.
Watch out

Common mistakes

  • Storing artifacts on the training machine's scratch disk.
  • Logging the model once globally, not per run — mixing bytes across runs.
  • Keeping only final metrics; when auditors ask for proof the plots are gone.
  • Unversioned artifact store so 'model_final.pkl' gets overwritten.
When things break

Debugging tips

  • Deployment can't find the artifact? Confirm the artifact URI is absolute and the store is reachable.
  • Model loads but predictions are weird? Corrupted or overwritten artifact — verify content hash against the run.
  • Audit request pending? Pull the run's commit + artifact URIs to reconstruct the recipe.
Interviews

Interview checkpoint

Practice

Hands-on lab

Track Code and Artifacts Together
25 min · intermediate
In progress
Objectives
  • Initialize a git repo so the run records its commit
  • Log a model and a report file as artifacts
  • Re-download the artifact bytes from the run record

Track Code and Artifacts Together

25 min · intermediate

0/3 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself

Quick quiz

0/2
1

Attaching the git commit to a run is enough to reproduce the model byte-for-byte.

2

A model review needs the PR curve and the exact binary that scored it. Where should both live?

Go deeper

Official documentation