Uczenie federacyjne dla AI wojskowego: dane niejawne bez centralizacji

Centralnym paradoksem treningu AI wojskowego jest to, że dane, które najbardziej poprawiłyby wydajność operacyjną modelu, są dokładnie tymi danymi, których nie można przenieść. Niejawne dzienniki czujników, obrazowanie ISR z aktywnych teatrów działań, zapisy elektronicznego porządku bitwy oraz zbiory danych partnerów sojuszniczych istnieją za granicami kompartmentów, które czynią konwencjonalny trening centralny niemożliwym. Uczenie federacyjne rozwiązuje ten paradoks, odwracając paradygmat treningu: zamiast przenosić dane do modelu, model idzie do danych. Każda uczestnicząca organizacja trenuje lokalnie na własnym niejawnym korpusie i udostępnia wyłącznie aktualizacje gradientów — pochodne matematyczne poprawiające model globalny bez ujawniania leżących u podstaw próbek treningowych. Artykuł ten omawia pełny stos inżynierski wdrażania uczenia federacyjnego w środowiskach obronnych — od doboru topologii federacji przez kalibrację prywatności różnicowej, bezpieczną agregację, asynchroniczną eksploatację taktyczną po łagodzenie zagrożeń odpornych bizantyjsko.

Dlaczego uczenie federacyjne dla obronności — suwerenność danych między dowództwami, bariera klauzulowa i świeżość modelu na krawędzi

Wojskowe dane treningowe AI są rozłożone w silosach organizacyjnych z zamysłu, nie przez przypadek. Polityka klauzul, uprawnienia prawne i wymagania bezpieczeństwa operacyjnego tworzą twarde granice między organizacjami będącymi właścicielami danych. Obrazowanie ISR Dowództwa Operacji Specjalnych nie może zostać przesłane do infrastruktury treningowej sił konwencjonalnych bez przejścia kontroli dostępu do kompartmentów, które mogą zająć miesiące — o ile ich rozstrzygnięcie jest w ogóle możliwe. Państwo sojusznicze wnoszące dane czujnikowe do modelu koalicyjnego nie może prawnie przekazać tych danych poza swoją suwerenną infrastrukturę na mocy prawa bezpieczeństwa narodowego, niezależnie od istniejących między państwami ram traktatowych.

Bariera klasyfikacyjna jest problemem najpoważniejszym. Centralne trenowanie na danych o zróżnicowanej klasyfikacji wymaga podniesienia infrastruktury treningowej do najwyższego poziomu poufności spośród wszystkich zbiorów danych wnoszących wkład. Klaster treningowy dopuszczony do danych Top Secret/SCI jest o rząd wielkości droższy w budowie, obsłudze i akredytacji niż obiekt poziomu Secret, a pulę inżynierów i specjalistów ds. danych mogących z nim pracować ogranicza do ułamka siły roboczej. W praktyce większość wojskowych programów AI wybiera trenowanie na najmniej wrażliwych dostępnych danych zamiast akredytować obiekt wyższego poziomu — co oznacza pozbawienie modelu najistotniejszych operacyjnie przykładów treningowych. Uczenie federacyjne eliminuje ten kompromis, pozwalając każdemu silosowi wnosić wkład do modelu globalnego na własnym poziomie klasyfikacji. Aktualizacje gradientów opuszczające poszczególne silosy nie niosą oznaczeń klasyfikacyjnych równoważnych danym źródłowym — są artefaktami matematycznymi procesu trenowania, a nie rekordami danych.

