Skip to content

Introduction

The Lucd federated modeling capability operates on objects known as pipelines. Pipelines allow users to combine and parameterize components of their Machine Learning model. For example, a model may include a DataIO component (loading data into the model) which feeds into a Logistic Regression component. However, we have abstracted away some of the base layers of constructing a pipeline to make the Lucd user’s life easier. We build necessary components for loading a federated VDS into a pipeline (Readers & DataIO) and apply federated feature engineering components. We then hand the partially constructed pipeline to the user’s model python script as an argument. Once they select a federated VDS from the GUI when starting a training job, we automatically load and pass it into their modeling components. Essentially, this means that writing a federated model and uploading it to our system involves few simple steps:

  • Ensure VDS has a feature titled id , e.g. student.id
  • Set the model initiator's role & party ID on the pipeline. The initiator must be set to your local federate.
  • Set the active roles (guest/host/arbiter) participating in the job on the pipeline.
  • Instantiate, parameterize, and add remaining desired modeling components to the pipeline (such as a Logistic Regression & Evaluation component).

The user will then return the pipeline object & information about the role/party configuration. The completed pipeline is then submitted to the local federate’s configured federation server, thus completing the development and launching of a federated model training job from within the Lucd platform.

Common and known errors when developing federated models include: - improper role/party configuration in the pipeline by the user - improper parameterization of input/output between components - networking issues with rabbitmq

Lucd federated modeling currently supports horizontal datasets Each has been developed and tested to the standards of the provided example pipelines. The Lucd Model Shop.

Main Function

The main function is intended to contain code for building pipeline models. The LMF sends args from the GUI, a partially completed Pipeline object with a Reader component, a DataIO component pre-configured with the user’s selected VDS, and components for any supported / selected federated feature engineering operations. It also provides a handle to the “final_component” for integration with the user’s modeling components inside of the main function. In turn, the main function must add components to the partially completed pipe, pulling the final_component.output.data as input to the new components being added, then return two objects:

  • The completed pipe object (uncompiled; no need to call pipe.compile())
  • A dictionary of role to party id list mappings; {"guest": [9999], "host": [10000], "arbiter": [9999]}
def main(args, pipe, final_component):
    """Function used by LMF for training and analyzing federated pipeline models.

        Args:
            args (list): List of parameters selected within the JedAI client upon train job initialization.
            pipe (PipeLine): A partially completed Pipeline.
            final_component (component): A handle to the last component added to the partially completed Pipeline.

        Returns:
            Pipeline object (for training),
            Role / party id mapping dictionary object (for properly monitoring and handling the Pipeline)
    """

JedAI federated model visibility

After starting a federated model training, the Lucd platform actively retrieves metrics and status information from the local federate and surfaces them to the Unity client.

If the job fails, any available error messages will be surfaced to the user through the Training object status block just as it occurs with non-federated models (i.e., PyTorch, TensorFlow, Sklearn.) Note that as federated models train within separate servers running alongside the Lucd backend and separate federates, it is possible to reach a failure mode within those servers/federates requiring manual inspection of the deployment.

If the job succeeds, users will see metric data and plots generated by the model training displayed within the JedAI Unity client. The available metrics and plots depend on the type of model trained and the data accessible. Examples include loss curves, accuracy curves, ROC curves, mean squared error, precision & recall, and several other metrics. Note that unavailable information includes metrics related to portions of your federated model trained in other federates, but users may log into the other federates via JedAI to see available data.