1 of 17

[ML]

Machine Learning for Machine Learning

2

2 of 17

Achieving ML interoperability via Deep Learning

Let us dope it

3 of 17

The long, tedious road to ML deployment

Product

Manager

Data Scientist

Software Engineers

Dev Ops

App

Requirements & Metrics

PoC Modeling

[R,Python]

Production code

  • Long slow road to delivery for each new application, Very little reuse across applications
  • POC code → Production code translation is highly error prone
  • Rigorous continuous evaluation of actual production systems if often unlikely (DS out of loop)

4 of 17

Would’ve been better if

Product

Manager

Data Scientist

Software Engineers

Dev Ops

App

Requirements & Metrics

PoC Modeling

[R,Python]

Production code

But

  • Tech stacks could be different.
  • Dev and Prod env could be different.
  • Scalability could be an issue!
  • Most importantly, skill sets could be different

5 of 17

Interoperability, the saviour

What is Machine Learning (ML) interoperability?

    • Ability to switch between different ML frameworks seamlessly.
    • Develop once -- Deploy anywhere
    • Ex - A user familiar with sklearn should be able to deploy his model using TensorFlow server with very minimal effort (2-3 lines of code).

Why is it the saviour?

    • Reduce time-to-market for ML models
    • Focus less on frameworks, more on the problem
    • Let every ML developer use his/her skills in whichever framework they are comfortable with, regardless of the Production environment -- avoid the two language, two stack.

6 of 17

What are we hoping for?

Let us recall what JAVA has done to IT Industry at large -- same piece of code can run anywhere -- regardless of the host operating system. Can we do the same for ML. Is there a JAR file and JVM equivalent for ML?

7 of 17

What is the current landscape

  • PMML
    • A markup language for Stat/ML models
      • High asymmetry in readers and writers
      • Adoption is questionable
  • ONNX, NNEF
    • Is a standard to exchange deep learning models
    • Deep Learning is inherently scalable, and is object oriented in spirit. Most importantly ecosystem is ripe for interoperability within the Deep Learning frameworks
    • But what about the “classical” non deep learning side?

dope’s approach is to fulfill an intent specified (in any framework), via any Deep Learning backend

8 of 17

The Design tenets

Modular

The very nature of neural network models is - they are extremely modular. In essence, it is this quality of neural network models that enables IMLY to accomplish the intent of a standard ML model using a neural network model.

For example, IMLY can convert a logistic regression, linear regression or lasso regression model without having to cause much changes to the core architecture of the neural network model it relies on.

This further enhances the ease of contributing more models and their corresponding mappings.

Zero learning curve: Just add one line of code to your existing workflow

The entire API collection of “dope” resembles that of scikit learn (any reference API) APIs. Except for one line of code(which connects the standard ML model’s intent to IMLY), the user experience is in coherence with that of Scikit-learn.

Scalable: Deep Learning scales from CPUs to TPUs

Software 2.0: “dope” is a semantic map between the target APIs and the backend Deep Learning Implementation

9 of 17

Implementation details

Primal Model

Dope’d Model

dope’d

Dope

Optimizer

Adapter

10 of 17

Implementation details

Primal model (API Spec)

    • The primal model, here, in dope’s context is any existing standard ML model that you wish to convert to a neural network.
    • dope currently supports basic sklearn models. This will be extended to more packages like XgBoost, SupriseLib etc

11 of 17

Implementation details

Fulfillment via Deep Learning Models

    • Dope - Dope acts as an entrypoint for the user. It’s a function that maps the Primal model to its corresponding neural network configuration. This configuration knowledge is then utilised by Dope to build the neural network model. Dope accomplishes this by delegating their respective task to the adapter and Optimizer.
    • Adapter - The Adapter component ensures that the final neural network model returned to the user performs exactly as the Primal model provided by the user; the only difference being that it’s a neural network model now. To put it simple terms, the task of ensuring there is “zero learning curve” required for a user is done by the Adapter.
    • Optimizer - The configuration mentioned above is dependant on the dataset the user intends to use. The Optimizer runs the model through a collection of search-spaces and returns a model that matches with Primal model.

12 of 17

Implementation details

Dope’d model

    • The Dope’d model is the final neural network model. This is saved as an ONNX file.
    • The idea is to be able to deploy this model to any possible neural network runtimes.
    • Currently, this has been tested on tf.js, onnx.js and the onnx runtime.

13 of 17

Add just 1 line of code

>>> from mlsquare.imly import dope

>>> from sklearn.linear_model import LinearRegression

>>> from sklearn.preprocessing import StandardScaler

>>> from sklearn.model_selection import train_test_split

>>> import pandas as pd

>>> from sklearn.datasets import load_diabetes

>>> model = LinearRegression()

>>> diabetes = load_diabetes()

>>> X = diabetes.data

>>> sc = StandardScaler()

>>> X = sc.fit_transform(X)

>>> Y = diabetes.target

>>> x_train, x_test, y_train, y_test =

train_test_split(X, Y, test_size=0.60, random_state=0)

>>> m = dope(model)

>>> # All sklearn operations can be performed on m, except that the underlying implementation uses DNN

>>> m.fit(x_train, y_train)

>>> m.score(x_test, y_test)

14 of 17

Discussion

No Free lunch theorem:

DOPE provides a semantic map to transpile an API in the target framework to its Deep Learning counterpart. It tries hard to retain the “intent” as much as possible but is not guaranteed, and not every time, there can be a one-to-one correspondence between target API parameter or specification to its Deep Learning counterpart.

However, it can be handle case by case basis and is an excellent research direction to work on

15 of 17

Demo

16 of 17

Roadmap

17 of 17

Contribute

Currently, we support many sklearn APIs.

But our goal is to map entire sklearn APIs, and extend the toolset to include other popular libraries in Python (such as XGBoost, Surpiselib for Recommendation Engines etc..)

We also are contributing new Keras Layers such as a Decision Tree layer, which we believe is a great new lego block in the Deep Leaning ecosystem, and waiting to see its wide range of applications.

If you are passionate about Scientific Computing in general, and Deep Learning in particular,

come - join the mission. checkout mlsquare.org for other interesting projects