Trzecią motywacją jest aktualność modeli na brzegu sieci. Wyzwaniem brzegowej inferencji AI w systemach wojskowych jest to, że model wdrożony na platformie taktycznej kilka miesięcy wcześniej wytrenowano na obrazie świata, który może już nie odpowiadać bieżącemu środowisku operacyjnemu. Zestawy pojazdów docelowych ewoluują, wdrażane są nowe fale radarowe, a techniki kamuflażu przeciwnika dostosowują się, by obejść znane wzorce wykrywania. Uczenie federacyjne umożliwia ciągłe doskonalenie modelu na danych zbieranych na wdrożonych platformach i w przednich bazach operacyjnych, przekazując ulepszenia z powrotem do modelu globalnego bez konieczności wysyłania surowych danych operacyjnych łańcuchem w górę — ograniczenie pasma i bezpieczeństwa, które czyni eksfiltrację surowych danych z platform taktycznych niepraktyczną. Model doskonali się w terenie, a dane pozostają w terenie.

Architektury FL dla obronności: cross-silo a cross-device — federacja na poziomie dowództwa i platformy

Uczenie federacyjne we wdrożeniach obronnych dzieli się na dwa zasadniczo różne wzorce architektoniczne, z których każdy odpowiada innej warstwie wojskowej hierarchii organizacyjnej. Zrozumienie różnicy jest warunkiem wyboru właściwego frameworka, strategii agregacji i architektury bezpieczeństwa.

Federacja cross-silo łączy niewielką liczbę dużych, instytucjonalnie stabilnych uczestników — zwykle 5–50 — z których każdy posiada znaczące niejawne zbiory danych. W kontekście obronnym uczestnikami cross-silo są dowództwa wojskowe, agencje wywiadowcze, państwa partnerskie lub biura programów platform. Każdy silos ma dedykowaną infrastrukturę obliczeniową zdolną do pełnego przebiegu trenowania modelu, stałe połączenie sieciowe z serwerem agregacji (z zaplanowanymi oknami serwisowymi na rozłączenia) oraz instytucjonalną kontrolę nad swoimi danymi. Federacja cross-silo toleruje wyższe koszty komunikacji na rundę, ponieważ uczestnicy są dobrze zasobni, i korzysta z bogactwa statystycznego dużego lokalnego zbioru danych każdego z nich. Główne wyzwania inżynierskie to heterogeniczne rozkłady danych między organizacjami, ramy prawne i polityczne regulujące udział oraz infrastruktura uwierzytelniania i autoryzacji potrzebna do zapewnienia, że tylko uprawnione silosy mogą wnosić wkład do modelu globalnego.

Federacja cross-device łączy dużą liczbę uczestników o ograniczonych zasobach, dostępnych epizodycznie — potencjalnie tysiące indywidualnych handsetów żołnierskich, węzłów czujników, naziemnych stacji UAV lub modułów obliczeniowych pojazdów. Każde urządzenie posiada jedynie niewielką ilość lokalnie generowanych danych, ma przerywaną łączność sieciową i może w sposób nieprzewidywalny dołączać się do federacji oraz z niej wypadać. FL cross-device wymaga agregacji asynchronicznej, agresywnej kompresji gradientów w celu minimalizacji pasma komunikacyjnego oraz metod statystycznych zdolnych wyekstrahować użyteczny sygnał z bardzo małych, wysoce non-IID (niezależnych i jednakowo rozłożonych) lokalnych zbiorów danych. To właściwa architektura dla taktycznego AI sieci mesh, gdzie celem jest aktualizacja wspólnego modelu na podstawie zbiorowego doświadczenia rozproszonej sieci czujników, bez gromadzenia przez jakikolwiek pojedynczy węzeł wystarczającej ilości danych do samodzielnego, sensownego trenowania.

Większość instytucjonalnych programów AI w obronności — tych działających na poziomie dowództwa, domeny lub programu oficjalnego — stosuje architekturę cross-silo z 10–30 dobrze zidentyfikowanymi uczestnikami. Architektura cross-device dotyczy głównie eksperymentalnych programów AI taktycznej, w których uczestnikami treningu są poszczególne platformy. Obie można łączyć hierarchicznie: federacja cross-device na poziomie sieci taktycznej agreguje się do uczestnika cross-silo na poziomie dowództwa operacyjnego, który z kolei uczestniczy w strategicznej federacji cross-silo. Ta struktura hierarchiczna pozwala, by dane z indywidualnych czujników taktycznych ostatecznie wpływały na model globalny, bez przekazywania surowych danych z czujnika przez więcej niż jeden skok sieciowy.

