Model update
Model update
In this task, a model for recognition is updated by contributors defined as model_engineer.
Assets
For this procedure, two sets of assets are required. One for the model_creator and one for model_contributor. Possible examples for these assets can be found in substrate-client-decentralml/assets.
Here's an example of the code and assets for the model_creator:
model_creator
├── __init__.py
├── model_creator.py
├── setup.sh
├── requirements.txt
└── settings.pymodel_creator.pycontains the python code for generating the first model, saving it and federated the results once the contributors have completed their training.setup.shis a script to setup the development environment for themodel_creatorrequirements.txtlists thepythonrequirements for the model developementsettings.pyis just a support file for specifiying the model parameters for themodel_contributorand the creator.
The model_creator must also create the python code for the contributor to perform his task:
model_engineer
├── __init__.py
├── model_engineer.py
├── setup.sh
├── requirements.txt
└── settings.pymodel_contributor.pycontains the python code for the training of the modelrequirements.txtlists thepythonrequirements for the model developementsettings.pyis just a support file for specifiying the model parameters for themodel_contributorand the creator.start_task.shis a script for themodel_contributorto actually execute the task
Procedure
The
model_creatorstarts by creating a model structure and compiles it:Once the first model is generated, it can be trained:
Evaluated:
And more importantly, saved for the model contributors to use:
In a federated system, the training step is generally delegated to the model contributors, but the model creator could perform some training just to initiate the system. The contributors can then subsequently training on new data.
Note all these steps are part of the
model_creator.pyin the assets folder.The
model_creatorcan then delegate the subsequent update to the model structure to themodel_engineercontributors by creating a corresponding task:In which:
model_engineer_pathis the path to the assets for themodel_contributor. The creation of the task also upload the corresponding asset to a remote/shared storage.
For additional info on the substrate parameters (i.e. expiration block, substrate, etc.) consult the documentation of the python client or view the example (https://github.com/livetreetech/DecentralML/blob/main/substrate-client-decentralml/src/decentralml/create_task.py).
The
model_engineerthen canlist_task(see Listing objects) and accept a task with:by specifying the
task_id. Assigning a task will download the corresponding assets for model contributor task.The
model_engineercan then setup its development environment using thesetup.shscript.The contributor can then start working on redefining and updating the structure of the model provided by the creator.
In order to do so, the
model_engineercan use theredefine_modelfunction provided in this example:Once the
model_engineerhas updated the model structure, he can train and evaluate the new model:Finally, once the engineer is satisfied, he can save the model for sending it back as result of the task:
Saving the model creates an output folder which includes the structure and the weights. The name of the folder includes the model name and an id for the contributor:
The contributor ID in this example is a randomly generated string used to uniquely identify the different models generated by the contributors as part of the training.
Once the
model_engineerhas completed his task, he can send the results using:This function accepts a parameter
result_pathwhich will have to be set to the output folder containing the saved model. Sending the results uploads the model training results to a remote and/or shared storage.The
model_creatorcan list the available results for each task using thelist_task_results(see Listing objects).Once, a result is available, the
model_creatorcan start validating the results using thevalidate_task_results. The validation of the results can be performed according to three policies:AutoAccept: the results are automatically accepted
ManualAccept: the
model_creatormanually accepts each task resultsCustomAccept: the
model_creatorcan implement custom methods for automatically validating the results.
Starting the validation process downloads the results and the corresponding saved models. In this example, we explain a manual validation process. The
model_creatorcan validate process by loading the federated models. For this example, the functions to federate the models are included in theassets/model_creator/model_creator.py.This model can then be evaluated:
Once the validation process is complete, the
model_creatoror the automatic validation procedure can either accept or reject the results, using respectivelyaccept_task_results()orreject_task_results().Accepting the results issues the payment to the contributor.
Last updated