Utilisez les Mods intégrées

Note

Ce tutoriel couvre des fonctionnalités de prévisualisation. La fonctionnalité et les interfaces peuvent changer dans les futures versions.

Dans ce tutoriel, nous allons apprendre à utiliser les mods intégrés pour augmenter le comportement d’un ClientApp. Les mods (parfois appelés Modifiers) nous permettent de réaliser des opérations avant et après une tâche est traitée dans le ClientApp.

Qu’est-ce qu’un Mod ?

Un mod est un appelable qui enveloppe autour d’un ClientApp. Il peut manipuler ou inspecter les entrées Message et les sorties résultantes Message. La signature pour un mod est la suivante:

ClientAppCallable = Callable[[Message, Context], Message]
Mod = Callable[[Message, Context, ClientAppCallable], Message]

Une fonction mod typique pourrait ressembler à ceci :

from flwr.app import Context, Message
from flwr.clientapp.typing import ClientAppCallable


def example_mod(msg: Message, ctx: Context, call_next: ClientAppCallable) -> Message:
    # Do something with incoming Message (or Context)
    # before passing it to the next layer in the chain.
    # This could be another Mod or, if this is the last Mod, the ClientApp itself.
    msg = call_next(msg, ctx)
    # Do something with outgoing Message (or Context)
    # before returning
    return msg

Utiliser les Mods

Les mods peuvent être enregistrés de deux manières : Mods d’application et Mods spécifiques à une fonction.

  1. Mods applicatifs : ces mods s’appliquent à toutes les fonctions au sein du ClientApp.

  2. Mods spécifiques à une fonction : Ces mods s’appliquent uniquement à une fonction spécifique (par exemple, la fonction décorée par @app.train())

1. Enregistrer les Mods d’Application

Pour utiliser des mods applicatifs dans votre ClientApp, suivez ces étapes :

Importez les mods requis

import flwr as fl
from flwr.clientapp.mod import example_mod_1, example_mod_2

Créez le ClientApp avec des mods applicatifs

Créez votre ClientApp et passez les mods en tant que liste à l’argument mods. L’ordre dans lequel vous fournissez les mods compte :

app = fl.clientapp.ClientApp(
    mods=[
        example_mod_1,  # Application-wide Mod 1
        example_mod_2,  # Application-wide Mod 2
    ],
)

2. Inscription de Fonctions spécifiques Mods

Au lieu d’appliquer des mods au ClientApp entier, vous pouvez spécifier ceux-ci pour une fonction particulière :

import flwr as fl
from flwr.clientapp.mod import example_mod_3, example_mod_4

app = fl.clientapp.ClientApp()


@app.train(mods=[example_mod_3, example_mod_4])
def train(msg, ctx):
    # Training logic here
    return reply_msg


@app.evaluate()
def evaluate(msg, ctx):
    # Evaluation logic here
    return reply_msg

Dans ce cas, seuls example_mod_3 et example_mod_4 sont appliqués à la fonction train.

Ordre d’exécution

Lorsque le ClientApp s’exécute, les mods exécutent dans l’ordre suivant :

  1. Mods applicatifs (exécutés en premier, dans l’ordre où ils sont fournis)

  2. Mods fonctionnels (exécutés après les mods applicatifs, dans l’ordre où ils sont fournis)

  3. ClientApp (fonction de base qui gère les entrées Message et retourne les sorties résultantes Message)

  4. Mods fonctionnels (en cours de retour, dans l’ordre inverse)

  5. Mods applicatifs (en cours de retour, dans l’ordre inverse)

Chaque mod a la possibilité d’inspecter et modifier les entrées Message avant de passer à l’autre mod, et de même avec les sorties Message avant de les renvoyer vers le haut.

Flux d’exécution d’exemple

En supposant la suivante inscription :

app = fl.clientapp.ClientApp(mods=[example_mod_1, example_mod_2])


@app.train(mods=[example_mod_3, example_mod_4])
def train(msg, ctx):
    return Message(fl.app.RecordDict(), reply_to=msg)


@app.evaluate()
def evaluate(msg, ctx):
    return Message(fl.app.RecordDict(), reply_to=msg)

L’ordre d’exécution pour un message train entrant est le suivant :

  1. example_mod_1 (before handling)

  2. example_mod_2 (before handling)

  3. example_mod_3 (before handling)

  4. example_mod_4 (before handling)

  5. train (handling message)

  6. example_mod_4 (after handling)

  7. example_mod_3 (after handling)

  8. example_mod_2 (after handling)

  9. example_mod_1 (after handling)

L’ordre d’exécution pour un message évaluation entrant est le suivant :

  1. example_mod_1 (before handling)

  2. example_mod_2 (before handling)

  3. evaluate (handling message)

  4. example_mod_2 (after handling)

  5. example_mod_1 (after handling)

Conclusion

En suivant ce guide, vous avez appris comment utiliser efficacement les mods pour améliorer la fonctionnalité de votre ClientApp . N’oubliez pas que l’ordre des mods est crucial et affecte la manière dont les entrées et sorties sont traitées.

Profitez de la construction d’un ClientApp plus robuste et flexible avec des mods !