10 posts tagged with "MLOps"

Every time you train a model, you change something: the number of trees, a setting, the data. A week later nobody remembers which change gave the best result. MLflow remembers it for you. In this first part you install MLflow, start your own tracking server, and log your first machine learning experiment from Python.

An MLflow tracking server keeps your work in two places: a database for experiments, runs, parameters, metrics and tags, and a folder for the files your runs log, such as charts and models. With the default settings, both sit in the folder you started the server from. This guide finds them, follows one run from the UI to its files and database rows, and reads the database safely, with real output from MLflow 3.18.0.

Tracking runs pays off when you compare them: which settings gave the lowest error, and was the extra training time worth it? The MLflow UI gives you a runs table you can filter and sort, a chart view, and a Compare page with four plots and side-by-side tables. This guide uses all of them on four real runs, with screenshots from MLflow 3.18.0.

Tags are labels on a run: the model type, the dataset, who owns it. Unlike parameters, you can change them later, and unlike metrics, they're text. MLflow also adds its own tags to every run, such as who ran it and which Git commit the code was at. This guide sets tags, overwrites one, adds a run description, and lists everything MLflow recorded, with real output from MLflow 3.18.0.

Metrics are the numbers a run produces: error scores, accuracy, a loss that falls during training. Unlike parameters, a metric can be logged many times, so MLflow keeps its whole history and draws it as a chart. This guide logs single values, a batch, and a metric at ten steps, reads the history back, and shows what happens when a value isn't a number.

Parameters are the settings that shape a run: the number of trees, a learning rate, which features you used. Logging them is what lets you answer "what was different about the good run?" later. This guide logs parameters one at a time and in a batch, shows how MLflow stores them, and runs into the one rule people trip over: a parameter can't change once it's logged.

A run is one execution of your code that MLflow records: its settings, results and files. Everything you log goes into the active run, so how you start and end runs decides where your data lands. This guide starts runs four ways, names them, checks their status, and shows what MLflow does when your code fails halfway, with real output from MLflow 3.18.0.

An MLflow experiment is a folder for related runs: one per project, or one per question you're trying to answer. Every run belongs to exactly one experiment. This guide creates experiments two ways, reads their ID and artifact location, shows the error you get for a duplicate name, and finds them in the UI, with real output from MLflow 3.18.0.

The MLflow UI is where your runs become useful: every setting, score and chart in one place, searchable and comparable. MLflow 3.18's UI serves two audiences, AI apps and classic model training, and opens in the AI view by default. This tour switches it to model training and walks through the pages you'll use most: experiments, the runs table, and a run's own page.

The MLflow tracking server is the place your training runs go: a small web server that stores every run and shows them in the MLflow UI. You don't need a cloud account or a database server to run one; MLflow 3.18 brings everything, including a SQLite database. This guide starts a server on your own computer, explains every line it prints, checks that it's ready, and stops it safely.