Föderiertes Training mit LayoutXLM zur Verarbeitung komplexer Dokumente

  1. Ausgangssituation
    1. Dokumente bei CE
    2. Dokumente bei Fraunhofer
    3. Dokumentenanalyse mit LayoutXLM
    4. Vorgehen föderiertes Training
  2. Showcase
    1. Erzeugung der beteiligten Komponenten
    2. Jobs
    3. Server
    4. Administrator
    5. Clients
    6. Verteiltes Training
    7. Ergebnisse des Föderierten Trainings mit LayoutXLM und 5 Epochen

1 Ausgangssituation

  • Problem: Viele Kunden von CE (u.a. Versicherer) möchten moderne DeepLearning-Architekturen einsetzen, verfügen aber für sich allein nicht über genügend Daten und/oder können diese nicht mit CE teilen

  • Föderiertes Lernen ermöglicht dabei verschiedenen Kunden das Training gemeinsamer Modelle über CE, ohne dass Daten die eigenen Server verlassen

  • ControlExpert kann Expertise sammeln in der Entwicklung einer Open Source-Lösung zur einfachen Organisation moderner KI-Verfahren

Nach oben

1.1 Dokumente bei CE

Kostenvoranschlag (KVA)

  • Erstellt mit Kalkulationssoftware,

  • Wenig Varianz in Format

  • Kopf mit Halter und Fahrzeugdaten

  • Serien-/ und Sonderausstattung

  • Tabelle mit Reparaturkosten

  • Fotos

Gutachten

  • Viele verschiedene Formate

  • Ausführliche Beschreibung des Fahrzeugs und seines Zustands

  • Vorschäden, Wertminderung, Wiederbeschaffungswert

  • KVA

  • Fotos

Rechnung

  • Viele verschiedene Formate(15.000 Markenwerkstätten, 22.000 freie Werkstätten)

  • Rechnungskopf

  • Tabelle mit Reparaturkosten

  • Fotos

Herausforderungen

  • z.T. gescannte Dokumente von schlechter Qualität (geringe Auflösung, rotiert, …)

  • Im pdf sind oft viele zusätzliche Dokumente enthalten (z.B. Gutachten oder KVA in der Rechnungsprüfung)

  • Im pdf sind nur die für den jeweiligen Prozess relevanten Entitäten gelabelt (z.B. Rechnungsdatum auf separater Lackierrechnung ist nicht gelabelt)

  • Entitäten, die mehrmals auf dem Dokument vorhanden sind, sind nur an einer Stelle gelabelt.

→ verrauschte Daten, da eigentlich zu lernende Entitäten nicht überall gelabelt sind

Relevante Entitäten

Allgemeine Entitäten:

  • Kopfdaten

  • Einzelne Kostenpositionen

  • Gesamtkosten (Netto/Brutto)

  • Rechnungsdatum (nur bei Rechnungen)

Kfz-spezifische Entitäten:

  • Fahrzeuginformationen

  • Schadeninformationen

Nach oben

1.2 Dokumente bei Fraunhofer

Gesamtzahl der Dokumente in jeder Lieferung

Gesamtzahl der Dokumente in jeder Lieferung

Entitätshäufigkeit der 1. Lieferung

Entitätshäufigkeit der 2. Lieferung

Entitätshäufigkeit der 3. Lieferung

Einige annotierte Beispiele

Label Mapping

Nach oben

1.3 Dokumentenanalyse mit LayoutXLM

Quellen:

Wichtigste Eigenschaften
  • Transformer-based approach to extracting content from documents
  • Pretraining on unlabeled data
    • Multilingual Masked Visual-Language Modeling: Determine masked word based on surrounding words and layout/image features beforehand
    • Text-Image Alignment: Mask text on image.Model should determine for each word whether it is masked
    • Text-Image Matching: Determine whether text and image originate from the same document
  • Finetuning auf Downstream-Tasks
    • Z.B. Named Entity Recognition, Reading Order Detection, DocumentClassification,…
    • Gelabelte Daten notwendig
Verteiltes Training

Konzeption und Aufsetzen für ein verteiltes Training von KI-Modellen auf Basis eines FL Frameworks mit Betrachtung der verschiedenen Aspekte wie Management, Datenverteilung, Training, Validierung und Security.

Aufsetzen des Nvidia Flare Frameworks

  • Konfiguration der Cloud Services
  • Einrichtung Firewalls/Security
  • Konfiguration von Admins, Overseer, Clients, Statistics.

Bereitstellung eines DL/ML Frameworks

  • Anbindung von DL/ML Libraries
  • Integration von Tools für OCR, Graphische Analyse, NER, Tokenizer, GPU …
  • Einrichtung der Security Policies(Authentication, Encryption, Differential Privacy, Data Protection…)…

