Az AI és az "okos világ" gyenge pontjai
(2025 november)
Az "okos világ": Lassan mindenre rákerül az „okos” jelző – okosóra, okoshűtő, okosvillanykörte, okosredőny, okosfogkefe...-: a marketingesek elárasztják a világot okos, WIFI-ről és mobiltelefonokról működő időkapcsolós automatákkal. Miért van ez a nagy „okosodás”? Kényelemes, automatizált és időt takarít meg, néha energiatakarékos, jobban optimalizál, mint amit mi kézzel csinálnánk. A gyártók szeretnek adatokat gyűjteni, mert sokat tanulnak a használatról: mit lehet eladni profitmaximalizálással, és mit kéne gyártani? Divat lett az "okos", ezért minden termékcsalád próbál okos lenni, még akkor is, ha nem indokolt. Nem feltétlenül okos az "okos", gyakran csak marketing, átverés. Az utolsó években (2025) az okos világban megjelent az AI, amitől még okosabb lett a világ. Egy más kérdés, hogy az AI-s "okos világ" már mindenki számára átláthatatlan, és csak annyira megbízható, mint a műszaki berendezések és a szoftverek, illetve még annyira se. A sok okos készülék alkotta AI-s rendszer gyenge pontjait kerestük, és az találtuk, hogy a gyenge pontok az emberi hibákkal, beavatkozássokkal kapcsolatosak.
Mi szokunk hozzá az Ai haszálatához
Az AI (= mesterséges intelligencia) segíti a teljes vállalati adattömeg feldolgozását, az ügyvitelt, és már a gyártási folyamatok, teljes gyárak optimalizálását, és lehetővé teszi a kis sorozatú tömeggyártást, a gyakori termékváltást a gyártósorokon. Az AI hozzájárul a beszállítói láncok stabilitásához és a kiberbiztonság erősödéséhez, bár néha azt érezzük, hogy a "kiberbizonytalanság" mindig gyorsabban terjed, mint a biztonság, egy folyamattá alakult a védekezés. A jövőben a kiberbiztonság lesz az egyik gyenge pontja az AI irányította "okos világ"-nak, egy szoftver jellegű ok, ami az AI-k biztonságos működését veszélyezteti. A rosszindulatú AI-kről sok szamárságot összeírtak már, a példák végén minden esetben ott az emberi tényező, a gép nem hibázik. Az AI ma már (2025) az átlagos képzettséget igénylő kérdésekben "mindent tud, amit tudni érdemes." (A gép akkor fog valóban sokat tudni, ha kérdéseket tesz fel magának, esetleg véletlenszerűen, és bizonyítható módon meg is válaszolja a kérdéseket helyesen. Hogy mi honnan tudjuk meg a új válaszokat, az egy másik kérdés.) A középiskolákban tanítani kéne a használatát, és kívülről -mint a verseket- megtanultatni az AI válaszait adott kérdésekre.
A hardver jellegű leggyengébb láncszem a szolgáltatókkal kapcsolatos, akik beékelődnek az AI szerver és a felhasználók közé. A felhasználói Wi-Fi hálózatok megbízhatósága függ a rádiós környezettől, az eszközök minőségétől, lefedettségtől, zsúfoltságtól, sávszélességtől, IP-cím ütközésektől, mégis a WIFI problémák műszakilag megoldottak, vannak nagy (négy-öt kilences) megbízhatóságú hálózatok. A szolgáltató kiesések esetén nem a Wi-Fi a hibás, hanem az instabil működésű modemek, a szolgáltatói csomagok, a hálózatok megbízhatatlansága, pl. építkezéseknél véletlenül vagy szándékosan elvágják a kábelt.
Velünk maradnak (https://financialpost.com/technology/tech-news/opinion-why-canada-should-guard-the-worlds-ai-not-race-to-build-it)
Hol tart ma az AI-vezérelt ipar? (AI válasz)
1. Gyárak (ipar 4.0 / okosgyárak) Sok új gyárban AI felügyeli a gyártási folyamatokat WIFI-k segítségével, félautomata rendszerek, ahol az AI döntéseit emberek kontrollálják. Például:
◦ hibadetektálás kamerákkal,
◦ karbantartás előrejelzése (predictive maintenance),
◦ robotkarok optimalizált mozgásvezérlése,
◦ termelés ütemezése és készletezés.
◦ karbantartás előrejelzése (predictive maintenance),
◦ robotkarok optimalizált mozgásvezérlése,
◦ termelés ütemezése és készletezés.
2. Készülékek és gépek, jellemző az emberi és az AI együttes felügyelete. Sok eszköz már rendelkezik AI-val:
◦ okos robotporszívók,
◦ ipari robotok,
◦ önvezető járművek (még felügyelet mellett),
◦ drónok autonóm repülési módokkal.
Teljesen autonóm gyárak, néhány „lights-out” üzem (ahol sötétben működik minden) már létezik, például robotizált elektronikai összeszerelő üzemek, de a "sötét gyárak"-ban is kell emberi:
• központi felügyelet,
• karbantartó személyzet,
• biztonsági kontroll,
◦ ipari robotok,
◦ önvezető járművek (még felügyelet mellett),
◦ drónok autonóm repülési módokkal.
Teljesen autonóm gyárak, néhány „lights-out” üzem (ahol sötétben működik minden) már létezik, például robotizált elektronikai összeszerelő üzemek, de a "sötét gyárak"-ban is kell emberi:
• központi felügyelet,
• karbantartó személyzet,
• biztonsági kontroll,
• minőség végellenőrzés.
Az AI meghibásodások* gyakoriságait tekintjük önmagukban (szoftverhiba > kommunikációs hiba > hardverhiba > tápegység / energiaellátás hibái).Az AI sokrétegű (adat előkészítés → modell → futtatókörnyezet → driver → hardver), ezért több a hibalehetőség. Az AI-rendszerek meghibásodásai ritkán magából az AI-algoritmusból fakadnak; sokkal gyakoribbak a klasszikus hibaforrások.
1. Szoftverhibák (leggyakoribbak)
• modell-kód hiba
• függőségek, könyvtárak inkompatibilitása
• verzióváltási problémák (Python, CUDA, driver, framework)
• rosszul kezelt bemeneti adatok
• konfigurációs hibák
• memóriaszivárgások, túlterhelés
• modell-kód hiba
• függőségek, könyvtárak inkompatibilitása
• verzióváltási problémák (Python, CUDA, driver, framework)
• rosszul kezelt bemeneti adatok
• konfigurációs hibák
• memóriaszivárgások, túlterhelés
2. Kommunikációs csatorna hibái, az AI-rendszerek gyakran elosztottak, ezért nagy a hibaarányuk a kommunikációs láncban.
• hálózati késleltetés vagy szakadás
• API-hívások hibái
• nem elérhető adatbázis / storage
• protokoll inkompatibilitás
• túl sok egyidejű kérés → torlódás
• API-hívások hibái
• nem elérhető adatbázis / storage
• protokoll inkompatibilitás
• túl sok egyidejű kérés → torlódás
3. Hardverhibák ritkábbak, de amikor bekövetkeznek, súlyosak. Az AI különösen megterheli a hardvert (nagy memória- és hőterhelés), ami növeli a meghibásodási esélyt, de összesített gyakoriságuk kisebb, mint a szoftveres és kommunikációs problémáké:
• GPU memóriahibák (VRAM ECC error, overheating)
• SSD elhasználódás (logok, checkpointok, datasetek)
• RAM hibák
• szerver alkatrészhibák: a félvezető hibák gyakoriságai a passzív alkatrészek hibanagyságrendjébe esnek, eloszlásuk az exponenciális eloszlás családba tartozik (exponenciális vagy geometriai eloszlású, vagy ezekből származtatott eloszlások).
• GPU memóriahibák (VRAM ECC error, overheating)
• SSD elhasználódás (logok, checkpointok, datasetek)
• RAM hibák
• szerver alkatrészhibák: a félvezető hibák gyakoriságai a passzív alkatrészek hibanagyságrendjébe esnek, eloszlásuk az exponenciális eloszlás családba tartozik (exponenciális vagy geometriai eloszlású, vagy ezekből származtatott eloszlások).
4. Tápegység / energiaellátás**, ritka, de kritikus), mert az ipari rendszerek nagyon jól redundáltak (alapelv, a két tartalékból csak egy működhet), viszont ha megtörténnek, általában teljes rendszerleállást okoznak.
• túlfeszültség, hő miatti leállások
• adatközpont hűtési problémák
• áramszünet
• UPS hibák• túlfeszültség, hő miatti leállások
• adatközpont hűtési problémák
Megbízhatósági modell AI-rendszerekre, ami figyelembe veszi a különböző hibaforrásokat és azok gyakoriságát, valamint a következmény súlyosságát. Az egyik leggyakrabban használt módszer az FMEA (Failure Modes and Effects Analysis), vagy annak egyszerűsített változata, ami valószínűség × súlyosság = kockázat alapú. Lépésről lépésre:
1. Hibaforrások azonosítása
Hibaforrás Lehetséges okok Valószínűség (P) Súlyosság (S) Kockázati szám (R = P×S)
Szoftver Kódhiba, konfiguráció, adat probléma 0.5 0.6 0.3
Hibaforrás Lehetséges okok Valószínűség (P) Súlyosság (S) Kockázati szám (R = P×S)
Szoftver Kódhiba, konfiguráció, adat probléma 0.5 0.6 0.3
Kommunikáció Hálózati késleltetés, API hiba 0.3 0.5 0.15
Hardver GPU/CPU/SSD meghibásodás 0.15 0.7 0.105
Tápegység/ Áramszünet, UPS hiba 0.05 0.9 0.045
Tápegység/ Áramszünet, UPS hiba 0.05 0.9 0.045
energia
(A súlyosság 0–1 között értendő, ahol 1 = teljes rendszerleállás vagy kritikus adatvesztés)
2. Hibák hatásának modellezése (a redundáns elemek miatt részleges működés)
• Szoftverhiba → gyakori, de általában részekre korlátozódik (pl. modell nem fut, de adat nem vész el)
• Kommunikáció → rendszer részleges leállása, vagy csak késleltetés
• Hardverhiba → ritkább, de kritikus (GPU/SSD meghibásodás = hosszú leállás)
• Tápegység → ritka, de teljes rendszer leállás
• Szoftverhiba → gyakori, de általában részekre korlátozódik (pl. modell nem fut, de adat nem vész el)
• Kommunikáció → rendszer részleges leállása, vagy csak késleltetés
• Hardverhiba → ritkább, de kritikus (GPU/SSD meghibásodás = hosszú leállás)
• Tápegység → ritka, de teljes rendszer leállás
3. Megbízhatósági modell (egyszerűsített)
A rendszer megbízhatósága számítható részegységek hibamentes működés-valószínűségeinek a szorzataként, ami ≈ 0.283. Tehát a rendszer hosszú távon 28% valószínűséggel működik hibamentesen az átlagos üzemidő alatt, ha minden hibaforrást azonos idő alatt veszünk figyelembe.
• Szoftver: 1 - 0.5 = 0.5
• Kommunikáció: 1 - 0.3 = 0.7
• Hardver: 1 - 0.15 = 0.85
• Tápegység: 1 - 0.05 = 0.95
A rendszer megbízhatósága számítható részegységek hibamentes működés-valószínűségeinek a szorzataként, ami ≈ 0.283. Tehát a rendszer hosszú távon 28% valószínűséggel működik hibamentesen az átlagos üzemidő alatt, ha minden hibaforrást azonos idő alatt veszünk figyelembe.
• Szoftver: 1 - 0.5 = 0.5
• Kommunikáció: 1 - 0.3 = 0.7
• Hardver: 1 - 0.15 = 0.85
• Tápegység: 1 - 0.05 = 0.95
4. Kockázatcsökkentés
• Szoftver → egységek tesztjei, CI/CD, monitoring
• Kommunikáció → ismétlő mechanizmusok, redundáns hálózat
• Hardver → redundáns GPU/CPU, ECC memória, rendszeres karbantartás
• Tápegység → UPS stabilizátor, generátor, redundáns adatközpont
• Kommunikáció → ismétlő mechanizmusok, redundáns hálózat
• Hardver → redundáns GPU/CPU, ECC memória, rendszeres karbantartás
• Tápegység → UPS stabilizátor, generátor, redundáns adatközpont
5. Emberi hibák, környezeti hibák
• Rossz konfiguráció
• Hibás frissítés
• Rossz adatkezelés
• Hibás frissítés
• Rossz adatkezelés
• Hőmérséklet-emelkedés
• Páratartalom
• Áramkimaradás.
• Páratartalom
• Áramkimaradás.
Pl. 2025 novemberben a Cloudflare internetszolgáltató rendszerében kialakult zavar átmenetileg megbénított számos weboldalt és szolgáltatást, köztük volt többek között az X, a Spotify és a ChatGPT is. Az Independent beszámolója szerint olyan oldalakon jelentek meg a hibaüzenetek, mint a korábbi nevén Twitter, vagy a filmes értékelőoldal, a Letterboxd. A Cloudflare az internetes infrastruktúra központi szolgáltatója
Ez csak egy volt a sorban a legutóbbi internetes leállások közül. Előtte egy hónappal az Amazon Web Services problémája milliókat érintett, sokak számára lehetetlenné téve az internetes rendelést vagy az okoseszközök kezelését a lakásokban. Napokkal később a Microsoft Azure szolgáltatás szünetelt (CNN). Veszélyes, hogy a kritikus felhőinfrastruktúra mindössze néhány nagyvállalat kezében összpontosul. A Cloudflare leállása egy „konfigurációs fájlból” eredt, amely a fenyegető forgalom kezelésére szolgált. A fájl túlnőtt a várt méreten, és rendszer-összeomlást okozott számos felhő-szerverben, amelyeket Cloudflare szolgáltat.
Ez csak egy volt a sorban a legutóbbi internetes leállások közül. Előtte egy hónappal az Amazon Web Services problémája milliókat érintett, sokak számára lehetetlenné téve az internetes rendelést vagy az okoseszközök kezelését a lakásokban. Napokkal később a Microsoft Azure szolgáltatás szünetelt (CNN). Veszélyes, hogy a kritikus felhőinfrastruktúra mindössze néhány nagyvállalat kezében összpontosul. A Cloudflare leállása egy „konfigurációs fájlból” eredt, amely a fenyegető forgalom kezelésére szolgált. A fájl túlnőtt a várt méreten, és rendszer-összeomlást okozott számos felhő-szerverben, amelyeket Cloudflare szolgáltat.
Ismétlődő mintákról van szó: a A Cisco hálózatfigyelő szolgálata 2025-ben eddig 12 jelentős leállást regisztrált (a keddi Cloudflare-incidenst nem számítva), szemben a 2024-es 23-mal, a 2023-as 13-mal és a 2022-es 10-zel. A Cisco elemzése szerint 2025 első felében ismétlődő mintázatok rajzolódnak ki: vannak rendszerek, amelyek véletlenül tovább terjesztik a technikai hibákat, mások látszólag működnek, miközben a háttérben rejtett problémákat „cipelnek”, és egyre gyakoribbak a konfigurációs változtatások által elindított láncreakciók. A várható leállások számát a rendelkezésre állás, az elérhetősék valószínűségével jellemzik. Az AI modellek tanítása hetekig, hónapokig megszakítás nélkül fut. Egy rövid áramkimaradás is megszakítja a tanítást, ◦ adatvesztést okozhat, ◦ újraindításkor jelentős idő- és költségveszteséget eredményezhet. Az energiaellátási problémák gyakran hűtési zavarokkal együtt jelennek meg; ha nincs megfelelő teljesítmény, a hűtés leállhat, aminek túlmelegedés a következménye.
A felhőszolgáltatók tipikus megbízhatósági szintjei:
A ≈ 0.999 → 99,9% elérhetőség ("három kilences"):
• 99.9% – havi 45 perc kiesés
• 99.99% – havi 4,5 perc
• 99.999% – havi 26 másodperc.
• 99.999% – havi 26 másodperc.
Soros rendszerben (series system) a teljes rendszer akkor hibásodik meg, ha bármely komponens meghibásodik. Tipikusan: komponensek meghibásodási valószínűsége összeadódik. Párhuzamos rendszer (parallel system) a rendszer akkor hibásodik meg, ha minden redundáns komponens elromlik. A modern szerverarchitektúrák gyakran elosztott rendszerek. Egy elosztott rendszerben egyszerre csak kettő működhet háromból. Hibatűrő protokollok (Paxos, Raft)
biztosítják, hogy a rendszer akkor is működjön, ha néhány node kiesik. Karbantartási stratégiák és monitoring rendszerek segítik a megbízhatóságot.
*
Tipikus AI szerver meghibásodások
1. Hardver erőforrás-problémák
CPU/GPU túlterhelés
• Nagy batch-méretek, nem optimalizált modellek.
• Több párhuzamos inferencia lekérés, amely meghaladja a GPU-kapacitást.
GPU memória-kimerülés (OOM)
• A leggyakoribb hiba a deep learning rendszereknél.
• Tünet: CUDA out of memory.
Diszk I/O telítettség
• Modellfájlok folyamatos betöltése.
• Nagy mennyiségű logolás.
Hőterhelés, throttling
• Főleg on-premise szervereknél.
• Nagy batch-méretek, nem optimalizált modellek.
• Több párhuzamos inferencia lekérés, amely meghaladja a GPU-kapacitást.
GPU memória-kimerülés (OOM)
• A leggyakoribb hiba a deep learning rendszereknél.
• Tünet: CUDA out of memory.
Diszk I/O telítettség
• Modellfájlok folyamatos betöltése.
• Nagy mennyiségű logolás.
Hőterhelés, throttling
• Főleg on-premise szervereknél.
2. Hálózati hibák,
Latency vagy csomagvesztés
• API-k válaszidejének extrém megnövekedése.
DNS vagy load balancer hibák
• A szerver “elérhetetlen”, holott él.
Túlterhelt inference endpointok
• DDoS vagy egyszerűen túl sok felelős API-hívás.
• API-k válaszidejének extrém megnövekedése.
DNS vagy load balancer hibák
• A szerver “elérhetetlen”, holott él.
Túlterhelt inference endpointok
• DDoS vagy egyszerűen túl sok felelős API-hívás.
3. Modell- és szoftverhibák
Modellbetöltési hiba
• Sérült model weights
• Inkompatibilis framework verzió (pl. PyTorch 2.x vs 1.x)
Framework-verzió inkompatibilitás
• „Module not found” vagy CUDA verzió ütközések.
Nem determinisztikus hibák
• Párhuzamos futtatásból adódó race condition.
Modellbetöltési hiba
• Sérült model weights
• Inkompatibilis framework verzió (pl. PyTorch 2.x vs 1.x)
Framework-verzió inkompatibilitás
• „Module not found” vagy CUDA verzió ütközések.
Nem determinisztikus hibák
• Párhuzamos futtatásból adódó race condition.
4. Deployment / üzemeltetési hibák
Konténer összeomlás (Docker, Kubernetes)
• OOM killer leállítja a podot.
• CrashLoopBackOff.
Autoscaling hibás konfigurációja
• Skálázás késik → túlterhelést okoz.
• Túl agresszív skálázás → instabilitás.
Storage limit túllépése
• Logfájlok elárasztják a diszket.
Konténer összeomlás (Docker, Kubernetes)
• OOM killer leállítja a podot.
• CrashLoopBackOff.
Autoscaling hibás konfigurációja
• Skálázás késik → túlterhelést okoz.
• Túl agresszív skálázás → instabilitás.
Storage limit túllépése
• Logfájlok elárasztják a diszket.
5. Biztonsági események
Token-vagy kulcsszivárgás
• API endpointok túlterhelése.
Nem megfelelő sandboxing
• Kódfuttatásos modellek (pl. code-assistant) esetén.
Token-vagy kulcsszivárgás
• API endpointok túlterhelése.
Nem megfelelő sandboxing
• Kódfuttatásos modellek (pl. code-assistant) esetén.
6. Modell specifikus hibák
Túl lassú inferencia
• Nagy nyelvi modellek (LLM) kvantálásának hiánya.
• Nem optimalizált futtatómotor (pl. ONNX Runtime vs TensorRT eltérések).
Memóriaszivárgás hosszú futás alatt
• Különösen Python + GPU esetén, ha nincs megfelelő torch.cuda.empty_cache() vagy ref-cleanup.
Túl lassú inferencia
• Nagy nyelvi modellek (LLM) kvantálásának hiánya.
• Nem optimalizált futtatómotor (pl. ONNX Runtime vs TensorRT eltérések).
Memóriaszivárgás hosszú futás alatt
• Különösen Python + GPU esetén, ha nincs megfelelő torch.cuda.empty_cache() vagy ref-cleanup.
7. Adat- és input-hibák
Nem várható input formátum
• Rossz JSON.
• Túl hosszú kontextus → "input length exceeded".
Adatvalidáció hiánya
• Modell összeomlik extrém értékeken.
Nem várható input formátum
• Rossz JSON.
• Túl hosszú kontextus → "input length exceeded".
Adatvalidáció hiánya
• Modell összeomlik extrém értékeken.
**
Az AI-k energiellátását a jövőben az SMR-ek, a kis nukleáris reaktorok foglák ellátni, ma a tartalékok diezel generátorok, gázturbinák, de az elmúlt években egyértelműen a napenergia-termelés felfutásáról szóltak a hírek, aminek három oka van: lényegesen olcsóbbak a nappanelek, mint például a szélturbinák, egyszerűbb őket előállítani és telepíteni is. A napenergia tárolása akkumlátortelepekkel vagy magas hőmérsékleten, fémsókkal (nátrium és kálium nitrátok és nitritek) történik. A Nemzetközi Energiaügynökség (IEA) 2024-es tanulmánya szerint a szélturbinák fajlagos gyártási költsége két évvel ezelőtt jutott el arra a szintre, ahol a napelemek tíz éve voltak, ami szélturbinák gazdaságtalanságát bizonyítja. Főleg ott, ahol nincs szél. A napenergia felfutása várhatóan a következő években is folytatódik, az IEA október elején publikálta legfrissebb előrejelzését, mely szerint – elsősorban a napenergia tovább növekvő népszerűségének köszönhetően – 2030-ig megduplázódhat a telepített megújuló energiaforrást hasznosító termelőeszközök száma.
Ennek a bővülésnek a 80 százalékát a naperőművek adják majd az IEA becslése szerint, azt követhetik a szél-, illetve a vízerőművek. Kiemelik, hogy a napelemek előnye továbbra is az alacsony költség és a gyors telepíthetőség. Ez a két fontos támogató tényező pedig várhatóan a következő öt évben is fennmarad. Egy friss tanulmány szerint a nyári hónapokban egy egységnyi energia előállításának költsége napkollektorokkal mindössze 0,02 angol font (jelenlegi árfolyamon kevesebb mint 10 forint), ezzel pedig a szén, a gáz és más energiaforrások sem tudnak versenyezni.