Hi! Let’s talk about versioning machine learning experiments and how it is different from tracking them. You may have heard of experiment tracking tools such as Weights&Biases, MLflow, or Neptune. They offer an API you can call from your code to log the experiment information which is then stored in a database, and you get access to a dashboard where you can visually compare your numerous experiments. This is a massive improvement over manually logging the machine learning experiments into a spreadsheet. However, if you want to a particular experiment, you still need to trace back your steps to stitch together the exact code, data, and pipeline to reproduce the experiment. Wouldn’t it be better to be able to automate this? We can actually do that if we move from tracking experiments to versioning them! This is something that we can do with a new feature that has been recently added to , an open-source tool mostly known in the context of Data Versioning. Let’s see how it works. reproduce or restore DVC Setup To experiments with DVC, initialize it from any Git repo with . Make sure your project is structured in the following way: start versioning dvc exp init -i This not only helps to organize the project in a logical way, but also helps DVC to version all the moving parts that make up an experiment. Next, instead of logging experiment metadata and metrics with a tracking tool, we’ll need to store them in files, so make sure that your training script reads the parameters from , and writes the resulting metrics into a . params.yaml metrics.json You may notice that when initializing DVC automatically creates a basic pipeline, and stores it in a file. With this setup your training code, pipeline, parameters, and metrics now live in files that can be versioned. dvc.yaml Once you set up your project like this, you can already point out a few benefits: Your training code has less dependencies and doesn’t need to call an external API to log experiment information. Your training code can use any programming language you like. Python, R, Julia, Java even? Pick your favorite! Your project is well organized. You can version control parameters, metrics, pipeline, code and data (DVC can handle large data that won’t fit in Git) The pipeline in captures everything needed to reproduce an experiment, and it can be versioned too. dvc.yaml In addition to these, there are some perks that may be less obvious at a first glance. Large Data and Model Versioning Large data and models aren’t easily tracked in Git, but with DVC you can keep them using your own storage, yet make them Git-compatible. When initialized DVC starts tracking the folder making Git ignore it yet storing and versioning it so you can back up versions anywhere and check them out alongside your experiment code. models Less noise when comparing experiments In a dashboard, you can see all of your experiments, and I mean ALL of them. It can be overwhelming to go through them even with filtering and sorting options. With version control you have more flexibility and control over what you share and how you organize things. You can keep your experiments in branches and choose not to push the ones with uninspiring results. That already reduces some of the clutter. But DVC can take it one step further. If you were to create a branch for each and every experiment, especially when doing hyperparameter tuning, this would result in way too many branches to fit any Git branching workflow. To help with that, DVC tracks your experiments so you don’t need to create commits or branches for each one: Only when you decide which of these experiments are worth sharing with the team, you can convert them into actual Git branches: Single-command reproducibility Finally, codifying the entire experiment pipeline is a good first step towards reproducibility, but it still leaves it to the user to execute that pipeline. With DVC you can reproduce the entire experiment with a single command. Not only that, but it will check for cached inputs and outputs and skip recomputing data that’s been generated before which can be a massive time saver at times. Conclusion To summarize, experiment versioning allows you to codify your experiments in such a way that your experiment logs are always connected to the exact data, code, and pipeline that went into the experiment. You have control over which experiments end up shared with your colleagues for comparison, and this can prevent clutter. Finally, reproducing a versioned experiment becomes as easy as running a single command, and it can even take less time than initially, if some of the pipeline steps have cached outputs that are still relevant. Thanks for reading! And if you want to learn more about versioning machine learning experiments, check out . DVC docs Also published . here

Alongside

Initialized

Trace

Read My Stories

Too Long; Didn't Read

Make resilience your competitive advantage

How to Version Machine Learning Experiments Instead of Tracking Them

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

The Noonification: How Often Do NFTs Pass The Howey Test? (1/13/2023)

Darwin's Hybrid Intelligence to Align AI & Human Goals for Startups & VCs

The Noonification: White Man (11/26/2022)

The Noonification: The Metaverse is a Sh*tshow (11/2/2022)

100 Days of AI Day 1: From Newsletter to Podcast, Leveraging AI for Audio Transformation

The Noonification: How Often Do NFTs Pass The Howey Test? (1/13/2023)

Darwin's Hybrid Intelligence to Align AI & Human Goals for Startups & VCs

The Noonification: White Man (11/26/2022)

The Noonification: The Metaverse is a Sh*tshow (11/2/2022)

100 Days of AI Day 1: From Newsletter to Podcast, Leveraging AI for Audio Transformation

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps