As the data science tent widens, practitioners may excel at using prepared data, but lack the skills to do this preparation in a reliable way. These responsibilities can be split across multiple roles and teams, but enormous productive gains can be achieved by taking a full-stack approach where data scientists own the entire process from ideation through deployment.
Whether you’re a data scientist building your own ETLs or a data engineer assisting data scientists in this process, making your data pipelines easier to understand, debug, and extend will reduce the support burden for yourself and your teammates. …
I’ve been a data scientist at Stitch Fix for just over a year now. If you’re not familiar with us, we’re an online clothing retailer, and our mission is to help our customers find clothing that they’ll love and that fits them perfectly. To do this, we’ve put data science at the core of the business.
One thing that drew my attention to Stitch Fix as I was looking for a new data science position is their incredible Multithreaded blog. …
In the last part, we looked at automated testing with pytest to verify that our API is correctly scoring the model. In this post, we’ll look at how we can separate the API functionality — which is responsible for handling requests and preparing the responses — from the code necessary to prepare features and score the model.
If you’re new to this series, welcome! Also, you may want to start at the beginning just to review what we’ve already done.
Throughout this post, we’ll look at snippets of code, but the full files are available on GitHub.
Side Note: I…
In the last post, we improved the error handling of our prediction API and considered the nuanced decision about which records we should score. In this post, we’ll look at how we can test our API using pytest.
As always, we’re going to use Python 3, and I’m going to assume that you are either using Anaconda or that you’ve set up an environment with these packages installed: flask, scikit-learn, and pytest.
In the initial series post, we created a simple API to score a Scikit-Learn random forest classifier built on the iris dataset. In this post, we’ll explore how we can handle errors that occur during scoring as well as look at the broader topic of defining when a model should be used.
We can begin by thinking about testing a simple Python function. No model, no APIs, just a function that adds two numbers.
When we think about how to test this function, we should consider everything that can go wrong and assume it will go wrong at some…
Ok, so you’ve trained a model, but now what? All that work is meaningless if no one can use it. In some applications, you can simply create a batch job that will collect the records that need to be scored, prepare them, and the run the model. However, other applications require or at least highly benefit from a process for scoring models in real-time. Ideally, we’d even like to share the ability to use the model with others through a REST API. …