mljar-supervised VS lleaves

Web App is using two open-source packages that I've created:

- MLJAR AutoML - Python package for AutoML on tabular data https://github.com/mljar/mljar-supervised

- Mercury - framework for converting Jupyter Notebooks into Web App https://github.com/mljar/mercury

You can run Web App locally. What is more, you can adjust notebook's code for your needs. For example, you can set different validation strategies or evalutaion metrics or longer training times. The notebooks in the repo are good starting point for you to develop more advanced apps.

It's an Automated Machine Learning python package. It's open-source, you can see how it works on GitHub: https://github.com/mljar/mljar-supervised

Sure, at the bottom of our website you can subscribe for newsletter.

If you need a simple and fast solution, go with auto-sklearn Maybe a bit more complex, but very powerful was mljar-supervised

In my case, I had experience in DS and software engineering. It gives me ability to start a company that works on Data Science tools.

MLJAR AutoML is a Python package for Automated Machine Learning on tabular data with feature engineering, explanations, and automatic documentation.

I recommend trying my AutoML package. You can easily check many different algorithms. Waht is more, the baseline algorithms are checked (major class predictor for classification and mean predictor for regression). The advance of AutoML is that it is really quick. You dont need to write preprocessing code, just call fit method.

I built this decision tree (LightGBM) compiler last summer: https://github.com/siboehm/lleaves

It get's you ~10x speedups for batch predictions, more if your model is big. It's not complicated, it ended up being <1K lines of Python code. I heard a couple of stories like yours, where people had multi-node spark clusters running LightGBM, and it always amused me because by if you compiled the trees instead you could get rid of the whole cluster.

In a near-future version I'll expose some of the compilation parameters, I was somewhat afraid of having an API that's too complicated deterring people who just want a no-fuzz drop-in replacement for LightGBM. But as long as I keep sane defaults and have the parameters optional it should be fine. Relevant parameters are definitely block size (needs to adjust to L1i size and tree size) as well as the LLVM codemodel (a smaller adress space increases single-batch prediction speeds but doesn't work for large models). The thread-size specific compilation I'm still looking into, it makes the API more complicated and so might not be worth it.