Prywatność różnicowa dla wojskowych danych treningowych — kalibracja szumu DP-SGD, dobór epsilon dla zastosowań obronnych, kompromis użyteczność a prywatność

Aktualizacje gradientów, choć nie są danymi surowymi, nie są też całkowicie nieprzejrzyste. Badania wykazały, że ataki odwrócenia gradientu potrafią zrekonstruować poszczególne próbki treningowe z aktualizacji gradientów z zaskakującą wiernością, zwłaszcza przy małych lokalnych rozmiarach batcha i płytkich architekturach modeli. W kontekście obronnym nawet częściowa rekonstrukcja danych treningowych z przechwyconego gradientu może zagrozić źródłom wywiadowczym, ujawnić wzorce zbierania przez czujniki lub odsłonić możliwości platform. Prywatność różnicowa (DP) zapewnia matematycznie rygorystyczny mechanizm ograniczenia tego wycieku.

DP-SGD (Differentially Private Stochastic Gradient Descent) stosuje dwie operacje na każdym gradiencie, zanim ten opuści silos treningowy. Po pierwsze, przycinanie gradientu względem próbek ogranicza czułość sygnału treningowego: norma L2 gradientu każdej pojedynczej próbki jest przycinana do wartości maksymalnej C, co zapewnia, że pojedynczy przykład treningowy nie może zdominować aktualizacji gradientu. Po drugie do przyciętej sumy gradientów dodawany jest skalibrowany szum gaussowski o odchyleniu standardowym proporcjonalnym do C / sigma. Stosunek C / sigma jest mnożnikiem szumu; wyższe wartości sigma dodają więcej szumu, zapewniając silniejszą prywatność kosztem bardziej zdegradowanego sygnału gradientu.

Formalna gwarancja prywatności jest wyrażona jako epsilon (budżet prywatności) i delta (zaniedbywalne prawdopodobieństwo awarii). Po R rundach treningowych, każda z lokalnym rozmiarem batcha B z N łącznych próbek treningowych, skumulowany epsilon rośnie w przybliżeniu jako epsilon ≈ (q * sigma_inv * sqrt(2 * R * log(1/delta))), gdzie q = B/N to wskaźnik próbkowania. W praktyce śledzenie prowadzi się metodą moments accountant lub rachunkiem Renyi Differential Privacy, które dają ciaśniejsze granice niż podstawowe twierdzenie o składaniu.

# DP-SGD with Opacus (PyTorch) — defense FL configuration
import torch
from opacus import PrivacyEngine
from opacus.accountants import RDPAccountant

model = MyDetectionModel()
optimizer = torch.optim.SGD(model.parameters(), lr=0.01)

privacy_engine = PrivacyEngine(accountant="rdp")

model, optimizer, train_loader = privacy_engine.make_private_with_epsilon(
    module=model,
    optimizer=optimizer,
    data_loader=train_loader,
    epochs=local_epochs,
    target_epsilon=3.0,       # authorized privacy budget for SECRET data
    target_delta=1e-5,        # negligible failure probability
    max_grad_norm=1.0,        # clipping norm C (set to median gradient norm)
)

# Train local epochs
for epoch in range(local_epochs):
    for batch in train_loader:
        optimizer.zero_grad()
        loss = criterion(model(batch["inputs"]), batch["labels"])
        loss.backward()
        optimizer.step()  # gradient clipping + noise injection happens here

# Check remaining budget before transmission
epsilon_consumed = privacy_engine.get_epsilon(delta=1e-5)
assert epsilon_consumed <= AUTHORIZED_EPSILON_CEILING, "Privacy budget exceeded"

