16.1.1. Adat validáció és tisztítás: A pipeline első védelmi vonala

2025.10.06.
AI Biztonság Blog

Egy gépi tanulási modell nemcsak a minőségét, de a biztonságát is az adatokból örökli. A „szemét be, szemét ki” elve a biztonságra hatványozottan igaz: a rosszindulatú, manipulált vagy egyszerűen csak hibás adat nem csupán pontatlan előrejelzésekhez, hanem sebezhető, kihasználható rendszerekhez vezet. Ezért az adat validáció és tisztítás nem egy opcionális előfeldolgozási lépés, hanem a biztonságos ML pipeline megkérdőjelezhetetlen alapköve.

Kapcsolati űrlap

AI Biztonság kérdésed van? Itt elérsz minket:

Az incidensek elemzése (lásd az előző részeket) gyakran rámutat, hogy a támadások gyökere a bemeneti adatok elégtelen ellenőrzésében rejlik. Egy robusztus validációs folyamat proaktívan szűri ki azokat az anomáliákat, amelyek egy támadás előhírnökei lehetnek, legyen szó adat mérgezésről (data poisoning) vagy a szolgáltatás megbénítására irányuló kísérletekről. Nézzük végig a folyamatot lépésről lépésre.

Formai és séma validáció: A kapuőr

Mielőtt bármilyen mélyebb elemzésbe kezdenénk, a legalapvetőbb kérdés: a beérkező adat megfelel-e a várt struktúrának? Ez a pipeline legelső, legszigorúbb szűrője.

  • Adattípusok ellenőrzése: A numerikus mező valóban számot tartalmaz? A dátum a megfelelő formátumú? Egy egyszerű típushiba is okozhat futásidejű kivételeket, ami DoS (Denial of Service) sebezhetőséghez vezethet.
  • Kötelező mezők megléte: Hiányzik egy kritikus attribútum? Ha egy modell egy adott bemeneti változóra támaszkodik, annak hiánya előre nem látható viselkedést eredményezhet.
  • Strukturális integritás: JSON, XML vagy CSV adatok esetén ellenőrizni kell, hogy a struktúra (pl. beágyazás, elválasztók) sértetlen-e. Egy hiányzó zárójel vagy idézőjel megbéníthatja az egész adatfeldolgozó láncot.

A modern adatfeldolgozó keretrendszerekben erre már kiváló eszközök léteznek. Egy Pydantic séma Pythonban például deklaratív módon kényszeríti ki a struktúrát.


# Python példa Pydantic használatával
from pydantic import BaseModel, conint, constr
from datetime import date

class FelhasznaloiAdat(BaseModel):
 user_id: int
 # Az életkornak 0 és 120 között kell lennie
 eletkor: conint(ge=0, le=120) 
 # A regisztrációs dátum nem lehet a jövőben
 reg_datum: date
 # A felhasználónév legalább 3 karakter
 nev: constr(min_length=3)

try:
 # Példa egy érvényes adatra
 valid_adat = FelhasznaloiAdat(
 user_id=101, eletkor=35, reg_datum="2023-10-26", nev="Teszt Elek"
 )
 print("Adat valid!")

 # Példa egy érvénytelen adatra (negatív életkor)
 invalid_adat = FelhasznaloiAdat.parse_obj(
 {"user_id": 102, "eletkor": -5, "reg_datum": "2024-01-01", "nev": "Támadó"}
 )
except ValueError as e:
 print(f"Validációs hiba: {e}")
# Kimenet: Validációs hiba: ... ensure this value is greater than or equal to 0 ...
 

Tartalmi és konzisztencia ellenőrzés: A józan ész tesztje

Ha az adat formailag rendben van, a következő kérdés: van értelme? Ez a lépés az adatban rejlő logikai buktatókat és ellentmondásokat keresi. Ezek a hibák gyakran utalnak adatbeviteli problémákra, de egy kifinomultabb támadó is használhatja őket a modell megzavarására.