Definition von Trainingsworkflows

  • Bereitstellung Basis Modelle
  • Zusammenstellung Trainings-/Validierungsdaten für Clients
  • Definition Training-/update Strategie (Spread& Gather, Cyclic…)
  • Festlegung der Evaluations Strategie und Tools (Cross sitemodelvalidation, Global modelvalidation…)
  • FL Learning Algorithms(FedAvg, FedOpt, FedProx…

Weitere Informationen:
FedXtract Best Practice Guide

Nach oben

1.4 Vorgehen föderiertes Training

  • Ein Grundmodell wird gemeinsam mit allen drei Partner trainiert

  • Fraunhofer stellt Architektur und Skript zum Training bereit (in FL Framework)

  • Alle Partner trainieren Modell mit eigenen Daten und teilen Gewichte

    • allgemeines Training ohne spezielle Aufgaben (z.B. Vorhersage von nächstem Wort)

    • spezielles Training von gemeinsam definierten Feldern, z.B. Kopfdaten, Dokumentendatum, Betrag (Netto/Brutto)

    • Gemeinsame Experimente, z.B.

      • Kann man vom Training der anderen profitieren oder spezialisiert sich das Modell in eine falsche Richtung?

      • Wie viele Daten benötigt man?

    • Jeder kann Modell mit eigenen Feldern nachtrainieren, Modelle werden nicht geteilt

Datenvorbereitung
Datennormalisierung

  • Überführung in ein einheitliches Format

  • Aufteilung in Trainings-, Validierungs-und Testdatensätze von verschiedener Größe

Bereitstellung der Daten

Die Trainingsdaten von ControlExpert bestehen aus Paaren von PDF- und CSV-Dateien. Jedem dieser Datensätze wird eine eindeutige UUID zugewiesen. Der Zugriff auf die Trainingsdaten erfolgt über eine Indexdatei, die die oben genannten drei Elemente zusammenführt.

Es ist zu beachten, dass die Trainingsdaten in Form von mehrseitigen Dokumenten vorliegen, das Training jedoch seitenweise durchgeführt wird. Dies führt zu einer deutlich höheren Anzahl an Trainingsschritten im Vergleich zur Anzahl der vorhandenen Dokumente.

Diese Indexdatei wurde nachträglich in folgende Teile aufgespalten:

  • Train: 80 % der Dokumente, um das Modell zu trainieren.

  • Dev: 10 % der Dokumente, um das Modell während des Trainings zu evaluieren und den besten Checkpoint auszuwählen.

  • Test: 10 % der Dokumente, um den ausgewählten Checkpoint zu bewerten.

Des Weiteren wurden diese Teile in unterschiedliche Größen aufgeteilt, um die Möglichkeit zu haben, die Auswirkung von unterschiedlichen Datenmengen auf die Laufzeit zu untersuchen.

Die Fraunhofer-Trainingsdaten bestehen aus Paaren von JPG- und hocr-Dateien. Jeder dieser Datensätze ist mit einer eindeutigen UUID versehen. Der Zugriff auf die Trainingsdaten erfolgt über einen Datenlader

Es ist zu beachten, dass die Trainingsdaten in Form von einseitigen Dokumenten vorliegen.

  • Diese Indexdatei wurde anschließend in die folgenden Teile aufgeteilt:

  • Train: 80% der Dokumente zum Trainieren des Modells.

  • Dev: 10% der Dokumente, um das Modell während des Trainings zu evaluieren und den besten Kontrollpunkt auszuwählen.

  • Test: 10 % der Dokumente zur Bewertung des ausgewählten Prüfpunkts.

Die Entitäten des Fraunhofer-Datensatzes wurden mit den CE-Entitäten verknüpft.

Erster Test mit Layout-XLM

  • LayoutXLM ist ein vortrainiertes, frei verfügbares Sprachmodell

  • LayoutXLMwurde mit Dokumenten in 53 Sprachen (u.a. Deutsch) vortrainiert

  • Um Ansatz des föderierten Trainings zu testen, wurde LayoutXLM auf verschiedene Arten nachtrainiert

    • Fine Tuning ausschließlich mit Fraunhofer Dokumenten

    • Fine Tuning ausschließlich mit Dokumenten von CE

    • Zuerst Fine Tuning mit Fraunhofer Dokumenten, dann Fine Tuning mit Dokumenten von CE

  • Aufgabe: Vorhersage von Entitäten (z.B. Kopfdaten)

Nach oben

2 Showcase

Folgendes Beispiel zeigt ein verteiltes Training mit Nvidia FLARE für ein KI Modell auf vier Rechner: je eins für Server und Administrator und zwei für Clients.

Die Tabelle zeigt einen Überblick über die beteiligten Komponenten des Showcases

2.1 Erzeugung der beteiligten Komponenten

Die im Training beteiligten Komponenten werden zunächst in einer Yaml-Projekt-Datei als participants beschrieben:

participants:
  - name: fl-server.bmbf.aws.condat.de
    type: server
    org: condat
    fed_learn_port: 8002
    admin_port: 8003
  - name: client-fraunhofer
    type: client
    org: fraunhofer
    enable_byoc: true
  - name: client-controlexpert
    type: client
    org: controlexpert
    enable_byoc: true
  - name: admin@condat.de
    type: admin
    org: condat
    role: project_admin
...

enable_byoc -Parameter ermöglicht das Laden des Codes in das custom– Verzeichnis der jeweiligen Komponente.

Die weiteren Eigenschaften der Projektdatei können in der Online-Dokumentation von nvidia gefunden werden.

Die benötigten Federated Learning Komponenten werden mit dem Befehl

nvflare provision -p lxlm-fl.yml -w .

generiert. Das in NVFLARE implementierte Provisioning-Tool generiert aus der vorhandenen Projektdatei lxlm-fl.yml im aktuellen Verzeichnis ein Projektverzeichnis prod_0x und für jeden Participant wird je ein Unterverzeichnis angelegt:

  prod_00
  |-- admin@condat.de  
  |-- client-controlexpert  
  |-- client-fraunhofer  
  |-- fl-overseer.bmbf.aws.condat.de  
  |-- fl-server.bmbf.aws.condat.de

Jedes dieser Verzeichnisse erhält die gleiche Unterverzeichnisstruktur:

<Participant>
  |-- local
  |-- startup
  |-- transfer

Im Unterverzeichnis startupbefinden sich die generierten Zertifikate, die JSON-Kofiguration sowie ein Start- und ggf. ein Stop-Skript für die jeweilige Komponente. Die anderen Verzeichnisse werden wärend des Trainings verwendet.

Die einzelnen Komponenten des Federated Learning sind nun in der Lage miteinander zu kommunizieren, beihalten aber noch keine ML-Logik.

Die fünfte Komponente, der s.g. Overseer kommt dann zum Einsatz, wenn es in der System-Landschaft mehrere Server gibt.

Nach oben

2.2 Jobs

Die Trainingsfunktionalität wird bei NVFLARE in Jobs bzw. Apps definiert und von dem Admin-Client an die beteiligten Clients verteilt. Dazu wird folgende Verzeichnisstruktur angelegt:

<job>|-- <app>
    meta.json
    |-- config
        config_fed_client.json
        config_fed_server.json
    |-- custom
        ...
        <learner-implementierungsklasse(n)>
        ...</learner-implementierungsklasse(n)>...

Im Verzeichnis job wird eine Konfigurationsdatei meta.json erwartet, wo u.A. die minimale Anzahl der Clients definiert wird.

Im Verzeichnis configwerden zwei Konfigurationsdateien: config_fed_client.json mit Angabe der zu verwendeten Klasse und anderen Client-Konfigurationsparametern sowie config_fed_server.json Server-Konfigurationsparametern erwartet.

    ...
    "executors": [
     {
        "executor": {
          "id": "Executor",
          "path": "nvflare.app_common.executors.learner_executor.LearnerExecutor",
          "args": {
            "learner_id": "pt_learner"
          }
        }
      }
    ],
    "components": [
      {
        "id": "pt_learner",
        "path": "pt_learner.PTLearner",
        "args": {
          "lr": 0.01,
          "epochs": 5,
          "config_file": "config.yaml"
        }
      }
    ]

In der Server-Konfiguration werden die für das Training geplanten Prozesse (Workflows) festgelegt:

"workflows": [
        {
          "id": "scatter_and_gather",
          "name": "ScatterAndGather",
          "args": {
              "min_clients" : 2,
              "num_rounds" : 2,
              "start_round": 0,
              "wait_time_after_min_received": 10,
              "aggregator_id": "aggregator",
              "persistor_id": "persistor",
              "shareable_generator_id": "shareable_generator",
              "train_task_name": "train",
              "train_timeout": 0
          }
        },
        {
          "id": "cross_site_validate",
          "name": "CrossSiteModelEval",
          "args": {
            "model_locator_id": "model_locator"
          }
        }
    ]

Im Verzeichnis custom befinden sich die Python-Klassen, die die eigentliche Trainings-Logik implementieren. Dabei muß diejenige Klasse, die im config_fed_client.json als LearnerExecutor definiert wurde, die Learner-Schnittstelle implementieren.

Nach oben

Auf einem Server können gleichzeitig mehrere unterschiedliche Jobs/Apps gehostet werden.

2.3 Server

Die Aufgabe des FL-Servers ist es, die Clients nach ihrer Anmeldung zu registrieren und auf Befehl vom Admin-Client die Jobs an sie zu verteilen. Desweiteren hostet der Server das zentrale Modell sowie sammelt die Trainingsergebnisse von den beteiligten Clients ein. Daher wird diese Komponente als erste mit dem bereitgestellten Skript start.sh gestartet:

./start.sh

Darauf startet der Server seinen Runner-Prozess und wartet auf die Verbindungen mit den Clients:

2024-04-10 13:15:25,579 - runner_process - INFO - Runner_process started.
2024-04-10 13:15:25,687 - CoreCell - INFO - server.ae1f5aa0-4dfd-471b-9280-1d301da09966: created backbone internal connector to tcp://localhost:21680 on parent
2024-04-10 13:15:25,687 - nvflare.fuel.f3.sfm.conn_manager - INFO - Connector [CH00001 ACTIVE tcp://localhost:21680] is starting
2024-04-10 13:15:25,689 - Cell - INFO - Register blob CB for channel='server_command', topic='*'
2024-04-10 13:15:25,689 - Cell - INFO - Register blob CB for channel='aux_communication', topic='*'
2024-04-10 13:15:25,689 - ServerCommandAgent - INFO - ServerCommandAgent cell register_request_cb: server.ae1f5aa0-4dfd-471b-9280-1d301da09966
2024-04-10 13:15:25,691 - nvflare.fuel.f3.sfm.conn_manager - INFO - Connection [CN00002 127.0.0.1:56398 => 127.0.0.1:21680] is created: PID: 3099
2024-04-10 13:15:33,507 - ServerRunner - INFO - [identity=lxlm-fl, run=ae1f5aa0-4dfd-471b-9280-1d301da09966]: Server runner starting ...

Nachdem die Clients mit ihren Start-Skripten gestartet wurden, melden sie sich beim Server an:

2024-04-10 15:15:33,649 - Cell - INFO - broadcast: channel='aux_communication', topic='__sync_runner__', targets=['server.ae1f5aa0-4dfd-471b-9280-1d301da09966'], timeout=2.0
2024-04-10 15:15:33,786 - ClientRunner - INFO - [identity=client-controlexpert, run=ae1f5aa0-4dfd-471b-9280-1d301da09966]: synced to Server Runner in 6.017249345779419 seconds
2024-04-10 15:15:33,787 - ClientRunner - INFO - [identity=client-controlexpert, run=ae1f5aa0-4dfd-471b-9280-1d301da09966]: client runner started

Nach oben

2.4 Administrator

Der Admin-Client meldet sich ebenfalls beim Server an:

(nvflare-env) >.../lxlm-fl/prod_00/admin@condat.de/startup$ ./fl_admin.sh
User Name: admin@condat.de
Trying to obtain server address
Obtained server address: fl-server.bmbf.aws.condat.de:8003
Trying to login, please wait ...
Logged into server at fl-server.bmbf.aws.condat.de:8003 with SSID: abcdef

Der Admin-Client verfügt über eine Liste der Befehle, die zum einen den Überblick über den Serverstatus geben und zum Anderen die Prozesse auf dem Server initiieren können. So können z.B. die verbundenen Clients ermittelt werden:

> check_status server
Engine status: stopped
---------------------
| JOB_ID | APP NAME |
---------------------
---------------------
Registered clients: 2
------------------------------------------------------------------------------------------
| CLIENT               | TOKEN                                | LAST CONNECT TIME        |
------------------------------------------------------------------------------------------
| client-fraunhofer    | 562be09c-9120-4640-9295-e70cd7dadef1 | Wed Apr 10 13:14:37 2024 |
| client-controlexpert | 952c74bd-9b72-40fe-adba-031212f22277 | Wed Apr 10 13:14:29 2024 |
------------------------------------------------------------------------------------------
Done [236105 usecs] 2024-04-10 15:14:39.018338

Nach oben

2.5 Clients

Das folgende Klassendiagramm gibt eine Übersicht über die Architektur der föderierten Clients. Zu beachten ist, dass abhängig von der Umgebung jeweils nur eine Instanz des Datensatzes verwendet wird: entweder CeDataset bei ControlExpert oder LayoutLMDataset bei Fraunhofer.

PTLearner

Die Klasse PTLearner ist eine Implementierung eines Lerners für das Training von maschinellen Lernmodellen mit PyTorch im Kontext von federiertem Lernen unter Verwendung von NVIDIA FLARE. Hier ist eine kurze Zusammenfassung dessen, was die Klasse macht:

  • Initialisierung: Beim Erstellen einer Instanz von PTLearner werden verschiedene Parameter wie Lernrate, Anzahl der Epochen und Ausschlussvariablen festgelegt. Es wird auch eine Konfigurationsdatei verwendet, um das Training zu konfigurieren.

  • Trainingseinrichtung: In der Methode initialize wird die Umgebung für das Training eingerichtet, einschließlich der Definition des Modells, des Datenprozessors, des Datasets und des Datenladens.

  • Federiertes Training: Die train-Methode wird verwendet, um das Modell lokal auf den Daten eines Clients zu trainieren. Nach dem Training werden die aktualisierten Modellgewichte an den Server zurückgesendet.

  • Lokales Training: Die local_train-Methode führt das eigentliche Training des Modells durch, wobei ein Abbruchsignal berücksichtigt wird, das das Training vorzeitig beenden kann.

  • Validierung: Die validate-Methode wird verwendet, um das Modell auf einem Validierungsdatensatz zu testen und die Genauigkeit zu bewerten.

Insgesamt ermöglicht die Klasse PTLearner das Training und die Validierung eines PyTorch-Modells in einer verteilten Umgebung, wobei die Privatsphäre der Daten durch federiertes Lernen gewahrt wird.

Federated Trainer

  • Signal-Handling: Die Klasse nimmt ein optionales Signal-Objekt entgegen, das genutzt wird, um das Training frühzeitig zu beenden, falls nötig.

  • Trainingsloop: Die Methode _inner_training_loop ist für das Durchführen des eigentlichen Trainings verantwortlich. Sie behandelt die Initialisierung des Trainings, das Durchlaufen der Trainingsdaten und die Aktualisierung der Modellgewichte.

  • Datensammler: Die Klasse verwendet verschiedene Arten von Datensammlern (DataLoader), um die Trainingsdaten zu verarbeiten. Dies kann ein RandomSampler oder ein DistributedSampler sein, abhängig von der Konfiguration und dem Einsatz von Distributed Training.

  • Verteiltes Training: Die Klasse unterstützt verteiltes Training, was für das federierte Lernen wichtig ist, da es das Training über mehrere Maschinen hinweg ermöglicht.

  • Gradientenakkumulation: Es wird die Möglichkeit geboten, Gradienten über mehrere Schritte zu akkumulieren, bevor ein Optimierungsschritt durchgeführt wird. Dies ist nützlich, wenn man mit sehr großen Modellen oder Batch-Größen arbeitet, die nicht in den Speicher einer einzelnen GPU passen.

  • Trainingsstatus und -metriken: Während des Trainings wird der Trainingsstatus, einschließlich der Anzahl der durchgeführten Schritte und Epochen, sowie Metriken wie die Trainingsloss und die Accuracy des Trainings, verfolgt.

Insgesamt ermöglicht die FederatedTrainer-Klasse das effiziente und effektive Training von Modellen unter den Bedingungen des federierten Lernens, wobei die Daten auf den lokalen Geräten der Teilnehmer bleiben und nur die Modellaktualisierungen zwischen den Teilnehmern und dem zentralen Server ausgetauscht werden.

LayoutXLMWrapper

Die Klasse LayoutXLMWrapper ist eine einfache Wrapper-Klasse für das LayoutXLM Modell aus der Huggingface Transformers-Bibliothek. Sie initialisiert das Modell mit einer vorgegebenen Anzahl von Labels und einem Modellnamen. Die forward-Methode leitet die Eingabedaten an das Modell weiter und gibt die Ausgabe zurück.

CEDataset

Die Klasse CeDataset ist ein benutzerdefiniertes PyTorch Dataset, das speziell für das Laden und Vorbereiten von Daten für das Training von Modellen mit ControlExpert-Daten konzipiert ist. Hier sind die Hauptfunktionen dieser Klasse:

  • Initialisierung: Beim Erstellen einer Instanz des CeDataset werden der Pfad zur Indexdatei, der Datenverzeichnispfad, ein Datenprozessor und optionale Parameter wie die maximale Sequenzlänge übergeben.

  • Datenladen: Die Methode load_data lädt die Daten aus einer Indexdatei und begrenzt die Anzahl der Fälle, wenn eine maximale Anzahl (max_cases) angegeben ist.

  • Textdaten verarbeiten: Die read_text_item-Methode liest und verarbeitet OCR-Daten für einzelne Fälle, indem sie Informationen wie Wörter und Bounding-Box-Koordinaten extrahiert und entsprechende Labels zuweist.

  • Bildverarbeitung: Die raster_page-Methode konvertiert PDF-Seiten in Bilder, die dann als Eingabe für das Modell verwendet werden können.

  • Elementzugriff: Die __getitem__-Methode wird aufgerufen, um ein einzelnes Trainingsbeispiel zu erhalten. Sie bereitet die Daten für das Modell vor, indem sie Text und Bildinformationen verarbeitet und in das richtige Format bringt, das für das Training erforderlich ist.

Insgesamt dient CeDataset dazu, ControlExpert-Daten für das Training von Modellen im Bereich des maschinellen Sehens und der Textverarbeitung aufzubereiten.

LayoutLMDataset

Die Klasse LayoutLMDataset ist ein PyTorch Dataset, das für das Laden und Vorbereiten von Trainingsdaten für das LayoutLM-Modell verwendet wird. Diese Daten stammen vom Fraunhofer-Institut und enthalten Informationen für das Training von Modellen, die sich mit der Verarbeitung von Dokumentenlayout und Named Entity Recognition (NER) befassen. Hier sind die Hauptfunktionen der Klasse:

  • Initialisierung: Die Klasse wird mit Listen von Wörtern, Bounding-Box-Koordinaten, NER-Tags, Bildpfaden und einem Datenprozessor initialisiert.

  • Länge: Die __len__-Methode gibt die Anzahl der Beispiele im Dataset zurück, die der Anzahl der Bildpfade entspricht.

  • Elementzugriff: Die __getitem__-Methode wird aufgerufen, um ein einzelnes Trainingsbeispiel zu erhalten. Sie lädt das Bild, wendet den Prozessor an, um die Eingabedaten zu kodieren, und gibt ein Sample-Dictionary zurück, das die kodierten Informationen wie Bild, Input-IDs, Masken, Bounding-Box-Koordinaten und Labels enthält.

Die Klasse LayoutLMDataset ermöglicht es, strukturierte Daten für das Training von Modellen zur Dokumentenanalyse aufzubereiten und zu verwenden, indem sie visuelle und textuelle Informationen kombiniert.

Nach oben

2.6 Verteiltes Training

Haben sich genügend Clients beim Administrator angemeldet, dann kann das Training beginnen:

> submit_job ../../../../job
Submitted job: ae1f5aa0-4dfd-471b-9280-1d301da09966
Done [414539 usecs] 2024-04-10 15:15:21.706632

Der Admin-Client verteilt dabei den im Verzeichnis job befindlichen Code über den Server an die beiden Clients:

2024-04-10 13:15:33,508 - ServerRunner - INFO - [identity=lxlm-fl, run=ae1f5aa0-4dfd-471b-9280-1d301da09966]: starting workflow scatter_and_gather (<class 'nvflare.app_common.workflows.scatter_and_gather.scatterandgather'="">) ...
2024-04-10 13:15:33,508 - ScatterAndGather - INFO - [identity=lxlm-fl, run=ae1f5aa0-4dfd-471b-9280-1d301da09966, wf=scatter_and_gather]: Initializing ScatterAndGather workflow.
2024-04-10 13:15:33,509 - PTFileModelPersistor - INFO - [identity=lxlm-fl, run=ae1f5aa0-4dfd-471b-9280-1d301da09966, wf=scatter_and_gather]: Both source_ckpt_file_full_name and ckpt_preload_path are not provided. Using the default model weights initialized on the persistor side.
2024-04-10 13:15:33,521 - ServerRunner - INFO - [identity=lxlm-fl, run=ae1f5aa0-4dfd-471b-9280-1d301da09966, wf=scatter_and_gather]: Workflow scatter_and_gather (<class 'nvflare.app_common.workflows.scatter_and_gather.scatterandgather'="">) started
2024-04-10 13:15:33,521 - ScatterAndGather - INFO - [identity=lxlm-fl, run=ae1f5aa0-4dfd-471b-9280-1d301da09966, wf=scatter_and_gather]: Beginning ScatterAndGather training phase.
2024-04-10 13:15:33,522 - ScatterAndGather - INFO - [identity=lxlm-fl, run=ae1f5aa0-4dfd-471b-9280-1d301da09966, wf=scatter_and_gather]: Round 0 started.
2024-04-10 13:15:33,522 - ScatterAndGather - INFO - [identity=lxlm-fl, run=ae1f5aa0-4dfd-471b-9280-1d301da09966, wf=scatter_and_gather]: scheduled task train
2024-04-10 13:15:33,634 - ServerRunner - INFO - [identity=lxlm-fl, run=ae1f5aa0-4dfd-471b-9280-1d301da09966, wf=scatter_and_gather, peer=client-fraunhofer, peer_run=ae1f5aa0-4dfd-471b-9280-1d301da09966, task_name=train, task_id=2e05b479-8196-40a3-bad0-37140a6e57cc]: assigned task to client client-fraunhofer: name=train, id=2e05b479-8196-40a3-bad0-37140a6e57cc
2024-04-10 13:15:33,635 - ServerRunner - INFO - [identity=lxlm-fl, run=ae1f5aa0-4dfd-471b-9280-1d301da09966, wf=scatter_and_gather, peer=client-fraunhofer, peer_run=ae1f5aa0-4dfd-471b-9280-1d301da09966, task_name=train, task_id=2e05b479-8196-40a3-bad0-37140a6e57cc]: sent task assignment to client. client_name:client-fraunhofer task_id:2e05b479-8196-40a3-bad0-37140a6e57cc
2024-04-10 13:15:33,635 - GetTaskCommand - INFO - return task to client.  client_name: client-fraunhofer  task_name: train   task_id: 2e05b479-8196-40a3-bad0-37140a6e57cc  sharable_header_task_id: 2e05b479-8196-40a3-bad0-37140a6e57cc
2024-04-10 13:15:33,888 - ServerRunner - INFO - [identity=lxlm-fl, run=ae1f5aa0-4dfd-471b-9280-1d301da09966, wf=scatter_and_gather, peer=client-controlexpert, peer_run=ae1f5aa0-4dfd-471b-9280-1d301da09966, task_name=train, task_id=996e2a83-dcb5-4301-8a06-ce8397760616]: assigned task to client client-controlexpert: name=train, id=996e2a83-dcb5-4301-8a06-ce8397760616
2024-04-10 13:15:33,953 - ServerRunner - INFO - [identity=lxlm-fl, run=ae1f5aa0-4dfd-471b-9280-1d301da09966, wf=scatter_and_gather, peer=client-controlexpert, peer_run=ae1f5aa0-4dfd-471b-9280-1d301da09966, task_name=train, task_id=996e2a83-dcb5-4301-8a06-ce8397760616]: sent task assignment to client. client_name:client-controlexpert task_id:996e2a83-dcb5-4301-8a06-ce8397760616
2024-04-10 13:15:34,050 - GetTaskCommand - INFO - return task to client.  client_name: client-controlexpert  task_name: train   task_id: 996e2a83-dcb5-4301-8a06-ce8397760616  sharable_header_task_id: 996e2a83-dcb5-4301-8a06-ce8397760616

Der Controlexpert-Client meldet dann auf seiner Console, dass er mit dem Training beginnt:

2024-04-10 15:16:18,720 - Communicator - INFO - Received from lxlm-fl server. getTask: train size: 1.5GB (1476573387 Bytes) time: 44.931915 seconds
2024-04-10 15:16:18,720 - FederatedClient - INFO - pull_task completed. Task name:train Status:True 
2024-04-10 15:16:18,720 - ClientRunner - INFO - [identity=client-controlexpert, run=ae1f5aa0-4dfd-471b-9280-1d301da09966, peer=lxlm-fl, peer_run=ae1f5aa0-4dfd-471b-9280-1d301da09966]: got task assignment: name=train, id=996e2a83-dcb5-4301-8a06-ce8397760616
2024-04-10 15:16:18,721 - ClientRunner - INFO - [identity=client-controlexpert, run=ae1f5aa0-4dfd-471b-9280-1d301da09966, peer=lxlm-fl, peer_run=ae1f5aa0-4dfd-471b-9280-1d301da09966, task_name=train, task_id=996e2a83-dcb5-4301-8a06-ce8397760616]: invoking task executor LearnerExecutor
2024-04-10 15:16:18,721 - LearnerExecutor - INFO - [identity=client-controlexpert, run=ae1f5aa0-4dfd-471b-9280-1d301da09966, peer=lxlm-fl, peer_run=ae1f5aa0-4dfd-471b-9280-1d301da09966, task_name=train, task_id=996e2a83-dcb5-4301-8a06-ce8397760616]: Client trainer got task: train
Loading data from index_1000_train.csv: 100% 1/1 [00:00<00:00,  2.47it/s]
2024-04-10 13:16:20.572 CeDataset initialized with 1288 pages from index_1000_train.csv self.max_cases=100

Nach jedem Trainingsdurchlauf senden die Clients ihre Ergebnisse an den Server zurück:

2024-04-10 15:23:15,270 - ClientRunner - INFO - [identity=client-controlexpert, run=ae1f5aa0-4dfd-471b-9280-1d301da09966, peer=lxlm-fl, peer_run=ae1f5aa0-4dfd-471b-9280-1d301da09966, task_name=train, task_id=996e2a83-dcb5-4301-8a06-ce8397760616]: finished processing task
2024-04-10 15:23:15,270 - ClientRunner - INFO - [identity=client-controlexpert, run=ae1f5aa0-4dfd-471b-9280-1d301da09966, peer=lxlm-fl, peer_run=ae1f5aa0-4dfd-471b-9280-1d301da09966, task_name=train, task_id=996e2a83-dcb5-4301-8a06-ce8397760616]: try #1: sending task result to server
2024-04-10 15:23:15,270 - ClientRunner - INFO - [identity=client-controlexpert, run=ae1f5aa0-4dfd-471b-9280-1d301da09966, peer=lxlm-fl, peer_run=ae1f5aa0-4dfd-471b-9280-1d301da09966, task_name=train, task_id=996e2a83-dcb5-4301-8a06-ce8397760616]: checking task ...
2024-04-10 15:23:15,270 - Cell - INFO - broadcast: channel='aux_communication', topic='__task_check__', targets=['server.ae1f5aa0-4dfd-471b-9280-1d301da09966'], timeout=5.0
2024-04-10 15:23:15,304 - ClientRunner - INFO - [identity=client-controlexpert, run=ae1f5aa0-4dfd-471b-9280-1d301da09966, peer=lxlm-fl, peer_run=ae1f5aa0-4dfd-471b-9280-1d301da09966, task_name=train, task_id=996e2a83-dcb5-4301-8a06-ce8397760616]: start to send task result to server
2024-04-10 15:23:15,305 - FederatedClient - INFO - Starting to push execute result.
2024-04-10 15:31:31,604 - Communicator - INFO -  SubmitUpdate size: 1.5GB (1476573439 Bytes). time: 496.298949 seconds
2024-04-10 15:31:31,710 - ClientRunner - INFO - [identity=client-controlexpert, run=ae1f5aa0-4dfd-471b-9280-1d301da09966, peer=lxlm-fl, peer_run=ae1f5aa0-4dfd-471b-9280-1d301da09966, task_name=train, task_id=996e2a83-dcb5-4301-8a06-ce8397760616]: task result sent to server

Der Server empfängt die Ergebnisse von jedem Client und aggregiert sie:

2024-04-10 13:30:14,615 - ServerRunner - INFO - [identity=lxlm-fl, run=ae1f5aa0-4dfd-471b-9280-1d301da09966, wf=scatter_and_gather, peer=client-fraunhofer, peer_run=ae1f5aa0-4dfd-471b-9280-1d301da09966]: got result from client client-fraunhofer for task: name=train, id=2e05b479-8196-40a3-bad0-37140a6e57cc
...
2024-04-10 13:31:31,668 - ScatterAndGather - INFO - [identity=lxlm-fl, run=ae1f5aa0-4dfd-471b-9280-1d301da09966, wf=scatter_and_gather]: Start aggregation.
2024-04-10 13:31:31,668 - DXOAggregator - INFO - [identity=lxlm-fl, run=ae1f5aa0-4dfd-471b-9280-1d301da09966, wf=scatter_and_gather]: aggregating 2 update(s) at round 0
2024-04-10 13:31:32,444 - ScatterAndGather - INFO - [identity=lxlm-fl, run=ae1f5aa0-4dfd-471b-9280-1d301da09966, wf=scatter_and_gather]: End aggregation.
2024-04-10 13:31:32,445 - ScatterAndGather - INFO - [identity=lxlm-fl, run=ae1f5aa0-4dfd-471b-9280-1d301da09966, wf=scatter_and_gather]: Start persist model on server.
2024-04-10 13:31:34,510 - ScatterAndGather - INFO - [identity=lxlm-fl, run=ae1f5aa0-4dfd-471b-9280-1d301da09966, wf=scatter_and_gather]: End persist model on server.
2024-04-10 13:31:34,510 - ScatterAndGather - INFO - [identity=lxlm-fl, run=ae1f5aa0-4dfd-471b-9280-1d301da09966, wf=scatter_and_gather]: Round 0 finished.

Unmittelbar danach startet der Sever den nächsten Trainingsdurchlauf.

Nach dem Durchlaufen aller definierten Trainingszyklen/Epochen beginnt die Validierung der Ergebnisse:

2024-04-10 13:53:46,727 - CrossSiteModelEval - INFO - [identity=lxlm-fl, run=ae1f5aa0-4dfd-471b-9280-1d301da09966, wf=cross_site_validate]: Beginning model validation with clients: ['client-fraunhofer', 'client-controlexpert'].
2024-04-10 13:53:46,727 - CrossSiteModelEval - INFO - [identity=lxlm-fl, run=ae1f5aa0-4dfd-471b-9280-1d301da09966, wf=cross_site_validate]: scheduled task submit_model
2024-04-10 13:53:46,727 - CrossSiteModelEval - INFO - [identity=lxlm-fl, run=ae1f5aa0-4dfd-471b-9280-1d301da09966, wf=cross_site_validate]: Locating server models.
2024-04-10 13:53:46,973 - ServerRunner - INFO - [identity=lxlm-fl, run=ae1f5aa0-4dfd-471b-9280-1d301da09966, wf=cross_site_validate, peer=client-controlexpert, peer_run=ae1f5aa0-4dfd-471b-9280-1d301da09966, task_name=submit_model, task_id=64d6759e-7eff-424b-8a0c-b093df6ffb6b]: assigned task to client client-controlexpert: name=submit_model, id=64d6759e-7eff-424b-8a0c-b093df6ffb6b
2024-04-10 13:53:46,974 - ServerRunner - INFO - [identity=lxlm-fl, run=ae1f5aa0-4dfd-471b-9280-1d301da09966, wf=cross_site_validate, peer=client-controlexpert, peer_run=ae1f5aa0-4dfd-471b-9280-1d301da09966, task_name=submit_model, task_id=64d6759e-7eff-424b-8a0c-b093df6ffb6b]: sent task assignment to client. client_name:client-controlexpert task_id:64d6759e-7eff-424b-8a0c-b093df6ffb6b
2024-04-10 13:53:46,975 - GetTaskCommand - INFO - return task to client.  client_name: client-controlexpert  task_name: submit_model   task_id: 64d6759e-7eff-424b-8a0c-b093df6ffb6b  sharable_header_task_id: 64d6759e-7eff-424b-8a0c-b093df6ffb6b
2024-04-10 13:53:47,170 - ServerRunner - INFO - [identity=lxlm-fl, run=ae1f5aa0-4dfd-471b-9280-1d301da09966, wf=cross_site_validate, peer=client-fraunhofer, peer_run=ae1f5aa0-4dfd-471b-9280-1d301da09966, task_name=submit_model, task_id=9f8992df-42eb-4a77-b4d2-c9bfdaaf0f53]: assigned task to client client-fraunhofer: name=submit_model, id=9f8992df-42eb-4a77-b4d2-c9bfdaaf0f53
2024-04-10 13:53:47,171 - ServerRunner - INFO - [identity=lxlm-fl, run=ae1f5aa0-4dfd-471b-9280-1d301da09966, wf=cross_site_validate, peer=client-fraunhofer, peer_run=ae1f5aa0-4dfd-471b-9280-1d301da09966, task_name=submit_model, task_id=9f8992df-42eb-4a77-b4d2-c9bfdaaf0f53]: sent task assignment to client. client_name:client-fraunhofer task_id:9f8992df-42eb-4a77-b4d2-c9bfdaaf0f53
2024-04-10 13:53:47,171 - GetTaskCommand - INFO - return task to client.  client_name: client-fraunhofer  task_name: submit_model   task_id: 9f8992df-42eb-4a77-b4d2-c9bfdaaf0f53  sharable_header_task_id: 9f8992df-42eb-4a77-b4d2-c9bfdaaf0f53
2024-04-10 13:53:53,090 - CrossSiteModelEval - INFO - [identity=lxlm-fl, run=ae1f5aa0-4dfd-471b-9280-1d301da09966, wf=cross_site_validate]: Server models loaded: ['SRV_FL_global_model.pt'].
2024-04-10 13:53:53,165 - CrossSiteModelEval - INFO - [identity=lxlm-fl, run=ae1f5aa0-4dfd-471b-9280-1d301da09966, wf=cross_site_validate]: Sending SRV_FL_global_model.pt model to all participating clients for validation.
2024-04-10 13:53:53,167 - CrossSiteModelEval - INFO - [identity=lxlm-fl, run=ae1f5aa0-4dfd-471b-9280-1d301da09966, wf=cross_site_validate]: scheduled task validate

Die Clients erhalten das entsprechende Model dazu:

2024-04-10 15:53:46,990 - Communicator - INFO - Received from lxlm-fl server. getTask: submit_model size: 568B (568 Bytes) time: 0.034332 seconds
2024-04-10 15:53:46,991 - FederatedClient - INFO - pull_task completed. Task name:submit_model Status:True

Die Validierungsergebnisse werden ebenfalls zum Server zurückgeschickt:

2024-04-10 15:53:48,488 - FederatedClient - INFO - Starting to push execute result.
2024-04-10 16:02:18,797 - Communicator - INFO -  SubmitUpdate size: 1.5GB (1476573384 Bytes). time: 510.308219 seconds
2024-04-10 16:02:18,884 - ClientRunner - INFO - [identity=client-controlexpert, run=ae1f5aa0-4dfd-471b-9280-1d301da09966, peer=lxlm-fl, peer_run=ae1f5aa0-4dfd-471b-9280-1d301da09966, task_name=submit_model, task_id=64d6759e-7eff-424b-8a0c-b093df6ffb6b]: task result sent to server
2024-04-10 16:03:04,541 - Communicator - INFO - Received from lxlm-fl server. getTask: validate size: 1.5GB (1476573346 Bytes) time: 43.601636 seconds
2024-04-10 16:03:04,542 - FederatedClient - INFO - pull_task completed. Task name:validate Status:True 
2024-04-10 16:03:04,542 - ClientRunner - INFO - [identity=client-controlexpert, run=ae1f5aa0-4dfd-471b-9280-1d301da09966, peer=lxlm-fl, peer_run=ae1f5aa0-4dfd-471b-9280-1d301da09966]: got task assignment: name=validate, id=a6381707-53dd-420b-ab47-77c3d83712a8

Der Empfang aller Validierungsergebnisse quittert das Ende des kompletten Trainings auf dem Server:

2024-04-10 14:08:28,355 - CrossSiteModelEval - INFO - [identity=lxlm-fl, run=ae1f5aa0-4dfd-471b-9280-1d301da09966, wf=cross_site_validate]: task validate exit with status TaskCompletionStatus.OK
2024-04-10 14:08:28,837 - ServerRunner - INFO - [identity=lxlm-fl, run=ae1f5aa0-4dfd-471b-9280-1d301da09966, wf=cross_site_validate]: Workflow: cross_site_validate finalizing ...
2024-04-10 14:08:28,857 - ServerRunner - INFO - [identity=lxlm-fl, run=ae1f5aa0-4dfd-471b-9280-1d301da09966, wf=cross_site_validate]: ABOUT_TO_END_RUN fired
2024-04-10 14:08:28,858 - ServerRunner - INFO - [identity=lxlm-fl, run=ae1f5aa0-4dfd-471b-9280-1d301da09966, wf=cross_site_validate]: Firing CHECK_END_RUN_READINESS ...
2024-04-10 14:08:28,863 - ServerRunner - INFO - [identity=lxlm-fl, run=ae1f5aa0-4dfd-471b-9280-1d301da09966, wf=cross_site_validate]: END_RUN fired
2024-04-10 14:08:28,863 - ServerRunner - INFO - [identity=lxlm-fl, run=ae1f5aa0-4dfd-471b-9280-1d301da09966, wf=cross_site_validate]: Server runner finished.
2024-04-10 14:08:30,274 - FederatedServer - INFO - Server app stopped.

Die Ergebnisse des Trainings können nun analysiert werden.

Nach Abschluß eines Trainings kann das Ergebnis heruntergeladen werden.

> list_jobs
------------------------------------------------------------------------------------------------------------------------------------------------
| JOB ID                               | NAME               | STATUS                       | SUBMIT TIME                      | RUN DURATION   |
------------------------------------------------------------------------------------------------------------------------------------------------
| ae1f5aa0-4dfd-471b-9280-1d301da09966 | layoutxlm-on-flare | FINISHED:COMPLETED           | 2024-04-10T13:15:21.683784+00:00 | 0:53:10.645112 |
------------------------------------------------------------------------------------------------------------------------------------------------
Done [222535 usecs] 2024-04-10 16:08:53.364245
> download_job ae1f5aa0-4dfd-471b-9280-1d301da09966
downloading job.zip ...
downloaded job.zip (87446 bytes) in 0.3846409320831299 seconds
downloading meta.json ...
downloaded meta.json (682 bytes) in 0.2960479259490967 seconds
downloading workspace.zip ...

Die heruntergeladene Datei enthält u.A. folgende Dateien und Unterverzeichnisse:Zwei Clients:

  • Laden des Modells: Abbas, Alex

  • Training mit lokalen Daten

  • Versenden der veränderten Gewichtungen des Modells an den Server

Nach oben

2.7 Ergebnisse des Föderierten Trainings mit LayoutXLM und 5 Epochen

Nach oben