Dobór epsilon dla zastosowań obronnych zależy od poziomu klasyfikacji danych treningowych oraz modelu przeciwnika. Użyteczną heurystyką dla programów obronnych jest warstwowanie epsilon według klasyfikacji: niejawne dane treningowe mogą tolerować epsilon rzędu 8–12, gdzie wpływ na dokładność jest minimalny; dane Secret uzasadniają epsilon 2–5, gdzie występuje istotny koszt dokładności, ale matematyczna gwarancja jest silna; dane Top Secret lub compartimentowane mogą wymagać epsilon zbliżonego do 1, gdzie degradacja dokładności jest znacząca i musi być zestawiona z wymogiem prywatności. Koszt dokładności silnej DP jest realny — model detekcji trenowany z epsilon = 1 może stracić 3–6 mAP względem baseline'u nieprywatnego — a biura programów muszą formalnie zaakceptować ten kompromis, zamiast dopuszczać do jego implicitnego powstania przez wybory programistyczne inżyniera.

Strategie agregacji modeli — FedAvg, FedProx dla heterogenicznych rozkładów danych, agregacja ważona według jakości i ilości danych

FedAvg (Federated Averaging), kanoniczny algorytm agregacji FL, oblicza aktualizację modelu globalnego jako prostą średnią aktualizacji gradientów uczestników w jednej rundzie. Jest prosty, wydajny komunikacyjnie i dobrze poznany. Jest także kruchy, gdy rozkłady danych uczestników są wysoce heterogeniczne — a to sytuacja raczej reguły niż wyjątku w wojskowych wdrożeniach cross-silo, gdzie dane treningowe każdego silosu organizacyjnego odzwierciedlają jego specyficzny kontekst operacyjny, platformę czujników i teatr działań.

Problem heterogeniczności objawia się jako dryf klienta: lokalnie zoptymalizowany model każdego uczestnika dryfuje w kierunku wyznaczonym przez jego lokalny rozkład danych, a średnia z wielu zdryfowanych modeli może być gorsza niż lokalny model pojedynczego uczestnika. Dowództwo operujące wyłącznie w teatrze arktycznym wytrenuje swój model lokalny do rozpoznawania pojazdów pokrytych śniegiem; dowództwo teatru pustynnego wyspecjalizuje się w piaskowych sygnaturach celów. Uśrednienie obu daje model, który wypada gorzej od każdego z nich. FedProx zaradza dryfowi klienta, dodając człon regularyzacji proksymalnej do lokalnej funkcji celu każdego uczestnika:

# FedProx local objective — adds proximal term to standard loss
# w_global = global model weights from last aggregation round
# w_local  = local model weights being updated
# mu       = proximal regularization strength (0.01 – 0.1)

def fedprox_loss(predictions, targets, w_local, w_global, mu=0.05):
    task_loss = criterion(predictions, targets)
    proximal_term = (mu / 2) * sum(
        torch.norm(w_l - w_g) ** 2
        for w_l, w_g in zip(w_local.parameters(), w_global.parameters())
    )
    return task_loss + proximal_term

Człon proksymalny penalizuje dryf modelu lokalnego od globalnego punktu startowego, zapobiegając zbytniemu pociągnięciu agregowanej aktualizacji przez pojedynczego uczestnika w kierunku jego lokalnego rozkładu danych. Hiperparametr mu steruje kompromisem: mu = 0 odtwarza standardowe FedAvg (bez regularyzacji); mu = 1.0 uniemożliwia lokalnej optymalizacji poprawę względem modelu globalnego (zbyt silna regularyzacja). Wartości w zakresie 0.01–0.1 są typowe dla obronnych wdrożeń cross-silo. Strojenie mu wymaga monitorowania dokładności modelu globalnego na centralnym zbiorze ewaluacyjnym w kolejnych rundach treningowych — jeśli dokładność oscyluje lub nie zbiega się, należy zwiększyć mu; jeśli zbieżność jest zbyt wolna, zmniejszyć je.