Értéktartományok és megengedett halmazok

Az egyes attribútumok értékei gyakran csak egy meghatározott tartományból vagy halmazból származhatnak. A tartományon kívüli értékek azonnali figyelmeztető jelek.

Attribútum Érvénytelen érték Indoklás Potenciális kockázat
Termék ára (Ft) -1500 Az ár nem lehet negatív. Számítási hibák, a modell megtévesztése.
Értékelés (1-5) 7 Az értékelési skála 1-től 5-ig tart. A statisztikai eloszlás torzítása.
Fizetési mód „Fabatka teleportálás” Az érték nincs a megengedett kategóriákban (pl. ‘Kártya’, ‘Átutalás’). A rendszer logikájának megkerülése, feldolgozási hiba.

Keresztellenőrzések

Egyes adatok csak más mezők kontextusában értelmezhetők. Például egy „egyetemista” besorolású ügyfélnek nem lehet 30 éves munkatapasztalata. Az ilyen logikai ellentmondások kiszűrése megakadályozza, hogy a modell valószerűtlen összefüggéseket tanuljon meg, amelyeket egy támadó később kihasználhat.

Outlier és anomália detekció: A rejtett támadók keresése

Az adat mérgezési támadások legkifinomultabb formái nem extrém, könnyen szűrhető értékeket használnak. Ehelyett finoman eltolt, de a normál eloszláson belül még éppen hihetőnek tűnő adatpontokat injektálnak a tanítóhalmazba. Céljuk egy „hátsó kapu” (backdoor) létrehozása vagy a modell teljesítményének rontása egy specifikus alcsoporton. Az ilyen anomáliák detektálása statisztikai és gépi tanulási módszereket igényel.

  • Statisztikai módszerek: A legegyszerűbb megközelítés a Z-score vagy az interkvartilis tartomány (IQR) alapú szűrés. Ezek a módszerek az adatok eloszlása alapján azonosítják a szélsőségesen ritka értékeket.
  • Klaszterezés alapú módszerek: Algoritmusok, mint a DBSCAN, képesek az adatok sűrűsége alapján csoportokat (klasztereket) találni. Azok az adatpontok, amelyek egyik klaszterhez sem tartoznak, anomáliának minősülnek.
  • Rekonstrukciós modellek: Autoenkóderek vagy PCA segítségével a rendszer megtanulja az adatok „normális” szerkezetét. Azok az adatpontok, amelyeket a modell csak nagy hibával tud rekonstruálni, valószínűleg anomáliák.
Jellemző 1 Jellemző 2 Outlier Normál adatklaszter

1. ábra: Outlierek vizuális azonosítása egy kétdimenziós adathalmazban. A vörös pontok jelentősen eltérnek a sűrű, kék klasztertől.

A teljes validációs és tisztítási folyamat

A hatékony védelem egy többlépcsős folyamatot igényel, ahol az egyes szintek egymásra épülnek. A beérkező adatoknak minden kapun át kell jutniuk, mielőtt a modell tanítására vagy predikcióra használnánk őket.

Nyers Adat 1. Séma & Formátum 2. Tartalom & Konzisztencia 3. Anomália Szűrés Tiszta, validált adat Elutasítva Jelölve/Elutasítva

2. ábra: Egy rétegzett adat validációs pipeline. A hibás adatok a lehető legkorábbi fázisban kiesnek.

Ez a folyamat nem csupán a modell minőségét javítja, hanem kritikus biztonsági funkciót is ellát! 

Minden egyes elutasított vagy megjelölt adatpont egy potenciális támadási kísérlet naplóbejegyzése lehet. Ezen események monitorozása és elemzése elengedhetetlen a proaktív védekezéshez, és átvezet minket a következő témához: a modell verziókezeléshez és az auditálhatósághoz, ahol nyomon követjük, hogy pontosan melyik tiszta adathalmaz melyik modellt hozta létre.