Federated learning: AI tanulás betegadatok nélkül

A legtöbb egészségügyi AI-projekt ott vérzik el, ahol a legjobban fáj: nem lehet (és nem is szabad) egy helyre összegyűjteni a betegadatokat. Kórházak, rendelők, diagnosztikai központok és telemedicinás szolgáltatók mind külön rendszerekben, külön szabályokkal, eltérő adatminőséggel dolgoznak. Eközben a vezetők ugyanazt kérik: pontosabb előrejelzés, gyorsabb triázs, kevesebb téves riasztás.

A 2025.12.22-én frissített kutatás (FedProtoKD) egy konkrét, gyakorlati problémára ad választ a federált tanuláson belül: miért romlik el a „közös tudás”, amikor a partnerek különböző modelleket és eltérő adateloszlásokat használnak, és hogyan lehet ezt javítani úgy, hogy közben az adat továbbra sem hagyja el a helyi rendszert.

És itt jön a csavar, ami miatt ez a téma a „Mesterséges intelligencia a kiskereskedelemben és e-kereskedelemben” sorozatba is tökéletesen illik: ugyanazok a gondok jelennek meg a több telephelyes kereskedelmi láncoknál, franchise-hálózatoknál, marketplace-eknél és logisztikai partnereknél is. Az egészségügy csak még érzékenyebb terep, ezért ami ott működik, az jellemzően üzletben is erős.

Miért pont a federált tanulás (és miért most)?

A federált tanulás lényege egy mondatban: a modell megy az adathoz, nem az adat a modellhez. Ez az egészségügyben kulcskérdés, mert a betegadatok mozgatása jogi, etikai és biztonsági kockázat. Ugyanakkor egyetlen intézmény adata gyakran kevés ahhoz, hogy stabil, általánosítható AI-modellt kapjunk.

A valóságban a partnerségek „heterogének”:

• Eltérő adatok (non-IID): egy vidéki kórház esetei és egy budapesti centrum esetei más mintázatokat hordoznak.
• Eltérő modellek: nem mindenhol fut ugyanaz a hardver, ugyanaz a deep learning architektúra, ugyanaz a verzió.
• Eltérő protokollok: más kódolási szokások, más laborműszerek, más képalkotó beállítások.

Ezt hívják heterogén federált tanulásnak (HFL). A FedProtoKD erre a környezetre készült.

Prototípusokkal tanulni: mi ez, és miért hasznos az egészségügyben?

A prototípus-alapú HFL-ben a résztvevők nem nyers adatot osztanak meg, hanem osztály-reprezentatív „prototípusokat”: tipikus, összegzett jellemzővektorokat, amelyek egy diagnóziscsoportot (vagy kockázati kategóriát) képviselnek.

Egészségügyi példa:

• „tüdőgyulladás” képalkotó mintázatainak összegzett, vektorizált reprezentációja
• „magas szepszis-kockázat” labor+vital paraméter profil prototípusa

Ezek a prototípusok adatvédelmileg barátságosabbak, és segítenek áthidalni azt, hogy a partnerek eltérő modelleket használnak.

A gond: a klasszikus szerveroldali aggregálás gyakran sima súlyozott átlagolás. A kutatás szerint ez egy kellemetlen mellékhatást okoz: a döntési margó „összenyomódik”.

Ha a prototípusok túl közel kerülnek egymáshoz, a modell könnyebben kever össze osztályokat. Egészségügyben ez nem „csak” pontosságvesztés: rossz triázst, hibás riasztást, téves negatívot jelenthet.

A FedProtoKD lényege: kettős tudásdesztilláció + adaptív margók

A cikk két ötlete együtt erős:

1. Dual (kettős) tudásdesztilláció
2. Tanulható globális prototípusok adaptív margókkal

Kettős tudásdesztilláció: nem csak „kimenetet” tanítunk

A tudásdesztilláció klasszikusan azt jelenti, hogy egy „tanár” modell kimenetei (logitjai) segítenek egy „diák” modell betanításában. FedProtoKD ezt kibővíti:

• Logit-alapú tudás: a kliensmodell osztályonkénti valószínűségi/score jellegű jelzései.
• Prototípus (feature) alapú tudás: a kliens által képzett jellemzőtérbeli reprezentációk.

Egészségügyben ez azért praktikus, mert a „mit gondol a modell” (logit) és a „milyen mintázatból gondolja” (feature) együtt stabilabb közös tudást ad. Különösen akkor, amikor egyik kórház CT-alapon, a másik többnyire röntgenen, a harmadik strukturált EHR-adatokon erős.

Adaptív margók: a ritka esetek nem szorulhatnak háttérbe

A prototípusátlagolás margin-szűkülést okozhat: az osztályok reprezentációi túl közel kerülnek.

A FedProtoKD erre kontrasztív tanulás alapú, tanulható szerver-prototípust vezet be, és osztályonként adaptív prototípus-margót használ.

Mit jelent ez egyszerűen?

• A szerver nem csak „összeátlagol”, hanem tanul: úgy igazítja a globális prototípusokat, hogy az osztályok jobban elkülönüljenek.
• Az elkülönítés mértéke (a margó) osztályonként változik. Ez egészségügyben aranyat ér, mert a ritka, de kritikus kórképeket (például bizonyos komplikációk) nem lehet ugyanazzal a „távolságszabállyal” kezelni, mint a gyakoriakat.

A publikált eredmény szerint a megközelítés átlagosan 1,13% pontosságjavulást hozott, és bizonyos beállításokban akár 34,13%-ot is. Ez széles tartomány, de pont ezt üzeni: heterogén környezetben néha „kicsi” módszertani változás is nagyot szól.

„Nyilvános” minták okos használata: mi számít valóban hasznosnak?

Sok federált rendszerben van egy kis, nem érzékeny publikus (vagy pszeudo-publikus) mintaállomány, amit a szerver oldalon is lehet használni. A FedProtoKD ebben sem naiv: értékeli a minták fontosságát az alapján, hogy mennyire „közel” vannak a saját osztályuk prototípusához.

Gyakorlati értelmezés:

• Ha egy minta tipikus és jól illeszkedik, akkor jó „tananyag” lehet a közös prototípusok finomításához.
• Ha nagyon kilóg, lehet zaj, rosszul címkézett eset, vagy intézményspecifikus torzítás.

Ez a gondolkodásmód kiskereskedelemben is ismerős: nem minden tranzakció egyformán informatív. Egy egészségügyi analógiában pedig: nem minden vizsgálati eredmény ugyanolyan megbízható.

Mit jelent ez a gyakorlatban: 3 egészségügyi forgatókönyv

A kutatás nem „kész termék”, de nagyon jól kijelöli, merre érdemes építkezni.

1) Kórházak közötti diagnosztikai együttműködés

Ha több intézmény együtt tanít képdiagnosztikai modellt (CT/MR/röntgen), szinte garantált a heterogenitás: más géppark, más protokoll, más betegösszetétel. Prototípus-alapú HFL-lel és adaptív margókkal csökkenthető az intézményi torzítás, és stabilabb lehet a több helyszínre kiterjeszthető teljesítmény.

2) Telemedicina és otthoni monitorozás

Otthoni eszközök (pulzus, SpO2, EKG patch) adatai zajosabbak, és gyártónként is eltérnek. A heterogén federált tanulás itt természetes választás. A kettős desztilláció segít, hogy a rendszer ne csak „jósoljon”, hanem a jellemzőtérben is közelítsen a közös reprezentációhoz.

3) Multimodális kockázat-előrejelzés (EHR + lab + kép)

A valós klinikai döntéstámogatás ritkán csak egy adatforrás. A prototípusok jó „közös nyelvet” adnak: a különböző intézmények más-más modalitásokkal is hozzájárulhatnak a közös tudáshoz anélkül, hogy mindenkinek ugyanazt a modellt kellene futtatnia.

Ugyanez a logika kiskereskedelemben: miért illik a sorozatba?

