16.1.2. Modell verziókezelés és audit

A verziókezelés a szoftverfejlesztésben olyan magától értetődő, mint a levegővétel. Egy `git commit` nélkül ma már el sem indul egy projekt. 

Azonban a gépi tanulási rendszerek esetében ez a koncepció sokkal többrétegűvé válik. Nem elég a kódot verziókövetni; a modell életciklusának minden eleme – az adatoktól a hiperparamétereken át a kész modell артеfaktumig – visszakövethető kell, hogy legyen. Ellenkező esetben egy biztonsági incidensnél a sötétben tapogatózunk!

Ahelyett, hogy elvont definíciókkal kezdenénk, nézzünk egy valósághű, bár fiktív esetet, ami rávilágít a tétre.

A verziókezelés láthatatlan gerince

A FraudXGuard esete tökéletesen illusztrálja, hogy a modell verziókezelése nem csupán technikai feladat, hanem alapvető biztonsági követelmény! 

A robusztus verziókezelő rendszernek a következő komponenseket kell megmásíthatatlanul összekapcsolnia:

• Kód: A tanító, kiértékelő és adat-előkészítő scriptek pontos `git` commit hash-e.
• Adatok: A tanító-, validációs és tesztadatkészletek pontos verziója vagy hash-e. Ez kritikus, ahogy az előző fejezetben láttuk, hiszen az adatok minősége alapjaiban határozza meg a modell viselkedését.
• Konfiguráció: Hiperparaméterek, architektúra-leírások, függőségek (pl. `requirements.txt`). Egyetlen paraméter megváltozása is drasztikusan módosíthatja a modell sebezhetőségét.
• Modell аrtefaktum: A betanított, szerializált modell (pl. egy `.pkl` vagy `.h5` fájl), amely egyértelműen azonosítható.
• Metrikák: A kiértékelés során kapott teljesítménymutatók, beleértve a standard pontosságot, F1-score-t, és ami még fontosabb, az AI Red Teaming során feltárt sebezhetőségekre vonatkozó robusztussági metrikákat. 

Ha ezek az elemek nincsenek atomi egységként kezelve, a rendszer auditálhatatlanná válik!)

Egy incidens esetén lehetetlen megmondani, hogy a hibát egy adatszennyezés, egy rosszul beállított hiperparaméter, vagy egy kódbeli hiba okozta-e.

A megoldás: Integrált modell-regiszter és audit napló

A gyakorlatban ezt a problémát egy modell-regiszter (Model Registry) segítségével oldjuk meg. 

Ez egy központi, verziókövetett adatbázis, amely minden egyes modellverzióhoz eltárolja a fent felsorolt elemeket. 

Olyan eszközök, mint az MLflow, a DVC (Data Version Control) vagy a felhőszolgáltatók saját MLOps platformjai (pl. SageMaker Model Registry, Vertex AI Model Registry) biztosítanak ilyen funkcionalitást.

Egy bejegyzés egy ilyen regiszterben a FraudXGuard v2.1 modelljének „helyes” verziójáról valahogy így nézne ki:

Ez a struktúra azonnali válaszokat ad a kritikus kérdésekre:

• Reprodukálhatóság: Bárki, bármikor újra le tudja futtatni a tanítási folyamatot a f5e6d7c8 commit és az a1b2c3d4 adathalmaz segítségével, hogy pontosan ugyanazt a modellt kapja.
• Összehasonlíthatóság: Könnyen összevethető a v2.1.1 és a v2.0. Mi változott az adatokban? Melyik commit hozott be új kódot? A robusztussági score csökkent?
• Auditálhatóság: Incidens esetén pontosan tudjuk, ki, mikor, milyen adatok és kód alapján hozta létre a problémás modellt. Ez nem a bűnbakkeresésről szól, hanem a hiba okának gyors és hatékony feltárásáról.

A gyakorlati megvalósítás

A tanítási folyamatba be kell építeni a modell és a hozzá tartozó metaadatok automatikus regisztrálását. Ez egy tipikus MLOps pipeline lépés.

# Pszeudokód egy modell regisztrálására egy MLOps eszközzel (pl. MLflow)

import mlaudit as ml

# A tanítási kísérlet kontextusának elindítása
with ml.start_run(run_name="fraud_model_training_v2.1.1") as run:
 # 1. Bemenetek naplózása
 ml.log_param("learning_rate", 0.001)
 ml.log_param("epochs", 5)
 ml.set_tag("git_commit", "f5e6d7c8a1b9...") # CI/CD pipeline-ból jön
 ml.log_input(dataset_path, version="a1b2c3d4e5f6...") # DVC-ből jön

 # 2. Modell tanítása
 model = train_model(data, params)
 
 # 3. Metrikák naplózása
 metrics = evaluate_model(model, validation_data)
 ml.log_metrics(metrics) # pl. {"accuracy": 0.981, ...}

 # Red Teaming tesztek futtatása és eredmények naplózása
 robustness_scores = run_red_team_tests(model)
 ml.log_metrics(robustness_scores) # pl. {"adversarial_noise_v3": 0.65}
 
 # 4. Modell regisztrálása a regiszterbe
 ml.register_model(
 model_artifact=model,
 model_name="fraud-detection-transformer"
 )

 print(f"Modell sikeresen regisztrálva a {run.info.run_id} futásból.")

Ez a fajta automatizálás biztosítja, hogy egyetlen modell se kerülhessen éles környezetbe anélkül, hogy a teljes származási lánca (lineage) dokumentálva és visszakövethető lenne. 

Az AI Red Team számára ez aranyat ér, mert egy sebezhetőség felfedezésekor nem csak a hibát tudják jelezni, hanem pontosan meg tudják mutatni azt a verziót – a kóddal és adatokkal együtt –, amelyben a hiba megjelent.

A modell verziókezelés és audit tehát nem egy opcionális kényelmi funkció, hanem a biztonságos AI fejlesztés egyik alapköve, amely lehetővé teszi a gyors reagálást, a felelősségteljes üzemeltetést és a rendszerszintű tanulást a hibákból.