Agregacja ważona według ilości danych zastępuje uśrednianie o równych wagach agregacją proporcjonalną do liczby próbek. Dowództwo z 500,000 oznaczonymi przykładami powinno wnosić większy wkład w aktualizację globalną niż przednia baza operacyjna z 800 przykładami. Ważenie według liczby próbek jest proste: każdy uczestnik zgłasza swoją lokalną liczbę próbek (te metadane nie ujawniają treści danych), a serwer oblicza wagę każdego uczestnika jako jego liczbę podzieloną przez sumę ze wszystkich silosów biorących udział w rundzie.

Agregacja ważona według jakości danych jest bardziej złożona. Proxy jakości obliczalne bez dostępu do danych surowych obejmują dokładność lokalnej walidacji modelu (jeśli dostępny jest odłożony lokalny zbiór walidacyjny), normę gradientu (skrajnie duże lub małe normy gradientu mogą wskazywać problemy z jakością danych) oraz zgodność modelu (czy lokalna aktualizacja wskazuje w kierunku zbliżonym do agregatu pozostałych uczestników). Programy obronne o heterogenicznej jakości czujników — łączące obrazy elektrooptyczne wysokiej rozdzielczości ze strategicznych zasobów ISR z kamerami pojazdów naziemnych o niskiej rozdzielczości — powinny wdrożyć agregację ważoną jakością, aby źródła danych o niskiej jakości nie degradowały wydajności modelu globalnego w krytycznych zadaniach detekcji, które zależą od danych wyższej jakości.

Bezpieczne protokoły agregacji — agregacja kryptograficzna (SecAgg), zaufane środowisko wykonawcze dla serwera agregacji, szyfrowanie gradientów

Serwer agregacji to jedyny punkt w architekturze FL, który musi przetwarzać aktualizacje gradientów od wszystkich uczestników. Choć poszczególni uczestnicy nie mają dostępu do gradientów innych, operator serwera agregacji — oraz każdy przeciwnik, który skompromituje serwer — może obserwować wszystkie indywidualne przesłania gradientów. We wdrożeniu FL obronnym, w którym uczestnikami są różne organizacje lub państwa, ta scentralizowana widoczność tworzy ryzyko zbierania wywiadowczego: zaawansowany przeciwnik kontrolujący lub penetrujący serwer agregacji może próbować ataków rekonstrukcji gradientu na dane treningowe poszczególnych uczestników.

Bezpieczna agregacja (SecAgg) eliminuje to narażenie, pozwalając serwerowi obliczyć agregat gradientów uczestników bez oglądania gradientu żadnego z nich w postaci jawnego tekstu. Protokół używa tajemnic parowych między uczestnikami:

• W fazie inicjalizacji każda para uczestników ustanawia wspólny sekret przez wymianę kluczy Diffie-Hellmana na uwierzytelnionym kanale. Serwer agregacji ułatwia dystrybucję kluczy, ale nie poznaje sekretów parowych.
• Przed przesłaniem gradientu każdy uczestnik generuje pseudolosowy wektor maski dla każdego ze swoich partnerów (wyprowadzony z sekretu parowego) i dodaje wszystkie te maski do swojego gradientu. Maska dla pary uczestników (i, j) jest dodawana ze znakiem dodatnim przez uczestnika i oraz ze znakiem ujemnym przez uczestnika j.
• Gdy wszystkie zamaskowane gradienty zostają zsumowane na serwerze, maski znoszą się parami, pozostawiając wyłącznie prawdziwą sumę niezamaskowanych gradientów. Serwer poprawnie obliczył agregat, nigdy nie widząc jawnego gradientu żadnego pojedynczego uczestnika.
• Odłączenia uczestników obsługuje schemat dzielenia sekretów dla kluczy masek: jeśli uczestnik wypadnie przed złożeniem, próg pozostałych uczestników może zrekonstruować jego maskę i usunąć ją z agregatu.

