Adat nélküli folyamatos tanulás: AI a felhő és eszközök között

A legtöbb cég ott rontja el a federált tanulást, hogy úgy kezeli, mintha minden résztvevő ugyanazzal a modellel, ugyanolyan adatokkal és ugyanazzal a tempóval dolgozna. A valóság meg pont az ellenkezője: a kórházak, rendelők, raktárak, üzletek és mobilos alkalmazások különböző eszközparkon, különböző adatmintázatokkal és különböző frissítési ciklusokkal futnak. Ez nem esztétikai probléma, hanem teljesítmény- és kockázati kérdés.

A 2025 végén publikált FedDCL kutatás (adat nélküli, folyamatos tanulás a felhő–eszköz együttműködésben) azért érdekes, mert egy kényes pontot céloz: hogyan tud a szerveroldali (felhős) „központi” modell úgy fejlődni új feladatokkal és új eszközökkel, hogy közben nem kér nyers adatot, és mégsem felejt el mindent, amit korábban megtanult.

És itt jön a csavar: bár a kampányunk fókusza az AI az egészségügyben, ezt a megközelítést érdemes a „Mesterséges intelligencia a kiskereskedelemben és e‑kereskedelemben” sorozatban is tárgyalni, mert a logika ugyanaz. A diagnosztikai modellek és a kereslet-előrejelző rendszerek egyaránt folyamatosan változó, heterogén világban élnek.

Miért fáj ennyire a „heterogén” federált tanulás?

A rövid, egyenes válasz: mert a heterogenitás három külön problémát egyszerre hoz be, és ezek egymást erősítik.

1) Nem-IID adatok: mindenhol más a valóság

Federált tanulásnál az adatok az eszközöknél maradnak (pl. kórházi telephelyeknél, rendelői rendszereknél, pénztárgépeknél, bolti kameráknál). Csakhogy az adat eloszlása nem azonos (non-IID):

• Egy vidéki szakrendelőben más betegpopuláció jelenik meg, mint egy budapesti centrumkórházban.
• Egy belvárosi kisboltban más a kosárösszetétel, mint egy agglomerációs hipermarketben.

Ez a szerveroldali aggregációt instabillá teszi: a modell „rááll” pár domináns mintára, és gyengül ott, ahol a valóság ritkább vagy speciális.

2) Modellheterogenitás: nem minden eszköz bírja ugyanazt

A kutatás kulcsállítása: a gyakorlatban nem reális elvárni, hogy minden kliens ugyanazt a neurális hálót futtassa.

• Klinikai környezetben lehet modern GPU-s szerver, de lehet régi PACS-integráció vagy hordozható ultrahang eszköz.
• Kiskereskedelemben lehet erős edge box a kamerákhoz, de lehet olcsó IoT-szenzor vagy mobilalkalmazás.

Ilyenkor jön a modellheterogenitás: eltérő architektúrák, paraméterszámok, kimeneti rétegek. A „klasszikus” FL ezt rosszul viseli.

3) Katasztrofális felejtés: ami új, letolja a régit

A folyamatos tanulásnál (continual learning) a modell új feladatokat kap időben egymás után. Ha nincs jó memória-mechanizmus, az új tanulás felülírja a régit.

Az egészségügyben ez konkrét kockázat: egy új protokoll vagy új eszközadat miatt romolhat a teljesítmény régebbi, de még mindig releváns alcsoportokon.

Egy mondatban: heterogén eszközök + eltérő adatok + folyamatos frissítés = nagy eséllyel széteső minőség.

Mit ad hozzá a FedDCL: „adat nélküli” folyamatos tanulás a szerveren

A lényeg: a FedDCL keretrendszer a szerveroldali modellt úgy frissíti, hogy közben nem támaszkodik a klienseszközök nyers adataira, és mégis képes:

1. Szintetikus adatot generálni az aktuális feladathoz (a non-IID ellen).
2. Generatív visszajátszást végezni korábbi feladatokhoz (a felejtés ellen).
3. Dinamikus tudásátadást megoldani eltérő kliensmodellekből (a modellheterogenitás ellen).

A kutatás trükkje, hogy előre betanított diffúziós modelleket használ „könnyű” osztály-prototípusok kinyerésére. Magyarul: a szerver kap egy olyan generatív képességet, amivel kontrollált módon tud „pótadatot” előállítani és „emlékezni”, miközben nem kell konkrét betegadat vagy vásárlói tranzakció a felhőbe.

Mi az a „könnyű osztályprototípus”, és miért számít?

A válasz: kicsi, hordozható reprezentáció, ami egy osztály vagy fogalom lényegét tömöríti.

• Egészségügy: prototípus lehet például egy diagnosztikai kategória jellemző mintázatának sűrített leírása (nem azonosítható nyers képkocka).
• E-kereskedelem: prototípus lehet „visszatérő vásárló”, „árérzékeny kosár”, „szezonális termék” jellegzetességeinek tömör reprezentációja.

Ezekből a szerver „emlékeztető” jellegű szintetikus mintákat tud generálni, és ez az, ami adatmentesen támogatja a folyamatos tanulást.

Egészségügyi párhuzam: telemedicina, alacsony sávszél, gyors változás

A rövid válasz: az adat nélküli szerveroldali frissítés pont ott segít, ahol a rendszer nem enged adatmozgatást.

Alacsony sávszélességű együttműködés

Telemedicinában és régiós ellátásban tipikus, hogy a kapcsolat instabil vagy drága. Ha a felhőnek nem kell adathalmazokat mozgatni, csak modelleket/összegzett tudást, az:

