At MindsDB, we have focused on democratizing machine learning (ML) for a while now. Not only do we believe ML should be done at the data layer (i.e. your database), but we also think that offering a compelling automated machine learning pipeline can be of great value for people who are not ML experts.
However, our community has grown quickly these past few months, and we have seen new members that do have great machine learning expertise repeatedly ask the same question:
How can I bring my own model into the MindsDB ecosystem?
For a while, we offered an answer that was not ideal to many: “our in-house AutoML engine Lightwood is flexible enough to incorporate custom model logic, so you should look into that”. This is a detour that some ML-savvy users found counterintuitive, or just did not have the time to properly learn how to use.
We’re happy to announce that -as of release 22.214.171.124 — you can bring your own model to MindsDB. In this blog post, we’ll show how you can leverage this beta feature to deploy a pre-existing natural language processing machine learning model written in Keras, a popular deep learning framework. As some of you may know, we love PyTorch and leverage it in our AutoML engine. Hence, we thought using a different framework would lead to a challenging test drive.
The rest of this article is structured as follows: first, we’ll explore the basics of the Bring Your Own Model (a.k.a. BYOM) feature and how you can use it. Then, we will briefly explain the machine learning model we’ll be bringing into a database. Finally, we’ll actually train the model, connect it to MindsDB and call it via SQL to get some predictions. Buckle up!
To follow this tutorial, you will need a Python3.7 or Python3.8 virtual environment with the following packages:
NOTE: We recommend these versions as they’re the ones we used to write this post, but it’s possible that you’ll get this example to work with older versions of some/all of the packages above.
You will also need Conda, as it is used by MLflow to generate reproducible experiments. Additionally, the tutorial assumes you have a working SQL database instance to upload a couple of datasets, and a SQL database access tool like DBeaver, to interact with it.
Finally, you should also download the data from this Kaggle competition, as we’ll be using it to train a model and then get predictions for the test split.
The Bring Your Own Model feature is fairly straightforward. Even though it supports both MLflow and Ray Serve APIs, in this post we will focus on the former.
The BYOM feature assumes you have the code for some machine learning model that you would like to deploy, and interact with, from the database. If you’re using MLflow, you will need to first train and save the model with it.
Once this is done, serving the model will enable access through a REST API endpoint. The BYOM feature essentially bridges the gap between your database and the predictor without ever leaving the data layer. In practice, this means you get to call the model and access predictions as if they were just another table in your database.
For this tutorial, we are going to focus on the Kaggle competition “Natural Language Processing with Disaster Tweets”. The dataset contains a bunch of tweets, each with their own ID, location, and related keywords. The task is to predict when a tweet is related to a disaster, which is denoted by the “target” column for the training set. Hence, this is a (supervised) binary classification task.
As the focus of this post is not the model itself, we’ll keep it simple and leverage the nice example model by Kaggle Grandmaster Shahules, built using the Keras deep learning framework. It works by taking pre-trained GLOVE embeddings of words in pre-processed/cleaned tweets, aggregating and passing them as input for an LSTM neural network that will learn to gauge if a tweet is referencing a disaster or not.
We will not be inspecting the code for the model here (please refer to the link at the end of the article for more details), but as a first step we need to train the model and store it . Remember that, as this is a Keras model, it is actually really simple to achieve this:
Let’s focus on how the model should be wrapped to use MLflow. This particular use case is complex because data preprocessing is required to transform actual tweets into the initial embeddings that the model takes. These embeddings are not really meant to be pre-loaded from a feature store to a table on a per-tweet basis, but rather loaded and aggregated on demand as you trigger new inferences (otherwise, said table would be huge and highly redundant). So, when calling the predictor we actually need to remove a bunch of noise in the tweet (URLs, punctuation, emojis), tokenize the remaining words and pad the sequence because our model expects a constant length in the input sequences. Whew.
To serve models with custom inference logic like the above in MLflow, we need to subclass mlflow.pyfunc.PythonModel:
As you can see, the context loader has to load whatever artifacts are required to predict, model included. This can be achieved by passing a dictionary with all relevant information. Additionally, as MLflow will build a conda environment to guarantee reproducibility, we have to specify how this environment should look:
Now, let’s implement the final Model wrapper to replicate the pre-processing done at training, ensuring that inference works with well-formed inputs:
With this, we can ask MLflow to actually store the trained model in some path of our preference:
Finally, serving is simple. Go to the directory where you called the training script, and execute mlflow models serve --model-uri ./nlp_kaggle. If all goes well, your model should be ready to be called! But wait, we actually wanted to do this from our database with SQL, remember? Here’s where MindsDB comes in.
MindsDB has its own MySQL and HTTP APIs. To start it, you would do python -m mindsdb which will spin up the MySQL API by default. Then, you need to add a connection to MindsDB from your SQL access tool (e.g. DBeaver). For this step, I will actually refer you to our documentation, but it is a rather simple procedure.
Once that’s done, you can link the MLflow model with these SQL statements:
As you can see, linking is easy. We only need to specify the name by which we’ll access this model, the name of the column that it will predict, what URL should we find the model at (i.e. the /invocations endpoint) and last but not least, what is the data type for each column (target included).
Now, to get predictions from the model there are two main paths. On the one hand, you can directly pass input data using the WHERE clause:
However, most of the time what you actually will want in a deployed context is to pass a batch of data for the model to emit a batch of predictions.
For this, you should have your database linked to MindsDB. As an example, here’s how a Postgres connection (let’s call it db_byom) would look like:
We will create a table called nlp_kaggle_test inside a testdatabase with the following schema:
And ingest the dataset’s test split into this table. Once you’ve managed this, MindsDB can actuallyJOIN the table with our model, like so:
The output will look something like this:
Seems like the predictor did learn a thing or two about disaster tweets!
Hopefully, this blog post has given you an idea of how any model can be served and then linked with MindsDB to generate predictions inside the data layer.
This can be pretty powerful for ML in the loop if you use tools like DBT, effectively simplifying the deployment of your machine learning models.
If you have some ML models of your own and are tired of bringing its results back into the database, we suggest you go check the MindsDB repo, give it a try (and a star) and use your own models with this feature! We recommend joining our community slack as well, our team will be more than happy to help you with any questions that may arise, and all feedback is always appreciated.
As for what’s next, we’re hard at work simplifying the steps required to integrate alternative datasources, ML modeling tools, and serving tools (e.g. Ray Serve, which is already available), as well as improving the overall user experience and journey.
— About the author: Patricio Cerda Mardini, Machine Learning Research Engineer @ MindsDB.
As a masters student at PUC Chile, he focused on machine learning methods for human–robot interaction and recommendation systems, areas in which he holds several academic publications. Prior to joining MindsDB, he also interned at EY Chile as a computer vision researcher.