How ML for Kids handles numbers models now

I’m on vacation for the Easter holidays this week. Apparently I don’t know how vacations work, so I’ve spent a lot of the last six days working on a major rewrite of a big chunk of Machine Learning for Kids. In this post, I want to describe what I’ve been doing and why.

In the beginning

The premise behind Machine Learning for Kids is giving school-age children the tools for creating their own machine learning models, and integrating them in child-friendly coding platforms like Scratch so they can create projects using their models.

When I launched the site in 2017…

  • models for recognising text were trained using the Watson Conversation service in IBM Cloud
  • models for recognising images were trained using the Watson Visual Recognition service in IBM Cloud
  • models for recognising numbers were trained in a Python web service that I wrote using scikit-learn

All models were trained in the cloud.

All models were stored in the cloud.

All inferencing was done in the cloud.

For example, if you had a picture that you wanted to recognise using your ML model, you’d upload that image to the cloud. The image would need to be posted to the model server hosting your model. The model would classify your uploaded image, and return the results.

I still think that was the right decision for the time:

  • ML models were resource-expensive to train and run
    pushing all the ML-related function to the cloud made sense
  • ML in JavaScript was prohibitively complex
    moving all the ML-related function off the browser made sense
  • School computers were very, very underpowered
    giving them nothing other than HTTP POST’s to do made sense
  • The site had a low number of concurrent users
    I didn’t need to optimise for scale yet

But times change.

Seven years is a long time for a website

The factors that underpinned these decisions have shifted.

  • ML models are more efficient than ever
    quicker and easier to train and run
  • JavaScript libraries like TensorFlow.js are amazingly powerful
    (and you can use the same models in both Python and JavaScript)
  • School computers are getting more powerful
    (they’re still slow compared to non-school computers, but so much better than seven years ago!)
  • The site has a huge number of concurrent users nowadays
    bottle-necking all projects through cloud APIs is more of a challenge

I also support more environments than before – including Python-based options like replit and EduBlocks.

These sort of shifts have driven a lot of the recent changes in the site. (For example, last Christmas, I added support for “local” projects – using IndexedDB and browser storage for training data.)

My general trend is that I’m steadily moving work out of the cloud and onto student computers.

In 2017…

classifier models for recognising text

Trained in the cloud using Watson Conversation

Classifying in the cloud using Watson Conversation

classifier models for recognising images

Trained in the cloud using Watson Visual Recognition

Classifying in the cloud using Watson Visual Recognition

classifier models for recognising numbers

Trained in the cloud using scikit-learn

Classifying in the cloud using scikit-learn

Today…

classifier models for recognising text

Trained in the cloud using Watson Assistant

Classifying in the cloud using Watson Assistant

classifier models for recognising images

Trained in the browser using TensorFlow.js

Classifying in the browser using TensorFlow.js

classifier models for recognising numbers

Trained in the cloud using TensorFlow Decision Forest

Classifying in the browser using TensorFlow.js

classifier models for recognising sounds

Trained in the browser using TensorFlow.js

Classifying in the browser using TensorFlow.js

regression models for predicting numbers

Trained in the browser using TensorFlow.js

Classifying in the browser using TensorFlow.js

.

Classifier models for recognising numbers are the latest shift.

How it works now

Students collect training data. If it’s a “local project”, they store it in their browser. If it’s a “cloud project”, it’s stored in my PostgreSQL database.

When it is time to train a model, this goes to a new Python web service I’ve created.

It uses the TensorFlow Decision Forests library to create a model…

(It really is that easy.)

The model is saved to a file…

TensorFlow Converter converts the model to a TensorFlow.js version, and saves that to a file.

Browser-based environments, like Scratch, download the JS model files

From here on, all classifying can be done in the browser.

The browser saves the model in IndexedDB storage, so it can be reused.

Python-based environments download the full TF model files – from here on, classifying is all done locally on the student’s computer. The model is saved locally, so it can be reused.

All of this means the web service doesn’t need to keep the model around for long. It only needs to be stored long enough for the student to download it, immediately after it was trained. After that, it can be deleted to save storage space.

This makes it much easier to scale – the only complex thing the web service is doing is training models, as hosting static model files is computationally trivial.

Will this help?

It’s been a bigger piece of work than I anticipated. What started as a bit of holiday tinkering turned into a 150-file commit, but I think this will help. The old numbers service was getting harder to scale, and was long overdue an update.

I would’ve loved to have moved the model training off the cloud as well, but I couldn’t get that working in an easy way that was consistent across web and Python environments. This feels like a decent compromise – training once but then doing everything else locally after that.

Tags:

Leave a Reply