Läbipaistvus ja korratavus ei ole isoleeritud tehnilised toimingud, vaid süsteemsed insenertehnilised võimalused, mis läbivad andmeid, koodi, protsesse, korraldust ja vastavust. Järgnev on seitsme-kihiline juurutusraamistik, mis on valideeritud mitmes domeenis, kusjuures iga kiht vastab rakendatavatele tehnilistele toimingutele ja tööriistaahelatele.
1. Andmekiht: jälgitava sugupuu loomine
Põhiprintsiip: töötlemata andmed ≠ puhastatud andmed ≠ funktsioonitehniline väljund
Rakendamine: kasutage DVC-d (andmeversiooni juhtimine), et märgistada iga andmekomplekt versiooninumbriga (nt v2.1.3).
Looge sõltumatu DVC torustiku kirje iga andmete eeltöötluse, funktsioonide eraldamise või diskreetimisstrateegia muudatuse jaoks.
Andmeallika märgistus: anduri ID, hankimisaeg, seadme mudel, keskkonnaparameetrid (nt temperatuur ja niiskus)
Kontrollimise mehhanism: iga hindamistulemus peab olema jälgitav andmestiku konkreetse versioonini; ebamäärased kirjeldused nagu "viimased andmed" on keelatud.
Näide: hindamistulemus koos F1-score=0.91 peab olema seotud failiga data/v2.1.3/sensor_rbt047_20260410.csv + dvc.yaml:preprocess_v4
2. Koodikiht: valge-kasti kujundus ja versioonikontroll
Põhiprintsiip: kogu hindamisloogika peab olema loetav, auditeeritav ja siduv kood, mitte eraldatud Exceli valemid või Jupyteri sülearvutid.
Rakendamine: kõik meetrikaarvutused, lävemäärangud ja mudeli järeldamisloogika tuleks kirjutada ühtselt Pythoni moodulitesse (nt metrics.py, threshold_engine.py).
Kasutage koodi haldamiseks Giti; igal modifikatsioonil peab olema kinnitusteade, mis selgitab muudatuse eesmärki (nt feat: kohandage RBT-047 vibratsioonilävi valehäire trendi alusel).
"Kohalike modifikatsioonide" või "ajutiste skriptide" kasutamine on keelatud.
Kohustuslik nõue: hindamisaruanne peab sisaldama koodi commit hash, näiteks a1b2c3d4.
3. Keskkonnakiht: konteinerisse paigutamine ja sõltuvuse lukustamine
Põhiprintsiip: vältige "see töötab minu masinas" lõksu.
Rakendamine: kasutage Dockerit. Pakkige hindamiskeskkond: Pythoni versioon, teegi sõltuvused (requirements.txt), süsteemiteegid, GPU draiveri konfiguratsioon.
Looge korduvkasutatav pildimärgend: registry.example.com/eval-rbt:v1.2.0
Koos MLflow projektidega kapseldage kogu hindamisprotsess käivitatavasse projekti.
Kinnitusmehhanism: uued liikmed peavad tulemuste taasesitamiseks käivitama ainult käsu `docker run --rm -v $(pwd):/data eval-rbt:v1.2.0 --run-id a1b2c3d4.
4. Protsessi kiht: automatiseeritud konveier ja CI/CD manustamine
Põhiprintsiip: käsitsi täitmine=mitte-korduv; Automaatne täitmine=auditeeritav
Rakendusmeetod: kasutage Airflow'i või Jenkinsi igapäevase hindamise torujuhtme korraldamiseks:
merineitsi
graafik LR
A[Pull DVC v2.1.3 data] -->B[Laadi MLflow mudel a1b2c3]
B -->C [Arvutage F1-skoor, valehäire määr ja teostusaeg]
C -->D [Loo soojuskaart ja trenddiagramm]
D -->E [Võrdle eelmise perioodi näitajatega]
E -->F {F1 vähenemine > 5%?}
F -- Yes -->G [Alarmite automaatne käivitamine + arhiivilogid]
F -- No -->H [Vajuta armatuurlauale]
Väljund: iga päev automaatselt genereeritud hindamisaruanne, mis salvestatakse kesksesse teadmistebaasi koos ajatempli ja torujuhtme ID-ga
5. Salvestuskiht: struktureeritud auditilogid
Nõuded salvestusruumile: logid tuleb kirjutada muutumatusse andmebaasi (nt plokiahela notariaalne kinnitamine või WORM-salvestus), mis toetab mitmedimensioonilisi päringuid seadme, aja ja operaatori järgi.
6. Aruandluskiht: kohustuslikud kontrollitavad komponendid Iga hindamisaruanne peab sisaldama viit järgmist kontrollitavat elementi, millest ühtegi ei saa ära jätta:
Tabeli komponendi sisu nõuete kontrollimise meetod
Läve muutuste trajektoori graafik Näitab põhinäitajate dünaamilist läve arengut aja jooksul Joondatud algsete anduriandmete ajajoonega
Valealarm/vastamata häire soojuskaart Statistiline jaotus seadme, vahetuse ja ajaperioodi järgi Rist{0}}kinnitatud töökäsusüsteemis sildiga „Viga puudub”
Kulude kokkuhoiu joondiagramm Võrdleb hoolduskulusid ja seisakuid enne ja pärast juurutamist. Kooskõla ERP finantssüsteemi andmetega
Mudeli ja andmeversiooni võrdlustabel: loetleb mudeli ID, treeningandmete versioon ja koodiräsi. Juurdepääs algsele kirjele MLflow/DVC lingi kaudu.
Auditilogi kokkuvõte: võtab kokku kõik jooksva perioodi korrigeerimissündmused ja kontrollib iga kirjet logi andmebaasi alusel.
Aruande allkiri: jälgitavuse tagamiseks peab iga aruanne lõppema digitaalallkirjaga (põhineb Giti voliniku identiteedil).
7. Vastavuskiht: rahvusvaheliste standardite ja sertifikaatide manustamine
ISO 13374-1: nõuab "jälgitavat hindamistõendite ahelat" – täielikku linki algandmetest lõpliku järelduseni.
IEC 60038: sätestab, et hindamise järeldused peavad olema sõltumatult reprodutseeritavad kolmanda osapoole poolt; vastasel juhul on need kehtetud.
TOP-kriteerium (läbipaistvuse ja avatuse edendamine): andmed, kood ja analüüsimeetodid peavad olema avalikult avalikustatud. Eelregistreeritud-uuringuplaanid takistavad hilisemat valikulist aruandlust.
Siseaudit: iga kuue kuu tagant valitakse juhuslikult kolm juhtumit ja sõltumatu meeskond, kes kasutab algandmeid + koodi + peegeldamist, uuesti läbi. Veamäär peab olema<0.5%.
Ülim kontrollistandard: kui uus töötaja suudab 24 tunni jooksul reprodutseerida kõik eelmise kuu hindamistulemused ilma suulise juhendamiseta, kasutades ainult aruannet, koodihoidlat, DVC-versiooni ja Dockeri kujutist, läbib protsess tööstusliku-taseme korratavuse sertifikaadi.