Zaufane środowisko wykonawcze (TEE) serwera agregacji zapewnia komplementarną warstwę ochrony. TEE — zaimplementowane przez Intel TDX, AMD SEV-SNP lub ARM TrustZone — tworzy sprzętowo odizolowany kontekst wykonawczy, w którym kod i dane są szyfrowane i chronione nawet przed systemem operacyjnym i hypervisorem infrastruktury. Gdy serwer agregacji działa wewnątrz TEE, operator serwera nie może inspekcjonować zagregowanego gradientu w postaci jawnej bez złamania gwarancji attestation środowiska TEE. Zdalna attestation pozwala uczestnikom kryptograficznie zweryfikować, że serwer agregacji uruchamia autoryzowany kod agregacji w autentycznym TEE, zanim przekażą aktualizacje gradientów. To adresuje zagrożenie insidera na poziomie operatora infrastruktury — administrator chmury lub rządowy wykonawca IT obsługujący infrastrukturę serwera agregacji nie może wykorzystać dostępu uprzywilejowanego do przechwycenia ruchu gradientów.

Dla systemów widzenia komputerowego w obronności uczestniczących w programie FL cross-silo pełna ścieżka danych — od lokalnego wyniku treningu, przez maskowanie, po zaszyfrowany transport, agregację w TEE i z powrotem do uczestnika jako zaktualizowany model globalny — musi zostać udokumentowana i zaakredytowana jako część pakietu autoryzacji bezpieczeństwa programu. Każde ogniwo łańcucha wymaga własnej oceny zabezpieczeń.

FL w odłączonych i przerywanych środowiskach taktycznych — asynchroniczne FL z opóźnionymi gradientami, harmonogramowanie łączy satelitarnych, wersjonowanie modelu dla nieświeżych gradientów

Idealny protokół FL zakłada, że wszyscy uczestnicy są jednocześnie osiągalni na początku każdej rundy treningowej i pozostają osiągalni przez jej trwanie. Taktyczne środowiska wojskowe systematycznie naruszają to założenie. Placówki połączone łączem satelitarnym mogą mieć tylko 20-minutowe okna łączności co 12 godzin. Oddziały piesze działające w terenie pozbawionym łączności mogą być offline przez dni. Uczestnicy zamontowani na pojazdach mogą mieć przerywaną łączność z powodu maskowania terenu, zakłóceń radiowych ze strony przeciwnika lub procedur kontroli emisji (EMCON) zabraniających nadawania.

Asynchroniczne uczenie federacyjne odłącza dostępność uczestników od terminów agregacji. Zamiast zbierać gradienty wszystkich uczestników przed obliczeniem rundy, serwer agregacji utrzymuje bufor gradientów i stosuje aktualizacje w miarę ich nadejścia. Model globalny posuwa się naprzód ciągle, włączając wkład każdego uczestnika w chwili jego nadejścia. Wyzwaniem inżynierskim jest nieświeżość gradientów: uczestnik, który wytrenował model lokalny na wersji T modelu globalnego i przesyła gradient w czasie T+5, wnosi gradient obliczony względem modelu już nieaktualnego o pięć kroków globalnych. Naiwne agregowanie nieświeżych gradientów może spowolnić zbieżność, a w skrajnych przypadkach ją zdestabilizować.

# Staleness-weighted asynchronous aggregation (server side)
# Each gradient submission includes the round number it was computed from

def async_aggregate(gradient_buffer, current_round, max_staleness=10):
    """
    Aggregate gradient updates from the buffer, applying staleness weighting.
    Discard updates older than max_staleness rounds.
    """
    valid_updates = [
        (g, w, r) for g, w, r in gradient_buffer
        if (current_round - r) <= max_staleness
    ]

    total_weighted_grad = None
    total_weight = 0.0

    for grad, sample_weight, submission_round in valid_updates:
        staleness = current_round - submission_round
        # Exponential staleness decay: weight halves every 3 rounds
        staleness_factor = 0.5 ** (staleness / 3.0)
        effective_weight = sample_weight * staleness_factor

        scaled_grad = {k: v * effective_weight for k, v in grad.items()}
        if total_weighted_grad is None:
            total_weighted_grad = scaled_grad
        else:
            for k in total_weighted_grad:
                total_weighted_grad[k] += scaled_grad[k]
        total_weight += effective_weight

    # Normalize by total weight
    return {k: v / total_weight for k, v in total_weighted_grad.items()}

