Experiments

Track your training runs — parameters, metrics, and artifacts — and compare them side by side without leaving the editor. It runs a real MLflow server for you and shows everything in the Experiments panel.

What you can do

• Install MLflow and start a local tracking server with one click, with your tracking data stored alongside your project
• Write ordinary mlflow code in a cell and see the run appear, with no configuration and no special API
• Open any run to read its parameters, a grid of metric charts, and its artifacts
• Switch a chart between step, relative time, and wall-clock, toggle a log y-axis, and smooth a noisy series with EMA
• Tick two or more runs and compare them: a parameter diff, overlaid metric charts, a parallel-coordinates plot, and a metric-vs-metric scatter
• Attach a workspace file to a run, or download what a run produced
• See your registered models, which version each alias points at, and promote a version to champion with approval and a record of who did it
• Scaffold the train.py and evaluate.py a pipeline calls, with your model and features left as your work

Zero-setup tracking

1. One click — the sidebar's Install MLflow button installs MLflow into your active Python environment (creating a workspace .venv if you don't have one yet) and starts a local MLflow server.

2. Kernels are wired automatically — every kernel session is pointed at the server, so your runs show up with no configuration. If you set a tracking URI yourself, it's left alone.

3. Just use mlflow in a cell:

   import mlflow
   mlflow.autolog()          # sklearn / torch / xgboost — zero-effort capture
   
   # or log by hand:
   with mlflow.start_run(run_name="demo"):
       mlflow.log_param("lr", 0.01)
       mlflow.log_metric("loss", 0.42, step=1)
   

   If your kernel doesn't have the client yet: %pip install mlflow.

Flow and agent runs are captured into the same server automatically. Start and stop the server from the sidebar; it survives editor reloads and shuts down with the app.

Artifacts and models

mlflow.autolog() and mlflow.log_artifact() upload artifacts to the server. For the local server, the detail tab lists them and lets you attach a workspace file to a run or download them. Models are stored and versioned as artifacts; the extension does not run them.

The quality gate

The same tracking data backs a quality gate an MLOps pipeline can run between training and the registry. It checks a run against the bar you set: metric thresholds, whether it beats the current champion, and whether it lost ground on any slice while its headline metric improved. The bar lives in .punica/mlops.yaml next to the gate, so it is reviewable in git rather than buried in a setting.

MLOps: Scaffold train.py and evaluate.py writes the two files a pipeline calls, and it is careful about which half is yours. The model, the features and the hyperparameters stay your work, in two functions that say so. Everything around them is written for you: connecting to the tracking server, recording which dataset produced the run, saving the model with a signature, and exiting with a code CI can read. Neither file is ever overwritten once you have edited it.

Remote MLflow (optional)

The + button connects an existing MLflow tracking server (URI plus none / bearer / basic auth; the token is stored in your OS keychain). Once connected, the panel reads from it and kernels are pointed at it automatically. Artifacts on a remote server are listed read-only, and deleting a run uses MLflow's soft-delete.

Notes

• Metric charts require the desktop app.
• The local server runs without authentication — the standard setup for local MLflow.
• On Linux with Docker, the container must be able to reach your host machine for the automatic wiring to work.

Getting started

Open the Experiments sidebar and click Install MLflow, then run a cell that calls mlflow.autolog().