A kiskereskedelemben és e-kereskedelemben a federált tanulás tipikus indokai:

• adatmegosztási korlátok partnerhálózatok között,
• üzleti titok védelme,
• eltérő rendszerek (különböző POS, CRM, webshop motorok),
• országonként eltérő vásárlói viselkedés.

A FedProtoKD szemlélete itt úgy fordítható le, hogy:

• a „prototípus” lehet vásárlói szegmens-reprezentáció,
• az adaptív margó segít, hogy a hasonló szegmensek ne olvadjanak össze,
• a kettős desztilláció erősíti, hogy a partnerek eltérő modelljei mégis „egy nyelvet beszéljenek”.

Ha ajánlórendszert, kereslet-előrejelzést vagy készletoptimalizálást építesz több bolt/hub/partner adataiból, a heterogén federált tanulás egyre kevésbé elmélet, egyre inkább napi realitás.

Gyakori kérdések, amiket a döntéshozók feltesznek (és a jó válaszok)

Mennyi adatot kell megosztani a federált tanuláshoz?

Nullát is lehet, ha csak modellfrissítések mennek. Prototípus-alapú módszereknél prototípusok és logit-információk is megosztásra kerülhetnek, ami továbbra sem nyers betegadat.

A prototípus tényleg „biztonságos”?

Biztonságosabb, de nem varázspajzs. A prototípus aggregált reprezentáció, mégis lehetnek visszafejtési kockázatok. Egészségügyben én azt tartom jó alapnak, ha a prototípusos megosztást is kiegészítjük szervezeti és technikai kontrollokkal (hozzáférés-kezelés, audit, differenciális privacy vagy secure aggregation, ahol indokolt).

Mi a fő kockázat bevezetéskor?

A legnagyobb kockázat nem az algoritmus, hanem a heterogén adatminőség: címkézési eltérések, protokoll-különbségek, hiányzó adatok. A FedProtoKD pont azt üzeni, hogy a heterogenitást kezelni lehet, de nem lehet „szőnyeg alá söpörni”.

Mit érdemes kipróbálni 30 nap alatt? (gyakorlati lépések)

Ha intézményi vagy partnerhálózati AI-t építesz (egészségügyben vagy kereskedelemben), ez a rövid terv működni szokott:

1. Heterogenitás-térkép: írd össze, melyik partnernél milyen adatforrás, milyen címkézés, milyen modell/infra van.
2. Prototípus definíció: döntsd el, mi az „osztály” (diagnózis, kockázati kategória, szegmens), és milyen feature-térben képeztek prototípust.
3. Pilot 2–3 klienssel: nem kell rögtön 20 intézmény. Előbb nézd meg, hogy a prototípusátlagolásnál jelentkezik-e margin-szűkülés (tipikusan igen).
4. Kontrasztív szerver-prototípus teszt: még ha nem is pont FedProtoKD-t valósítasz meg, a „tanulható globális prototípus” gondolatot érdemes lemásolni.
5. Metrikák rendbetétele: pontosság mellett mérj osztályonkénti recall-t (különösen ritka, kritikus osztályokra), és nézd a kalibrációt is.

Merre tartunk 2026-ban: a decentralizált tanulás lesz a normál

A 2025 végi trend egyértelmű: a decentralizált, adatot helyben tartó tanítási módok nem extra opciók, hanem alapelvárások lesznek. Az egészségügyben ez adatvédelem és bizalom kérdése. A kiskereskedelemben versenyelőny és partneri együttműködés.

A FedProtoKD legfontosabb üzenete számomra egyszerű: nem elég adatot nem megosztani – a közös tudást is jól kell összerakni. Ha a prototípusokat csak „összeátlagoljuk”, az gyakran pont azt a finom döntési távolságot nyírja ki, ami a jó diagnózist (vagy jó ajánlást) megkülönbözteti a közepestől.

Ha most építesz több szereplős AI-rendszert, érdemes feltenni egy konkrét kérdést: hol fog a te rendszeredben összenyomódni a döntési margó – és mit teszel ellene még a pilot fázisban?