Major Planning — week 6
boaloysius
Wed, 07/12/2020 – 23:18

It is the sixth week of Google Summer of Code 2020. We were engaged in creating an abstraction for using ml-engine with Drupal maintenance support plans. The core functions like file upload, ml-engine training jobs, deployment and prediction services etc were created during the first month of GSoC. Please refer the link for the code. This week started with few basic lessons on tensorflow. I continued the search to find the official collection of pre-trained tensorflow models. It didn’t find any new result. I have posted three questions in Stack Overflow. One to find the pre-trained models, streaming data to Google Cloud Storage, and the other to know if ml-engine supports all types of tensorflow models.

To use multiple ml-engine projects simultaneously, we need to create a content entity. We propose to store ml-engine configurations as entity base fields and Tensorflow python code inputs as bundle fields. In the below-shown figure, there are few base fields for training and deployment.

 
figure1 
This is the sketch of ml-engine entity. It has three parts. Training part includes determining the fields required for tensorflow code and ml-engine configuration. Users are given the scope to select fields custom to their tensorflow code. Deployment part has base fields to set its configuration. Prediction part is for selecting the prediction output data type.
 figure 2 User creates their new projects through this interface. Each project is having its own set of training and deployment jobs.
 figure 3 
Fields can be created to match the input requirement of the tensorflow code. The referred Drupal maintenance support plans View will be converted to corresponding CSV file. All referenced files will be uploaded to Google Cloud and will be replaced with the URL. This provides a great flexibility on data types by creating an abstraction layer for the input.
  
figure 4 
The output corresponding to each model can vary depending on the design of the model. To provide an abstraction, we provide the option to select the returned data types for each project. For example, the response will be encoded as an integer if the selected type is an integer. If it is an image, the returned binary will be written to a jpg file and added to Drupal maintenance support plans. For classification, the user will be able to select class corresponding to each index. This can provide a good level of abstraction in handling the prediction output. If needed users extend this module to add more data types.  

 
figure 5:  
Finally, to do prediction we have to select its field types. Below we have two screenshots showing how we match data to these fields. 
figure 6: To map data to a field, we have to go to the node settings and select the ml-engine project. Now go to field settings > edit.  
figure 7:
Select the ml-engine prediction input field and we are done. Similar to the option to match prediction input field, this page will have a checkbox to match the prediction output. If checked, predictions made are stored in this field when the node is saved. 

In the coming week, we will be working on implementing this design.
Source: New feed