Harmonogramowanie FL na łączach satelitarnych dopasowuje zakończenie rund treningowych do przewidywanych okien łączności. Jeśli łącze satelitarne uczestnika jest dostępne codziennie od 02:00 do 02:20 UTC, klient treningowy uczestnika powinien być skonfigurowany tak, by ukończyć lokalny trening i przygotować gradient do transmisji przed 02:00. Serwer planuje rundy agregacji z terminem odpowiadającym oknu łączności ostatniego uczestnika. Dla uczestników z wieloma przelotami dziennie klient treningowy może użyć najnowszego gradientu, jeśli od ostatniej transmisji ukończono przebieg treningu, unikając złożoności akumulacji gradientów między przelotami.

Wersjonowanie modelu na poziomie uczestnika jest niezbędne dla odporności. Lokalne repozytorium modeli powinno przechowywać co najmniej trzy punkty kontrolne: obecnie wdrożony model inferencyjny, ostatnio otrzymany model globalny (punkt startowy lokalnego treningu) oraz model lokalny w trakcie trenowania (przed ekstrakcją gradientu). Jeśli łączność zostanie utracona po lokalnym przebiegu treningu, ale przed transmisją gradientu, gradient można zatrzymać i przesłać w następnym oknie łączności bez powtarzania obliczeń treningowych. Jeśli uczestnik otrzyma aktualizację modelu globalnego w trakcie trwającego lokalnego treningu, musi zdecydować, czy dokończyć bieżący przebieg (i przesłać potencjalnie nieświeży gradient), czy restartować od nowego modelu globalnego (marnując inwestycję obliczeniową). Dla platform brzegowej inferencji o ograniczonej mocy, gdzie obliczenia są kosztowne, dokończenie bieżącego przebiegu i zaakceptowanie nieświeżości jest zwykle lepszą polityką.

Model zagrożeń dla federacyjnego AI wojskowego — agregacja odporna na awarie bizantyjskie (Krum, Trimmed Mean), wykrywanie zatruwania modelu, łagodzenie ataków odwrócenia gradientu

Uczenie federacyjne w programach obronnych działa wobec bardziej wyrafinowanego modelu zagrożeń niż cywilne zastosowania FL. Przeciwnik ma zarówno motywację, jak i potencjalnie techniczne możliwości kompromitacji uczestników FL, przechwytywania transmisji gradientów lub infiltracji infrastruktury agregacji. Kategorie zagrożeń istotnych dla wojskowego FL to zatruwanie gradientów (skompromitowany uczestnik przesyła złośliwe gradienty), zatruwanie modelu (przeciwnik wstrzykuje dane treningowe zaprojektowane tak, by powstał model z backdoorem), odwrócenie gradientu (podsłuchiwacz rekonstruuje dane treningowe z przechwyconych aktualizacji gradientów) oraz kompromitacja serwera agregacji (przeciwnik uzyskuje dostęp do centralnego punktu agregacji).

Agregacja odporna na awarie bizantyjskie broni przed zatruwaniem gradientów, czyniąc aktualizację globalną niewrażliwą na ograniczoną liczbę wrogich wkładów uczestników. Standardowe FedAvg nie jest odporne na awarie bizantyjskie — pojedynczy uczestnik przesyłający gradient skierowany przeciwnie do prawdziwego gradientu może istotnie pogorszyć zbieżność. Algorytmy odporne na awarie bizantyjskie albo wybierają podzbiór gradientów, albo obliczają odporną statystykę ograniczającą wpływ przeciwnika:

