undefined | Better HN

0 pointsfisf3y ago0 comments

Ok, I'll bite.

disclaimer: this is a nice framework, will happily try it.

Imho: The underlying patterns are quite clear, and there are various approaches to build stable pipelines.

I have used automation with basic containers + gitlab actions / custom runners, clearml, earthly pipelines, kubeflow,.. for this.

All of those can give reproducibility (experiment tracking, code & dependencies, etc.) without much effort.

The last mile (model deployment) is often very specific, so let's keep that out of scope.

But: The basic problem is cultural, not technical.

One stated goal of this project hits close to the root cause: "Facilitating the transition from Jupyter Notebook prototype code to steady production-grade pipelines".

As ML developers, we have to stop regarding notebooks as anything that produces acceptable output (apart from initial exploration). Work has to happen in structured, tracked, and versioned codebases (~production code).

Anything that happened locally/in a notebook might as well not exist from my point of view.

0 comments

2 comments · 2 top-level

neutralino13y ago

That is very true. In our careers we have repeatedly incentivized users to exit Notebooks early on.

Of course we understand why Notebooks are so appealing and useful, and we think they have their place in the toolbox (like a Python console for developers).

And you are correct that there already are many tools to build reproducible traceable pipelines. What we have found is that they are still too difficult to adopt. Which is why we are trying to greatly lower the barrier to entry.

crimsoneer3y ago

Notebooks, with the right workflow, are just fine, just use nbdev or equivalent.

j / k navigate · click thread line to collapse