• csökkenti az átviteli terhelést,
• gyorsítja a frissítési ciklust,
• és egyszerűsíti a megfelelőségi folyamatokat.

Folyamatos alkalmazkodás új protokollokhoz

2025-ben a klinikai AI egyik legnehezebb kérdése nem az, hogy „tud-e jó modellt tanítani?”, hanem hogy tud-e biztonságosan változni. Új eszköz, új annotációs szabvány, új gyógyszerelési protokoll, új populációs hullám — a modellnek lépést kell tartania anélkül, hogy a régi teljesítményt feladná.

A FedDCL-szerű megközelítés itt azért erős, mert a generatív „visszajátszás” nem klasszikus adattárolás. Nem egy adatbázist őrzünk, hanem egy tudás-visszaidézési mechanizmust.

Kiskereskedelem és e-kereskedelem: ugyanaz a gond, csak más köntösben

A válasz: a kiskereskedelemben a kereslet-előrejelzés, a készletoptimalizálás és a személyre szabott ajánlórendszer pontosan olyan folyamatosan változó feladat, mint az orvosi AI.

December vége ráadásul különösen kegyetlen időszak az adatok szempontjából: karácsonyi lecsengés, ajándék-visszaküldések, év végi akciók, készletkisöprés, majd januári „újratervezés”. Ez tipikusan olyan helyzet, ahol a modell könnyen túlilleszkedik a friss mintára, és elfelejti a „normál” üzemet.

Gyakorlati példa: ajánlórendszer több boltban, több eszközön

Képzelj el egy láncot:

• nagy budapesti üzletekben erős edge szerver futtat valós idejű polcfelismerést,
• kisebb egységekben csak pénztáradat és készletszenzor van,
• az e-kereskedelmi oldal külön modellen számolja a kosár-ajánlásokat.

Ez modellheterogenitás a gyakorlatban.

FedDCL-szemlélettel a központi modell úgy tudna frissülni, hogy:

• az aktuális kampányhoz generál szintetikus mintákat (non-IID enyhítése),
• megtartja a korábbi szezonok „emlékét” generatív replay-jel,
• és különböző kliensmodellekből tudást vesz át anélkül, hogy mindenki ugyanazt a modellt futtatná.

Mit érdemes ebből átültetni 2026-os projektekbe? (Konkrét lépések)

A lényeg: nem kell holnap diffúziós modellt bevezetned ahhoz, hogy a gondolkodásmódot használd. Én ezt a 6 lépést javaslom, ha egészségügyi vagy kiskereskedelmi AI rendszert skálázol.

1. Írd le, hol keletkezik heterogenitás

   • adat (non-IID),
   • hardver (CPU/GPU/memória),
   • modell (külön architektúrák),
   • frissítési gyakoriság.

2. Döntsd el, mi a „tiltott” adatmozgás

   • nyers kép? nyers tranzakció? csak aggregátum mehet?

3. Válassz felejtés elleni stratégiát

   • klasszikus: példatárolás (egészségügyben gyakran problémás),
   • jobb: generatív replay vagy prototípus-alapú emlékezet.

4. Kezeld külön a „tudás-illesztést” (knowledge alignment)

   • ha eltérő modellek vannak, legyen explicit illesztési réteg vagy protokoll (pl. logit-szintű tudásátadás, prototípus-szinkron).

5. Mérj úgy, hogy a felejtés látszódjon

   • ne csak összpontszám legyen, hanem időbeli bontás: „régi feladatok” vs „új feladatok” teljesítménye.

6. Készülj auditálható frissítésekre

   • egészségügyben ez kötelező, kiskereskedelemben üzleti előny: visszakövethető, mikor miért változott az ajánlás vagy a készletjavaslat.

Gyakori kérdések, amiket a csapatok feltesznek

„Az adat nélküli tanulás akkor azt jelenti, hogy nincs is adat?”

Nem. A kliensoldalon van adat, csak a szerver nem kap nyers adatot. A szerver a tudásátadásból és a prototípusokból dolgozik.

„A szintetikus adat nem rontja el a modellt?”

Ha rosszul generálod, de. A kutatás ezért támaszkodik előre tanított generatív modellekre és osztályprototípusokra, hogy a szintetikus minták kontrolláltabbak legyenek.

„Ez kiváltja a federált tanulást?”

Nem kiváltja, inkább felnőtt verzió heterogén környezetre: a federált tanulás alapelvét (adat helyben marad) megtartja, de hozzáad egy folyamatos tanulási és generatív memóriaréteget.

Merre tart ez 2026-ban: skálázhatóság adat nélkül, felejtés nélkül

Az „adat nélküli folyamatos tanulás” üzenete szerintem egyszerű: a felhőben futó központi modelleknek nem szabad minden frissítésnél újra és újra „megenniük” az adatot, mert ez drága, lassú és sokszor tiltott. Ehelyett okosabb a tudásáthelyezésre, prototípusokra és generatív emlékezetre építeni.

A „Mesterséges intelligencia a kiskereskedelemben és e‑kereskedelemben” sorozatban ez azért kulcstéma, mert a személyre szabott ajánlások, a készletkezelés és a kereslet-előrejelzés 2026-ban még inkább edge-közeli lesz: több bolt, több csatorna, több eszköz, rövidebb kampányciklusok.

Ha most tervezel AI bevezetést egészségügyben vagy retailben, én ezt a kérdést tenném fel a legvégén a döntéshozói meetingen: a rendszerünk képes lesz tanulni új helyzetekből úgy, hogy közben nem felejt el régi, üzletileg vagy klinikailag kritikus mintákat?