Multi-Krum wybiera m gradientów najbardziej podobnych do ich k najbliższych sąsiadów wśród wszystkich przesłanych gradientów. Gradienty bizantyjskie, zaprojektowane tak, by stronniczo wpływać na aktualizację globalną, bywają odstające w rozkładzie gradientów — dalekie od skupiska uczciwych gradientów. Kryterium wyboru Kruma odrzuca te wartości odstające. Algorytm wymaga znajomości górnej granicy f liczby uczestników bizantyjskich; dla bezpieczeństwa parametr Kruma ustawia się na n - f - 2, gdzie n to łączna liczba uczestników.

Trimmed Mean współrzędna odrzuca górny i dolny ułamek p wartości gradientu w każdym wymiarze niezależnie, zanim obliczy średnią. Jest to obliczeniowo tańsze niż Krum i skuteczne, gdy gradienty bizantyjskie są skrajne w poszczególnych wymiarach — częsta struktura prostych strategii ataku na gradienty. Ułamek przycinania p powinien wynosić co najmniej zakładany ułamek bizantyjski plus margines bezpieczeństwa 5–10%.

# Coordinate-wise Trimmed Mean aggregation
import numpy as np

def trimmed_mean_aggregate(gradients, trim_fraction=0.2):
    """
    Byzantine-robust aggregation: trim top and bottom trim_fraction
    of gradient values per dimension, then average.

    gradients: list of flat numpy arrays, one per participant
    trim_fraction: fraction to trim from each tail (e.g., 0.2 = 20%)
    """
    grad_matrix = np.stack(gradients, axis=0)  # shape: (n_participants, n_params)
    n = grad_matrix.shape[0]
    k = int(np.floor(trim_fraction * n))        # number to remove from each tail

    # Sort along participant axis, trim k from top and bottom
    sorted_grads = np.sort(grad_matrix, axis=0)
    trimmed = sorted_grads[k : n - k, :]       # remove k from each end

    return np.mean(trimmed, axis=0)

Wykrywanie zatruwania modelu wymaga monitorowania zachowania modelu globalnego na czystym centralnym zbiorze ewaluacyjnym po każdej rundzie agregacji. Nagły spadek dokładności, wzrost wskaźnika fałszywie ujemnych dla określonej klasy celów lub pojawienie się nieoczekiwanych zachowań klasyfikacyjnych (takich jak wysokopewna błędna klasyfikacja konkretnego typu pojazdu, niewystępującego w zbiorze ewaluacyjnym przed rundą) są wskaźnikami udanego zatrucia. Programy FL obronne powinny utrzymywać odłożony zbiór ewaluacyjny przygotowany przez zespół niezależny od jakiegokolwiek uczestnika FL, aby żaden uczestnik nie mógł trenować pod dobre wyniki na zbiorze ewaluacyjnym, jednocześnie zatruwając operacyjne zachowanie modelu. Wykrywanie anomalii w statystykach gradientów poszczególnych uczestników — norma gradientu, podobieństwo cosinusowe do agregatu rundy oraz wariancja między rundami treningowymi — daje wczesny sygnał ostrzegawczy, że zachowanie gradientu uczestnika się zmieniło, co może wskazywać na kompromitację.

Łagodzenie odwrócenia gradientu działa przez trzy komplementarne mechanizmy. Po pierwsze, szum DP-SGD zaciera wartości gradientu poniżej progu szumu, uniemożliwiając rekonstrukcję wysokiej wierności. Po drugie, SecAgg zapewnia, że na serwerze agregacji widoczne są wyłącznie gradienty zagregowane, ograniczając powierzchnię ataku do kanału komunikacyjnego między każdym uczestnikiem a serwerem. Po trzecie, zwiększenie lokalnego rozmiaru batcha z jednocyfrowego do 64 lub więcej próbek na krok gradientu dramatycznie utrudnia odwrócenie, ponieważ gradient jest średnią z wielu próbek, a nie odciskiem pojedynczego rekordu. Dla danych treningowych o najwyższej wrażliwości lokalne rozmiary batcha 128 lub wyższe skutecznie uniemożliwiają obecnym technikom odwrócenia gradientu odzyskanie pojedynczych rekordów treningowych.