3 ms·

Data Science 2020 – Highlights

20 points by amrrs 6y ago

Jugurtha 6y ago
>Data Scientists are bad Web Developers, but what if we need to build web apps that can talk or do Machine Learning? We do have colleagues like that, but even for those who can go end to end (helping client to state the problem, to data acquisition, model building, writing application, setting up infrastructure, deploying, and monitoring), it's tiring.. We'd get the data, build the models, and then we'd have to write the application. That's a separate repository and software project, often on-premises deployment which we have to maintain. And that's for the "application" proper with user management, and business logic. I'm not even talking about what most people do "Flask app that loads model weights, exposes a form, and returns predictions to show the client, let me set a VM on GCP and send a link to the client", but the client is busy, and you forget about it, so you shut down the VM, the client clicks on the link, nothing there, and you're left to remember which of the VMs and which of the models was there. This toil is one of the reasons we're building https://iko.ai https://iko.ai, because we've done it so many times for clients, that certain patterns and inefficiencies have emerged and we're addressing them in our platform to really focus on high value things. For example, we have AppBooks[1] where a machine learning practitioner clicks a button and publishes an automatically parametrized notebook, without tagging cells or using metadata, or cluttering the notebook with code that does that. It generates a form and the client or domain expert can then change parameters and run the notebook without mutating it. One other benefit is that this automatically tracks the run: the parameters, metrics, and the model generated is saved, and you can then deploy that model in one click or build a Docker image. These are not much, but solve the problem of "I want to show results and get feedback, how do I do that? VM on GCP and Flask app? Export to PDF?" >Finally, Models are easy to build on Jupyter Notebooks. We all know it just takes a few lines of code and your `model.fit()` is ready. But what’s next? Well, it depends. Long-running notebooks have been problematic when the kernel and the front-end would stop talking with each other. The computation would take place, but the results wouldn't find their way to the front-end. People would be watching training, and then there would be a disconnection or they'd close the browser tab and lose results. Some would add code to save the model/pickle it, but that's clutter. We've added long-running notebook scheduling[2] right from the notebook's interface, so closing a tab or shutting down your computer doesn't impact anything. You can view the output outside of JupyterLab in a simple page, even on your phone. That's very useful because it sometimes happens where we want to run a bunch of experiments. We just schedule them all in a fire and forget way. But the gist of it is that so far, it's helping us: - Load data - Start notebooks with the most popular libraries pre-installed - Collaborate in real-time on notebooks and see cursors and changes - Publish AppBooks: automatically parametrized notebooks - Schedule long-running training jobs and be able to watch their output as they run - Automatically track experiments without remembering to do so or polluting the notebook with tracking code - Deploying models into a "REST endpoint", and monitoring their performance in near-real time dashboards Basically, a lot of work we're happy not to be doing :) - [0]: https://iko.ai https://iko.ai - [1]: https://iko.ai/docs/appbook/ https://iko.ai/docs/appbook/ - [2]: https://iko.ai/docs/notebook/#long-running-notebooks https://iko.ai/docs/notebook/#long-running-notebooks

20 points by amrrs 6y ago

>Data Scientists are bad Web Developers, but what if we need to build web apps that can talk or do Machine Learning? We do have colleagues like that, but even for those who can go end to end (helping client to state the problem, to data acquisition, model building, writing application, setting up infrastructure, deploying, and monitoring), it's tiring.. We'd get the data, build the models, and then we'd have to write the application. That's a separate repository and software project, often on-premises deployment which we have to maintain. And that's for the "application" proper with user management, and business logic. I'm not even talking about what most people do "Flask app that loads model weights, exposes a form, and returns predictions to show the client, let me set a VM on GCP and send a link to the client", but the client is busy, and you forget about it, so you shut down the VM, the client clicks on the link, nothing there, and you're left to remember which of the VMs and which of the models was there. This toil is one of the reasons we're building https://iko.ai https://iko.ai, because we've done it so many times for clients, that certain patterns and inefficiencies have emerged and we're addressing them in our platform to really focus on high value things. For example, we have AppBooks[1] where a machine learning practitioner clicks a button and publishes an automatically parametrized notebook, without tagging cells or using metadata, or cluttering the notebook with code that does that. It generates a form and the client or domain expert can then change parameters and run the notebook without mutating it. One other benefit is that this automatically tracks the run: the parameters, metrics, and the model generated is saved, and you can then deploy that model in one click or build a Docker image. These are not much, but solve the problem of "I want to show results and get feedback, how do I do that? VM on GCP and Flask app? Export to PDF?" >Finally, Models are easy to build on Jupyter Notebooks. We all know it just takes a few lines of code and your `model.fit()` is ready. But what’s next? Well, it depends. Long-running notebooks have been problematic when the kernel and the front-end would stop talking with each other. The computation would take place, but the results wouldn't find their way to the front-end. People would be watching training, and then there would be a disconnection or they'd close the browser tab and lose results. Some would add code to save the model/pickle it, but that's clutter. We've added long-running notebook scheduling[2] right from the notebook's interface, so closing a tab or shutting down your computer doesn't impact anything. You can view the output outside of JupyterLab in a simple page, even on your phone. That's very useful because it sometimes happens where we want to run a bunch of experiments. We just schedule them all in a fire and forget way. But the gist of it is that so far, it's helping us: - Load data - Start notebooks with the most popular libraries pre-installed - Collaborate in real-time on notebooks and see cursors and changes - Publish AppBooks: automatically parametrized notebooks - Schedule long-running training jobs and be able to watch their output as they run - Automatically track experiments without remembering to do so or polluting the notebook with tracking code - Deploying models into a "REST endpoint", and monitoring their performance in near-real time dashboards Basically, a lot of work we're happy not to be doing :) - [0]: https://iko.ai https://iko.ai - [1]: https://iko.ai/docs/appbook/ https://iko.ai/docs/appbook/ - [2]: https://iko.ai/docs/notebook/#long-running-notebooks https://iko.ai/docs/notebook/#long-running-notebooks