Mérnöki MLOps

Mérnöki MLOps
Gyorsan épít, tesztel és kezel nagy léptékű üzemkész

gépi tanulási életciklusokat
Emmanuel Raj
BIRMINGHAM—MUMBAI
Mérnöki MLOps
Copyright © 2021 Packt Publishing
Minden jog fenntartva. Ezen könyvnek semmilyen részét nem szabad reprodukálni, visszakereső
rendszerben tárolni vagy bármilyen formában vagy módon továbbítani a kiadó előzetes írásos
engedélye nélkül, a bíráló cikkekben vagy kritikákban lévő rövid idézetek kivételével.
Minden erőfeszítést megtettek ezen könyv előkészítése során, hogy biztosítsák a megjelenő
információk pontosságát. Azonban az ebben a könyvben szereplő információk kifejezett vagy
hallgatólagos garancia nélkül kerülnek értékesítésre. Sem a szerző, sem a Packt Publishing,
sem annak kereskedői és forgalmazói nem felelnek az e könyv által közvetlenül vagy közvetve
okozott vagy állítólagos károkért.
A Packt Publishing igyekezett biztosítani a könyvben említett minden vállalat és termék
védjegyének információit a megfelelő betűhasználattal. Azonban a Packt Publishing nem
garantálhatja ezen információk pontosságát.
Csoport termékmenedzser: Kunal Parikh

Kiadó termékmenedzser: Aditi Gour
Főszerkesztő: Mohammed Yusuf Imaratwale
Tartalomfejlesztő szerkesztő: Nazia Shaikh
Műszaki szerkesztő: Arjun Varma
Lektor: Safis Editing
Projektkoordinátor: Aishwarya Mohan
Korrektor: Safis Editing
Indexáló: Priyanka Dhadke
Terméktervező: Joshua Misquitta
Első kiadás: 2021. április

Gyártási hivatkozás: 1160421
Kiadja a Packt Publishing Ltd.

Livery Place
35 Livery Street
Birmingham
B3 2PB, UK.
ISBN 978-1-80056-288-2
www.packt.com
Közreműködők
A szerzőről
Emmanuel Raj egy finnországi gépi tanulással foglalkozó főmérnök, több, mint 6 éves
szakmai tapasztalattal. Gépi tanulással foglalkozó mérnök a TietoEvry-nél is és
a mesterséges intelligenciával foglalkozó szövetség tagja az Európai Bizottságnál. Lelkesedik
az MI demokratizálásáért és kutatás és a tudományos világ iparba történő integrálásáért.
Mérnöki diplomáját az Arcada University of Applied Sciences-en szerezte Big Data
Analytics témában Élénken érdeklődik az olyan technológiák K+F-e iránt, mint az Edge
MI, Blockchain, NLP, MLOps, és robotika. Hisz benne, hogy a tanulás legjobb módja a
tanítás, lelkesedik az új technológiák megismerése és másokkal történő megosztása iránt.
A lektorokról
Magnus Westerlund (DSc) információ technológiai egyetemi tanár és a mesterképzés
vezetője a finnországi Arcada University of Applied Sciences egyetem big data analytics
szakán, Helsinkiben. Telekommunikációs és információkezelési háttérrel rendelkezik és az
információs rendszerekből doktorált a finnországi Åbo Akademi University egyetemen.
Magnus az analitika, IT biztonság, kiberszabályozás és megosztott könyvelési technológia
területein publikált kutatásokat. Jelenlegi kutatási témája az okos szerződésen alapuló
megosztott biztonság az IoT alkalmazásoknál és az intelligens rendszerek értékelése.
Műszaki szakértőként részt vesz a Z-inspection® hálózatban, amely az MI tudatos
használatáért (#MUAI) dolgozik.
Stephen Oladele az AgServer társalapítója, amely egy peer-to-peer tudásmegosztó

platform az afrikai kisbirtokosoknak. Adattudománnyal foglalkozó tehetségek képzésében
is részt vesz a TheGradientBoost-nál, amely egy utánpótlással és toborzással foglalkozó
cég. Adattudósként vállalatok és magánszemélyek tanácsadója volt, segít nekik
megvalósítani az üzleti ötleteket olyan jelentős projekteknél, mint amilyen a gépi látás,
üzleti analitika és NLP (dokumentumelemzés), amely olyan felsőalapú gépi tanulási
szolgáltatásokat használ, mint amilyen a Google Cloud Platform és Microsoft Azure.
Szabadidejében imád önkénteskedni. Olyan nonprofit szervezeteket működtet, amelyek
segítenek megismerni az MI-t és technológiát az afrikai képviselet nélküli csoportokkal.
Korábban volt önkéntes a Google és AWS projektjeinél.
Emerson Bertolo egy adatkutató és szoftverfejlesztő, aki létrehozott egy létfontosságú

szoftvert és több, mint 12 éve foglalkozik big data alkalmazásokkal. Bertolo 2016-ban
elmélyült a gépi tanulásban és a mély tanulásos projektekben TensorFlow, PyTorch,
MXNet, Keras, és Python könyvtárakat használó MI modellek alkotásával, hogy
megvalósítsa ezeket a modelleket olyan technológiai vállalatoknak, mint a LawTech,
biztonság és védelem. Az Agile-elvek adattudományba történő beolvasztásával Bertolo
a legjobb összeállítást keresi az Agile szoftverfejlesztés és a gépi tanulással foglalkozó
kutatások között, hogy piaci MI alkalmazásokat készíthessen. A megközelítésének alapja
a tanulásra alkalmas kialakítás, az eredmények validálása, bizonytalanságok keresése és
azonosítása, újraépítés és ismét a tanulás!
Table of Contents
Előszó
1. rész: Keretrendszer gépi tanulási

modellek kiépítéséhez
1
MLOps WorkFlow alapjai
A szoftver- és Az ML adoptációjának trendjei
infrastruktúrafejlesztés evolúciója4 a szoftverfejlesztésben 13
A gépi tanulás és mély-tanulás erősödése 5 Az MLOps megértése 14
A Moore-törvény vége 7 MLOps munkafolyamatai és
MI-alapú alkalmazások 7 elvei 16
A szoftverfejlesztés evolúciója 8 Egy felhasználási mód megvitatása 17
A hagyományos Összefoglalás26
szoftverfejlesztés kihívásai 11
2
Az Ön gépi tanulási problémájának jellemzése
Az ML megoldás fejlesztési Az MLOps-jának szerkesztése 37
folyamata28 Kis adatos műveletek 39
ML modelltípusok 29 Big data műveletek 40
Tanulási modellek 30 Hibrid MLOps 41
Hibrid modellek 31 Nagy léptékű MLOps 41
Statisztikai modellek 34
Megvalósítási ütemterv
HITL modellek 36
az Ön megoldásához 42
ii Table of Contents
1. fázis: ML fejlesztés 43 Követelmények 46

2. fázis: Átvitel a műveletekhez 44
3. fázis: Műveletek 44
Eszközök és infrastruktúra 47
Egy valós üzleti probléma
Adatok, követelmények és megvitatása48
eszközök beszerzése 44 Összefoglalás 49
Adatok 45
3
A kód találkozik az adattal
Az üzleti probléma elemzése és Adat előfeldolgozás 66
a probléma kategorizálása 52 Adatminőség értékelése 66
Az erőforrások és eszközök Hiányzó adatok kalibrálása 68
beállítása 54 Címkekódolás 68
Az MLflow telepítése 54 Új jellemző: Future_weather_condition 70
Azure Machine Learning 55 Adatkorrelációk és szűrés 70
Azure DevOps 58 Idősorozatok elemzése 73
JupyterHub 60
Adatok regisztrációja
A forráskódkezelés és ellátása verzióval 74
10 alapelve az ML-nél 60 Az ML folyamat irányába 76
Milyen a jó adat az ML-nek? 64 Funkció tároló 77
Összefoglalás 78
4
Machine Learning folyamatok
Átvesszük az ML folyamatok Modell tesztelése és mérések
alapjait 80 meghatározása 96
Adatbevitel és funkciótervezés 88 Az SVM osztályozó tesztelése 96
Adatbevitel (tanítási adatkészlet) 90 A Random Forest osztályozó tesztelése 97
Gépi tanulás tanítása és Modellcsomagolás 97

hiperparaméter optimalizáció 92 Modellek és termelési tárgyak
Support Vector Machine 92 regisztrációja 98
Random Forest osztályozó 94 Termelési tárgyak regisztrációja 100
Összefoglalás 102
Table of Contents iii
5
Modellértékelés és csomagolás
Modellértékelés és Következtetés 126
értelmezhetőségi mérések 104 Együttműködési képesség 126
Tanulási modellek mérései 105 Telepítési agnoszticitás 126
Hibrid modellek mérései 114
Hogyan kell csomagolni az ML
Statisztikai modellek mérései 119
modelleket? 126
HITL modellek mérése 121
Szerializált fájlok 127
Termeléstesztelési módszerek 122 Csomagolás vagy konténerezés 128
Tömeges tesztelés 123 Mikroszolgáltatás generálása és
A/B tesztelés 123 telepítése 129
Próbateszt vagy árnyékteszt 124 Következtetéskész modellek 130
Tesztelés CI/CD-ben 124
Csatlakozás a munkaterülethez és a
Miért kell csomagolni az ML modelltárgyak importálása 131
modelleket? 125 Modelltárgyak betöltése
következtetéshez 131
Szállíthatóság 125
Összefoglalás 132
2. rész: Gépi tanulási modellek telepítése

méretre
6
Az Ön ML rendszerének telepítési alapelvei
ML a kutatásban vs a Gyakorlati telepítés (az üzleti
termelésben 136 problémához) 146
Adatok 136 A modell telepítése az ACI-n 146
Méltányosság 137 A modell telepítése az Azure
Értelmezhetőség 138 Kubernetes Service-en (AKS) 153
Teljesítmény 138 A szolgáltatás telepítése az MLflow
Prioritás 139 használatával 161
Az ML következtetés típusainak A folytonos integráció

megismerése a termelésben 139 és folytonos fejlesztés
Telepítési célok 139
szükségességének felismerése 163
Az infrastruktúra leképezése a Összefoglalás 163
megoldásunknál 145
iv Table of Contents
7
Robosztus CI/CD folyamatok kialakítása
Folytonos integráció, szállítás munkaterülethez 172
és telepítés az MLOps-ban 166 Egy folytonos integrációs és
Folyamatos integráció 167 telepítési folyamat felállítása
a tesztkörnyezethez. 174
Folyamatos szállítás 167
Tárgyak csatlakoztatás a folyamathoz 175
Folyamatos telepítés 168
Egy tesztkörnyezet beállítása 178
Egy CI/CD folyamat és a
tesztkörnyezet felállítása (Azure Folyamatvégrehajtás és
DevOps használatával) 168 tesztelés 185
Egy szolgáltatási fiók létrehozása 169 Folyamat-végrehajtási
A bővítmény telepítése, hogy kapcsolók188
csatlakozzon az Azure ML Összefoglalás 190
8
API-k és mikroszolgáltatások kezelése
Bevezetés az API-khoz és Egy ML modell API-ként történő
mikroszolgáltatásokhoz 192 kiszolgálásának gyakorlati
Mi az Application Programming megvalósítása 199
Interface (API, alkalmazásprogramozó API tervezése és fejlesztése 200
interfész)? 192
Mikroszolgáltatások 193 Egy mikroszolgáltatás
fejlesztése Docker
Mikroszolgáltatások igénye használatával 206
az ML-hez 195
Az API tesztelése 207
Elméleti felhasználási eset 195
Összefoglalás212
A régi aranyat ér: REST API-
alapú mikroszolgáltatások 198
9
Az Ön ML megoldásának tesztelése és biztosítása
Az ML alkalmazásának tesztelése a tervezés szerint 214
tesztelési és biztosítási Adatok tesztelése 214
igényének felismerése 214 Modelltesztelés 215
Az Ön ML megoldásának Tanítás előtti tesztek 216
Table of Contents v
Tanítás utáni tesztek 216 Az Ön ML megoldásának

biztosítása a tervezés szerint 224
Gyakorlatias telepítés- és
Támadások típusai 225
következtetés-tesztelés
(egy üzleti felhasználási eset) 217 Összefoglalás 227
10
A termelési kiadás lényeges részei
A termelési infrastruktúra konfigurálása az
felállítása 230 automatizációhoz 245
Azure Machine Learning munkaterület 231 Egy Git kapcsoló beállítása 246
Azure Machine Learning SDK 234 Egy Tárgyas kapcsoló beállítása 247
Egy Ütemező kapcsoló beállítása 248
A termelési környezetünk
felállítása a CI/CD folyamatban 237 Folyamat kiadáskezelés 250
A termeléskész folyamatunk A folytonos monitorozás felé 252
tesztelése 243 Összefoglalás 252
Folyamatkapcsolók
3. rész: Gépi tanulási modellek

monitorozása a termelésben
11
Az Ön ML rendszerének mon-itorozási alapelvei
Egy ML rendszer Az Explainable Monitoring
monitorozásának fő alapelvei 256 Framework értelmezése 264
Modelleltérés 257 Megfigyelés 265
Modellelfogultság 258 Elemzés 267
Modellátláthatóság 258 Irányítás 271
Modellmegfelelőség 259
Magyarázható MI 260
Folytonos monitorozás lehetővé
tétele a szolgáltatásnál 274
Monitorozás az MLOps Összefoglalás 274
munkafolyamatban 263
vi Table of Contents
12
Modellek kiszolgálása és monitorozása
Modellek kiszolgálása, A modell kiszolgálása egy gépnek 280
monitorozása és fenntartása
a termelésben 276 A magyarázható monitorozási
keretrendszer megvalósítása 281
Az ML modellek
Az Ön ML rendszerének monitorozása 284
kiszolgálásának különböző
Az Ön ML rendszerének elemzése 307
módjai 277
A modell kiszolgálása tömeges Az Ön ML rendszerének
szolgáltatásként 278 irányítása 308
A modell kiszolgálása egy emberi Összefoglalás 309
felhasználónak 279
13
Az ML rendszerek irányítása a folytonos tanuláshoz
A folytonos tanulás Modell auditálása és jelentések 333
szükségességének értelmezése 312
Modell újratanításának
Folytonos tanulás 312
engedélyezése 335
A folytonos tanulás szükségessége 313
Modell manuális újratanítása 336
Magyarázható monitorozás, Modell automatikus újratanítása 336
irányítás 315
A CI/CD folyamat fenntartása 336
Riasztások és műveletek 315
Modell QA és irányítás 333
Összefoglalás 338
Miért érdemes feliratkozni? 339
Egyéb könyvek, amiket ajánlunk

Index
Előszó
Az MLOps egy szisztematikus megközelítés a gépi tanulásos (ML) megoldások
kialakításához, telepítéséhez és monitorozásához. Ez műszaki tudomány, amely számos
iparágban és használati esetben alkalmazható. Ez a könyv átfogó bepillantást tesz
lehetővé az MLOps-ba, valódi példákkal kiegészítve, hogy segítsen Önnek programokat
írni, robosztus és méretezhető ML modelleket képezni és ML folyamatokat kialakítani
a termelési modellek biztonságos képzéséhez és telepítéséhez.
Megismer az MLOps munkafolyamatot és elkezd programokat írni az ML modellek
képzéséhez. Aztán felfedezi az ML modellek utóképzésének szerializálási és csomagolási
lehetőségeit, hogy telepítse őket a termelésben a gépi tanulásos következtetés kezelésére.
Aztán az ML modellek és rendszerteljesítmény monitorozásáról fog tanulni egy
magyarázandó monitorozási keretrendszer használatával. Végül a megszerzett tudást
valós projektek készítéséhez fogja használni.
Ezen ML könyv végén teljeskörű betekintést nyer az MLOps-ba és készen fog állni
az MLOps alkalmazására a saját szervezeténél.
Kinek szól a könyv?

Ez az MLOps könyv adatkutatóknak, szoftvermérnököknek, DevOps mérnököknek,
gépi tanulással foglalkozó mérnököknek, valamint üzleti és technológiai vezetőknek
szól, akik Ml rendszereket akarnak kialakítani, telepíteni és fenntartani a termelésben
az MLOps elveinek és technikáinak felhasználásával. A gépi tanulás alapismeretei
szükségesek ezen könyv elkezdéséhez.
viii Előszó
Mit tartalmaz ez a könyv?

1. fejezet: MLOps WorkFlow alapjai, áttekintést ad a szoftverfejlesztés változó területéről,
kiemeli, hogy a hagyományos szoftverfejlesztés hogyan változik a gépi tanulás kezelése
érdekében. Ki fogunk emelni néhány mindennapos problémát a hagyományos
megközelítést használó szervezetektől, és bemutatjuk, miért van szükség a gondolkodás
és kivitelezés módosítására. Ezután szisztematikus gépi tanulás jelentőségének
bemutatásával folytatjuk, ezt a gépi tanulás és a DevOps néhány koncepciója követi,
illetve ezek MLOps-ba történő beolvasztása. A fejezet egy javaslattal végződik egy
generikus munkafolyamat alkalmazására, amellyel szinte bármely gépi tanulási probléma
megközelíthető.
2. fejezet: Az Ön gépi tanulási problémájának jellemzése, széles perspektívát kínál
a termelési ML megoldások lehetséges típusairól. Meg fogja tanulni kategorizálni
a megoldásokat, létrehozni egy ütemtervet egy megoldás fejlesztéséhez és telepítéséhez,
és beszerezni a szükséges adatokat, eszközöket vagy infrastruktúrát ahhoz, hogy
elkezdhessen szisztematikus megközelítésben fejleszteni egy ML megoldást.
3. fejezet: A kód találkozik az adattal, elkezdi a gyakorlatias üzleti eset megvalósítását egy
gépi tanulási megoldás fejlesztésével. Megvitatjuk a gépi tanulás forráskód-kezelésének,
az üzleti felhasználás adatfeldolgozásának hatékony módszereit, egy adatkezelési stratégia
kialakítását, valamint a gépi tanulás képzésének és telepítésének folyamatát.
4. fejezet: Machine Learning folyamatok, elmélyedünk a megoldásokhoz készülő gépi
tanulási folyamatok kialakításában. Megnézzük a funkciókialakítás, algoritmusválasztás,
hiperparaméter optimalizáció fő jellemzőit, illetve egy robosztus gépi tanulási folyamat
egyéb aspektusait.
5. fejezet: Modellértékelés és csomagolás, elmélyedünk a gépi tanulási modellek
utóképzésének szerializálásában és csomagolásában, hogy futásidőben telepíthesse őket,
a gépi tanulásos következtetés kezelése, modell kölcsönös átjárhatósága és az end-to-
end modell követhetősége érdekében. Széleskörű rálátása lesz az elérhető opciókra és
a legkorszerűbb fejlesztésekre a gépi tanulási modellek csomagolása és kiszolgálása terén,
hogy hatékony, robosztus és méretezhető szolgáltatásokat állíthasson elő.
6. fejezet: Az Ön ML rendszerének telepítési alapelvei, bemutatjuk a folytonos integráció
és telepítés elveit a termelésben, különböző beállításoknál. Meg fogja tanulni, hogyan
válassza ki a helyes opciókat, eszközöket és infrastruktúrát egy gépi tanulási megoldás
telepítésének kezeléséhez. Betekintést fog nyerni a gépi tanulás következtetési
lehetőségeibe és a telepítési célokba, és bevezetést kap a gépi tanulás CI/CD folyamatairól.
Előszó ix
7. fejezet: Robosztus CI és CD folyamatok kialakítása, különböző CI/CD folyamat

összetevőit nézzük meg, mint a kapcsolók, kiadások, munkák stb. Fel fogja vértezni Önt
a tudással a saját egyedi ML megoldásaihoz tartozó CI/CD folyamatainak felügyeletéhez.
Készíteni fogunk egy üzleti példához tartozó ML megoldáshoz egy CI/CD folyamatot.
Az általunk kialakítandó folyamatok nyomon követhetők lesznek a végpontok között,
mivel köztes szoftverként fognak szolgálni a modell telepítéséhez és monitorozásához.
8. fejezet: API-k és mikroszolgáltatások kezelése, belemegyünk az ML következtetéshez
tartozó API és mikroszolgáltatás tervezésének alapelveibe. Bátorítani fogjuk a gyakorlatias
megközelítést. Át fogjuk venni a gyakorlati megvalósítását egy ML modellhez tartozó API és
mikroszolgáltatás tervezésének és fejlesztésének, olyan eszközök használatával, mint amilyen
a FastAPI és Docker. Megtanuljuk a robosztus és méretezhető mikroszolgáltatások és API-k
tervezésének alapelveit, kihívásait és tippjeit a teszt- és termelési környezetek esetében.
9. fejezet: Az Ön ML megoldásának tesztelése és biztosítása, be fogjuk mutatni
a tesztkörnyezetben végzett tesztek fő elveit a korábban fejlesztett API vagy mikroszolgáltatás
robosztusságának és méretezhetőségének teszteléséhez. Gyakorlati terheléses tesztelést
fogunk végrehajtani egy telepített ML megoldáson. Ez a fejezet tartalmaz egy ellenőrzőlistát
az elvégzendő tesztekről a mikroszolgáltatás termelési kiadása előtt.
10. fejezet: A termelési kiadás lényeges részei, el fogjuk magyarázni, hogyan telepítse az ML
szolgáltatásokat a termelésbe egy robosztus és méretezhető megközelítéssel, amely egy
korábban tervezett CI/CD folyamatot használ. A termelésben lévő szolgáltatás telepítésére,
monitorozására és kezelésére fogunk koncentrálni. A fő tudnivalók a szerver nélküli
és szerveres környezetekben végzett telepítések lesznek, olyan eszközök használatával,
mint a Python, Docker, és Kubernetes.
11. fejezet: Az Ön ML rendszerének monitorozási alapelvei, megnézzük a termelésben
lévő ML rendszerek monitorozásának fő elveit és vonásait a robosztusság, biztonság és
méretezhető teljesítmény szempontjából. A fő gondolat, amit az olvasó kap egy konkrét
magyarázandó monitorozási keretrendszer és egy ellenőrzőlista lesz a termelésben lévő
ML megoldásuk monitorozó keretrendszerének felállításához és konfigurálásához.
12. fejezet: Modellek kiszolgálása és monitorozása, el fogjuk magyarázni a modellek
kiszolgálását a felhasználóknak és meghatározzuk az MLL megoldás mérését, különösen
az algoritmus hatékonyságának, pontosságának és a termelés teljesítményének
tekintetében. Elmerülünk az adateltérés, modell eltérés monitorozásának és az alkalmazás
teljesítményének gyakorlati megvalósításában és valós példáiban.
13. fejezet: Az ML rendszerek irányítása a folytonos tanuláshoz, válaszolni fogunk a gépi
tanulási megoldásoknál a folytonos tanulás szükségességének kérdésében. Meg fogjuk
nézni, mire van szükség egy ML rendszer sikeres irányításához az üzleti eredményesség
érdekében. A Magyarázandó Monitorozási keretrendszer használatával meg fogunk
tervezni egy stratégiát az irányításhoz, és meg fogunk nézni egy gyakorlati megvalósítást
a hibakezelés és a riasztások és műveletek konfigurálása szempontjából. Ez a fejezet el fogja
látni Önt a kritikus készségekkel a saját MLOps-jainak irányításához és automatizálásához.
x Előszó
Ahhoz, hogy a legtöbbet hozza ki ebből

a könyvből
Szüksége lesz egy Microsoft Azure előfizetésre és egy alap DevOps-alapú szoftver
hozzáférésére a CI/CD folyamatok kialakításához. Egy Linuxos vagy macOS-os
számítógép vagy laptop is jól jön.
A könyvben tárgyalt szoftver/

OS követelményei
hardver
Linux, macOS, vagy
Python
Windows
Linux, macOS, vagy
Git
Windows
Linux, macOS, vagy
Docker
Windows
Linux, macOS, vagy
Kubernetes
Windows
Linux, macOS, vagy
Microsoft Azure
Windows
Linux, macOS, vagy
Azure ML Service
Windows
Linux, macOS, vagy
MLFlow
Windows
Linux, macOS, vagy
Azure DevOps
Windows
Linux, macOS, vagy
Gyors API
Windows
Linux, macOS, vagy
Locust.io
Windows
Ha a digitális verzióját használja ennek a könyvnek, azt javasoljuk, hogy gépelje

be a kódot, vagy keresse ki a kódot a GitHub tárolóból (a link a következő részben
található). Ha így tesz, az segíteni fog a kód másolásával és beillesztésével kapcsolatos
potenciális hibák elkerülésében.
Előszó xi
Töltse le a példa kódfájlokat

A könyv példa kódfájljait a GitHub-ról töltheti le a következő címen: https://
github.com/PacktPublishing/EngineeringMLOps. Ha a kód frissül, akkor
a meglévő GitHub-adattárban is frissítjük azt. Más kódcsomagjaink is vannak a könyveink
és videóink gazdag katalógusában, amelyek itt érhetők el: https://github.com/
PacktPublishing/. Nézze meg őket!
Töltse le a színes képeket

Egy PDF-fájlt is biztosítunk, amely tartalmazza a könyvben használt képernyőképek/
ábrák színes képeit. Ezt itt töltheti le: https://static.packt-cdn.com/
downloads/9781800562882_ColorImages.pdf.
Alkalmazott jelölések
A könyvben többféle szöveges jelölést alkalmazunk.
Kód a szövegben: A kódszavakat jelöli a szövegben, adatbázis táblázatok neveit,
mappaneveket, fájlneveket, fájlkiterjesztéseket, elérési utakat, formális URL-eket,
felhasználói beviteleket és Twitter-neveket. Itt egy példa: "Az előkészített adatkészletet
a .get_by_name() függvénnyel importáltuk."
A kódblokkok a következőképpen néznek ki:
uri = workspace.get_mlflow_tracking_uri( )
mlflow.set_tracking_uri(uri)
Amikor fel kívánjuk hívni a figyelmét a kódblokk egy adott részére, akkor a releváns
sorokat vagy elemeket félkövérrel szedjük:
# Importing pre-processed dataset

dataset = Dataset.get_by_name (workspace, name='processed_
weather_data_portofTurku')
A parancssori bemenetek vagy kimenetek az alábbi módon vannak szedve:
python3 test_inference.py
Félkövér: Egy új kifejezést, fontos szót vagy szavakat jelöl, amelyek a képernyőn láthatók.
Például a menükön vagy párbeszédablakokon megjelenő szavak a szövegben ilyenek.
Itt egy példa: "Lépjen a Számítás opcióra és kattintson a Létrehozás gombra, hogy
megismerje a felhőn elérhető számítási lehetőségeket."
xii Előszó
Tippel vagy fontos megjegyzések

Így jelennek meg.
Kapcsolatfelvétel
Mindig szívesen fogadjuk olvasóink visszajelzését.
Általános visszajelzés: Ha a könyvre vonatkozó bármilyen kérdése van, említse meg
a könyv címét az üzenet tárgyában és küldjön egy e-mailt nekünk a customercare@
packtpub.com címre.
Hibajegyzék: Bár mindent megtettünk a tartalom pontossága érdekében, hibák mindig
vannak. Ha hibát talál ebben a könyvben, hálásak lennénk, ha jelentené nekünk. Kérjük
látogasson el a www.packtpub.com/support/errata oldalra, válassza ki a könyvét,
kattintson az Errata Submission Form linkre és írja le az információkat.
Kalózkodás: Ha bármilyen illegális másolatával találkozik a munkáinknak az interneten,
hálásak lennénk, ha megadná nekünk az elérési címet vagy a weboldal nevét. Kérjük,
vegye fel velünk a kapcsolatot a copyright@packt.com címen az anyag linkjével.
Ha szeretne szerzővé válni: Ha van olyan terület, amelynek Ön a szakértője, és szeretne
könyvet írni, vagy közreműködni benne, kérjük látogasson el az authors.packtpub.
com címre.
Vélemények
Kérjük, írjon véleményt. Miután elolvasta és használta a könyvet, írjon egy véleményt azon
a webhelyen, ahonnan könyvet megvásárolta. Ezáltal a potenciális olvasók is láthatják és
használhatják az Ön elfogulatlan véleményét a vásárlási döntések meghozatalához; a Packt
csapatánál megtudhatjuk, mit gondolnak vevőink a termékeinkről; szerzőink pedig
megismerhetik a visszajelzését a könyveikkel kapcsolatban. Köszönjük!
További információkért a Packt-ról, kérjük, látogasson el a packt.com címre.
1. rész:
Keretrendszer gépi
tanulási modellek
kiépítéséhez
Ez a rész megismerteti az olvasókat az MLOps és munkafolyamatok alapjaival,

hogy jellemezhessék az ML problémáikat, hogy tiszta képet kapjanak a robosztus és
méretezhető ML folyamatok kiépítéséről. Ezt gyakorlatias megközelítésben ismerhetik
meg praktikus megvalósításon keresztül, amely a javasolt módszereket és eszközöket
(Azure Machine Learning szolgáltatások vagy MLflow) használja.
Ez a rész a következő fejezeteket tartalmazza:
• 1. fejezet: MLOps WorkFlow alapjai

• 2. fejezet: Az Ön gépi tanulási problémájának jellemzése
• 3. fejezet: A kód találkozik az adattal
• 4. fejezet: Machine Learning folyamatok
• 5. fejezet: Modellértékelés és csomagolás
1
MLOps WorkFlow
alapjai
A gépi tanulás (ML) az alkalmazott üzleti megoldások kutatásából forrott ki. Azonban
a szomorú igazság az, hogy az ML-t használó vállalatoknak csak 2%-a telepített sikeresen
egy modellt a termelésben ahhoz, hogy javítsa az üzleti folyamatait, a DeepLearning.AI
(https://info.deeplearning.ai/the-batch-companies-slipping-on-
ai-goals-self-training-for-better-vision-muppets-and-models-
china-vs-us-only-the-best-examples-proliferating-patents)
jelentése szerint. Mitől lesz ez olyan nehéz? És mire van szükségünk a helyzet javításához?
Ahhoz, hogy jól megértsük ezt a problémát és annak megoldásait, ebben a fejezetben
a mélyére ásunk az ML és a szoftverfejlesztés metszetének és fejlődésének. Azzal kezdünk,
hogy reflektálunk a hagyományos szoftverfejlesztés néhány trendjére, a vízesés-módszertől
kezdve az agilis DevOps gyakorlatokig, és h gy ezek hogyan fejlődtek az ML-alapú
alkalmazások iparosításává. Bemutatjuk a Gépi tanulásos műveleteket (MLOps) használó
MI működésbe hozásának egy szisztematikus megközelítését. A fejezet végére megismeri
az MLOps-t és képes lesz megvalósítani egy generikus MLOps munkafolyamatot, amely
felhasználható az ML alkalmazások széles választékának kialakítására, telepítésére és
monitorozására.
4 MLOps WorkFlow alapjai
Ebben a fejezetben a következő fő témákat érintjük:
• A szoftver- és infrastruktúrafejlesztés evolúciója

• A hagyományos szoftverfejlesztés kihívásai
• Az ML adoptációjának trendjei a szoftverfejlesztésben
• Az MLOps megértése
• MLOps munkafolyamatai és elvei
A szoftver- és infrastruktúrafejlesztés
evolúciója
A modern internetes kor (1995 körül) beköszöntésével a szoftveres alkalmazások
növekedését figyelhettük meg, az olyan operációs rendszerektől kezdve, mint
amilyen a Windows 95 a Linus operációs rendszerekig és weboldalakig, mint amilyen
a Google és az Amazon, amelyek több, mint két évtizede szolgálják a világot (online).
Ez a folyamatosan fejlődő szolgáltatások kultúráját eredményezte a felhasználói
interakciókból származó hatalmas mennyiségű adat gyűjtése, tárolása és feldolgozása
révén. Az ilyen fejlesztések formálják az IT infrastruktúra- és szoftverfejlesztés evolúcióját.
Az IT infrastruktúra átalakulása az évezred eleje óta felgyorsult. Azóta a cégek egyre
jobban adoptálták a felhő alapú számítást, mivel az új lehetőségeket tárt fel számukra,
hogy kiszervezzék az IT infrastruktúra karbantartását, miközben biztosítja a szükséges
IT erőforrásokat, mint amilyen a tárhely, a számítási erőforrások és a műveletek
méretezéséhez és futtatásához szükséges szolgáltatások.
A felhő alapú számítás igény szerint biztosítja az olyan IT erőforrások elérhetőségét,
mint amilyen az adattárolás és a számítási erőforrások úgy, hogy nincs szükség arra, hogy
az IT erőforrások felhasználója aktívan menedzselje őket. Például a számítási és tárolási
erőforrásokat biztosító cégeknek nem kell közvetlenül kezelniük ezeket az erőforrásokat,
és nem felelősek a futtatásukért, a karbantartást kiszervezték a felhőszolgáltatónak.
A felhő alapú számítást használó cégek profitálhatnak belőle, mivel nem kell megvenniük
és karbantartaniuk az IT erőforrásokat; ez lehetővé teszi számukra, hogy kevesebb belsős
szakembert foglalkoztassanak az IT erőforrások karbantartása terén, és így optimalizálni
tudják a költségeket és erőforrásokat. A felhő alapú számítás lehetővé teszi az igény
szerinti méretezést, és a felhasználók az erőforrások felhasználása alapján fizetnek.
Ennek eredményeként olyan cégeket láttunk, akik a vállalkozásuk és IT infrastruktúrájuk
részeként adoptálták a felhő alapú számítást.
A szoftver- és infrastruktúrafejlesztés evolúciója 5
A felhő alapú számítás 2006 óta vált népszerűvé az iparban, amikor a Sun Microsystems
elindította a Sun Grid-et 2006 márciusában. Ez egy hardver- és adaterőforrás megosztó
szolgáltatás. Ezt a szolgáltatást vásárolta fel az Oracle, és később Sun Cloud-nak nevezték.
Ezzel párhuzamosan ugyanabban az évben (2006) egy másik felhő alapú számítási
szolgáltatást indított el az Amazon, amelyet Elastic Compute Cloud-nak hívtak. Ez új
lehetőségeket tett elérhetővé a cégek számára az igény szerinti számítási, tárolási és
méretezési lehetőségek biztosításához. Azóta az iparágak közötti átalakulás egységesen
a felhő alapú számítás irányába tart.
Az elmúlt évtizedben globális és regionális szinten is számos cég katalizálta a felhőre
való áttérést, olyan vállalatokkal, mint a Google, IBM, Microsoft, UpCloud, Alibaba és
még mások, akik komolyan beruháztak a felhőszolgáltatások kutatásába és fejlesztésébe.
Ennek eredményeképp váltás történt a helyi számításról (a cégeknek saját szervereik
és adatközpontjaik vannak) az igény szerinti számításra, ennek oka a robosztus és
méretezhető felhőszolgáltatások elérhetősége. Ma a cégek és szervezetek képesek igény
szerint biztosítani az erőforrásokat a felhőben, hogy kielégítsék az adatfeldolgozási
igényeiket.
Ezzekel a fejlesztésekkel működés közben figyelhettük meg Moore törvényét, amely azt
állítja, hogy az egy mikrochipen található tranzisztorok száma 2 évente megduplázódik,
bár a számítógépek ára feleződik, ez idáig igaz volt. Következésképpen néhány trend
a következőként változik.
A gépi tanulás és mély-tanulás erősödése

Az elmúlt évtizedben megfigyelhettük az ML adoptációját a mindennapi alkalmazásokban.
Nem csak az olyan ezoterikus alkalmazásoknál, mint amilyen a Dota vagy az AlphaGo,
de az ML megtalálta az útját az olyan szabványos alkalmazásokhoz is, mint amilyen a gépi
fordítás, képfeldolgozás és a hangfelismerés.
Ezt az adoptációt az infrastruktúra fejlődése segítette, különösen a számítási kapacitás

kihasználása. Ez tette lehetővé a mély-tanulás és ML potenciálját. Megfigyelhetjük,
hogy a mély-tanulás áttörései korrelálnak a számítási fejlesztésekkel az 1.1 ábrán (Forrás:
OpenAI: https://openai.com/blog/ai-and-compute):
1.1 ábra: A mély-tanulás kereslete az idő függvényében, a számítással támogatva

Ezeket a mély-tanulásos áttöréseket a számítás exponenciális növekedése tette lehetővé,
amely nagyjából 35-szörösen növekszik 18 havonta. Ha a jövőbe tekintünk, ilyen igények
mellett útakadályokba ütközhetünk a központi számítás fejlesztése terén a CPU-knál,
GPU-knál vagy TPU-knál. Ez arra kényszerített minket, hogy olyan alternatívákat
keressünk, mint például a megosztott tanulás, ahol az adatfeldolgozás számításigénye
több számítási csomópont között oszlik szét. Láttunk néhány áttörést a megosztott
tanulásnál, mint amilyen az egyesített tanulás és az élszámítási megközelítések.
A megosztott tanulás reményt adott rá, hogy kiszolgálja a mély-tanulás növekvő igényeit.
A Moore-törvény vége
2012 előtt az MI eredményei szorosan követték a Moore-törvényt, a számítás 2 évente
megduplázódott. 2012 óta a számítás 3,4 hónaponta duplázódik meg (forrás: AI Index
2019 - https://hai.stanford.edu/research/ai-index-2019). Az 1.1 ábrán
megfigyelhetjük, hogy a kereslet a mély-tanulásra és a nagy teljesítményű számításra
(HPC) exponenciálisan növekszik, nagyjából 35-szörös a számítás növekedése
18 hónaponta, és ez láthatóan túlszárnyalja a Moore-törvényt (2x, 18 hónaponta).
A Moore-törvény még mindig érvényes a CPU-k (egymagos teljesítmény) esetében, de az
olyan új hardver architektúrákra, mint a GPU és TPU, nem. Ez elavulttá és túlszárnyalttá
teszi a Moore-törvényt a jelenlegi igények és trendek tükrében.
MI-alapú alkalmazások
Az alkalmazások MI-alapúvá válnak, ezt több iparágban látjuk. Jóformán minden
alkalmazás elkezdi használni az MI-t, és ezek az alkalmazások külön futnak megosztott
munkaterheléseken, mint amilyen a HPC, mikroszolgáltatások, és a big data, ahogy az
a 1.2 ábrán látható:
1.2 ábra: Megosztott munkaterheléseken futó alkalmazások

A HPC és MI kombinálásával elérhetővé tehetjük azokat a számítási előnyöket,

amelyekre a mély-tanulásos és ML modellek tanításához van szükség. A big data
és MI átfedésével olyan léptékben használhatjuk ki a szükséges adat kinyerését,
amely az MI modell tanításához kell, illetve a mikroszolgáltatások és MI átfedésével
kiszolgálhatjuk az MI modelleket a következtetéshez az üzleti műveletek és hatás javítása
érdekében. Így a megosztott alkalmazások válnak az új normává. A megfelelő méretű
MI-alapú alkalmazások fejlesztése megkövetelni a megosztott alkalmazások (HPC,
mikroszolgáltatások és big data) szinergiáját, és ehhez egy új fajta szoftverfejlesztés
szükséges.
A szoftverfejlesztés evolúciója
A szoftverfejlesztés kéz a kézben fejlődött az infrastruktúrafejlesztéssel, hogy kezelje az
alkalmazások hatékony fejlesztését az infrastruktúra használatával. Hagyományosan
a szoftverfejlesztés a fejlesztés vízesés-módszerével kezdődött, ahol a fejlesztést lineárisan
végezték a követelmények összegyűjtésével a kialakításhoz és fejlesztéshez. A vízesés-
modellnek számos korlátozása van, amelyek az évek folyamán a szoftverfejlesztés
evolúciójához vezettek, az Agile módszertanok és a DevOps módszer képében, ahogy az
1.3 ábrán látható:
1.3 ábra: A szoftverfejlesztés evolúciója
A vízesés-módszer
A vízesés-módszert szoftverfejlesztésre használták az internetes kor (~1995) kezdete
óta. Ez egy nem iteratív szoftverfejlesztési mód. Egyirányú módszer. Minden szakasza
előre szervezett és egymás után kerül végrehajtásra, a követelmények összegyűjtésétől
kezdve a szoftvertervezésig, -fejlesztésig és -tesztelésig. A vízesés-módszer megfelelő
és megvalósítható, amikor jól meghatározott, konkrét követelmények vannak, és azok
nem változnak az idő múlásával. Így ez nem felel meg a dinamikus projektekhez, ahol
a követelmények a felhasználói igények szerint változnak és fejlődnek. Az ilyen esetekben,
ahol folytonos a módosítás, a vízesés-módszer nem használható a szoftverfejlesztéshez.
A vízesés szoftverfejlesztési módszer fő hátrányai a következők:
• A teljes követelménykészletet meg kell adni a fejlesztés előtt; a projekt előrehaladása

közben vagy után a módosításuk nem lehetséges.
• Kisebb az esély az újrahasználható komponensek létrehozására vagy

megvalósítására.
• A tesztelést csak a fejlesztés befejezése után lehet elvégezni. A tesztelés nem
iterálható; nem lehet visszatérni és javítani a dolgokat, ha azok elkészültek.
Továbbá az ügyfél átvételi vizsgálatai gyakran módosításokat eszközölnek,
ami a leadás késését és magasabb költségeket eredményez. Az ilyen fejlesztés
és tesztelés negatív hatással lehet a projekt leadási ütemtervére és a költségekre.
• Legtöbbször a rendszer felhasználói olyan rendszert kapnak, amely a fejlesztő
meglátásain alapszik, így nem felhasználóközpontú és lehet, hogy nem felel meg
az igényeiknek.
Az Agile módszer
Az Agile módszer elősegíti az iteratív és progresszív megközelítését a szoftverfejlesztésnek.
A vízesés módszerrel szemben az Agile megközelítés precíz és felhasználóközpontú.
A módszer kétirányú és gyakran bevonja a végfelhasználókat vagy ügyfeleket a fejlesztési
és tesztelési folyamatba, így lehetőségük van tesztelni, visszajelezni és javításokat javasolni
a projekt fejlesztési folyamata és fázisai során. Az Agile-nak számos előnye van a vízesés
módszerrel szemben:
• A követelményeket a fejlesztés előtt határozzák meg, de bármikor módosíthatók.

• Lehetséges az újrahasználható komponensek létrehozása vagy megvalósítása.
• A megoldás vagy projekt lehet moduláris, ha a projektet különböző modulokra
választják szét, amelyeket periodikusan adnak le.
• A felhasználók vagy ügyfelek részt vehetnek az alkotásban a kifejlesztett megoldási
modulok periodikus tesztelése és értékelése által, így biztosíthatják az üzleti igények
teljesülését. Az ilyen felhasználóközpontú folyamat biztosítja, hogy az eredmény
minősége megfeleljen az ügyfél és üzlet igényeinek.
A következő ábra mutatja a különbséget a vízesés és Agile módszerek között:
1.4 ábra: A különbség a vízesés és Agile módszerek között
A DevOps módszer
A DevOps módszer kibővíti az agile fejlesztési gyakorlatokat a szoftverváltozás
mozgásának korszerűsítésével a kialakítás, tesztelés, telepítés és leadás folyamatán keresztül.
Arra bátorítja a szoftverfejlesztőket, hogy CI/CD folyamatokat használó alkalmazásokat
készítsenek a keresztfunkcionális csapatok közötti autonómia engedélyezésével.
Ez összehozza a fejlesztést, IT műveleteket, minőségbiztosítást és biztonságot, hogy
javítsa a szoftver leadásának minőségét és hatékonyságát. A DevOps gyakorlatok és
eszközök egy keretrendszert biztosítanak a jobban megtervezett, fejlesztett és telepített
szoftver létrehozásához, amely jobban válaszol az ügyfél igényeire. A DevOps módszerek
használatával lehetőség van a szoftver gyors elkészítésére és megbízható futtatására.
A hagyományos szoftverfejlesztés kihívásai 11
A hagyományos szoftverfejlesztés kihívásai

Az előző részben láttuk a szoftverfejlesztés evolúcióját a hagyományos vízesés modelltől
az Agile és DevOps gyakorlatokig. Azonban ezen modern módszerek sikere ellenére nem
használhatjuk ugyanezeket a módszereket a gépi tanulásos alkalmazásokhoz.
Ahhoz, hogy lássuk, miért, meg kell néznünk, valójában mi is a gépi tanulás; nem
csupán egy kód, mint a hagyományos szoftverfejlesztésnél, hanem kód és adat. Az adat
alapvető fontosságú az ML modellnél, ahogy az 1.5 ábrán látható, és a kód teszi lehetővé
számunkra, hogy hozzáillesszük az adatot, így ötleteket nyerhetünk belőle.
1.5 ábra: Gépi tanulás = adat + kód

A kód és adat ezen kapcsolata miatt gondosan össze kell kapcsolni a kettőt a fejlesztésben,
így irányított módon fejlődnek a robosztus és méretezhető ML rendszer közös célja felé;
a tanításhoz, teszteléshez és következtetéshez szükséges adat a különböző források között
és az idő múlásával változik, illetve meg kell felelnie a változó kódnak. A szisztematikus
MLOps megközelítés nélkül eltérés lehet abban, ahogy a kód és adat fejlődik, amely
problémákat okoz a termelésben, útját állja az egyenletes telepítésnek, és olyan
eredményekhez vezet, amelyeket nehéz követni és reprodukálni.
1.6 ábra: Az adat és kód haladása az idő múlásával

Az MLOps korszerűsíti az ML alkalmazások fejlesztési, telepítési és monitorozási
folyamatát, egyesíti az érintett különböző csapatok közreműködését, és biztosítja,
hogy az összes lépés a folyamatban nyilvántartott és megismételhető legyen. A következő
részben megtanuljuk, az MLOps hogyan teszi lehetővé és erősíti az adatkutatást és az
IT csapatokat az együttműködésben a robosztus és méretezhető ML rendszerek kialakítása
és fenntartása érdekében.
Az ML adoptációjának trendjei a szoftverfejlesztésben 13
Az ML adoptációjának trendjei
a szoftverfejlesztésben
Mielőtt elmélyednénk az MLOps módszer és munkafolyamat működésében, érdemes
megérteni az átfogó képet és a trendeket arról, hogy az MLOps hol és hogyan jelent meg
a világban. Ahogy számos alkalmazás vált MI-alapúvá, a szoftverfejlesztés továbbfejlődött
az ML elősegítésére. Az ML egyre nagyobb részét fogja képezni a szoftverfejlesztésnek,
főleg a következő okok miatt:
• Befektetések: 2019-ben a globális magán MI-nél a befektetések elérték a 70 milliárd

$-t, az MI-hez kapcsolódó start-up befektetés több, mint 37 milliárd $ volt, M&A
34 milliárd $, IPO-k 5 milliárd $, és a kisebbségi részesedés értéke nagyjából 2
milliárd $. A globális MI előrejelzés gyors növekedést mutat a piaci értékben, mivel
az MI 2018-ban elérte a 9,5 milliárd $-t, és várhatóan 2025-re 118 milliárd $ lesz
a piaci értéke. A becslések szerint az MI miatti gazdasági növekedés 2030-ig nagy
értékű és jelentős lesz. Jelenleg a globális KT-alap ~50%-a az USA-jé, ~39% Kínáé és
11% Európáé.
• Big data: Az adatok mennyisége, gyorsasága, pontossága és változatossága
exponenciálisan nő. Például a megfigyelések szerint az adatok mennyisége 61%-kal
nő évente Európában, és várhatóan négyszer annyi adat lesz 2025-re, mint amennyi
ma van. Az adat egy szükséges nyersanyag az MI fejlesztéséhez.
• Infrastrukturális fejlesztések és adoptáció: 2012-ig a Moore-törvény szorosan
követte a valóságot. 2012 óta a számítás 3,4 hónaponta duplázódik.
• A kutatás és fejlesztés fokozása: Az MI kutatása minőségben és mennyiségben is
virágzik. Egy kiemelkedő, 300%-os növekedés figyelhető meg a lektorált MI anyagok
mennyiségében 1998-tól 2018-ig, amely a publikált konferencia anyagok 9%-a és
a lektorált szakcikkek 3%-a.
• Ipar: Egy felmérésről készített jelentés alapján a nagy vállalatok 47%-a adoptálta
az MI-t legalább egy funkciónál vagy üzletágnál. 2019-ben ez 58%-ra emelkedett,
és várhatóan növekedni fog.
Információ
Ezen pontok forrása az Európai Bizottság megbízható MI-re vonatkozó
szabályzata és befektetési ajánlatai (https://ec.europa.eu/
digital-single-market/en/news/policy-and-
investment-recommendations-trustworthy-artificial-
intelligence) és a 2019-es MI Index (https://hai.stanford.
edu/research/ai-index-2019).
Ezek a fejlesztések az MI iparosításának erőteljes törekvését jelzik, és ez az ipar és kutatás

összekötésével lehetséges. Az MLOps kulcsszerepet fog játszani az MI iparosításában.
Ha egy tanulási módszerbe fektet be, az előnyt biztosíthat a vállalatának vagy csapatának,
és Ön lehet az ML működésbe hozásának és az MI iparosításának katalizátora.
Eddig tanultunk néhány kihívásról és fejlesztésről az IT, szoftverfejlesztés és MI területén.
Következőként elmélyedünk az MLOps elvi felépítésében és részletesen megismerünk egy
generikus MLOps munkafolyamatot, amely általánosan használható bármilyen esetben.
Ezek az alapok segíteni fognak Önnek átlátni az MLOps-t.
Az MLOps megértése
Az MLOps célja a termelési ML rendszerek hatékony és megbízható kialakítása, telepítése
és fenntartása. Ez egy kialakulóban lévő, interdiszciplináris módszer, amely az ML,
DevOps és az adattechnika metszetében áll.
1.7 ábra: Az MLOps metszete

Az MLOps megértése 15
A metszet (MLOps) működésbe hozásához terveztem egy moduláris keretrendszert

a Wieringa által javasolt szisztematikus tervezéstudományi módszer alapján
(https://doi.org/10.1007/978-3-662-43839-8) egy munkafolyamat
fejlesztéséhez, amely összehozza ezt a hármat (Adattechnika, Gépi tanulás és DevOps).
A tervezéstudomány a problémáknak és kontextusnak megfelelő alkalmazáskialakítással
foglalkozik. A tervezéstudomány a tárgyak vizsgálata és tervezése egy kontextuson belül.
A tárgy ebben az esetben az MLOps munkafolyamat, amelyet iteratívan terveztek meg
a probléma kontextusaival (ipari alkalmazási esetek az MI alkalmazására):
1.8 ábra: Tervezéstudományi munkafolyamat

Egy szerkesztett és iteratív megközelítésben a két ciklus (a tervezési ciklus és az
empirikus ciklus) megvalósítását kvalitatív és kvantitatív elemzéssel végzik az MLOps
munkafolyamat tervezéséhez, iterációkon keresztül. Ezen ciklusok eredményeként
egy MLOps munkafolyamatot több problémát tartalmazó kontextusokban történő
alkalmazással fejlesztik és validálják, amely legalább tíz ML felhasználási eset (például
anomália észlelése, valós idejű kereskedelem, előrejelző karbantartás, ajánló rendszerek,
virtuális asszisztensek stb.) több iparágban (például pénzügy, gyártás, egészségügy,
kiskereskedelem, autóipar, energiaipar stb.). Különféle projektekben alkalmaztam és
validáltam sikeresen ezt az MLOps munkafolyamatot több iparágban az ML működésbe
hozásához. A következő részben átnézzük a tervezéstudományi folyamat eredményeként
megtervezett MLOps munkafolyamat elveit.
MLOps munkafolyamatai és elvei

Ebben a részben egy generikus MLOps munkafolyamatról fogunk tanulni; ez számos
tervezési iterációciklus eredménye, ahogy azt az előző részben megvitattuk. Korszerű
módon hozza össze az adattechnikát, ML-t és a DevOps-t. Az 1.9 ábra egy generikus
MLOps munkafolyamat, amely moduláris és flexibilis, és alkalmas az ML megoldások
működésbe hozására vagy működőképességének bizonyítására bármely üzletágban vagy
iparágban:
1.9 ábra: MLOps munkafolyamat

Ez munkafolyamat két modulra tagolódik:
• MLOps folyamat (kialakítás, telepítés és monitorozás: a felső réteg

• Meghajtók: Adat, kód, tárgyak, köztes szoftver és infrastruktúra; a középső és alsó
rétegek
A felső réteg az MLOps folyamat (kialakítás, telepítés és monitorozás), amelyet az olyan

meghajtók tesznek lehetővé, mint az adat, kód, tárgyak, köztes szoftverek és infrastruktúra.
Az MLOps folyamatot a szolgáltatások, meghajtók, köztes szoftverek és infrastruktúra
tömbje működteti, illetve ez készíti az ML-vel működő megoldásokat. Ezen folyamat
használatával egy cég vagy személy(ek) gyorsan elvégezheti a modell(ek) prototípus
készítését, tesztelését, validálását és telepítését a termelésben egyszerű és hatékony
mértékben.
Az MLOps munkafolyamat megvalósításának és működésének megértéséhez megnézzük
az egyes rétegek és lépések megvalósítását egy képletes üzleti felhasználási mód
használatával.
MLOps munkafolyamatai és elvei 17
Egy felhasználási mód megvitatása

Ennél a felhasználási módnál egy képosztályozó szolgáltatást működtetünk
(prototípuskészítés és telepítés a termelésben), amely macskákat és kutyákat osztályoz
egy állatsimogatóban a spanyolországi Barcelonában. A szolgáltatás valós időben fogja
azonosítani a macskákat és kutyákat a következtetéses adatokból, amelyek az
állatsimogatóban felszerelt CCTV kamerából érkeznek.
Az állatsimogató megadja a hozzáférést a szolgáltatás működtetéséhez szükséges
adatokhoz és infrastruktúrához:
• Adatok: Az állatsimogató hozzáférést adott az adattárolóhoz, amely 100000

címkézett képet tartalmaz macskákról és kutyákról, amelyek a modell tanításához
fogunk használni.
• Infrastruktúra: Nyilvános felhő (IaaS).
Ez a felhasználási mód hasonlít az ML működésbe hozásának valós felhasználási

módjához, és ezzel magyarázzuk az MLOps munkafolyamat megvalósítását és működését.
Ne felejtse el megkeresni a magyarázatát a felhasználási mód megvalósításának az MLOps
munkafolyamat minden szegmensénél és lépésénél. Most nézzük meg részletesen az
összes réteg és lépés működését.
Az MLOps folyamat
A felső réteg az MLOps folyamat, amely olyan műveleteket végez, mint például
a kialakítás, telepítés és monitorozás, ezek modulárisan működnek, egymással
szinkronban. Nézzük meg az egyes modulok működését.
Kialakítás
A kialakítás modul rendelkezik a fő ML folyamattal, és ez kizárólag az ML modellek
tanítására, csomagolására és verziókezelésére szolgál. A szükséges számítási erőforrások
(például a felhőben vagy a megosztott számítási kapacitáson található CPU vagy GPU)
működteti, hogy futtassa az ML tanítását és folyamatát:
1.10 ábra: MLOps, kialakítási folyamat

A folyamat balról jobbra halad. Nézzük meg részletesen az egyes lépések működését:
• Adatbevitel: Ez a lépés aktiválja az ML folyamatot. Ez foglalkozik az adat

mennyiségével, gyorsaságával, pontosságával és változatosságával a különböző
adatforrásokból (például adatbázisok, adatraktárak vagy adattárolók) történő
adat kinyerése által, és beviszi a szükséges adatot a modell tanítási lépéséhez.
Robosztus adatfolyamatok kapcsolódnak több adatforráshoz, ez teszi lehetővé
a kinyerés, átalakítás és betöltés (ETL) műveletek végrehajtását az ML tanítási
céljaihoz szükséges adatok biztosítása érdekében. Ennél a lépésnél feloszthatjuk
és elláthatjuk verzióval az adatokat a modell tanításához a szükséges formátumban
(például a tanítási vagy tesztelési készlet). A lépés eredményeként bármilyen kísérlet
(azaz modelltanítás) auditálható és visszakövethető.
Az adatbeviteli lépés jobb megértése érdekében itt van az előbb leírt felhasználási
mód megvalósítása:
A felhasználási mód megvalósítása
Mivel hozzáférése van az állatsimogató adattárolójához, így már megszerezheti
az adatokat a kezdéshez. Az adatfolyamatok felhasználásával (az adatbeviteli lépés
részeként), a következőt teszi:
1. A macskákról és kutyákról készült 100000 kép kinyerése, átalakítása és betöltése
2. Az adatok felosztása és ellátása verzióval a tanítás és tesztelés közötti
felosztáshoz (80% és 20% felosztással).
Az adat ellátása verzióval lehetővé teszi az end-to-end követhetőséget a tanított
modelleknél.
Gratulálok, már készen áll az ML modell tanítására és tesztelésére ezen adatok
felhasználásával.
• Modelltanítás: Az előző lépésben az ML modelltanításához szükséges adatok
megszerzése után ez lépés fogja lehetővé tenni a modelltanítást; moduláris
szkriptekkel vagy kóddal rendelkezik, amely végrehajtja az összes hagyományos
lépést az ML-ben, mint amilyen az adat előfeldolgozása, a funkció készítése és
méretezése a modell tanítása vagy újratanítása előtt. Ezután az ML modell tanítása
következik, a hiperparaméter hangolása közben, hogy modell illeszkedjen az
adatkészlethez (tanítási készlethez). Ez lépés végezhető manuálisan, de léteznek
olyan hatékony és automatikus megoldások, mint például a Grid Searchvagy
a Random Search. Ennek eredményeként az ML modelltanítás minden fontos
lépése egy olyan ML modellel hajtódik végre, mint amilyen ennek a lépésnek
a kimenete.

Ebben a lépésben megvalósítjuk a képosztályozó modell tanításához szükséges
összes fontos lépést. A cél egy olyan ML modell tanítása, amely osztályozza
a macskákat és kutyákat. Ebben az esetben egy konvolúciós neurális hálót
(CNN - https://towardsdatascience.com/wtf-is-image-
classification-8e78a8235acb) tanítunk a képosztályozó szolgáltatáshoz.
A következő lépéseket hajtjuk végre: adatok előfeldolgozása, funkciók kialakítása
és méretezése a tanítás előtt, ezt követi a modell tanítása a hiperparaméter
hangolásával. Ennek eredményeként egy olyan CNN modellünk van, amely
97%-os pontossággal osztályozza a macskákat és kutyákat.
• A modell tesztelése: Ebben a lépésben kiértékeljük a tanított modell teljesítményét
egy elkülönített adatpontkészlettel, amelyet tesztadatoknak nevezünk (ezt osztottuk
fel és láttuk el verzióval az adatbevitel lépésnél). A tanított modell következtetését
a felhasználási módnak megfelelően kiválasztott mérések szerint értékeljük.
Ennek a lépésnek a kimenete egy jelentés a tanított modell teljesítményéről.
Teszteljük a tanított modellt a tesztadatokkal (az adatokat korábban felosztottuk
az Adatbevitel lépésnél), hogy kiértékeljük a tanított modell teljesítményét.
Ebben az esetben a pontosságot és a visszahívási pontot nézzük, hogy validáljuk
a modell teljesítményét a macskák és kutyák osztályozásában, hogy megbecsüljük
hamis pozitívok és valódi pozitívok számát, hogy realisztikus képet kapjunk
a modell teljesítményéről. Ha és amikor elégedettek vagyunk az eredményekkel,
tovább léphetünk a következő lépésre, vagy újra iterálhatjuk az előző lépéseket,
hogy egy megfelelően teljesítő modellt kapjunk az állatsimogató képosztályozó
szolgáltatásához.
• A modell csomagolása: Miután teszteltük az előző lépésben a betanított modellt,
a modell szerializálható egy fájllá vagy konténerizálható (a Docker használatával),
hogy exportálják a termelési környezetbe.
Egy ONNX fájllá szerializáltuk a modellt, amelyet az előző lépésekben tanítottunk
és teszteltünk, és készen áll a telepítésre a termelési környezetben.
• A modell regisztrációja: Ebben a lépésben az előző lépésben szerializált vagy

konténerizált modellt regisztráljuk és tároljuk a modelljegyzékben. A regisztrált
modell egy vagy több fájl logikus gyűjteménye vagy csomagja, összeállítja, képviseli
és végrehajtja az Ön ML modelljét. Például több fájl regisztrálható egyetlen
modellként. Például egy osztályozó modell állhat vektorizáló, modellmérő és
szerializált modellfájlokból. Ezek a fájlok mind regisztrálhatók egyetlen modellként.
A regisztráció után a modell (az összes vagy az egyetlen fájl) szükség szerint
letölthető és telepíthető.
Az előző lépésben szerializált modellt regisztráltuk a modelljegyzékben, és elérhető
a gyors telepítéshez az állatsimogató termelési környezetében.
Az előző lépések teljesítésével sikeresen végrehajtottuk a felhasználási módunkhoz
tervezett ML folyamatot. Ennek eredményeként vannak betanított modelljeink
a modelljegyzékben, amelyek készen állnak a telepítésre a termelési környezetben.
Következőként megnézzük a telepítési folyamat működését.
Telepítés
A telepítés modul lehetővé teszi az ML modellek működésbe hozását, amelyeket az
előző modulban (kialakítás) fejlesztettünk. Ebben a modulban teszteljük a modellünk
teljesítményét és viselkedését egy termelési vagy termeléshez hasonló (teszt) környezetben,
hogy megbizonyosodjunk az ML modell robosztusságáról és méretezhetőségéről
a termelési felhasználásnál. Az 1.11 ábra leírja a telepítési folyamatot, amelynek két
a komponense van, a termelési tesztelés és a termelési kiadás; illetve a telepítési folyamatot
a korszerűsített CI/CD folyamatok teszik lehetővé, amelyek összekötik a fejlesztést
a termelési környezetekkel:
1.11 ábra: MLOps, telepítési folyamat

Ez is balról jobbra halad. Nézzük meg részletesen az egyes lépések működését:
• Alkalmazás tesztelése: Mielőtt telepítenénk egy ML modellt a termelésben,

létfontosságú, hogy a teszteléssel ellenőrizzük a robosztusságát és teljesítményét.
Így van egy "alkalmazástesztelés" fázis, ahol szigorúan teszteljük minden betanított
modell robosztusságát és teljesítményét egy termeléshez hasonló környezetben,
amelyet tesztkörnyezetnek nevezünk. Az alkalmazástesztelés fázisban telepítjük
a modelleket a tesztkörnyezetben (termelés előtt), amely a termelési környezetet
másolja le.
A tesztelendő ML modellt egy API-ként vagy adatfolyamos szolgáltatásként
telepítjük a tesztkörnyezetben az olyan telepítési céloknál, mint amilyen a Kubernetes
klaszterek, konténerpéldányok vagy méretezhető virtuális gépek vagy határeszközök
a felhasználási mód és igény szerint. A modell telepítése után előrejelzéseket végzünk
a tesztadatok felhasználásával (amelyeket nem használtunk a modell tanításához;
a tesztadat mintaadat egy termelési környezetből) a telepített modellnél, amely
során a modell következtetése csomagokban vagy periodikusan történik a telepített
modell tesztelése érdekében a tesztkörnyezetben a robosztusság és teljesítmény
szempontjából.
A teljesítmény eredményeit egy minőségbiztosítási szakértő áttekintheti
automatikusan vagy manuálisan. Amikor az ML modell teljesítménye megfelel
a szabványoknak, akkor elfogadják a telepítését a termelési környezetben,
ahol a modellt használni fogják a csomagonkénti vagy valós idejű következtetésre,
az üzleti döntések meghozásához.
A modellt egy API szolgáltatásként telepítjük egy helyi számítógépre az
állatsimogatóban, amelyet tesztelési célokra állítottak be. Ez a számítógép
csatlakozik egy CCTV kamerához a simogatóban, hogy valós idejű következtetési
adatokat olvasson ki, hogy megjósolja a macskákat vagy kutyákat a videó
képkockáin. A modell telepítését a CI/CD folyamat engedélyezi. Ennél a lépésnél
a modell robosztusságát teszteljük egy termeléshez hasonló környezetben, hogy
a modell konzisztensen, pontosan igazságosan hajtja-e végre a következtetést
és a hibaelemzést. Ennek a lépésnek a végén egy minőségbiztosítási szakember
tanúsítja a modellt, ha az megfelel a szabványoknak.
• Termelési kiadás: A korábban tesztelt és jóváhagyott modelleket telepítik

a termelési környezetben a modelles következtetés érdekében, hogy üzleti vagy
működési értéket generáljon. Ezt a termelési kiadást telepítik a termelési
környezetben, amelyet a CI/CD folyamatok engedélyeztek.
Egy korábban tesztelt és (egy minőségbiztosítási szakember által) jóváhagyott
modellt telepítünk API szolgáltatásként egy számítógépre, amelyet a CCTV-hez
kapcsoltak az állatsimogatóban (termelési telepítés). Ez a telepített modell
hajtja végre az ML következtetést a CCTV kamerától érkező videó adatain az
állatsimogatóban, hogy valós időben osztályozza a macskákat és kutyákat.
Monitorozás
A monitorozási modul a telepítési modullal szinkronban működik. A magyarázandó
monitorozás használatával (amelyet később részletezünk a 11. fejezet: Az Ön ML
rendszerének monitorozási alapelvei részben), monitorozhatjuk, elemezhetjük és
irányíthatjuk a telepített ML alkalmazást (ML modell vagy alkalmazás). Először:
monitorozhatjuk az ML modell teljesítményét (előre meghatározott mérések
használatával) és a telepített alkalmazást (a telemetriai adatok használatával). Másodszor:
elemezhetjük a modell teljesítményét egy előre meghatározott megmagyarázhatósági
keretrendszer használatával. Végül: az ML alkalmazás irányítható a riasztások és
műveletek használatával, amelyek a modell minőségbiztosításán és irányításán alapulnak.
Ez egy robosztus monitorozási mechanizmust biztosít a termelési rendszerhez:
1.12 ábra: MLOps, monitorozási folyamat

Nézzük meg részletesen a monitorozási modul egyes lehetőségeit:
• Monitorozás: A monitorozási modul kritikus információkat rögzít az

adatintegritás, modell eltérés és alkalmazásteljesítmény monitorozásához.
Az alkalmazásteljesítmény monitorozható a telemetriai adatok használatával.
Ez leírja egy termelési rendszer eszközteljesítményét egy időszakban. Az olyan
telemetriai adatokkal, mint amilyen egy gyorsulásmérő, giroszkóp, páratartalom-,
mágnestér-, nyomás- és hőmérsékletmérő, ellenőrizhetjük a termelési rendszer
teljesítményét, állapotát és élettartamát.
Valós időben három dolgot fogunk monitorozni: az adatintegritást, modell

eltérést és alkalmazásteljesítményt, a telepített API szolgáltatásnál a simogató
számítógépén. Az olyan mérések, mint a pontosság, F1 pontszám, precízió és
visszahívás az adatintegritás és modell eltérés követésére szolgálnak. Az alkalmazás
teljesítményét a telepített ML modellt futtató termelési rendszer (a helyi számítógép
a simogatóban) telemetriai adatainak követésével monitorozzuk, hogy biztosítsuk
a termelési rendszer helyes működését. A telemetriai adatokat azért monitorozzuk,
hogy előre láthassunk bármilyen anomáliát vagy potenciális hibát és időben
javíthassuk őket. A telemetriai adatok naplózva vannak és felhasználhatók
a termelési rendszer teljesítményének időalapú értékelésérem hogy ellenőrizzük
annak állapotát és élettartamát.
• Elemzés: Kritikus fontosságú, hogy elemezzük a termelési környezetben telepített
ML modellek modellteljesítményét, hogy biztosítsuk az optimális teljesítményt és
irányítást az üzleti döntésekkel vagy hatásokkal összefüggésben. Modellmagyaráz-
hatósági technikákat használunk a modellteljesítmény valós idejű mérésére.
Így értékeljük az olyan fontos jellemzőket, mint a modell korrektsége, bizalma,
elfogultsága, átláthatósága és hibaelemzése azért, hogy javítsuk a modellt a céggel
összefüggésben.
Idővel a célváltozó statisztikai tulajdonságai, amelyeket próbálunk megjósolni, előre
nem látható módon változhatnak. Ezt a változást hívjuk "modell eltérésnek", például
egy olyan esetben, ahol egy ajánló rendszermodellt telepítettünk, amely megfelelő
tárgyakat javasol a felhasználóknak. A felhasználó viselkedése változhat előre nem
látható trendek miatt, amelyeket nem lehet megfigyelni az előzmények adataiban,
amelyeket a modell tanításához használtunk. Kulcsfontosságú, hogy figyelembe
vegyük az ilyen előre nem látható tényezőket, hogy biztosítsuk, hogy a telepített
modellek a legjobb és legrelevánsabb üzleti értéket biztosítsák. Amikor modelleltérés
figyelhető meg, akkor a következő műveletek közül kell valamelyiket végrehajtani:
a) A termék tulajdonosát vagy a minőségbiztosítási szakértőt kell figyelmeztetni.
b) A modellt cserélni vagy frissíteni kell.
c) Aktiválni kell az újratanító folyamatot, hogy újratanítsa és frissítse a modellt
a legújabb adatok vagy igények szerint.
Monitorozzuk a telepített modell teljesítményét a termelési rendszerben
(egy számítógép a CCTV-hez csatlakoztatva az állatsimogatóban). Periodikusan
(naponta egyszer) elemezni fogjuk a modell pontosságát, precizitását és visszahívási
pontjait, hogy biztosítsuk, hogy a modell teljesítménye ne romoljon a küszöbérték
alá. Amikor a modell teljesítménye a küszöbérték alá csökken, elindítjuk a
rendszerirányítási mechanizmusokat (például egy kapcsoló a modell újratanításához).
• Irányítás: A monitorozást és elemzést azért végezzük, hogy irányítsuk a telepített

alkalmazást, hogy a teljesítmény optimális legyen a cégnek (vagy az ML rendszer
céljának). A termelési adatok monitorozása és elemzése után bizonyos riasztásokat
és műveleteket generálhatunk a rendszer irányításához. Például a termék
tulajdonosa vagy a minőségbiztosítási szakértő riasztást kap, amikora modell
teljesítménye csökken (például alacsony pontosság, magas elfogultság stb.)
egy előre meghatározott küszöbérték alá. A termék tulajdonosa aktivál egy
kapcsolót egy alternatív modell újratanításához és telepítéséhez. Végül az irányítás
egy fontos aspektusa a "megfelelés" a helyi és globális törvényeknek és szabályoknak.
A megfelelőséghez a modell magyarázhatósága és átláthatósága kulcsfontosságú.
Ehhez auditálni kell a modellt és jelenteni róla, az end-to-end követhetőség és
magyarázhatóság biztosítása érdekében a termelési modelleknél.
Monitorozzuk és elemezzük a telepített modell teljesítményét a termelési
rendszerben (egy számítógép a CCTV-hez csatlakoztatva az állatsimogatóban).
A telepített modell pontosságának, precizitásának és visszahívási pontjainak
periodikus (naponta egyszer) elemzése alapján riasztásokat generálunk, amikor
a modell teljesítménye az előre meghatározott küszöbérték alá csökken. A simogató
terméktulajdonosa műveleteket generál, és ezek a riasztásokon alapulnak. Például
egy riasztás jön létre, hogy értesítse a termék tulajdonosát, hogy a termelési modell
30%-ban elfogult, és kutyát észlel macska helyett. Ezután a termék tulajdonosa
aktiválja a modell újratanítási folyamatot a modell frissítéséhez a legújabb adatok
felhasználásával, hogy csökkentse az elfogultságot, amely egy robosztus és igazságos
modellt eredményez a termelésben. Így a barcelonai állatsimogatóban lévő ML
rendszer jól irányított, hogy cég igényeit szolgálja.
Ezzel elértünk az MLOps folyamat végére. Az MLOps módszer használatával tanított,
telepített és monitorozott minden modell end-to-end követhető, és az előzményeik
naplózottak, a modell származásának követése érdekében, amely magába foglalja a modell
tanításához használt forráskódot, a modell tanításához és teszteléséhez használt adatokat,
és a modell konvergálásához használt paramétereket. Az összes előzmény hasznos az audit
műveleteknél vagy modell másolásánál, vagy amikor elér egy akadályt, a naplózott ML
modell előzménye hasznos a modell származásának visszakövetéséhez, vagy az akadály
okának megfigyeléséhez és elhárításához. Mivel az ML modellek adatot generálnak
a termelésben a következtetés során, ez az adat hozzákapcsolható a modelltanítás
és -telepítés előzményeihez az end-to-end előzmények biztosításához, és ez fontos
bizonyos megfelelőségi követelményeknél. Következőként megnézzük a kulcsfontosságú
meghajtókat, amelyek engedélyezik az MLOps folyamatot.
Meghajtók
Ezek a kulcsfontosságú meghajtók az MLOps folyamatnál: adat, kód, tárgyak, köztes
szoftverek és infrastruktúra. Nézzük meg az egyes meghajtókat, hogy hogyan engedélyezik
az MLOps folyamatot:
1.13 ábra: MLOps meghajtók

Az MLOps folyamat minden kulcsfontosságú meghajtójának definíciója a következő:
• Adat: Az adatnak több formája lehet, például szöveg, hang, videó és képek.
A hagyományos szoftveres alkalmazásoknál az adat általában strukturált, míg az
ML alkalmazásoknál strukturált vagy strukturálatlan, Az adatok kezeléséhez az
ML alkalmazásoknál az adatok a következő lépésekben kell kezelni: adatszerzés,
adatcímkézés, adatkatalogizálás, adatelőkészítés, adat minőségellenőrzés,
adatmintázás és adatjavítás. Minden lépésnek meg van a maga életciklusa. Ebből
áll az ML alkalmazásokhoz szükséges folyamatok és eszközök teljesen új készlete.
Az ML folyamat hatékony működéséhez az adatokat szét kell választani tanítási,
tesztelési és monitorozási adatokra (a termelésben gyűjtötték, például modell
bemenetek, kimenetek és telemetriai adatok) és el kell látni verzióval. Ezek az
adatműveletek az MLOps folyamat részét képezik.
• Kód: Ez három kulcsfontosságú kódmodul, amelyek az MLOps folyamatot
működtetik: tanítási kód, tesztelési kód és alkalmazáskód. Ezeket a szkripteket vagy
kódokat a CI/CD és adatfolyamatok használatával hajtják végre, hogy biztosítsák
az MLOps folyamat robosztus működését. A forráskódkezelő rendszer (például Git
vagy Mecurial használatával) lehetővé teszi a feldolgozást és jelentős szerepet játszik
az irányításban és a CI, CD és adatfolyamatok zökkenőmentes integrációjában.
A teljes kód fel van osztva és el van látva verzióval a forráskódkezelő beállításban
(például Git).
• Tárgyak: Az MLOps folyamat olyan tárgyakat generál, mint az adatok, szerializált
modellek, kódrészek, rendszernaplók, ML modell tanítása és a tesztelő mérések
információi. Mindezek a tárgyak hasznosak az MLOps folyamat sikeres működése
érdekében, biztosítják annak követhetőségét és fenntarthatóságát. Ezeket
a tárgyakat olyan köztes szoftverszolgáltatások használatával kezeljük, mint amilyen
a modelljegyzék, munkaterületek, naplózó szolgáltatások, forráskódkezelő
szolgáltatások, adatbázisok stb.
• Köztes szoftver: A köztes szoftver olyan számítógépes szoftver, amely olyan

szoftveres alkalmazásokhoz kínál szolgáltatásokat, amelyek többek azoknál, mint
amelyek az operációs rendszerről érhetők el. A köztes szoftverszolgáltatások
biztosítják több alkalmazás számára a folyamatok automatizálását és feldolgozását
az MLOps folyamatnál. A köztes szoftverek és szolgáltatások széles választékát
használhatjuk a felhasználási módtól függően, például a Git-et a forráskódkezeléshez,
a VNets-et a szükséges hálózati konfigurációk engedélyezéséhez, a Docker-t
a modelljeink konténerizálásához és a Kubernetes-t a konténer feldolgozáshoz,
hogy automatizáljuk az alkalmazás telepítését, méretezését és kezelését.
• Infrastruktúra: Az MLOps folymaat sikeres működéséhez lényeges számítási és
tárolási erőforrásokra van szükségünk az ML modellek tanításához, teszteléséhez és
telepítéséhez. A számítási erőforrások teszik lehetővé az ML modelljeink tanítását,
telepítését és monitorozását. Két típusú tároló erőforrás képes kezelni az ML
műveleteket, a központi tároló és a tulajdonságtárak. Egy központi tároló tárolja
a naplókat, tárgyakat, tanítási, tesztelési és monitorozási adatokat. A tulajdonságtár
opcionális és a központi tároló kiegészítője. Kiveszi, átalakítja és tárolja az ML
modell tanításához és következtetéséhez szükséges jellemzőket egy jellemzőfolyamat
használatával. Amikor az infrastruktúráról van szó, számos opció van, például a helyi
erőforrások vagy az infrastruktúraszolgáltatás (IaaS), amely a felhőszolgáltatások.
Napjainkban számos felhőszolgáltató kínál IaaS-t, például az Amazon, Microsoft,
Google, Alibaba stb. Ha a felhasználási módjának megfelelő infrastruktúrája van,
az robosztus, hatékony és takarékos műveleteket tesz lehetővé a csapata és vállalata
számára.
Teljesen automatizált munkafolyamat érhető el az okos optimalizációval és
az MLOps folyamat összes meghajtójának szinergiájával. Az automatizált
MLOps munkafolyamat megvalósításának közvetlen előnyei az IT csapatok
hatékonyságának ugrásszerű növekedése (az adatkutatok és fejlesztők által
eltöltött idő csökken az egyszerű és ismétlődő feladatoknál) és az erőforrások
optimalizációja, amely költségcsökkenést eredményez, és mindkettő nagyszerű
bármelyik cég számára.
Összefoglalás
Ebben a fejezetben megismertük az ML-t működtető infrastruktúra és szoftverfejlesztés
evolúcióját. Elmerültünk az MLOps alapkoncepcióiban, majd megismertünk egy
generikus MLOps munkafolyamatot, amely számos ML megoldásnál megvalósítható több
iparágban.
A következő fejezetben arról fog tanulni, hogy képezzen le bármilyen ML problémát egy
MLOps-on alapuló megoldássá és kezdje el fejleszteni azt egy MLOps munkafolyamat
használatával.
2
Az Ön gépi tanulási
problémájának
jellemzése
Ebben a fejezetben alapvető ismereteket szerez a Gépi tanulás (ML) megoldásainak
különböző fajtáiról, amelyeket a termeléshez készítenek, és megtanulja kategorizálni
a kapcsolódó műveleteket a szervezete üzleti és technológiai igényeivel összhangban.
Megtanulja, hogyan felügyelje az ML megoldások beüzemelésének megvalósítási
ütemtervét, amelyet a szükséges eszközök és infrastruktúra beszerzése követ bármilyen
adott problémánál. A fejezet végére megismeri, hogyan kell robosztus és méretezhető
ML megoldásokat tervezni és beszerezni a megoldások megvalósításához szükséges
eszközöket és adatokat.
Az ML Operations (MLOps) célja, hogy összekösse a tudományos világot az iparral
a legkorszerűbb tervezési elvek felhasználásával, és fel fogjuk deríteni az ipar és
a tudományos világ különböző elemeit, hogy holisztikus képet alkothassunk és tudatában
legyünk a lehetőségeknek. Mielőtt elkezdené kialakítani az MLOps megoldását, fontos, hogy
megértse az elérhető különféle lehetőségeket, összeállításokat, problémákat, megoldásokat
és módszertanokat az üzletorientált problémák megoldásához. Ahhoz, hogy ezeket
megismerje, ebben a fejezetben a következő fő témákat érintjük:
• Az ML megoldás fejlesztési folyamata

• ML modelltípusok
28 Az Ön gépi tanulási problémájának jellemzése
• Az Ön MLOps-jának jellemzése
• Megvalósítási ütemterv az Ön megoldásához
• A szükséges adatok, eszközök és infrastruktúra beszerzése
• Egy valós üzleti probléma ismertetése
Ne húzzuk tovább az időt, ugorjunk neki és fedezzük fel a lehetőségeket, amelyeket az ML

tehet lehetővé, nézzünk az ML megoldásfejlesztési folyamat mélyére, és vizsgáljuk meg az
ML modellek különböző típusait, amelyek üzleti problémákat oldanak meg.
Az ML megoldás fejlesztési folyamata

Az ML számos lehetőséget kínál az üzlet automatizálására és javítására. Ahhoz, hogy
a legjobbat hozzuk ki az ML-ből, az ML-lel működő üzleti átalakításban résztvevő
csapatoknak és embereknek meg kell érteniük mind az ML-t, mint magát az üzletet.
A hatékony üzleti átalakítás az üzlet hozzávetőleges megértésével kezdődik, beleértve
az olyan aspektusokat, mint az értéklánc elemzése, a felhasználási mód azonosítása,
az adatok feltérképezése és az üzleti szimulációk az üzleti átalakítás validálásához.
A 2.1 ábra egy folyamatot mutat be az ML megoldások fejlesztésére az üzleti műveletek
automatizálásához vagy javításához:
2.1 ábra: ML megoldás fejlesztési folyamata

ML modelltípusok 29
Az üzleti felfogás az ML megoldás fejlesztésének eredete. Egy megfelelő üzleti felfogás

megszerzése után továbblépünk az adatelemzésre, ahol a megfelelő adatokat megszerezzük,
ellátjuk verzióval és tároljuk. Az ML modellezése során elfogyasztott adatok adatfolya-
matokat használnak, ahol a funkciótervezés történik a modell tanításához megfelelő
funkciók megszerzése érdekében. Kiértékeljük a betanított modelleket és becsomagoljuk
őket a telepítéshez. A telepítés és monitorozás egy olyan folyamatot használ, amely
kihasználja a Folytonos integráció/Folytonos fejlesztés (CI/CD) funkciókat, ez lehetővé
teszi a valós idejű és folytonos fejlesztést a betanított ML modellek felhasználóknak történő
kiszolgálása érdekében. Ez a folyamat robosztus és méretezhető ML megoldásokat biztosít.
ML modelltípusok
Mivel egy sor ML és mély tanulásos modell van, amely ugyanazt az üzleti problémát
kezeli, kulcsfontosságú megérteni az ML modellek világát ahhoz, hogy egy hatékony
algoritmust válasszunk. Nagyjából 15 típusú ML technika van, ezeket 4 kategóriába lehet
sorolni, nevezetesen a tanulási modellekbe, hibrid modellekbe, statisztikai modellekbe
és az ember a hurokban (HITL) modellekbe, ahogy az a következő táblázatban látható
(ahol minden négyzetrács az egyik kategóriát képviseli) a 2.2 ábrán. Érdemes megjegyezni,
hogy más lehetséges módjai is vannak az ML modellek kategorizálásának, és egyik sem
teljes, így ezek a kategorizálások egyik esetben megfelelőek, míg másik esetben nem.
Itt van az általunk javasolt kategorizálás, amellyel az ML modelleket vizsgáljuk:
2.2 ábra: ML modelltípusok

Tanulási modellek
Először megnézünk kétféle alap tanulási modellt, a felügyelt tanulást és a felügyelet
nélküli tanulást:
2.3 ábra: felügyelt és felügyelet nélküli tanulás
Felügyelt tanulás
A felügyelt tanulási modelleket vagy algoritmusokat címkézett adatok alapján tanítják.
A tanítási adatokban a bemenet eredménye jelölt vagy ismert. Így a modellt arra tanítják
be, hogy megjósolja a kimenetelt, amikor kap egy bemenetet a címkézett adat alapján,
amelyből tanul, és Ön mondja meg a rendszernek, melyik kimenet felel meg egy adott
bemenetnek a rendszerben.
A felügyelt tanulási modellek nagyon hatékonyak a szűk MI eseteiben és a jól
meghatározott feladatoknál, de csak ott használhatók, ahol van elegendő és széleskörű
címkézett adat. Láthatjuk a 2.3 ábrán, hogy a felügyelt tanulás esetében a modell
megtanult osztályozni és jósolni egy bemenetet.
Gondoljon a képosztályozó modell példájára, amelyet a macskák és kutyák képeinek
osztályozására használtunk. Egy felügyelt tanulási modellt tanítottunk be a címkézett
adatokkal, amely több ezer helyesen címkézett macska és kutya képéből állt. A betanított
modell ezután megtanulja osztályozni az adott bemeneti képet, mivel az egy kutyát vagy
macskát tartalmaz.
Felügyelet nélküli tanulás

A felügyelet nélküli tanulásnak semmi köze ahhoz, hogy a gép önállóan fut és emberi
felügyelet nélkül csinál dolgokat. A felügyelet nélküli tanulási modellek vagy algoritmusok
címkézetlen adatokból tanulnak. A felügyelet nélküli tanulás használható ötletek szerzésére
és a címkézetlen adatokban a mintázatok azonosítására. A felügyelet nélküli algoritmusok
széleskörűen használatosak klaszterezéshez vagy az anomáliák észlelésére a címkék segítsége
nélkül. Ezek az algoritmusok lehetnek mintázatkereső algoritmusok; amikor az adatokon
lefuttatnak egy ilyen algoritmust, az azonosítani fogja a mintázatokat és receptet készít
belőlük egy új címkézetlen adatbevitelhez és a helyes címkét fogja rajta alkalmazni.
A felügyelet nélküli tanulást főleg analitikához alkalmazzák, bár használhatja

automatizálására és ML-hez is. Ezeket az algoritmusokat nem ajánlott a termelésben
használni a dinamikus természetük miatt, amely megváltoztatja a kimeneteket minden
tanítási ciklusnál. Azonban hasznosak lehetnek bizonyos folyamatok automatizációjánál,
mint például a bejövő adat szegmentálása vagy az anomáliák valós idejű azonosítása.
Nézzünk meg egy klaszterezési példát az újságcikkek megfelelő csoportokba
sorolására. Tegyük fel, hogy Önnek több ezer címke nélküli újságcikke van, és szeretné
meghatározni a cikkek típusait vagy kategóriáit. Ezen cikkeken a felügyelet nélküli tanulás
végrehajtásához bevihetünk egy köteg cikket az algoritmusba és konvergálhatjuk, hogy
tegye össze a hasonló dolgokat (azaz klaszterezzen) négy csoportba. Aztán megnézzük
a klasztereket, és azt látjuk, hogy a hasonló cikkeket csoportosította olyan kategóriákba,
mint például politika, sport, tudomány és egészség. Ez a mintázatok gyűjtésének egy
módja az adatokban.
Hibrid modellek
Gyors fejlődés történt az ML-nél, mivel kombinálták a hagyományos módszereket, hogy
hibrid modelleket fejlesszenek a változatos üzleti és kutatási problémák megoldásához.
Nézzünk meg néhány hibrid modellt és hogy hogyan működnek. A 2.4 ábra különböző
hibrid modelleket mutat:
2.4 ábra: hibrid modelltípusok
Félig felügyelt tanulás

A félig felügyelt tanulás a felügyelt tanulás egy hibridje, olyan esetekben használják,
amikor csak néhány minta van címkézve és nagy mennyiségű minta nincs címkézve.
A félig felügyelt tanulás lehetővé teszi az elérhető adatok hatékony felhasználását
(bár nincs mind címkézve), beleértve a címkézetlen adatokat. Például a szöveges
dokumentumosztályozó egy tipikus példa a félig felügyelt tanulási programra. Nagyon
nehéz elhelyezni a nagy mennyiségű szöveges dokumentumot ebben az esetben, így a félig
felügyelt tanulás az ideális. Ennek az az oka, hogy nem hatékony csak azért végigolvastatni
egész szöveges dokumentumokat valakivel, hogy besorolja egy alap kategóriába. Ennek
eredményeként a félig felügyelt tanulás lehetővé teszi az algoritmusnak, hogy korlátozott
számú címkézett szöveges dokumentumból tanuljon, miközben osztályozza a tanulási
adatokban lévő nagy mennyiségű címkézetlen szöveges dokumentumokat.
Önellenőrzéses tanulás
Az önellenőrzéses tanulási problémák olyan felügyelet nélküli tanulási problémák,
ahol az adat címkézetlen; ezeket a problémákat lefordítják felügyelt tanulási problémákra
annak érdekében, hogy a felügyelt tanuláshoz használt algoritmusokat használhassák
rajtuk a fenntartható megoldásukhoz. Általában az önellenőrzéses algoritmusokat egy
alternatív feladat megoldására használják, amelyben azért ellenőrzik magukat, hogy
megoldják a problémát vagy egy kimenetet generáljanak. Az önellenőrzéses tanulás egyik
példája a Generative Adversarial Networks (GANs); ezeket általában arra használják,
hogy szintetikus adatokat generáljanak címkézett és/vagy címkézetlen adatokon történő
tanítással. Megfelelő tanítással a GAN modellek képesek egy releváns kimenetet generálni
önellenőrzött módon. Például egy GAN képes legenerálni egy emberi arcot egy bevitt
szöveges leírás alapján, mint például nem: férfi, kor: 30, szín: barna stb.
Több példányos tanulás

A több példányos tanulás egy felügyelt tanulási probléma, amelynél az adatok nem az egyes
adatminták szerint vannak címkézve, hanem összesítve kategóriák vagy osztályok szerint.
A tipikus felügyelt tanulással szemben, ahol minden egyes adatminta címkézve van, például
az újságcikkek olyan kategóriákba vannak sorolva, mint politika, tudomány és sport; a több
példányos tanulásnál a címkézés kategóriánként történik. Az ilyen esetekben az egyes minták
együtt kerülnek címkézésre több osztályban, és a felügyelt tanulási algoritmusok használatával
előrejelzéseket készíthetünk.
Multitask tanulás
A multitask tanulás a felügyelt tanulás egy megtestesülése, amely magába foglalja a
modell tanítását egy adatkészlettel, és ennek a modellnek a felhasználását több feladat
vagy probléma megoldására. Például a természetes nyelv feldolgozásánál szóbeágyazásokat
használunk vagy Bidirectional Encoder Representations from Transformers (BERT)
beágyazó modelleket, amelyet egyetlen nagy adatállománnyal tanítottak be. (a BERT
egy előtanított modell, amelyet nagy szöveges korpusszal tanítottak be. A modell jól érti
egy adott emberi nyelv működését.) Ezek a modellek számos felügyelt tanulási feladat
megoldására felhasználhatók, például szövegosztályozásra, kulcsszavak kinyerésére,
érzelemelemzésre stb.
Megerősítő tanulás
A megerősítő tanulás egy olyan tanulási típus, amelyben egy ágens, például egy
robotrendszer, megtanul egy meghatározott környezetben működni, hogy szekvenciális
döntéshozatali feladatokat hajtson végre vagy elérjen egy előre meghatározott célt. Ezzel
egyidejűleg az ágens a folyamatosan kiértékelt visszajelzés és a környezet jutalmazása alapján
tanul. Mind a visszajelzést, mind a jutalmakat az ágens tanulásának alakítására használják,
ahogy az a 2.5 ábrán látható. Erre egy példa a Google AlphaGo-ja, amely nemrég
felülmúlta a világ vezető Go játékosát. A visszajelzést és jutalmakat használó 40 napos
öntanítás után az AlphaGo képes volt legyőzni a világ legjobb ember Go játékosát:
2.5 ábra: Megerősítő tanulás
Együttes tanulás
Az együttes tanulás egy olyan hibrid modell, amely magába foglal két vagy több, azonos
adatokon tanított modellt. Az előrejelzésekhez az egyes modelleket külön használja és
egy együttes előrejelzést készít az összes kimenet kombinálásának eredményeként és
átlagolja őket, hogy meghatározza a végső kimenetet vagy előrejelzést. Erre egy példa
a véletlenszerű erdő algoritmus, amely egy együttes tanulási módszer az osztályozási vagy
regressziós feladatokhoz. Úgy működik, hogy számos döntési fát képez a tanítás során,
és kimenetként létrehoz egy előrejelzést az összes döntési fa előrejelzéseinek átlagolása
alapján.
Átvitt tanulás
Mi, emberek rendelkezünk egy természetes képességgel, hogy átadjuk a tudást
egymás között. Ezt az elvet fordították le az ML-re, ahol egy modellt úgy tanítanak be,
hogy végrehajtson egy feladatot, és ezt átviszik egy másik modellhez kiindulási pontként
egy másik feladat végrehajtásához szükséges betanításhoz vagy finomhangoláshoz.
Ez a típusú tanulás népszerű a mély tanulásnál, ahol az előtanított modelleket használják
a számítógépes látással vagy természetes nyelv feldolgozásával kapcsolatos problémák
megoldására egy előtanított modell finomhangolása vagy betanítása által. Az előtanított
modellekből történő tanulás hatalmas kezdőlökést ad, mivel nem kell a nulláról tanítani
a modellt, ami nagy mennyiségű tanítási adatot spórol meg. Például betaníthatunk
egy érzelemosztályozó modellt olyan tanítási adat felhasználásával, amely csak néhány
címkézett adatmintát tartalmaz. Ez lehetséges az átvitt tanulással, amely egy előtanított
BERT modellt használ (amelyet egy nagy címkézett adatos korpuszon tanítottak be).
Ez lehetővé teszi a tanítás átvitelét egyik modelltől a másikhoz.
Egyesített tanulás
Az egyesített tanulás az ML végrehajtásának egy kollaboratív módja (szinergia a felhő
és a peremhálózat között). A tanulási folyamat megoszlik több eszköz között, az adatnak
csak egy helyi mintáját tárolja. Nincs adatcsere vagy adatátvitel az eszközök vagy a felhő
között az adatvédelem és -biztonság megőrzése érdekében. Az adatok megosztása
helyett a helyben tanított modelleket osztják meg, hogy tanuljanak egymástól a globális
modellek tanításához. Nézzünk meg egy példát az egyesített tanulásra kórházakban
(ahogy az a 2.6 ábrán látható), ahol a páciensek adatai bizalmasok és nem oszthatók meg
harmadik felekkel. Ebben az esetben az ML tanítása helyben történik a kórházakban
(a peremhálózaton) és globális modelleket központilag tanítják (a felhőben) az adatok
megosztása nélkül. A helyben tanított modelleket úgy finomhangolják, hogy globális
modelleket állítsanak elő. Az adatok központi ML folyamatban történő bevitele helyett,
helyben tanított modelleket visznek be. A globális modellek úgy tanulnak, hogy a helyi
modellekből hangolják a paramétereiket, hogy konvergáljanak az optimális teljesítmény
felé, összefűzik a helyi modellek tanulását:
2.6 ábra: Egyesített tanulási architektúra
Statisztikai modellek
Néhány esetben a statisztikai modellek hatékonyak a döntéshozásban. Fontos tudni, hogy
hol lehet statisztikai modelleket használni a legjobb eredmények vagy döntések eléréséhez.
A statisztikai modelleknek három típusa van: induktív tanulás, deduktív tanulás és
transzduktív tanulás. A 2.7 ábra mutatja a statisztikai modellek típusai közötti kapcsolatot:
2.7 ábra: A statisztikai modellek három típusa közötti kapcsolat

Az induktív tanulás egy olyan statisztikai módszer, amely speciális példákból
általánosít a tanítási adatokban, ezt a bizonyítékot használja a legvalószínűbb kimenetel
meghatározásához. Magába foglalja a példa alapú tanulási folyamatot, ahol egy
rendszer próbál általánosítani egy általános funkciót vagy szabályt egy megfigyelt
példánykészletből. Például amikor egy ML modellt illesztünk az egy indukciós
folyamat. Az ML modell a tanítási adatkészletben lévő konkrét példák általánosítása.
Például a lineáris regresszió használata, amikor a modellt ráillesztik a képzési adatokra,
általánosítja a konkrét példákat a képzési adatokban az Y = a + bX függvény segítségével.
Ilyen általánosítás történik az induktív tanulásnál.
A deduktív tanulás arra utal, amikor általános szabályokat használnak a konkrét
kimenetelek meghatározására. A deduktív tanulás kimenetelei determinisztikusak
és konkrétak, míg az induktív következtetésnél a konklúziók probabilisztikusak vagy
általánosítottak. Bizonyos tekintetben a dedukció az indukció fordítottja. Ha az indukció
konkréttól halad az általános felé, a dedukció az általánostól halad a konkrét felé.
A transzduktív tanulás egy olyan módszer, amely a konkrét tanítási adatminták
(a tanítási adatkészletben) alapján következtet a kimenetelekről. Ez a módszer
különbözik az induktív tanulástól, ahol az előrejelzések általánosítottak a tanítási adat
által. A transzduktív tanulásnál konkrét vagy hasonló adatmintákat hasonlítanak össze
a tanítási adatokból ahhoz, hogy egy kimenetelt kikövetkeztessenek vagy előrejelezzenek.
Például a k-hoz legközelebbi algoritmus esetében ez konkrét adatmintákat használ,
amin a kimenetele alapszik ahelyett, hogy általánosítaná a kimenetelt vagy a tanítási
adatokkal modellezne.
HITL modellek
Kétféle HITL modell van: az emberközpontú megerősítéses tanulás modelljei és az aktív
tanulási modellek. Ezeknél a modelleknél az ember-gép kollaboráció lehetővé teszi az
algoritmus számára, hogy emberszerű viselkedéseket és kimeneteleket utánozzon. A fő
hajtóerő ezeknél az ML megoldásoknál az ember a hurokban (HITL). Emberek validálják,
címkézik és tanítják újra a modelleket, hogy fenntartsák a modell pontosságát:
2.8 ábra: Emberközpontú megerősítéses tanulás munkafolyamata

Az emberközpontú megerősítéses tanulás a megerősítéses tanulás egy hibridje,
mivel embereket von be a hurokba az ágens tanulásának monitorozására és kiértékelő
visszajelzést ad az ágens tanulásának alakításához. Az emberközpontú megerősítéses
tanulást úgy is ismerik, mint interaktív megerősítéses tanulás. Minden alkalommal, amikor
az ágens elvégez valamit, a felügyelő emberi szakértő kiértékelő visszajelzést adhat, amely
leírja az ágens által választott tevékenység minőségét az emberi szakértő tudása alapján,
ahogy az a 2.8 ábrán látható.
Az MLOps-jának szerkesztése 37
A feladatkörnyezettől és emberi szakértőtől kapott visszajelzés alapján az ágens javítja

a viselkedését és tevékenységeit. Az emberi megerősítéses tanulás nagyon hatékony
olyan környezetekben, ahol az ágensnek az emberi viselkedést kell megtanulnia vagy
utánoznia. További információkért olvassa el a következő dokumentumot: Emberközpontú
megerősítéses tanulás: egy felmérés (https://ieeexplore.ieee.org/abstract/
document/8708686).
Az aktív tanulás egy olyan módszer, ahol a tanított modell megkérdezheti a HITL-t
(az emberi felhasználót) a következtetési folyamat során, hogy eloszlassa a kétséget
a tanulási folyamat során. Például ez lehet egy kérdezz-felelek chatbot, amely validálást
kér az emberi felhasználótól eldöntendő kérdésekkel.
Ezek a termelésben kialakítható ML megoldások típusai, amelyek a valóságban
problémákat oldanak meg. Most, hogy megismerte az ML megoldások készítésének
lehetőségeit, a következő lépésként rendkívül fontos, hogy kategorizálja az MLOps-ját az
üzleti és technológiai igényei szerint. Fontos, hogy képes legyen azonosítani a megfelelő
követelményeket, eszközöket, módszertant és infrastruktúrát, amely az üzletének és
MLOps-jának támogatásához szükséges, ezért a következő részben megnézzük az MLOps
szerkesztését.
Az MLOps-jának szerkesztése
Az MLOps elsődleges célja, hogy egy szervezetet vagy az egyének egy csoportját rávegye
a hatékony együttműködésre, hogy olyan adatokat és ML-működtetésű eszközöket
alakítsanak ki, amely megoldja az üzleti problémáikat. Ennek eredményeként nő a teljes
teljesítmény és átláthatóság. A munkavégzés a silókban vagy a funkcionalitások ismétlődő
fejlesztése rendkívül költséges és időrabló lehet.
Ebben a részben megismerjük, az MLOps hogyan szerkeszthető a szervezeteken belül.
Az MLOps folyamat helyes kialakítása elsődleges fontosságú. A MLOps megfelelő
folyamatának és eszközeinek kiválasztásával Ön és a csapata készen állnak egy robosztus,
méretezhető, egyszerű és fenntartható MLOps folyamat megvalósítására. Például nemrég
segítettem az egyik ügyfelemnek az egészségügyben az MLOps-juk kialakításában és
optimalizálásában, amely 76%-os költségoptimalizációt eredményezett (a tárolási és
számítási erőforrásoknál) az előző hagyományos működésükhöz képest.
Az ügyfél adatkutatókból álló csapata azt vette észre, hogy az idejük 30%-a felszabadult
a hétköznapi és ismétlődő napi feladatok miatt (például adattördelés, ML folyamat
és a hiperparaméter hangolása), ez lehet a hatása egy hatékony MLOps folyamat
kialakításának. A hatékony MLOps megvalósításával a csapata biztos lehet
a hatékonyságban, magas teljesítményben és nagyszerű együttműködésben, amely
megismételhető és követhető a szervezetén belül.
Az MLOps csoportosítható kis adatos műveletekre, nagy adatos műveletekre,

nagyléptékű MLOps-ra, és hibrid MLOps-ra (ez az osztályozás a szerző tapasztalatain
alapszik és az MLOps megközelítésének egy ajánlott módja a csapatoknál és
szervezeteknél):
2.9 ábra: MLOps kategóriák

Ahogy a 2.9 ábrán látható, a szervezeteken belüli MLOps nagyjából négy különböző
kategóriába csoportosítható a csapat méretétől, és a műveletek végrehajtásához használt
ML alkalmazásoktól, üzleti modellektől, adatmérettől, eszközöktől és infrastruktúrától
függően. Az adatok tekintetében számos esetben nincs szükség big data (bármi 1 TB felett)
műveletekre, mivel az egyszerű műveletek hatékonyak lehetnek a kis vagy közepes méretű
adatoknál. Az adatméretek közötti különbségek a következők:
• Big data: Olyan mennyiségű adat, amely nem fér el egyetlen tipikus számítógép
memóriájában; például > 1 TB
• Közepes méretű adat: Olyan mennyiségű adat, amely elfér egyetlen szerver
memóriájában; például 10 GB és 1 TB között
• Kis méretű adat: Olyan mennyiségű adat, amely könnyen elfér egy laptop vagy
PC memóriájában; például < 10 GB
Ezeknek a tudatában nézzük meg az MLOps kategóriákat, hogy meghatározzuk

a megfelelő folyamatot és méretet az MLOps megvalósításához az üzleti problémájánál
vagy szervezeténél.
Kis adatos műveletek

Egy adatkutatókból álló csapattal rendelkező kis induló vállalkozás ML modelleket akar
kiépíteni leszűkített és jól meghatározott problémákhoz, amely agilis és nagymértékben
kollaboratív. Az ilyen esetekben általában az ML modelleket helyben tanítják be
a megfelelő adatkutatók számítógépein, aztán megfeledkeznek róluk, vagy kiterjesztik
és telepítik a felhőre a következtetéshez. Ilyenkor lehet néhány általános buktató,
például hogy a csapat nem rendelkezik egy korszerű CI/CD megközelítéssel a modellek
telepítéséhez. Azonban talán megoldották, hogy legyenek központi vagy megosztott
adatforrásaik, amelyeket a csapat gondosan kezel, és a tanítási kódot lehet a központi
adatraktárban verziózni és fenntartani. Amikor a műveletek elkezdenek kibontakozni,
az ilyen csapatok hajlamosak a következőkre:
• Olyan szituációkba futnak bele, amikor a munka nagy részét több ember ismétli,
beleértve az olyan feladatokat, mint az adatok előállítása, az ML folyamatok
ugyanazt a munkát végzik, vagy az ML modellek hasonló típusait tanítják be.
• Silókban dolgoznak és alig értik a csapattársaik által végzett párhuzamos munkát.
Ez kisebb átláthatósághoz vezet.
• Hatalmas költségek vagy a vártnál nagyobb költségek merülnek fel a hétköznapi
és ismételt munka miatt.
• A kód és az adat elkezd önállóan növekedni.
• A tárgyakat nem ellenőrzik és így nem megismételhetők.
Ezek bármelyike költséges és fenntarthatatlan lehet a csapat számára. Ha egy

olyan csapatban dolgozik vagy a következőhöz hasonló körülmények között,
akkor a tevékenységeit a kis adatos műveletek közé sorolhatja be:
• A csapat csak adatkutatókból áll.

• Csak Python környezetekben dolgozik és mindent a Python keretrendszerben
kezel. A Python használata lehet annak az eredménye, hogy számos készenléti
ML könyvtárral és eszközzel rendelkezik a prototípusok és megoldások gyors
kialakításához. Az egyetlen nyelvhez, például Java-hoz tartozó ML könyvtárak
száma sokkal kisebb a Pythonban elérhetőkhöz képest.
• Kevés vagy semmilyen big data feldolgozásra van szükség, mivel az adatkutatók kis
adatot (< 10 GB) használnak.
• A gyors ML modellfejlesztés egy helyi számítógépen kezdődik, aztán kiterjesztik
a felhőre a masszív számítási erőforrások érdekében.
• A támogatási követelmények magasak az olyan nyílt forráskódú technológiáknál,
mint amilyen a PyTorch, TensorFlow, és scikit-learn, bármely ML-típusnál,
a klasszikus tanulástól a mély, felügyelt és felügyelet nélküli tanulásig.
Big data műveletek

Ez lehet egy tapasztalt adatkutatókból és mérnökökből álló csapat egy induló
vállalkozásnál vagy egy SME-nél, ahol nagy méretű big data feldolgozást követelnek
meg tőlük az ML tanulás vagy következtetés végrehajtásához. Olyan big data eszközöket
használnak, mint a Kafka, Spark vagy Hadoop, hogy kialakítsák és irányítsák az
adatfolyamataikat. Olyan nagy teljesítményű processzorokat használnak, mint a GPU-k
vagy TPU-k az ilyen esetekben, hogy felgyorsítsák az adatfeldolgozást és ML tanítását.
Az ML modellek fejlesztését az adatkutatók vezetik, és a modellek telepítését az adat/
szoftvermérnökök irányítják. A modellek fejlesztésére fókuszálnak és kisebb hangsúlyt
fektetnek a modellek monitorozására. A tevékenységeik végrehajtása során az ilyen csapat
a következőkre hajlamos:
• A modell tanítása és monitorozása nem nyomon követhető

• Hiányoznak a reprodukálható tárgyak
• Hatalmas vagy a vártnál nagyobb költségek merülnek fel a hétköznapi és ismételt
munka miatt
• A kód és az adat elkezd önállóan növekedni
Ezek bármelyike költséges és fenntarthatatlan lehet egy csapat számára.

Ha egy olyan csapatban dolgozik vagy a következőkben leírt körülmények között, akkor
a tevékenységeit a big data műveletek közé sorolhatja be:
• A csapat adatkutatókból/mérnökökből áll.

• Nagy az igény a big data feldolgozási kapacitásra.
• A Databricks a fő keretrendszer a megosztásra és együttműködésre a csapatokon
belül és a szervezetek között.
• Az ML modell fejlesztése a felhőben történik a számos ML munkafolyamat-kezelő
eszköz egyikének felhasználásával, mint amilyen a Spark MLlib.
• Alacsonyak a támogatási követelmények az olyan nyílt forráskódú technológiáknál,
mint amilyen a PyTorch és TensorFlow a mély tanuláshoz.
Hibrid MLOps
A hibrid csapatok tapasztalt adatkutatókkal, adatmérnökökkel és DevOps mérnökökkel
működnek, és ezek a csapatok kihasználják az ML lehetőségeit az üzleti tevékenységük
támogatásához. Jóval előrébb járnak az MLOps megvalósításában más csapatokhoz képest.
Big data-val és olyan nyílt forráskódú szoftveres eszközökkel dolgoznak, mint amilyen
a PyTorch, TensorFlow, és scikit-learn, és így megkövetelik a hatékony együttműködést.
Gyakran jól meghatározott problémákon dolgoznak a robosztus és méretezhető
szoftvertechnológiai gyakorlatok megvalósításával. Azonban ez a csapat is érzékeny
az olyan kihívásokra, mint a következők:
• Hatalmas, vagy a vártnál nagyobb költségek merülnek fel amiatt, hogy az

adatkutatók végzik a hétköznapi és ismétlődő munkát, mint például az ismétlődő
adattisztítás és funkciótechnika.
• Nem hatékony a modellek monitorozása és az újratanítási mechanizmusok.
Ezek bármelyike költséges és fenntarthatatlan lehet a csapat számára.

Ha egy olyan csapatban dolgozik vagy a következőkben leírt körülmények között,
akkor a tevékenységeit a hibrid műveletek közé sorolhatja be:
• A csapat adatkutatókból, adatmérnökökből és DevOps mérnökökből áll.

• Nagyon megkövetelik a hatékony és hatásos együttműködést.
• Nagy az igény a big data feldolgozási kapacitásra.
• A támogatási követelmények magasak az olyan nyílt forráskódú technológiáknál,
mint amilyen a PyTorch, TensorFlow, és scikit-learn, bármely ML-típusnál,
a klasszikus tanulástól a mély tanulásig, és felügyelttől a felügyelet nélküli tanulásig.
Nagy léptékű MLOps

A nagy léptékű műveletek gyakoriak az olyan nagy cégeknél, amelyek nagy vagy közepes
méretű, adatkutatókból, adatmérnökökből és DevOps mérnökökből álló csapatokkal
rendelkeznek. Big data léptékű adatműveleteik vannak, vagy változatos adattípusokkal
foglalkoznak változó méretben, pontosságban és sebességben. Általában a csapataik több
hagyományos rendszerrel rendelkeznek, hogy kezeljék, támogassák az üzleti műveleteiket.
Az ilyen csapatok vagy szervezetek hajlamosak a következőkre:
• Hatalmas vagy a vártnál nagyobb költségek merülnek fel a hétköznapi és ismételt

munka miatt.
• A kód és az adat elkezd önállóan növekedni.
• Bürokratikus és nagyon szabályozott folyamataik és minőségellenőrzéseik vannak.

• Nagyon szövevényes rendszerek és folyamatok, ha egy dolog elromlik, minden
elromlik.
Ezek bármelyike költséges és fenntarthatatlan lehet a csapat számára.

Ha egy olyan csapatban dolgozik vagy a következőkben leírt körülmények között,
akkor a tevékenységeit a nagy léptékű műveletek közé sorolhatja be:
• A csapat adatkutatókból, adatmérnökökből és DevOps mérnökökből áll.

• Nagy léptékű következtetés és műveletek.
• Big data műveletek.
• Az ML modell kezelése több erőforráson történik.
• Nagy vagy több csapat.
• Több felhasználási eset és modell.
Miután jellemezte az MLOps-ját az üzleti és technológiai igényei szerint, egy alapos

megvalósítási ütemterv biztosítja a robosztus és méretezhető MLOps megoldás
zökkenőmentes fejlesztését és megvalósítását a szervezete számára. Például egy olyan
pénzügyi technológiai induló vállalkozásnak, amely 0-1000 tranzakciót dolgoz fel
naponta, egy kis léptékű adatműveletre lenne szüksége, szemben egy nagyobb pénzügyi
intézettel, amelynek nagy léptékű MLOps-ra van szüksége. Az ilyen csoportosítás lehetővé
teszi egy csapatnak vagy szervezetnek, hogy hatékonyabb és robosztusabb legyen.
Megvalósítási ütemterv az Ön megoldásához

Ha van egy jól meghatározott módszere és mérföldkövei, az biztosítja a kívánt ML
megoldás sikeres elkészítését (az MLOps módszerek felhasználásával). Ebben a részben
megnézünk részletesen egy generikus megvalósítási ütemtervet, amely képes kezelni az
MLOps-t bármilyen ML problémánál. Az ütemterv célja, hogy a megfelelő megoldással
oldja meg a problémát:
Megvalósítási ütemterv az Ön megoldásához 43
2.10 ábra: Megvalósítási ütemterv egy MLOps-alapú megoldáshoz

Az előző ütemterv felhasználásával átmenetet képezhetünk az ML fejlesztése és az MLOps
között az egyértelmű mérföldkövekkel, ahogy az ennél a három fázisnál látható az MLOps
megvalósításánál. Most nézzük meg részletesen az ütemterv ezen három fázisát. Érdemes
megjegyezni, hogy a következő elméleti rész után rátérünk az ütemterv gyakorlati
megvalósítására és egy valós üzleti felhasználási módon fogunk dolgozni.
1. fázis: ML fejlesztés
Az Ön problémájánál az MLOps keretrendszer megvalósításának ez a kezdete;
a követelmények teljesítésének megkezdése előtt a problémának és a megoldásnak
egyértelműnek és életszerűnek kell lennie. Ebben a fázisban figyelembe vesszük
a robosztus és méretezhető MLOps keretrendszer tervezéséhez és megvalósításához
szükséges rendszerkövetelményeket. Azzal kezdjük, hogy kiválasztjuk a megfelelő
eszközöket és infrastruktúrát (tárolás, számítás stb.), amely az MLOps megvalósításához
szükséges.
Amikor felállítottuk az infrastruktúrát, el kell látnunk a szükséges munkaterülettel és
a fejlesztési és tesztkörnyezetekkel az ML kísérletek (tanítás és tesztelés) végrehajtásához.
A fejlesztési környezet használatával tanítjuk az ML modelljeinket, és a tesztadatok
felhasználásával a fejlesztési vagy tesztkörnyezetekben teszteljük a modellek teljesítményét
és működését a munkafolyamattól vagy követelménytől függően. Amikor az infrastruktúrát
felállítottuk, és betanítottuk, teszteltük, szerializáltuk és becsomagoltuk az első ML
modellt, akkor kész van az MLOps keretrendszer 1. fázisa és validáltuk a robosztusságát.
A szerializálás és konténerizálás fontos folyamat a szabványosításhoz, és hogy felkészítsük
a modelleket a telepítésre.
Most rátérünk a 2. fázis megvalósítására.
2. fázis: Átvitel a műveletekhez

A 2. fázis a műveletekhez történő átvitelről szól, és magába foglalja az 1. fázisban betanított
modellek szerializálását és konténerizlását, és a felkészítésüket a telepítésre. Ez lehetővé
teszi a szabványosítást, hatékony telepítést. A modelleket API-k vagy független tárgyak
formájában nyújtják a tömeges következtetéshez. Amikor egy modellt becsomagoltak
és készen áll az átadásra, akkor korszerű CI/CD folyamatok felhasználásával telepítik
a termelési környezetben, miután átment a minőségbiztosítási ellenőrzéseken. A 2.
fázis végére becsomagolt modellekkel fog rendelkezni, amelyeket átadtak és telepítettek
a termelési környezetben a valós idejű következtetés végrehajtására.
3. fázis: Műveletek
A 3. fázis a fő műveletek fázisa a 2. fázisban telepített modelleknél. Ebben a fázisban
a telepített modell teljesítményét monitorozzuk a modell eltérése, elfogultsága vagy
más mérések alap (a következő fejezetekben fogunk elmélyedni ezekben a feltételekben
és mérésekben). A modell teljesítménye alapján engedélyezhetjük a folytonos tanulást
a periodikus modell újratanításán keresztül és engedélyezhetjük a riasztásokat és
tevékenységeket. Ezzel egyidőben monitorozzuk a naplókat a telemetriai adatokban
a termelési környezetnél, hogy észleljünk minden lehetséges hibát, és azonnal megoldjuk
őket, hogy biztosítsuk a termelési rendszer megszakítatlan működését. Egyúttal
kezeljük az adatfolyamatokat, az ML platformot és biztonságot is. Ezen fázis sikeres
megvalósításával monitorozhatjuk a telepített modelleket és robosztus, méretezhető
és biztonságos módon taníthatjuk újra őket.
A legtöbb esetben mind a három fázist meg kell valósítani az ML megoldásához,
de néhány esetben elég az 1. és 2. fázis; például amikor az ML modellek tömeges
következtetéseket készítenek és nem kell valós időben következtetniük. Ezen mérföldkövek
elérésével és a három fázis megvalósításával egy robosztus és méretezhető ML életciklust
állítottunk fel szisztematikusan és fenntarthatóan az alkalmazásainkhoz.
Adatok, követelmények és eszközök

beszerzése
Az MLOps sikeres megvalósítása olyan tényezőktől függ, mint például a megfelelő
tanítási adatok beszerzése, illetve a magas normák, megfelelő követelmények, eszközök
és infrastruktúra birtoklása.
Ebben a részben elmélyedünk ezekben a tényezőkben, amelyek robosztussá
és méretezhetővé teszik az MLOps-t.
Adatok, követelmények és eszközök beszerzése 45
Adatok
Korábban azt hittem, hogy az adatokról tanulni az olyan eszközök használatának
elsajátítását jelenti, mint például a Python, SQL és regression. Az eszköz csak olyan jó,
amennyire a személy, és amennyire az a kontextust érti körülötte. A kontextus és
a tartomány számít az adattisztítástól a modellezésen át az értelmezésig. A világ legjobb
eszközei sem javítanak meg egy rossz problémameghatározást (vagy annak hiányát).
Annak ismerete, hogy mely problémát kell megoldani, nagyon kontextusvezérelt és
üzletfüggő döntés. Ha tudatában van a problémának és kontextusnak, az lehetővé
teszi, hogy felismerje a megfelelő tanítási adatokat, amelyek a probléma megoldásához
szükségesek.
A tanítási adat létfontosságú része az ML rendszereknek. Kulcsszerepet játszik az ML
rendszerek fejlesztésében a hagyományos szoftverrendszerekkel szemben. Ahogy az
előző fejezetben láttuk, mind a kód, mind a tanítási adatok párhuzamosan dolgoznak
egy ML rendszer fejlesztésével és fenntartásával. Ez nem csak az algoritmusról, hanem
az adatokról is szól. Két szempont biztosítja, hogy a megfelelő adatokkal rendelkezzen
az algoritmus tanításához, ezek a megfelelő mennyiségű és minőségő adatok biztosítása:
• Adatmennyiség: Az adatkutatók egy gyakori érvet ismételgetnek a modelljeiknél,

hogy a modell teljesítménye azért nem jó, mert nem kaptak elegendő mennyiségű
adatot a jó modellteljesítmény előállításához. Ha több adatuk lett volna,
a teljesítmény bizonyára jobb lenne; ismeri az ilyen érveket? A legtöbb esetben
a több adat nem igazán segítene, mivel a minőség is egy fontos tényező. Például
a modelljei több ötletet és jellemzőt tanulhatnak az adataiból, ha több mintája
van minden csoporthoz. Például ha szabálytalan pénzügyi tranzakciókat elemez
sok mintával az adatai között, akkor többféle szabálytalan tranzakciót fog találni.
Ha csak egyetlen szabálytalan eset van benne, akkor az ML nem hasznos.
Az ML projektek adatkövetelményeinek nem szabad pusztán az adat mennyiségére
koncentrálnia, hanem a minőségre is figyelnie kell, ami azt jelenti, hogy fókusznak
nem az adatminták számán kell lennie, hanem inkább az adatminták sokféleségén.
Azonban néhány esetben korlátozva van a probléma megoldásához rendelkezésre
álló adatmennyiség. Például tételezzük fel, hogy olyan modelleken dolgozunk,
amelyek előjelzik az ügyfélforgási sebességet egy biztosító vállalatnak. Ebben az
esetben korlátozva lehetünk, hogy csak egy korlátozott időszak adatait vehetjük
figyelembe, vagy korlátozott számú mintát használhatunk, mivel ennyi adat érhető
el egy bizonyos időszakhoz; például 5 év (miközben a biztosító vállalat lehet, hogy
50 éve működik). A cél a lehetséges maximális mennyiségű és minőségű adat
megszerzése a legjobb teljesítményű ML modellek tanításához.
• Adatminőség: Az adatminőség egy fontos tényező az ML modellek tanításakor;

hatással van a modell teljesítményére. Minél átfogóbb vagy jobb az adat minősége,
annál jobban fog működni az ML modell vagy alkalmazás. Így fontos a tanítás
előtti folyamat: az adatok tisztítása, javítása és méretezése. Az adatminőségnek
van néhány fontos szempontja, amelyeket figyelembe kell venni, például
a következetesség, korrektség és teljesség.
Az adat következetessége az adatminták összefüggésére és hasonlóságára utal
az adatkészleten belül. Az adat korrektsége a pontosság foka, és hogy milyen
mértékben támaszkodhat arra, hogy az adat valóban tükrözi az eseményeket.
Az adatkorrektség függ attól, hogyan gyűjtötték az adatokat. Az adat elszórtsága
az egyes jellemzőknél (például, hogy az adat lefedi-e a lehetséges értékek átfogó
tartományát egy esemény tükrözéséhez) az adat teljességét tükrözi.
Megfelelő mennyiségű, jó minőségű adattal biztos lehet benne, hogy az ML
modelljei és alkalmazásai a megkívánt normák felett fognak teljesíteni. Így a jó
normák megléte kulcsfontosságú, hogy az alkalmazás a leghatékonyabb módon
teljesítsen és oldja meg az üzleti problémákat.
Követelmények
A termék vagy üzleti/technológiai probléma tulajdonosa kulcsfontosságú szerepet
játszik a robosztus ML rendszer hatékony kialakításának irányításában azáltal, hogy
meghatározza a követelményeket és az adatok méretére, gyűjteményére és a szükséges
adatformátumokra tekintettel alakítja őket. Ezek a követelmények fontos bemenetek az
ML rendszerek fejlesztőinek, mint amilyenek az adatkutatók vagy ML mérnökök, hogy
elkezdhessék megtervezni a megoldást a probléma kezelésére a követelményeken alapuló
megadott adatkészlet elemzése és korrelálása által. Az ML megoldás követelményeinek
átfogó adatkövetelményekből kell állnia. Az adatkövetelmények specifikációi az
adatok minőségéről és mennyiségéről szóló információkból állnak. A követelmények
lehetnek extenzívebbek; például tartalmazhatnak becsléseket az elvárt vagy előre jelzett
teljesítményről a teljesítmény mérőszámainak képében, amelyeket a követelmények
elemzése és közzététele során határoztak meg.
Eszközök és infrastruktúra 47
Készíthetők aprólékos specifikációk, mint például az elvárt specifikációk vagy a tanítási

adatok előrejelzett teljesítménye, mivel ezek gyorsan validálhatók a modell tanítási
folyamata után. Noha a tanulási teljesítmény alapján a következtetés vagy futásidejű
(beleértve a termelésben és műveletekben töltött időt) teljesítmény megbecsülhető
az üzemeltetés során. A termék tulajdonosa vagy az üzlet tulajdonosa által készített
követelményeknek figyelembe kell vennie az olyan fontos tényezőket, mint az etikai és
magyarázhatósági tényezők. A diszkrimináció vagy elfogultság (például kit vagy mit
jeleztek előre vagy osztályoztak) kritikus az alkalmazásnál, és hogy mely jellemzőket kell
megőrizni az adatvédelem részeként (például néhány jellemzőt nem szabad felhasználni
az előrejelzésekhez vagy osztályozáshoz, ilyenek a faj, kor vagy nem). A magyarázhatósági
követelményeket egyértelműen figyelembe kell venni az ML megoldás vagy rendszer
döntéseinek és szituációinak magyarázása során a rendszer felhasználói felé. Végül
a követelményeknek szabályozásokat és korlátozásokat kell megállapítaniuk az ML
rendszer által hozott döntések validációja és az adatok felhasználása kapcsán. A következő
táblázat néhány követelményt mutat, amelyeket érdemes figyelembe venni annak
biztosítása érdekében, hogy egy robosztus és méretezhető ML megoldást alakítson ki:
2.11 ábra: Követelmények az ML megoldások leképzéséhez

A 2.11 ábra táblázata a követelmények kialakítási folyamatát ábrázolja a közzétételtől
az elemzésen és specifikációkon át a rendszer ellenőrzéséig és validálásáig. Ez a folyamat
biztosítja a legjobban illeszkedő erőforrások beszerzését az Ön problémáját megoldó
hatékony ML rendszer kialakításához és telepítéséhez. Ha a követelményeket rendesen
meghatározták, a megfelelő eszközök és infrastruktúra kiválasztása kritikus fontosságú,
amely támogatja a felállított folyamatot és biztosítja a normák teljesülését.
Eszközök és infrastruktúra
Az MLOps területe gyorsan fejlődött az elmúlt két évben; számos eszköz és
keretrendszer továbbfejlődött az infrastruktúrakínálat részeként. Meglátogathatja
a https://landscape.lfai.foundation/ oldalt, hogy lássa milyen sok
mainstream lehetőséget fejlesztettek, hogy kezelni tudja az ML-t, mély tanulást,
megerősítő tanulást, fejlesztési környezeteket, adatfolyamatokat, modellkezelést,
magyarázandó MI-t, biztonságot és megosztott számítást.
Fellendültek az olyan szolgáltatások, amelyet a népszerű felhőszolgáltatók kínálnak,

például a Microsoft, AWS, és Google, amelyeket olyan adatfeldolgozó eszközök
egészítenek ki, mint az Airflow, Databricks, és Data Lake. Ezeket azért készítették,
hogy lehetővé tegyék az ML-t és mély tanulást, amelyekhez nagyszerű keretrendszerek
érhetők el, mint például többek között a scikit-learn, Spark MLlib, PyTorch, TensorFlow,
MXNet, és CNTK. Számos eszköz és keretrendszer van, de a megfelelő eszköz beszerzése
választás kérdése és számít az ML megoldásának kontextusa illetve a működési
környezet. A megfelelő eszközök használata biztosítja az MLOps munkafolyamatának
automatizációját és hatékonyságát. Számos opció van, a határ a csillagos ég, de valahonnan
el kell indulnunk, hogy elérjük az eget. Emiatt ezután megpróbálunk néhány hasznos
tapasztalatot átadni. Mindig jobb valós problémákból tanulni, és mi is így fogunk tenni
azzal, hogy a következő részben leírt valós üzleti problémát használjuk.
Egy valós üzleti probléma megvitatása

A következő üzleti problémát fogjuk megvalósítani, hogy hasznos tapasztalatot
szerezzünk. Azt ajánlom, olvassa el többször ezt a részt, hogy jól megértse az üzleti
problémát; így könnyebb lesz megvalósítani.
Fontos megjegyzés
A probléma kontextusa:
Adatkutatóként dolgozik egy kis csapatban, három másik adatkutatóval együtt,
egy teherszállító cégnek, amelynek a székhelye a finnországi Turku kikötőben
van. A Finnországba importált termékek 90%-a teherhajókon érkezik országszerte
a kikötőkbe. A teherhajózáshoz az időjárási körülmények és a logisztika időnként
kihívást jelenthet a kikötőknél. Az esős idő hátráltathatja a kikötői logisztikát
és műveleteket, amely hatással lehet az ellátási lánc műveleteire. Az esős idő
előrejelzése lehetőséget ad rá, hogy optimalizálják az olyan erőforrásokat,
mint a humánerőforrás, logisztika és szállítási erőforrások a kikötői ellátási
lánc hatékony műveletei érdekében. Üzleti szempontból az esős idő előrejelzése
lehetőséget ad a kikötőknek, hogy akár ~20%-kal csökkentsék a működési
költségeiket a humánerőforrás, logisztika és szállítási erőforrások hatékony
tervezése és beosztása által a kikötői ellátási lánc műveleteinek esetében.
Feladat:
Adatkutatóként azt a feladatot kapta, hogy fejlesszen egy ML-alapú megoldást
az időjárási körülmények 4 órás előrejelzésére a finnországi Turku kikötőben.
Ez lehetővé teszi a kikötőnek, hogy optimalizálja az erőforrásait, amely akár
20%-os költségmegtakarítást tesz lehetővé. A kezdéshez megkapta az elmúlt
10 év időjárásának adatkészletét Turku kikötőben (az adatkészlet a következő
fejezetben található). A feladata, hogy egy folytonos tanuláson alapuló ML
megoldást alakítson ki a Turku kikötőbeli műveletek optimalizálására.
Összefoglalás 49
A probléma megoldásához a Microsoft Azure-t fogjuk használni, amely az egyik

legszéleskörűbben használt felhőszolgáltatás, és az MLflow-t, egy nyílt forráskódú
ML fejlesztő eszközt, hogy gyakorolhassuk az erőforrások felhasználását. Így megtanulunk
a felhőben és egy nyílt forráskódú szoftverrel dolgozni. Mielőtt elkezdenénk a gyakorlatias
megvalósítást a következő fejezetben, kérem, feltétlenül tegye meg a következőket:
1. Hozzon létre egy ingyenes Azure előfizetést a következő oldalon:

https://azure.microsoft.com/ (5 percet vesz igénybe).
2. Hozzon létre egy Azure Machine Learning alkalmazásszolgáltatást MLOps_WS
néven. Ez az Azure portálján tehető meg, ha rákattint az Erőforrás létrehozás
lehetőségre. Aztán gépelje be a keresési mezőbe, hogy Machine Learning és
válassza ki a Machine Learning opciót. Aztán kövesse a részletes utasításokat
a következő fejezetben (3. fejezet: A kód találkozik az adattal), hogy létrehozza
az Azure Machine Learning szolgáltatás erőforrást MLOps_WS néven.
Ezzel teljesen készen áll rá, hogy megvalósítson egy MLOps keretrendszert az előző üzleti
problémára.
Összefoglalás
Ebben a fejezetben megismertük az ML megoldás fejlesztési folyamatát, hogy hogyan kell
meghatározni a megfelelő ML megoldást egy problémához, és hogyan kell kategorizálni
a műveleteket a megfelelő MLOps megvalósításához. Vetettünk egy futó pillantást egy
generikus megvalósítási ütemtervre és láttunk néhány tippet a legfontosabb dolgok
beszerzésére, mint amilyenek az eszközök, adatok és infrastruktúra az ML alkalmazásának
megvalósításához. Végül átvettük a következő fejezetben egy MLOps munkafolyamat
(megvitattuk az 1. fejezet: MLOps WorkFlow alapjai részben) megvalósításával
megoldandó üzleti problémát, ahol gyakorlatias tapasztalatokat fogunk szerezni az
MLOps-ról.
A következő fejezetben rátérünk az elméletről a gyakorlati megvalósításra. A fejezet
gyakorlatias lesz, amikor elkezdjük felállítani az MLOps eszközöket az Azure-on
és elkezdjük a kódolást az adatok tisztításához, hogy megoldjuk az üzleti problémát
és rengeteg gyakorlati tapasztalatot szerezzünk.
3
A kód találkozik
az adattal
Ebben a fejezetben elkezdjük az MLOps gyakorlatias megvalósítását, mivel megtanulunk
megoldani egy üzleti problémát az előző fejezetben megvitatott MLOps munkafolyamat
használatával. Megbeszéljük a forráskódkezelés hatékony módszereit is a gépi tanuláshoz
(ML), felderítjük az adatminőség jellemzőit, valamint elemezzük és formáljuk az adatokat
egy ML megoldáshoz.
Azzal kezdjük ezt a fejezetet, hogy kategorizáljuk az üzleti problémát kiválasszuk
a leginkább hozzáillő MLOps megoldást. Ezt követően felállítjuk a szükséges erőforrásokat
és eszközöket a megoldás megvalósításához. Megvitatjuk az ML forráskód-kezelésének
10 vezérelvét, hogy alkalmazzuk a tiszta kód gyakorlatokat. Megvitatjuk, miből áll
a jó minőségű adat az ML-nél és még egyebeket, amelyet az üzleti problémához
kapcsolódó adatkészlet feldolgozása követ, illetve beolvassuk és ellátjuk verzióval az ML
munkaterületen. A fejezet nagy része gyakorlatias és úgy készült, hogy megismertesse Önt
az MLOps-szal. Ehhez ebben a fejezetben a következő fő témákat érintjük:
• Az üzleti probléma elemzése és a probléma kategorizálása

• Az erőforrások és eszközök beállítása
• a forráskódkezelés 10 alapelve a gépi tanulásnál
• Jó adatok a gépi tanuláshoz
• Adat előfeldolgozás
• Adatok regisztrációja és ellátása verzióval
• Egy ML folyamat irányába
52 A kód találkozik az adattal
Ugorjunk is neki késedelem nélkül, hogy demisztifikáljuk az üzleti problémát és valósítsuk

meg a megoldást egy MLOps megközelítés használatával.
Az üzleti probléma elemzése és a probléma

kategorizálása
Az előző fejezetben megnéztük a következő üzleti probléma felvetését. Ebben a részben
demisztifikáljuk a problémafelvetést azzal, hogy kategorizáljuk a vezérelvek használatával,
hogy felügyeljük a megvalósítási ütemtervet. Megtekintjük az adatkészletet, amit kaptunk
az üzleti probléma kezelésére, és eldöntjük, milyen ML modelltípus fogja hatékonyan
kezelni az üzleti problémát. Végül kategorizáljuk az MLOps megközelítést a robosztus
és méretezhető ML műveletek megvalósításához és kiválasztjuk hozzá az eszközöket.
Itt van a problémafelvetés:

Adatkutatóként dolgozik egy kis, adatkutatókból álló csapattal, egy teherszállító
cégnek, amelynek a székhelye a Finnországban van. A Finnországba importált
termékek 90%-a teherhajókon érkezik. Azzal bízták meg, hogy takarítson meg
20% költséget a teherszállítási műveleteknél a finnországi Turku kikötőben.
Ez egy ML megoldás kifejlesztésével érhető el, amely 4 órával előre jelzi az
időjárási körülményeket a kikötőben. Monitoroznia kell a lehetséges esős
időt, amely felboríthatja a kikötői műveleteket a humánerőforrás és szállítás
tekintetében, amely így hatással van a kikötői ellátási lánc műveleteire.
Az ML megoldása segíteni fog a kikötő hatóságainak, hogy 4 órával korábban
megjósolják a lehetséges esőt; ez a költségek 20%-át takarítja meg, és lehetővé
teszi a zökkenőmentes ellátási lánc műveleteket a kikötőben.
Egy probléma megoldásának az első lépése, hogy egyszerűsítjük és kategorizáljuk

az egy megfelelő megközelítés használatával. Az előző a fejezetben megvitattuk,
hogyan kell kategorizálni egy üzleti problémát ahhoz, hogy ML használatával oldjuk
meg. Alkalmazzuk azokat az elveket, hogy rajzoljunk egy egyértelmű ütemtervet
a megvalósítására.
Először megnézzük, milyen modelltípust tanítsunk be a maximális üzleti érték érdekében.
Másodszor azonosítjuk a megfelelő megközelítést az MLOps-unk megvalósításához.
A tanítandó modell típusának eldöntéséhez kezdhetünk azzal, hogy vetünk egy pillantást
a GitHubon elérhető adatkészletre: https://github.com/PacktPublishing/
EngineeringMLOps.
Itt van egy kép a weather_dataset_raw.csv adatkészletről a 3.1 ábrán. A fájlméret
10,7 MB, a sorok száma 96453, és fájl CSV formátumban van:
Az üzleti probléma elemzése és a probléma kategorizálása 53
3.1 ábra: Kép az adatkészletről

Az adat értékelésével a következőképpen kategorizálhatjuk az üzleti problémát:
• Modelltípus: A működési költségek 20%-os megtakarításához Turku kikötőben

egy felügyelt tanulási modellre van szükség, hogy osztályozással megjósolja, fog-e
esni vagy sem. Az adat címkézett és a Weather condition (időjárási
körülmény) oszlopa leírja, hogy rögzítettek-e eső, hó vagy tiszta időjárási
körülményt eseményként. Ez alakítható és újracímkézhető, mint eső vagy nem
eső és felhasználható a bináris osztályozás végrehajtásához. Így egyértelmű,
hogy az üzleti problémát egy felügyelt tanulási megközelítéssel kell megoldani.
• MLOps megközelítés: A problémafelvetés és adatok megvizsgálás után itt vannak
a tények:
(a) Adat: A tanítási adat 10,7 MB. Az adatméret meglehetősen kicsi
(nem tekinthető big data-nak).
(b) Műveletek: Egy ML modellt kell tanítanunk, tesztelnünk, telepítenünk és
monitoroznunk az időjárás óránkénti (4 órával előre) előrejelzésére Turku
kikötőben, amikor új adatot rögzítenek.
(c) Csapatméret: Egy adatkutatókból álló kis/közepes csapat, nincsenek DevOps
mérnökök.
Az előző tények alapján a műveleteket bekategorizálhatjuk kis csapatos műveletnek; nincs
szükség big data feldolgozására és a csapat kicsi és agilis. Most megnézünk néhány megfelelő
eszközt a műveletek megvalósítására, amelyekre az üzleti probléma megoldásához van szükség.
Ahhoz, hogy holisztikusan ismerjük meg az MLOps megvalósítását, az üzleti problémát
két különböző eszközzel fogjuk egyszerre megoldani:
• Azure Machine Learning (Microsoft Azure)

• MLflow (egy nyílt forráskódú felhő és platform-agnosztikus eszköz)
Ezt a két eszközt használjuk ahhoz, hogy lássuk, hogyan működnek a dolgok egy tisztán
felhőalapú megközelítésnél és egy nyílt forráskódú/felhő-agnosztikus megközelítésnél.
A teljes kódot és a CI/CD műveleteket az Azure DevOps használatával fogjuk irányítani
és kezelni, ahogy az a 3.2 ábrán látható:
3.2 ábra: MLOps eszközök a megoldáshoz

Most felállítjuk a szükséges erőforrásokat és eszközöket az üzleti problémánál a megoldás
megvalósításához. Mivel Pythont fogunk használni elsődleges programozási nyelvként,
előfeltétel a Python 3 telepítése a Mac, Linux vagy Windows operációs rendszerünkre.
Az erőforrások és eszközök beállítása

Ha már telepítette ezeket az eszközöket és beállította őket a PC-jén, akkor nyugodtan
hagyja ki ezt a részt; másképp kövesse a részletes utasításokat a beállításuk és futtatásuk
érdekében.
Az MLflow telepítése
Az MLflow telepítésével kezdünk, amely egy nyílt forráskódú platform az ML életciklus
kezeléséhez, beleértve a kísérletezést, reprodukálhatóságot, telepítést és egy központi
modelljegyzéket.
Az MLflow telepítéséhez menjen a terminálhoz és hajtsa végre a következő parancsot:
pip3 install mlflow

Az erőforrások és eszközök beállítása 55
A sikeres telepítés után tesztelje a telepítést úgy, hogy végrehajtja a következő parancsot és
elindítja az mlflow követő UI-t:
mlflow ui
Az mlflow követő UI futásakor egy szerver fog futni, amely az 5000-es porton válaszol
a számítógépén, és egy olyan üzenetet ír ki, mint a következő:
[2021-03-11 14:34:23 +0200] [43819] [INFO] Starting gunicorn

20.0.4
[2021-03-11 14:34:23 +0200] [43819] [INFO] Listening at:
http://127.0.0.1:5000 (43819)
[2021-03-11 14:34:23 +0200] [43819] [INFO] Using worker: sync
[2021-03-11 14:34:23 +0200] [43821] [INFO] Booting worker with
pid: 43821
Hozzáférhet és megtekintheti az mlflow UI-t a http://localhost:5000 helyen.

Amikor sikeresen telepítette az mlflow-t és fut a követő UI, akkor készen áll a
következő eszköz telepítésére.
Azure Machine Learning

Az Azure Machine Learning egy felhőalapú ML platformot biztosít az ML modellek
tanításához, telepítéséhez és kezeléséhez. Ez a szolgáltatás a Microsoft Azure-on érhető el,
így előkövetelmény, hogy legyen egy ingyenes Microsoft Azure előfizetése. Kérjük, hozzon
létre egy ingyenes fiókot nagyjából 170 $ jóváírással, amely elegendő lesz a megoldás
megvalósításához, itt: https://azure.microsoft.com/.
Amikor van hozzáférése egy Azure előfizetéshez, lépjen a következő részre, hogy beállítsa
és futtassa az Azure Machine Learning-et.
Egy erőforráscsoport létrehozása

Az erőforráscsoport a kapcsolódó erőforrások gyűjteménye egy Azure megoldásnál.
Ez egy tároló, amely összeköti a szolgáltatáshoz vagy megoldáshoz kapcsolódó összes
erőforrást. Egy erőforráscsoport létrehozása lehetővé teszi egy megoldás könnyű
hozzáférését és kezelését. Kezdjünk neki a saját erőforráscsoportjának létrehozásával:
1. Nyissa meg az Azure-portált.

2. Nyissa meg a portálmenüt (menjen a portál kezdőoldalára, ha nincs ott
alapértelmezetten) és menjen az erőforráscsoport ikonja fölé a navigáció
részen. Egy Create gomb fog megjelenni; kattintson rá, hogy létrehozzon egy
új erőforráscsoportot:
3.3 ábra: Egy erőforráscsoport létrehozása

3. Hozzon létre egy erőforráscsoportot az Ön által választott névvel (Learn_MLOps
az ajánlott, ahogy az látható a 3.3 ábrán.
4. Válasszon egy régiót közel Önhöz, hogy optimális teljesítményt és árat kapjon.
Például a 3.3 ábrán készen áll a létrehozásre egy erőforráscsoport Learn MLOps
névvel a (Europe) North Europe régióban. Miután rákattint a Review + create
gombra és az Azure validálja a kérését, megjelenik a végső Create gomb. Meg kell
nyomni a végső Create gombot, hogy létrehozza az új erőforráscsoportot.
Amikor ellenőrizte és létrehozta az erőforráscsoportot, az ML megoldáshoz kapcsolódó

összes szolgáltatást ebben az erőforráscsoportban állíthatja be és kezelheti. Az újonnan
létrehozott erőforráscsoport meg fog jelenni az erőforráscsoportok listájában.
Azure Machine Learning-munkaterület létrehozása

Az ML munkaterület egy központi elosztópont az ML-je tanítási, telepítési és
monitorozási kísérleteinek követéséhez és kezeléséhez, Egy Azure Machine Learning
munkaterület létrehozásához menjen az Azure-portál menüjébe, kattintson a Create
a resource opcióra, majd keresse meg a Machine Learning opciót és válassza ki.
A következő képernyőt fogja látni:
3.4 ábra: Egy Azure Machine Learning munkaterület létrehozása

Nevezze el a munkaterületet tetszés szerint (például mi MLOps_WS-nek neveztük
a 3.4 ábrán). Válassza ki a korábban létrehozott erőforráscsoportot, hogy hozzákapcsolja
ezt az ML szolgáltatást (Learn_MLOps kiválasztva a 3.4 ábrán). Végül kattintson
a Review + create gombra és átkerül egy új képernyőre a végső Create gombbal. Nyomja
meg a végső Create gombot, hogy létrehozza az Azure Machine Learning munkaterületét.
Az Azure Machine Learning munkaterület (Learn_MLOps) létrehozása után az Azure
platform telepíteni fogja a szolgáltatáshoz szükséges összes erőforrást. Az Azure Machine
Learning példányával (Learn_MLOps) telepített erőforrások, mint amilyen a Blob
Storage, Key Vault, és Application Insights, a munkaterülethez lesznek kötve. Ezeket az
erőforrásokat a munkaterületen és az SDK-n keresztül fogja fogyasztani vagy felhasználni.
Itt részletes utasításokat találhat egy Azure Machine Learning példány létrehozásáról:
https://docs.microsoft.com/azure/machine-learning/how-to-
manage-workspace?tabs=python.
Azure Machine Learning SDK telepítése

Menjen a terminálhoz vagy a parancssorhoz a PC-jén és telepítse az Azure
Machine Learning SDK-t, amelyet átfogóan használunk a kódban a kísérletek irányítására.
A telepítéséhez futtassa a következő parancsot:
pip3 install --upgrade azureml-sdk
Itt találhat részletes utasításokat: https://docs.microsoft.com/python/api/

overview/azure/ml/install?view=azure-ml-py.
Azure DevOps
A forráskód és a CI/CD-vel kapcsolatos műveletek egészét az Azure DevOps használatával
fogjuk irányítani és kezelni. Az Azure DevOps adatraktárában lévő kezelt kódot fogjuk
használni az ML modellek tanítására, telepítésére és monitorozására, amelyet a CI/CD
folyamatok tesznek lehetővé. Kezdjük azzal, hogy létrehozunk egy Azure DevOps
előfizetést:
1. Hozzon létre egy ingyenes fiókot a dev.azure.com címen. Az ingyenes fiók

létrehozható egy meglévő Microsoft vagy GitHub fiók használatával.
2. Hozzon létre egy projektet Learn_MLOps néven (tetszés szerint állítsa publikusra
vagy privátra).
3. Menjen a repos részre. Az Import a repository részen nyomja meg az Import
gombot.
4. Importáljon egy adatraktárt egy publikus GitHub projektből ebbe az adatraktárba:

https://github.com/PacktPublishing/EngineeringMLOps (ahogy
látható a 3.5 ábrán):
3.5 ábra: A GitHub adatraktár importálása az Azure DevOps projektbe

A GitHub adatraktár importálása után megjelennek a fájlok az importált adatraktárból.
JupyterHub
Végül szükségünk lesz egy interaktív adatelemzési és vizualizációs eszközre, hogy
feldolgozzuk az adatokat a kódunk használatával. Ehhez a JupyterHub-ot használjuk.
Ez egy gyakori adatkutatási eszköz, amelyet az adatkutatók széleskörűen használnak az
adatok feldolgozására, vizualizációjára és ML modellek tanítására. A telepítéséhez kövesse
a két egyszerű lépést:
1. Telepítse a JupyterHub-ot a parancssoron keresztül a PC-jén:
python3 -m pip install jupyterhub
Itt találhat részletes utasításokat: https://jupyterhub.readthedocs.io/

en/stable/quickstart.html.
2. Anaconda telepítése.
Szükséges az Anaconda, mivel függőségeket, környezeteket és szolgáltatásokat
telepít a JupyterHub támogatásához. Töltse le és telepítse az Anaconda-t az itt
található részletes utasítások alapján: https://docs.anaconda.com/
anaconda/install/.
Most, hogy készen állunk a gyakorlatian megvalósításra, nézzük meg mi kell a jó
kód és adatok kezeléséhez.
A forráskódkezelés 10 alapelve az ML-nél

Itt van a 10 alapelv, amely alkalmazható a kódjánál, hogy biztosítsa a kódja minőségét,
robosztusságát és méretezhetőségét:
• Modularitás: A moduláris kód jobb, mint egy nagy tömb. A modularitás támogatja
az újrahasználhatóságot és megkönnyíti a korszerűsítést a szükséges komponensek
cseréjével. A szükségtelen komplexitás és ismétlődés elkerüléséhez kövesse ezt az
aranyszabályt:
Két vagy több ML komponenst csak akkor kell párosítani, amikor az egyik
használja a másikat. Ha egyik sem használja a másikat, akkor a párosítást
el kell kerülni.
Egy olyan ML komponenst, amely nincs szorosan párosítva a környezetével,

könnyebb lehet módosítani vagy cserélni, mint egy szorosan párosított komponenst.
A forráskódkezelés 10 alapelve az ML-nél 61
• Egyetlen feladatra kijelölt függvények: A függvények fontos építőelemei

a folyamatoknak és a rendszernek, és kis kódrészletek, amelyek bizonyos feladatok
végrehajtására használatosak. A függvények célja a parancsok ismétlődésének
elkerülése és az újrahasználható kód lehetővé tétele. Könnyen válhatnak komplex
parancskészletté a feladatok megkönnyítésére. Az olvasható és újrahasználható
kód érdekében hatékonyabb, ha egyetlen függvényt egyetlen feladathoz jelölünk ki
több feladat helyett. Jobb, ha több függvényünk van, mintha egy hosszú és komplex
függvényünk.
• Szerkesztés: A függvényeket, osztályokat és utasításokat egy olvasható, moduláris és
tömör formába kell szerkeszteni. Senki sem akar egy olyan hibát látni, mint: Error
300. Ha szerkeszti a kódblokkokat és próbálja korlátozni a függvények és osztályok
behúzásának maximális szintjeit, az javíthatja a kód olvashatóságát.
• Tiszta kód: Ha meg kell magyaráznia a kódot, az nem jó. A tiszta kód magától
értetődő. Az ilyen a jó olvashatóságra, optimális modularitásra, újrahasználhatóságra,
ismétlődés elkerülésére és optimális teljesítményre koncentrál. A tiszta kód csökkenti
az ML folyamatainak fenntartási és fejlesztési költségét. Lehetővé teszi egy csapatnak,
hogy hatékonyan teljesítsen és kiterjeszthető más fejlesztők felé.
Ahhoz, hogy mélyebben megértse ezt, olvassa el a Clean Code: A Handbook of Agile
Software Craftsmanship könyvet Robert C Martin-tól.
• Tesztelés: Kulcsfontosságú, hogy biztosítsa egy rendszer robosztusságát,
és a tesztelés fontos szerepet játszik ebben. Általában véve a tesztelés kiterjed az
egység tesztelésére és az átvétel tesztelésére. Az egység tesztelése egy olyan módszer,
amellyel a forráskód komponenseinek robosztusságát tesztelik korlátozott adatokkal
és használati módszerekkel, hogy meghatározzák, a komponens illik a termelési
rendszerbe. Az átvételi teszteket azért végzik, hogy a teljes rendszert teszteljék, hogy
biztosítsák, a rendszer megvalósítja-e a felhasználó követelményeit; az end-to-end
üzleti áramlatokat valós idejű szituációkban ellenőrzik. A tesztelés létfontosságú
a kód hatékony működésének biztosításához: "ha nem tesztelték, rossz."
Ahhoz, hogy többet tudjon meg az egységtesztelés megvalósításáról, olvassa el ezt a

dokumentumot: https://docs.python.org/3/library/unittest.html.
• Verziókezelés (kód, adat és modellek): A Git használatos a kód verziókezelésére

az ML rendszerekben A verziókezelés célja, hogy biztosítsa, hogy minden csapattag,
aki a rendszeren dolgozik, friss kódhoz férjen hozzá, és az a kód ne vesszen el, amikor
meghibásodik egy hardver. A Git-tel valós munkavégzés egy szabálya kell legyen,
hogy ne törje meg a master-t (elágazás). Ez azt jelenti, hogy amikor az adatraktárban
lévő kódon dolgozik, és új jellemzőket ad hozzá, vagy javításokat végez, ezt egy
jellemző elágazáson teszi, amely összeolvad a master elágazással, amikor a kódot
ellenőrizték és működik. Az elágazásoknak egy rövid, leíró nevet kell adni,
például: feature/label-encoder. Az elágazások elnevezését és jóváhagyási irányelveit
megfelelően kommunikálni és egyeztetni kell a csapattal, hogy elkerüljék az összes
komplexitást és felesleges konfliktust. A kód ellenőrzését a kód adatraktárába történő
behúzási kérésekkel végzik. Általában kis készletekben a legjobb ellenőrizni a kódot,
ami kevesebb, mint 400 sor. A gyakorlatban ez gyakran egy modult vagy almodult
jelent egyszerre.
Az adatok verziókezelése kritikus az ML rendszereknél, mivel ez segít nekünk
követni, hogy mely adatokat használták fel egy adott kódverzióhoz egy modell
generálásához. Az adatok verziókezelése lehetővé teheti a modellek reprodukálását
és a megfelelőséget az üzleti igények és törvény szempontjából. Mindig
visszakövethetjük és láthatjuk az ML rendszer által végrehajtott bizonyos
tevékenységeknek az okát. Ehhez hasonlóan a modellek (tárgyak) verziókezelése
fontos annak követéséhez, hogy egy modell melyik verziója generált bizonyos
eredményeket vagy tevékenységeket az ML rendszernél. Követhetjük vagy
naplózhatjuk a paramétereket is, amelyeket a modell egy bizonyos verziójának
tanításához használtak. Így lehetővé tehetjük az end-to-end követhetőséget a modell
tárgyaknál, adatoknál és kódnál. A kód, adatok és modellek verziókezelése javíthat
egy ML rendszert az azt fejlesztő és fenntartó embereknek biztosított nagyszerű
átláthatóság és hatékonyság miatt.
• Naplózás: A termelésben egy naplózó hasznos, mert lehetséges monitorozni
és azonosítani a fontos információkat. A print utasítások jók a teszteléshez
és hibakereséshez, de nem ideálisak a termelésnél. A naplózó információkat
tartalmaz, különösen rendszerinformációkat, figyelmeztetéseket és hibákat, amelyek
meglehetősen hasznosak a termelési rendszerek monitorozásában.
• Hibakezelés: A hibakezelés létfontosságú a peremesetek kezelésénél, különösen
azoknál, amelyeket nehéz előre látni. Ajánlott kiszűrni és kezelni a kivételeket,
akkor is, ha úgy gondolja, nem szükséges, mivel jobb megelőzni, mint gyógyítani.
A naplózás kombinálva a kivételkezeléssel hatékony módja lehet a peremesetek
kezelésének.
A forráskódkezelés 10 alapelve az ML-nél 63
• Olvashatóság: A kód olvashatósága lehetővé teszi az információ átvitelét, a kód

hatékonyságát és a kód fenntarthatóságát. Az olyan következő alapelvekkel érhető
el, mint a PEP-8 programozási gyakorlatok ipari szabvány (https://www.
python.org/dev/peps/pep-0008/) vagy a JavaScript standard stílus (az Ön
által használt nyelvtől függően). A dokumentációs sztringek használata is növeli az
olvashatóságot. A dokumentációs sztring egy szöveg, amelyet például egy függvény
elejére írnak, ami leírja, hogy mit csinál, és mi lehet a bemenete. Néhány esetben
elég egy egysoros magyarázat, mint például ez:
def swap(a,b):
"""Swaps the variables a and b. Returns the swapped
variables"""
return b, a
Egy komplexebb függvényhez egy hosszabb dokumentációs sztringre van szükség.

Az argumentumok és visszatérések megmagyarázása jó ötlet:
def function_with_types_in_docstring(param1, param2):
"""Example function with types documented in the
docstring.
`PEP 484`_ type annotations are supported. If attribute,

parameter, and
return types are annotated according to `PEP 484`_, they
do not need to be
included in the docstring:
Args:
param1 (int): The first parameter.
param2 (str): The second parameter.
Returns:
bool: The return value. True for success, False
otherwise.
"""
• Kommentelés és dokumentálás: A kommentelés és dokumentálás létfontosságú

a fenntartható kód megőrzéséhez. Nem mindig lehet egyértelműen megmagyarázni
a kódot. A kommentek hasznosak lehetnek az ilyen esetekben, hogy megelőzzék
a zavarodottságot és megmagyarázzák a kódot. A kommentek olyan információkat
tartalmazhatnak, mint például a szerzői jogok információi, szándék, a kód
egyértelműsítése, lehetséges hibák és a kód feldolgozása. A rendszer és modulok
dokumentációjának feldolgozása lehetővé teszi egy csapatnak, hogy hatékonyan
dolgozzanak, illetve megoszthassák a kódot és eszközöket más fejlesztőkkel.
A dokumentációhoz vannak elérhető nyílt forráskódú eszközök az API-k
dokumentálására, mint például a Swagger (https://swagger.io) és a Read
the Docs (https://readthedocs.org). A megfelelő dokumentációs eszközök
használata lehetővé teszi a tudás szabványosítását és hatékonyságát a fejlesztőknek.
Milyen a jó adat az ML-nek?

A jó ML modellek a jó minőségű adaton végzett tanítás eredményei. Mielőtt
továbblépnénk az ML tanítására, egy előkövetelmény, hogy jó minőségű adataink
legyenek. Ezért fel kell dolgoznunk az adatokat, hogy javítsuk a minőségét. Ezért az
adatminőség meghatározása létfontosságú. Öt jellemző lehetővé teszi számunkra, hogy
megismerjük az adatminőséget, ezek a következők:
• Pontosság: A pontosság egy kritikus jellemzője az adatminőségnek, mivel

a pontatlan adat gyenge ML modellteljesítményhez és következményekhez vezethet
a való életben. Az adatpontosság ellenőrzéséhez erősítse meg, hogy az információ
egy szituációt képvisel-e vagy sem.
• Teljesség: A legtöbb esetben a nem teljes információ használhatatlan és helytelen
kimenetelekhez vezethet, ha ilyennel tanítják az ML modellt. Kulcsfontosságú
ellenőrizni az adatok átfogóságát.
• Megbízhatóság: Az ellentmondások vagy duplikációk az adatban az adat
megbízhatatlanságához vezethetnek. A megbízhatóság egy lényeges jellemző;
fontos megbízni az adatokban, mielőtt felhasználják az ML-t alkalmazó valós
döntések meghozásához. Bizonyos fokig értékelhetjük az adat megbízhatóságát,
ha megvizsgáljuk az elfogultságot és eloszlást. Szélsőségek esetében az adat lehet,
hogy nem megbízható az ML tanításához vagy elfogultságot tartalmazhat.
• Relevancia: Az adat relevanciája létfontosságú szerepet játszik a kontextusba
helyezésben és annak meghatározásában, gyűjtöttek-e irreleváns információt.
A releváns adatok lehetővé tehetik a megfelelő döntéseket ML használatával a valós
kontextusban.
• Időbeniség: Az elavult vagy régi információ pénzbe és időbe kerül a cégeknek;
a friss információ néhány esetben lényeges és javíthatja az adatminőséget. A nem
időbeni adatokat használó ML-lel hozott döntések költségesek lehetnek és rossz
döntésekhez vezethetnek.
Milyen a jó adat az ML-nek? 65
Amikor ezt az öt jellemzőt maximalizálják, az biztosítja a legjobb minőségű adatokat.

Észben tartva ezeket az alapelveket, mélyedjünk el a megvalósításban, ahol a kód
találkozik az adatokkal.
Először értékeljük az adatokat és dolgozzuk fel, hogy készen álljon az ML tanítására.
Kezdésként klónozzuk az adatraktárt, amelyet importált az Azure DevOps projektjébe
(a GitHub-ról):
git clone https://xxxxxxxxx@dev.azure.com/xxxxx/Learn_MLOps/_

git/Learn_MLOps
Következőként nyissa meg a terminálját és nyissa meg a klónozott adatraktár mappáját

és pörgesse fel a JupyterLab szervert az adatfeldolgozáshoz. Ehhez gépelje be a következő
parancsot a terminálon:
jupyter lab
Ez automatikusan megnyit egy ablakot a böngészőjében a http://localhost:8888

címen, ahol kódolhat, és futtathatja a kódot a JupyterLab interfészen. A Code_meets_
data_c3 mappában van egy Python szkript (dataprocessing.py) és egy .ipynb
jegyzettömb (dataprocessing.ipynb); nyugodtan futtassa ezen fájlok bármelyikét
vagy hozzon létre egy új jegyzettömböt és kövesse a következő lépéseket.
Számításokat fogunk végezni a 3.6 ábrán leírt feladatokhoz. Az adatfeldolgozást helyben
fogjuk elvégezni a PC-jén, ezt az ML tanítása, telepítése és monitorozása követi a számítási
célokon a felhőben. Ezzel tapasztalatot szerez a modellek különböző környezetben történő
megvalósításáról. A fejezet hátralévő részében adatfeldolgozást fogunk végezni (helyileg),
hogy elérjük az adat legjobb minőségét az ML tanítás érdekében (a felhőben, amelyet
a következő fejezetben részletezünk).
3.6 ábra: A számítás helyszínei az adatoknál és ML feladatoknál

A nyers adatok feldolgozásához és ML-re történő felkészítéséhez Ön fogja

elvégezni a számítást és adatfeldolgozást a helyi PC-jén. Kezdésként telepítjük és
importáljuk a szükséges csomagokat és importáljuk a nyers adatkészletet (ahogy az
a dataprocessing.ipynb és .py szkriptekben látható). A jegyzettömbökben lévő
Python utasításokat a meglévő jegyzettömbben kell végrehajtani:
%matplotlib inline
import pandas as pd
import numpy as np
from matplotlib import pyplot as plt
from matplotlib.pyplot import figure
import seaborn as sns
from azureml.core import Workspace, Dataset
#import dataset
df = pd.read_csv('Dataset/weather_dataset_raw.csv')
Ezzel importálta az adatkészletet egy pandas DataFrame-be, df, a további feldolgozáshoz.
Adat előfeldolgozás
A nyers adat nem adható át közvetlenül az ML modellnek a tanításhoz. Az adatot
előfeldolgozni vagy finomítani kell, mielőtt az ML modellt tanítjuk. Az importált adat
további elemzéséhez egy lépéssort fogunk végrehajtani az adatok előfeldolgozásához,
hogy az ML tanításához megfelelő formába kerüljön. Azzal kezdjük, hogy értéklejük az
adatminőséget, hogy ellenőrizzük a pontosságot, teljességet, megbízhatóságot, relevanciát
és időbeniséget. Ezután kalibráljuk a szükséges adatokat és a szöveges számokból álló adattá
kódoljuk, amely ideális az ML tanításához. Végül elemezzük a korrelációkat és idősorokat,
és kiszűrjük az ML modell tanításánál irreleváns adatokat.
Adatminőség értékelése
Az adatminőség értékeléséhez megnézzük a pontosságot, teljességet, megbízhatóságot,
relevanciát és időbeniséget. Először ellenőrizzük, hogy az adat teljes-e és megbízható-e
úgy, hogy értékeljük a formátumokat, összesített statisztikákat és az olyan anomáliákat,
mint a hiányzó adat. Pandas függvényeket használunk a következőképpen:
df.describe()
Adat előfeldolgozás 67
A describe függvény használatával megfigyelhetjük a leíró statisztikákat a kimenetben

a következőképpen:
3.7 ábra: A DataFrame leíró statisztikái

Tehetünk néhány megfigyelést, hogy levonjuk a következtetést, az adat koherens és
releváns, mivel valós statisztikákat ábrázol, mivel egy átlaghőmérséklet ~11 °C és egy
szélsebesség ~10 kmph. Finnországban a minimum hőmérséklet el szokta érni a nagyjából
-21 °C-ot és az átlagos láthatóság 10 km. Az ilyen tények mutatják a relevanciát és az adat
származásának körülményeit. Most vizsgáljuk meg az oszlop formátumait:
df.dtypes
Itt vannak az oszlop formátumai:
• S_No int64
• Timestamp object
• Location object
• Temperature_C float64
• Apparent_Temperature_C float64
• Humidity float64
• Wind_speed_kmph float64
• Wind_bearing_degrees int64
• Visibility_km float64
• Pressure_millibars float64
• Weather_conditions object
• dtype object
A legtöbb oszlop numerikus (float és int), ahogy vártuk. A Timestamp oszlop

object formátumú, amelyet át kell váltani DateTime formátumra:
df['Timestamp'] = pd.to_datetime(df['Timestamp'])
A pandas to_datetime függvényének használatával átalakíthatjuk a Timestamp

formátumot DateTime formátummá. Következőként nézzük meg, van-e nulla érték.
Ennek ellenőrzéséhez a pandas isnull függvényét használjuk:
df.isnull().values.any()
A nulla értékek ellenőrzésekor, ha nulla értékeket találunk, következő lépésként

létfontosságú a hiányzó adat kalibrálása.
Hiányzó adatok kalibrálása

Nem ideális, ha hiányzó értékek vannak az adatban, mivel ez rossz adatminőség jele.
A hiányzó adatok vagy értékek számos technika használatával kicserélhetők az adat
megbízhatóságának vagy korrektségének veszélyeztetése nélkül. Miután megvizsgáltuk
az adatot, amelyen dolgozunk, találtunk néhány hiányzó értéket. A Forward fill
módszert használjuk a hiányzó adat kezelésére:
df['Weather_conditions'].fillna(method='ffill', inplace=True,
axis=0)
NaN vagy nulla értékek csak a Weather_conditions oszlopban találhatók. Kicseréljük

a NaN értékeket a fillna() pandas módszer használatával, és az elől töltő (ffill)
módszerrel. Mivel az időjárás folytatólagos, valószínűleg az előző esemény ismétlődik az
adatokban. Ezért az előre töltő módszert használjuk, amely lemásolja az utolsó nem nulla
értéket, amíg egy másik nem nulla értéket nem talál.
Címkekódolás
Mivel a gépek nem értik az emberi nyelvet vagy szöveget, minden szöveget számokká kell
alakítani. Ezelőtt dolgozzuk fel a szöveget. Van egy Weather_conditons oszlopunk
a szövegben olyan értékekkel vagy címkékkel, mint például rain, snow és clear.
Ezeket az értékeket találtuk a pandas value_counts() függvényének használatával
df['Weather_conditions'].value_counts()
A Weather_conditions egyszerűsíthető az oszlop címkéinek két címkévé történő

osztályozásával, amelyek a rain vagy no_rain. Ebben a két kategóriában az előrejelzés
lehetővé teszi számunkra, hogy megoldjuk a teherszállító cég üzleti problémáját:
df['Weather_conditions'].replace({"snow": "no_rain", "clear":

"no_rain"}, inplace=True)
Ez lecseréli a snow és clear értékeket a no_rain értékre, mivel mindkét körülmény

arra utal, hogy nem esik a kikötőben. Most hogy feldolgoztuk a címkéket, konvertálhatjuk
a Weather_conditions oszlopot egy gép által olvasható formátumba vagyis számokká
a címkekódolás használatával. A címkekódolás egy kategorikus értékeket gép által
olvasható formátummá vagyis számokká konvertáló módszer, amely minden kategóriához
egy egyedi értéket rendel hozzá. Mivel csak két kategóriánk van, rain és no_rain, a
címkekódolás hatékony lehet, mivel ezeket az értékeket 0-vá és 1-gyé alakítja. Ha kettőnél
több értékünk lenne, akkor a one-hot encoding egy jó választás lenne, mert növekményes
számokat rendel hozzá a kategorikus változókhoz, amely nagyobb prioritást adhat a
változóknak vagyis numerikus elfogultságot a tanítás során. A one-hot encoding megelőzi
az elfogultságot vagy a magasabb preferenciát bármely változónál, és biztosítja a semleges
előjogokat a kategorikus változók minden értékének. A mi esetünkben, mivel csak két
kategorikus változónk van, címkekódolást hajtunk végre a scikit-learn használatával a
következőképpen:
from sklearn.preprocessing import LabelEncoder

le = LabelEncoder()
y = df['Weather_conditions']
y = le.fit_transform(y)
Itt importáljuk a LabelEncoder() függvényt, amely nullákká és egyesekké kódolja

a Weather_conditions oszlopot a fit_transform() módszer használatával.
Ezt úgy tehetjük meg, hogy kicseréljük az előző szöveges oszlopot egy címkekódolt vagy
gép által olvasható formátumra a Weather_condition oszlopot a következőképpen:
y = pd.DataFrame(data=y, columns=["Weather_condition"])
df = pd.concat([df,y], axis=1)
df.drop(['Weather_conditions'], axis=1, inplace=True)
Itt az új címkekódolt vagy gép által olvasható Weather_condition oszlopunkat

összefűzzük a DataFrame-mel és eldobjuk az előző, gép által nem olvasható vagyis szöveges
Weather_conditions oszlopot. Az adat már gép által olvasható formátumban van és
készen áll a további feldolgozásra. Ellenőrizheti az átalakított adatokat, ha végrehajtja a df.
head() funkciót a jegyzettömbben (opcionális).
Új jellemző: Future_weather_condition
Mivel azzal bíztak meg minket, hogy jósoljuk meg az időjárást 4 órával előre, ezért
létrehozunk egy új jellemzőt Future_weather_condition néven azáltal, hogy négy
sorral eltoljuk a Current_weather_condition-t, mivel minden sort egy órás
időközzel rögzítettek. A Future_weather_condition a jövőbeni időjárási körülmény
címkéje 4 órával később. Ezt az új jellemzőt függő változóként fogjuk használni az
előrejelzéshez az ML használatával:
df['Future_weather_condition'] = df.Current_weather_condition.
shift(4, axis = 0)
df.dropna(inplace=True)
A pandas dropna() függvényét fogjuk használni a DataFrame-en, hogy elvessük vagy

eldobjuk a nulla értékeket, mivel néhány sornak nulla lesz az értéke amiatt, hogy egy új
oszlopra váltunk.
Adatkorrelációk és szűrés
Most, hogy az adat gép által teljesen olvasható, megfigyelhetjük a korrelációkat a Pearson
korrelációs együttható használatával, hogy megfigyeljük, hogyan kapcsolódnak az
egyes oszlopok más oszlopokhoz. Az adat és jellemző korrelációja egy lényeges lépés,
mielőtt jellemzőt választanánk az ML modell tanításához, különösen, amikor a jellemzők
folytonosak, mint a mi esetünkben. A Pearson korrelációs együttható egy statisztikai
lineáris korreláció az egyes változók (X és Y) között, amely egy értéket hoz létre +1 és
-1 között. A +1 érték egy pozitív lineáris korreláció, a -1 egy negatív lineáris korreláció,
és a 0 egy nem lineáris korreláció. Ez használható a folytonos változók közötti kapcsolat
feltárására, bár érdemes megjegyezni, hogy a Pearson korreláció nem jelent okozati
viszonyt. Megvizsgálhatjuk a Pearson korrelációs együtthatókat az adatunknál a pandas
használatával a következőképpen:
df.corr(method="pearson")
# Visualizing using heatmap
corrMatrix = df.corr()
sn.heatmap(corrMatrix, annot=True)
plt.show()
Itt vannak a Pearson hőtérkép korrelációs eredményei:
3.8 ábra: A korreláció hőtérképének pontszámai

A 3.8 ábra hőtérképén láthatjuk, hogy a Temperature és Apparent_Temperature_

C együtthatója 0,99. S_No (Sorszám) egy folytonos érték, amely többé-kevésbé egy
növekményes index egy DataFrame-nél, és elvethető vagy kiszűrhető, mivel nincs nagy
értéke. Így mind az Apparent_Temperature mind a S_No értékeket elvetettük vagy
kiszűrtük. Most nézzük meg a függő változónkat, a Future_weather_condition-t,
és a korrelációját a többi független változóval:
3.9 ábra: Pearson korreláció a Future_weather_condition-nél

Bármi 0,5 és 1,0 között egy pozitív korrelációval rendelkezik és bármi -0,5 és -1,0 között
egy negatív korrelációval rendelkezik. A grafikon alapján pozitív korreláció van a
Current_weather_condition-nel, és a Temperature_C szintén pozitívan korrelál
a Future_weather_c-vel.
Idősorozatok elemzése
Mivel a hőmérséklet egy folytonos változó, érdemes megfigyelni a változását az időben.
Vizualizálhatunk egy idősorozatrajzolót a matplotlib használatával a következőképpen:
time = df['Timestamp]
temp = df['Temperature_C']
# plot graph
plt.plot(time, temp)
plt.show()
Itt van az ábrázolt eredmény:
3.10 ábra: A hőmérséklet idősorozatos változása Celsius fokban ábrázolva
A hőmérséklet idősorozatos változásának értékelés után a 3.10 ábrán, azt láthatjuk

hogy ez egy állandósult mintát ábrázol, mivel az átlag, variancia és kovariancia az időben
állandósult. Az állandósult viselkedések lehetnek tendenciák, ciklusok rendezetlen bejárások
vagy a három kombinációja. Ennek van értelme, mivel a hőmérséklet évszakonként változik
és évszakos mintákat követ. Ezzel elérkeztük az adat elemzésének és feldolgozásának
végére; már készen állunk a feldolgozott adat regisztrálására a munkaterületen, mielőtt
továbblépnénk az ML modell tanítására.
Adatok regisztrációja és ellátása verzióval

Fontos regisztrálni az adatokat és ellátni őket verzióval a munkaterületen, mielőtt elkezdjük
tanítani az ML-t, mivel ez lehetővé teszi számunkra, hogy visszakövessük a kísérleteinket vagy
ML modelljeinket az adatforráshoz, amelyet a modellek tanítására használtunk. Az adatok
verziókezelésének célja, hogy bármilyen pontra visszakövessük, hogy megismételjük egy
modell tanítását vagy hogy megmagyarázzuk a modell működését a következtetés vagy
a tesztadatok alapján az ML modell magyarázásánál. Ezen okokból regisztrálni fogjuk
a feldolgozott adatokat és ellátjuk őket verzióval, hogy az ML folyamatunkhoz használhassuk.
Az Azure Machine Learning munkaterülethez regisztráljuk és verziózzuk a feldolgozott
adatokat az Azure Machine Learning SDK használatával a következőképpen:
subscription_id = '---insert your subscription ID here----'

resource_group = 'Learn_MLOps'
workspace_name = 'MLOps_WS'
workspace = Workspace(subscription_id, resource_group,
workspace_name)
Olvassa ki az előfizetési ID, resource_group és workspace_name adatokat

az Azure Machine Learning portálról, ahogy az látható a 3.11 ábrán:
3.11 ábra: A munkaterület belépési adatai (erősforráscsoport, előfizetési ID és munkaterület neve)

Adatok regisztrációja és ellátása verzióval 75
A munkaterület belépési adatainak lekérésével kap egy munkaterület objektumot.

Amikor a Workspace() függvényt futtatja, a laptopja csatlakozni fog az Azure
platformhoz. Megkérik, hogy kattintson egy hitelesítési linkre, és adjon meg egy random
kódot és az Azure fiók adatait. Ezután a szkript megerősíti a hitelesítést. A munkaterület
objektumának használatával hozzáférünk az alapértelmezett adattárhoz és feltöltjük
a szükséges adatfájlokat az adattárolóra a munkaterülethez csatlakoztatott Azure Blob
Storage-en:
# get the default datastore linked to upload prepared data

datastore = workspace.get_default_datastore()
#upload the local file from src_dir to target_path in datastore
datastore.upload(src_dir='Dataset', target_path='data')
dataset = /
Dataset.Tablular.from_delimited_files(datastore.path('data/
weather_dataset_processed.csv'))
Tabular.from_delimited_files() okozhat egy hibát a Linux vagy MacOS

gépeken, amelyekre nem telepítették a .NET Core 2.1-et. Ezen függőség helyes
telepítéséhez, kövesse ezeket az utasításokat: https://docs.microsoft.com/
dotnet/core/install/linux. Miután sikeresen végrehajtotta az előző parancsokat,
fel fogja tölteni az adatfájlokat az adattárba és az eredményt a 3.12 ábrán láthatja.
Az adatkészletet megtekintheti az adattárban a következőképpen:
# preview the first 3 rows of the dataset from the datastore

dataset.take(3).to_pandas_dataframe()
Miután feltöltötte az adatokat az adattárba, regisztrálni fogjuk az adatkészletet

a munkaterülethez és verziót adunk neki a következőképpen:
weather_ds = dataset.register(workspace=workspace,
name=weather_ds_portofTurku, description='processed weather
data')
A register(...) függvény regisztrálja az adatkészletet a munkaterületen, ahogy

a 3.12 ábrán látható. A részletes dokumentációért látogasson el a https://docs.
microsoft.com/azure/machine-learning/how-to-create-register-
datasets#register-datasets oldalra:
3.12 ábra: Az ML munkaterületen regisztrált feldolgozott adatkészlet
Az ML folyamat irányába
Idáig feldolgoztuk az adatokat azzal, hogy az olyan szabálytalanságokon dolgoztunk, mint
a hiányzó adatok, a korrelációk megfigyelésével kiválasztott jellemzők, létrehozott új
jellemzők és végül a Machine Learning munkaterületre bevitt és verziókezelt, feldolgozott
adatok. Két módja van az adatbevitelre az ML modell tanításánál az ML folyamatban.
Az egyik mód a központi tárolóból (ahol az összes nyers adatot tárolja) és a másik mód
egy funkció tároló használata. Mivel a tudás hatalom, ismerjük meg a funkció tároló
használatát, mielőtt rátérünk az ML folyamatra.
Az ML folyamat irányába 77
Funkció tároló
Egy funkció tároló tiszteletben tartja a központi tárolót, mivel fontos jellemzőket tárol
és elérhetővé teszi őket a tanításhoz vagy következtetéshez. A funkció tároló egy olyan
tároló, ahol a nyers adatokat hasznos jellemzőkké alakíthatja, amelyeket az ML modellek
közvetlenül tanításra és előrejelzések készítésére használhatnak. A nyers adat általában
különböző adatforrásokból érkezik, amelyek lehetnek, strukturáltak, strukturálatlanok,
folyamszerűek, kötegeltek és valós idejűek. Mindegyiket be kell húzni, át kell alakítani
(egy jellemzőfolyamat használatával) és tárolni kell valahol, ami lehet egy funkció tároló.
A funkció tároló aztán fogja az adatot és fogyasztásra elérhetővé teszi. Az adatkutatók
hajlamosak duplán dolgozni (főleg az adatfeldolgozásnál). Ez elkerülhető, ha van egy
központosított funkció tárolónk. A funkció tároló lehetővé teszi az adatkutatóknak,
hogy hatékonyan osszák meg és használják újra a jellemzőket más csapatokkal, és így nő
a termelékenységük, mivel nem a nulláról kell kezdeniük a jellemzők előfeldolgozását.
3.13 ábra: Funkció tároló munkafolyamat

Ahogy a 3.13 ábrán láthatjuk, a Funkció tároló egy Jellemzőfolyamatot használ, amely
egy Központi tárolóhoz van csatlakoztatva (amely több forrásból tárolja az adatokat),
hogy átalakítsa és hasznos jellemzőként tárolja a nyers adatokat az ML tanításához.
A funkció tárolóban tárolt jellemzők visszakereshetők a tanításhoz, kiszolgáláshoz vagy
ötletek vagy trendek felderítéséhez. Itt van a funkció tároló használatának néhány előnye:
• Hatékony Jellemzőtervezés a Tanítási adatokhoz

• Az adat szükségtelen előfeldolgozásának elkerülése a tanítás előtt
• Ismétlődő jellemzőtervezés elkerülése
• A jellemzők elérhetők a gyors következtetéshez (tesztelés)
• Rendszertámogatás a jellemzők kiszolgálásához
• Előzetes adatelemzés a funkció tároló által

• A modellek jellemzőinek újrafelhasználási lehetősége
• Jellemzők gyors lekérdezése
• Reprodukálhatóság a tanítási adatkészletekhez
• A jellemzőeltérés monitorozása a termelésben (a jellemzőeltérésről tanulni fogunk
a 12. fejezet: Modellek kiszolgálása és monitorozása részben)
• Az adateltérés monitorozásához elérhető jellemzők
Jó tudni egy funkció tároló előnyeit, mivel hasznos lehet az ML folyamat működtetéséhez
(főleg az adatbeviteli lépésnél), azonban nem alkalmas minden esetben. A felhasználás
eseten múlik. A mi esetünk megvalósításánál nem fogjuk használni a funkció tárolót, de
folytatjuk az adat összekapcsolásával közvetlenül a központi tárolóból, ahol előfeldolgozott
és regisztrált adatkészleteink vannak, amelyekre a tanításhoz és teszteléshez szükségünk
van. A bevitt és verziókezelt adatokkal készen áll, hogy továbblépjen a saját ML
folyamatának kialakítására. Az ML folyamat lehetővé teszi a további jellemzőtervezést,
jellemző méretezést, tanítás felügyeletét és az adatkészletek tesztelését, amelyeket az ML
modellek tanításához és a hiperparaméterek hangolásához fogunk használni a gépi tanulás
betanításánál. Az ML folyamatot és funkcionalitásokat felhőalapú számítási erőforrásokon
keresztül fogjuk végrehajtani, nem helyileg a számítógépén, mint ebben a fejezetben.
Ez teljesen felhőalapú lesz.
Összefoglalás
Ebben a fejezetben megismertük hogyan kell meghatározni a megfelelő ML megoldást
egy üzleti problémához, és hogyan kell kategorizálni a műveleteket a megfelelő
MLOps megvalósításához. Beállítottuk az eszközeinket, erőforrásainkat és fejlesztési
környezetünket. Megvitattuk a forráskódkezelés 10 vezérelvét, amelyet az adatminőség
jellemzői követtek. Gratulálok! Eddig megvalósította az MLOps munkafolyamat egyik
kritikus építőelemét, az adatfeldolgozást és az adatok regisztrációját a munkaterületen.
Végül vetettünk egy pillantást az ML folyamat fő részeire.
A következő fejezetben az MLOps legizgalmasabb részét fogja megcsinálni: kialakítja
az ML folyamatot. Haladjunk tovább!
4
Machine Learning
folyamatok
Ebben a fejezetben felfedezzük és megvalósítjuk a gépi tanulás (ML) folyamatokat
az MLOps megközelítés használatával átvett gyakorlatias példákon keresztül. Többet
tudhatunk meg, ha megoldjuk az üzleti problémát, amelyen a 3. fejezet: A kód találkozik
az adattal részben dolgoztunk. A tanulásnak ez az elméleti és gyakorlati megközelítése
biztosítja, hogy széleskörű tudással rendelkezzen az ML folyamatok megtervezéséről és
megvalósításáról a problémáinál és cégének problémáinál. Egy ML folyamat moduláris
szkriptekből vagy kódból áll, amely végrehajtja az ML összes hagyományos lépését, mint
például az adatok előfeldolgozása, funkciók kialakítása és méretezése bármely modell
tanítása vagy újratanítás előtt.
Az előző fejezetben előfeldolgozott adatok bevitelével kezdjük ezt a fejezetet azáltal,
hogy funkciótervezést és -méretezést hajtunk végre, hogy az ML tanításához megfelelő
formába kerüljenek. Felderítjük az ML folyamatok alapelveit és megvalósítjuk őket
az üzleti problémánál. Ezután megnézzük az ML modell tanítását, a hiperparaméter
hangolását és a betanított modellek tesztelését. Végül a modellek csomagolásáról és
a szükséges tárgyakról fogunk tanulni. Regisztrálni fogjuk a modelleket a további
kiértékeléshez és telepíteni fogjuk az ML modelleket. Ebben a fejezetben a következő fő
témákat érintjük:
• Átvesszük az ML folyamatok alapjait

• Adatbevitel és funkciótervezés
• ML tanítása és hiperparaméter optimalizáció
80 Machine Learning folyamatok
• Modell tesztelése és mérések meghatározása

• Modellcsomagolás
• Modellek és termelési tárgyak regisztrációja
Átvesszük az ML folyamatok alapjait

Mielőtt belevetjük magunkat az ML folyamat megvalósításába, tegyük helyre az alapokat.
Reflektálni fogunk az ML folyamatokra és felállítjuk az ML folyamat megvalósításához
szükséges erőforrásokat, aztán elkezdjük az adatbevitelt. Rántsuk le a leplet az ML
folyamatokról azzal, hogy reflektálunk az ML folyamatra, amelyet az 1.10 ábrán az 1.
fejezet: Az MLOps Workflow alapjai részben tárgyaltunk.
4.1 ábra: Machine Learning folyamat

Ahogy a 4.1 ábrán látható, egy átfogó ML folyamat a következő lépésekből áll:
1. Adatbevitel
2. Modellképzés
3. Modelltesztelés
4. Modellcsomagolás
5. Modellregisztráció
A folyamat összes lépését megvalósítjuk az Azure ML szolgáltatás (felhőalapú) és MLflow

(nyílt forráskódú) egyidejű használatával az eltérő perspektíva érdekében. Az Azure ML és
MLflow egy erős páros az MLOps-nál: a 4.1 táblázatban látható jellemzőket mutatják be.
A lehetőségeik is egyediek, ahogy azt a következő táblázatban láthatjuk.
Átvesszük az ML folyamatok alapjait 81
4.1 táblázat: MLflow vs. Azure ML szolgáltatás

Az ML folyamat megvalósításához szükségünk van egy tároló erőforrásra az
adatkészleteinkhez és egy számítási erőforrásra az ML modelljeinkhez. Ahogy az
korábban megvitattuk a 2. fejezet: Az Ön gépi tanulási problémájának jellemzése részben,
végre fogjuk hajtani az ML folyamat és az üzleti probléma megvalósításához szükséges
számításokat, ahogy az a 4.2 táblázatban látható.
A helyi számítógépünkön vagy PC-n dolgozzuk fel az adatokat a kezdéshez és
előfeldolgozzuk az adatokat az ML tanításához. Az ML tanításához és a folyamat
megvalósításához a felhőben (Microsoft Azure) biztosított számítási erőforrásokat
használjuk. Bár az ML tanítása a folyamatnál elvégezhető lenne az Ön helyi számítógépén,
a felhőn lévő számítási erőforrásokat fogjuk használni, hogy megtanuljuk, hogyan kell
biztosítani és felhasználni a szükséges számítási erőforrásokat az ML folyamathoz.
4.3 ábra: A számítás helyszíne az adatoknál és ML feladatoknál

További késlekedés nélkül konfiguráljuk a szükséges számítási erőforrásokat az ML

folyamathoz a következő lépéseken keresztül:
1. Menjen az ML-je munkaterületére.
4.4 ábra: Azure Machine Learning munkaterület

2. Lépjen a Compute opcióra és kattintson a Create gombra, hogy megismerje a
felhőn elérhető számítási lehetőségeket.
3. Válassza ki a megfelelő számítási opciót az ML modell tanításához, hogy az
optimális és hatékony legyen.
Válasszon ki egy megfelelő számítási opciót a tanítási igényei és költségkorlátai

alapján, és nevezze el. Például a 4.4 ábrán egy számítást vagy virtuális gépet
választottunk ki a Standard_D1_v2 kísérlethez: ez egy 1 magos CPU, 3,5 GB RAM
és 50 GB tárhely. A javasolt gépkonfiguráció vagy méret kiválasztásához pipálja
ki a select from all options lehetőséget a Virtual machine size részen. A kívánt
virtuális gép konfigurációjának vagy méretének kiválasztása után kattintson
a Next gombra, hogy továbblépjen és a 4.5 ábrán bemutatott képet fogja látni.
4.5 ábra: Egy számítási erőforrás létrehozása egy Azure munkaterületen

Válasszon ki egy egyedi számítási nevet egy Azure régión belül (érdemes olyasmit
használni, mint unique_code-ml-compute1). A 4.4 ábrán kiválasztott
számítási opció az egyik legolcsóbb számítási opció és elegendő az ML folyamat
megvalósításához ennél az üzleti problémánál. Az ML modellek gyorsabb
megvalósításához és tanításához ajánlott a STANDARD_DS11_V2 (2 mag, 14 GB
RAM) virtuális gépméretet használni. Ezzel a lehetőséggel egy modell tanítása
nagyjából 12 percet fog igénybe venni.
4. Biztosítsa a korábban létrehozott számítási erőforrást. A szükséges számítási

erőforrás létrehozása és elnevezése után az Ön számítási erőforrása biztosított,
készen áll és fut a felhőn az ML tanításához, ahogy az a 4.6 ábrán látható.
4.6 ábra: Biztosított számítás egy AzureML munkaterületen

Miután biztosítottuk, válassza ki a JupyterLab opciót. A JupyterLab egy nyílt
forráskódú, webalapú felhasználói interfész. Olyan funkciói vannak, mint a
szövegszerkesztő, kódszerkesztő, terminál és egyedi összetevők bővíthető módon
integrálva. Ezt programozási interfészként használjuk, amelyet a biztosított
számításhoz csatlakoztattunk az ML modellek tanításához.
Most elkezdjük az ML folyamat gyakorlati megvalósítását. Kövesse ezeket a lépéseket az

ML folyamat megvalósításához:
1. A megvalósítás megkezdéséhet klónozza az adatraktárt, amelyet importált az

Azure DevOps projektjébe. Az adatraktár klónozásához kattintson a Clone gombra
a Repos menü jobb felső sarkában, majd kattintson a Generate Git Credentials
gombra. Létrejön egy hash jelszó.
4.7 ábra: Egy Azure DevOps Git tároló klónozása (Git hitelesítő adatok generálása)
2. Másolja ki a HTTPS linket a Command Line részen, hogy megkapja az Azure
DevOps adatraktár linket, például egy ilyet:
https://xxxxxxxxx@dev.azure.com/xxxxx/Learn_MLOps/_git/
Learn_MLOps
3. Másolja ki a jelszót, amelyet az 1. lépésben generáltunk és adja hozzá a linkhez

a 2. lépésből úgy, hogy hozzáadja a jelszót egyből az felhasználónév után, és válassza
el :-tal a @ karakter előtt. Ezután lehetséges a következő git clone parancs
használata engedélyhibák nélkül:
git clone https://user:password_hash@dev.azure.com/user/
repo_created
4. Amint futtatja a JupyterLab-ot, hozzá fogunk férni a terminálhoz, hogy klónozzuk

az adatraktárt az azure számításra. A terminál eléréséhez ki kell választania
a Terminal opciót a Launcher fülön. Egy másik módszer a terminál közvetlen
elérésére a Terminal link használata az Application URl oszlopból az Azure ML
munkaterületen lévő számítási példányok listájában. Menjen a JupyterLab Terminal
opciójára és hajtsa végre a következőt (ahogy a 4.8 ábrán látható):
git clone https://xxxxxxxxx@dev.azure.com/xxxxx/Learn_
MLOps/_git/Learn_MLOps
Itt a kimenet:
4.8 ábra: Klónozza az Azure DevOps Git adatraktárt az Azure számításon

5. Menjen a 04_MLpipelines mappába és kövesse a megvalósítási lépéseket az

ML-pipeline.ipynb fájlnál a klónozott adatraktárból. Az következő lépést az
ML-pipeline.ipynb fájlban hajtjuk végre. Ajánlott követni a fájl utasításait,
hogy jobban megértse a megvalósítást és Ön futtassa le a kódot egy új fájlban
a beállítása szerint.
Eddig biztosítottuk a számítási erőforrást és klónoztuk a GitHub adatraktárt
a számításon.
6. Következőként elkezdjük megvalósítani az ML-pipeline.ipynb fájlt a szükséges
könyvtárak importálásával, mint amilyen a pandas, numpy, azureml, pickle,
mlflow stb. ahogy a következő kódblokkban látható:
import pandas as pd
import numpy as np
import warnings
from math import sqrt
warnings.filterwarnings('ignore')
from azureml.core.run import Run
from azureml.core.experiment import Experiment
from azureml.core.workspace import Workspace
from azureml.core.model import Model
from azureml.core.authentication import
ServicePrincipalAuthentication
from azureml.train.automl import AutoMLConfig
import pickle
from matplotlib import pyplot as plt
from matplotlib.pyplot import figure
import mlflow
7. Következőként az MLflow telepítését használjuk (a kísérletek követéséhez).

Használja a get_mlflow_tracking_url() függvényt, hogy egy követési
ID-t kapjon ahhoz, hová kell naplózni az MLflow kísérleteket és tárgyakat (ebben
az esetben a biztosított tanítási számításhoz kapjuk meg a követési ID-t). Aztán
a set_tracking_uri() függvényt használjuk, hogy csatlakozzunk egy
követési URl-hez (egy adott erőforrás egységes erőforrásazonosítója) a biztosított
tanítási számításnál. A követő URl tartozhat egy távoli szerverhez, egy adatbázis
csatlakozási sztringhez vagy egy helyi útvonalhoz, hogy naplózza az adatokat
egy helyi könyvtárban. A mi esetünkben a követő URl a helyi útvonalra mutat
alapértelmezetten (a biztosított tanítási számításon):
uri = workspace.get_mlflow_tracking_uri( )
mlflow.set_tracking_uri(uri)
Az URl az mlruns mappát adja meg, ahová az MLflow tárgyakat és naplókat fogjuk
menteni a kísérletekhez.
A követési URl beállításával az MLflow kísérleteinél, Ön beállította az MLflow-nak
a tárgyak és naplók mentési helyét az mlruns mappában (a biztosított számításán).
Ezen parancsok végrehajtása után ellenőrizze az aktuális útvonalat. Meg fogja találni
az mlruns mappát.
Adatbevitel és funkciótervezés
Az adat létfontosságú az ML modellek tanításához; adatok nélkül nincs ML. Az adatbevitel
egy kapcsoló lépés az ML folyamatnál. Ez foglalkozik az adat mennyiségével,
gyorsaságával, pontosságával és változatosságával a különböző adatforrásokból történő
adat kinyerése által, és beviszi a szükséges adatot a modell tanításához.
Az ML folyamat az ML modellek tanításához megfelelő adatok bevitelével kezdődik. Azzal
kezdünk, hogy hozzáférünk az előző fejezetben regisztrált előfeldolgozott adatokhoz.
Kövesse ezeket a lépéseket, hogy hozzáférjen és importálja az előkészített adatokat és
készen álljon az ML tanítására:
1. A Workspace() függvény használatával az Azure ML SDK-nál, férjen hozzá

az adattárolók adataihoz az ML munkaterületen a következőképpen:
from azureml.core import Workspace, Dataset
subscription_id = 'xxxxxx-xxxxxx-xxxxxxx-xxxxxxx'
resource_group = 'Learn_MLOps'
workspace_name = 'MLOps_WS'
workspace = Workspace(subscription_id, resource_group,
workspace_name)
Adatbevitel és funkciótervezés 89
Megjegyzés
Írja be a saját hitelesítő adatait, mint amilyen a subscription_id,
resource_group és workspace_name és indítson el egy munkaterület
objektumot a hitelesítő adatok használatával.
Amikor sikeresen végrehajtotta ezeket az utasításokat a JupyterLab-ban, futtathatja

a hátralévő kódblokkokat a következő cellákban.
2. Importálja az előző fejezetben előkészített feldolgozott adatkészletet. Az előkészített
adatkészlet a .get_by_name() függvény használatával importálható az Azureml
SDK-ban található Dataset függvényből, és ez a függvény használatos a szükséges
adat visszakeresésére:
# Importing pre-processed dataset
dataset = Dataset.get_by_name (workspace,
name='processed_weather_data_portofTurku')
print(dataset.name, dataset.version)
3. Az adatkészlet sikeres visszakeresésekor vagy csatlakoztatásakor megerősítheti

a dataset.name és dataset.version kiírásával, amely ki kell írja a
processed_weather_data_portofTurku 1 szöveget vagy azt a nevet,
amelyet korábban adott az adatkészletnek.
4. Az előkészített adatok visszakeresése után, fontos azt felosztani tanítási és validációs
készletekre annak érdekében, hogy az ML modellt betanítsa és tesztelje vagy
értékelje a tanítási fázisban és a későbbi szakaszokban. Így felosztjuk tanítási és
validációs készletekre 80% (tanítási készlet) és 20% (tesztelési készlet) arányban a
következőképpen:
df_training = df.iloc[:77160]
df_test = df.drop(df_training.index)
df_training.to_csv('Data/training_data.csv',index=False)
df_test.to_csv('Data/test_data.csv',index=False)
5. Miután sikeresen felosztotta az adatokat, ezt a két adatkészletet tároljuk és

regisztráljuk az adattárolóban (az Azure ML munkaterülethez csatlakoztatva)
datastore = workspace.get_default_datastore()
datastore.upload(src_dir='Data', target_path='data')
training_dataset = /
Dataset.Tabular.from_delimited_files(datastore.
path('data/training_data.csv'))
validation_dataset = /
Dataset.Tabular.from_delimited_files(datastore.
path('data/validation_data.csv'))
training_ds = training_dataset.
register(workspace=workspace, name='training_dataset',
description='Dataset to use for ML training')
test_ds = validation_dataset.register(workspace=workspace,
name='test_dataset',
description='Dataset for validation ML models')
A register() függvény használatával képesek vagyunk regisztrálni a tanítási

és tesztelési adatkészleteket, amelyek később importálhatók az adattárolóból.
Következőként importáljuk a tanítási adatokat és bevisszük az ML folyamatba, és később
használjuk fel a tesztelési adatkészletet a modell teljesítményének tesztelésére a nem
látható adatokon a termelésben vagy a modell elemzéséhez.
Adatbevitel (tanítási adatkészlet)

A tanítási adat ML folyamatba történő beviteléhez az importálásával kezdjük a get_
by_name() függvény használatával, és átalakítjuk egy pandas adatszerkezetté a to_
pandas_dataframe() függvény használatával:
dataset = Dataset.get_by_name (workspace, name='training_

dataset')
print(dataset.name, dataset.version)
df = dataset.to_pandas_dataframe ( )
Most visszakerestük a tanítási adatkészletet és fel fogjuk használni az ML modellek

további tanításához. A cél osztályozó modelleket tanítani annak megjóslására, hogy
fog-e esni vagy sem. Így válasszuk ki a Temperature, Humidity, Wind_speed,
Wind_bearing, Visibility, Pressure és Current_weather_conditions
jellemzőket a bináris osztályozó modellek tanításához, hogy megjósoljuk a jövőbeni
(4 órával előre) időjárási körülményeket.
Adatbevitel és funkciótervezés 91
Kövesse ezeket a lépéseket, hogy kiválassza a jellemzőket és méretezze őket:
1. Az ML modellek tanítása előtt kulcsfontosságú a megfelelő jellemzők kiválasztása

és az adatok méretezése. Ezért a következőképpen választjuk ki a jellemzőket.
Az X változóban lévő értékek független változókat képviselnek és az Y változó
a függő változó (előrejelzett időjárás):
X = df[['Temperature_C', 'Humidity', 'Wind_speed_kmph',
'Wind_bearing_degrees', 'Visibility_km', 'Pressure_
millibars', 'Current_weather_condition']].values
y = df['Future_weather_condition'].values
2. Osszuk fel a tanítási adatokat tanítási és tesztelési készletekre (a tanítás

validációjához a tanítás után) a train_test_split() függvény használatával
az sklearn-ből. Szükség van a véletlenszámgenerátor kezdőértékének (random_
state) rögzítésére, hogy reprodukáljunk egy tanítási munkaegységet azáltal,
hogy megtartjuk a mintákat az előző kísérletből ugyanazzal a konfigurációval.
Így a random_state=1 opciót fogjuk használni:
# Splitting the Training dataset into Train and Test set
for ML training
from sklearn.model_selection import train_test_split
X_train, X_val, y_train, y_val = train_test_split(X, y,
test_size=0.2, random_state=1)
Egy 80% (tanítási adat) és 20% (tesztelési adat) felosztással a tanítási és tesztelési
adatkészletek már készek a jellemzők méretezésére és az ML modell tanítására.
3. Ahhoz, hogy az ML modell tanítása optimális és hatékony legyen, adatok egyforma
léptékűek kell legyenek. Ezért méretezzük az adatokat a StandardScalar()
funkció használatával az sklearn-ből, hogy kalibráljuk az adatokban lévő
numerikus értékeket ugyanarra a léptékre:
from sklearn.preprocessing import StandardScaler
sc = StandardScaler()
X_train = sc.fit_transform(X_train)
X_val = sc.transform(X_val)
Ezzel a lépéssel a tanítási adatok numerikus értékeit méreteztük a

StandardScalar használatával és az összes értéket átalakítottuk a -1 és 1
közötti tartományba az X_train values alapján. Most már kész vagyunk az ML
modellek tanítására (a mókás rész)!
Gépi tanulás tanítása és hiperparaméter

optimalizáció
Most már készen állunk a mókás részre, az ML modellek tanítására! Ez a lépés teszi
lehetővé a modelltanítást; moduláris szkriptekkel vagy kóddal rendelkezik, amely
végrehajtja az összes hagyományos lépést az ML tanításánál, mint amilyen az adat
illesztése és átalakítása a modell tanításához és a hiperparaméter hangolásához a legjobb
modell konvergálásához. Ennek a lépésnek a kimenete egy betanított ML modell.
Az üzleti probléma megoldásához két jól ismert modellt fogunk betanítani
a Support Vector Machine osztályozó és a Random Forest osztályozó használatával.
A népszerűségük és konzisztens eredményeik alapján választottuk ezeket; Ön szabadon
választhat más modelleket is, nincsenek korlátozások ebben a lépésben. Először a Support
Vector Machine osztályozót fogjuk betanítani, majd a Random Forest osztályozót.
Support Vector Machine

A Support Vector Machine (SVM) egy népszerű felügyelt tanulási algoritmus
(osztályozáshoz és regresszióhoz használják). Az adatpontokat hipersíkok használatával
osztályozzák egy N-dimenziós térben. Közismert, hogy kiemelkedő pontosságot produkál
kevesebb számítási kapacitással. Érdemes elméletben megismerni az SVM-et, hogy jobban
megértse a modell tanítását a gyakorlatban. Ahhoz, hogy jobban megismerje az SVM-et,
nézzen el ide: https://www.kdnuggets.com/2017/02/yhat-support-
vector-machine.html.
Kezdjük az SVM osztályozó tanításával:
1. Azzal kezdjük, hogy elindítjuk a tanítást vagy kísérletet az Experiment()

függvény használatával az Azure SDK-ból. Ezen függvény célja, hogy elindítson egy
tanulási menetet vagy kísérletet a modell tanítási teljesítményének monitorozása és
naplózása érdekében az Azure ML munkaterületen:
myexperiment = Experiment(workspace, "support-vector-
machine")
2. Hasonlóképpen az MLflow kísérletet is elindítjuk, hogy megvizsgáljunk egy másik

perspektívát:
mlflow.set_experiment("mlflow-support-vector-machine")
Így már elindítottunk egy kísérletet mind az Azure ML munkaterületen, mind az

MLflow-ban. A következő tanítási lépést fogjuk monitorozni és naplózni.
Gépi tanulás tanítása és hiperparaméter optimalizáció 93
3. Következőként hangoljuk a hiperparamétert, hogy a legjobb paramétereket találjuk

meg a legjobb modell konvergálásához. Ez végezhető manuálisan, de léteznek
olyan hatékonyabb és automatikus megoldások, mint például a Grid Search vagy
a Random Search. A tanításhoz az SVM osztályozó a Grid Search-öt használja
a következőképpen. Az SVC() és Grid SearchCV() függvények használatával
folytatjuk az sklearn-ből és naplózzuk a futást az Azure ML-en és MLflow-on:
from sklearn.svm import SVC
from sklearn import svm
from sklearn.model_selection import GridSearchCV
parameters = {'kernel':('linear', 'rbf'), 'C':[1, 10]}
svc = svm.SVC( )
# initialize a run in Azureml and mlflow experiments
run = myexperiment.start_logging()
mlflow.start_run()
run.log("dataset name", dataset.name)
run.log("dataset Version", dataset.version)
svc_grid = GridSearchCV(svc, parameters)
svc_grid.fit(X_train, y_train)
Ennek a futtatásnak vagy kísérletnek a célja, hogy a legjobb SVM modellt tanítsa
be a legjobb paraméterekkel. A Grid Search a különböző paraméterkombinációk
tesztelésére és az algoritmus konvergenciájának optimalizálására használatos
a legjobb teljesítmény érdekében. A Grid Search-nek kell némi idő a futáshoz
(nagyjából 15 perc a STANDARD_DS11_V2 (2 mag, 14 GB RAM) számítógépen).
A Grid Search eredménye vagy kimenete az ajánlja, hogy a legjobban teljesítő
paraméterek legyenek C=1 és a kernel az rbf. A run.log() használatával
naplóztuk a modell tanításához használt adatkészletet (a tanítási készlet) és követtük
a kísérletet. Ezt az adatot az Azure ML munkaterület és az MLflow kísérletekben
naplóztuk.
4. Végül a legjobb paraméterek használatával egy új modellt tanítottunk be a C=1
és kernel='rbf' felhasználásával a következőképpen:
svc = SVC(C=svc_grid.get_params(deep=True)
['estimator__C'], kernel=svc_grid.get_params(deep=True)
['estimator__kernel'])
svc.fit(X_train, y_train)
# Logging training parameters to AzureML and MLFlow
experiments
run.log("C", svc_grid.get_params(deep=True)
['estimator__C'])
run.log("Kernel", svc_grid.get_params(deep=True)
['estimator__kernel'])
After training the SVC classifier, the following output
is shown:
SVC(C=1.0, cache_size=200, class_weight=None, coef0=0.0,
decision_function_shape='ovr', degree=3, gamma='auto_
deprecated',
kernel='rbf', max_iter=-1, probability=False, random_
state=None,
shrinking=True, tol=0.001, verbose=False)
Ezzel betanítottuk az SVM modellt! Most a Random Forest osztályozó modellt

fogjuk betanítani.
Random Forest osztályozó

A Random Forest egy másik népszerű felügyelt tanulási modell (osztályozáshoz és
regresszióhoz használják). A Random Forest egy együttes tanulási módszer, amely több
döntési fával működik. A modell tanításának végrehajtása előtt ajánlott megismerni
a Random Forest modell elméleti működését. Ahhoz, hogy jobban megismerje a Random
Forest modellt, látogasson el a https://www.kdnuggets.com/2020/01/random-
forest-powerful-ensemble-learning-algorithm.html oldalra.
1. A Random Forest osztályozó tanításának megkezdéséhez indítsa el a kísérletet

az Azure ML munkaterületen és az MLflow kísérletet a következőképpen:
myexperiment = Experiment(workspace, "support-vector-
machine")
mlflow.set_experiment("mlflow-support-vector-machine")
2. A kísérlet sikeres elindítása után, megkezdhető a tanítás

a RandomForestClassifier() függvény importálásával az sklearn.
ensemble-ből és a függvény meghívásával a szükséges paraméterekkel,
amely a következőképpen néz ki. Ezeket a paramétereket véletlenszerűen
választjuk ki (nem használjuk a Grid Search-öt). A Grid Search vagy
RandomizedSearch használható a legjobb paraméterek meghatározásához
és az algoritmus optimalizálásához:
from sklearn.ensemble import RandomForestClassifier
rf = RandomForestClassifier (max_depth=10, random_
state=0, n_estimators=100)
Gépi tanulás tanítása és hiperparaméter optimalizáció 95
3. A modell tanítását a fit(X_train, y_train) függvény használatával

végezzük, és átadjuk neki a tanítási adatokat. A tanítási adatkészletet
és paramétereket az Azure ML és az MLflow kísérletekben naplóztuk
# initialize runs in Azureml and mlflow
run = myexperiment.start_logging()
mlflow.start_run()
# Log dataset used
run.log("dataset name", dataset.name)
run.log("dataset Version", dataset.version)
rf.fit(X_train, y_train)
# Logging training parameters to AzureML and MLFlow
experiments
run.log("max_depth", 10)
run.log("random_state", 0)
run.log("n_estimators", 100)
4. A tanítás után a kimenet a következőképpen néz ki:

RandomForestClassifier(bootstrap=True, class_weight=None,
criterion='gini',
max_depth=10, max_features='auto', max_leaf_nodes=None,
min_impurity_decrease=0.0, min_impurity_split=None,
min_samples_leaf=1, min_samples_split=2,
min_weight_fraction_leaf=0.0, n_estimators=100, n_
jobs=None,
oob_score=False, random_state=0, verbose=0, warm_
start=False)
Ez az elvárt eredmény, amikor befejezzük a Random Forest modell tanítását.

Ezzel sikeresen befejezte a Random Forest modell tanítását, és összességében két
ML modellét: az SVM osztályozóét és a Random Forest osztályozóét.
A tanítás után kulcsfontosságú a modell teljesítményének tesztelése a pontosság
és mérőszámok tekintetében, hogy tudjuk, a modell megfelel-e a termelésnek vagy
tesztelési környezetnek.
Következőként teszteljük a tanított modellek teljesítményét a tesztadatokkal, amelyet

a modellek tanítása előtt felosztottunk.
Modell tesztelése és mérések meghatározása

Ebben a lépésben kiértékeljük a tanított modell teljesítményét egy elkülönített
adatpontkészlettel, amelyet tesztadatoknak nevezünk (ezt osztottuk fel és láttuk
el verzióval korábban az adatbevitel lépésnél). A tanított modell következtetését
a felhasználási módnak megfelelően kiválasztott mérések szerint értékeljük.
Ennek a lépésnek a kimenete egy jelentés a tanított modell teljesítményéről.
A modell teljesítményének átfogó elemzéséhez mérni fogjuk a pontosságot, precizitás,
újrahívást és f-pontszámot. Ezt értik a gyakorlatban az üzleti probléma kontextusa alatt:
• Pontosság: A helyes előrejelzések száma az adat tesztmintákból végzett összes

előrejelzés számának arányában.
• Precizitás: A precizitás a pozitívok arányát méri, amelyeket helyesen jelzett előre
pozitívként. Precizitás = Igaz pozitívok / (Igaz pozitívok + Hamis pozitívok)
• Újrahívás: Az újrahívás a tényleges pozitívok arányát méri, amelyeket helyesen
azonosított. Újrahívás = Igaz pozitívok / (Igaz pozitívok + Hamis negatívok)
• F-pontszám: A precizitást és az újrahívást is figyelembe vesszük az f-pontszám
számításakor. Ez a precizitás és újrahívás harmonikus közepe (átlaga). F1 pontszám
= 2*(Újrahívás * Precizitás) / (Újrahívás + Precizitás)
Mérni fogjuk ezeket a mérőszámokat a betanított modellnél a validációs adatkészleten.

Nézzük meg az SVM osztályozó és a Random Forest osztályozó eredményeit.
Az SVM osztályozó tesztelése

Az sklearn.metrics használatával kiszámítjuk a pontosságot, f1-pontszámot,
precizitást és újrahívást a modell teljesítménynél a tesztelési adatmintákon és
naplózzuk őket az Azure ML munkaterületen és az MLflow kísérletekben a run.log()
függvény használatával a következőképpen.
A sklearn.metrics-ből importáljuk az accuracy_score, f1_score,
precision_score, és recall_score opciókat:
predicted_svc = svc.predict(X_test)
acc = accuracy_score(y_test, predicted_svc)
fscore = f1_score(y_test, predicted_svc, average="macro")
precision = precision_score(y_test, predicted_svc,
average="macro")
Modellcsomagolás 97
recall = recall_score(y_test, predicted_svc, average="macro")

run.log("Test_accuracy", acc)
run.log("Precision", precision)
run.log("Recall", recall)
run.log("F-Score", fscore)
run.log("Git-sha", sha)
A tesztadat mérések eredményeit az Azure ML munkaterületen kísérletként naplóztuk.

Ezeket a naplókat később elolvashatja a modell regisztrációja után (a Modellek
regisztrációja és termelési tárgyak részben fogjuk regisztrálni a modellt).
A Random Forest osztályozó tesztelése

Ahhoz hasonlóan, amit az SVM osztályozó modellel tettünk, az sklearn.metrics
használatával kiszámítjuk a pontosság, f1-pontszám, precizitás és újrahívás
értékeket:
acc = accuracy_score(y_test, predicted_rf)

fscore = f1_score(y_test, predicted_rf, average="macro")
precision = precision_score(y_test, predicted_rf,
average="macro")
recall = recall_score(y_test, predicted_rf, average="macro")
run.log("Test_accuracy", acc)
run.log("Precision", precision)
run.log("Recall", recall)
run.log("F-Score", fscore)
run.log("Git-sha", sha)
A modell teljesítménymérések kimenete a tesztelési adatmintákon az Azure ML

munkaterületen és az MLflow kísérletekben kerül naplózásra a run.log() függvény
használatával.
Modellcsomagolás
Miután teszteltük az előző lépésben a betanított modellt, a modell szerializálható egy
fájllá, hogy exportálják a tesztelési vagy termelési környezetbe. A szerializált fájlok
kompatibilitási kihívásokkal járnak, mint amilyen a modell együttműködési képessége,
ha nem jól csinálják. A modell együttműködési képessége kihívás, különösen, amikor
a modelleket eltérő keretrendszerek használatával tanítják. Például ha az 1. modellt az
sklearn használatával tanították, és a 2. modellt a TensorFlow használatával tanították,
akkor az 1. modell nem importálható vagy exportálható a TensorFlow használatával
a modell további finomhangolásához vagy következtetéséhez.
A probléma elkerüléséhez az ONNX egy nyílt szabványt kínál a modell együttműködési

képességéhez. Az ONNX jelentése Open Neural Network Exchange (Nyílt neurális háló
csere). Egy szerializációs szabványt biztosít a modellek importálásához és exportálásához.
Az ONNX formátumot fogjuk használni a modellek szerializálásához, hogy elkerüljük az
kompatibilitási és együttműködési képességgel kapcsolatos problémákat.
Az ONNX használatakor a betanított modellt az skl2onnx könyvtár használatával
szerializáljuk. A modellt svc.onnx fájlként szerializáltuk ahhoz, hogy a modellt
importálhassuk és exportálhassuk a tesztelési és termelési környezetekbe:
# Convert into SVC model into ONNX format file

from skl2onnx import convert_sklearn
from skl2onnx.common.data_types import FloatTensorType
initial_type = [('float_input', FloatTensorType([None, 6]))]
onx = convert_sklearn(svc, initial_types=initial_type)
with open("outputs/svc.onnx", "wb") as f:
f.write(onx.SerializeToString())
Ennek a kódnak a kimenete egy szerializált svc.onnx fájl. Ehhez hasonlóan az ONNX
használatával konvertálni fogjuk a Random Forest modellt is egy rf.onnx nevű
szerializált fájllá, hogy a modellt importálhassuk és exportálhassuk a tesztelési és termelési
környezetekbe:
# Convert into RF model into ONNX format file

from skl2onnx import convert_sklearn
from skl2onnx.common.data_types import FloatTensorType
initial_type = [('float_input', FloatTensorType([None, 6]))]
onx = convert_sklearn(rf, initial_types=initial_type)
with open("outputs/rf.onnx", "wb") as f:
f.write(onx.SerializeToString())
Ennek a kódnak a kimenete egy szerializált rf.onnx fájl. Következőként regisztráljuk

ezeket a szerializált modelleket a modelljegyzékbe.
Modellek és termelési tárgyak regisztrációja

Ebben a lépésben az előző lépésben szerializált vagy konténerizált modellt regisztráljuk
és tároljuk a modelljegyzékben. A regisztrált modell egy vagy több fájl logikus tárolóként
történő fordítása, amely modellként működik. Például egy több fájlból álló modell
regisztrálható egyetlen modellként a modelljegyzékben. A regisztrált modell letöltésével
az összes fájl megkapható. A regisztrált modell igény szerint telepíthető és felhasználható
a következtetéshez.
Modellek és termelési tárgyak regisztrációja 99
Regisztráljuk az előző részben szerializált modelljeinket a model .register()

függvény használatával az Azure ML SDK-ból. Ennek a függvénynek a használatával
a szerializált ONNX fájlt regisztráljuk a munkaterületen a további felhasználáshoz és
a telepítéshez a tesztelési és termelési környezetben. Regisztráljuk a szerializált SVM
osztályozó modellt (svc.onnx):
# Register Model on AzureML WS

model = Model.register (model_path = './outputs/svc.onnx', #
this points to a local file
model_name = "support-vector-classifier",
tags = {'dataset': dataset.name, 'version': dataset.
version, 'hyparameter-C': '1', 'testdata-accuracy': '0.9519'},
model_framework='pandas==0.23.4',
description = "Support vector classifier to predict
weather at port of Turku",
workspace = workspace)
print('Name:', model.name)
print('Version:', model.version)
A modellt igény szerinti elnevezéssel és címkézéssel regisztráljuk. Megerősíthetjük

a modell sikeres regisztrációját, ha ellenőrizzük a regisztrált modell nevét és verzióját.
A kimenet vissza fogja adni a regisztrációnál használt modellnevet (például support-
vector-classifier) és megmutatja a modell verzióját, például 1. Ehhez hasonlóan
regisztráljuk a szerializált Random Forest osztályozó modellt (rf.onnx):

model = Model.register (model_path = './outputs/rf.onnx', #
model_name = "random-forest-classifier",
tags = {'dataset': dataset.name, 'version': dataset.
version, 'hyparameter-C': '1', 'testdata-accuracy': '0.9548'},
description = "Random forest classifier to predict
weather at port of Turku",
print('Name:', model.name)
print('Version:', model.version)
A modell sikeres regisztrációja után a print függvény kimenete vissza fogja adni
a regisztrációnál használt modellnevet (random-forest-classifier) és megmutatja
a modell verzióját, például 1. Végül regisztráljuk a termelési tárgyakat a következtetéshez.
Most láthatja minkét modellt az Azure ML munkaterület Models részén, ahogy
4.9 ábra: Regisztrált SVM modell (teszteredményekkel)

Így vizualizálhatja és elemezheti a tanítási és tesztelési naplóit az Azure ML
munkaterületen tanított egyes modelleknél. Ez közvetlen rátekintést kínál a modell
tanítására és tesztelésére, miközben lehetővé teszi a regisztrált modellek követhetőségét.
Termelési tárgyak regisztrációja

A valós idejű modellkövetkeztetéshez szükség van egy méretezőre a skálán bejövő
adatok méretezéséhez, ahol az adatokat méretezték az ML tanításához. Ugyanazt
a méretező függvényt fogjuk használni a scaling X_train-hez az sc.fit_
transform(X_train) használatával és ezen változó pickle fájllá történő
szerializálásához. Végül regisztráljuk ezt a pickle fájlt a munkaterületen a további
igény szerinti felhasználáshoz és visszakereséshez (különösen a modellkövetkeztetésnél
a tesztelési és termelési környezetben). A pickle használatával írja az sc
méretező változót egy pickle fájlba a pickle.dump() függvény használatával
a következőképpen.
Importálja a pickle fájlt az open('./outputs/scaler.pkl', 'wb') as
scaler_pkl használatával:
pickle.dump(sc, scaler_pkl)
Modellek és termelési tárgyak regisztrációja 101
A kód kimenete egy szerializált pickle fájlt fog elmenteni a méretező számára
a scaler.pkl néven. Következőként regisztrálni fogjuk ezt fájlt a modellregisztrációhoz,
hogy később a modelljeinkkel együtt töltsük le és telepítsük a következtetéshez.
A méretező regisztrációja a model .register() függvény használatával történik

scaler = Model.register(model_path = './outputs/scaler.pkl', #
model_name = "scaler", # this is the name the model
is registered as
tags = {'dataset': dataset.name, 'version':
dataset.version},
description = "Scaler used for scaling incoming
inference data",
print('Name:', scaler.name)
print('Version:', scaler.version)
A méretező objektum regisztrációjával és mentésével egy regisztrált objektum az Azure

ML munkaterületen található. Ehhez hasonlóan a regisztrált modellek nyomonkövethetők,
ahogy az látható a 4.10 ábrán:
4.10 ábra: Regisztrált modellek

Gratulálunk! Mind az SVM osztályozó, mind a Random Forest osztályozó, a szerializált

méretezővel együtt regisztrálva lett a modelljegyzékben. Ezek modellek később letölthetők
és telepíthetők. Ezzel elértünk az ML folyamat sikeres megvalósításához!
Összefoglalás
Ebben a fejezetben átvettük az ML folyamatok elméletét és gyakoroltuk őket az ML
folyamatok kialakításával egy üzleti probléma esetében. Beállítottuk az eszközöket,
erőforrásokat és a fejlesztési környezetet az ML modellek tanításához. Az adatbeviteli
lépéssel kezdtük, amelyet a modell tanítási, tesztelési és csomagolási lépése követett
és végül befejeztük a regisztráló lépést. Gratulálok! Idáig megvalósította az MLOps
munkafolyamat egy kritikus építőelemét.
A következő fejezetben megnézzük a termelési modellek értékelését és csomagolását.
5
Modellértékelés és
csomagolás
Ebben a fejezetben részletesen fogunk tanulni az ML modellek értékeléséről és
értelmezhetőségi méréseiről. Ez lehetővé teszi számunkra, hogy átfogóan megismerjük
az ML modellek teljesítményét a tanításuk után. Arról is tanulunk majd, hogyan kell
csomagolni és telepíteni a modelleket a további felhasználáshoz (mint amilyenek
a termelési rendszerek). Részletes megvizsgáljuk, hogyan értékeltük és csomagoltuk
a modelleket az előző fejezetben és felderítjük a modellek értékelésének és magyarázásának
új módjait, hogy biztosítsuk a betanított modellek átfogó ismeretét és a potenciális
felhasználhatóságukat a termelési rendszerekben.
104 Modellértékelés és csomagolás
Azzal kezdjük ezt a fejezetet, hogy a modellteljesítmény mérésének, értékelésének

és fordításának különböző módjairól tanulunk. Többféleképpen nézzük meg
a modellek tesztelését a termeléshez és az ML modellek csomagolását a termeléshez
és következtetéshez. Végre fogjuk hajtani az ML modellek értékelésének mélyreható
vizsgálatát, ahogy bemutatjuk a keretrendszert, amellyel bármilyen ML modell értékelhető
és csomagolható a termeléshez. Készüljön fel egy szilárd alap kialakítására az ML
modellek értékelése és termelési felkészítése tekintetében. Ehhez ebben a fejezetben
a következő fő témákat érintjük:
• Modellértékelés és értelmezhetőségi mérések

• Termeléstesztelési módszerek
• Miért kell csomagolni az ML modelleket?
• Hogyan kell csomagolni az ML modelleket?
• Következtetéskész modellek
Modellértékelés és értelmezhetőségi mérések

Az adatok megszerzése és az ML modellek tanítása egy jó kezdés az üzleti érték teremtése
felé. A modellek tanítása után fontos mérni a modell teljesítményét és megérteni, egy
modell miért és hogyan jósol vagy teljesít egy bizonyos módon. Így modellértékelés
és értelmezhetőség fontos részei az MLOps munkafolyamatnak. Ezek teszik lehetővé,
hogy megértsük és validáljuk az ML modelleket, hogy meghatározzuk, mekkora üzleti
értéket fognak produkálni. Mivel számos ML modelltípus van, ezért sokféle az értékelési
technika is.
Tekintsünk vissza 2. fejezet: Az Ön gépi tanulási problémájának jellemzése részre, ahol
a különböző modelltípusokat vizsgáltuk, és tanulási modellekként, hibrid modellekként,
statisztikai modellekként és HITL (Human-in-the-loop) modellekként kategorizáltuk
őket, most a különböző méréseket vitatjuk meg, hogy kiértékeljük ezeket a modelleket.
Itt van néhány főbb modellértékelési és értelmezhetőségi technika, ahogy az látható
az 5.1 ábrán. Ezek váltak szabvánnyá a kutatásban és az iparban a modellteljesítmény
értékelésére és igazolására:
Modellértékelés és értelmezhetőségi mérések 105
5.1 ábra: A modellértékelés és értelmezés rendszertana

(A technikák ebben a rendszertanban alkalmazhatók szinte bármely üzleti problémára, ha gondosan
választják ki, irányítják és hajtják végre.)
Tanulási modellek mérései

Két típusú tanulási modell van: felügyelt tanulás (a felügyelt tanulási modelleket vagy
algoritmusokat címkézett adatok alapján tanítják) és felügyelet nélküli tanulás (a felügyelet
nélküli tanulási modellek vagy algoritmusok képesek címkézetlen adatokból tanulni).
Ahogy az előző fejezetben megvizsgáltuk, a felügyelt tanulási algoritmusok példái

magukba foglalják az osztályozási (random forest, support vector machine stb.)
és regressziós (lineáris regresszió, logisztikai regresszió stb.) algoritmusokat. Másrészt
a felügyelet nélküli tanulás példái magukba foglalják a klaszterező (k-átlagok, DBSCAN,
kevert Gauss-modell stb.) és dimenziócsökkentéses (PCA, random forest, forward and
backward feature elimination stb.) algoritmusokat. Ezen algoritmusok hatékony mérése
érdekében következzen néhány példa a gyakran használt és hatékony mérésekre.
Felügyelt tanulási modellek

A felügyelt tanulási modelleket címkézett adatokkal tanítják. A tanítási adatokban a bemenet
eredménye jelölt vagy ismert. Így egy modellt arra tanítanak, hogy megjósolja a kimenetelt,
amikor a címkézett adatokon alapuló bemenetet kap. A modell tanítása után fontos mérni a
modell teljesítményét és potenciálját. itt van néhány mérés a felügyelt tanulási modellekhez.
Keresztvalidálás
Egy ML modell értékelése fontos ahhoz, hogy megértsük a viselkedését és trükkös lehet.
Általában két alkészletre osztjuk az adatkészletet: a tanítási és a tesztelési készletekre.
Először a tanítási készletet használjuk fel a modell betanításához, aztán a tesztelési
készletet a modell teszteléséhez. Ezután értékeljük a modell teljesítményét, hogy
meghatározzuk a hibát, olyan mérések használatával mint a modell pontossági százaléka
a tesztadatokon.
Ez a módszertan nem megbízható és átfogó, mert az egyik tesztkészlet pontossága
eltérhet egy másik tesztkészletétől. Ezen probléma elkerülésére a keresztvalidálás biztosít
megoldást az adatkészlet fragmentálásával vagy csoportokra osztásával, és biztosítja, hogy
mindegyik csoportot felhasználják valamikor tesztkészletként, ahogy az 5.2 ábrán látható:
5.2 ábra: K-csoportos keresztvalidálás

Több keresztvalidálási módszer van, beleértve a rétegezett keresztvalidálást, egyet kihagyó

keresztvalidálást és a K-csoportos keresztvalidálást. A K-csoportos keresztvalidálás
széleskörűen használatos és érdemes megjegyezni, mivel ez a technika magába foglalja az
adatkészlet felosztását k csoportokra/részletekre, aztán felhasznál minden egyes csoportot
tesztelési készletként az egymást követő iterációknál. Ez a folyamat hasznos, mert minden
iterációnak egyedi tesztkészlete van, amelyen a pontosságot mérjük. Aztán az egyes
iterációk pontosságát arra használjuk, hogy megtaláljuk az átlagos teszteredményeket
(a kiszámításához egyszerűen vesszük az összes teszteredmény átlagát).
A keresztvalidálással meghatározott átlagos pontosság egy megbízhatóbb és átfogóbb
mérés, mint a hagyományos pontosságmérés. Például az 5.2 ábrán öt iterációt láthatunk.
Ezen iterációk mindegyike egyedi tesztkészlettel rendelkezik, és az egyes iterációk
pontosságának tesztelésével és a pontosságok átlagolásával kapunk egy átlagos pontosságot
a modellhez a K-csoportos keresztvalidálás használatával. Érdemes megjegyezni, hogy
a K-csoport nem jó választás, ha nagyon nagy a tanítási adatkészlet vagy ha a modell nagy
mennyiségű időt, CPU és/vagy GPU feldolgozást igényel a futáshoz.
Precizitás
Amikor egy osztályozót betanítottak, a precizitás egy lényeges mérés lehet a pozitív
osztályú jóslások számszerűsítésénél, amelyek valójában igazak és a pozitív osztályhoz
tartoznak. A precizitás számszerűsíti a helyes pozitív előrejelzések számát.
Például mondjuk, hogy betanítottunk egy osztályozót, hogy határozza meg a macskákat és
kutyákat a képek alapján. Amikor a betanított modell a tesztképeken végez következtetést,
a modellt a kutyák előrejelzésére/észlelésére használjuk a képeknél (más szóval a kutyák
a pozitív osztály). A precizitás ebben az esetben számszerűsíti a helyes kutya előrejelzések
számát (pozitív előrejelzések).
A precizitás a helyesen jelzett pozitív példák és az összes észlelt pozitív példa arányaként
számítható.
Precizitás = Igaz pozitívok / (Igaz pozitívok + Hamis pozitívok)
A precizitás a hibás pozitívok minimalizálására fókuszál. A magas precizitás a 0 és 1
közötti tartományba esik, és a hibás pozitívok alacsony arányával van összefüggésben.
Minél magasabb a precizitás, annál jobb; például egy képosztályozó modell, amely
megjósolja, hogy egy rákos beteg igényel-e kemoterápiás kezelést. Ha a modell azt jósolja,
hogy egy betegnek kemoterápiát kellene kapnia, amikor ténylegesen nincs rá szükség, az
nagyon káros lehet, mivel a kemoterápia hatásai károsak lehetnek, ha nincs rá szükség.
Ez az eset egy veszélyes hibás pozitív. A magasabb precizitási pontszám kevesebb hibás
pozitívot eredményez, miközben egy alacsony precizitási pontszám a hibás pozitívok
magasabb számát eredményezi. Így a kemoterápiás kezelés esetében a jósló modellnek
magas precizitási pontszámmal kell rendelkeznie.
Újrahívás
Amikor egy osztályozót betanítottak, az újrahívás felhasználható a pozitív osztályú
jóslások számszerűsítésére, az adatkészletben lévő pozitív példák összessége alapján.
Az újrahívás a helyesen jelzett pozitívok számát méri az összes elérhető pozitív jóslás
számához viszonyítva. Az újrahívás megadja kihagyott pozitív jóslásokat a precizitással
szemben, amely csak a helyesen jelzett pozitívok számát árulja el az összes pozitív jóslás
számához viszonyítva.
Például vegyük a korábbi példát, ahol betanítottunk egy osztályozót, hogy határozza
meg a macskákat és kutyákat a képek alapján. Amikor a betanított modell a tesztképeken
végez következtetést, a modellt a kutyák előrejelzésére/észlelésére használjuk a képeknél
(más szóval a kutyák a pozitív osztály). Az újrahívás ebben az esetben számszerűsíti
a hiányzó kutya előrejelzések számát (pozitív előrejelzések).
Ilyen módon az újrahívás a pozitív osztály lefedettségének empirikus jelölése.
Újrahívás = Igaz pozitívok / (Igaz pozitívok + Hamis negatívok)
Az újrahívás a hibás negatívok minimalizálására fókuszál. A magas újrahívás alacsony
hibás negatív aránnyal van összefüggésben. Minél magasabb az újrahívás, annál
jobb. Például egy modell, amely a profiladatokat elemzi egy utasnál egy repülőtéren,
hogy megjósolja, az utas potenciális terrorista-e. Ebben az esetben biztonságosabbak
a hibás pozitívok, mint a hibás negatívok. Ha a modell azt jósolja, hogy egy ártatlan
személy terrorista, az leellenőrizhető a következő mélyebb vizsgálatnál. De ha egy
terrorista átmegy, számos élet kerülhet veszélybe. Ebben az esetben a hibás negatívok
biztonságosabbak, mint a hibás pozitívok, mivel a hibás negatívok ellenőrizhetők egy
mélyebb kivizsgálás segítségével. A újrahívásnak magasnak kell lennie a hibás negatívok
elkerüléséhez. Ebben az esetben a magas újrahívási pontszám előnyt élvez a magas
precizitással szemben.
F-pontszám
Olyan esetben, amikor el kell kerülnünk mind a magas hibás pozitívokat, mind a magas
hibás negatívokat, az f-pontszám egy hasznos mérés ennek eléréséhez. Az f-mérték
lehetőséget biztosít rá egyesítsük a precizitást és az újrahívást egyetlen mérőszámmá,
amely mindkét tulajdonságot tükrözi.
Se a precizitás se az újrahívás nem kapja meg a szerepet a teljes történetben.
A precizitásunk lehet a legjobb szörnyű újrahívással, vagy alternatívaként az F-mérték
kifejezi mind a precizitást mind az újrahívást. A következő képlettel számítjuk:
F-mérték = (2 * Precizitás * Újrahívás) / (Precizitás + Újrahívás)

A precizitás és újrahívás harmonikus közepe az F-mérték. A legtöbb esetben választania
kell a precizitás és újrahívás közül. A harmonikus közép gyorsan csökken, ha az egyik
irányba optimalizálja az osztályozóját. Amikor a precizitás és újrahívás hasonló,
az a legjobb; például egy modell, amely korán megjósolja a rákot a beteg képei és
laboreredményei alapján. Ebben a valós szituációban sok felesleges költséget okozhat
a kórháznak és lehetséges kárt a beteg egészségének, ha modell kimenetei között sok
a hibás pozitív. Másrészt, ha modell nem észleli jól a rákos betegeket, sok élet kerülne
veszélybe. Az ilyen esetekben el kell kerülnünk mind a magas hibás pozitívokat,
mind a magas hibás negatívokat, és itt az f-pontszám egy hasznos mérés a magas
hibás pozitívok és hibás negatívok elkerüléséhez. Az F-pontszám értéke 0 és 1 közötti.
Minél nagyobb az f-pontszám, annál jobb. Kevesebb hibás pozitívra és hibás negatívra
számíthatunk magas f-pontszám mellett.
Zavarodottsági mátrix
A zavarodottsági mátrix egy olyan mérés, amely az osztályozó modellek teljesítményét
jelenti a tesztadatminták egy készletén, amelynél az előrejelzési értékek ismertek.
Ez egy mátrixos formájú mérés, ahol a zavarodottsági mátrix egy N x N mátrix, és N az
előrejelzett osztályok száma. Például mondjuk, hogy két osztályunk van az előrejelzéshez
(bináris osztályozás), akkor N = 2, és ennek eredményeként egy 2 x 2 mátrixunk lesz,
mint amilyen itt látható az 5.3 ábrán:
5.3 ábra: Zavarodottsági mátrix a bináris osztályozáshoz

Az 5.3 ábra egy zavarodottsági mátrix példája bináris osztályozásnál a diabéteszes

és nem diabéteszes betegek között. 181 tesztadatminta van, amelyeken előrejelzést
végeztünk a betegek adatmintáinak osztályozásához diabéteszes és nem diabéteszes
kategóriákra. Egy zavarodottsági mátrix használatával kritikus meglátásokat kaphat
a modell teljesítményének értelmezéséhez. Például egy rápillantással tudni fogja, hány
előrejelzés valóban igaz és mennyi a hibás pozitív. Az ilyen meglátások számos esetben
felbecsülhetetlen értékűek a modell teljesítményének értelmezésénél. Itt van, hogy mit
jelentenek ezek a kifejezések a zavarodottsági mátrix kontextusában:
• Igaz pozitívok (TP): Ezen eseteket igaznak jelezték és tényleg igazak

a tesztadatminták alapján.
• Igaz negatívok (TN): Ezen eseteket hamisnak jelezték és ezek az esetek tényleg
hamisak a tesztadatminták alapján.
• Hamis pozitívok (FP): A modell igaznak jelezte, de ezek az esetek hamisak
a tesztadatminták alapján. A hiba ezen típusát I. típusú hibaként ismerik.
• Hamis negatívok (FN): A modell hamisnak jelezte, de ezek az esetek igazak
a tesztadatminták alapján. A hiba ezen típusát II. típusú hibaként ismerik.
Az 5.3 ábrára a következők vonatkoznak:
• Az x-tengely az ML modellek előrejelzéseit képviseli.

• Az y-tengely a tényleges címkéket képviseli.
• Az első és negyedik mezők a mátrixban (diagonális mezők) a helyesen jelzett
képeket mutatják.
• A második és harmadik mezők a mátrixban a hibás előrejelzéseket mutatják.
• Az első mezőben (Nem diabéteszes x Nem diabéteszes), 108 adatmintát (Igaz
negatívok - TN) jelzett, hogy nem diabéteszen (helyes előrejelzések).
• A negyedik mezőben (Diabéteszes x Diabéteszes), 36 adatmintát (Igaz pozitívok -
TP) jelzett helyesen.
• A többi kép a második mezőben (Macskák x Kutyák) 11 kép hamis pozitív.
• A harmadik mező (Kutyák x Macskák), ahol 26 kép van, hamis negatívokat
tartalmaz.
A zavarodottsági mátrix egy nagy képet adhat a tesztadatmintákon végzett előrejelzésekről

és olyan meglátásokat, amelyek jelentősek a modell teljesítményének értelmezésénél.
A zavarodottsági mátrix a de facto hibaelemzési mérés az osztályozási problémáknál,
mivel a legtöbb más mérés ebből származik.
AUC-ROC
Egy eltérő perspektíva a modellteljesítmény vizsgálatánál lehetővé teheti számunkra,
hogy értelmezzük a modell teljesítményét és finomhangoljuk azt a jobb eredmények
eléréséhez. A ROC és AUC görbék lehetővé tehetik az ilyen meglátásokat. Nézzük meg,
hogy a Receiver Operating Characteristic (ROC) görbe hogyan teheti lehetővé, hogy
értelmezzük a modellteljesítményt. A ROC görbe az osztályozási modell teljesítményét az
összes osztályozási küszöbértéknél bemutató grafikon. A grafikon két paramétert használ,
hogy leírja a modell teljesítményét: az Igaz pozitív arányt (TPR=TP/TP+FN) és a Hamis
pozitív arányt (FPR=FPFP+TN).
A következő grafikon egy tipikus ROC görbét mutat:
5.4 ábra: ROC-AUC görbe

Egy ROC görbe lerajzolja a TPR-t az FPR-rel szemben a különböző osztályozási
küszöbértékekhez. Az osztályozás küszöbértékének csökkentése lehetővé teszi, hogy több
tételt osztályozzon pozitívként, ami cserébe növeli mind a hamis pozitívokat mind az igaz
pozitívokat. Az Area Under the Curve (AUC) egy olyan mérőszám, amelyet hatékonyság
vagy egy osztályozó osztályok közötti különbségtételének számszerűsítésére használnak és
a ROC görbe összefoglalására használatos.
Az AUC értéke 0 és 1 között változik, az osztályozó akkor képes helyesen különbséget

tenni az összes pozitív és negatív osztálypont között, ha az AUC értéke 1, illetve az
osztályozó képtelen helyesen különbséget tenni az összes pozitív és negatív osztálypont
között, ha az AUC értéke 0. Amikor az AUC értéke 0,5 (egy küszöbérték manuális
beállítása nélkül), akkor az egy random osztályozó.
Az AUC segít nekünk rangsorolni az előrejelzéseket a pontosságuknak megfelelően,
de nem ad nekünk abszolút értékeket. Így egy méretfüggetlen. Továbbá az AUC az
osztályozás küszöbértékétől független. A választott osztályozási küszöbérték nem számít,
amikor az AUC-ot használjuk, mivel az AUC a modell előrejelzéseinek minőségét becsüli
a választott osztályozási küszöbértéktől függetlenül.
A Matthew korrelációs együttható

Brian Matthews fejlesztette ki a Matthews korrelációs együtthatót (MCC) 1975-ben
egy modellértékelési módszerként. Kiszámítja az eltéréseket a valós és várt értékek
között. Ez a zavarodottsági mátrix eredményeinek egy kiterjesztése az osztályozó
eredménytelenségének
mérésére. A TP, TN, FP és FN a négy bejegyzés a zavarodottsági mátrixban.
Ezek a bejegyzések
számítanak bele az együtthatóba:
Ez a mérőszám csak akkor ad magas pontszámot, ha az előrejelzés jó arányokat ad vissza

mint a négy kategóriában. Az MCC tartománya -1 és +1 közötti:
• Az 1 a legjobb egyezőség a valóság és az előrejelzések között.

• Amikor a pontszám 0, az azt jelenti, egyáltalán nincs egyezés a valóság és az
előrejelzések között. Az előrejelzés véletlenszerű valósághoz képest.
Például egy 0,12 értékű MCC azt mutatja, hogy az osztályozó nagyon véletlenszerű.
Ha 0,93, az azt jelenti, hogy az osztályozó jó. Az MCC egy hasznos mérőszám,
hogy segítsen egy osztályozó eredménytelenségének kimutatásában.
Felügyelet nélküli tanulási modellek

A felügyelet nélküli tanulási modellek vagy algoritmusok tanulhatnak címkézetlen
adatokból. A felügyelet nélküli tanulás használható ötletek szerzésére és a címkézetlen
adatokban a mintázatok azonosítására. A felügyelet nélküli algoritmusok széleskörűen
használatosak klaszterezéshez vagy az anomáliák észlelésére a címkék segítsége nélkül.
Itt van néhány mérőszám a felügyelet nélküli tanulási algoritmusok teljesítményének
méréséhez.
A Rand index
A Rand index egy olyan mérőszám, amely a klaszterező technikák minőségét értékeli.
A klaszterek közötti hasonlóság fokát mutatja. A Rand index a helyes döntések százalékát
méri. A döntések egy adatpontpárt (például dokumentumokat) rendelnek hozzá
ugyanahhoz a klaszterhez.
Ha N adatpont van, a döntések teljes száma = N(N-1)/2, amely a döntésben érintett
adatpontpárokat mutatja.
Rand index = TP + TN / TP + FP + FN + TN
Tisztaság
A tisztaság egy külső értékelési mérőszám a klaszterminőséghez. A tisztaság
kiszámításához a klasztereket a klaszteren belül leggyakoribb osztály szerint kell címkézni,
majd ezen klaszter hozzárendelésének pontossága mérhető, ha a helyesen hozzárendelt
adatpontok számát elosztjuk N-nel (a klaszterezett adatpontok teljes száma). A jó
klaszterezés tisztasági értéke közel van az 1-hez, és a rossz klaszterezés tisztasági értéke
közel van a 0-hoz. Az 5.5 ábra egy tisztaság számítási példa vizuális megjelenítése,
amelynek alább található a magyarázata:
5.5 ábra: Klaszterek a klaszterezés után

A tisztaság egy külső értékelési kritérium a klaszterminőségre vonatkozóan. Az 5.5 ábrán
a többségi osztály és a többségi osztály tagjainak száma a három klaszternél a következő:
zöld csepp x 5 (1. klaszter), piros pont x 5 (2. klaszter) és kereszt x 4 (3. klaszter). Így
a tisztaság (1/17) x (5 + 5 + 3) = ~0,76.
A Silhouette-együttható
A klaszterező algoritmusoknál fontos a klaszterminőség meghatározása. A klaszterek
minőségének vagy jóságának meghatározásához használatos mérőszámként a silhouette-
pontszám vagy silhouette-együttható. Az értéktartománya -1 és +1 közötti. Amikor
a klaszterek egyértelműen megkülönböztethetők vagy jól elkülönülnek egymástól, akkor
a silhouette-pontszám 1. Másrészt a -1 azt jelenti, hogy klasztereket rosszul osztották ki,
és a 0 azt jelenti, hogy a klaszterek közömbösek egymáshoz képest. Így kell kiszámítani
a silhouette-pontszámot:
Silhouette-pontszám = (b-a)/max(a,b)
a = az átlagos távolság az egyes pontok között egy klaszteren belül (átlagos klaszteren
belüli távolság).
b = az átlagos távolság a klaszterek között (átlagos klaszterek közötti távolság).
Hibrid modellek mérései

Gyors fejlődés történt az ML-nél, mivel kombinálták a hagyományos módszereket, hogy
hibrid módszereket fejlesszenek a változatos üzleti és kutatási problémák megoldásához.
A hibrid modellek magukba foglalják a félig felügyelt, önellenőrzött, több példányos,
multitask, megerősített, együttes, átvitt és egyesített tanulási modelleket. Ezen modellek
értékeléséhez és validálásához egy sor mérés használatos a felhasználási esettől és a modell
típusától függően. Érdemes ismerni ezeket a méréseket, hogy képes legyen a megfelelő
méréseket használni a modell alapján, amelyet a jövőben fejleszteni és értékelni fog.
Itt vannak a mérések a hibrid modellek értékeléséhez:
Ember vs gép tesztelés

Az emberi szintű teljesítmény iránti lelkesedés elég gyakori az ML és mély tanulásos
modellek tanítása és tesztelése során. A modellek validálása érdekében és annak
meghatározásához, hogy a modellek elérték-e vagy meghaladták-e az ember szintű
teljesítményt, ember vs gép kísérleteket hajtanak végre a feladatoknál. Ugyanazt
a feladatot hajtja végre egy ML modell, és az emberi teljesítményt értékelik az ML modell
teljesítményével szemben. Számos mérés van az ember vs gép teljesítmény értékelésére
a kontextustól és feladattól függően. Itt van néhány példa:
• A Bilingual evaluation understudy (BLEU) egy módszer a szövegminőség

értékelésére a gépi fordítás feladatánál egyik nyelvről a másikra. A gépi fordító
algoritmus által generált szöveg minőségét hasonlítják össze egy ember
teljesítményével. Azért végzik az értékelést, hogy megvizsgálják, mennyire van közel
egy gépi fordítás egy szakszerű emberi fordításhoz.
• A Recall-Oriented Understudy for Gisting Evaluation (ROUGE) egy ember

vs gép teljesítményértékelő mérés az olyan feladatok értékelésére, mint például
az automatikus összefoglalás és a gépi fordítás. Ez a mérés egy automatikusan
generált összefoglalást vagy fordítást hasonlít össze az emberek által készített
összefoglalással/fordításokkal.
A Turing-teszt
A Turing-tesztet a híres Alan Turing készítette. Ő az imitációs játékként utalt rá az 1950-es
években. A Turing-teszt egy olyan teszt, amely azt értékeli, hogy egy gép mennyire képes
egy emberéhez hasonló intelligens viselkedés bemutatására. Más értelemben a Turing-
teszt azt is értékeli, hogy egy gép mennyire képes átverni egy embert, hogy az azt higgye,
hogy egy feladatot egy emberszerű gép vagy egy ember végzett-e el. Például működés
közben láthatjuk a Turing-tesztet az 5.6 ábrán, ahol egy szöveg alapú interakció történik az
emberi vizsgáztató, X, és egy számítógép vagy gépi alany (Bob), valamint a vizsgáztató,
X, és egy emberi alany (Alice) között:
5.6 ábra: Turing-teszt

A Turing-teszt során az emberi vizsgáztató, X, egy sor interakciót hajt végre mind Bobbal
(számítógép), mind Alice-szal (ember) azzal a szándékkal, hogy helyesen különbséget
tegyen az ember és a gép között. A gép akkor megy át a Turing-teszten ha/amikor
a vizsgáztató nem tud jól különbséget tenni közöttük, vagy összetéveszti a gépet egy
emberrel (Bobot Alice-szal).
Fordulónkénti jutalmak
A megerősítéses tanulási modellek olyan hibrid modellek, amelyek tartalmazzák
a folytonos tanulás mechanizmusát az ágens és a működtető környezet között, hogy
előre meghatározott célokat érjen el. Az ágens a jutalmak alapján tanul, amelyeket
a célhoz vezető hatékony vagy optimális lépésekért kap. Amikor az optimális irányítás
a cél, akkor azalapján akarja mérni az ágenst, hogy milyen jól végzi a feladatot.
Annak számszerűsítéséhez, hogy az ágens mennyire végzi jól a feladatot, az összesített
jutalom, mint például a teljes jutalom epizódonként ("visszatérésként" is ismert) vagy
időléptékenkénti átlagos jutalom használható az irányítás értékelésére és optimalizálására
az ágensnél, tekintettel a környezetre és a célokra.
Megbánás
A megbánás egy gyakran használt mérés az olyan hibrid modelleknél, mint amilyenek
a megerősítéses tanulási modellek. Minden időléptéknél Ön kiszámítja a különbséget
az optimális döntés és az algoritmus által hozott döntés jutalma között. A kumulatív
megbánás ezután kiszámítható ennek összegzésével. A minimális megbánás 0 az optimális
intézkedésnél. Minél kisebb a megbánás, annál jobban teljesített egy algoritmus.
A Megbánás lehetővé teszi az ágens tevékenységeinek értékelését a legjobb intézkedésre
való tekintettel az ágens optimális teljesítménye érdekében, ahogy az 5.7 ábrán látható.
Az árnyékolt terület a pirosban a megbánás:
5.7 ábra: Megbánás a megerősítő tanulásnál

SHapley Additive exPlanations (SHAP)
A modell értelmezhetősége és annak magyarázata, hogy modell miért hoz meg bizonyos
döntéseket vagy előrejelzéseket, számos üzleti problémánál vagy iparágnál kulcsfontosságú
lehet. A korábban megvitatott technikák használatával értelmezhetjük a modell
teljesítményét, de marad néhány szürke terület, például a mély tanulásos modellek, amelye
fekete dobozos modellek. Általánosan megjegyzendő, hogy ezek a modellek taníthatók
úgy, hogy nagyszerű eredményeket vagy pontosságokat érjenek el a tesztadatokon,
de nehéz megmondani miért. Az ilyen szituációkban a SHapley Additive exPlanations
(SHAP) hasznos lehet annak dekódolásához, hogy mi történik az előrejelzett
eredményekkel és melyik jellemző előrejelzése korrelál a legjobban. A SHAP-ot ez
a dokumentum ajánlotta (a NIPS-nél): http://papers.nips.cc/paper/7062-a-
unified-approach-to-interpreting-model-predictions.
A SHAP működik az osztályozási és regressziós modelleknél is. A SHAP elsődleges célja,
hogy megmagyarázza a modell kimeneti előrejelzését az egyes jellemzők hozzájárulásának
kiszámításával. A SHAP magyarázási módszer Shapley-értékeket használ, hogy
megmagyarázza a jellemző fontosságát a modell kimeneteinél vagy előrejelzéseinél.
A Shapley-értékeket a kooperatív játékelméletből számítják, és ezek az értékek -1 és 1
között változnak. A Shapley-értékek leírják a modell kimeneteinek eloszlását a jellemzők
között, ahogy az 5.8 ábrán látható:
5.8 ábra: Shapley-értékes oszlopdiagram ábrázolja a jellemző jelentőségét

Számos SHAP magyarázó technika van, mint például a SHAP Tree Explainer, SHAP
Deep Explainer, SHAP Linear Explainer, és SHAP Kernel Explainer. A felhasználási
esettől függően ezek a magyarázók hasznos információt nyújthatnak a modell
előrejelzéseiről és segítenek megérteni a fekete dobozos modelleket. Továbbiakat
itt olvashat: https://christophm.github.io/interpretable-ml-book/
shap.html
MIMIC magyarázó
A Mimic magyarázó egy fekete dobozos modelleket utánzó megközelítés, amely egy
magyarázható globális helyettes modellt tanít. Ezek a betanított globális helyettesítő
modellek magyarázható modellek, amelyeket úgy tanítottak be, hogy megközelítsék
bármely fekete dobozos modell előrejelzéseit, amilyen pontosan csak lehetséges.
A helyettesítő modell használatával egy fekete dobozos modell a következőképpen
mérhető vagy magyarázható.
Az következő lépéseket egy helyettesítő modell tanításához hajtjuk végre:
1. Egy helyettesítő modell tanítását azzal kezdjük, hogy kiválasztunk egy adatkészletet,
X-et. Ez az adatkészlet leget ugyanaz, mint amit a fekete dobozos modell tanításához
használtunk vagy lehet egy hasonló eloszlásokkal rendelkező másik adatkészlet,
a felhasználástól függően.
2. Nyerjük ki a fekete dobozos modell előrejelzéseit a kiválasztott adatkészlethez,
X-hez.
3. Válasszunk ki egy magyarázható modelltípust (lineáris modell, döntési fa, random
forest stb.).
4. Az adatkészlet, X, és annak előrejelzéseinek használatával tanítsuk be
a magyarázható modellt.
5. Most van egy betanított helyettesítő modellje. Éljen!
6. Értékelje ki, hogy a helyettesítő modell milyen jól adta vissza a fekete dobozos
modell előrejelzéseit, például az R-négyzet vagy F-pontszám használatával.
7. Értelmezze a fekete dobozos modell előrejelzéseit a helyettesítő modell
értelmezésével.
A következő értelmezhető modellek használhatók helyettesítő modellként: Light Gradient

erősítő modell (LightGBM), lineáris regresszió, sztohasztikus gradiens csökkenés vagy
random forest és döntési fa.
A helyettesítő modellek lehetővé tehetik az ML-megoldás fejlesztőinek, hogy mérjék és
megértsék a fekete dobozos modell teljesítményét.
Permutation feature importance (PFI) magyarázó

A Permutation Feature Importance (PFI) az osztályozási és regressziós modellek
magyarázására használatos technika. Ez a technika hasznos egy jellemző értelmezésénél és
megismerésénél a modell kimenetén vagy előrejelzési korrelációján. A PFI egy alternatíva
a SHAP-ra. Úgy működik, hogy véletlenszerűen értékel egyszerre egy jellemzőt az egész
adatkészletből és kiszámítja a változást a teljesítményértékelési mérésben. A változás
értékelése a teljesítménymérésben minden jellemzőnél megtörténik; minél jelentősebb
a változás, annál fontosabb a jellemző.
A PFI képes leírni bármely modell általános viselkedését, de nem magyarázza meg
a modell egyes előrejelzéseit. A PFI egy alternatíva a SHAP-ra, mégis eléggé különbözik
tőle, mivel a PFI a modell teljesítményének csökkenésén alapszik, míg a SHAP a jellemző
tulajdonságainak nagyságrendjén alapszik.
Statisztikai modellek mérései

Ahogy megtanultuk a 2. fejezet: Az Ön gépi tanulási problémájának jellemzése részben,
a statisztikai modelleknek három típusa van: induktív tanulás, deduktív tanulás és
transzduktív tanulás. A statisztikai modellek jól értelmezhetők.
Átlag
A középérték vagy átlag az adatkészlet központi értéke. Kiszámításához össze kell adni
az összes értéket és az összeget elosztani az értékek számával:
átlag = x1 + x2 + x3 +.... + xn / n
Standard eltérés
A standard eltérés az értékek szórását méri az adatkészletben. Minél alacsonyabb
a standard eltérés, az adatpontok annál közelebb vannak az átlaghoz. Egy nagyobb
szórású adatkészletnek magasabb lenne a standard eltérése.
Elfogultság
Az elfogultság a leképező függvény erősségét (vagy merevségét) méri a független
(bemeneti) és függő (kimeneti) változók között. Minél erősebbek a modell feltételezései
a leképezés funkcionális formájának tekintetében, annál nagyobb az elfogultság.
A magas elfogultság jól jön, amikor az alapot szolgáló igaz (de ismeretlen) modellnek
olyan egyeztetési tulajdonságai vannak, mint a leképező függvény feltételezései. Azonban
teljesen elveszítheti a fonalat, ha a mögöttes modell nem mutat hasonló tulajdonságokat
a leképzés funkcionális formájával. Például az a feltételezés, hogy egy lineáris kapcsolat
van a változók között, amikor a valóságban az erősen nem lineáris, és ez rossz
illeszkedéshez vezetne:
• Alacsony elfogultság: Gyenge feltételezések a bemenetektől kimenetekig tartó

leképezés funkcionális formájának tekintetében
• Magas elfogultság: Erős feltételezések a bemenetektől kimenetekig tartó leképezés
funkcionális formájának tekintetében
Az elfogultság mindig pozitív érték. Itt van egy további forrás, hogy többet tudjon
az elfogultságról az ML-nél. Ez a cikk részletesebb magyarázatot kínál: https://
kourentzes.com/forecasting/2014/12/17/the-bias-coefficient-a-
new-metric-for-forecast-bias/.
Variancia
A modell varianciája annak a mértéke, ahogy a modell teljesítménye változik, amikor
eltérő tanítási adatokra illesztik. A jellemzők modellre gyakorolt hatását rögzíti
a variancia.
Egy magas varianciájú modell sokat fog változni a tanítási adatkészlet kis változásaira is.
Másrészt egy alacsony varianciájú modell nem változna sokat a tanítási adatkészlet nagy
változásaira sem. A variancia mindig pozitív érték.
R-négyzet
Az R-négyzet, determinációs együtthatóként is ismert, a függő változó változását méri,
amely magyarázható a modellel. Kiszámításához a megmagyarázott változást el kell
osztani a teljes változással. Egyszerűen az R-négyzet azt méri, az adatpontok mennyire
vannak közel az illesztett regressziós vonalhoz.
Az R-négyzet értéke 0 és 1 közé esik. Az alacsony R-négyzet azt jelzi, hogy függő változó
változásának nagy részét a modell nem magyarázza, hanem más tényezők okozzák,
amelyeket az nem tartalmaz. Általában véve egy magasabb R-négyzet értéket kell
megcéloznia, mert ez azt jelzi, hogy a modell jobban illeszkedik az adatokra.
RMSE
Az átlagos négyzetes gyökeltérés (RMSE) a különbséget méri a modell előrejelzett értékei
és a megfigyelt (valós) értékek között.
Számos opció van, és Önnek ki kell választania a helyes mérést a valós termelési
szituációhoz, hogy rendesen igazolt értékelésekkel rendelkezzen; például miért akarna
egy adatkutató vagy adatkutató csapat egy értékelési mérést választani egy másik helyett,
például az R-négyzetet az átlag helyett egy regressziós problémánál. A felhasználási eseten
és az adattípuson múlik.
HITL modellek mérése

Kétféle HITL modell van: az emberi megerősítéses tanulás és az aktív tanulási modellek.
Ezeknél a modelleknél az ember-gép kollaboráció segíti az algoritmust, hogy emberszerű
viselkedéseket és kimeneteleket utánozzon. A fő hajtóerő ezeknél az ML megoldásoknál
az ember a hurokban. Emberek validálják, címkézik és tanítják újra a modelleket, hogy
fenntartsák a modell pontosságát.
Emberi elfogultság
Mint az emberi agy, az ML rendszerek is ki vannak téve a kognitív elfogultságnak. Az emberi
kognitív elfogultság olyan folyamat, amely rontja a döntéshozást és érvelési képességet,
amely hibázáshoz vezet. Az emberi elfogultság esetei magukba foglalják a sztereotipizálást,
szelektív észlelést, a bandwagon-effektust (divatból cselekvés), kivételezést, az igenlésre való
hajlamot, megfigyelési szelekciós elfogultságot és a spekuláns tévképzetét. Számos esetben
fontos elkerülni az ilyen elfogultságokat az ML rendszereknél, hogy észszerű és optimális
döntéseket hozzanak. Ez pragmatikusabbá teszi az ML rendszereket az embereknél, ha
megoldjuk az emberi elfogultság levezetését és kijavítjuk azt. Ez különösen hasznos a
HITL-alapú rendszereknél. Az elfogultság tesztelésénél az emberi elfogultság három típusa
azonosítható, és ezeken kell dolgozni az ML rendszer döntéshozásának fenntartásához, hogy
az mentes legyen az emberi elfogultságtól. A három emberi elfogultság a következő:
• Interakció elfogultság
Amikor egy ML rendszerrel megetetnek egy olyan adatkészletet, amely bizonyos
típusú bejegyzések tartalmaz, akkor egy interakció elfogultság jön létre, amely
megakadályozza az algoritmust, hogy más típusú bejegyzéseket ismerjen fel. Ez az
elfogultságtípus a betanított modellek következtetéses tesztelésénél azonosítható.
Az olyan módszerek, mint a SHAP és PFI hasznosak lehetnek az ilyen elfogultság
azonosításánál.
• Látens elfogultság
A látens elfogultság akkor tapasztalható, amikor a tanítási adatkészletben több
példa rendelkezik egy jellemzővel, amely kiemelkedő. Ezután az algoritmus nem
fogja felismerni azokat, amelyek nem rendelkeznek ezzel a jellemzővel. Például
nemrégiben az Amazon HR algoritmusa, amely a jelentkezések alapján választotta
ki az embereket a vállalaton belüli szerepekre, elfogult lett a nőkkel szemben, az oka
a látens elfogultság volt.
• Szelekciós elfogultság
Szelekciós elfogultság akkor kerül bele egy algoritmusba, amikor az elemzésre
kijelölt adatok nincsenek jól randomizálva. Például egy nagy teljesítményű
arcfelismerő rendszer tervezésekor, kulcsfontosságú minden lehetséges arcszerkezet
és arcforma típusát belefoglalni, illetve mintát venni minden etnikai és földrajzi
lehetőségből, hogy elkerüljék a szelekciós elfogultságot. A szelekciós elfogultság
olyan módszerekkel azonosítható, mint a SHAP vagy PFI, amelyek figyelik
a modellre jellemző elfogultságot.
Optimális intézkedés
Az emberi megerősítéses tanulás esetében a rendszer célja, hogy maximalizálja a művelet
jutalmát az aktuális állapotban. A műveletekért kapott jutalom maximalizálása érdekében
az optimális tevékenység használható mérőszámként a rendszer méréséhez. Az optimális
tevékenység esetében olyan művelet kerül kiválasztásra, amely az aktuális állapotban
maximalizálja a jutalmat. Az optimális tevékenység az a mérőszám vagy állapot, amely
ideális egy rendszernek, hogy legjobban teljesítsen. Egy emberi megerősítéses tanuláson
alapuló rendszerben egy emberi kezelő vagy tanár állítja be az optimális tevékenységet
a rendszer céljaként, hogy elérje az emberszintű teljesítményt.
Az automatizáció foka
Az automatizáció a termékek automatikus előállításának folyamata, vagy egy feladat
elvégzése robotok vagy algoritmusok használatával, közvetlen emberi segítség nélkül.
Egy ML rendszer automatizációs szintje kiszámítható az összes feladat automatizációs
fokának felhasználásával. Alapvetően ez a rendszer által teljesen automatizált feladatok
százaléka, és ezek a feladatok nem igényelnek semmilyen emberi segítséget. Azt mutatja,
hogy az összes feladatnak hány százaléka teljesen automatizált. Például a DeepMind
AlphaGo-ja elérte a 100%-os automatizációt, hogy önállóan működjön, hogy legyőzze
a világbajnok ember játékosokat.
Kockázati arány
Annak valószínűsége, hogy egy ML modell hibákat vét, a hibaarány. A hibaarányt a modell
termelési rendszerekben nyújtott teljesítménye alapján számítják. Minél alacsonyabb
a hibaarány, annál jobb egy ML rendszer. Az ember a hurokban rendszerek célja,
hogy csökkentse a hibaarányt, megtanítsa az ML modellt a legoptimálisabb működésre.
Termeléstesztelési módszerek
Mivel különféle üzletek működnek, ezért eltérő típusú termelési rendszerek szolgálják
ezeket az üzleteket. Ebben részben megnézzük az általánosan használt termelési
rendszerek különböző típusait, és hogy hogyan kell tesztelni őket.
Termeléstesztelési módszerek 123
Tömeges tesztelés
A tömeges tesztelés validálja a modelljét azzal, hogy olyan környezetben hajt végre
tesztelést, amely különbözik a tanítási környezettől. A tömeges tesztelést egy adatminta-
készleten hajtják végre, hogy teszteljék a modell a következtetését a választott mérőszámok
használatával, mint amilyen a pontosság, RMSE vagy f1-pontszám. A tömeges tesztelés
elvégezhető különféle számítási típusokon, például a felhőben vagy egy távoli szerveren
vagy egy tesztszerveren. A modellt általában egy szerializált fáljként szolgáltatják, és a fájlt
objektumként töltik be és a tesztadatokon következtetnek vele.
A/B tesztelés
Biztosan találkozott már az A/B teszteléssel. Gyakran használják szolgáltatások
tervezésénél (weboldalak, mobil appok stb.) és reklámkampányok értékelésénél.
Például arra használják, hogy kiértékeljék, egy konkrét célközönségnek szánt kialakítás
konkrét megváltoztatása pozitív hatással lesz-e az olyan üzleti mutatókra, mint
a felhasználói elköteleződés, az átkattintási arány vagy értékesítés arány. Egy hasonló
technikát alkalmaznak az ML modellek tesztelésénél az A/B tesztelés használatával.
Amikor a modelleket az A/B tesztelés használatával tesztelik, a teszt olyan fontos
kérdéseket fog megválaszolni, mint például a következők:
• Az új B modell jobban teljesít a termelésben, mint a jelenlegi A modell?

• A két modelljelölt közül melyik működik jobban a termelésben, hogy pozitív üzleti
mutatókhoz vezessen?
Az A/B tesztelés eredményeinek értékeléséhez statisztikai technikákat használnak

az üzlet vagy műveletek alapján, hogy meghatározzák, melyik modell teljesít jobban
a termelésben. Az A/B tesztelést általában így végzik, és a valós idejű vagy élő adatokat
két készletre osztják fel, A készletre és B készletre. Az A adatkészlet a régi modellhez
vezet, és a B adatkészlet az új modellhez vezet. Annak értékeléséhez, hogy az új modell
(B modell) jobban teljesít-e, mint a régi modell (A modell), sokféle statisztikai technika
felhasználható a modellteljesítmény értékeléséhez (például a pontosság, precizitás,
újrahívás, f-pontszám és RMSE) az üzleti felhasználási esettől vagy műveletektől függően.
A modellteljesítmény üzleti mutatókra (pozitív változás az üzleti mutatókban) vonatkozó
statisztikai elemzésétől függően meghozható a döntés, hogy lecserélik a régi modellt
az újra, vagy eldöntsék, melyik modell a jobb.
Az A/B tesztelést módszeresen hajtják végre a statisztikai hipotézistesztelés használatával,

és ez a hipotézis validálja egy érme két oldalát, a nullhipotézisét és az ellenhipotézisét.
A nullhipotézis azt állítja, hogy az új modell nem növeli a monitorozási üzleti mutatók
átlagos értékét. Az ellenhipotézis azt állítja, hogy az új modell javítja a monitorozási üzleti
mutatók átlagos értékét. Végül az A/B tesztelést használják, hogy értékeljék, az új modell
jelentős javuláshoz vezet-e a konkrét üzleti mutatóknál. Az A/B tesztelésnek több fajtája van
az üzleti felhasználási esetektől és műveletektől függően, például a Z-teszt, G-teszt
(ajánlom ezek és egyebek ismeretét) stb. A helyes A/B teszt és mutatók kiválasztása az
értékelésnél egy win-win szituáció lehet az üzlete és az ML műveletek szempontjából.
Próbateszt vagy árnyékteszt

Mielőtt telepítene egy modellt a termelésben, amely aztán üzleti döntéseket hozna,
érdemes lehet lemásolni egy termelésszerű környezetbe (próbakörnyezet), hogy tesztelje
a modell teljesítményét. Ez különösen fontos a modell robosztusságának teszteléséhez és
a teljesítményének értékeléséhez valós idejű adatokkal. Ez kivitelezhető úgy, hogy telepíti
a fejlesztői ágat vagy a tesztelendő modellt egy próbaszerverre és következtetést hajt végre
ugyanazon az adaton, mint a termelési folyamatban. Ennek csak annyi a hibája, hogy
a végfelhasználók nem fogják látni a fejlesztési ág eredményeit vagy az üzleti döntések
nem születnek meg a próbaszerveren. A próbakörnyezet eredményeit statisztikusan ki
lehet értékelni a megfelelő mutatók (például a pontosság, precizitás, újrahívás, f-pontszám
és RMSE) használatával, hogy meghatározzák a modell teljesítményét és robosztusságát az
üzleti mutatókkal kapcsolatosan.
Tesztelés CI/CD-ben
A tesztelés megvalósítása a CI/CD folyamatok részeként értékes lehet a modell
teljesítményének automatizálása és (beállított kritériumok alapján történő) értékelése
tekintetében. A CI/CD folyamatokat többféleképpen lehet beállítani a műveletektől és
architektúrától függően, például:
• Egy ML folyamat sikeres futásakor a CI/CD folyamatok bekapcsolhatják egy új

modell A/B tesztelését a próbakörnyezetben.
• Amikor egy új modellt betanítottak, érdemes beállítani egy, a tesztkészlettől
különböző adatkészletet, hogy mérje a teljesítményét a megfelelő mutatók
tekintetében, és ez a lépés lehet teljesen automatizált.
• A CI/CD folyamatok periodikusan bekapcsolhatják az ML folyamatok egy
megadott időben a nap során, hogy betanítsanak egy új modellt, amely élő vagy
valós idejű adatokat használ egy új modell tanításához vagy egy meglévő modell
finomhangolásához.
Miért kell csomagolni az ML modelleket? 125
• A CI/CD folyamatok monitorozhatják a ML modell teljesítményét a termelésben

telepített modellnél, és ez bekapcsolható vagy kezelhető idő alapú kapcsolók vagy
manuális kapcsolók (a minőségbiztosításért felelős csapattagok kezdeményezésével)
használatával.
• A CI/CD folyamatok biztosíthatnak két vagy több próbakörnyezetet az A/B
tesztelés végrehajtásához egyedi adatkészleteket a diverzebb és átfogóbb tesztelés
végrehajtásához.
Ez sokféle szituáció volt, és a követelményektől függően a CI/CD folyamatok különböző

munkafolyamatok és műveleteket kínálnak az üzleti és technológiai követelményekre
szabva. Egy hatékony architektúra és CI/CD folyamat kiválasztása átfogóan javíthatja
a technológiai műveleteket és a csapat teljesítményét. A CI/CD tesztelés nagymértékben
javíthatja és automatizálhatja a tesztelést.
Miért kell csomagolni az ML modelleket?

Az MLOps egy szisztematikus megközelítést tesz lehetővé a modellek tanításához
és értékeléséhez. A modellek tanítása és értékelés után a következő lépés eljuttatni
őket a termelésbe. Mint tudjuk, az ML nem úgy működik, mint a hagyományos
szoftverfejlesztés, természetében determinisztikus, és ahol egy kódrészlet vagy modul
a meglévő rendszerből kerül importálásra és működik. Az ML megoldások fejlesztése nem
determinisztikus és magába foglalja az ML modellek kiszolgálását, az előrejelezzenek vagy
adatokat elemezzenek.
A modellek kiszolgálásához szoftvertárgyakba kell őket csomagolni, hogy elszállítsák
a tesztelési vagy termelési környezetekbe. Általában ezeket a szoftvertárgyakat egy
fájlba, vagy fájlkötegbe vagy konténerbe csomagolják. Ez lehetővé teszi, hogy a szoftver
környezet- és fejlesztésagnosztikus legyen. Az ML modelleket a következő okok miatt kell
csomagolni:
Szállíthatóság
Az ML modellek szoftvertárgyakba történő csomagolása lehetővé teszi, hogy elszállítsák egyik
környezetekből a másikba. Ez egy fájl vagy fájlköteg vagy konténer szállításával végezhető
el. Mindegyik esetben elszállíthatjuk a tárgyakat és különböző beállításokban átmásolhatjuk
a modellt. Például egy csomagolt modell telepíthető egy virtuális gépen vagy szerver nélküli
beállításban.
Következtetés
Az ML következtetés egy olyan folyamat, amely magába foglalja a valós idejű adatok
feldolgozását az ML modellek használatával egy kimenet kiszámításához, ami például egy
előrejelzés vagy numerikus pontszám. Az ML modellek csomagolásának célja, hogy képes
legyen kiszolgálni az ML modelleket valós időben az ML következtetéshez. A hatékony
ML modellcsomagolás (például egy szerializált modell vagy konténer) képes kezelni
a telepítést és kiszolgálni a modellt az előrejelzésekhez és a valós idejű vagy kötegelt adatok
elemzéséhez.
Együttműködési képesség
Az ML modell együttműködési képessége két vagy több modell vagy komponens azon
képességes, hogy információt cseréljenek, és hogy felhasználják a kicserélt információt
egymás tanítására vagy finomhangolására és hatékonyan végezzék a műveleteket.
A kicserélt információ formája lehet adat vagy szoftvertárgy vagy modellparaméter.
Az ilyen információk lehetővé teszik a modellek finomhangolását, újratanítását vagy
adaptálását különböző környezetekhez más szoftvertárgyak tapasztalata alapján,
a teljesítmény és hatékonyság érdekében. Az ML modellek csomagolása az alapja az
ML modellek együttműködési képességének lehetővé tételéhez.
Telepítési agnoszticitás
ML modellek olyan szoftvertárgyakba történő csomagolás, mint amilyenek a szerializált
fájlok vagy konténerek, lehetővé teszik, hogy a modelleket változatos futtásidejű
környezetekbe szállítsák és telepítsék, mint amilyen egy virtuális gép, egy tároló szerver
nélküli környezet, egy streaming szolgáltatás, mikroszolgáltatás vagy szolgáltatásköteg.
Olyan szállítási és telepítési agnoszticitási lehetőségeket tár fel, amelyek ugyanazokat
a szoftvertárgyakat használják, mint amibe egy ML modellt csomagoltak.
Hogyan kell csomagolni az ML modelleket?

Az ML modellek sokféleképpen csomagolhatók az üzleti és technológiai követelményektől
függően és az ML műveletei alapján. Az ML modellek háromféleképpen csomagolhatók és
szállíthatók, ahogy azt a következő alrészekben tárgyaljuk.
Hogyan kell csomagolni az ML modelleket? 127
Szerializált fájlok
A szerializálás egy fontos folyamat egy ML modell csomagolásánál, mivel lehetővé
teszi a modell hordozhatóságát, együttműködési képességét és a modellkövetkeztetést.
A szerializálás egy objektum vagy adatszerkezet (például változók, tömbök és rekordok)
tárolható tárggyá (például egy fájl vagy memóriapuffer) történő konvertálásának
módszere, amely szállítható a számítógépes hálózatok között. A szerializálás fő célja
a szerializált fájl újraépítése az előző adatszerkezetté (például egy szerializált fájlt egy
ML modellváltozóvá) egy eltérő környezetben. Így egy újonnan betanított ML modell
szerializálható egy fájllá és exportálható egy új környezetbe, ahol deszerializálható egy
ML modellváltozóvá vagy adatszerkezetté az ML következtetéséhez. A szerializált fájl nem
menti vagy tartalmazza a korábban társított módszereket vagy megvalósításokat. Csak
az adatszerkezetet menti, ahogy van, egy tárolható tárgyban, például egy fájlban.
Itt van néhány népszerű szerializálási formátum az 5.1 táblázatban:
5.1 táblázat: Az ML modell népszerű szerializálási formátumait

Egy közös problémája van ezeknek a szerializált formátumoknak (az ONNX-et kivéve),
az együttműködési képesség problémája. Ennek kezelésére kifejlesztették az ONNX-et egy
nyílt forráskódú projektként, amelyet a Microsoft, Baidu, Amazon és más nagyvállalatok
támogattak. Ez lehetővé teszi, hogy modellt betanítsanak egy keretrendszer használatával
(például scikit-learn-ben), majd újratanítsák a TensorFlow használatával. Ez nagy fordulat
volt az iparosított MI-nél, mivel modellek formázhatók lettek együttműködésre képesként
és keretrendszertől függetlenül.
Az ONNX új utakat nyitott meg, mint például az egyesített tanulás és átvitt tanulás.
A szerializált modellek lehetővé teszik a hordozhatóságot és a tömeges következtetést is
(tömeges következtetés vagy offline következtetés, az előrejelzések generálásának olyan
módszere, amely kötegelt adatpontokkal vagy mintákkal dolgozik) eltérő környezetekben.
Csomagolás vagy konténerezés

Gyakran találkozunk diverz környezetekkel a termelési rendszereknél. Minden
környezet eltérő kihívásokkal rendelkezik, amikor az ML modellek telepítéséről van
szó a kompatibilitás, robosztusság és méretezhetőség tekintetében. Ezek a kihívások
elkerülhetők néhány folyamat vagy modul szabványosításával, és a konténerek az ML
modellek és szoftvermodulok szabványosításának nagyszerű módjai.
A konténer egy szabványos szoftveregység, amely kódból és annak minden függőségéből
áll. Lehetővé teszik az alkalmazások gyors és megbízható működését a számítási
környezetek között. Lehetővé teszi, hogy a szoftver környezet- és fejlesztésagnosztikus
legyen. A konténereket a Docker kezeli és hangolja össze. A Docker ipari szabvánnyá vált
a konténerek fejlesztése és összehangolása területén.
A Docker egy nyílt forráskódú (https://opensource.com/resources/what-
open-source) eszköz. Azért fejlesztették ki, hogy kényelmessé tegye az alkalmazások
kialakítását, telepítését és futtatását a konténerek használatával. A konténerekkel egy
fejlesztő becsomagolhat egy alkalmazást összes összetevőjével és moduljával, mint
amilyenek a fájlok, könyvtárak és más függőségek, és egyetlen csomagként telepítheti azt.
A konténerek egy megbízható mód a Linux operációs rendszert használó alkalmazások
futtatására, személyre szabott beállításokkal. A Docker konténerek a Dockerfájlok
használatával készülnek, amelyek egy alkalmazás konténerizálására szolgálnak. Egy
Docker kép kialakítása után elkészül egy Docker konténer. A Docker konténer egy
alkalmazás, amely egyedi beállításokkal fut, ahogy a fejlesztő beállította. Az 5.9 ábra
mutatja egy Docker konténer kialakításának és futtatásának folyamatát egy Docker-fájlból.
Egy Dockerfájl épül bele egy Dockerképbe, amely aztán egy Docker konténerként fut:
5.9 ábra: Docker tárgyak

Hogyan kell csomagolni az ML modelleket? 129
A Dockerfájl, Docker kép és Docker konténer alapvető összetevői a konténerek

kialakításának és futtatásának. Ezeket itt jellemezzük:
• Dockerfájl: egy szöveges dokumentum, amely a Docker parancsok készletét

tartalmazza, ahogy a fejlesztő elrendezte egy Docker kép kialakításához. A Docker
képes beolvasni a Dockerfájlt és kialakítani egy Dockerképet.
• Docker kép: Ez a futtatási paraméterek szekvenciális gyűjteménye egy
gyökérfájlrendszer gyűjteményén belüli használathoz egy konténeren belül,
futásidőben. A Docker képek olyanok, mint a konténerek pillanatképei.
A konténerek a Docker képekből állnak össze.
• Docker konténer: A konténerek a Docker képekből állnak össze. Egy konténer
egy Docker kép futásidejű példánya.
Az ML modellek kiszolgálhatók Docker konténerekben a robosztusság, méretezhetőség

és telepítési agnoszticitás érdekében. A későbbi fejezetekben fogunk telepíteni ML
modelleket a Docker használatával a gyakorlati tapasztalat céljából, így érdemes
általánosan megismerni ezt az eszközt.
Mikroszolgáltatás generálása és telepítése

A mikroszolgáltatások lehetővé teszik az olyan szolgáltatások összegyűjtését, amelyek
függetlenül telepíthetők. Ezen szolgáltatások mindegyike jól fenntartható, tesztelhető
és alig kapcsolódik. A mikroszolgáltatásokat az architektúra kezeli, amelyet az
üzleti lehetőségek alapján szerveztek, hogy lehetővé tegye egy rendszernek az üzleti
igények kiszolgálását. Például a Spotify egy monolitikus komplex rendszerről áttért
egy mikroszolgáltatás alapú rendszerre. Ez úgy történt, hogy a komplex rendszert
felosztották szolgáltatásokra olyan konkrét célokkal, mint például a keresőmotor,
tartalomcímkézés, tartalomosztályozás, felhasználói viselkedés elemzése az ajánló
motorhoz és automatikusan generált lejátszási listák. A felosztott mikroszolgáltatásokat
most egy kijelölt csapat fejleszti. Minden mikroszolgáltatás el van különítve, és kevésbé
függenek egymástól. Így könnyebb fejleszteni és fenntartani. A vállalat konzisztens lehet
az ügyfélszolgálattal és folyamatosan javít a szolgáltatás leállítása nélkül.
Jellemzően egy mikroszolgáltatás jön létre, amikor a szerializált fájlokat szétdarabolják egy
konténerezett Docker képpé. Aztán ezek a Docker képek bármely Docker által támogatott
környezetben telepíthetők és kezelhetők. A Docker képek telepítését és kezelését
végezhetjük konténerkezelő eszközök használatával, mint amilyen a Kubernetes. A Docker
rendkívüli hordozhatóságot és együttműködési képességet tesz lehetővé, a Docker képek
könnyen telepíthetők bármely népszerű felhőszolgáltatásra, mint amilyen a Google Cloud,
Azure, vagy AWS. A Docker képek telepíthetők és kezelhetők bármely Docker vállalati
szerveren, adatközpontban vagy valós idejű környezetben, amíg az támogatja a Dockert.
A mikroszolgáltatások kiszolgálhatók egy REST API formátumban, és ez egy népszerű

módja az ML modellek kiszolgálásának. Néhány Python keretrendszer, mint a Flask,
Django és FastAPI azzal lett népszerű, hogy lehetővé tette az ML modelleknek, hogy REST
API mikroszolgáltatásként szolgáljanak. A robosztus és méretezhető rendszerműveletek
irányításához a szoftverfejlesztők szinkronizálhatnak Dockerezett mikroszolgáltatásokkal
egy REST API-n keresztül. Egy Docker-alapú mikroszolgáltatás telepítésének kezeléséhez
a Kubernetes támogatású infrastruktúrán a Kubeflow egy jó opció. Ez felhő-agnosztikus
és futtatható helyben vagy a helyi gépeken. Emellett a Kubeflow a Kubernetes-en alapszik,
de Kubernetes részleteit és nehézségeit egy dobozon belül tartja. A Kubeflow egy modell
kiszolgálásának robosztus módja. Érdemes megismerni ezt az eszközt: https://www.
kubeflow.org/docs/started/kubeflow-overview/.
Következtetéskész modellek
Korábban egy üzleti problémán dolgoztunk, hogy megjósoljuk az időjárást egy kikötőben.
Ahhoz, hogy kialakítsunk egy megoldást ehhez az üzleti problémához, végrehajtottuk
az adatfeldolgozást és az ML modell tanítását, amelyet a modellek szerializálása követett.
Most ebben a részben megismerjük, hogyan történik a következtetés a szerializált
modellen. Ezen rész kódja elérhető a mellékelt a Jupyter jegyzettömbből a fejezethez
tartozó mappában a könyv GitHub adatraktárában. Itt vannak az utasítások a kód
futtatásához:
1. Jelentkezzen be újra az Azure portálra.

2. A Recent Resources részen válassza ki az MLOps_WS munkaterületet,
majd kattintson a Launch Studio gombra. Ez elirányítja Önt az MLOps_WS
munkaterületre.
3. A Manage részen kattintson a Compute részre, majd válassza ki a 4. fejezet:
Machine Learning folyamatok részben létrehozott gépet. Kattintson a Start gombra
a példány elindításához. Amikor a VM készen áll, kattintson a JupyterLab linkre.
4. Most a JupyterLab-ban menjen a fejezetre vonatkozó mappába (05_model_
evaluation_packaging) és nyissa meg a jegyzettömböt (model_
evaluation_packaging.ipynb).
Következtetéskész modellek 131
Csatlakozás a munkaterülethez és a modelltárgyak

importálása
Először importáljuk a szükséges csomagokat, csatlakozunk az ML munkaterülethez
a Workspace() függvény használatával, majd letöltjük a szerializált méretezőt és modellt
az előrejelzések elkészítéséhez. A Scaler fájlt fogjuk használni a bemeneti adatok
méretezéséhez, hogy ugyanolyan méretűek legyenek, mint amit a modell tanításához
használtunk. A Model fájlt ONNX formátumban szerializáltuk. Mind a Scaler, mint
a Model fájlokat a Model() függvény használatával importáltuk:
import pandas as pd
import numpy as np
import warnings
import pickle
from math import sqrt
warnings.filterwarnings('ignore')
from azureml.core.run import Run
from azureml.core.experiment import Experiment
from azureml.core.workspace import Workspace
# Connect to Workspace
ws = Workspace.from_config()
print(ws)
# Load Scaler and model to test
scaler = Model(ws,'scaler').download(exist_ok=True)
svc_model = Model(ws,'support-vector-classifier').
download(exist_ok=True)
Ezen kód futtatása után új letöltött fájlokat fog látni a bal panelen a JupyterLab ablakában.
Modelltárgyak betöltése következtetéshez

Megnyitjuk és betöltjük a Scaler és Model fájlokat a változókba, amelyek
felhasználhatók az ML modell következtetéséhez. A Scaler-t a pickle használatával
olvastuk és töltöttük be egy változóba, és az ONNX-et futásidőben használtuk az ONNX
fájl betöltésére az InferenceSession() használatával a ML modell előrejelzéseihez
with open('scaler.pkl', 'rb') as file:

scaler = pickle.load(file)
# Compute the prediction with ONNX Runtime
import onnxruntime as rt
import numpy
sess = rt.InferenceSession("svc.onnx")
input_name = sess.get_inputs()[0].name
label_name = sess.get_outputs()[0].name
ML modelles következtetés
Az ML modelles következtetés végrehajtásához méretezzük a tesztadatokat és beállítjuk
őket a következtetéshez a fit_transform() metódus használatával. Most végrehajtjuk
a következtetést a tesztadatokon az ONNX munkamenet használatával és futtatjuk
a sess.run() függvénnyel a test_data bemeneti adatok float 32 formátumban
való átadásával. Végül kiírjuk a modell következtetésének eredményeit:
test_data = np.array([34.927778, 0.24, 7.3899, 83, 16.1000, 1])

test_data = scaler.fit_transform(test_data.reshape(1, 6))
# Inference
pred_onx = sess.run([label_name], {input_name: test_data.
astype(numpy.float32)})[0]
print(pred_onx[0])
Ezekkel a lépésekkel sikeresen letöltöttük a szerializált modellt, betöltöttük egy változóba

és végrehajtottuk a következtetést egy tesztadatmintán. A kódblokk várt eredménye az
1 érték.
Összefoglalás
Ebben a fejezetben megismertük az ML modellek értékelésére és értelmezésére szolgáló
különféle módszereket. Tanultunk a termelési tesztelés módszereiről és a modellek
csomagolásának jelentőségéről, miért és hogyan kell csomagolni a modelleket, és
különféle gyakorlatokról és eszközökről a modellek csomagolására az ML modelles
következtetésekhez a termelésben. Végül ahhoz, hogy megértsük a következtetéshez
használt szerializált modellek be- és kicsomagolásának működését, végrehajtottuk az
ML modelles következtetés gyakorlati megvalósítását szerializált modellek használatával
a tesztadatokon.
A következő fejezetben megismerjük az Ön ML modelljeinek telepítését. Csatolják be
biztonsági öveiket és készüljenek fel a modellek termelésben történő telepítésére!
2. rész:
Gépi tanulási
modellek telepítése
méretre
Ez a rész elmagyarázza a gépi tanulási modell telepítésének lehetőségeit, módszereit

és tervezetét. Elmélyedünk a folytonos integráció, kézbesítés és telepítés módszerei
által elérhető termelési telepítések néhány alapvető jellemzőjében. Bepillantást nyerhet
a robosztus és méretezhető mikroszolgáltatások és API-k tervezésébe és fejlesztésébe is,
amelyek az Ön gépi tanulási megoldásait szolgálják.
• 6. fejezet: Az Ön ML rendszerének telepítési alapelvei

• 7. fejezet: Robosztus CI és CD folyamatok kialakítása
• 8. fejezet: API-k és mikroszolgáltatások kezelése
• 9. fejezet: Az Ön ML megoldásának tesztelése és biztosítása
• 10. fejezet: A termelési kiadás lényeges részei
6
Az Ön ML
rendszerének
telepítési alapelvei
Ebben a fejezetben a gépi tanulás (ML) modellek termelésben való telepítésének
alapvető elveiről fog tanulni és megvalósítja az ML modellek telepítését a gyakorlatban
az üzleti problémánál, amelyen dolgozunk. Ahhoz hogy átfogóan megértse és első
kézből tapasztalja, ML modelleket fogunk telepíteni, amelyeket korábban tanítottunk és
csomagoltunk be (a 4. fejezet: Machine Learning folyamatok és az 5. fejezet: Modellértékelés
és csomagolás részben) az Azure ML szolgáltatás használatával két különböző telepítési
célon: egy Azure konténerpéldányon és egy Kubernetes klaszteren.
Azt is meg fogjuk tanulni, hogy kell telepíteni az ML modelleket egy nyílt forráskódú
MLflow-nak nevezett keretrendszer használatával, amellyel már dolgoztunk. ez lehetővé
teszi Önnek, hogy megismerje az ML modellek REST API végpontként történő telepítését
sokféle telepítési célon a két különböző eszköz (az Azure ML szolgáltatás és MLflow)
használatával. Ez ellátja Önt az ML modellek felhőben történő telepítéséhez szükséges
készségekkel bármilyen szituációban.
136 Az Ön ML rendszerének telepítési alapelvei
Ebben a fejezetben azzal kezdjük, hogy megnézzük, miben különbözik az ML a kutatásban

és a termelésben és a következő témák felfedezésével folytatjuk:
• ML a kutatásban vs a termelésben
• Az ML következtetés típusainak megismerése a termelésben
• A leképező infrastruktúra az Ön megoldásánál
• Gyakorlati telepítés (az üzleti problémához)
• A folytonos integráció és folytonos fejlesztés szükségességének felismerése
ML a kutatásban vs a termelésben
Az ML-t a kutatásban adott célokkal és prioritásokkal valósítják meg, hogy javítsák
a legkorszerűbb technológiát, míg az ML célja a termelésben egy szituáció vagy üzlet
optimalizálása, automatizálása vagy javítása.
Az ML modellek telepítésének megértéséhez kezdjük azzal, hogy összehasonlítjuk, hogyan
valósítanak meg egy ML-t a kutatásban és a termelésben (az iparban). Több tényező,
mint például a teljesítmény, prioritás, adat, méltányosság és értelmezhetőség (ahogy a 6.1
táblázat felsorolja) írja le, miben különbözik az ML működése és telepítése a kutatásban
és a termelésben:
6.1 táblázat: ML a kutatásban és a termelésben
Adatok
Általában véve az adatok a kutatási projektekben statikusak, mivel az adatkutatók vagy
statisztikusok egy beállított adatkészleten dolgoznak és próbálják felülmúlni az aktuálisan
legkorszerűbb modelleket. Például nemrég számos áttörést figyeltek meg a természetes
nyelveket feldolgozó modellekben, például a Google BERT-jénél vagy a Baidu XLNet-
jénél. Ezen modellek tanításához az adatokat összegyűjtötték és lefordították statikus
adatkészletté. A kutatás világában a modellek teljesítményének értékeléséhez vagy
teljesítményméréséhez statikus adatkészleteket használnak, ahogy a 6.2 táblázatban
látható (forrás: https://arxiv.org/abs/1906.08237):
ML a kutatásban vs a termelésben 137
6.2 táblázat: A BERT és XLNet teljesítménye (a kutatásban)

Például összehasonlíthatjuk két modell teljesítményét egy népszerű adatkészlet
segítségével, amelyet SQUAD-nak hívnak (10.000+ QnA) 1.1 verzió, amelynél a BERT
pontossága 92,8% és az XLNET pontossága 94,0%. Ehhez hasonlóan a kutatásban
a modellek tanítására és értékelésére használt adat statikus, míg a termelésben vagy az
ipari felhasználási eseteknél az adat dinamikus és folyamatosan változik a környezet,
műveletek, üzlet vagy felhasználók alapján.
Méltányosság
A való életben az elfogult modellek költségesek lehetnek. A nem méltányos vagy elfogult
döntések rossz üzleti és műveleti választásokhoz vezetnek. A termelésben lévő ML
modelleknél fontos, hogy döntések a lehető legméltányosabbak legyenek. Költséges
lehet az üzletnek, ha a termelésben lévő modell nem méltányos. Például nemrég az
Amazon készített egy HR szűrő szoftvert, amely kiszűri a jelentkezőket a munkára
való megfelelőségük alapján. Az ML szakértők az Amazonnál felfedezték, hogy a férfi
jelentkezők előnyben részesültek a női jelentkezőkkel szemben (forrás: https://
www.businessinsider.com/amazon-ai-biased-against-women-no-
surprise-sandra-wachter-2018-10). Ez a fajta rendszerelfogultság költséges
lehet, mivel az Amazon esetében elszalaszthatnak néhány csodálatos tehetséget az
elfogultság miatt. Így a méltányos modellek kritikusak a termelésben, és folyamatosan
monitorozni kell őket. A kutatásban is fontosak a méltányos modellek, de nem olyan
kritikusak, mint a termelésben vagy a való életben, és nem olyan kritikusan monitorozzák
a méltányosságot, mint a termelésben. A kutatás célja a legkorszerűbb technológia
felülmúlása, és a modell méltányossága csak egy másodlagos cél.
Értelmezhetőség
A modell értelmezhetősége kritikus a termelésben, hogy megértsék a korrelációt vagy
okozatot az ML modell döntései és a műveletekre vagy üzletre gyakorolt hatás között, hogy
egy adott üzletet vagy feladatot optimalizáljon, javítson vagy automatizáljon. A kutatásban
nem ez a helyzet, ahol a cél a legkorszerűbb eredmények elérése vagy felülmúlása, és itt
a jobb teljesítmény (például a pontosság vagy más mérőszámok) a prioritás. A kutatás
esetében az ML értelmezhetősége jó, ha van, de nem követelmény. Jellemzően az ML
projektek inkább a kimenetelek előrejelzésével foglalkoznak, mint az okozat megértésével.
Az ML modellek nagyszerűek a korrelációk megtalálásában az adatok között, de az
okozatokban nem. Nem akarunk abba a hibába esni, hogy azonosnak tekintjük a társítást
az okkal a vállalkozásunkban. Annak a lehetőségét, hogy az ML-re támaszkodjunk,
ez a probléma komolyan akadályozza. Ez a probléma komolyan korlátozza azon
lehetőségünket, hogy az ML-t döntéshozásra használjuk. Olyan erőforrásokra van
szükségünk, amelyek megérthetik az okozati összefüggéseket az adatok között, olyan ML
megoldásokat alakítanak ki, amelyek jól általánosítanak üzleti szempontból. A jó modell
értelmezhetőségi mechanizmusok javíthatják az okozat felismerését és lehetővé teszi,
hogy olyan ML megoldásokat készítsünk, amely jól általánosít és képes korábban nem
látott adatokat kezelni. Ennek eredményeként megbízhatóbb és átláthatóbb döntéseket
hozhatunk az ML használatával.
A termelés esetében (egy üzleti felhasználási esetnél) az értelmezhetőség hiánya
egyáltalán nem ajánlott. Nézzünk meg egy elméleti esetet. Tételezzük fel, hogy Ön rákos
és ki kell választania egy sebészt a műtétje végrehajtásához. Két sebész érhető el, egy
ember (80%-os gyógyulási aránnyal) és a másik egy MI fekete dobozos modell (90%-os
gyógyulási aránnyal), amelynél nem értelmezhető vagy magyarázható, hogyan működik,
de magas a gyógyulási arány. Mit választana? MI-t vagy egy sebészt a rák gyógyítására?
Egyszerűbb lenne a sebészt lecserélni az MI-re, ha a modell nem egy fekete dobozos
modell lenne. Bár az MI jobb, mint a sebész, a modell megértése nélkül a döntés, bizalom
és megfelelőség problémás. A modell értelmezhetősége létfontosságú a jogi döntések
meghozásához. Ezért lényeges a modell értelmezhetősége az ML-nél a termelésben.
A következő fejezetekben többet fogunk erről tanulni.
Teljesítmény
Amikor az ML modellek teljesítményére terelődik a szó, a kutatásban a legkorszerűbb modellek
javításán van a fókusz, míg a termelésben az egyszerűbb modellek helyett a jobb modellek
kialakításán van a hangsúly, amely kiszolgálja az üzleti igényeket (a legkorszerűbb modellek
nincsenek fókuszban).
Az ML következtetés típusainak megismerése a termelésben 139
Prioritás
A kutatásban a modellek gyorsabb és jobb betanítása a prioritás, míg a termelésben
a gyorsabb következtetés a prioritás, mivel a fókusz a döntéshozáson és az üzleti igények
valós idejű kiszolgálásán van.
Az ML következtetés típusainak megismerése

a termelésben
Az előző részben láttuk az ML prioritásait a kutatásban és a termelésben. Az üzleti igények
kiszolgálásához a termelésben az ML modellek különböző telepítési célok használatával
következtetnek az igénytől függően. Egy ML modell használatával végzett előrejelzést vagy
döntéshozást ML modelles következtetésnek nevezünk. Ismerjük meg az ML modellek
különböző telepítési célokra történő telepítésének módjait, hogy az üzleti igények szerint
irányítsuk az ML következtetést.
Telepítési célok
Ebben a részben megnézzük a telepítési célok különböző típusait, és hogy miért és hogyan
szolgáljuk ki az ML modelleket a következtetéshez ezeken a telepítési célokon. Kezdésként
nézzünk meg egy virtuális gépet vagy egy helyi szervert.
Virtuális gépek
Virtuális gépek lehetnek a felhőben vagy helyben az üzlet vagy szervezt IT beállításaitól függően.
Az ML modellek virtuális gépeken történő kiszolgálása elég gyakori. Az ML modellek virtuális
gépeken való kiszolgálása webszolgáltatások formájában történik. A virtuális gépen futó
webszolgáltatás egy felhasználói kérést (HTTP kérés formájában) kap, amely tartalmazza
a bemeneti adatokat. A webszolgáltatás a bemeneti adatok átvétele után előfeldolgozza azt az ML
modell következtetéséhez szükséges formátumban, amely webszolgáltatás része. Miután az ML
modell elkészíti az előrejelzést vagy végrehajtja a feladatot, a kimenetet átalakítja és egy felhasználó
által olvasható formátumban mutatja be. Gyakran a formátum JavaScript Object Notation
(JSON) vagy Extensible Markup language string (XML). Általában egy webszolgáltatást egy
REST API formájában szolgálnak ki. A REST API webszolgáltatások többféle eszköz használatával
fejleszthetők; például FLASK vagy FAST API webalkalmazási eszközök használhatók a REST API
webszolgáltatások fejlesztésére Python vagy Spring Boot felhasználásával Java-ban, vagy Plumber-
rel R-ben, az igényektől függően. Ezzel párhuzamosan a virtuális gépek kombinációját használják
a webszolgáltatás robosztusságának méretezésére és fenntartására.
A forgalom irányítása és a gépek méretezése érdekében egy terheléskiegyenlítőt

használnak a bejövő kérések virtuális gépekre történő kiküldéséhez az ML modell
következtetésénél. Így vannak telepítve az ML modellek a virtuális gépekre a felhőben
vagy helyben, hogy kiszolgálják az üzleti igényeket, ahogy azt a következő ábra mutatja:
6.1 ábra: Telepítés a virtuális gépeken
Konténerek
A konténerek egy megbízható mód a Linux operációs rendszert használó alkalmazások
futtatására, személyre szabott beállításokkal. A konténer egy alkalmazás, amely egyedi
beállítással fut, ahogy a fejlesztő beállította. A konténerek egy alternatív és erőforrás-
takarékosabb módjai a modellek kiszolgálásának a virtuális gépeknél. Úgy működnek, mint
a virtuális gépek, mivel van saját futásidejű környezetük, amely elszigetelt és a memóriára,
fájlrendszerre és folyamatokra korlátozódik.
A tervezők testre szabhatják a konténereket, hogy a szükséges erőforrásokra korlátozzák
őket, mint amilyen a memória, fájlrendszer és a folyamatok, a virtuális gépek is ilyen
beállításokra vannak korlátozva. Rugalmasabbak és modulárisan működnek és így
optimálisabban és hatékonyabban használják az erőforrásokat. lehetővé teszik a nullára
méretezést, mivel a konténerek csökkenthetők nulla másolatra és kérésre futtathatnak
egy biztonsági mentést. Így lehetséges az alacsonyabb számítási kapacitás fogyasztása
a virtuális gépeken futó webszolgáltatásokhoz képest. Az alacsonyabb számítási
kapacitásfogyasztás eredményeként lehetséges a költségmegtakarítás a felhőben.
A konténereknek számos előnye van; azonban egyik hátrányuk lehet a konténerekkel

végzett munka komplexitásigénye, mivel ez szakértelmet igényel.
Van néhány különbség a konténerek és virtuális gépek működése között. Például egy
virtuális gépen belül futhat több konténer, amelyek a virtuális géppel osztoznak az
operációs rendszeren és erőforrásokon, de a virtuális gép futhat a saját erőforrásain
és operációs rendszerén. A konténerek működhetnek modulárisan, de a virtuális
gépek csak egyetlen egységként működhetnek. A Docker használható a konténerek
kialakítására és telepítésére; azonban vannak olyan alternatívák, mint a Mesos és CoreOS
rkt. Egy konténert jellemzően az ML modellel és webszolgáltatással együtt csomagolnak
az ML következtetés irányítására ahhoz hasonlóan, ahogyan egy webszolgáltatásba
csomagolt ML modellt kiszolgálunk a virtuális gépen. A konténereket irányítani kell,
hogy a felhasználók elfogyasszák. A konténerek irányítása a telepítés, kezelés, méretezés és
hálózatban működés automatizálását jelenti. A konténereket egy olyan konténerirányítási
rendszerrel irányítják, mint amilyen a Kubernetes. A következő ábrán (a kérések
mennyisége alapján) automatikus méretezésű konténerirányítást láthatunk:
6.2 ábra: Telepítés a konténereken

Szerver nélküli
A szerver nélküli számítás, ahogy a neve sugallja, nem tartalmaz virtuális gépet vagy
konténert. Megszünteti az infrastruktúrakezelési feladatokat, mint például az OS kezelése,
szerverkezelés, kapacitásbiztosítás és tárhelykezelés. A szerver nélküli számítás lehetővé
teszi a fejlesztőknek és szervezeteknek, hogy a fő termékükre koncentráljanak az olyan
hétköznapi feladatok helyett, mint a szerverek kezelése és működtetése, akár a felhőn,
akár helyben vannak. A szerver nélküli számítás felhőalapú szolgáltatások használatával
irányítható.
Például a Microsoft Azure az Azure Functions-t használja, és az AWS a Lambda
functions-t használja a szerver nélküli alkalmazások telepítéséhez. A szerver nélküli
alkalmazások telepítése magába foglalja egy fájlgyűjtemény elküldését ( .zip fájlok
formájában) az ML alkalmazások futtatásához. A .zip archívum jellemzően egy adott
függvénnyel vagy metódussal rendelkező fájl, amely futtatható. A zip archívumot feltöltik
a felhőplatformra a felhőszolgáltatások használatával és szerver nélküli alkalmazásként
telepítik. A telepített alkalmazás egy API végpontként szolgál, hogy elküldje a bemenetet
az ML modellt kiszolgáló szerver nélküli alkalmazásnak.
Számos előnye lehet a szerver nélküli alkalmazásokat használó ML modellek telepítésének:
nem szükséges telepíteni vagy frissíteni a függőségeket vagy karbantartani vagy frissíteni
a rendszereket. A szerver nélküli alkalmazások igény szerint automatikusan méreteznek
robusztus az egész teljesítményük. A szinkron (a végrehajtás egymás után történik
egyetlen sorozatban, A → B → C → D) és aszinkron (a kivétel párhuzamosan vagy egy
prioritás alapján történik, nem sorrendben: A → C → D → B vagy A és B egymással
párhuzamosan, illetve C és D párhuzamosan) műveletek is támogatottak a szerver
nélküli funkcióknál. Azonban van néhány hátrány is, például az olyan felhő erőforrások
elérhetősége, mint a RAM vagy tárhely vagy GPU, amelyek kritikus követelmények az
olyan nehéz modellek futtatásához, mint amilyenek a mély tanulásos vagy megerősítéses
tanulási modellek. Például az erőforráskorlát falába ütközhetünk, ha egy modellt a szerver
nélküli műveletek használata nélkül telepítettünk. A telepített modell vagy alkalmazás
nem fog automatikusa méretezni, és így korlátozza az elérhető számítási kapacitás.
Ha a limitnél több felhasználó következtet a modellel vagy alkalmazással, az elérhetetlen
erőforrás akadályba ütközünk. A következő ábrán a hagyományos alkalmazások és szerver
nélküli alkalmazások fejlesztését láthatjuk:
6.3 ábra: Hagyományos és szerver nélküli telepítések

A szerver nélküli alkalmazások fejlesztéséhez a fejlesztőnek csak az alkalmazás logikájára
kell koncentrálnia és nem kell aggódnia kiszolgálói oldal vagy biztonsági kód miatt,
amelyre a felhőszolgáltatások ügyelnek a szerver nélküli alkalmazások telepítésekor.
Modell streaming
A modell streaming egy modellkiszolgálási módszer a streaming adatok kezelésére.
A streaming adatoknak nincs kezdete vagy vége. Minden pillanatban ezernyi forrásban
képződik adat, és amint lehet fel kell dolgozni és elemezni kell őket. Például a Google
Search eredményeit valós időben kell feldolgozni. A modell streaming egy másik módja
az ML modellek telepítésének. Két fő előnye van más modellkiszolgáló technikákkal
szemben, mint amilyenek REST API-k vagy tömeges feldolgozási megközelítések. Az első
előnye az aszinkronitás (több kérés egyidejű kiszolgálása). A REST API ML alkalmazások
robosztusak és méretezhetőek, de meg van az a korlátjuk, hogy szinkronok (a klienstől
érkező kéréseket első be első ki alapon dolgozzák fel), amely magas késéshez és erőforrás-
felhasználáshoz vezethet. Ennek a korlátozásnak a leküzdéséhez elérhető a folyamatos
feldolgozás. Ez eredendően aszinkron, mivel a felhasználónak vagy kliensnek nem kell
irányítania vagy várnia a rendszerre, hogy feldolgozza a kérést.
A folyamatos feldolgozás aszinkron módon feldolgozni és egyből kiszolgálni

a felhasználókat. Ehhez a folyamatos feldolgozás egy üzenetbrókert használ
a felhasználóktól vagy kliensektől érkező üzenetek fogadására. Az üzenetbróker úgy
engedi az adatot, ahogy az érkezik, és szétteríti a feldolgozást az időben. Az üzenetbróker
szétválasztja a beérkező kéréseket és kezeli a kommunikációt a felhasználók vagy kliensek
és a szolgáltatás között anélkül, figyelemmel lenne a többiek működésére, ahogy a 6.4
ábrán látható. Van pár lehetőség a streaming üzenetbrókerekre, mint például az Apache
Storm, Apache Kafka, Apache Spark, Apache Flint, Amazon Kinesis és StreamSQL. Az Ön
által választott eszköz az IT beállításoktól és architektúrájától függ.
6.4 ábra: Modell streaming folyamat

A folyamatos feldolgozás második előnye az, amikor több modell következtet egy ML
rendszerben. A REST API-k nagyszerűek az egy vagy két modelles feldolgozáshoz,
de késést és a számítási erőforrások nagy mennyiségű felhasználását eredményezik,
amikor több modellel kell következtetni, és ennek tetejébe szinkron következtetésre
korlátozódnak.
Több modell esetén a folyamatos feldolgozás egy jó lehetőség, mivel minden modellt és
tárgyat (kód és fájlok), amely az ML rendszer futásához szükséges, egybe lehet csomagolni
és telepíteni egy folyamatos feldolgozó motorra (saját gépklaszteren fut és kezeli az
erőforrás-allokációt az adatfeldolgozás kiosztásához).
Például nézzük meg egy intelligens e-mail asszisztens felhasználási esetét, amelyet az
ügyfélszolgálat automatizálásával bíztak meg, ahogy a 6.4 ábrán látható. A felhasználók
kiszolgálásához szükséges válaszok automatizálása érdekében az e-mail asszisztens
rendszer előrejelzést hajt végre több modell használatával:
• Megjósolja az e-mail osztályát, mint spam, ügyfél vagy megújítás

• Szándékfelismerés
• Vélemény előrejelzése
• Válasz/szöveg generálása
Ez a négy modell a REST API végpontokon telepítve magas késést és karbantartási

költségeket fog generálni, míg egy streaming szolgáltatás egy jó alternatíva lehet,
mivel több modellt képes csomagolni és kiszolgálni egy folyamatként, és folyamatosan
kiszolgálja a felhasználói kéréseket egy folyamat formájában. Így az ilyen esetekben
a streaming az ajánlott a REST API végpontok helyett.
Az infrastruktúra leképezése a megoldásunknál

Ebben a részben feltérképezzük az infrastruktúraigényeket és telepítési célokat, amelyek
a sokféle üzleti igények kezeléséhez szükségesek, ahogy a 6.3 táblázatban látjuk:
6.3 táblázat: Az infrastruktúra leképezése az ML megoldásoknál

Az Ön felhasználási esetétől függően érdemes kiválasztani a megfelelő infrastruktúrát
és telepítési célokat az ML modellek kiszolgálásához, hogy üzleti vagy működési hatást
generáljanak.
Gyakorlati telepítés (az üzleti problémához)

Ebben a részben megtanuljuk, hogyan kell telepíteni a megoldásokat az üzleti
problémához, amelyen dolgozunk. Eddig elvégeztük az adatok feldolgozását, ML modell
tanítását, szerializáltuk a modelleket és regisztráltuk őket az Azure ML munkaterületen.
Ebben a részben megismerjük, hogyan történik a következtetés a szerializált modellen
egy konténeren és egy automatikusan méretező klaszteren. Ezek a telepítések széleskörű
ismereteket nyújtanak és jól felkészítik Önt a jövőbeni feladatokra.
A Python-t fogjuk elsődleges programozási nyelvként használni, és a Docker-t és
Kubernetes-t a konténerek kialakításához és telepítéséhez. Egy REST API szolgáltatás
telepítésével kezdünk egy Azure konténerpéldányon az Azure ML használatával.
Következőként telepítünk egy REST API szolgáltatást egy automatikusan méretező
klaszteren az Azure ML-t használó Kubernetes használatával (a konténer kezeléséhez),
és végül telepítünk egy Azure konténerpéldányt az MLflow és egy nyílt forráskódú
ML keretrendszer használatával; így megtanuljuk több eszköz használatát és az ML
modellek felhőre (Azure) történő telepítését. Kezdjük a telepítéssel az Azure Container
Instances-on (ACI).
A modell telepítése az ACI-n

A telepítés megkezdéséhez menjen a GitHub adatraktárba, amelyet korábban klónoztunk
az Azure DevOps-on (a 3. fejezet: A kód találkozik az adattal részben), keresse meg a 06_
ModelDeployment nevű mappát, és kövesse a megvalósítás lépéseit a 01_Deploy_
model_ACI.ipynb jegyzettömbben:
1. Kezdésként importáljuk a szükséges csomagokat és ellenőrizzük az Azure ML ADK

verzióját, ahogy az a következő kódban látható:
%matplotlib inline
import numpy as np
import matplotlib.pyplot as plt
import azureml.core
from azureml.core import Workspace
# display the core SDK version number

print("Azure ML SDK Version: ", azureml.core.VERSION)
Az előző kód kiírja az Azure ML SDK verzióját (például 1.10.0; az Ön verziója

eltérhet ettől).
Gyakorlati telepítés (az üzleti problémához) 147
2. Következőként az Azure ML SDK workspace függvényének használatával

csatlakozunk az ML munkaterülethez és letöltjük a szükséges szerializált fájlokat és
a korábban betanított modellt a munkaterület Model függvényének használatával.
A szerializált scaler és model használandó a következtetés vagy előrejelzés
végrehajtásához. A Scaler fájlt fogjuk használni a bemeneti adatok kicsinyítéséhez,
hogy ugyanolyan méretűek legyenek, mint amit a modell tanításához használtunk, és
a model fájlt használjuk az előrejelzések készítésére a bejövő adatok alapján:
print(ws.name, ws.resource_group, ws.location, sep =
'\n')
model = Model(ws,'support-vector-classifier').
3. Miután letöltöttük a scaler és a model fájlokat, a következő lépés a scoring fájl

előkészítése. A scoring fájlt használjuk az ML modellek következtetéséhez az ML
szolgáltatással telepített konténerekben az Azure konténerpéldányban és Kubernetes
klaszterben. A scoring szkript a felhasználó által átadott bemeneteket használja
és az ML modell következtet az előrejelzéshez, majd kiszolgálja a kimenetet az
előrejelzéssel a felhasználónak. Két elsődleges függvényt tartalmaz: init()
és run(). Azzal kezdjük, hogy importáljuk a szükséges könyvtárakat majd
meghatározzuk az init() és run() függvényeket:
%%writefile score.py
import json
import numpy as np
import os
import pickle
import joblib
import onnxruntime
import time
%%writefile score.py beleírja ezt a kódot egy score.py nevű fájlba,

amelyet később az ML szolgáltatás részeként csomagolunk bele a konténerbe az ML
modelles következtetés végrehajtásához.
4. Meghatározzuk az init() függvényt; mely letölti a szükséges modelleket
deszerializálja őket változókká, amelyeket az előrejelzésekhez használunk:
def init():
global model, scaler, input_name, label_name
scaler_path = os.path.join(os.getenv('AZUREML_MODEL_
DIR'), 'scaler/2/scaler.pkl')
# deserialize the scalar file back into a variable to
be used for inference
scaler = joblib.load(scaler_path)

model_onnx = os.path.join(os.getenv('AZUREML_MODEL_DIR'),
'support-vector-classifier/2/svc.onnx')
# deserialize support vector classifer model
model = onnxruntime.InferenceSession(model_onnx,
None)
input_name = model.get_inputs()[0].name
label_name = model.get_outputs()[0].name
Az onnxruntime használatával deszerializálhatjuk a support vector osztályozó

modellt. Az InferenceSession() függvény használatos a következtetéshez való
modell deszerializálására és kiszolgálására, és az input_name és label_name
változókat a deszerializált modellből töltjük be.
5. Dióhéjban az init() függvény tölti be a fájlokat (model és scaler) illetve
deszerializálja és kiszolgálja az előrejelzésekhez szükséges modellt és tárgyfájlokat,
amelyeket a run() függvény használ a következőképpen:
def run(raw_data):
try:
data = np.array(json.loads(raw_data)
['data']).astype('float32')
data = scaler.fit_transform(data.
reshape(1, 7))
# make prediction
model_prediction = model.run([label_
name], {input_name: data.astype(np.float32)})[0]
# you can return any data type as long as it is JSON-

serializable

except Exception as e:
model_prediction = 'error'

return model_prediction
A run() függvény argumentumként fogadja a nyers bejövő adatokat, végrehajtja

az ML modelles következtetést és visszaadja az előrejelzett eredményeket
kimenetként. Amikor meghívják, a run() függvény fogadja a bejövő adatokat,
amelyeket megtisztítottak és betöltöttek egy változóba a méretezéshez. A bejövő
adatokat a scaler használatával méretezték, amelyet korábban betöltöttek az
init() függvénybe. A modell következtetési lépése következik, amely a fő lépés,
a méretezett adatok következtetésével hajtja végre a modell, ahogy előbb láthattuk.
Aztán a modellből következtetett előrejelzés visszatér kimenetként. Így a scoring fájl
beleíródik a score.py fájlba, hogy felhasználjuk a telepítésnél.
6. Következőként a szolgáltatás egy Azure konténerpéldányon történő telepítésének
kritikus részével folytatjuk. Ehhez meghatározunk egy telepítési környezetet
egy környezet létrehozásával, amelyet Yet Another Markup Language
(YAML) myenv.yml fájlnak nevezünk, ahogy a következő kódban látható.
A CondaDependencies() függvény használatával megemlítjük az összes pip
csomagot, amelyeket telepíteni kell azon a Docker konténeren belül, amelyet
ML szolgáltatásként fogunk telepíteni. Az olyan csomagokat, mint a numpy,
onnxruntime, joblib, azureml-core, azureml-defaults és scikit-
learn a konténeren belül telepítettük a környezetfájl aktiválásával:
from azureml.core.conda_dependencies import

CondaDependencies
myenv = CondaDependencies.create(pip_packages=["numpy",
"onnxruntime", "joblib", "azureml-core", "azureml-
defaults", "scikit-learn==0.20.3"])
with open("myenv.yml","w") as f:
f.write(myenv.serialize_to_string())
7. Következőként meghatározzuk a következtetési konfigurációt az

InferenceConfig() függvény használatával, amely a score.py fájlt és a
környezetfájlt veszi argumentumnak, amikor meghívjuk. Következőként meghívjuk
az AciWebservice() függvényt, hogy elindítsuk a számítási konfigurációt (cpu_
cores és memory) az aciconfig változóban a következőként:
from azureml.core.model import InferenceConfig

from azureml.core.environment import Environment
myenv = Environment.from_conda_specification(name="myenv",
file_path="myenv.yml")
inference_config = InferenceConfig(entry_script="score.
py", environment=myenv)
from azureml.core.webservice import AciWebservice
aciconfig = AciWebservice.deploy_configuration(cpu_
cores=1,
memory_gb=1,
tags={"data": "weather"},
description='weather-prediction')
8. Így már mindent beállítottuk az ML vagy webszolgáltatás telepítéséhez az ACI-n.

A score.py fájlt fogjuk használni, a környezetfájlt (myenv.yml), inference_
config, és aci_config fájlokat az ML vagy webszolgáltatás telepítéséhez. Rá kell
mutatnunk a telepítendő modellekre vagy tárgyakra. Ehhez a Model() függvényt
használjuk, hogy betöltsük a scaler és model fájlokat a munkaterületről és
felkészítsük őket a telepítésre:
%%time
from azureml.core.webservice import Webservice
model1 = Model(ws, 'support-vector-classifier')
model2 = Model(ws, 'scaler')
service = Model.deploy(workspace=ws,
name='weatherprediction',
models=[model1, model2],
inference_config=inference_config,
deployment_config=aciconfig)
service.wait_for_deployment(show_output=True)
9. Miután a modelleket a model1 és model2 változókba csatoltuk, folytatjuk

a webszolgáltatásként történő telepítésüket. A deploy() függvényt használjuk
a csatolt modellek webszolgáltatásként történő telepítéséhez az ACI-n, ahogy az
előző kódban láthattuk. A folyamat nagyjából 8 percig tart, szóval dőljön hátra és
élvezze a szolgáltatás telepítését. Egy ehhez hasonló üzenetet fog látni:
Running..................................................
............................
Succeeded
ACI service creation operation finished, operation
"Succeeded"
CPU times: user 610 ms, sys: 103 ms, total: 713 ms
Wall time: 7min 57s
Gratulálunk! Sikeresen telepítette az első ML szolgáltatását az MLOps használatával.

10. Ellenőrizzük a telepített szolgáltatás működését és robosztusságát. Nézzük meg
a szolgáltatás URL-jét és Swagger URL-jét, ahogy a következő kódban látható.
Ezeket az URL-eket használhatja az ML modelles következtetés végrehajtására
a választási szerinti bemeneti adatokon, valós időben:
print(service.scoring_uri)
print(service.swagger_uri)
11. Ellenőrizze az Azure ML munkaterületen telepített szolgáltatást.

12. Most tesztelhetjük a szolgáltatást az Azure ML SDK service.run()
függvényének használatával, ha néhány bemeneti adatot adunk neki
import json
test_sample = json.dumps({'data': [[34.927778, 0.24,
7.3899, 83, 16.1000, 1016.51, 1]]})
test_sample = bytes(test_sample,encoding = 'utf8')
prediction = service.run (input_data=test_sample)
A jellemzők a bemeneti adatban ilyen sorrendben vannak: Temperature_C,

Humidity, Wind_speed_kmph, Wind_bearing_degrees, Visibility_
km, Pressure_millibars, and Current_weather_condition. Kódoljuk
a bemeneti adatok UTF-8 formátumban a zökkenőmentes következtetéshez.
A modell következtetésekor a service.run() használatával a modell a 0 vagy
1 előrejelzési értékekkel tér vissza. 0 jelenti a tiszta eget és 1 jelenti, hogy esni fog.
A szolgáltatás használatával, időjárási előrejelzéseket készíthetünk Turku kikötőben,
amivel megbíztak minket az üzleti problémánál.
13. A telepített szolgáltatás egy REST API webszolgáltatás, amellyel következtethetünk
egy HTTP kéréssel a következőképpen:
import requests
headers = {'Content-Type': 'application/json', 'Accept':
'application/json'}
if service.auth_enabled:
headers['Authorization'] = 'Bearer '+ service.get_
keys()[0]
elif service.token_auth_enabled:
token()[0]
scoring_uri = service.scoring_uri
print(scoring_uri)
response = requests.post(scoring_uri, data=test_sample,
headers=headers)
print(response.status_code)
print(response.elapsed)
print(response.json())
Amikor egy POST kérés érkezik a bemeneti adatok átadásával, a szolgáltatás

visszaadja a modell előrejelzését a 0 vagy 1 formájában. Amikor egy ilyen
előrejelzést kap, akkor a szolgáltatása működik és elég robosztus, hogy kiszolgálja
a termelés igényeit.
Következőként telepíteni fogjuk a szolgáltatást egy automatikusan méretező
klaszteren; ez az ideális a termelési szituációkban, mivel a telepített szolgáltatás
automatikusan méretezhet és szolgálhatja ki a felhasználói igényeket.
A modell telepítése az Azure Kubernetes Service-

en (AKS)
A telepítés megkezdéséhez menjen a Git adatraktárba, amelyet klónoztunk az Azure
DevOps-on a 3. fejezet: A kód találkozik az adattal részben, keresse meg a 06_
ModelDeployment mappát, és kövesse a megvalósítás lépéseit a 02_Deploy_model_
AKS.ipynb jegyzettömbben:
1. Ahogy az előző részben tettük, a szükséges csomagok importálásával kezdjük,

mint amilyen a matplotlib, numpy, és azureml.core, és a szükséges
függvényekével, mint amilyen a Workspace és Model az azureml.core
csomagból, ahogy a következő kódblokkban látható:
%matplotlib inline
import numpy as np
import matplotlib.pyplot as plt
import azureml.core

2. Írja ki az Azure ML SDK verzióját és ellenőrizze a verziót (kiírja, hogy például

1.10.0; az Ön verziója eltérhet ettől). Használja a konfigurációs fájlt és
a Workspace függvény csatlakozik a munkaterületéhez, ahogy a következő
kódblokkban látható:
'\n')
model = Model(ws,'support-vector-classifier').
3. Töltse le a model és scaler fájlokat, ahogy korábban tettük. A model és a

scaler fájlok letöltése után a következő lépés, hogy előkészítjük a scoring
fájlt, amelyet az ML modellek következtetéséhez használunk az ML szolgáltatással
telepített konténerekben. A scoring szkript a felhasználó által átadott bemenetet
használja, és az ML modell következtet az előrejelzéshez, majd kiszolgálja
a kimenetet az előrejelzéssel a felhasználónak. Azzal kezdjük, hogy importáljuk
a szükséges könyvtárakat, ahogy az a következő kódblokkban látható:
%%writefile score.py
import json
import numpy as np
import os
import pickle
import joblib
import onnxruntime
import time
4. Ahogy az ACI telepítésnél tettük korábban a score.py fájllal, ugyanazt a fájlt

fogjuk használni. Két elsődleges függvényt tartalmaz: init() és run().
Meghatározzuk az init() függvényt; mely letölti a szükséges modelleket és
deszerializálja őket változókká, amelyeket előrejelzésekhez használunk:
def init():
global model, scaler, input_name, label_name
DIR'), 'scaler/2/scaler.pkl')
# deserialize the model file back into a sklearn
model

model_onnx = os.path.join(os.getenv('AZUREML_MODEL_
DIR'), 'support-vector-classifier/2/svc.onnx')
None)
5. Ahogy az előző részben tettük az ACI telepítésnél, az onnxruntime

csomagolófüggvény használatával deszerializálhatjuk a support vector osztályozó
modellt. Az InferenceSession() függvény használatos a következtetésre
használt modell deszerializálására és kiszolgálására, és betöltjük az input_name
és label_name változókat a deszerializált modellből. Dióhéjban az init()
függvény tölti be a fájlokat (model és scaler), illetve deszerializálja és kiszolgálja
az előrejelzésekhez szükséges modellt és tárgyfájlokat, amelyeket a run() függvény
használ:
def run(raw_data):
try:
data = np.array(json.loads(raw_data)
['data']).astype('float32')
data = scaler.fit_transform(data.
reshape(1, 7))
# make prediction
model_prediction = model.run([label_
name], {input_name: data.astype(np.float32)})[0]
# you can return any data type as
long as it is JSON-serializable

model_prediction = 'error'

return model_prediction
Ugyanazt a run() függvényt fogjuk használni, mint az előző A modell telepítése

ACI-n részben az AKS telepítéshez. Ezzel folytathatjuk a szolgáltatás telepítését
az AKS-en.
6. Következőként a szolgáltatás Azure Kubernetes Service-en történő telepítésének

kritikus részével folytatjuk. Hozzon létre egy környezetet, amelyben a modelljét
telepíteni fogja a CondaDependencies() függvény használatával. Meg fogjuk
említeni az összes szükséges pip és conda csomagokat, amelyeket telepíteni kell
azon a Docker konténeren belül, amelyet ML szolgáltatásként fogunk telepíteni.
Az olyan csomagokat, mint a numpy, onnxruntime, joblib, azureml-
core, azureml-defaults és scikit-learn a konténeren belül telepítettük
a környezetfájl aktiválásával: Következőként használja a nyilvánosan elérhető
konténert a Microsoft Container Registry-ben bármilyen hitelesítés nélkül.
Ez a konténer telepíteni fogja a környezetét és a cél AKS-ére történő telepítéshez lesz
konfigurálva:
from azureml.core import Environment
from azureml.core.conda_dependencies import
CondaDependencies
conda_deps = CondaDependencies.create(conda_
packages=['numpy','scikit-learn==0.19.1','scipy'], pip_
packages=["numpy", "onnxruntime", "joblib", "azureml-
core", "azureml-defaults", "scikit-learn==0.20.3"])
myenv = Environment(name='myenv')
myenv.python.conda_dependencies = conda_deps
# use an image available in public Container Registry

without authentication
myenv.docker.base_image = "mcr.microsoft.com/azureml/
o16n-sample-user-base/ubuntu-miniconda"
7. Most határozza meg a következtetési konfigurációt az InferenceConfig()

függvény használatával, amely a score.py fájlt és a környezetváltozót veszi
argumentumnak, amikor meghívja:
inf_config = InferenceConfig(entry_script='score.py',
environment=myenv)
8. Most készen állunk az ML vagy webszolgáltatás telepítésére az Azure Kubernetes

Service-en (automatikusan méretező klaszter). Ehhez szükségünk lesz egy
AKS klaszter létrehozására, amelyet hozzá kell csatolnunk az Azure ML
munkaterülethez. Válasszon egy nevet a klaszterének, és ellenőrizze, hogy létezik-e,
a ComputeTarget() függvény használatával. Ha nem, a ComputeTarget().
create függvény használatával hozzon létre vagy biztosítson egy klasztert.
A klaszter létrehozásához egy munkaterület objektum, ws; egy szolgáltatásnév,
és egy biztosítási konfiguráció szükséges. Az alapértelmezett paramétereket
használjuk a biztosítási konfigurációhoz, hogy egy alapértelmezett klasztert
hozzunk létre:
%%time
from azureml.core.compute import ComputeTarget
from azureml.core.compute_target import
ComputeTargetException
from azureml.core.compute import AksCompute,
ComputeTarget
# Choose a name for your AKS cluster

aks_name = 'port-aks'
# Verify that cluster does not exist already

try:
aks_target = ComputeTarget(workspace=ws, name=aks_
name)
print('Found existing cluster, use it.')
except ComputeTargetException:
# Use the default configuration (can also provide
parameters to customize)
prov_config = AksCompute.provisioning_configuration()
# Create the cluster

aks_target = ComputeTarget.create(workspace = ws,
name = aks_name,
provisioning_configuration = prov_config)
if aks_target.get_status() != "Succeeded":
aks_target.wait_for_completion(show_output=True)
A klaszter létrehozása után a következő üzenetet fogja megkapni:

Creating.................................................
........................
SucceededProvisioning operation finished, operation
"Succeeded"
Gratulálok, sikeresen létrehozott egy klasztert!
Megjegyzés
Ha már létezik egy klaszter ugyanazzal az AKS klaszternévvel ( aks_name
= port-aks), akkor az új klaszter nem jön létre. Helyette a meglévő
klaszter (itt a port-aks nevű) lesz csatolva a munkaterülethez a további
telepítésekhez.
9. Következőként az ML szolgáltatás Kubernetes klaszterben történő telepítésének

kritikus feladatával folytatjuk. A telepítéshez teljesítenünk kell néhány előfeltételt,
mint például a modellek csatolását a telepítéshez. A modelleket a Model()
függvény használatával csatoljuk, hogy betöltsük a scaler és model fájlokat
a munkaterületről és felkészítsük őket a telepítésre, ahogy a következő kódban
látható:
from azureml.core.webservice import Webservice,
AksWebservice
# Set the web service configuration (using default here)
aks_config = AksWebservice.deploy_configuration()
%%time
from azureml.core.webservice import Webservice
model1 = Model(ws, 'support-vector-classifier')
model2 = Model(ws, 'scaler')
10. Így már mindent beállítottuk a szolgáltatás telepítéséhez az AKS-n. A szolgáltatást

a Model.deploy() függvény segítségével telepítjük az Azure ML SDK-ból,
amely meghíváskor a ws munkaterület objektumot; és a service_name; models;
inference_config; deployment_config és deployment_target fájlokat
veszi argumentumként:
%%time
aks_service_name ='weatherpred-aks'
aks_service = Model.deploy (workspace=ws,

name=aks_service_name,
models=[model1, model2],
inference_config=inf_config,
deployment_config=aks_config,
deployment_target=aks_target)
aks_service.wait_for_deployment(show_output = True)
print(aks_service.state)
A szolgáltatás telepítés nagyjából 10 percbe telik. Az ML szolgáltatás telepítése után

a következőhöz hasonló üzenetet fog kapni:
Running........................ Succeeded AKS service
creation operation finished, operation "Succeeded"
Gratulálunk! Most telepített egy ML szolgáltatást az AKS-en. Tesztelje le az Azure

ML SDK használatával.
11. A service.run() függvényt használjuk, hogy adatokat adjunk a szolgáltatásnak
és előrejelzéseket kapjunk a következőképpen:
import json
test_sample = json.dumps({'data': [[34.927778, 0.24,

7.3899, 83, 16.1000, 1016.51, 1]]})
test_sample = bytes(test_sample,encoding = 'utf8')
prediction = service.run(input_data=test_sample)
12. A telepített szolgáltatás egy REST API webszolgáltatás, amellyel egy HTTP kéréssel
érhető el a következőképpen:
import requests
headers = {'Content-Type': 'application/json', 'Accept':

'application/json'}
if service.auth_enabled:
keys()[0]
elif service.token_auth_enabled:
token()[0]
scoring_uri = service.scoring_uri
print(scoring_uri)
response = requests.post(scoring_uri, data=test_sample,
headers=headers)
print(response.status_code)
print(response.elapsed)
print(response.json())
Amikor egy POST kérés érkezik a bemeneti adatok átadásával, a szolgáltatás

visszaadja a modell előrejelzését 0 vagy 1 formájában. Amikor egy ilyen előrejelzést
kap, akkor a szolgáltatása működik és robosztus, hogy kiszolgálja a termelés
igényeit. A szolgáltatás 0-tól a konténermásolatok szükséges számáig méretez
a felhasználó kérésmennyisége alapján.
A szolgáltatás telepítése az MLflow használatával

Végül végezzük el egy ML szolgáltatás telepítését a telepítési célon (ACI) az MLflow
használatával, hogy gyakorlati tapasztalatot szerezzünk egy nyílt forráskódú
keretrendszerrel. A kezdéséhez menjen a Git adatraktárba, amelyet korábban klónoztunk
az Azure DevOps-on (a 3. fejezet: A kód találkozik az adattal részben), keresse meg a 06_
ModelDeployment nevű mappát, és kövesse a megvalósítás lépéseit a 02_Deploy_
model_MLflow.ipynb jegyzettömbben. A megvalósítás előtt érdemes elolvasni
ezt a dokumentumot, hogy megértse az elveket az mlflow.azureml SDK mögött:
https://docs.microsoft.com/azure/machine-learning/how-touse-
mlflow#deploy-and-register-mlflow-models.
1. Kezdésként importáljuk a szükséges csomagokat és ellenőrizzük az Azure ML ADK

verzióját, ahogy az a következő kódblokkban látható:
import numpy as np
import mlflow.azureml
import azureml.core
2. Következőként az Azure ML SDK workspace függvényének használatával

csatlakozunk az ML munkaterülethez és beállítjuk a követő URl-t a
munkaterülethez a set_tracking_uri használatával:
'\n')
mlflow.set_tracking_uri(ws.get_mlflow_tracking_uri())
3. Most menjen a munkaterületre, és keresse meg az útvonalat az mlflow modellhez

a models vagy experiments részből és állítsa be az útvonalat:
from azureml.core.webservice import AciWebservice,
Webservice
# Set the model path to the model folder created by your
run
model_path = "model path"
4. Így már mindent beállítottuk a telepítéshez az ACI-n az mlflow és az

azureml SDK használatával. Konfigurálja az ACI telepítési célját a deploy_
configuration függvény használatával, és telepítse az ACI-ra az mlflow.
azureml.deploy függvény használatával. A deploy függvény a model_uri,
workspace, model_name, service_name, deployment_config fájlokat és
egyedi címkéket vesz argumentumnak, amikor meghívják:
# Configure
aci_config = AciWebservice.deploy_configuration
(cpu_cores=1,
memory_gb=1,
tags={'method' : 'mlflow'},
description='weather pred model',
location='eastus2')
# Deploy on ACI
(webservice,model) = mlflow.azureml.deploy(model_uri=
'runs:/{}/{}'.format(run.id, model_path), workspace=ws,
model_name='svc-mlflow', service_name='port-weather-
pred', deployment_config=aci_config, tags=None, mlflow_
home=None, synchronous=True)
webservice.wait_for_deployment(show_output=True)
Egy telepítés sikeres üzenetet fog kapni, amikor a telepítés sikerrel járt. Az MLflow
telepítés további részleteiért kövesse ezeket a példákat: https://docs.microsoft.
com/azure/machine-learning/how-to-use-mlflow#deploy-
andregister-mlflow-models.
Gratulálunk! Telepítette az ML modelleket több telepítési célon, mint amilyen az ACI és
AKS az azureml és mlflow használatával.
Következőként arra fogunk koncentrálni, hogy teljesen kihasználjuk az MLOps
lehetőségeit a folytonos integráció és folytonos telepítés használatával, hogy egy robosztus
és dinamikusan fejlődő rendszerünk legyen a termelésben.
A folytonos integráció és folytonos fejlesztés szükségességének felismerése 163
A folytonos integráció és folytonos fejlesztés

szükségességének felismerése
A folytonos integráció (CI) és folytonos fejlesztés (CD) lehetővé teszi az ML szolgáltatás
folytonos készítését. A cél a modell tanításához használt forráskód fenntartása és ellátása
verzióval, a kapcsolók engedélyezése a szükséges feladatok párhuzamos elvégzéséhez,
tárgyak kialakításához és kiadásához az ML szolgáltatásba történő telepítésre. Számos
felhőszolgáltató engedélyezi a DevOps szolgáltatásokat, amelyek használhatók
a termelésben lévő ML szolgáltatások, ML modellek monitorozására és más
szolgáltatásokkal történő összehangolásra a felhőben.
A CI és CD használatával lehetővé tehetjük a folytonos tanulást, amely kritikus egy ML
rendszer sikeréhez. A folytonos tanulás nélkül egy ML rendszer egy hibás PoC-ként
(Proof of Concept) fogja végezni. A következő fejezetben el fogunk mélyedni a CI/
CD elveiben és gyakorlatias CI és CD folyamatokat fogunk megvalósítani, hogy lássuk
működés közben az MLOps-t.
Összefoglalás
Ebben a fejezetben megtanultuk az ML modellek termelésben történő telepítésének fő
elveit. Megismertük a különböző telepítési módszereket és célokat, és a szükségleteiket.
Az átfogó ismeret és gyakorlati tapasztalat érdekében megvalósítottuk a telepítést, hogy
megtanuljuk, hogyan kell telepíteni az ML modelleket a különböző telepítési célokra, mint
a virtuális gépek, konténerek és egy automatikusan méretező klaszter. Ezzel készen áll rá,
hogy bármilyen típusú telepítési kihívást kezeljen, amellyel találkozik.
A következő fejezetben el fogunk mélyedni a robosztus ML szolgáltatások kialakításának,
telepítésének és fenntartásának titkaiban, amelyeket a CI és CD tesz lehetővé. Ez fogja
szabadjára engedni az MLOps potenciálját! Merüljön el benne!
7
Robosztus CI/
CD folyamatok
kialakítása
Ebben a fejezetben a folytonos műveletekről fog tanulni az MLOps folyamatban.
Az alapelvek, amelyeket ebben a fejezetben tanul, lesznek a kulcs folytonos telepítések
irányításához egy üzleti kontextusban. Ahhoz, hogy átfogó ismereteket és közvetlen
tapasztalatot szerezzen, átvesszük egyszerre az elveket és a gyakorlati megvalósítást.
Felállítunk egy CI/CD folyamatot a tesztkörnyezethez, miközben a folytonos
integrációról (CI) és folytonos telepítésről (CD) komponenseiről, a folyamattesztelésről,
valamint a kiadásokról és kapcsolótípusokról tanulunk. Ezáltal képes lesz automatizálni
a gépi tanulási (ML) modellek folyamatainak telepítését bármilyen szituációban
a felhőn a folytonos tanulás lehetőségeivel, összhangban az üzlettel, Kezdjük azzal,
hogy megnézzük, egyáltalán miért van szükségünk CI/CD-re az MLOps-ban. Olyan más
témák felfedezésével folytatjuk, mint a következők:
• Folytonos integráció, szállítás és telepítés az MLOps-ban

• Egy CI/CD folyamat és tesztkörnyezet felállítása (Azure DevOps használatával)
• Folyamatvégrehajtás és tesztelés
• Folyamat-végrehajtási kapcsolók
166 Robosztus CI/CD folyamatok kialakítása
Folytonos integráció, szállítás és telepítés

az MLOps-ban
Az automatizáció az elsődleges oka a CI/CD-nek az MLOps munkafolyamatban. Az ML
szolgáltatásban a folytonos szállítás lehetővé tételének célja, hogy fenntartsa a modellek
adatainak és forráskódjának verzióit, engedélyezze a kapcsolókat a szükséges feladatok
párhuzamos elvégzéséhez, tárgyak kialakításához és kiadások telepítéséhez a termelésben.
Számos felhőszolgáltató ajánlja a DevOps szolgáltatásokat a termelésben lévő ML
szolgáltatások és modellek monitorozására, valamint más szolgáltatásokkal történő
összehangolásra a felhőben. A CI és CD használatával lehetővé tehetjük a folyamatos
tanulást, amely kritikus egy ML rendszer sikeréhez. A folytonos tanulás nélkül egy ML
rendszer egy hibás Proof of Concept-ként (PoC) fogja végezni.
Csak egy folytonos tanulási lehetőségekkel telepített modell hozhat

üzleti értéket.
Egy folytonos tanulási lehetőségekkel rendelkező modell termelésben történő
telepítésének megtanulásához meg fogjuk ismerni a CI-t, CD-t és a folytonos szállítási
módszereket.
Ahogy láthatja a 7.1 ábrán, a CI a kulcs a CD-hez és a folytonos szállításhoz. Nézzük meg,
ezek hogyan kapcsolódnak:
7.1 ábra: Folytonos integráció, szállítás és telepítés folyamatok

Folytonos integráció, szállítás és telepítés az MLOps-ban 167
Folyamatos integráció
A CI célja, hogy szinkronizálja az alkalmazást (ML folyamat és alkalmazás) a fejlesztővel
valós időben. A fejlesztő módosításai a rögzítésekben vagy összevonásokban egy
alkalmazás létrehozásával és az azon végzett automatizált tesztelésekkel lesznek validálva.
A CI kiemeli az automatizált tesztelést, és az alkalmazás robosztusságának (hogy nem
rossz vagy hibás-e) ellenőrzése van a fókuszban, amikor új rögzítéseket von össze a fő
ágban. Amikor egy új rögzítés kerül a fő ágba, létrejön egy új kialakítás, amelynek
a robosztussága tesztelésre kerül az automatizált tesztelés használatával. Ezen folyamat
automatizálásával elkerülhetjük a szoftver megkésett szállítását és más integrációs
kihívásokat, amelyek miatt a felhasználók napokig várnak a kiadásra. Az automatizáció
és a tesztelés a CI lelke.
Folyamatos szállítás
A folytonos szállítás a CI-ből nyúlik ki, hogy biztosítsa, hogy az új módosítások vagy
kiadások telepítve lettek és hatékonyan jutottak el a felhasználókhoz; ezt az automatizált
tesztelés és kiadási folyamatok irányítják. Az automatizált tesztelés és a kiadási folyamatok
lehetővé teszik a fejlesztők és termékmenedzserek számára, egyetlen kattintással telepítsék a
változásokat, amely lehetővé teszi a zökkenőmentes irányítást és a felügyeleti lehetőségeket
a folyamat bármely fázisában. A folytonos szállítási folyamatban meglehetősen gyakori egy
emberi ágens (a QA csapatból) bevonása a kialakítás jóváhagyására (átment vagy sem),
mielőtt azt telepítenék a termelésben (ahogy az a 7.1 ábrán látható egy folytonos szállítási
folyamatban). Egy jellegzetes folytonos szállítási folyamatban egy kialakítás előzetes
elfogadási teszteken megy keresztül, mielőtt telepítik az próbafázisban, ahol egy emberi
ágens felügyeli a teljesítményt smoke tesztekkel és más megfelelő tesztekkel.
Amint teljesítette a smoke teszteket, az emberi ágens átadja a kialakítást, hogy telepítsék
a termelésben. A kialakítási és kiadási folyamat automatizálásával illetve egy emberi ágens
bevonásával a folyamatba, biztosítjuk a nagyszerű minőséget a termelés tekintetében,
és elkerülhetünk néhány buktatót, amelyet egy teljesen automatizált folyamat talán nem
venne észre. A folytonos szállítás használatával egy üzlet teljesen irányíthatja a kiadási
folyamatát és kis csomagokban adhat ki egy új kialakítást (könnyű a hibaelhárítás a hibák
vagy blokkolók esetén), vagy lehet egy teljes kiadása megkövetelt időkereten (napi, heti
vagy havi) belül.
Folyamatos telepítés
A CD lehetővé teszi a teljes automatizálását és egy lépéssel tovább megy, mint a folytonos
szállítás. A kialakítás és kiadás minden szakasza a termeléséhez teljesen automatizált
bármilyen emberi beavatkozás nélkül, a folytonos szállítással szemben. Egy ilyen
automatizált folyamatban csak egy elbukott teszt állíthatja meg, hogy egy új módosítás
telepítésre kerüljön a termelésben. A folytonos telepítés leveszi a nyomást a csapatról,
hogy fenntartsák a kiadási folyamatot, és gyorsítja a telepítést egyenesen az ügyfelekhez
a folytonos tanulás lehetővé tételével az ügyfelek visszajelzési hurkain keresztül.
Az ilyen automatizációval nem lesz többé kiadási nap a fejlesztőknek. Ez leveszi róluk
a nyomást és koncentrálhatnak csak a szoftver kialakítására, és nem kell aggódniuk
a tesztek és a kiadáskezelés miatt. A fejlesztők végezhetik kényelmesen a szoftver
kialakítását, tesztelését és telepítését és perceken belül élesíthetik azt, ahelyett hogy
a kiadási napokra várnának vagy az emberi jóváhagyásra, amely napokkal és néha
hetekkel késleltetheti a szoftver kiadását a felhasználóknak. A folytonos telepítés biztosítja
a teljes automatizációt, hogy robosztus és méretezhető szoftvert telepítsünk és szolgáljunk
ki a felhasználóknál.
Egy CI/CD folyamat és a tesztkörnyezet

felállítása (Azure DevOps használatával)
Az előző részben átvettük a CI, folytonos szállítás és folytonos telepítés elméletét, most pedig
itt az ideje, hogy lássuk gyakorlatban. Az Azure DevOps használatával fel fogunk állítani egy
saját egyszerű CI/CD folyamatot az üzleti problémánkhoz (időjárás előrejelzés), amelyen
korábban dolgoztunk (a 6. fejezet: Az Ön ML rendszerének telepítési alapelvei, a gyakorlati
telepítés részben (az üzleti problémánál)).
Az Azure DevOps egy a Microsoft által biztosított szolgáltatás, amely elvégzi a forráskód-
menedzsmentet (verziókezelés), projektmenedzsmentet, CI-t, folytonos szállítást és
folytonos telepítést (automatizált kialakítás, tesztelés és kiadás lehetőségei). Lehetővé
teszi az életciklus kezelését is a szoftveres alkalmazásoknál. Az Azure DevOps-t fogjuk
használni a gyakorlati képzéshez, mivel zökkenőmentesen integrálja az Azure ML
szolgáltatást, amelyet korábban használtunk a 6. fejezetben. Meg fogja tapasztalni a két
szolgáltatás integrációját és szinkronizálását, hogy könnyedén elkészüljenek a telepítések.
Kezdjünk is hozzá!
Egy CI/CD folyamat és a tesztkörnyezet felállítása (Azure DevOps használatával) 169
Menjen a saját Azure DevOps Learn_MLOps projektjébe. Menjen a klónozott

adatraktárhoz és nyissa meg a 07_CICD_Pipeline mappát. Ezeket a fájlokat fogjuk
(a 07_CICD_Pipeline nevű mappában) driverként használni egy kiadási folyamat
kialakításához:
Learn_MLOps
├──07_CICD_Pipeline
│ ├── AciDeploymentconfig.yml
├── AksDeploymentconfig.yml
└── InferenceConfig.yml
└── myenv.yml
└── score.py
Korábban betanított ML modelleket (a 4. fejezet: Machine Learning folyamatok részben)

fogunk telepíteni két telepítési célra: az egyik az Azure Container Instances (ACI)
a tesztkörnyezethez, és második egy Azure Kubernetes Service (AKS) klaszter a termelési
környezethez. Az AciDeployment.yml fájl tartalmazza a konfigurációt az ACI
telepítési célhoz, és az AksDeployment.yml fájl tartalmazza a konfigurációt az AKS
klaszterhez. Az InferenceConfig.yml olyan következtetéses tárgyakra mutat, mint
amilyen a score.py és myenv.yml.
A score.py fájlban meghatározott függvényeket fogjuk használni a beérkező adatok
előfeldolgozására és a következtetésre az előfeldolgozott adatokon az ML modellel,
hogy előrejelzéseket készítsünk. A myenv.yml fájl egy konfiguráció a következtetési
környezethez, például a környezetben telepítendő Python verzió és csomagok.
Ezeket a fájlokat fogjuk driverként használni a kiadási folyamat irányításához. Most,
hogy megismerte ezeket a fájlokat, kezdjük azzal, hogy csatlakoztatjuk az Azure ML
szolgáltatást és az Azure DevOps projektet egy szolgáltatási fiók használatával.
Egy szolgáltatási fiók létrehozása

Szinkronizálnunk kell az Azure ML szolgáltatásokaz és az Azure DevOps-t, hogy
irányítsuk a CI-t mindkét szolgáltatás között. Korábban (a 4. fejezet: Machine Learning
folyamatok részben) az Azure ML szolgáltatással fejlesztettük és kezeltük az ML
modelljeinket, és a Learn_MLOps munkaterületet használtuk. Most csatlakoztatjuk
az Azure ML munkaterületet (Learn_MLOps a neve) és az Azure DevOps projektet
(Learn_MLOps a neve) egy szolgáltatási fiók használatával.
A szolgáltatási fiók egy identitás, amelyet az alkalmazáson belüli kommunikációhoz

hoztak létre; ez egy csatlakozásautomatizáló eszköz az Azure erőforrások eléréséhez.
A szolgáltatási fiók gondoskodik az alkalmazásainak hálózati és összekapcsolhatósági
jellemzőiről is. Hajtsa végre a következő lépéseket egy szolgáltatási fiók beállításához
a folyamatokhoz:
1. Menjen a Project Settings részre (a képernyője bal alsó oldalán) és válassza ki

a Service connections lehetőséget. Kattintson a New service connection opcióra/
gombra, hogy megjelenjen a New service connection ablak, ahogy a 7.2 ábrán
látható:
7.2 ábra: Új szolgáltatási fiók csatlakoztatása

2. A csatlakozás típusának válassza az Azure Resource Manager opciót és

a továbblépéshez kattintson a Next gombra. Válassza ki a Service principal
(automatic) lehetőséget és lépjen tovább a szolgáltatási fiók létrehozásának utolsó
lépésére.
3. Figyelmeztetést fog kapni, hogy hozzon létre egy új szolgáltatáskapcsolatot. Állítsa
a hatókört Machine Learning Workspace lehetőségre, és kattintson a Subscription,
Resource group és Machine Learning Workspace lehetőségekre, ahogy a 7.3 ábrán
látható:
7.3 ábra: Egy új szolgáltatási fiók létrehozásának utolsó lépése

4. Nevezze el a szolgáltatási fiókot a Service connection name beviteli mezőben
(pl. mlops_sp, ahogy a 7.3 ábrán látható). Végül pipálja ki a négyzetet
(Grant access permission to all pipelines) és kattintson a Save gombra,
hogy létrehozza a szolgáltatási fiókot.
Ezzel a szolgáltatási fiókja a megadott névvel (például mlops_sp) készen áll a használatra
a CI/CD folyamatok kezeléséhez. Következőként telepíteni fogjuk a folyamatokhoz
használatos bővítményt.
A bővítmény telepítése, hogy csatlakozzon az Azure

ML munkaterülethez
A Microsoft kifejlesztett egy Machine Learning nevű bővítményt. Ez elérhető az Azure
DevOps Marketplace-en. A modellek és tárgyak kívánt Azure ML munkaterületéről
történő irányítására használják. Lehetővé teszi nekünk a modellek telepítését
a munkaterületről a kívánt telepítési célokra, mint amilyen az ACI vagy AKS.
Telepíteni fogjuk az ML bővítményt és felhasználjuk a CI/CD folyamat irányítására.
Hajtsa végre a következő lépéseket a bővítmény telepítéséhez:
1. Menjen el a Marketplace-re, és keresse meg a Machine Learning bővítményt.

Ahhoz, hogy eljusson a Marketplace-re, kattintson a zsák ikonra a képernyője jobb
felső részében, ahogy a 7.4 ábrán látható:
7.4 ábra: Az Azure DevOps Marketplace megtalálása

Miután belépett a Marketplace-re, több bővítményt is hozzáadhat az Azure DevOps

projektjéhez. Következőként megkeressük a Machine Learning bővítményt.
2. Keresse meg a Machine Learning bővítményt és telepítse ingyen. Kattintson
a Get it free gombra, hogy telepítse a bővítményt, ahogy a 7.5 ábrán látható:
7.5 ábra: A Machine Learning bővítmény telepítése

A Machine Learning bővítmény telepítésre kerül, amint rákattint a Get it free gombra.
A sikeres telepítés után, felhasználhatja a Machine Learning bővítményt a CI/CD
folyamat feladatainak kezelésére. Ezekkel az előfeltételekkel konfigurálta a folytonos
telepítés vagy folytonos szállítás folyamatát.
Egy folytonos integrációs és telepítési folyamat

felállítása a tesztkörnyezethez.
Ebben a részben konfiguráljuk a CI/CD folyamatot a próbakörnyezethez
(tesztkörnyezetnek is nevezik). Ezt folyamatot használjuk a folytonos tanulás és
automatizált telepítés irányítására. kezdjük azzal, hogy elmegyünk a Pipelines >>
Releases helyre, ahogy a 7.6 ábrán látható:
7.6 ábra: CI/CD folyamatának beállítása

Hozzon létre egy új folyamatot a Release részen. Nevezze el tetszés szerint a folyamatát.
A bemutatóban a folyamat neve Port Weather ML Pipeline. Következőként
elkezdjük csatlakoztatni a szükséges tárgyakat, hogy lehetővé tegyék a folyamatot,
mint amilyen a kódot tartalmazó adatraktár, és a modellek telepítését tartalmazó
munkaterületek.
Tárgyak csatlakoztatás a folyamathoz

Csatlakozzon az Azure DevOps adatraktárhoz. Az Azure DevOps adatraktára szolgál
a kód központi adatraktáraként a telepítések és műveletek irányításához az Azure
DevOps-on. Így csatlakoztassa az adatraktárt (Learn_MLOps) a kiadási folyamathoz:
1. Ahogy a 7.7 ábrán látható, menjen az Artifacts részre, kattintson az Add gombra,
válassza ki az Azure Repository opciót, majd válassza ki az adatraktárt (például
Learn_MLOps), hogy csatlakozzon a kiadási folyamattal:
7.7 ábra: Az Azure DevOps adatraktár csatlakoztatása tárgyként

2. Válassza ki az alapértelmezett ágat (például master) és végül kattintson az Add
gombra a képernyő alján, hogy csatlakoztassa az adatraktárt a kiadási folyamathoz.
Az adatraktár hozzáadása után láthatja az adatraktár nevét (Learn_MLOps)
és ikonját az Artifacts részen.
3. Csatlakozzon az Azure ML munkaterületéhez. Az Azure ML munkaterületének

kiadási folyamathoz történő csatlakoztatásához menjen az Artifacts részre,
kattintson az Add gombra, válassza ki az Azure ML Model Artifact opciót
a tárgytípusnál, ahogy a 7.8 ábrán látható. Válassza ki a Service Endpoint opciót
(az Ön Azure ML munkaterülete, például mlops_ws) és a telepítendő modelleket.
Válassza ki a model-scaler-t modellként. A scaler tárgyat fogjuk használni,
amelyet korábban a 4. fejezet: Machine Learning folyamatok részben regisztráltunk
a bejövő adatok méretezéséhez a szabvány használatával:
7.8 ábra: A méretező csatlakoztatása tárgyként

4. A model_scaler tárgy kiválasztása után adja hozzá a tárgyat a kiadási
folyamathoz úgy, hogy az Add gombra kattint. A model_scaler tárgy
hozzáadása után láthatja a modell nevét (model_scaler) és a modell ikonját az
Artifacts részen, ahogy a 7.9 ábrán látható.
Ugyanígy csatlakoztassa a support_vector_classifier modellt a kiadási folyamat

tárgyaihoz. Kezdje azzal, hogy rákattint az Add gombra az Artifacts részen, válassza
ki az Azure ML Model Artifact opciót, mutasson rá a szolgáltatás végpontjára
(a szolgáltatási fiók csatlakozik az Ön Azure ML munkaterületéhez, például:
mlops_sp) és válassza ki a support_vector_classifier modellt, amelyet az előző
4. fejezet: Machine Learning folyamatok részben tanított be. Adja hozzá
a modelltárgyat a folyamathoz úgy, hogy az Add gombra kattint:
7.9 ábra: Csatolt tárgyak

A support_vector_classifier modell hozzáadása után láthatja a modell nevét (support_
vector_classifier) és a modell ikonját az Artifacts részen, ahogy a 7.9 ábrán
látható.
Gratulálunk! Meg van mind a három szükséges tárgy (Learn_MLOps, scaler és
support_vector_classifier) a kiadási folyamathoz csatlakoztatva. Ezeket a tárgyakat
használhatjuk a telepítések irányítására a folyamatban. Következőként készüljön fel
a Próba/TESZT környezet konfigurálására!
Egy tesztkörnyezet beállítása

Állítsunk fel egy folytonos integrációs és folytonos telepítési folyamatot a TESZT
környezethez a folyamatban. Ebben a szakaszban a szolgáltatás robosztusságát teszteljük
és különböző teszteket hajtunk végre a szolgáltatás termelésre való felkészültségének
validálásához:
1. A kezdéshez kattintson az Add a stage dobozra a Stages részen és adjon hozzá

egy üres munkát (ahogy a 7.6 ábrán látható) DEV TEST névvel. A szakasznak DEV
TEST lesz a neve, mivel ez a fejlesztési és tesztelési környezetünk. Ideális esetbe
a DEV és TEST különböző szakaszok, de az egyszerűség és az ismétlődő végrehajtás
elkerülése miatt összevonjuk a kettőt. Lásd a következő 7.10 ábrát:
7.10 ábra: A DEV TEST szakasz beállítása

2. A szakasz elnevezése után, mentsük a szakaszt a Save gomb megnyomásával fent.

Minden szakasz egy sor lépés vagy feladat összeállítása a szakasz robosztusságának
ellenőrzésére. Következőként konfigurálni fogjuk a feladatokat a DEV TEST
szakasznál. Egy CI/CD feladat, egyszerű szavakkal egy folyamat vagy szkript, amely
végrehajtja vagy teszteli a telepítéseket (például feladat lehet egy modell telepítése
a Kubernetes klaszterre). A feladatok konfigurálásához kattintson az 1 feladat,
0 feladat linkre a DEV TEST szakaszban, ahogy a 7.11 ábrán látható:
7.11 ábra: DEV TEST feladatok konfigurálása

Miután rákattint az 1 feladat, 0 feladat linkre a DEV TEST szakaszban, új ágens

feladatokat kell hozzáadnia.
3. Adjon hozzá egy feladatot az ágenshez azzal, hogy rákattint a + jelre az Agent job
fülön. Egy előre elkészített sablont fogunk használni, amelynek AzureML Model
Deploy a neve. Keresse meg és adja hozzá az AzureML model deploy sablont,
ahogy a 7.12 ábrán látható:
7.12 ábra: egy feladat hozzáadása - AzureML Model Deploy

Az AzureML Model Deploy feladat hozzáadásakor megjelenik egy felugró ablak,
hogy csatlakozzon az Azure ML munkaterületéhez és az inferenceconfig
fájlhoz.
4. Következőként fel fog ugrani egy ablak, hogy írja be a telepítési információkat.
Ahogy a 7.13 ábrán látható, mutasson az Azure ML munkaterületére (például
mlops_ws) és legyen beállítva a Model Source opció a Model Artifact lehetőségre
(mivel a korábban generált modelltárgyakat használjuk a modellek tanításakor
és csomagolásakor):
7.13 ábra: A Model Source opció átállítása Model Artifact-ra

Következőként megnézzük az inferenceConfig fájlt és annak működését.

A következő töredék az inferenceConfig.yml (az adatraktárban) fájlból való Itt
egy kép az inferenceConfig.yml fájlról:
inferenceConfig.yml
entryScript: score.py
runtime: python
condaFile: myenv.yml
Ez a beállítások egy reprezentációja egy egyedi környezetnél, amelyben a modelljeinket

fogjuk telepíteni. A score.py fájlra mutat (amelyet korábban hoztunk létre a 6. fejezet:
Az Ön ML rendszerének telepítési alapelvei részben) és a conda fájl, myenv.yml,
amely definiálja a conda környezetet (telepítendő csomagok és függőségek). Itt egy kép
a myenv.yml fájlról:
myenv.yml
name: project_environment
dependencies:
# The python interpreter version.
# Currently Azure ML only supports 3.5.2 and later.
- python=3.6.2
- pip:
- numpy
- onnxruntime
- joblib
- azureml-core~=1.10.0
- azureml-defaults~=1.10.0
- scikit-learn==0.20.3
- inference-schema
- inference-schema[numpy-support]
- azureml-monitoring
channels:
- anaconda
- conda-forge
Mind a score.py mind a myenv.yml fájl bele van csomagolva az inferenceConfig.

yml fájlba, hogy irányítsa az ML modellek telepítését és következtetését. Folytassa
a következtetési konfigurációs fájl (inferenceConfig.yml) kiválasztásával, ahogy
7.14 ábra: A következtetési konfigurációs fájl kiválasztása

Miután rámutatott az inferenceConfig.yml fájlra az Azure DevOps adatraktárában,
az alap konfigurációja készen áll a telepítésre. Végül konfigurálni fogjuk a telepítési
információkat úgy, hogy rámutatunk a Model Deployment célra, elnevezzük
a telepítést (webszolgáltatást) és rámutatunk a telepítési konfigurációs fájlra (a telepítési
konfigurációs fájl konfigurációkat tartalmaz a telepítéshez, olyan paraméterekkel,
mint a számítógép típusa, automatikus méretező beállításai és más engedélyezők
az infrastruktúra definíciójához). A tesztkörnyezetnél telepíteni fogjuk az ML
webszolgáltatást vagy végpontot az ACI-n. Itt egy kép a telepítési konfigurációs fájlról
(AciDeploymentConfig.yml) az ACI-hoz:
AciDeploymentConfig.yml
computeType: ACI
containerResourceRequirements:
cpu: 1
memoryInGB: 1
authEnabled: False
sslEnabled: False
appInsightsEnabled: True
Tartalmazza az infrastrukturális definíciót a szükséges számítás biztosításáról

a telepítéshez, mint például CPU egységek, memória GB-ban és más hitelesítési vagy
biztonsági definíciókat. Válasszuk ki ezt a telepítési konfigurációs fájlt, hogy beállítsuk
a kiadási folyamatot a próbakörnyezethez, ahogy a 7.15 ábrán látható:
7.15 ábra: Telepítési információ hozzáadása

A telepítési konfigurációs fájl hozzáadása után, mentse el a munkát úgy, hogy a Save
gombra kattint a képernyő jobb felső sarkában, majd menjen a Pipelines >> Releases
részre (a képernyője bal oldalán), hogy lássa a sikereresen beállított folyamatát. Folytassuk
innen a folyamat tesztelésével.
Folyamatvégrehajtás és tesztelés 185
Folyamatvégrehajtás és tesztelés
Most itt az idő tesztelni a folyamatát, és ehhez létre fogunk hozni egy kiadást és validálni
fogjuk, hogy a folyamat kiadása sikerese lefutott-e. A következő lépések segíteni fognak
a folyamata tesztelésében:
1. Kattintson a Create release gombra a folyamatában konfigurált feladatok

végrehajtásához. Egy felugró ablak fog megjelenni a képernyője jobb oldalán (ahogy
a 7.16 ábrán látható) a próbakörnyezetében telepítendő tárgyak megtekintéséhez
és kiválasztásához.
2. Válassza ki a tárgyakat (_scaler és _support-vector-classifier) és válassza
ki a verziójukat. Az egyszerűség kedvéért az 1. verzió az ajánlott mindkettőnél.
Ha egy másik verzióját akarja kiválasztani a modelljének vagy méretezőjének,
feltétlenül módosítsa a modell és méretező elérési útvonalát a score.py fájlban
(azaz illessze be a megfelelő verziószámot a scaler és model útvonalak model-
scaler/{version number}/modelscaler.pkl és support-vector-
classifier/ {version number} /svc.onnx fájlokban). Ha az 1. verziót
választja, nem kell aggódnia a kódmódosítás miatt a score.py fájlban, mivel az
útvonalak tartalmazzák az 1. verziót.
3. A tárgyak és szükséges verziók (az 1. verzió az ajánlott) kiválasztása után kattintson
a Create gombra, hogy létrehozza a kiadást a kiválasztott tárgyakhoz:
7.16 ábra: Egy kiadás létrehozása

4. Most aktiválva lett a kiadási folyamat (a CI/CD folyamat) végrehajtása.

A folyamatban megadott összes lépés végre lesz hajtva, mint például a tárgyak
letöltése, az ACI számítási példány biztosítása a telepítéshez és a webszolgáltatás
telepítése. A sikeres végrehajtáskor értesítést fog kapni egy zöld pipával a kiadásánál,
7.17 ábra: Kiadások monitorozása

5. Monitorozhatja az összes kiadását a Releases részen és kezelheti a telepített
webszolgáltatást az Azure ML szolgáltatásból. A sikeres kiadás azt jelenti, hogy
a feladatok összes lépését sikeresen végrehajtotta és a tárgyakat (scaler és
_support-vector-classifier) telepítették webszolgáltatásként az ACI-n,
7.18 ábra: Sikeres feladatok egy kiadásban (tesztkörnyezet)

Folyamatvégrehajtás és tesztelés 187
6. Végül menjen és ellenőrizze az Azure ML munkaterületét ( az Endpoints részből),

hogy megtekintse a telepített webszolgáltatást, ahogy a 7.19 ábrán látható:
7.19 ábra: Az Azure ML munkaterületen telepített webszolgáltatás.

Sikeresen telepítettünk egy webszolgáltatást a tesztkörnyezetben. Megnézhetjük a REST
végpontot és a devtest-webservice szolgáltatásnevet. Ezzel elérkeztünk a CI/CD folyamat
kialakításának és tesztelésének sikeres lezárásához a tesztkörnyezetnél. A folyamatok
irányíthatók kapcsolók használatával, és a következő részben megnézzük, mik azok
a kapcsolók, és hogyan használhatjuk őket az optimális CI/CD folyamatok kialakításához.
Folyamat-végrehajtási kapcsolók
Egy hatékony CI/CD folyamatban a folyamat végrehajtása lehetséges kell legyen többféle
esemény vagy kapcsoló hatására. Ha a folyamatot csak szokványos események, például
kódtárolás vagy push-or-pull kérések képesek aktiválni, az hátrány vagy korlátozás
lehet a rendszernek. Annak a lehetősége, hogy a folyamatot több esemény használatával
aktiváljuk, javítja a CI/CD folyamat rugalmasságát és működését. Nézzünk meg néhány
kapcsolótípust, amely értéket adhat hozzá a CI/CD folyamathoz:
• Tárgyas kapcsolók
A tárgyak generálása a folyamat és fejlesztési folyamat különböző szakaszaiban
történik. A generált tárgyak, mint egy betanított modell, metaadat, feltöltött Docker
képek vagy bármilyen feltöltött fájl, aktiválhatják egy bizonyos rész végrehajtását
a CI/CD folyamatban. Az ilyen opciók hatalmas rugalmasságot és funkcionalitást
tesznek lehetővé a CI/CD folyamat számára.
• Docker Hub kapcsolók
Minden alkalommal, amikor elküld egy új Docker képet egy Ön által választott
Docker Hub adatraktárba, egy kapcsoló aktiválható a CI/CD folyamatban
a követelmények alapján. Például amikor feltölt egy új Docker képet a Docker
Hub-ra (vagy Azure Container Registry-re), a folyamatot aktiválja, hogy telepítse
a Docker képet egy webszolgáltatásként.
• Ütemező kapcsolók
A folyamatrész aktiválható egy megadott időeseményt követően. Az ilyen kapcsoló
nagyon hasznos egy ütemezett tisztításhoz vagy cron feladatokhoz vagy bármilyen
más munkafolyamathoz, amelyet egy időintervallum után kell futtatni; például egy
kapcsoló az ML modell újratanításához minden nap 12:00-kor.
• API kapcsolók
Az API kapcsolók célja, hogy integrálják a külső szolgáltatásokat (vagy bármilyen
más alkalmazást vagy szolgáltatást). Ez beállítható, így a folyamatrésze egy másik
rendszer eseménye alapján aktiválódik. Például, amikor egy rendszergazda
retrain kommentet tesz egy fejlesztő platformján, a folyamat aktiválható
a meglévő, telepített modell újratanításához. Ezeket a kapcsolókat API hívások
használatával irányítják.
• Git kapcsolók
A Git kapcsolókat gyakran használják folyamat-végrehajtások aktiválására,
például amikor új kódot rögzítenek egy ághoz vagy egy új pull kérés érkezik.
Amikor módosítás történik egy adatraktáron, akkor bizonyos részek aktiválhatók
a folyamatban a követelmények szerint.
Folyamat-végrehajtási kapcsolók 189
Az Azure DevOps több kapcsolóopciót biztosít (a fentiek mindegyikét). Most állítsunk

be egy Git kapcsolót az adatraktáron végzett Git rögzítés alapján:
1. Menjen a Pipelines >> Releases részre és kattintson az Edit lehetőségre

(a képernyője jobb felső részében), hogy módosítsa a meglévő folyamatot.
2. Kattintson az adatraktár tárgyra (_Learn_MLOps nevű), ahogy a 7.20 ábrán látható
és engedélyezze (rákattintva a kapcsolóra) a folytonos telepítés kapcsolót.
3. Adjon hozzá egy ágszűrőt a fejlesztési ág bevonásával. Ez aktiválni fogja a folyamat
végrehajtását, amikor módosítás vagy rögzítés történik az adatraktár fejlesztés
ágán. A tesztelési vagy próba szakaszhoz konfiguráljon egy Git kapcsolót csak
a fejlesztés ághoz (ne a fő vagy másik ághoz). A termeléshez konfigurálhatunk
egy Git kapcsolót a fő ágnál. Így szétválaszthatjuk a Git kapcsoló ágait a tesztelési
és termelési szakaszoknál:
7.20 ábra: Egy Git kapcsoló engedélyezése a tesztkörnyezetben

4. Kattintson a Save gombra fent, hogy konfigurálja a Git kapcsolót. Gratulálunk!

Sikeresen beállított egy folytonos telepítési Git kapcsolót a tesztkörnyezetéhez. Amikor
módosítás vagy rögzítés történik az adatraktár fejlesztés ágán, a folyamat aktiválódik,
hogy telepítsen egy webszolgáltatást a teszt (DEV TEST) környezetben.
Összefoglalás
Ebben a fejezetben megtanultuk a folytonos műveletek fő elveit az MLOps-ban, elsősorban
a folytonos integrációt, szállítást és telepítést. Ehhez elvégeztük egy CI/CD folyamat és
tesztkörnyezet beállításának gyakorlati megvalósítását az Azure DevOps használatával.
Teszteltük a folyamatot a végrehajtás robosztusságára és végül megnéztünk néhány
kapcsolót a folyamat működésének javítására, illetve beállítottunk egy Git kapcsolót
a tesztkörnyezethez. Ez a fejezet a folytonos műveletek alapjául szolgál az MLOps-ban
és ezáltal képes lesz automatizálni az ML modellek folyamatainak telepítését bármilyen
szituációban a felhőn, a folytonos tanulás lehetőségeivel, összhangban az üzletével.
A következő fejezetben megnézzük az API-kat, mikroszolgáltatásokat, és hogy mit
kínálnak az MLOps-alapú megoldások számára.
8
API-k és
mikroszolgáltatások
kezelése
Ebben a fejezetben az API-król és a mikroszolgáltatások kezeléséről fog tanulni. Idáig
telepítettünk ML alkalmazásokat, amelyek API-kként szolgáltak. Most megnézzük,
hogyan kell API-kat fejleszteni, szervezni, kezelni és kiszolgálni. Meg fogja tanulni az
API és mikroszolgáltatás tervezési alapelveket az ML következtetéshez, így megtervezheti
a saját egyedi ML megoldásait.
Ebben a fejezetben gyakorlás útján megtanulunk kialakítani egy mikroszolgáltatást
FastAPI és Docker használatával és kiszolgálni az egy API-ként. Ehhez átvesszük az API
és mikroszolgáltatás tervezésének alapjait egy korábban betanított (a 4. fejezet: Machine
Learning folyamatok részben) ML modellhez. Végül reflektálunk a robosztus és méretezhető
mikroszolgáltatások és API-k tervezésének néhány alapelvére, kihívására és tippjeire a
teszt- és termelési környezetek esetében. Ez a fejezet a következő témaköröket tárgyalja:
• Bevezetés az API-khoz és mikroszolgáltatásokhoz

• Mikroszolgáltatások igénye az ML-hez
• A régi aranyat ér: REST API-alapú mikroszolgáltatások
• Egy ML modell API-ként történő kiszolgálásának gyakorlati megvalósítása
192 API-k és mikroszolgáltatások kezelése
• Egy mikroszolgáltatás fejlesztése Docker használatával

• Az API szolgáltatás tesztelése
Bevezetés az API-khoz és mikroszolgáltatásokhoz

Az API-k és mikroszolgáltatások hatékony eszközök, amelyek segítenek lehetővé tenni,
hogy a gépi tanulásos (ML) modelljei hasznossá váljanak a termelésben vagy hagyományos
rendszerekben a modellek kiszolgálásához vagy kommunikáljanak a rendszer egyéb
összetevőivel. API-k és mikroszolgáltatások használatával egy robosztus és méretezhető
ML megoldást tervezhet az üzleti igényeinek ellátásához. Nézzük meg, hogy mi is az API és
mikroszolgáltatás, és hogyan valósítják meg a modellje potenciálját a való életben.
Mi az Application Programming Interface

(API, alkalmazásprogramozó interfész)?
Az API az átjáró, amely lehetővé teszi a fejlesztőknek, hogy kommunikáljanak egy
alkalmazással. Az API-k két dolgot tesznek lehetővé:
• A hozzáférést egy alkalmazás adataihoz

• Egy alkalmazás funkcionalitásának használatát
Az alkalmazás adatainak és funkcionalitásainak hozzáférése és a kommunikáció által az

API-k teszik lehetővé a világ elektronikus eszközeinek, alkalmazásainak és weboldalainak,
hogy kommunikáljanak egymással a közös munka érdekében, hogy teljesítsék az üzleti-
vagy műveletspecifikus feladatokat.
8.1 ábra: Egy API működése

Bevezetés az API-khoz és mikroszolgáltatásokhoz 193
A 8.1 ábrán láthatjuk egy API szerepét, ahogy lehetővé teszi a hozzáférést az alkalmazás
adataihoz (az adatbázisból) és harmadik felekkel vagy más alkalmazásokkal kommunikál,
mint amilyenek a mobilalkalmazások (a mobilfelhasználóknál), időjárásjelző
alkalmazások (mobilon vagy a weben), elektromos autók stb. Az API-k a számítógépek
hajnala óta működnek, hogy lehetővé tegyék az alkalmazások közötti kommunikációt.
Idővel láttunk olyan fejlesztőket, akik konszenzusra jutottak olyan protokollokkal,
mint a Simple Object Access Protocol (SOAP) és Representational State Transfer
(REST) a 2000-es évek elején. Az előző években kifejlesztették az API protokollok
új típusú generációját, mint amilyen a Remote Procedure Call (RPC) és GraphQL,
ahogy a következő táblázatban látható:
8.1 táblázat: API protokollok összehasonlítása

Érdemes megismerni a fő API protokollokat, ha Ön egy alkalmazásfejlesztő (felhőalapú
vagy más szolgáltatásokkal kommunikáló alkalmazásoké). Ez segít Önnek az API-jait az
üzleti vagy funkcionalitási igényeinek megfelelően tervezni. Programozóként tekintse
szerencsésnek magát, hogy számos API protokoll áll a rendelkezésére, mivel 20 évvel ezelőtt
csak a SOAP és REST volt elérhető. Most sok választási lehetősége van az igényeitől függően,
például a GraphQL, Thrift és JSON-RPC. Ezek a protokollok különböző előnyökkel és
hátrányokkal rendelkeznek, így könnyű megtalálni az Önnek legjobban megfelelőt.
Mikroszolgáltatások
A mikroszolgáltatások egy modern módja az appok fejlesztésének és telepítésének,
egy szolgáltatás futtatásához. A mikroszolgáltatások lehetővé teszik a szétosztott
alkalmazásokat egyetlen nagy monolitikus alkalmazás helyett, ahol a funkcionalitások
kisebb töredékekre oszlanak fel (ezeket hívjuk mikroszolgáltatásnak). Egy mikroszol-
gáltatás egyedi alkalmazás a mikroszolgáltatás architektúrájában. Ez a központosított
vagy monolitikus architektúrák ellentétje, ahol minden funkcionalitást egybecsomagoltak
egy nagy appba. A mikroszolgáltatások népszerűsége megnőtt a Service-Oriented
Architecture (SOA) miatt, amely alternatíva a hagyományos monolitikus (egyedüli
és önmagába elegendő alkalmazások) fejlesztésre.
A mikroszolgáltatások tömegesen alkalmazták, mivel lehetővé teszik a fejlesztőknek,

hogy könnyen fejlesszenek, integráljanak és tartsanak fenn alkalmazásokat. Végül ez
ahhoz vezetett, hogy az egyes funkcionalitásokat függetlenül kezeljék, ez tette először
lehetővé, hogy egy szolgáltatás külön funkcionalitását fejlessze lépésről lépésre.
Végül ez lehetővé teszi, hogy függetlenül dolgozzon az egyes funkcionalitásokon,
miközben integrálja a teljes rendszert a szolgáltatás irányítására. Így hozzáadhat,
fejleszthet vagy javíthat rajta a teljes alkalmazás tönkretételének kockáztatása nélkül.
A mikroszolgáltatások nagyobb vállalatoknak értékesek, mivel lehetővé teszik, hogy
a csapatok elkülönített dolgokon dolgozzanak bonyolult szervezet nélkül. A 8.2 ábrán
láthatjuk a különbséget a monolitok és mikroszolgáltatások között. A mikroszolgáltatások
lehetővé teszik a megosztott alkalmazásokat a monolitokkal szemben, amelyek osztatlan
alkalmazások:
8.2 ábra: Mikroszolgáltatások vs monolitok

A szoftverfejlesztési csapatokat képessé teszi, hogy függetlenül és jól ismert szolgáltatási
kötelezettségek között dolgozzanak. A mikroszolgáltatás-alapú architektúra bátorítja
a szoftverfejlesztési csapatokat, hogy vegyék ki a részüket a szolgáltatásaikból vagy
moduljaikból. A mikroszolgáltatás-alapú architektúra egyik lehetséges hátránya,
hogyha darabokra tör egy alkalmazást, akkor nagy szükség van a részek hatékony
kommunikációjára a szolgáltatás működésben tartásához.
Mikroszolgáltatások igénye az ML-hez 195
Az API-k és mikroszolgáltatások közötti kapcsolat lenyűgöző, mivel két oldala van.

A mikroszolgáltatás-alapú architektúra eredményeként egy API a közvetlen kimenetele
az architektúra megvalósításának az alkalmazásában. Miközben az API egy létfontosságú
eszköz a szolgáltatások közötti kommunikációhoz egy mikroszolgáltatás-alapú
architektúrában a hatékony működéshez. Nézzük mega következő részt, ahol áttekintünk
néhány példát az ML alkalmazásokra.
Mikroszolgáltatások igénye az ML-hez

A mikroszolgáltatás-alapú architektúrák szükségességének megértéséhez az ML
alkalmazásoknál, nézzünk meg egy elméleti felhasználási esetet, és menjünk végig
az ehhez való ML alkalmazás fejlesztési fázisain.
Elméleti felhasználási eset

Egy nagy autójavító üzemnek szüksége van egy megoldásra, hogy megbecsülje az
üzemben lévő autók számát és a pontos pozícióikat. Egy rakás IP kamerát szereltek fel
a javító állomásokon az üzem monitorozásához. Tervezzen egy ML rendszert az autójavító
üzem monitorozásához és kezeléséhez.
1. szakasz: Proof of Concept (egy monolitikus)

Egy gyors PoC-t készítettek egy tipikus esetben az elérhető adatpontok felhasználásával
és alkalmazták az ML-t, hogy bemutassa és validálja a felhasználási esetet, és bizonyítsa
az üzlet részvényeseinek, hogy az ML képes megoldani a problémájukat vagy javítani az
üzleten.
Az elmélet felhasználási esetünkben egy monolit Python appot fejlesztettek, amely
a következőt teszi:
• Minden kamerától adatfolyamot szerez

• Meghatározza az autók helyzetét (orr vagy far) minden kameránál
• Összesíti a becsléseket egy üzemállapot értékelőben
Láthatjuk a 8.3 ábrán, hogy az appot csomagolták és telepítették a szerverre:
8.3 ábra: Monolitikus ML alkalmazás működése (PoC egy elméleti használati esethez)
Minden kamerát ehhez a szerverhez csatlakoztatnak a helyi hálózaton keresztül.
Az algoritmusok az autópozíció becsléséhez és az üzemállapot becslőhöz működnek,
de további fejlesztések szükségesek, és összességében a PoC működik. Ez a monolitikus
app nagy érzékeny az összeomlásra a kamerák instabilitása, a helyi hálózat és más hibák
miatt. Az ilyen instabilitások jobban kezelhetők mikroszolgáltatásokkal. Nézzük meg ezt
a gyakorlatban a 2. szakaszban.
2. szakasz: Termelés (mikroszolgáltatások)

Ebben a szakaszban kulcsfontosságú egy az összeomlásokra kevésbé érzékeny alkalmazás,
az autójavító üzem monitorozási műveleteinek folyamatos futtatásához. Ebből az okból
a monolitikus alkalmazást lecseréljük mikroszolgáltatás-alapú architektúrára, ahogy
Mikroszolgáltatások igénye az ML-hez 197
8.4 ábra: Mikroszolgáltatások (termeléskész alkalmazás egy elméleti használati esethez)

Az alkalmazást több szolgáltatásra tördeljük a következő módon:
• Videó adatfolyamgyűjtő.
• Képfeldolgozó: Ez összesíti a képeket, fogadja, feldolgozza és gyorsítótárazza
a képeket, illetve csomagokat készít a további feldolgozáshoz.
• Pozícióosztályozó: Megbecsüli egy autó pozícióját (orr vagy far), amely
a javítóüzemben parkol.
• Üzemállapot becslő: Ez aszinkron módon fogadja az autópozíciók becsléseit
és kalibrálja az üzemállapotot, illetve valós idejű adatokat küld a felhőbe.
• A felhő összegyűjti és tárolja az adatokat MQTT (egy alap könnyű, megosztó-
feliratkozó hálózati protokoll, amely üzeneteket szállít eszközök között)
használatával. Az adatok megjelennek egy kezelőpulton, hogy az autóüzem
operátorai elemezhessék a műveleteket.
Az egyes mikroszolgáltatások közötti összes kommunikációt API-k irányítják.

A mikroszolgáltatásos architektúra előnyei, hogyha a szolgáltatások bármelyike
összeomlik vagy hibás lesz, akkor egy adott mikroszolgáltatás elindul, hogy helyettesítse
a meghibásodottat, hogy az egész szolgáltatás futhasson. Másodszor egy kijelölt csapat
(adatkutatók, fejlesztők és DevOps mérnökök) minden mikroszolgáltatást fenntarthat
és folyamatosan javíthat, a koordináló csapatokkal ellentétben, amelyek egy monolitikus
rendszeren dolgoznak.
A régi aranyat ér: REST API-alapú

mikroszolgáltatások
A régi aranyat ér. Valamint jobb onnan indulni, ahol különböző API protokollok vannak.
A Representational State Transfer (REST) protokoll vált az aranyszabállyá számos
alkalmazásnál az évek során, és így van ez napjainkban az ML alkalmazásoknál is.
A vállalatok többsége szívesebben fejleszti az ML alkalmazásait a REST API protokoll alapján.
Egy REST API vagy RESTful API a REST-en alapszik, ami egy architekturális módszer
a kommunikációra főleg a webszolgáltatások fejlesztésénél.
A RESTful API-k széleskörűen használatosak; olyan cégek használják, mint az Amazon,
Google, LinkedIn, és Twitter. Az ML modelljeink RESTful API-kon keresztül történő
kiszolgálásának számos előny van, mint például a következők:
• Előrejelzéseket szolgáltat menet közben több felhasználó felé.
• Több példányt ad hozzá, hogy arányosan felemelje az alkalmazás egy
terheléskiegyenlítő mögött.
• Több modellt kombinálhat különböző API végpontok használatával.
• Elválasztja a modellünk működési környezetét az felhasználóval érintkező
környezettől.
• Lehetővé teszi a mikroszolgáltatás-alapú architektúrát. Így a csapatok dolgozhatnak
egymástól függetlenül a szolgáltatások fejlesztésén és javításán.
Egy RESTful API meglévő HTTP módszereket használ, amelyeket az RFC 2616 protokoll
definiál. A 8.2 táblázat foglalja össze a HTTP módszereket a CRUD műveleteikkel
kombinálva és a céljukat az ML alkalmazásokban.
8.2 táblázat: REST API HTTP módszerek

Egy ML modell API-ként történő kiszolgálásának gyakorlati megvalósítása 199
Az alapvető HTTP módszerek a MEGSZERZÉS, POSZTOLÁS, LETÉTEL, FRISSÍTÉS

és TÖRLÉS. Ezek a módszerek megfelelnek a CRUD műveleteknek, mint amilyen
létrehozás, beolvasás, frissítés és törlés. Ezen módszerek használatával
képesek vagyunk RESTful API-kat fejleszteni az ML modellek kiszolgálásához. A RESTful
API-k jelentősen elterjedtek az olyan illesztőprogramok miatt, mint az OpenAPI. Az
OpenAPI Specification egy szabványosított REST API leírási formátum. Szabványosított
formátummá vált az embereknél és gépeknél; lehetővé teszi a REST API érthetőségét és
bővített szerszámozást biztosít, mint például API validálást, tesztelést és egy interaktív
dokumentációgenerátort. A gyakorlatban az OpenAPI fájl lehetővé teszi Önnek, hogy
leírjon egy teljes API-t a kritikus információkkal, mint amilyenek a következők:
• Elérhető végpontok (/names) és műveletek az egyes végpontokon (GET /names,

POST /names)
• Bemenet és kimenet minden egyes műveletnél (működési paraméterek)
• Hitelesítési módszerek
• Fejlesztői dokumentáció
• Felhasználási feltételek, licenc és egyéb információk
További anyagokat találhat az OpenAPI-ról ezen az oldalon: https://swagger.io/

specification/.
A következő részben egy RESTful API-t fogunk fejleszteni egy ML modell kiszolgálásához
és tesztelni fogjuk azt egy OpenAPI-alapú interfésszel, amelynek Swagger UI a neve.
Egy ML modell API-ként történő

kiszolgálásának gyakorlati megvalósítása
Ebben a részben alkalmazni fogjuk az API-k és mikroszolgáltatások alapelveit, amelyeket
korábban tanultunk (a Bevezetés az API-khoz és mikroszolgáltatásokhozrészben) és
fejlesztünk egy RESTful API szolgáltatást az ML modell kiszolgálásához. Az ML modell,
amelyet ki fogunk szolgálni azé az üzleti problémáé (ML-t használó időjárás előrejelzés),
amelyen korábban dolgoztunk. A FastAPI keretrendszert fogjuk használni a modell
API-ként történő kiszolgálásához, és a Dockert az API szolgáltatás mikroszolgáltatásba
való konténerezéséhez.
A FastAPI egy keretrendszer az ML modellek telepítéséhez. Könnyen és gyorsan kódolható
és lehetővé teszi a magas teljesítményt az olyan jellemzőkkel, mint az aszinkron hívások
és adatintegritási ellenőrzések. A FastAPI-t könnyű használni és követi az OpenAPI
Specification-t, így könnyű tesztelni és validálni az API-kat. Tudjon meg többet a FastAPI-ról
itt: https://fastapi.tiangolo.com/.
API tervezése és fejlesztése

Ki fogjuk fejleszteni az API szolgáltatást és futtatni fogjuk egy helyi számítógépen.
(Ez fejleszthető azon a VM-en is, amelyek korábban hoztunk létre az Azure Machine
Learning munkaterületen. A tanuláshoz ajánlott helyben gyakorolni, a könnyűség
kedvéért.)
A kezdéshez klónozza a könyv adatraktárát a PC-jén vagy laptopján, és menjen a 08_
API_Microservices mappába. Ezeket a fájlokat fogjuk használni az API szolgáltatás
kialakításához:
Learn_MLOps
├──08_API_Microservices
│ ├── Dockerfile
├── app
└── variables.py
└── weather_api.py
└── requirements.txt
└── artifacts
└── model-scaler.pkl
└── svc.onnx
A könyvtárfában felsorolt fájlok a 08_API_Microservices mappánál tartalmaznak

egy Docker fájlt (egy Docker kép és konténer kialakítására használatos a FASTAPI
szolgáltatásból) és egy app nevű mappát. Az app mappa tartalmazza a weather_api.
py (tartalmazza a kódot az API végpont definícióihoz), variables.py (tartalmazza
a bemeneti változók definícióját), és requirements.txt (tartalmazza az API
szolgáltatás futtatásához szükséges Python csomagokat) fájlokat, és egy mappát az olyan
modelltárgyakkal, mint amilyen a modellméretező (a bejövő adatok méretezéséhez) és egy
szerializált modellfájl (svc.onnx).
A modellt korábban szerializáltuk, a modell tanítási és értékelési szakasznál,
ahogy az 5. fejezet: Modellértékelés és csomagolás részben láthattuk. A modellt
letöltöttük a modelljegyzékből és elhelyeztük a mappában az Azure Machine learning
munkaterületen (Learn_MLOps), ahogy a 8.5 ábrán látható:
8.5 ábra: A szerializált modellfájl letöltése

Lecserélheti a svc.onnx és model-scalar.pkl fájlokat azokra a fájlokra, amelyeket
Ön tanított be az Azure Machine learning munkaterületén vagy használja csak továbbra is
ezeket a fájlokat a gyors kísérletezéshez. Most megnézzük az egyes fájlok kódját. Kezdjük
a variables.py fájllal.
variables.py
Csak egy csomagot használunk a bemeneti változók definiálására. Az általunk
használandó csomagot pydantic-nak hívják; ez egy adatvalidációs és beállításkezelő
csomag, amely Python típusú megjegyzéseket használ. A pydantic használatával
definiálni fogjuk a bemeneti változókat a WeatherVariables nevű osztályban, amelyet
a fastAPI szolgáltatáshoz használtunk.
from pydantic import BaseModel
class WeatherVariables(BaseModel):
temp_c: float
humidity: float
wind_speed_kmph: float
wind_bearing_degree: float
visibility_km: float
pressure_millibars: float
current_weather_condition: float
A WeatherVariables osztályban definiáljuk a változókat és a típusaikat, ahogy az

előző kódban láthattuk. Ugyanazokat a változókat fogjuk használni a következtetéshez,
amelyeket a modell tanításához használtunk a 4. fejezet: Machine Learning folyamatok
részben. Ezeket a bemeneti változókat itt temp_c, humidity, wind_speed_kmph,
wind_bearing_degree, visibility_km, pressure_millibars és current_
weather_condition néven definiáljuk. Ezen változók adattípusa float. Importálni
fogjuk a WeatherVariables osztályt, és a definiált bemeneti változókat használjuk a
fastAPI szolgáltatásban. Nézzük meg, hogyan használhatjuk a WeatherVariables
osztályban definiált változókat a fastAPI szolgáltatásban a Weather_api.py fájl
használatával.
weather_api.py
Ez a fájl a fastAPI szolgáltatás definiálására használatos. A szükséges modelltárgyakat
importáltuk és felhasználtuk az API végpontok kiszolgálásához a modell
következtetéséhez, hogy előrejelzéseket készítsünk valós időben vagy a termelésben:
1. Azzal kezdjük, hogy importáljuk a szükséges csomagokat a következőképpen:

import uvicorn
from fastapi import FastAPI
from variables import WeatherVariables
import numpy
import pickle
import pandas as pd
import onnxruntime as rt
Importáltuk a szükséges csomagokat, mint amilyen a uvicorn (egy ASGI

szervermegvalósítási csomag), fastapi, numpy, pickle, pandas és
onnxruntime (az onnx modellek deszerializálására és következtetésére
használatos).
Megjegyzés
Importáltuk a WeatherVariables osztályt, amelyet korábban a
variables.py fájlban hoztunk létre. Az ebben a fájlban definiált változókat
használjuk a bemeneti adatok megszerzésére a fastAPI szolgáltatáshoz.
2. Következőként létrehozunk egy app objektumot. Észrevehet néhány szintaktikai

hasonlóságot a fastAPI és Flask webes keretrendszer között (ha használta már
a Flask-ot).
Például a következő lépésben létrehozzuk az app objektumot a FastAPI()
függvény használatával, hogy létrehozzuk az app objektumot. Egy app objektum
létrehozása hasonlít ahhoz, ahogyan a Flask-ban csináljuk, például: a Flask-ból
importáljuk a Flask-ot, majd felhasználjuk a Flask függvényt, hogy létrehozzuk
az app objektumot az app = Flask () kóddal. Észre fogja venni az ilyen
hasonlóságokat, ahogy kialakítjuk az API végpontokat a fastAPI használatával:
app = FastAPI()
# Load model scalar

pickle_in = open("artifacts/model-scaler.pkl", "rb")
scaler = pickle.load(pickle_in)
# Load the model

sess = rt.InferenceSession("artifacts/svc.onnx")
input_name = sess.get_inputs()[0].name
label_name = sess.get_outputs()[0].name
3. Az app objektum létrehozása után importálni fogjuk a szükséges modelltárgyakat

a végpontokban történő következtetéshez. Pickle használatos a model-
scaler.pkl adatméretező fájl deszerializálásához. Ezt a fájlt használtuk a modell
tanításához (a 4. fejezet: Machine Learning folyamatok részben), és most a bejövő
adatok méretezésére fogjuk használni a modell következtetése előtt. A korábban
betanított support vector classifier modellt fogjuk használni, amelyet szerializáltunk
az scv.onnx nevű fájlba (elérhetjük és letölthetjük a fájlt, ahogy a 8.5 ábrán
látható).
4. ONNX Runtime használatos a szerializált modell betöltésére a következtetési

munkamenetekbe (input_name és label_name) az ML modell előrejelzéseinek
elkészítéséhez. Következőként rátérhetünk az API végpontok definiálásának fő
részére az ML modell következtetéséhez. kezdésként készítünk egy GET kérést az
index útvonalhoz a @app.get('/') csomagoló függvény használatával:
@app.get('/')
def index():
return {'Hello': 'Welcome to weather prediction
service, access the api docs and test the API at
http://0.0.0.0/docs.'}
Egy index() nevű függvényt definiáltunk az index útvonalhoz. Az üdvözlő

üzenetet adja vissza, amely a docs linkre mutat. Ez az üzenet irányítja a felhasználót
a docs linkhez, hogy hozzáférjen és tesztelje az API végpontokat.
5. Következőként definiáljuk a /predict fő API végpontot, amely az ML modell
következtetéséhez használatos. Egy @app.post('/predict') csomagoló
függvény használatos egy POST kérés küldéséhez:
@app.post('/predict')
def predict_weather(data: WeatherVariables):
data = data.dict()
# fetch input data using data varaibles

temp_c = data['temp_c']
humidity = data['humidity']
wind_speed_kmph = data['wind_speed_kmph']
wind_bearing_degree = data['wind_bearing_degree']
visibility_km = data['visibility_km']
pressure_millibars = data['pressure_millibars']
current_weather_condition = data['current_weather_
condition']
Egy predict_weather() nevű függvényt kezdeményezünk a /predict

végpontnál. A függvény belsejében létrehoztunk egy data nevű változót, amely
összegyűjti a bemeneti adatokat; ez a változó gyűjti össze a JSON adatokat,
amelyeket a POST kérésen keresztül szereztünk és a WeatherVariables
osztályra mutat. Amint elvégezzük a POST kérést, az összes változó a bejövő
adatokban leképződik a változókra a WeatherVariables osztályban
a variables.py fájlból.
6. Következőként átalakítjuk az adatokat egy szótárrá, kiolvasunk minden bemeneti

változót a szótárból, és tömörítjük őket egy numpy tömbváltozóban, a data_to_
pred-ben. Ezt a változót fogjuk használni az adatok méretezéséhez és az ML modell
következtetéséhez:
data_to_pred = numpy.array([[temp_c, humidity, wind_
speed_kmph,
wind_bearing_degree,visibility_km, pressure_millibars,
current_weather_condition]])
# Scale input data

data_to_pred = scaler.fit_transform(data_to_pred.
reshape(1, 7))
# Model inference

prediction = sess.run(
[label_name], {input_name: data_to_pred.
astype(numpy.float32)})[0]
Az adatokat (data_to_pred) a scaler használatával méreteztük és átformáltuk,

amelyet korábban betöltöttünk a fit_transform() függvény használatával.
7. A modell következtetési lépése következik, amely a fő lépés, a méretezett adatok
következtetésével hajtja végre a modell, ahogy az előző láthattuk. Aztán a modellből
következtetett előrejelzés visszatér kimenetként a prediction változóba:
if(prediction[0] > 0.5):
prediction = "Rain"
else:
prediction = "No_Rain"
return {
'prediction': prediction
}
Végül átalakítjuk a modell következtetését egy emberek által olvasható formátummá

a rain vagy no_rain javaslásával az ML modell előrejelzései alapján, és visszatér
a prediction a POST hívásért a /predict végponthoz. Ezzel elértünk
a weather_api.py fájl végére. Amikor egy POST kérés érkezik a bemeneti adatok
átadásával, a szolgáltatás visszaadja a modell előrejelzését 0 vagy 1 formájában.
A szolgáltatás a rain vagy not_rain értékkel tér vissza a modell előrejelzése
alapján. Amikor egy ilyen előrejelzést kap, akkor a szolgáltatása működik és elég
robosztus, hogy kiszolgálja a termelés igényeit.
Requirement.txt
Ez a szövegfájl tartalmazza az összes csomagot, amely a fastAPI szolgáltatás futásához
szükséges:
numpy
fastapi
uvicorn
scikit-learn==0.20.3
pandas
onnx
onnxruntime
Ezeket a csomagokat telepíteni kell abban a környezetben, ahol az API szolgáltatást

futtatni akarja. A numpy, fastapi (egy ML keretrendszer robosztus API-k készítéséhez),
uvicorn (egy AGSI szerver), scikit-learn, pandas, onnx és onnxruntime (az
onnx modellek deszerializálásához és következtetéséhez) csomagokat fogjuk használni
a FastAPI szolgáltatás futtatásához Az API szolgáltatás szabványosított telepítéséhez
és futtatásához a Docker-t fogjuk használni, hogy egy Docker konténerben futtassa a
FastAPI szolgáltatást.
Következőként nézzük meg, hogyan kell létrehozni egy Docker fájlt a szolgáltatáshoz.
Egy mikroszolgáltatás fejlesztése Docker

használatával
Ebben a részben szabványosított módon becsomagoljuk a FastAPI szolgáltatást a Docker
használatával. Így nagyjából 5 perc alatt telepíthetjük a Docker képet vagy konténert a
választott telepítési célunkra.
A Docker számos előnnyel rendelkezik, például: ismételhetőség, biztonság, egyszerűség
fejlesztése stb. Használhatjuk a fastAPI hivatalos Docker képét (tiangolo/
uvicorn-gunicorn-fastapi) a Docker Hub-ról. Itt egy két a Docker fájlról:
FROM tiangolo/uvicorn-gunicorn-fastapi:python3.7
COPY ./app /app
RUN pip install -r requirements.txt
EXPOSE 80
CMD ["uvicorn", "weather_api:app", "--host", "0.0.0.0",
"--port", "80"]
Először egy hivatalos fastAPI Docker képet használunk a Docker Hub-ról a FROM
parancs használatával, és a képre mutatunk: tiangolo/uvicorn-gunicorn-
fastapi:python3.7. A kép Python 3.7-et használ, amely kompatibilis a fastAPI-
val. Következőként átmásoljuk az app mappát egy app nevű könyvtárba a docker
képen/konténeren belül. Az app mappa Docker képbe/konténerbe való
átmásolása után telepítjük a requirements.txt fájlban felsorolt szükséges csomagokat
a RUN parancs használatával.
Mivel az uvicorn szerver (AGSI szerver) a fastAPI-nél a 80-as portot használja
alapértelemzettként, ezért EXPOSE-oljuk (hozzáférhetővé tesszük) a 80 -as portot
a Docker képnek/konténernek. Végül előkészítjük a szervert a Docker képen/
konténeren belül a CMD "uvicorn weather_api:app –host 0.0.0.0 –
port 80" parancs használatával. Ez a parancs a weather_api.py fájlra mutat, hogy
hozzáférjen a fastAPI app objektuma a szolgáltatáshoz és hosztolja azt a kép/konténer
80-as portján.
Gratulálok, már majdnem kész van. Most teszteljük a mikroszolgáltatás gyorsaságát
és meglátjuk, működik-e, és ha igen, hogyan.
Az API tesztelése
Az API gyorsaságának teszteléséhez a következő lépéseket hajtjuk végre:
1. Kezdjük a Docker kép kialakításával. Ehhez szükség van a telepített Docker-re.

Menjen a termináljához vagy a parancssorhoz és klónozza az adatraktárt a
kívánt helyre, és nyissa meg a 08_API_Microservices mappát. Hajtsa végre
a következő Docker parancsot, hogy elkészítse a Docker képet:
docker build -t fastapi .
A build parancs végrehajtása elindítja a Docker kép kialakítását a Docker fájlban

felsorolt lépéseket követve. A kép a fastapi nevet kapja. A build parancs sikeres
végrehajtása után validálhatja, hogy a kép kialakítása és elnevezése sikeres-e vagy
sem a docker images parancs használatával. A következő információkat fogja
kiadni a kép sikeres kialakítása után:
(base) user ~ docker images
REPOSITORY TAG IMAGE ID CREATED
SIZE
fastapi latest 1745e964f57f 56 seconds ago
1.31GB
2. Futtasson egy Docker konténert helyileg. Most letehetünk egy futó Docker
konténert az előbb létrehozott Docker képből. Egy Docker konténer futtatásához
a RUN parancsot használjuk:
docker run -d –name weathercontainer -p 80:80 fastapi
Egy Docker konténer a fastapi Docker képből lett lerakva. A futó konténer neve
weathercontainer és a portja a 80 leképezve a helyi számítógép 80-as portjára.
A konténer a háttérben fog futni, mivel használtuk a -d kifejezést a RUN parancsban.
Egy konténer sikeres futtatásakor egy konténer ID jelenik meg a terminálon, például:
2729ff7a385b0a255c63cf03ec9b0e1411ce4426c9c49e8db
4883e0cf0fde567.
3. Tesztelje az API szolgáltatást a mintaadatok használatával. Ellenőrizni fogjuk, hogy

a konténer sikeresen fut-e. Ennek ellenőrzéséhez használja a következő parancsot:
docker container ps
Ez felsorolja az összes futó konténert a következőképpen:

(base) user ~ docker container ps
CONTAINER ID IMAGE COMMAND CREATED
STATUS PORTS NAMES
2729ff7a385b fastapi "uvicorn weather_api…"
18 seconds ago Up 17 seconds 0.0.0.0:80->80/tcp
weathercontainer
Láthatjuk, hogy a fastapi kép konténerje leképződött és sikeresen fut a helyi gép 80-as
portján. Hozzáférhetünk a szolgáltatáshoz és tesztelhetjük azt a böngészőből a helyi
gépünkön a 0.0.0.0:80 címen.
Megjegyzés
Ha hibákat kap vagy nincs válasz, amikor az API szolgáltatását futtatja
vagy teszteli, akkor lehet, hogy le kell tiltania a CORS validálást az olyan
böngészőknél, mint a Chrome, Firefox és Brave vagy hozzá kell adnia egy
bővítményt (például menjen a Chrome Web Store-ba és keressen egyet),
amely letiltja a CORS validálást az API-k helyi futtatásához és teszteléséhez.
Alapértelmezetten nem kell letiltania a CORS-t; csak akkor tegye meg, ha
szükséges.
A következő üzenetet fogja látni:
8.6 ábra: FastAPI szolgáltatás fut a helyi 80-as porton

A FastAPI az Open API Specification-t használja (olvasson többet: https://
www.openapis.org/, https://swagger.io/specification/),
hogy kiszolgálja a modellt. Az OpenAPI Specification (OAS) egy szabványos,
nyelvagnosztikus interfész a RESTful API-khoz. Az OpenAPI jellemzők
használatával elérhetjük az API dokumentációt és szélesebb áttekintést nyerünk
az API-ról. Az API docs-hoz hozzáférhet és tesztelheti az API-t a 0.0.0.0:80/
docs címen, és ez elirányítja Önt egy Swagger-alapú UI-ra (az OAS-t használja),
hogy tesztelje az API-ját.
4. Most tesztelje a /predict végpontot (válassza ki a végpontot és kattintson a Try it

out gombra) a választása szerinti bemeneti adatokkal, ahogy a 8.7 ábrán látható:
8.7 ábra: Bemenet a FastAPI szolgáltatás kéréstörzséhez

5. Kattintson az Execute lehetőségre, hogy elindítson egy POST hívást és tesztelje
a végpontot. A bemenetből következtetés készül a modellel a szolgáltatásban,
és a modell Rain vagy No_Rain előrejelzése lesz a POST hívás kimenete, ahogy
8.8 ábra: A POST hívás (/predict végpont) kimenete

A sikeresen végrehajtott POST hívás a /predict API-nál a modell előrejelzés
kimeneténél hoz eredményt, ahogy a 8.6 ábrán látható. A Docker konténerben
futó modell kiírja az időjárási körülményt Rain formájában a POST híváshoz.
Gratulálok, sikeresen lerakott egy fastAPI konténert és tesztelte azt. Ez a gyakorlat
ellátta Önt a készségekkel, hogy ML-alapú API szolgáltatások alakítson ki, telepítsen
és teszteljen a felhasználási esetéhez.
Összefoglalás
Ebben a fejezetben megtanultuk az API tervezésének és a mikroszolgáltatás termelésben
történő telepítésének fő elveit. Érintettük az API-tervezési módszerek alapjait és tanultunk
a FastAPI-ról. Az üzleti problémánknál elkészítettük egy API szolgáltatás fejlesztésének
gyakorlati megvalósítását az Egy ML modell API-ként történő kiszolgálásának gyakorlati
megvalósítása részben a FastAPI és Docker használatával. Az ebben a fejezetben szerzett
gyakorlati tudás felhasználásával robosztus API szolgáltatások tervezhet és telepíthet az
ML modelljeinek kiszolgálására. Az API szolgáltatások fejlesztése az ML modellekhez egy
lépcsőfok az ML modellek termelésbe való eljuttatásához.
A következő fejezetben elmélyedünk a tesztelés és biztonság fogalmaiban. Megvalósítunk
egy tesztelési módszert egy API szolgáltatás robosztusságának teszteléséhez a Locust
használatával. Gyerünk!
9
Az Ön ML
megoldásának
tesztelése és
biztosítása
Ebben a fejezetben elmélyedünk a gépi tanulási (ML) megoldás tesztelési és biztonsági
vonatkozásaiban. Várhatóan megkapja az alapokat a tesztek különböző típusairól az
ML megoldásának méretezhetőségi és robosztussági teszteléséhez, valamint az ML
megoldásának biztosításához szükséges tudást. Megnézünk több, az ML megoldások ellen
irányuló támadást és az ML megoldás megvédésének módjait.
Ebben a fejezetben példákkal fogunk tanulni, ahogy terheléstesztelést és biztonsági
tesztelést hajtunk végre az időjárás előrejelző üzleti felhasználási esetnél, amelyen
korábban dolgoztunk. Kezdésként reflektálunk az ML megoldás tesztelésének és
biztosításának szükségességére és következő témák felderítésével folytatjuk a fejezetben:
• Az ML alkalmazásának tesztelési és biztosítási igényének felismerése

• Az Ön ML megoldásának tesztelése a tervezés szerint
• Az Ön ML megoldásának biztosítása a tervezés szerint
214 Az Ön ML megoldásának tesztelése és biztosítása
Az ML alkalmazásának tesztelési és biztosítási

igényének felismerése
Az adatközpontú és ML-alapú megoldások növekvő terjedése miatt az üzleteknek kezelnie
kell a növekvő munkaterheléseket, ez további komplexitási és sebezhetőségi szinteknek
teszi ki őket.
A kiberbiztonság a legriasztóbb kockázat az MI fejlesztőinek és felhasználóinak. A Deloitte
által kiadott felmérés alapján (https://www2.deloitte.com/us/en/insights/
focus/cognitive-technologies/state-of-ai-and-intelligent-
automation-in-business-survey.html) 2020 júliusában az alkalmazók
62%-a figyelt meg jelentős vagy rendkívüli veszélyességű kiberbiztonsági kockázatot,
de csak 39% állította, hogy felkészültnek érezte magát a kockázatok kezelésére.
Ebben a részben megnézzük az ML-alapú rendszerek és megoldások biztosításának igényét.
Reflektálunk az ML rendszerek néhány nagyobb kihívására, mint amilyen az elfogultság,
etika és magyarázhatóság. Tanulmányozunk néhány kihívást az ML életciklusának minden
szakaszából a bizalmassághoz, integritáshoz és elérhetőséghez kapcsolódóan, felhasználva
az ML tervezés szerinti tesztelésének és biztosításának vezérelveit.
Az Ön ML megoldásának tesztelése a tervezés

szerint
A rendszeres szoftverfejlesztési tesztek végrehajtásán felül (mint például egység tesztek,
integrációs tesztek, rendszerteszt és elfogadási teszt) az ML megoldásoknak további
tesztekre van szüksége, mivel adatok és ML modellek érintettek. Mind az adatok,
mind a modellek dinamikus változnak az időben. Itt van néhány elv a tervezés szerinti
teszteléshez; alkalmazásuk az üzleti eseteinél biztosíthatja a robosztus ML megoldások
készítését eredményként.
Adatok tesztelése
Az adatok tesztelésének célja, hogy biztosítsuk, hogy az adatok elég jó minőségűek-e az
ML modell tanításához. Minél jobb az adat minősége, annál jobb modelleket tanítunk be
az adott feladatokra. Szóval hogyan értékeljük az adatminőséget? Az adatok következő öt
tényezőjének vizsgálatával:
• Pontosság
• Teljesség (nincsenek hiányzó értékek)
• Konzisztencia (az adat várható formátumának és mennyiségének tekintetében)
• Relevancia (az adatoknak meg kell felelnie a tervezett igényeknek és szükségleteknek)
• Időbeniség (a legújabb vagy naprakész adatok)
Az Ön ML megoldásának tesztelése a tervezés szerint 215
Ezen tényezők alapján, ha egy vállalat képes kezelni minden egyes adatkészlet
adatminőségét, amikor megkapja vagy létrehozza azt, akkor az adatminőség garantált.
Itt van néhány lépés, amelyet a csapata vagy vállalata használhat az adat minőségbiztosítási
intézkedésént:
1. Aprólékos adatkatalogizálás és a bejövő adatok irányítása: Az adatkatalogizálás

(az adatok szükséges formátumban vagy minta szerinti dokumentálása és tárolása)
és az irányítási funkciók kombinációja biztosíthatja a bejövő adatok magas
minőségét. Az adatok katalogizálása és irányítása elvégezhető az olyan adattényezők
monitorozásával, mint az adatok formátumai és mintái, értékeloszlások és anomáliák,
teljesség és konzisztencia, ezek segíthetnek biztosítani a bejövő adatok jó minőségét.
2. Adatfolyamatok gondos felügyelete a duplikált adatok elkerüléséhez: Amikor
duplikált adat készül ugyanabból az adatforrásból, és ha ugyanazt a logikát
használják különböző emberek, akkor bonyolulttá válhat a származás, hitelesség és
adatintegritás kezelése. Ez kaszkád effektusokat hozhat létre a több rendszer vagy
adatbázis miatt. Jobb elkerülni az adatok duplikálását, amennyire csak lehetséges.
3. Adatirányítás megerősített integritással: Napjainkban az adatintegritás fenntartása
kritikussá vált. Ha nincs meg az adatintegritás erőltető gondolkodásmód, az
költséges lehet egy szervezetnek. Az adat véletlenül hiányossá, késetté vagy elavulttá
válhat, amely komoly adatminőségi problémákhoz vezet.
4. End-to-end követhetőség és származás fenntartása: Az adatok származása és
követhetősége elérhető a metaadatok és az adatok okos használatával. Mindkettő
használatával dokumentálhatjuk az olyan kritikus információkat, mint az egyedi
kulcsok az egyes adatkészletekhez, egy időbélyeg hozzáadása minden bejegyzéshez
és az adatváltozások naplózása. Az adatszármazás és end-to-end követhetőség
biztosítása megadhatja a lehetőséget, hogy reprodukáljuk a modelleket és
debuggoljuk a hibákat és folyamatokat.
Modelltesztelés
A modelltesztelésnek le kell fednie az olyan szerverhibákat, mint a következők:
• Az ML modell pontosságának vagy fő mérőszámainak értékelése

• Tesztelés random adatpontokon
• Az elfogadható veszteség vagy teljesítmény tesztelés a feladatnál
• Egység tesztelések a modell robosztusságához, valós adatok használatával
Ezek a tesztek két fázisban szervezhetők: tanítás előtt és után. Ezen tesztek beleillesztése
a munkafolyamatba robosztus modelleket készíthet a termelésnek. Nézzük meg, mit tehet
a tervezés által a tanítás előtti és utáni tesztelés.
Tanítás előtti tesztek

Teszteket lehet végrehajtani, hogy elcsípjük a hibákat, mielőtt elérnénk a tanítási szakaszt.
Ezek lehetnek az adatok, folyamatok vagy paraméterek hibái. A 9.1 ábra tanítás előtti
és utáni tesztek futtatását ajánlja egy javasolt munkafolyamat részeként a jó minőségű
modellek fejlesztéséhez:
9.1 ábra: Javasolt munkafolyamat a jó minőségű modellek fejlesztéséhez

Itt van néhány módja a tanítás előtti hibák észlelésének és elkerülésének a tanítás előtti
tesztek használatával:
• Az adatfolyamat adósságának megszüntetése az adatszivárgás, perem esetek és

optimalizálás kezelésével, hogy a folyamat időben és erőforrásokban hatékony legyen
• Gondoskodjon róla, hogy a modellkimenet alakja illeszkedjen a címkékhez az
adatkészletében
• Vizsgálja meg a kimenet tartományai, hogy azok biztosan megfeleljenek
az elvárásainknak (például annak ellenőrzése, hogy egy osztályozó modell
kimenetének eloszlásánál az osztályvalószínűségek összege 1)
• Vizsgálja meg a tanítási és validálási adatkészletek címkehiányát
• Gondoskodjon az ETL folyamat kimeneteiről vagy szerezzen adatokat a kívánt
formátumban
A tanítás előtti teszteknek nincs szükségük paraméterekre a futáshoz, de elég hasznosak

lehetnek a hibák felfedezésében a modelltanítás futtatása előtt.
Tanítás utáni tesztek

A tanítás utáni tesztek lehetővé teszik, hogy megvizsgáljuk a modellteljesítményt és
a modell előrejelzései mögötti logikát, és megjósoljuk a lehetséges hibákat a modellben,
mielőtt telepítenénk a termelésben. A tanítás utáni tesztek lehetővé teszik, hogy észleljük
a modell teljesítményének és funkcionalitásának hibáit. A tanítás utáni tesztek magukba
foglalják a modell teljesítményét értékelő tesztet, változatlansági tesztet és a minimális
funkcionalitás tesztjét. Itt van egy ajánlott olvasnivaló a tanítás utáni tesztek további
ötleteihez: Beyond Accuracy: Behavioral Testing of NLP Models with CheckList
(https://homes.cs.washington.edu/~marcotcr/acl20_checklist.pdf)
Gyakorlatias telepítés- és következtetés-tesztelés (egy üzleti felhasználási eset) 217
Telepítés és következtetés tesztelése

A telepítés tesztelése magába foglalja a Folytonos integráció/Folytonos szállítás (CI/
CD) folyamat szállításának, integrációjának tesztelését, valamint a telepítés sikerességének
tesztelését. Kritikus a telepített modell tesztelése, és itt jön szóba a következtetés tesztelése a
telepített modell terheléses teszteléséhez, és a teljesítmény teszteléséhez valós idejű adatokkal.
A következő részben terheléssel teszteljük a korábban telepített modellt (egy felhasználási
esethez).
Gyakorlatias telepítés- és következtetés-

tesztelés (egy üzleti felhasználási eset)
Amikor készen áll a szolgáltatása (API vagy ML), és készül átadni a felhasználóknak,
de ötlete sincs róla, hány felhasználó használhatja valójában, és hogyan fog reagálni,
ha sok felhasználó fér hozzá egyszerre, akkor itt lesz hasznos a terheléses tesztelés annak
mérésére, hogy a szolgáltatása hány felhasználót képes kiszolgálni és annak validálására,
hogy a szolgáltatás megfelel-e az üzleti követelményeknek.
Terheléses tesztelést fogunk végrehajtani a korábban telepített (a 7. fejezet: Robosztus CI és
CD folyamatok kialakítása) szolgáltatásnál. A terheléses teszteléshez a Locust.io-t fogjuk
használni. A locust.io egy nyílt forráskódú terheléstesztelő eszköz. Ehhez telepíteni
fogjuk a locust-ot (a pip használatával) és megvizsgálunk egy Python szkriptet a locust.io
SDK használatával egy végpont teszteléséhez. Kezdjük a locust telepítésével:
1. A locust telepítése: menjen a terminálhoz és hajtsa végre a következő parancsot:

pip install locust
A pip használatával a locust telepítésre kerül, ez nagyjából egy percet vesz

igénybe. A sikeres telepítés után ideje megvizsgálni a Python szkriptet a locust.
io SDK használatával egy végpont teszteléséhez.
2. Vizsgáljuk meg a load_test.py szkriptet: Lépjen a kedvenc IDE-jebe és kezdje
el vizsgálni a szkriptet, vagy kövesse a lépéseket az előkészített szkriptben. Az
előkészített szkript eléréséhez menjen a korábban klónozott Engineering MLOps
adatraktárba, keresse meg a 09_Testing_Security mappát és menjen a load_
test.py fájlhoz. Rántsuk le először a leplet a kódról a load_test.py fájlnál,
a szükséges könyvtárak importálása a következőképpen történik:
import time
import json
from locust import HttpUser, task, between
Importáltuk a time, json és locust könyvtárakat, majd a locust könyvtárból

importáljuk a következő szükséges függvényeket: HttpUser (egyfelhasználói
ágens, amely képes különböző végpontok meglátogatására), task és between.
3. Hozzon létre egy test_data változót a tesztadatmintával, amivel az ML modell
következtet a terheléses teszt során. Definiálja a headers-t, amelyet az API
meghívására fogunk használni a terheléses tesztünknél:
test_data = json.dumps({"data": [[8.75, 0.83, 70, 259,
15.82, 1016.51, 1.0]]})
headers = {'Content-Type': 'application/json'}
4. Következőként megvalósítjuk a terheléses teszt fő funkcionalitását az

MLServiceUser osztály részeként (tetszés szerint elnevezheti) a HttpUser
bővítésével. A HttpUser a felhasználói ágens, amely meglátogatja a különböző
végpontokat:
class MLServiceUser(HttpUser):
wait_time = between(1, 5)
@task
def test_weather_predictions(self):
self.client.post("", data=test_data,
headers=headers)
Létrehoztunk egy wait_time változót a between() függvény használatával,

amely megadja, hogy mennyi idő telik el az egyik végponton befejezett tesztelés és
a következő végpont tesztelésére való váltás között. Tehát megadjuk, hogy wait_
time az 1 és 5 másodperc, a between(1,5) függvényben. A következő rész egy
feladat definiálásának nehézsége, amely teszteli a végpontot.
Ehhez egy @task csomagolót vagy dekorátort használunk, hogy kezdje el
definiálni a feladatunkat egy általunk választott végpont tesztelésére egy egyedi
függvény használatával. Definiáljon egy egyedi függvényt, def test_weather_
predictions() és készítsen egy post kérést a végpontra a test_data és
a korábban definiált headers használatával. Így már mindent beállítottunk a
terheléses teszteléshez!
5. Futtassa a locust.io szervert: Menjen a termináljához, és módosítsa a
load_test.py fájl helyét (ahogy a 09_Testing_Security mappában van
a könyvben használt klónozott adatraktárban), majd futtassa a következő parancsot
egy locust.io szerver elindításához:
Locust -f load_test-py
Az előző parancs végrehajtása elindítja a locust szervert a 8089 porton.

Végrehajthatjuk a terheléses teszteket a locust.io-val renderezett webes
interfészen. A webszolgáltatás eléréséhez nyisson meg egy tetszőleges böngészőt
és menjen a következő webhelyre: http://0.0.0.0:8089/, ahogy a 9.2 ábrán
látható:
9.2 ábra: A Locust.io webszolgáltatás elérése

6. Futtassa a terheléses tesztet: A webszolgáltatás megnyitása felszólítja Önt, hogy
adja meg az olyan opciókat, mint a felhasználók száma, a letételi arány és a hoszt
(a tesztelendő végpont). Adja meg a felhasználók számát a szimuláláshoz és a letételi
arányt (hány felhasználó lesz letéve másodpercenként) az Ön követelményei szerint,
hogy validálja, a végpontja képes-e kiszolgálni az üzleti/felhasználói igényeket,
például 50 felhasználó és 50-es letételi arány.
7. Végül adja meg a végpontot vagy hosztot, amelyet terheléssel szeretne tesztelni
és nyomja meg a Start swarming gombot, hogy elindítsa a terheléses teszt
végrehajtását. A 7. fejezet: Robosztus CI és CD folyamatok kialakítása részben
telepítettünk egy végpontot. Ajánlott a telepített végpontot tesztelni.
8. Menjen az Azure ML munkaterületére, lépjen be az Endpoints részre, lépjen
a dev-webservice nevű telepített végpontra, és másolja ki a végpont webcímét
a hoszt szövegdobozába.
9. Következőként kattintson a Start swarming gombra, hogy elindítsa végpont
terheléses tesztelését. Ez elindítja a terheléses tesztet és megnyit egy új oldalt, ahol
valós időben monitorozhatja a terheléses tesztjeit, ahogy a 9.3 ábrán látható:
9.3 ábra: A terheléses teszt valós idejű monitorozása

10. A terheléses teszt eredményeinek elemzése: Valós időben monitorozhatja
a statisztikákat, diagramokat, hibákat és kivételeket. Például a 9.3 ábrán a terheléses
tesztet monitorozzuk a /score végponton, amely egy POST kérés használatával
következtet a tesztadatokkal. A kérések száma (77459), a hibák száma (0), az átlagos
válaszolási idő (75 ms) és még egyéb információk is monitorozhatók. Fontos
ellenőrizni, hogy ne legyenek hibák, és hogy az átlagos válaszolási idő olyan
tartományon belül legyen, amely hatékonyan szolgálja ki az üzleti/felhasználói
igényeket, és ne legyenek nagyobb sebességtörések.
Ha nincsen hibás elrontott kérés és az átlagos válaszolási idő a szükséges

tartományon belül van, akkor a végpontja átment a terheléses teszten, és készen
áll rá, hogy átadják a felhasználóknak. A terheléses tesztelés során vagy után
megtekintheti a terheléses teszt teljesítményének diagramjait az olyan kritikus
információkkal, mint a másodpercenkénti összes kérés, válaszolási idők, és a
felhasználók száma az idő előrehaladtával. Valós időben tekinthetjük meg ezeket
az információkat, ahogy 9.4 ábrán és 9.5 ábrán látható:
9.4 ábra: A másodpercenkénti összes kérés és válaszidők diagramjai

A 9.4 ábrán észrevehetjük, hogy a másodpercenkénti kérések száma a 18-22
tartományba esik, ahogy a locust.io szimulált felhasználói kéréseket küldenek,
és a válaszolási idő néhány esetben 70 és 500 között változik milliszekundumban ,
430 ms-os varianciával a minimum és maximum között. Az átlagos válaszolási idő
75 ms (ahogy a 9.3 ábrán látható).
Kérjük, vegye figyelembe, hogy ez a teljesítmény egy adott felhasználási esetnél lehet
is ideális és nem is, az Ön üzleti vagy felhasználói igényeitől függően. Egy stabilabb
válaszolási idő a kívánatos; például egy 50 ms-nál kevesebbet változó válaszolási idő
a minimum és maximum válaszolási idők között kedvezőbb lehet egy stabil
teljesítményhez. Az ilyen teljesítmény eléréséhez ajánlott a modelljeit felsőbb kategóriás
infrastruktúrán telepíteni, ahogy megfelelő, például egy GPU-n vagy egy felső kategóriás
CPU-n, nem pedig egy CPU-n egy Azure konténerpéldányon. Ehhez hasonlóan
a 9.5 ábrán láthatjuk a válaszolási időket a felhasználók számának arányában.
9.5 ábra: A másodpercenkénti összes kérés és a felhasználók számának diagramjai

Láthatjuk, hogy a másodpercenkénti felhasználók száma 50, ahogy említettük (a 9.2
ábránál). Ahogy az idő halad, a letételi arány állandó és a válaszolási idő változik 70-500
ms között, 75 ms átlagos válaszolási idővel.
1. Eredmények dokumentálása vagy letöltése: A terheléses teszt sikeres végrehajtása

után dokumentálhatja vagy bemutathatja a terheléses teszt eredményeit a
releváns részvényeseknek (QA/termékmenedzser) egy tesztjelentés használatával.
A tesztjelentés eléréséhez vagy eltöltéséhez menjen a Download Data részre és
töltse le a szükséges információt, mint például a kérések statisztikája, hibák vagy
kivételek, .csv fájlok formájában, ahogy a 9.6 ábrán látható:
9.6 ábra: A teszteredmények letöltése

Töltse le a statisztikát vagy hibajelentéseket, amelyek az igényei szerinti további
vizsgálatokhoz szükségesek, és jegyezze meg, hogy elérheti a teljes tesztjelentést,
ha rákattint a Download the Report gombra, ahogy a 9.7 ábrán látható:
9.7 ábra: A teszteredmények letöltése

Egy átfogó tesztjelentést láthatunk kritikus információkkal, mint amilyen a következtető

végpont átlagos kérésideje és a kérési idők minimuma és maximuma, ez az információ
vizualizált diagramok formájában is megjelenik, ahogy a 9.7 ábrán látható. le is töltheti ezt
a teljes jelentést, hogy bemutassa a részvényeseinek.
Gratulálok, végrehajtott egy gyakorlatias terhelési tesztet, hogy validálja a végpontját
és ellenőrizze, hogy az ML szolgáltatása képes-e hatékonyan kiszolgálni az üzleti vagy
felhasználói igényeket.
Az Ön ML megoldásának biztosítása a tervezés

szerint
Az ML alkalmazásainak biztosítása fontosabb, mint valaha az MI növekvő elterjedése
miatt az okos alkalmazásoknál. Az ML rendszerek tervezése és fejlesztése a biztonság
figyelmen kívül hagyásával költséges lehet abban a tekintetben, hogy kiteszi a rendszert
a hekkereknek, manipulációhoz, adatvédelmi incidensekhez és a megfelelőség
elvesztéséhez vezet. A robosztusság és biztonság fontos szerepet játszik egy MI rendszer
megbízhatóságának biztosításában. Megbízható ML alkalmazások kialakításához
kulcsfontosságú észben tartani a biztonságot, hogy ne maradjon támadási felület.
A 9.8 ábra egy keretrendszert mutat a tervezés miatt biztonságos ML alkalmazások
létrehozásához. A keretrendszer kulcsfontosságú területeket kezel az ML életciklusában,
biztosítja a bizalmasságot, integritást és elérhetőséget adott szakaszokon belül.
Reflektáljunk az ML életciklusának egyes területeire, és kezeljük a bizalmasság, integritás
és elérhetőség problémáját az egyes területeken:
9.8 ábra: Keretrendszer az ML életciklus tervezés általi biztosításához

Az Ön ML megoldásának biztosítása a tervezés szerint 225
Reflektáljunk az ML életciklusának egyes területeire, és kezeljük a bizalmasság, integritás

és elérhetőség problémáját az egyes területeken, miközben megnézzük a támadások
különböző típusait.
Támadások típusai
Megnézünk néhányat az ML rendszerek leggyakoribb támadásaiból. Magas szinten
a hekkerek támadásai négy kategóriára bonthatók: mérgezés, bemeneti támadások és
kitérés, visszatervezés és hátsó ajtós támadások. Nézzük meg, a támadók hogyan jutnak
be az ML rendszerekbe ezekkel a támadásokkal.
Mérgezés
Egy hekker vagy támadó azt keresi, hogyan rongálhatja meg az MI modellt egy mérgezéses
támadásnál. Mérgezéses támadások bármelyik szakaszban (tanítás, telepítés vagy valós
idejű következtetés) történhetnek. Jellemzően a tanítás és következtetés során történnek.
Nézzük meg a mérgezéses támadások megvalósításának három jellemző módját:
• Adatkészlet mérgezése: A tanítási adatkészletek tartalmazzák azt a tudást, amellyel

a modellt betanítják. Egy támadó manipulálhatja ezt a tudást a tanítási adatkészletbe
való bejutással. Itt a támadó rosszul címkézett vagy helytelen adatokat juttat be
a tanítási adatkészletbe, és ezzel az egész tanítási folyamat torzul. Ez egy közvetlen
módja egy modell mérgezésének. A tanítási adatkészletek megmérgezhetők az
adatgyűjtés és kezelés fázisai során, és nehéz lehet észrevenni vagy észlelni, mivel
a tanítási adatkészletek több forrásból érkezhetnek, lehetnek nagyok, és a támadó
bejuthat az adatelosztókba is.
• Az algoritmus mérgezése történik, amikor egy támadó belekontárkodik a modell
tanítására használt algoritmusba. Ez lehet olyan egyszerű, mint a hiperparaméterek
módosítása vagy az algoritmus szerkezetének megbabrálása. Például nézzük az
egyesített tanulást (amelynek a célja az egyének adatainak biztosítása), ahol modell
tanítása privát adatok több alkészletén (például egészségügyi adatok több kórháztól,
a betegek bizalmas adatainak megőrzésével) történik. Minden alkészletből több
modell származik, majd kombinálják őket egy végső modell kialakításához.
Ezalatt egy támadó manipulálhatja az adatok bármelyik alkészletét, és hatással lehet
a végső modellre. A támadó egy hamis modellt is létrehozhat hamis adatokból
és összefűzheti olyan modellekkel, amelyeket a privát adatok több alkészletén
tanítottak be. Így egy olyan végső modell jön létre, amely nem végzi hatékonyan
a feladatot vagy a támadó szándékait szolgálja.
• A modell mérgezése következhet be, amikor egy támadó kicseréli a telepített
modellt egy alternatív modellre. Ez a támadás megegyezi kegy tipikus
kibertámadással, ahol a modellt tartalmazó elektronikus fájlokat módosíthatják
vagy cserélhetik ki.
Bemeneti támadás és kitérés

Egy bemeneti vagy kitéréses támadás történik, amikor a támadó módosítja az ML rendszer
bemenetét úgy, hogy az a rendszer hibás működését (vagy rossz következtetést) okozza.
Ezek a zavarkeltések vagy módosítások lehetnek nehezen észlelhetők, mivel a változások
nagyon finomak vagy kicsik.
Például a bemeneti támadások népszerűek a számítógépes látás algoritmusainál.
Ez elvégezhető csupán néhány pixel módosításával a bemeneti képen. Ennek
eredményeként a rendszer lehet, hogy úgy azonosít egy képet, ahogy nem kéne vagy rossz
előrejelzést készít. Az ilyen kis módosítások hatékonyan manipulálhatják az előrejelzést,
amely a rendszer rossz tevékenységeit eredményezi. Ennek eredményeként az ML rendszer
úgy viselkedik, ahogy kell, miközben a kimenetet manipulálták.
Az ML rendszerek nagyon érzékenyek a bemeneti támadásokra. Így egy anomáliadetektor
elég hasznos lehet a bejövő adatok figyelésére, hogy elkerülje az ilyen zavarokat a bejövő
adatokban. A bemeneti adatoktól függetlenül az osztályozási modellek nagy része egy
érvényes osztályt választ a betanításából. Az ML rendszer védelmének másik módja
a bemenetek előfeldolgozása egy proxy bináris modellel, amely megmondja például, hogy
egy bemeneti képen egy személy vagy egy állat van-e, mielőtt elküldi ezt a képet a végső
képosztályozóhoz.
Visszatervezés
Egy MI rendszer felhasználójának az lehet egy fekete vagy nem átlátszó doboz. Gyakori
az Mi rendszereknél, hogy bemeneteket fogadnak kimenetek generálásához anélkül,
hogy megmutatnák, mi van belül (mind logika, mind algoritmus tekintetében). A tanítási
adatkészletek, amelyek hatékonyan tartalmazzák az összes betanított rendszer tudását,
általában bizalmasok. Ez elméletileg lehetetlenné teszi egy külsősnek, hogy megjósolja,
miért bizonyos kimenetek jönnek létre, vagy hogy mi megy az MI rendszer belsejében
az algoritmus, tanítási adatok vagy logika tekintetében. Azonban néhány esetben
ezek a rendszerek érzékenyek lehetnek a visszatervezésre. A támadó vagy hekker célja
a visszatervezéses támadásoknál, hogy lemásolja az eredetileg szolgáltatásként telepített
modellt és saját céljára használja.
Egy Model Extraction Attacks against Recurrent Neural Networks (https://arxiv.
org/pdf/2002.00123.pdf) című dokumentumban, amelyet 2020 februárjában
adtak ki, a kutatók kísérleteket végeztek a modellkinyerési támadásokkal egy RNN és egy
LSTM nyilvánosan elérhető tudományos adatkészletekkel tanított modelleken. A kutatók
ténylegesen reprodukálták egy ML rendszer funkcionalitását egy modellkinyerési
támadáson keresztül. Bemutatták, hogy egy nagy pontosságú modellkinyerési támadás
kinyerhető hatékonyan, elsődlegesen egy loss függvény vagy architektúra konfigurálásával
vagy másolásával a célmodellről.
Egy másik esetben a Max Planck Institute for Informatics kutatói bemutatták 2018-ban,
hogyan voltak képesek információt következtetni egy nem átlátszó modellből egy sor
bemeneti-kimeneti kérés használatával.
Összefoglalás 227
Hátsó ajtós támadások

A hátsó ajtós támadásoknál a támadások választásuk szerinti mintákat foglalhatnak
magukba a modellben a betanítás vagy következtetés szakaszaiban, és következtethetnek
a telepített modellel az előre kezelt bemenetek használatával, hogy váratlan kimeneteket
vagy kapcsolókat produkáljanak az ML rendszernek. Ezért a hátsó ajtós támadások
történhetnek mind a tanítás, mind a következtetés fázisaiban, míg a kitérés és mérgezési
támadások csak egy fázisban következhetnek be a tanítás vagy következtetés alatt.
A mérgezéses támadások felhasználhatók a hátsó ajtós támadások részeként, és néhány
esetben a tanuló modell megtanulhat meghekkelni néhány hátsó ajtót a tanító modelltől
az átvitt tanulás használatával.
A hátsó ajtós támadások integritási kihívásokat okozhatnak, különösen a tanítás fázisában,
ha a támadó egy mérgezéses támadást használ arra, hogy bejusson a tanítási adatokba és
aktiváljon egy frissítést a modellen vagy rendszeren. A hátsó ajtós támadások célozhatják a
teljesítmény rontását, az erőforrások kimerítését vagy átirányítását is, ami rendszerhibához
vezethet, vagy megpróbálhatnak különös viselkedést vagy kimeneteket bevinni az MI
rendszerből.
Összefoglalás
Ebben a fejezetben megtanultuk az API tervezés általi tesztelésének és biztosításának fő
elveit. Megismertük az ML megoldások különféle tesztelési módszereit, hogy biztosítsuk
őket. Az átfogó értelmezés és gyakorlati tapasztalat érdekében megvalósítottuk a korábban
telepített ML modell (a 7. fejezet: Robosztus CI és CD folyamatok kialakítása részben)
terheléses tesztjét, hogy megjósolja az időjárást. Ezzel készen áll rá, hogy különböző
tesztelési és biztonsági szituációkat kezeljen, amellyel találkozik.
A következő fejezetben el fogunk mélyedni a robosztus ML szolgáltatások termelésben
történő telepítésének és fenntartásának titkaiban. Ez lehetővé teszi, hogy robosztus ML
megoldásokat telepítsen a termelésben. Merüljön el benne!
10
A termelési kiadás
lényeges részei
Ebben a fejezetben a folytonos integráció és folytonos szállítás (CI/CD) folyamatról
fog tanulni, egy termelési környezet lényeges részeiről, és hogy hogyan kell felállítani
egy termelési környezetet a korábban tesztelt és jóváhagyott gépi tanulásos (ML)
modelljeinek kiszolgálásához a végfelhasználók számára. Be fogjuk állítani a szükséges
infrastruktúrát a CI/CD folyamat termelési környezetéhez, konfigurálni fogjuk a termelési
telepítések folyamatait, a folyamatvégrehajtási kapcsolókat a teljes automatizációhoz,
és megtanuljuk kezelni a termelési kiadásokat. Ez a fejezet taglalja a CI/CD folyamat
és termelési környezet lényeges alapjait, mivel a folyamat a termék nem a modell.
A CI/CD folyamatok alapjainak megismerésével képes lesz automatizált CI/CD
folyamatokat fejleszteni, tesztelni és konfigurálni a felhasználási esetéhez vagy üzletéhez.
Egy sor témát fogunk lefedni a termelési telepítések kapcsán, majd elmélyedünk
a termelésben lévő ML modellek monitorozásáról szóló bevezetésben.
230 A termelési kiadás lényeges részei
Ebben a fejezetben a következő témákat érintjük:
• A termelési infrastruktúra felállítása

• A termelési környezetünk felállítása a CI/CD folyamatban
• A termeléskész folyamatunk tesztelése
• Folyamatkapcsolók konfigurálása az automatizációhoz
• Folyamat kiadáskezelés
• A szolgáltatás folytonos monitorozása felé
Kezdjük az infrastruktúra felállításával, amely szükséges a CI/CD folyamat kialakításához.
A termelési infrastruktúra felállítása

Ebben a részben felállítjuk a szükséges infrastruktúrát, hogy kiszolgáljuk az üzleti
felhasználási esetünket (hogy megjósoljuk az időjárási körülményeket, fog-e esni
vagy sem Turku kikötőben, hogy megtervezzék és optimalizálják az erőforrásokat
a kikötőben). Felállítunk egy automatikusan méretező Kubernetes klasztert, hogy
telepítse az ML modellünket egy webszolgáltatás formájában. A Kubernetes egy nyílt
forráskódú konténerkezelő rendszer a szoftveralkalmazások telepítésének, méretezésének
és kezelésének automatizálására. Számos felhőszolgáltató kínál Kubernetes-alapú
infrastruktúraszolgáltatást. Ehhez hasonlóan a Microsoft Azure is biztosít egy Kubernetes-
alapú infrastruktúraszolgáltatást, amelynek Azure Kubernetes Service (AKS) a neve.
Az AKS-t fogjuk használni az infrastruktúránk kezelésére.
Több módszer van egy automatikusan méretező Kubernetes klaszter biztosítására
az Azure-on. A következő két módszert nézzük meg, hogy megismerjük az
infrastruktúrabiztosítás különböző perspektíváit:
• Azure Machine Learning munkaterület portál

• Azure SDK
Nézzük meg először a legegyszerűbb módot; az Azure Machine Learning munkaterület

használatával biztosítsunk egy Azure Kubernetes klasztert a termeléshez.
A termelési infrastruktúra felállítása 231
Azure Machine Learning munkaterület

Ebben a részben egy Azure Kubernetes klasztert biztosítsunk a termeléshez az Azure
Machine Learning munkaterület használatával. Hajtsa végre a következő lépéseket:
1. Menjen az Azure Machine Learning munkaterületre, majd lépjen a Compute részre,

amely lehetőségeket biztosít különböző típusú számítások létrehozására. Válassza
ki az Inference clusters opciót és kattintson a Create gombra, ahogy a következő
képernyőképen látható:
10.1 ábra: Következtetési klaszterek biztosítása

2. A Create gombra való rákattintás különböző számítási opciókat jelenít meg,

amelyeket felhasználhat egy Kubernetes szolgáltatás létrehozására. Kapni fog egy
üzenetet, hogy válasszon ki egy Region-t, ahol a számítását biztosítani fogják, és
néhány konfigurációt, hogy milyen legyen az erőforrás a magok, RAM és tárhely
tekintetében. Válasszon ki egy megfelelő opciót (ajánlott a Standard_D2_v4
kiválasztása, mivel ez egy optimális költségű választás ehhez a kísérlethez,
ahogy a következő képernyőképen látható:
10.2 ábra: Egy megfelelő számítási opció kiválasztása

3. Miután kiválasztott egy megfelelő számítási opciót, megjelenik egy Configure
Settings ablak a klaszterhez, ahogy a következő képernyőképen látható. Nevezzük
el a Compute-ot (például legyen 'prod-aks' aminek a jelentése production
Azure Kubernetes Service), állítsuk be a Cluster purpose lehetőséget
Production-re (mivel a termeléshez készül), válasszuk ki a Number of nodes
lehetőséget a klaszterhez, és válasszuk ki a Basic opciót a Network configuration
részen. Az egyszerűség kedvéért hagyjuk ki az Enable SSL configuration
opciót. Azonban a nagyobb termelési biztonsághoz ajánlott engedélyezni az SSL
kapcsolatokat, az Ön igényei szerint:
10.3 ábra: Configure Settings (Konfigurációs beállítások)

4. Kattintson a Create gombra, hogy biztosítsa a Kubernetes klasztert a termelés
részére. A számítás létrehozása és biztosítása a termelés részére nagyjából 15 percet
vesz igénybe:
10.4 ábra: A biztosított Kubernetes klaszter

5. Ha már biztosította az AKS klaszterét, egy futó Kubernetes klasztert fog látni azzal
a névvel, amelyet megadott a számításnál (például prod-aks), ahogy az előző
képernyőképen látható.
Azure Machine Learning SDK

Egy alternatív módszer egy Kubernetes klaszter létrehozására és biztosítására az Azure-on
az Azure Machine Learning SDK használata. Használhat egy előre elkészített create_
aks_cluster.py nevű szkriptet, amely megtalálható a 10_Production_Release
mappában. A create_aks_cluster.py szkript futtatásának előfeltétele a config.
json fájl (letölthető az Azure Machine Learning munkaterületről) az Azure Machine
Learning munkaterületénél, ahogy a következő képernyőképen látható:
10.5 ábra: A config fájl megszerzése az Azure Machine Learning munkaterületéről

Menjen az Azure Machine Learning munkaterületére és kattintson a Download config.

json lehetőségre, hogy letöltse a konfigurációs fájlt. A letöltés után másolja vagy helyezze
át a config.json fájlt ugyanabba a könyvtárba (10_Production_Release), ahol
a create_aks_cluster.py fájl van, ahogy itt látható:
├──10_Production_Release
├── create_aks_cluster.py
├── config.json
Ezzel készen áll a szkript (create_aks_cluster.py) futtatására, hogy létrehozza az

AKS számítást a termelési telepítésekhez. Nézzük meg a create_aks_cluster.py
szkriptet:
1. Importálja a szükséges függvényeket az azureml.core SDK-ból

vagy könyvtárból. Az olyan függvényeket, mint a Workspace, Model,
ComputeTarget, AksCompute stb. fogjuk használni az AKS klasztere
biztosításához:
from azureml.core.compute import ComputeTarget
from azureml.core.compute_target import
ComputeTargetException
from azureml.core.compute import AksCompute,
ComputeTarget
2. A szükséges függvények importálásával elkezdheti használni őket, ha csatlakozik az

Azure Machine Learning munkaterületéhez és létrehozza a ws objektumot. Végezze
el ezt a Workspace függvény használatával és irányítsa rá a config.json
fájlra így:
'\n')
3. Alapértelmezetten a from_config() függvény megkeresi a config.json fájlt

ugyanabban a könyvtárban, ahol futtatja a create_aks.py fájlt. Ha a config.
json fájlja másik helyen van, akkor irányítsa oda a fájl helyét a from_config()
függvényben. Miután sikeresen végrehajtotta a workspace.from_config()
függvényt, látni fogja kiírva a munkaterület nevét, az erőforráscsoportot és helyet.
4. következőként létrehozunk egy AKS Kubernetes klasztert a termelési telepítések

részére. kezdésként válasszon egy nevet az AKS klaszterének (hivatkozzon vele az
aks_name változóra), mint például prod-aks. A szkript ellenőrzi, hogy létezik-e
már klaszter a választott névvel. Használhatjuk a try utasítást, hogy ellenőrizzük,
az AKS célja létezik-e a választott névvel, a ComputeTarget() függvény
használatával. Ennek a workspace objektum és aks_name lesznek a paraméterei.
Ha a választott névvel talál egy klasztert, akkor kiírja a talált klasztert, és abbahagyja
a végrehajtást. Másképp létrehoz egy új klasztert a ComputeTarget.create()
függvény használatával, amely a provisioning beállítást veszi alapértelmezett
konfigurációnak:
# Choose a name for your AKS cluster
aks_name = 'prod-aks'
# Verify that cluster does not exist already

try:
aks_target = ComputeTarget(workspace=ws, name=aks_
name)
print('Found existing cluster, use it.')
except ComputeTargetException:
# Use the default configuration (can also provide
parameters to customize)
prov_config = AksCompute.provisioning_configuration()
# Create the cluster

aks_target = ComputeTarget.create(workspace = ws,
name = aks_name,
provisioning_configuration = prov_config)
if aks_target.get_status() != "Succeeded":
aks_target.wait_for_completion(show_output=True)
Az előző kód sikeres végrehajtása után egy új klaszter jön létre a kiválasztott névvel (azaz
a prod-aks). Általában egy új klaszter létrehozása nagyjából 15 percet vesz igénybe.
Amikor a klaszter létrejött, megtekinthető az Azure Machine Learning munkaterületen,
ahogy a 10.4 ábrán láthattuk. Most, hogy beállítottuk az előkövetelményeket a CI/CD
folyamat javításához a termelési környezetünkben, kezdjük el a beállítást!
A termelési környezetünk felállítása a CI/CD folyamatban 237
A termelési környezetünk felállítása a CI/CD

folyamatban
Hajtsa végre a következő lépéseket egy termelési környezet beállításához a CI/CD
folyamatban:
1. Menjen az Azure DevOps projektbe, amelyen korábban dolgozott, és látogassa meg

újra a Pipelines | Releases részt, hogy megtekintse a Port Weather ML Pipeline-t.
Ezt a folyamatot fogjuk javítani egy termelési szakasz létrehozásával.
2. Kattintson az Edit gombra a kezdéshez, és kattintson az Add gombra a DEV TEST
részen, ahogy a következő képernyőképen látható:
10.6 ábra: Egy új szakasz hozzáadása

3. Ha rákattint az Add gombra a DEV TEST részen, akkor ki kell választania egy sablont
az új szakasz létrehozásához. Válassza az EMPTY JOB opciót (a Select a template
szöveg alatt) és adja a production vagy PROD nevet a szakasznak és mentse el,
ahogy a következő képernyőképen látható:
10.7 ábra: A termelés szakasz (PROD) hozzáadása és elmentése

4. Létrejön egy új termelési szakasz PROD néven. Most konfigurálhatja a feladatokat
és folyamatokat a termelési szakasznál. A PROD-nál a feladatok konfigurálásához
kattintson az 1 feladat, 0 feladat linkre (ahogy ez előző képernyőképen látható,
a PROD szakasznál) a PROD szakasznál. Át lesz irányítva a Tasks részre, ahol
feladatokat adhat hozzá a PROD szakaszhoz. Ebben a szakaszban az Azure
Machine Learning munkaterületről fogunk modelleket telepíteni, szóval csatlakozni
fogunk hozzá az AzureML Model Deploy sablon használatával, amelyet korábban a
7. fejezet: Robosztus CI és CD folyamatok kialakítása részben használtunk. Kattintson
a + jelre az Agent job rész jobb oldalán, hogy hozzáadjon egy feladatot, ahogy itt
látható:
10.8 ábra: Egy AzureML Model Deploy feladat hozzáadása

5. Keresse meg az AzureML Model Deploy sablont vagy feladatot és adja hozzá. A
feladat hozzáadása után megjelenik egy felugró ablak, hogy csatlakozzon az Azure
Machine Learning munkaterületéhez és konfigurálja azt. Válassza ki az Azure
Machine Learning munkaterületét (például mlops_ws) és irányítsa a Model
Artifact-ra modellforrásként. Azért csináljuk ezt, mert azt a Model Artifacts-ot
fogjuk használni, amelyet a 4. fejezet: Machine Learning folyamatok részben
tanítottunk be.
6. Következőként mutasson rá a következtetés konfigurációs fájlra az Azure DevOps

adatraktárában, ahogy a következő képernyőképen látható. A következtetés
konfigurációs fájl egy egyedi környezet konfigurációs beállításait tartalmazza,
amelyet a telepítéshez használtak. Ugyanazt a Config.yml konfigurációs fájlt
fogjuk használni, amelyet a DEV TEST környezethez használtunk, mivel a telepítési
környezet meg kell egyezzen:
10.9 ábra: A következtetési konfiguráció kiválasztása

Az alap konfiguráció elvégezhető az inferenceConfig.yml fájl kiválasztásával.
7. Következőként konfigurálni fogjuk a Deployment Information-t a telepítési

céltípus Azure Kubernetes Service formájában történő megadásával. Azért tesszük
ezt, mert ezt a termelési környezetet fogjuk használni a Kubernetes klaszterünk
automatikus méretezéséhez a termelési telepítéseknél. Az Azure Kubernetes service
telepítési célként történő kiválasztása után válassza ki a korábban létrehozott AKS
klasztert (például prod-aks), nevezze el a telepítését vagy webszolgáltatását
(például prod-webservice) és válassza ki a Deployment Configuration fájlt az
Azure DevOps adatraktárból, amely a folyamathoz csatlakozik, ahogy itt látható:
10.10 ábra: Telepítési információ konfigurálása

A telepítési konfigurációs fájlt fogjuk használni a termelési környezethez, ennek

a neve AksDeploymentConfig.yml. Tartalmazza a telepítésünkhöz tartozó
konfiguráció részleteit, beleértve az automatikus méretezés engedélyezését
a másolatok minimális és maximális számával, a hitelesítés konfigurációját,
a monitorozás konfigurációját és a konténer erőforrásigényeit a CPU-val
(más szituációkban, ahol nagyos gyors következtetésre vagy nagy memórián belüli
feldolgozásra van szükség, megfontolhatja egy GPU erőforrás használatát) és
a memóriaigényeket, ahogy itt látható:
AksDeploymentConfig.yml
computeType: AKS
autoScaler:
autoscaleEnabled: True
minReplicas: 1
maxReplicas: 3
refreshPeriodInSeconds: 10
targetUtilization: 70
authEnabled: True
containerResourceRequirements:
cpu: 1
memoryInGB: 1
appInsightsEnabled: False
scoringTimeoutMs: 1000
maxConcurrentRequestsPerContainer: 2
maxQueueWaitMs: 1000
sslEnabled: False
8. Válassza ki az AskDeploymentConfig.yml fájlt a Deployment Configuration

fájlunkként. Most nyomja meg a Save gombot, hogy felállítsa a PROD környezetet.
Ezzel sikeresen felállította a termelési környezetet és integrálta a CI/CD folyamatával az

automatizációhoz. Most teszteljük a folyamatot, azzal hogy végrehajtjuk.
A termeléskész folyamatunk tesztelése 243
A termeléskész folyamatunk tesztelése

Gratulálunk a termelési folyamat felállításához! Következőként tesztelni fogjuk
a robosztusságát. Ennek az egyik nagyszerű módja, hogy létrehozunk egy új kiadást,
megfigyeljük és megvizsgáljuk, hogy a termelési folyamat sikeresen telepíti-e a modellt
a termelésben (a termelésben a Kubernetes klaszter telepítése tartalmazza a folyamatot).
Kövesse ezeket a lépéseket a folyamat teszteléséhez:
1. Először hozzon létre egy új kiadást, menjen a Pipelines | Releases részre, válassza
ki a korábban létrehozott folyamatot (például: Port Weather ML Pipeline),
és kattintson a Create Release gombra a képernyő jobb felső részén, hogy elindítson
egy új kiadást, ahogy itt látható:
10.11 ábra: Egy új kiadás létrehozása

2. Válassza ki a tárgyakat, amelyeket telepíteni szeretne a folyamatban (például:

Learn_MLOps repo, scaler és support_vector_classifier)
modellként és válassza ki a verziójukat. (Az 1. verzió az ajánlott a PROD telepítések
teszteléséhez az első alkalommal), és kattintson a Create gombra a képernyő jobb
felső részén, ahogy az előző képernyőképen láthatta. Ha ezt megtette, elindul egy új
kiadás, ahogy a következő képernyőképen látható:
10.12 ábra: Új kiadás végrehajtása

3. A folyamat végrehajtása után mind a DEV TEST, mind a PROD szakaszok telepítve
lesznek (például: Release-5, ahogy az előző képernyőképen láthatta). ellenőrizhet
minden lépést minden szakaszban, ha monitorozza valamelyik szakasz (DEV TEST
vagy PROD) egyes lépéseinek naplóit, miközben a folyamat kiadása tart, a folyamat
sikeres telepítéséig. Az előző kiadások naplóit is ellenőrizheti.
Folyamatkapcsolók konfigurálása az automatizációhoz 245
4. Amikor ezt sikeresen elvégzi egy kiadáson, akkor a DEV TEST és PROD szakaszok
is telepítve lesznek a CI és CD használatával. Biztosítania kell, hogy a folyamat
robosztus legyen. Következőként jobban testre szabhatjuk a folyamatot egyedi
kapcsolók hozzáadásával, amelyek automatizálják a folyamatot emberi felügyelet
nélkül. A CI/CD folyamatok emberi felügyelet nélküli automatizálása kockázatos
lehet, de vannak előnyei, például a valós idejű folyamatos tanulás (monitorozás és
modellek újratanítása) és gyorsabb telepítések. Jó tudni, hogyan kell automatizálni
a CI/CD folyamatot emberi felügyelet nélkül a hurokban. Jegyezze meg, hogy sok
esetben ez nem ajánlott, mivel sok hibalehetőség van. Néhány esetben hasznos
lehet, nagyban függ a felhasználási esettől és az ML rendszer céljaitól. Nézzük meg a
kapcsolókat a teljes automatizációhoz.
Folyamatkapcsolók konfigurálása az
automatizációhoz
Ebben a részben három kapcsolót fogunk konfigurálni a tárgyak alapján, amelyeket már
csatlakoztattunk a folyamathoz. A kapcsolók, amiket be fogunk állítani a következők:
• Git kapcsoló: A kódmódosításokhoz a fő ágnál.

• Tárgyas kapcsoló: Amikor egy új modellt vagy tárgyat hozunk létre vagy
tanítunk be.
• Ütemező kapcsoló: Egy heti rendszerességű kapcsoló.
Nézzük meg részletesen az egyes folyamatkapcsolókat.

Egy Git kapcsoló beállítása

A csapatokban gyakori, hogy beállítanak egy kapcsolót a telepítéshez, amikor változtatnak
a kódon egy bizonyos ágnál az adatraktárban. Például amikor megváltoztatják a kódot
a master ágnál vagy a develop ágnál, aktiválódnak a CI/CD folyamatok, hogy telepítsék
az alkalmazást a PROD vagy DEV TEST környezetekben. Amikor egy pull kérés érkezik
a kódösszevonásra a master vagy develop ágban, a QA szakértő vagy a termékmenedzser
elfogadja a pull kérést, hogy összeolvadjon a megfelelő ággal. A master vagy develop
ágnál a kódváltoztatáskor generálódik egy kapcsoló, hogy létrehozzon egy új kiadást
a folyamatban. Kövesse ezeket a lépéseket, hogy létrehozzon egy kapcsolót a master ágban
a kísérlethez, ahogy a következő képernyőképen látható:
1. Menjen a Pipelines | Releases részre és válassza ki a folyamatát (például:

Port Weather ML pipeline). Majd kattintson az Edit lehetőségre:
10.13 ábra: A folytonos telepítésű kapcsolók beállítása (Git kapcsolók)

Átkerül egy portálra, ahol szerkesztheti a folyamatát (például: Port Weather ML
pipeline), így konfigurálhatja a folytonos fejlesztés kapcsolóit a tárgyaihoz.
2. Egy Git kapcsoló beállításához a master ágnál (amikor módosítást hajtanak végre
a master ágon, aktiválódik egy új kiadás) kattintson a Trigger ikonra (villám ikon)
és mozgassa az on/off kapcsolót kikapcsoltról bekapcsoltra. Ez aktiválni fogja
a folytonos telepítés kapcsolóját.
3. Végül adjon hozzá egy ágszűrőt és mutasson rá az ágra, amelyhez a kapcsolót
be akarja állítani (ebben az esetben a master ág), ahogy az előző képernyőképen
láthatta. Mentse a változtatásait a Git kapcsoló beállításához.
Ezen lépések megvalósításával beállított egy folytonos telepítés kapcsolót, hogy elindítson
egy új kiadást, amikor változások történnek a master ágon.
Egy Tárgyas kapcsoló beállítása

Az ML alkalmazásoknál a Tárgyas kapcsolók elég hasznosak. Amikor új modelleket vagy
tárgyakat (fájlokat) tanítanak be az adatkutatók a csapatban, hasznos dolog telepíteni ezeket
a modelleket egy tesztkörnyezetben, aztán esetleg a termelésben, ha jobbak vagy jobbnak
tűnnek az előző modellektől vagy kapcsolótól. Kövesse ezeket a lépéseket, hogy beállítson
egy folytonos telepítés kapcsolót, amely létre fog hozni egy új kiadást a folyamathoz, amikor
betanítanak egy új modellt, ahogy az a következő képernyőképen látható:

Port Weather ML pipeline). Majd kattintson az Edit lehetőségre:
10.14 ábra: A CD Tárgyas kapcsolók beállítása (SVC modell)

Amikor rákattint az Edit gombra, átirányítják egy portálra, ahol szerkesztheti

a folyamatát, ahogy az előző képernyőképen láthatta.
2. Egy Tárgyas kapcsoló beállításához a modelljénél kattintson a választott
modellre, például Support Vector Classifier (SVC), és kapcsolja be a
Continuous deployment trigger opciót. Az előző képernyőképen egy kapcsolót
engedélyeztek egy modellhez (SVC). Amikor egy új SVC modellt tanítanak be és
regisztrálnak modelljegyzékben, amely kapcsolódik az Azure Machine Learning
munkaterületéhez, akkor aktiválódik egy új kiadás, hogy telepítse az új modellt
a folyamaton keresztül.
3. Végül mentse el a változtatásait, hogy beállítson egy Tárgyas kapcsolót az SVC
modellhez. Beállított egy folytonos telepítés kapcsolót, hogy elindítson egy új
kiadást, amikor betanítottak egy új SVC modellt és regisztrálták az Azure Machine
Learning munkaterületén. A folyamat kikeresi az új modellt és telepíti azt a DEV
TEST és PROD környezetekben.
Ezen lépések végrehajtásával lesz egy beállított folytonos telepítés kapcsolója, amely elindít
egy új folyamatkiadást, amikor egy új tárgyat hoztak létre vagy regisztráltak az Azure
Machine Learning munkaterületén.
Egy Ütemező kapcsoló beállítása

Most egy időspecifikus Ütemező kapcsolót állítunk be a folyamathoz. Ez a kapcsolófajta
hasznos a rendszer fenntartásánál és frissítésénél, ami periodikus új kiadásokon keresztül
történik. Az Ütemező kapcsolók megadott időintervallumonként hoznak létre új
kiadásokat. Be fogunk állítani egy Ütemező kapcsolót minden hét hétfő de. 11 órára.
Ebben az időpontban aktiválódik egy új kiadás telepítése az SVC modell aktuális
verziójával a DEV TEST és PROD környezetekben. Kövesse ezeket a lépéseket egy
Ütemező kapcsoló beállításához.

Port Weather ML pipeline). Majd kattintson az Edit gombra, ahogy a következő
10.15 ábra: Egy Ütemező kapcsoló beállítása

Amikor rákattintott az Edit gombra, átkerül egy portálra, ahol szerkesztheti
a folyamatát.
2. Ahhoz, hogy beállítson egy ütemezett kapcsolót a folyamathoz, kattintson
a Schedule Set opcióra és aktiválja a Scheduled release trigger opciót. Majd
válassza ki, mikor akar bekapcsolni egy kiadást. Például az előző képernyőképen
minden hét hétfő de. 11 órára állítottunk be egy kapcsolót.
3. Végül mentse el a változtatásait, hogy beállítsa az Ütemező kapcsolót a folyamathoz.
Ezen lépések végrehajtásával beállított egy folytonos telepítés kapcsolót egy új

folyamatkiadás elindításához megadott időközönként.
Gratulálunk hozzá, hogy beállította a Git, Tárgyas és Ütemezett kapcsolókat. Ezek
a kapcsolók lehetővé teszik a teljes automatizálást a folyamatnál. Beállítottuk a folyamatot,
és most sikeresen tesztelhetünk és telepíthetünk modelleket. Van olyan lehetősége is, hogy
félig automatizálja a folyamatot azzal, hogy hozzáad egy embert vagy Minőségbiztosító
(QA) szakértőt, hogy hagyja jóvá az egyes szakaszokat a folyamatban. Például a tesztelési
szakasz után a QA szakértő adhat jóváhagyást, így elkezdheti a telepítést a termelésben,
ha minden sikeres volt a tesztelési szakaszban. QA szakértőként kulcsfontosságú,
hogy monitorozza a CI/CD folyamatát. A következő részben megnézzük a legjobb
gyakorlatokat a folyamatkiadások kezeléséhez.
Folyamat kiadáskezelés
A kiadások a CI/CD folyamatokban lehetővé teszik a csapata számára, hogy teljesen
automatizálják és folyamatosan szállítsák a szoftvert az ügyfeleinek, gyorsabban és
alacsonyabb kockázattal. A kiadások lehetővé teszik, hogy több termelési szakaszban
tesztelje és szállítsa a szoftverét, vagy félig automatizált folyamatokat állítson be
jóváhagyásokkal és igény szerinti telepítésekkel. Fontos kezelni és monitorozni ezeket
a kiadásokat. Kezelhetjük úgy a kiadásokat, hogy megnyitjuk a folyamatot a Pipelines
| Releases részen, és kiválasztjuk a CI/CD folyamatunkat (például Port Weather ML
Pipeline), ahogy a következő képernyőképen látható:
10.16 ábra: Folyamat kiadáskezelés

Itt nyomon követheti az összes kiadást és az előzményeiket, és műveleteket hajthat
végre minden kiadásnál, mint például: újratelepítés, félbehagyás, naplók ellenőrzése
stb. A következő képernyőképen lévő kiadásokat láthatja. Az egyes kiadásokra kattintva
(például Release 4) ellenőrizhetjük, melyik modellt és tárgyakat telepítették a kiadásban
és hogyan aktiválták a kiadást (manuálisan vagy automatikus kapcsolókkal). Ez biztosítja
a folyamat end-to-end követhetőségét. Ez az információ kritikus az ML rendszer
irányításához és megfelelőségéhez:
Folyamat kiadáskezelés 251
10.17 ábra: Egy kiadás vizsgálata

Jobb a megelőzés, mint a gyógyítás. Ahogy ellenőrizzük az incidenst egy hiba után, ez
segít megelőzni a lehetséges hibákat a kiadás utáni ellenőrzések végrehajtásával egy új
szolgáltatás vagy modell telepítése után. A kiadás alapos elemzése a telepítés után lehetővé
teheti, hogy megtudjuk a válaszokat a kritikus kérdésekre, mint amilyenek a következők:
• Mi működik és mi nem egy kiadásban?

• Voltak nehézségek a kiadásnál?
• Vannak nem egyértelmű folyamatok, amelyeket megoldhatna és jobban
magyarázhatóvá tehetne a következő kiadásnál?
Ezen kérdések kiadás utáni alapos átgondolása segíthet javítani és iterálni a stratégiáján
illetve jobb kiadáskezelő gyakorlatokat kifejleszteni.
A folytonos monitorozás felé

Ezzel felállítottunk egy teljesen automatizált és robosztus folyamatot. Idáig sikeresen
megvalósítottuk a telepítés részt avagy modult az MLOps munkafolyamatban (ahogy
az megvitattuk az 1. fejezet: MLOps WorkFlow alapjai részben). Fontos valós időben
monitorozni a telepített ML modellt és szolgáltatást ahhoz, hogy ismerjük a rendszer
teljesítményét, mivel ez segít maximalizálni annak üzleti hatását. Az egyike oka annak,
hogy az ML projektek nem hoznak üzleti értéket, a bizalom és az átláthatóság hiánya
a döntéshozásban. A bizalom kialakítása az MI rendszerekkel szemben létfontosságú
manapság, különösen ha alkalmazkodni akarunk a változó környezethez, szabályozó
keretrendszerekhez és a dinamikus ügyféligényekhez. A folytonos monitorozás lehetővé
teszi, hogy felügyeljük az ML rendszer teljesítményét és kialakítsuk a bizalmat az MI-k
irányába, hogy maximalizáljuk az üzleti értékünket. A következő fejezetben az MLOps
munkafolyamat monitorozó moduljáról fogunk tanulni és hogy hogyan kezeli a folytonos
monitorozást.
Összefoglalás
Ebben a fejezetben átvettük a CI/CD folyamat és termelési környezet alapjait. Elvégeztünk
néhány gyakorlati megvalósítást, hogy beállítsuk a termelési infrastruktúrát, majd
folyamatokat állítottunk be a folyamat termelési környezetében a termelési telepítésekhez.
Teszteltük a termeléskész folyamatot, hogy teszteljük annak robosztusságát. Ahhoz, hogy
eljussunk a következő szintre, teljesen automatizáltuk a CI/CD folyamatot különféle
kapcsolók használatával. Végül megnéztük a kiadáskezelési gyakorlatokat és lehetőségeket,
valamint megvitattuk az ML rendszer folyamatos monitorozásának szükségességét.
az egyik fő gondolat, hogy a folyamat a termék, nem a modell. Jobb egy robosztus és
hatékony folyamat kialakítására koncentrálni a legjobb modell kialakítása helyett.
A következő fejezetben megismerjük az MLOps munkafolyamat monitorozási modulját
és többet tudunk meg a változtató magyarázható monitorozási keretrendszerről.
3. rész: Gépi
tanulási modellek
monitorozása
a termelésben
Ebben a részben megismertetjük az olvasókat a termelésben lévő gépi tanulási

rendszerek monitorozási elveivel és folyamataival. Ez lehetővé teszi számukra, hogy
CI/CD folyamatokat hozzanak létre a telepítések monitorozására, és felkészíti őket,
hogy beállítsák és kezeljék a gépi tanulási modellek folytonos kézbesítését és folytonos
monitorozását.
• 11. fejezet: Az Ön ML rendszerének monitorozási alapelvei

• 12. fejezet: Modellek kiszolgálása és monitorozása
• 13. fejezet: Az ML rendszerek irányítása a folytonos tanuláshoz
11
Az Ön ML
rendszerének
monitorozási
alapelvei
Ebben a fejezetben azokról az alapvető elvekről fogunk tanulni, amelyek elengedhetetlenek
a termelésben lévő gépi tanulásos (ML) modelljeinek monitorozásához. Tanulni fog
arról, hogy készítsen megbízható és magyarázható MI megoldásokat az Explainable
Monitoring Framework (magyarázható monitorozási keretrendszer) használatával.
Az Explainable Monitoring Framework használható a funkcionális monitorozási
folyamatok kialakításához, így monitorozhatja az ML modelljeit a termelésben,
elemezheti az alkalmazás és modell teljesítményét és irányíthatja az ML rendszereket.
Az ML rendszerek monitorozásának célja, hogy lehetővé tegye a bizalmat, átláthatóságot
és magyarázhatóságot az üzleti hatás növelése érdekében. Úgy fogunk erről tanulni,
hogy megnézünk néhány valós példát.
Az ebben a fejezetben említett alapelvek megértése ellátja Önt a tudással, hogy end-to-
end monitorozási rendszereket alakítson ki a felhasználási esetéhez vagy cégéhez. Ez segít
Önnek bevonni az üzleti, technológiai és nyilvános (ügyfelek és jogi) érintetteket,
így hatékonyan érheti el az üzleti céljait. Ez segíteni fog Önnek az ML rendszerének
irányításához a perem és a szisztematikus megközelítés elérésében. Az ebben a fejezetben
lévő keretrendszerek használatával elérheti a bizalmat, átláthatóságot
és magyarázhatóságot az ML rendszer és az érdekeltek esetében.
256 Az Ön ML rendszerének monitorozási alapelvei
A következő fő témákat érintjük ebben a fejezetben:
• Egy ML rendszer monitorozásának fő alapelvei

• Monitorozás az MLOps munkafolyamatban
• Az Explainable Monitoring Framework értelmezése
• Folytonos monitorozás lehetővé tétele a szolgáltatásnál
Vágjunk bele!
Egy ML rendszer monitorozásának fő alapelvei

A bizalom kialakítása az MI rendszerek irányába létfontosságú a napjainkban a növekvő
igényekkel az adatvezérelt termékek iránt, és hogy idomuljunk a változó környezethez és
a szabályozó keretrendszerekhez. Az egyik oka annak, hogy az ML projektek nem hoznak
üzleti értéket, az a bizalom és átláthatóság hiánya a döntéshozásukban. Sok fekete dobozos
modell magas pontosságot ér el, de elavulttá válnak, amikor meg kell magyarázni az
okokat az általuk hozott döntések mögött. Az írás időpontjában olyan hírek bukkantak
fel, amelyek növelik a bizalom és magyarázhatóság miatti aggodalmat, ahogy a következő
ábrán látható:
11.1 ábra: A modellbizalom és -magyarázhatóság összetevői

A kép a való élet fontos területeinek aggodalmait mutatja be. Nézzük meg, ez hogyan
jelenik meg a modell magyarázhatóságának néhány fő aspektusában, mint amilyen
a modell eltérése, elfogultsága, átláthatósága és megfelelősége, néhány valós példán
keresztül.
Egy ML rendszer monitorozásának fő alapelvei 257
Modelleltérés
Egy dinamikusan változó világban élünk. Emiatt a környezet és az adat, amelyben egy ML
modellt telepítettek egy feladat elvégzésére vagy előrejelzések készítésére, az folyamatosan
fejlődik, és elengedhetetlen figyelembe venni ezt a változást. Például a COVID-19 járvány
egy nemvárt valóságot mutatott meg nekünk. Sok üzleti művelet virtuálissá vált, és ez
a járvány egy egyedi szituációval szembesített minket, amelyet sokan az új normaként
érzékelnek. Sok kis üzlet ment csődbe, és a magánszemélyek rendkívüli pénzügyi hiánnyal
néznek szembe a munkanélküliség emelkedése miatt. Ezek az emberek (kis üzletek és
magánszemélyek) hiteleket és pénzügyi segítséget kérnek a bankoktól és intézetektől, mint
még soha (nagy léptékben). A csalásérzékelő algoritmusok, amelyet a bankok és intézetek
már telepítettek és használtak, nem látták ezt az adatsebességét és -pontosságot a hitel és
pénzügyi segítség igényléseinek tekintetében.
Ezek a változások a jellemzőknél (ilyen például a kérelmező bevétele, hiteltörténete,
a kérelmező lakhelye, az igényelt mennyiség stb.) eltéríthették a modell súlyozását/
ítélőképességét (vagy összezavarták a modellt), mivel egy egyébként hitelképes kérelmező,
aki még nem igényelt hitelt korábban, elveszítette a munkáját. Ez fontos kihívást jelentett
a modelleknek. Ahhoz, hogy megbirkózzon az ilyen dinamikusan változó környezetekkel,
kritikus fontosságú a modelleltérés, és hogy folyamatosan tanuljon belőle.
Az eltérés a környezetváltozásokhoz kapcsolódik, és az előrejelző ML modellek
teljesítményének romlására utal, illetve a romló változók közötti kapcsolatra. A
modellváltozások négy típusa következik, tekintettel a modellekre és adatokra:
• Adateltérés: Itt a független változók tulajdonságai változnak. Például ahogy az

előző példában, változnak az adatok a szezonalitás vagy új termékek vagy az ügyfél
igényeinek való megfelelős miatt hozzáadott változások miatt, ahogy a COVID-19
járvány esetében történt.
• Jellemzőeltérés: Itt a jellemző(k) tulajdonságai változnak idővel. Például változik
a hőmérséklet az évszakok változásával. Télen a hőmérséklet alacsonyabb a nyári
vagy őszi hőmérséklethez képest.
• Modelleltérés: Itt a függő változók tulajdonságai változnak. Például az előző
példában itt változott a csalásészlelés osztályozása.
• Upstream adatváltozások: Itt az adatfolyamat megy át működési adatváltozásokon,
mint amikor egy jellemzőt nem generálnak le többé, ami hiányzó értékeket
eredményez. Erre egy példa a fizetés értékének megváltozása az ügyfélnél (dollárról
euróra), ahol a dollár értéke többé nem lesz legenerálva.
Az egyértelműség érdekében fogunk még tanulni az eltérésről és eltérésfigyelőket

fejleszteni a következő fejezetben (12. fejezet: Modellek kiszolgálása és monitorozása).
Modellelfogultság
Akár tetszik, akár nem, az ML már sok döntésre hatással van az életében, például
a kiválasztásnál a következő munkájára, vagy a jelzáloga elfogadásánál a bankoktól.
Még az Evan rendfenntartó szervek is használják, hogy felkutassák a bűncselekmény
gyanúsítottjait, hogy megakadályozzák a bűncselekményeket. A ProPublica, egy újságíró
szervezet (ML-t használ a jövőbeni bűncselekmények előrejelzésére: https://www.
propublica.org/article/machine-bias-risk-assessments-in-
criminal-sentencing). 2016-ban a Propublica ML-je olyan eseteket mutatott, ahol
a modell elfogultan jelezte előre, hogy a fekete nők nagyobb kockázatot jelentenek, mint
a fehér férfiak, miközben az összes korábbi nyilvántartás az ellenkezőjét mutatta. Az ilyen
esetek költségesek lehetnek és káros szociális hatásaik vannak, ezért el kell kerülni őket.
Egy másik esetben az Amazon készített egy MI-t az emberek felvételéhez, de le kellett
állítania, mert diszkriminatív volt a nőkkel szemben (a Washington Post jelentése szerint).
Az ilyen elfogultságok költségesek lehetnek és nem etikusak. Ahhoz, hogy elkerüljük őket,
az MI rendszereket monitorozni kell, hogy megbízhassunk bennük.
A modellelfogultság egy olyan hibatípus, amely a modell tanításához használt
adatkészlet bizonyos jellemzői miatt következik be, amelyek jobban jelen vannak és/
vagy súlyozottabbak, mint a többi. Egy rosszul reprezentáló vagy elfogult adatkészlet
összekuszált kimeneteleket eredményezhet a modell felhasználási eseteinél, alacsony
pontosságot és analitikai hibákat. Más szóval az a hiba, amit az ML algoritmus
helytelen feltételezései eredményeznek. A magas elfogultság eredményezhet pontatlan
előrejelzéseket és okozhatja egy modellnél, hogy elmulassza a releváns kapcsolatokat
a jellemzők és az előrejelzett célváltozó között. Ennek egy példája az előbb említett MI,
amelyet az Amazon készített az emberek felvételére, de elfogult volt a nőkkel szemben.
Fogunk még tanulni a modellelfogultságról az Explainable Monitoring Framework részben,
ahol megismerjük az elfogultság és veszély észlelését.
Modellátláthatóság
Az MI nem determinisztikus természetű. Az ML-re különösen jellemző, hogy
folyamatosan fejlődik, frissül és újratanítják az életciklusa során. Az MI hatással van
szinte minden iparágra és szektorra. A növekvő adoptációjával és az ML használatával
hozott fontos döntésekkel lényegessé vált az ugyanolyan bizalmi szint kialakítása, mint
amilyen a determinisztikus rendszereké. Végül is a digitális rendszerek csak akkor
hasznosak, amikor meg lehet bízni a munkájukban. Egyértelműen szükség van a modell
átláthatóságára, sok CEO és üzleti vezető bátorít minket, értsük meg az MI üzleti döntéseit
és az üzleti hatásukat. Nemrég a TikTok vezérigazgatója tette a következő nyilatkozatot:
"Úgy véljük, minden vállalatnak közzé kéne tennie az algoritmusait, moderálási
szabályait és adatfolyamait a szabályozók előtt" (Forrás: TikTok).
A nyíltság és átláthatóság ilyen szintje a vállalatoknál kialakíthatná a társadalom bizalmát
az MI irányába, és lehetővé tenné a könnyebb adoptációt és megfelelőséget.
A modellátláthatóság az arra való törekvés, hogy kialakuljon az MI rendszerek iránti

bizalom, hogy biztosítva legyen a korrektség, csökkenjen vagy megszűnjön az elfogultság,
meglegyen az elszámolhatóság (a rendszer működési end-to-end folyamatának auditálása)
és igazolva legyenek a modell kimenetei és a rendszer döntései.
Modellmegfelelőség
A modellmegfelelőség fontossá vált, mivel hatalmas költségekkel járhat a nem
megfelelőség a kormányok és társadalom irányába. A következő címsor a Washington
Post-ban szerepelt:
"A JPMorgan-t szövetségi diszkriminációs per terheli 55 millió $-ért"

A megfelelőség hiánya költséges ügy lett a JP Morgan számára. Egyre fontosabbá válik
a felügyeleti megfelelőség, hogy elkerüljék a szükségtelen bírságokat és a társadalomnak
okozott kárt. Itt van néhány mozgatórugó, amely lehetővé teszi a modellmegfelelőséget
a cégeken belül:
• Az elszámolhatóság kultúrája: Az ML rendszerek end-to-end auditálása

elengedhetetlen a megfelelőség monitorozásához. Az MLOps lényeges szerepet
játszhat az auditálás irányításában és a műveletek és az MI használatával hozott
üzleti döntések szerkesztésében.
• Az etika az első: Felelős MI rendszerek kialakításához, amelyek értéket teremtenek
a társadalomban és elnyerik a bizalmunkat olyan MI előrejelzések kellenek, amelyek
mindent magukba foglalnak, tisztességesek és etikusak. Egy etikai keretrendszer
segíthet egy vállalatnak, hogy az ügyfeleik kapcsolódjanak az értékeikhez és
alapelveikhez, valamint biztosítják az etikus MI döntéseket. Az Európai Bizottság
itt jó munkát végzett az Ethics and guidelines for trustworthy AI (etika és
iránymutatások a megbízható MI-hez) elkészítésével. Ezeket az iránymutatásokat itt
találhatja meg: https://ec.europa.eu/digital-single-market/en/
news/ethics-guidelines-trustworthy-ai.
• Megfelelőségi folyamat: Egy olyan megfelelőségi folyamat használata, amely
kielégíti mind az üzleti, mind az állami szabályozásokat, jövedelmező lehet az olyan
szervezeteknek, amelyek biztosítani akarják a valós idejű megfelelőséget, auditálást
és szerkesztést. Az MLOps képes ezt irányítani az összes ML modell készletének
nyomon követésével, így rálátást ad, hogy működnek, és vizuálisan magyarázza el
a működésüket az érdekelteknek. Az ilyen működés lehetővé teszi az embereknek,
hogy monitorozzák, szerkesszék és magyarázzák a szabályozások korrelációit, így
ez hatékony lesz az üzleti érdekeltek, adatkutatók és szabályozók számára, hogy kéz
a kézben dolgozzanak az átlátható és magyarázható műveletek érdekében.
Magyarázható MI
Ideális esetben egy üzlet előtérben tartja a modell átláthatóságát és megfelelőségét, így az
üzlet dinamikusan adaptálódik a környezetváltozáshoz, mint amilyen a modelleltérés,
és menet közben kezeli az elfogultságot. Mindehhez szükség van egy keretrendszerre,
amely kapcsolatban tartja az üzlet összes érintettjét (IT és üzleti vezetők, szabályozók,
üzleti felhasználók stb.) az MI modellel, hogy megértsék a modell által hozott döntéseket,
miközben a modell átláthatóságának és megfelelőségének növelésére koncentrálnak.
Egy ilyen keretrendszer készíthető a Magyarázható MI használatával az MLOps részeként.
A Magyarázható MI lehetővé teszi, hogy az emberek könnyen megértsék az ML-t.
A modell magyarázhatósága és átláthatósága két megközelítés, amelyek lehetővé teszik
a Magyarázható MI-t. Az ML modellek mintákat vagy szabályokat alkotnak az adatok
alapján, amellyel betanították őket. A Magyarázható MI segít az embereknek vagy üzleti
érintetteknek, hogy megértsék ezeket a szabályokat vagy mintákat, amelyeket a modell
felfedezett, és segít validálni az üzleti döntéseket is, amelyeket az ML modell hozott. Ideális
esetben a Magyarázható MI-nek képesnek kell lennie több üzleti érintett kiszolgálására,
ahogy az a következő ábrán látható:
11.2 ábra: Üzletvezérelt Magyarázható MI

A fekete dobozos modellek magas pontosságot képesek elérni az előrejelzéseknél, de elavulttá
válnak, ha nem képesek megmagyarázni, miért hozták ezeket a döntéseket. A legtöbb fekete
dobozos modellnél nem lehet belelátni a modell működésébe, nincs monitorozás a potenciális
elfogultság vagy eltérés felderítésére és modell viselkedése nem magyarázható. Ennek
a problémának a kezeléséhez hatalmas mennyiségű kutatás és fejlesztés folyik a Magyarázható
MI módszerek területén, hogy növeljék a modellátláthatóságot és modellmagyarázhatóságot.
A Magyarázható MI módszerek az MLOps-ba építve lehetővé tehetik szinte az összes

üzleti érintetteknek, hogy megértsék és validálják ezeket az üzleti döntéseket, amelyeket
az ML modell hozott, és segítenek megmagyarázni is a belső és külső érintetteknek.
Nincs egyetlen megoldás a Magyarázható MI-re, mivel minden felhasználási eset saját
Magyarázható MI módszert igényel. Különféle módszerek vannak, amelyek egyre
népszerűbbek. Megnézünk néhány példát a következő alfejezetekben.
Jellemző tulajdonság módszerek

A jellemző tulajdonság módszerek megmutatják, hogy az egyes jellemzők a modellben
hogyan járulnak hozzá az egyes példányok előrejelzéseihez. Amikor Ön magyarázatot kér,
akkor megkapja az előrejelzéseket a jellemző tulajdonság információival. Itt van néhány
jellemző tulajdonság módszer:
• SHapley Additive exPlanations (SHAP): Egy módszer, amely megmagyarázza

bármely ML modell kimeneteit. A játékelmélet megközelítésen alapszik, amely
megmagyarázza bármely ML modell kimenetét. Főleg az egyes jellemzők
hozzájárulását magyarázza a modell kimenetéhez.
• Integrált gradiensek: Egy olyan technika, amelynek a célja, hogy megmagyarázza
a kapcsolatot egy modell előrejelzései között, annak jellemzőinek tekintetében.
Az Axiomatic Attribution for Deep Networks dokumentumban mutatták be. Képes
megmagyarázni a jellemző fontosságát a torzított adatok azonosításával és segít a
modell teljesítményének hibajavításában.
• Helyi értelmezhető modellagnosztikus magyarázat (LIME): Ez egy olyan
modellagnosztikus módszer, amely az előrejelzések magyarázatára szolgál. A helyi
magyarázatokra fókuszál; így a magyarázatok reflektálnak a modell viselkedésére
az előrejelzett adatpéldány tekintetében. Például a LIME képes utalni rá, hogy mely
tényezők vagy jellemzők voltak fontosak egy modellnél, hogy megjósoljon egy
kimenetelt. Ez látható a következő ábrán:
11.3 ábra: Egyes előrejelzések magyarázata LIME használatával

Az előző ábrán egy modell azt jósolta, hogy egy beteg diabéteszes. A LIME magyarázó
kiemeli és következtet a diabétesz tüneteire, mint a száraz bőr, túlzott vizelet és homályos
látás, amellyel hozzájárul a diabétesz előrejelzéséhez, miközben a Nincs fáradtság egy
bizonyíték ellene. A magyarázó használatával egy orvos képes dönteni és levonni
a következtetéseket a modell előrejelzéséből és ellátni a beteget a megfelelő kezeléssel.
Itt többet tudhat meg az MI magyarázatokról: https://cloud.google.com/
ai-platform/prediction/docs/ai-explanations/overview.
Nem jellemző tulajdonság módszerek

A nem jellemző tulajdonság módszerek nem az egyes jellemzők hozzájárulására
fókuszálnak a modell előrejelzéseiben. Helyette a modell következtetésénél a bemeneti
és kimeneti adatok közötti kapcsolatra koncentrálnak. Itt van néhány nem jellemző
tulajdonság módszer:
• Deeplift: Ez használatos a neurális hálók értékelésére, összehasonlítja az egyes
neuronok aktiválását azok referencia aktiválásával és hozzájárulás pontszámot
rendel hozzájuk a különbségnek megfelelően. A Deeplift megmutatja a korrelációkat
és hozzájárulásokat. Például mondjuk, hogy egy macskás és kutyás a képeket
osztályozó modellt használunk, hogy osztályozzuk a képeket a macskák és kutyák
között. Tegyük fel, hogy az osztályozó azt jelzi előre, hogy a bemeneti kép egy
kutya a deeplift módszer használatával. Itt visszaadhatjuk az aktivált neuronokat
a képosztályozó neurális hálójában a referencia aktiválásaikhoz, majd megadhatjuk
a hozzájárulási pontszámot az egyes jellemzőknek az eltérés alapján.
• Természetes nyelvi magyarázatok (NLE): Az NLE célja, hogy észrevegye
a bemeneti-kimeneti kapcsolatokat a szöveges magyarázatoknál több technika
keverékének használatával, mint amilyenek a részleges függőségi függvény,
gradienselemzés, kontextuális kódolás, Individual Conditional Expectation
(Egyedi feltételes elvárások), Accumulated Local Effects (Felhalmozódott helyi
hatások) stb. Ezek a technikák hasznosak a nyelvi modellek értelmezésénél, amelyek
szöveget generálnak vagy osztályoznak. Az NLE könnyen érthető és hasznos érveket
szolgáltat a felhasználóknak, hogy eldöntsék, megbíznak-e a modell döntésében
és cselekednek-e. Például szeretne venni egy terméket egy modell ajánlása és
magyarázata alapján. Az olyan eszközök, mint a Microsoft Power BI és Qlik Sense
azonnal használhatók az NLE vizsgálathoz. Ezeket az eszközöket személyre kell
szabni az Ön igényei vagy felhasználás esete alapján.
Vannak az előző listában említett módszereken kívül mások is. Ez a terület forró kutatási
téma az MI-nél. Sok kutató és üzleti vezető próbálja megoldani a Magyarázható MI
problémákat, hogy megmagyarázzák a modell döntéseit a külső és belső érintetteknek.
Ha van egy Magyarázható MI-alapú interfésze több üzleti érdekelt számára, az segíthet
nekik, hogy megválaszolják a kritikus üzleti kérdéseket. Például egy üzleti vezetőnek meg
kell magyaráznia: "Ezek a modelldöntések hogyan hatnak az üzletre?", miközben az IT
és Operations számára elengedhetetlen tudni a választ arra, hogy "Hogyan monitorozzak
és javítsam a hibákat?"
Monitorozás az MLOps munkafolyamatban 263
Ezen kérdések megválaszolása több üzleti érdekeltnél lehetővé teszi, hogy a munkavállalók
és üzletek adaptálódjanak az MI-hez, és maximalizálják a belőle nyert értéket azzal, hogy
biztosítják a modell átláthatóságát és megfelelőségét, miközben adaptálódnak a környezeti
változásokhoz a modell elfogultságának és eltérésének optimalizálásával.
Magyarázható MI = modell magyarázhatósága és átláthatósága

Mióta az ML modellek első osztályú állampolgárrá váltak, egy modell teljesítményének
monitorozásához, tekintettel ezen területekre, használhatjuk a Magyarázható
monitorozást, amely lehetővé teszi, hogy elemezzük és irányítsuk az ML rendszereket
a termelésben a döntéseik magyarázata és monitorozása által az Magyarázható MI
módszerek használatával. A magyarázható monitorozás egy Magyarázható MI hibrid;
Magyarázható MI módszereket használ műveletekkel (Ops) együtt a termelésben.
A magyarázható monitorozás az MLOps munkafolyamat szerves részévé vált. A következő
részben megnézzük, a Magyarázható Monitorozás hogyan teremt értéket az MLOps
munkafolyamatban.
Monitorozás az MLOps munkafolyamatban

Az MLOps munkafolyamatról már tanultunk az 1. fejezet: MLOps WorkFlow
alapjai részben. Ahogy a következő ábrán látható, a monitorozási blokk az MLOps
munkafolyamat szerves részét képezi a termelésben lévő ML modell teljesítményének
értékelése és az ML rendszer üzleti értékének mérése érdekében. Csak akkor vagyunk
képesek mindkettőt elvégezni (mérni a teljesítményt és az üzleti értéket, amelyet az ML
modell generált), ha megértjük a modell döntéseit az átláthatóság és magyarázhatóság
tekintetében (hogy megmagyarázzuk a döntéseket az érdekelteknek és ügyfeleknek).
A Magyarázható Monitorozás lehetővé teszi mind az átláthatóságot, mind
a magyarázhatóságot az ML rendszerek irányításához, hogy a legjobb üzleti értéket
állítsuk elő:
11.4 ábra: MLOps, monitorozási munkafolyamat

A gyakorlatban a Magyarázható Monitorozás lehetővé teszi az ML rendszer

monitorozását, elemzését és irányítását, és egy folytonos hurokként működik más
összetevőkkel együtt az MLOps munkafolyamatban. Azt is lehetővé teszi, hogy az emberek
részt vegyenek a hurokban, hogy megértsék a modell döntéseit és tanítsák a modellt
(az adatok címkézésével és a modell újratanításával) menet közben. A Magyarázható
Monitorozás lehetővé teszi a folytonos tanulást, és hosszú távon nagyon jövedelmező egy
vállalatnak. Egy folytonos tanulási folyamat egy emberrel a hurokban a Magyarázható
Monitorozás használatával válik elérhetővé, amely a következő ábrán látható:
11.5 ábra: A folytonos tanulás engedélyezését a Magyarázható Monitorozás segítségével

A folytonos tanulás a rendszer azon képessége, hogy folyamatosan tanuljon egy változó
környezetben, miközben arra épít, amit korábban tanult. A folytonos tanulás kezeléséhez
az adatoknak és modellezésnek kéz a kézben kell járnia, és támogatniuk kell a hurokban
lévő embereknek (jellemzően egy QA elemző vagy rendszergazda, például egy adatkutató
vagy ML mérnök). A Magyarázható Monitorozás elengedhetetlen szerepet játszik
a folytonos tanulási rendszerekben, hogy növelje a bevételt, megfelelő maradjon és
felelősen alakítsák ki az ML rendszereket. Elvégre csak egy olyan modell képes üzleti
értéket szállítani, amelyet folytonos tanulási lehetőségekkel telepítettek.
Az Explainable Monitoring Framework

értelmezése
Ebben a részben megismerjük a Magyarázható Monitorozási Keretrendszert (amely
a következő ábrán látható), hogy megértsük és megtanuljuk, a Magyarázható Monitorozás
hogyan javítja az MLOps munkafolyamatot és magát az ML rendszert:
Az Explainable Monitoring Framework értelmezése 265
11.6 ábra: Explainable Monitoring Framework

A Magyarázható Monitorozási Keretrendszer egy moduláris keretrendszer, amely egy
ML rendszer monitorozására, elemzésére és irányítására használatos, miközben lehetővé
teszi a folytonos tanulást. Az összes modul szinkronban dolgozik, hogy lehetővé tegyék
az átláthatóságot és a Magyarázható Monitorozást. Nézzük meg, hogyan működnek az
egyes modulok, hogy megértsük, hogyan járulnak hozzá a keretrendszerhez és hogyan
működnek benne. Először nézzük meg a monitorozási modult (az első panel az előző
ábrán).
Megfigyelés
A monitor modul feladata, hogy monitorozza az alkalmazást a termelésben (kiszolgálja
az ML modellt). Számos tényező szerepel egy ML rendszerben, mint például az alkalmazás
teljesítménye (telemetriai adatok, munkateljesítmény, szerver válaszidő, sikertelen kérések,
hibakezelés stb.), az adatvédelem, modelleltérés és a környezetek változása. A monitor
modulnak fontos információkat kell szereznie a termelésben lévő rendszernaplókból,
hogy kövesse az ML rendszer robosztusságát. Nézzük meg a monitor modul három
tevékenységének jelentőségét és funkcionalitását: az adatvédelemét, modelleltérését
és az alkalmazás teljesítményét.
Adatvédelem
Egy ML alkalmazás adatvédelmének biztosítása magába foglalja a bejövő (az ML
modell bemeneti adatai) és kimenő (ML modell előrejelzése) adatainak ellenőrzését,
hogy biztosítsa az ML rendszerek integritását és robosztusságát. A monitor modul
biztosítja az adatvédelmet az adat mennyiségének, változatosságának, pontosságának
és gyorsaságának vizsgálatával, hogy észlelje a kívülállókat és anomáliákat. A kívülállók
vagy anomáliák észlelése megakadályozza az ML rendszerek rossz teljesítményét és az
érzékenységüket a támadások ellen (például rosszindulatú támadások). A hatékony
auditálással párosított adatvédelem képes kezelni az ML rendszerek kívánt teljesítményét,
hogy üzleti érték jöjjön létre.
Modelleltérés
Ha nem mérik a modelleltérést, a modell teljesítménye könnyen átlag alattivá válhat
és akadályozhatja az üzletet a rossz döntésekkel és ügyfélszolgálattal. Például nehéz
előre látni a változásokat vagy trendeket az adatokban egy olyan ritka esemény során,
mint a COVID-19. Itt van néhány hír, ami a címlapra került:
• Az Instacart modell pontossága egy tétel elérhetőségének előrejelzésében

93%-ról 61%-ra zuhant a vásárlási szokások megrendítő változása miatt
(https://fortune.com/2020/06/09/instacart-coronavirus-
artificial-intelligence/).
• A bankárok kételkednek benne, hogy jó időkben betanított hitelmodellek pontosan
fognak-e válaszolni a stresszhelyzetekben (https://www.americanbanker.
com/opinion/ai-models-could-struggle-to-handle-the-market-
downturn).
• A piac bizonytalansága miatt besültek a kereskedelmi algoritmusok. Néhány
finanszírozás 21%-kal csökkent (https://www.wired.com/story/best-
ai-models-no-match-coronavirus).
• A képosztályozó modellek küzdenek azért, hogy adaptálódjanak az "új normához"
a COVID-19 járvány nyomán: otthon egy család a laptopok előtt most "munkát"
jelent, nem "szórakozást". (https://techcrunch.com/2020/08/02/
ai-is-struggling-to-adjust-to-2020/)
Ezért fontos monitorozni a modelleltérések minden formáját, mint például az adateltérést,

elveltérést vagy bármely upstream adatváltozást, hogy adaptálódjunk a változó környezetekhez,
a legrelevánsabb módon szolgáljuk ki az üzleteket és ügyfeleket és a maximális üzleti értéket
állítsuk elő.
Alkalmazás teljesítménye
Kritikus monitorozni az alkalmazás teljesítményét, lássuk előre és megakadályozzuk
a potenciális hibákat, mivel ez biztosítja az ML rendszerek robosztusságát.
Itt monitorozhatjuk a termelési telepítési cél (például Kubernetes vagy egy helyi szerver)
telemetria adatait és kritikusrendszernaplóit. Az alkalmazásteljesítmény monitorozása
fontos meglátásokat adhat valós időben, mint amilyen a szerver munkateljesítménye,
késése, szerver válaszideje, hibás kérések száma vagy irányítási folyamat hibái stb.
Nincs kikövezett útja az alkalmazások monitorozásának és az üzleti felhasználási esetétől
függően az alkalmazásának teljesítménymechanizmusa felügyelhető és monitorozható,
hogy a rendszer működjön és üzleti értéket termeljen.
A monitorozási összetevő tekintetében monitoroztuk az adatvédelmet, modelleltérést

és az alkalmazás teljesítményét. A következő részben azt fogjuk elemezni, hogyan kell
monitorozni a modell és az alkalmazás adatait.
Elemzés
Az Ön ML rendszerének elemzése a termelésben, valós időben, kulcsfontosságú az
ML rendszer teljesítményének megértéséhez és robosztusságának biztosításához.
Az emberek fontos szerepet játszanak a modellteljesítmény elemzésében és az apró
anomáliák és veszélyek észlelésében. Így egy ember a hurokban hatalmas átláthatóságot
és magyarázhatóságot vihet az ML rendszerbe. Elemezhetjük a modell teljesítményét,
hogy észrevegyük az elfogultságokat vagy veszélyeket, és megértsük, miért bizonyos minta
szerint hozza a modell a döntéseket. Ezt olyan haladó technikák alkalmazásával vihetjük
végbe, mint az adatok darabolása, a rosszindulatú támadásokat megelőző technikák, vagy
a helyi és globális magyarázatok megismerése. Nézzük meg mindezt a gyakorlatban.
Adatok darabolása
Számos sikertörténet van az ML körül, az üzlet és élet általános javítása tekintetében.
Azonban még van lehetőség fejleszteni az adateszközöket a hibajavításhoz és a modellek
értelmezéséhez. A fejlesztés egyik fontos területe a modellek rossz teljesítményének
megértése az adatok bizonyos részein vagy szeletein, és hogy hogyan egyensúlyozhatjuk ki
az átfogó teljesítményt. A szelet egy adatkészlet része vagy alkészlete. Az adatok darabolása
segíthet nekünk megérteni a modell teljesítményét az adatalkészletek különböző típusain.
Feloszthatjuk az adatkészletet több szeletre vagy alkészletre, és vizsgálhatjuk a modell
viselkedését náluk.
Például nézzünk meg egy elméleti esetet, ahol betanítottunk egy random forest modellt,
hogy osztályozza, egy személy jövedelme 50000 $ alatt vagy felett van-e. A modellt az
UCI népszámlálási adatokon tanítottuk be (https://archive.ics.uci.edu/ml/
datasets/Census-Income+%28KDD%29). A modell eredményei az adatszeleteken
(vagy alkészleteken) a következő táblázatban láthatók. A táblázat szerint az átfogó mutatók
elfogadhatók, mivel a teljes naplóveszteség alacsony az összes adatnál (lásd. az All sort).
Ez egy széleskörűen használt mérés a bináris osztályozási problémáknál, és azt mutatja,
mennyire van közel az előrejelzés valószínűsége a tényleges/valós értékekhez; bináris
osztályozás esetében 0 vagy 1. Minél jobban eltér az előrejelzett valószínűség a tényleges
értéktől, annál nagyobb a naplóveszteség értéke. Azonban az egyes szeletek mást
mondanak:
11.1 táblázat: UCI népszámlálási adatok szeletei

Ha megnézzük az előző táblázatot, azt a következtetést vonhatjuk le, hogy a modell
teljesítménye megfelelő. Azonban, ha megnézzük a férfi és női alanyok teljesítményét,
akkor azt láthatjuk, hogy modell csak a női alanyoknál teljesít jól, ahol kevesebb
a naplóvesztés, mint a férfi alanyoknál. Másrészt, ha megnézi a Prof – specialty
kihasználtságot, azt fogja látni, hogy a nettó teljesítmény egyenértékű a férfi alanyok
teljesítményével, ami 0,45 és 0,41 naplóveszteséget jelent ebben a sorrendben, miközben
a hatás mérete a Prof – specialty esetében lényegesen kisebb. A modell rosszul teljesít az
Alapképzés, Mesterképzés és Doktori képzés esetében, mivel a naplóveszteségek értéke
magas: 0,44, 0,49 és 0,59. Azt is érdemes megjegyezni, ha egy szelet naplóvesztesége és
az ellenpárjáé az elfogadható alatt van, akkor az azt jelzi, hogy modell teljesen rossz,
nem csak egy adott adatszeletnél.
Az adatok darabolása lehetővé teszi, hogy lássuk a kisebb elfogultságokat és nem látható
korrelációkat, hogy megértsük, miért teljesít rosszul a modell az adat egy alkészletén.
Elkerülhetjük ezeket az elfogultságokat és javíthatjuk a modell teljes teljesítményét, ha
a modellt kiegyensúlyozott adatkészletek használatával tanítjuk, amelyek reprezentálják az
összes adatszeletet (például szintetikus vagy alulmintázott stb. adatok használatával), vagy
ha hangoljuk a modellek hiperparamétereit, hogy csökkentsük az átfogó elfogultságot.
Az adatok darabolása egy átfogó képet adhat a modell korrektségéről és teljesítményéről
egy ML rendszernél, és abban is segíthet, hogy egy szervezet optimalizálja az adatokat
és ML modelleket az optimális teljesítmény és megfelelő korrektségi küszöbértékek
eléréséhez. Az adatok darabolása segíthet kialakítani a bizalmat az MI rendszer
irányába azzal, hogy átláthatóságot és magyarázhatóságot kínál az adat és a modell
teljesítményében.
Megjegyzés
Az adatok darabolásáról és az automatizált adatdarabolási módszerekről
alkotott átfogó kép érdekében vessen egy pillantást az Automated Data Slicing
for Model Validation: A Big data - AI Integration Approach dokumentumra,
ezen a címen: https://arxiv.org/pdf/1807.06068.pdf.
Elfogultság és fenyegetés észlelése

Az ML modellek használatával alkotott robosztus és etikus döntések biztosításához
gondoskodnunk kell róla, hogy a modellek korrektek és biztonságosak legyenek. Minden
elfogultságot és fenyegetést motorozni kell és meg kell szüntetni, hogy elkerüljük a nem
etikus vagy részre hajló döntéseket, amelyek egy bizonyos csoportnak kedveznek, így
megfelelünk az üzleti értékrendnek és a törvénynek.
Az elfogultságnak különböző típusai vannak, mint például a szelektáló elfogultság
(a modellek tanításához használt adatok nem reprezentálják a népességet, például
a kisebbségeket), keretező elfogultság (az adatgyűjtéshez használt kérdések vagy kérdőív
egy nézőpontból készült), szisztematikus elfogultság (ismétlődő vagy konzisztens hiba),
válasz elfogultság (az adatokban a megkérdezettek helytelenül válaszoltak a saját tudatos
elfogultságuk miatt) vagy megerősítő elfogultság (az adatokat úgy gyűjtötték, hogy
alátámasszák a saját feltevésüket). Ezen elfogultságok elkerüléséhez és megszüntetéséhez
a felhasználási esettől függően olyan technikák alkalmazhatók, mint az adatok darabolása,
szelet alapú tanulás vagy az elfogultságvariancia átváltásának kiegyensúlyozása.
Egy ML rendszer ki van téve olyan biztonsági fenyegetéseknek, amelyeket monitorozni
kell és meg kell szüntetni. Már megvitattunk néhány gyakori fenyegetést és megelőzési
technikát, beleértve a rosszindulatú támadásokat, mérgezéses támadásokat, adatvédelmi
támadásokat vagy hátsó ajtós támadásokat stb. a 9. fejezet: Az Ön ML megoldásának
tesztelése és biztosítása részben.
Helyi és globális magyarázatok

A helyi és globális magyarázatok különböző nézőpontokat kínálnak a modellek
teljesítményéről. A helyi magyarázatok igazolják a modell előrejelzését egy konkrét vagy
egyedi bemenetre, míg a globális magyarázatok meglátásokat adnak a modell előrejelzési
folyamatáról függetlenül az adott bemenettől. Például nézzünk meg egy elméleti esetet egy
visszatérő neurális hálós (RNN) modellről, amelyet az ügyfelek visszajelzéseinek érzelmi
elemzésére használtak. A következő ábra a globális magyarázatot (a folyamatot egészként)
mutatja az RNN modell érzelmi elemzéséhez az RNNVis eszköz használatával:
11.7 ábra: Az RNN modell globális magyarázata (RNNVis használatával) a folyamat egészként történő
értelmezéséhez (a rejtett állítások, rétegek stb. hogyan hat a modell kimeneteire és az előrejelzési
folyamatokra)
Forrás: https://blog.acolyer.org/2019/02/25/understanding-hidden-
memories-of-recurrent-neural-networks/
Itt például a közös klaszterezés vizualizációja különböző szófelhőket mutat pozitív és

negatív érzelmekkel. A globális magyarázatok használatával szimulálhatjuk a modell
előrejelzési folyamatát és megérthetjük a korrelációt a paraméterek vagy modell
architektúrája tekintetében (például rejtett állítások és rétegek). A globális magyarázatok
két perspektívát kínálnak a magyarázhatóságra: a magas szintű modellfolyamatot és az
előrejelző magyarázatokat. Másrészt a helyi magyarázatok egyetlen előrejelzésekhez adnak
meglátásokat. Mindkét magyarázat értékes, ha meg akarjuk érteni a modell teljesítményét
és átfogóan kívánjuk validálni.
Az elemző összetevőben elemezhetjük a modell teljesítményét azoknak a technikáknak
a használatával, amelyeket megismertünk, mint például az adatdarabolás, elfogultság
és fenyegetés észlelése, valamint a helyi és globális magyarázatok. A következő részben
megtanuljuk, hogyan irányítsuk az ML rendszereket hatékonyan, hogy elérjük a működési
vagy üzleti célokat.
Irányítás
Az ML rendszerek hatékonysága függ attól, hogyan irányítják, hogy elérjék a maximális
üzleti értéket. Egy rendszer irányításának nagy része magába foglalja a minőségbiztosítást
és irányítást, valamint a modell auditálását és a jelentést, hogy biztosítva legyen az
end-to-end követhetőség és a szabályoknak való megfelelőség. A modell teljesítményének
monitorozása és elemzése alapján irányíthatjuk az ML rendszereket. Az irányítást az okos
riasztások és műveletek végzik az üzleti érték maximalizálásához. Nézzük meg hogyan
irányítják az ML rendszert a riasztások és műveletek, a modell minőségbiztosítása és
irányítása és a modell auditálása és jelentése.
Riasztások és műveletek
Egy ML rendszer irányítása magába foglalja az ML alkalmazás monitorozását és
elemzését. Itt riaszthatók a rendszerfejlesztők, amikor a rendszer rendellenes viselkedést
mutat, mint amilyen a sikertelen kérés, a szerves lassú válaszideje, szerver kivételek,
hibák vagy nagy késés. A rendszerfejlesztők vagy rendszergazda riasztása gondoskodhat
a minőségbiztosításról és megelőzheti a rendszerhibákat. A riasztásoknak két különböző
típusa van: riasztások a rendszerteljesítményről és a modellteljesítményen alapuló
riasztások. Itt van néhány példa a rendszerteljesítmény riasztásaira:
• Szabály alapú riasztások a hibás kérésekhez egy küszöbérték alapján

• Szabály alapú riasztások a szerver válaszidejéhez egy küszöbérték alapján
• Szabály alapú riasztások a szerver elvárásaihoz egy küszöbérték alapján
• Szabály alapú riasztások az elérhetőséghez egy küszöbérték alapján
A modellteljesítmény riasztásai akkor jönnek létre, amikor a modell eltérést vagy

rendellenes jellemzőeloszlást vagy elfogultságot észlel. Amikor ilyen eseményt rögzítenek, a
rendszergazda vagy a fejlesztők riasztást kapnak e-mailben, SMS-ben, telefonos értesítésben
vagy hangos riasztással. Ezek a riasztási műveletek (automatizált vagy félig automatizált)
felhasználhatók a rendszerteljesítmény romlásának megszüntetésére. A szituációtól és
igényektől függően kiváltható néhány lehetséges művelet, mint a következők:
• Magas modelleltérés esetén egy alternatív modell telepítése

• Egy modell újratanítása
• Egy új modell tanítása
• Az ML rendszer újraindítása
• Az ML rendszer újratelepítése
A modell minőségbiztosítása és irányítása

Egy modell minőségbiztosítási és irányítási mechanizmusa elég jövedelmező lehet azoknak,
akik egy ML rendszert használnak, ha meg akarják előzni a számos lehetséges kellemetlenséget
és gondoskodni akarnak az ML rendszer rendszeres és jó monitorozásáról és működéséről.
Érdemes egy keretrendszert vagy mechanizmust használni a modell minőségbiztosításához
és irányításához. Ehhez egy ML rendszerekhez való minőségbiztosítási keretrendszer
lehetővé teheti a mechanizmust a szervezete számára, ahogy az a következő ábrán látható.
Ez egy moduláris keretrendszer, amelyet az ML rendszerek három fontos aspektusának
monitorozására használnak:
11.8 ábra: A modell minőségbiztosítási keretrendszere

A minőségbiztosítási szakértők segíthetnek a cégének vagy szervezetének egy tesztelő
mechanizmus beüzemelésében, hogy validálja, hogy a tanításhoz használt adatok
tiszták-e, biztosítsa, hogy a modell következtetéshez használt adatai nem tartalmaznak-e
fenyegetéseket az ML rendszerre nézve, és hogy monitorozza az adateltéréseket a változó
környezet megismeréséhez és validálásához. A monitorozási és tesztelési adatok
megszerezhetők a minőségbiztosítási vagy tesztelő mérnökök és termékmenedzserek által
a következők végrehajtásával:
• Ismerje meg és validálja az adat statisztikai kapcsolatait (például átlag, medián,

módusz stb.) a tanításhoz, teszteléshez és következtetéshez használt adatoknál.
• Fejlesszen teszteket az előbb említett statisztikák és kapcsolatok igazolására

(szkriptek használatával).
• Értékelje a jellemzők eloszlását olyan funkciótervezési technikák alkalmazásával,
mint funkcióválasztás, dimenziócsökkentés stb.
• Tanítsa újra és ellenőrizze az összes modell teljesítményét.
• Rendszeres időközönként monitorozza az összes modell teljesítményét új
adatkészletekkel.
• Indítson riasztást, ha egy másik modell (a modellkészletből) jobb pontosságot
produkál, mint a meglévő modell.
• Teszteljen rendszeres időközönként.
Modell auditálása és jelentések

A modell auditálása és jelentése elengedhetetlen, ha elegendő információt akar
a szabályozókhoz és a törvénynek való megfeleléshez. Az end-to-end követhetőség
a modellnél gondoskodik a kiváló átláthatóságról és magyarázhatóságról, amely átlátható
irányítási mechanizmusokat eredményezhet egy szervezet vagy vállalat számára. A modell
auditálásának és jelentésének célja, hogy értékelje a modell teljesítményét és ez alapján
lehetővé tegye az ML rendszer irányítását. A következő ábrán egy nagy, áttekintő képet
láthatunk a modell átláthatóságáról, amelyet az auditálás és jelentés alapján készítettek:
11.9 ábra: Modell átláthatósági diagram

A modell értékelései az auditáláson és jelentésen alapulnak, és ezek biztosítják a jó,

átlátható és robosztus irányítási mechanizmusokat a szervezetek számára, és lehetővé
teszik az end-to-end követhetőséget, a szabályozásoknak való megfelelés érdekében.
Az ilyen mechanizmusok segítenek a szervezeteknek hatalmas mennyiségű időt és
erőforrást megtakarítani, és lehetővé teszik a hatékonyságot a szabályozókkal folytatott
interakciók során.
Folytonos monitorozás lehetővé tétele

a szolgáltatásnál
Az Explainable Monitoring Framework találékony lehet, ha az ML rendszereket akarjuk
monitorozni a termelésben. A következő fejezetben aktiválni fogjuk az Explainable
Monitoring Framework-öt az üzleti felhasználási esetünknél, amelyen a korábbi
fejezetekben dolgoztunk. Aktiválni fogjuk a folyamatos monitorozást a rendszernél,
amelyet telepítettünk. Majd monitorozni fogjuk az ML alkalmazást, amelyet telepítettünk
a termelésben, és elemezni fogjuk a bejövő adatokat és a modell teljesítményét, hogy
irányítsuk az ML rendszert a maximális üzleti érték előállításához a felhasználási esetnél.
Összefoglalás
Ebben a fejezeteben megtanultuk egy ML rendszer monitorozásának alapelveit.
Megismertünk néhány gyakori monitorozási módszert és az Explainable Monitoring
Framework-öt (beleértve a monitorozás, elemzés és irányítás szakaszait). Aztán alaposan
megismertük a Magyarázható Monitorozás elveit.
A következő fejezetben elmélyedünk a Explainable Monitoring Framework gyakorlati
megvalósításában. Ennek használatával kialakítunk egy monitorozási folyamatot, hogy
folyamatosan monitorozhassuk a termelésben lévő ML rendszert az üzleti felhasználási
esetünknél (amely előre jelzi az időjárást Turku kikötőben).
A következő fejezet elég gyakorlatias lesz, szóval készüljenek fel!
12
Modellek
kiszolgálása és
monitorozása
Ebben a fejezetben a gépi tanulásos (ML) modellek termelésben való kiszolgálásának
és monitorozásának szükségességére reflektálunk, és megismerjük az ML modellek
kiszolgálásának különböző módjait a modell fogyasztóinak vagy felhasználóinak irányába.
Aztán újra meglátogatjuk az Explainable Monitoring framework-öt a 11. fejezet: Az Ön ML
rendszerének monitorozási alapelvei részből és megvalósítjuk azt az üzleti felhasználási esetnél,
amelyet megoldottunk az MLOps használatával az időjárás előrejelzésére. Az Explainable
Monitoring Framework megvalósítása gyakorlatias. Következtetni fogunk a telepített API-val,
monitorozzuk és elemezzük a következtetési adatokat az eltérések használatával (mint
amilyen az adateltérés, jellemzőeltérés és modelleltérés), hogy egy ML rendszer teljesítményét
mérjük. Végül megnézünk számos elvet az ML rendszerek irányítására az ML rendszerek
robosztus teljesítménye érdekében, a folytonos tanulás és szállítás működtetésére.
Kezdjük azzal, hogy reflektálunk az ML monitorozásának szükségességére a termelésben.
Aztán ebben a fejezetben a következő fő témákat érintjük:
• Modellek kiszolgálása, monitorozása és fenntartása a termelésben

• Az ML modellek kiszolgálásának különböző módjai
• A magyarázható monitorozási keretrendszer megvalósítása
• Az Ön ML rendszerének irányítása
276 Modellek kiszolgálása és monitorozása
Modellek kiszolgálása, monitorozása

és fenntartása a termelésben
Nincs értelme telepíteni egy modellt vagy egy ML rendszert és nem monitorozni azt.
A teljesítmény monitorozása az egyik legfontosabb aspektusa egy ML rendszernek.
A monitorozás teszi lehetővé számunkra, hogy elemezzük és leképezzük, egy ML rendszer
mekkora üzleti hatást kínál az érintetteknek kvalitatív és kvantitatív módon. Ahhoz,
hogy elérjük a maximális üzleti hatást, az ML rendszerek felhasználóit a legkényelmesebb
módon kell kiszolgálni. Ezután elfogyaszthatják az ML rendszert és értékel termelhetnek.
Az előző fejezetekben kifejlesztettünk és telepítettünk egy ML modellt, hogy előrejelezzük
az időjárási körülményeket egy kikötőben egy üzleti felhasználási eset részeként, amelyet
gyakorlati megvalósítással oldottunk meg. Ebben a fejezetben újra meglátogatjuk az
Explainable Monitoring Framework-öt, amelyet a 11. fejezet: Az Ön ML rendszerének
monitorozási alapelvei részben vitattunk meg, és megvalósítjuk azt az üzleti felhasználási
esetünkön belül. A 12.1 ábrán a Magyarázható Monitorozási keretrendszert és annak
néhány összetevőjét láthatjuk, zölddel kiemelve:
12.1 ábra: A magyarázható monitorozási keretrendszer megvalósítandó összetevői

Ezeknél a területeknél fogjuk megvalósítani a Magyarázható Monitorozást: Adatvédelem,
Modelleltérés, Alkalmazás teljesítménye, Elfogultság és fenyegetés észlelése, Helyi és globális
magyarázatok, Riasztások és műveletek, Modell QA és irányítás és Modell auditálása és
jelentések. Ezek az összetevők a legjelentősebbek a mi felhasználási esetünkben, hogy
megértsük a Magyarázható Monitorozás megvalósítását. Ki fogjuk hagyni az Adatok
darabolását, mivel nincs olyan nagy változatosság az adatainkon belül a demográfia vagy
minták tekintetében (például: nem, korcsoportok stb.). Más összetevők információinak
felhasználásával értékelhetjük a modell teljesítményét és korrektségét. Ebben a fejezetben
meg fogjuk valósítani a Monitor és Elemzés modulok összetevőit: az Adatvédelmet,
Modelleltérést, Alkalmazás teljesítményét, Elfogultság és fenyegetés észlelését és a Helyi és
globális magyarázatokat. A fennmaradó összetevők megvalósítását a 13. fejezet: Az ML
rendszerek irányítása a folytonos tanuláshoz részben fogjuk venni. Mielőtt rátérnénk
a megvalósítás folyamatára, vessünk rá egy pillantást, a modellek hogyan szolgálhatják ki
a felhasználók fogyasztását.
Az ML modellek kiszolgálásának különböző módjai 277
Az ML modellek kiszolgálásának különböző

módjai
Ebben a részben megnézzük, egy modell hogyan szolgálható ki úgy a felhasználóknak
(embereknek és gépeknek), hogy hatékonyan fogyasszák az ML szolgáltatást. A modell
kiszolgálása egy kritikus terület, ahol egy ML rendszernek sikerrel kell járnia, hogy
betöltse az üzleti hatását, mivel bármilyen késés vagy hiba ezen a területen költséges
lehet a felhasználók kiszolgálása tekintetében. A robosztusság, elérhetőség és kényelem
kulcsfontosságú tényezők, amelyeket észben kell tartani az ML modellek kiszolgálásánál.
Nézzük meg néhány módját annak, ahogyan az ML modellek kiszolgálhatók: ez végezhető
tömeges szolgáltatáson vagy kérésre történő szolgáltatáson keresztül (például amikor egy
kérést igény szerint nyújtanak be, hogy előrejelzést kapjanak). Egy modell kiszolgálható
egy gépnek vagy egy emberi felhasználónak is az igény szerinti módban. Itt egy példa egy
modell felhasználónak történő kiszolgálására:
12.2 ábra: Egy modell kiszolgálása a felhasználóknak

Egy tipikus szituációban (igény szerinti mód), egy modellt szolgáltatásként szolgáltak ki
fogyasztásra a felhasználóknak, ahogy a 12.2 ábrán látható. Aztán egy külső alkalmazás
egy gépen vagy egy ember egy kérést küld az előrejelzéshez vagy ML szolgáltatáshoz
az adatinak felhasználásával. Az ML szolgáltatás amikor megkapja a kérést, egy
terheléskiegyenlítőt használ, elirányítsa a kérést egy elérhető erőforráshoz (például egy
konténerhez vagy egy alkalmazáshoz) az ML alkalmazáson belül. A terheléskiegyenlítő
kezeli az erőforrásokat is az ML szolgáltatáson belül, hogy igény szerint új konténereket
vagy erőforrásokat kezeljen és generáljon. A terheléskiegyenlítő visszairányítja a kérést
a felhasználótól a modellhez, amely egy konténerben fut az ML alkalmazáson belül,
hogy készítse el az előrejelzést. Amikor megkapja az előrejelzést, a terheléskiegyenlítő
visszaáll a külső alkalmazásra a gépen vagy az emberre, aki a kérést indította, vagy a kérésre
a modell előrejelzésén belül. Így az ML szolgáltatás képes kiszolgálni a felhasználóit. Az ML
rendszer együttműködik a modelltárolóval vagy jegyzékkel, hogy frissítse magát a legújabb
vagy legjobban teljesítő modellekkel, hogy a legjobb módon szolgálja ki a felhasználókat.
Ezzel a szituációval szemben, ahol a felhasználók küldtek egy kérést, van egy másik
felhasználási eset is, ahol a modellt tömeges szolgáltatásként szolgálják ki.
A modell kiszolgálása tömeges szolgáltatásként

A tömeges feldolgozást vagy kiszolgálást nagy mennyiségű vagy kötegelt bemeneti
adatoknál alkalmazzák (azaz nem egyedülálló megfigyelések vannak, hanem összefogják
a megfigyeléseket). Olyan esetekben, ahol az adatok nagy tömegével kell következtetni,
a modellt általában tömeges módban szolgálják ki. erre egy példa, amikor a modellt az
összes fogyasztóra vagy egy termék vagy szolgáltatás felhasználóira vonatkozó adatok
egyszerre történő feldolgozására használják. Vagy egy gyárból érkező adatköteget kell egy
rögzített ütemterv szerint feldolgozni a gépekben lévő anomáliák észlelésére. Az igény
szerinti móddal szemben a tömeges mód erőforrás-hatékonyabb, és általában olyankor
alkalmazzák, amikor némi késés megengedhető:
12.3 ábra: Tömeges következtetés

Az ML modellek kiszolgálásának különböző módjai 279
A tömeges feldolgozás egyik fő előnye, hogy egy REST API-alapú szolgáltatással szemben egy
tömeges szolgáltatás könnyebb vagy kevesebb infrastruktúrát igényelhet. Egy tömeges feladat
megírása könnyebb egy adatkutatónak, mint egy online REST szolgáltatást telepíteni. Ez azért
van, mert az adatkutatónak csak egy modellt kell tanítania vagy deszerializálnia egy betanított
modellt egy gépen és végrehajtania a tömeges következtetést egy adatkötegen. A tömeges
következtetés eredményei tárolhatók egy adatbázisban, és nem kell válaszokat küldeni
a felhasználóknak vagy fogyasztóknak. Azonban az egyik fő hátránya a nagy késés, és hogy
nem valós idejű. Jellemzően egy tömeges szolgáltatás képes több száz vagy ezer jellemzőt
egyszerre feldolgozni. Használható egy tesztsorozat az optimális kötegméret meghatározására
az elfogadható késés eléréséhez a felhasználási esetnél. A jellemző kötegméret lehet 32, 64,
128 vagy 518, a 2 hatványa. A tömeges következtetés ütemezhető periodikusan és számos
felhasználási esetet szolgálhat ki, ahol a késés nem probléma. Mindjárt megvitatunk egy példát.
Egy valós példa

Egy valós példa egy bank, amely szöveges dokumentumok kötegeiből nyer
ki információkat. A bank több ezer dokumentumot kap egy nap a partner
intézetektől. Egy emberi ágens számára lehetetlen átolvasni az összeset és
kiemelni az intő jeleket a dokumentumokban felsorolt műveletekből. A tömeges
következtetést használják a név entitások és intő jelek kinyerésére az összes
dokumentumból egyszerre, amelyet a bank kapott. A tömeges következtetés
vagy kiszolgálás eredményei aztán egy adatbázisban kerülnek kiszolgálásra.
A modell kiszolgálása egy emberi felhasználónak

Mielőtt feldolgoznánk egy emberi felhasználóktól érkező kérést, elengedhetetlen
ellenőrizni, hogy a felhasználó rendelkezik-e a megfelelő engedélyekkel a modell
használatához. Továbbá a legtöbb esetben hasznos tudni a kérés küldésének kontextusát.
A kérés kontextusának összegyűjtése lehetővé teszi a modellnek, hogy jobb előrejelzéseket
készítsen. A kontextus összegyűjtése után átalakíthatjuk azt egy a modell által olvasható
bemenetté és a következtethetünk a modellel, hogy egy előrejelzést kapjunk.
A gyakorlatban itt van néhány fő lépés egy igény szerinti modell emberi felhasználóknak
történő kiszolgálására:
1. Validálja vagy hitelesítse a kérést.
2. Gyűjtse össze és elemezze a kontextus információit (például előzmény adatokat,
felhasználói tapasztalat adatait vagy bármilyen más személyes adatot a felhasználótól).
3. Alakítsa át a kontextus információit egy a modell által olvasható bemenetté vagy
vázlattá.
4. Következtessen a modell a bemeneti adatokkal (a kérés és a kontextus
információival), hogy egy előrejelzést készítsen vagy egy kimenetet kapjon.
5. Értelmezze a kimenetet a kontextus alapján.
6. Adja át a kimenetet a felhasználónak.
Egy valós példa

Gondoljunk egy chatbotra, amely emberi ügyfeleket szolgál ki, hogy
repülőjegyeket vegyenek. Kontextuális következtetést hajt végre, hogy
kiszolgálja az emberi felhasználókat.
A modell kiszolgálása egy gépnek

Egy gépet vagy egy külső alkalmazást kiszolgálhatunk egy REST API vagy egy
streaming szolgáltatással a felhasználási eset alapján. Jellemzően a gépi következtetés
adatkövetelményei előre meghatározottak vagy egy szabványos sémán belül vannak.
Egy jól meghatározott topológia vagy adatséma egy REST API vagy streaming szolgáltatás
formájában működni fog. Egy gép vagy ember igény szerint történő kiszolgálása
esetenként változik, mivel néhány szituációban változhat az igény (például a nap egy adott
időpontjában a felhasználó kiszolgálásának igénye magasabb lehet, például délután).
A magas igény szolgáltatásból történő kezeléséhez az automatikus méretezés (a felhőben)
segíthet a több erőforrás igény szerinti bevonásában, és lelőheti az üres erőforrásokat,
hogy több erőforrást szabadítson fel. Azonban az automatikus méretezés nem az egyetlen
megoldás a méretezésre, mivel nem képes magától kezelni a kérések hirtelen vagy különös
megugrását:
12.4 ábra: Egy üzenetbróker munkája a kérésre történő kiszolgáláshoz

A 12.4 ábrán látható megközelítés erőforrás-takarékosan kezeli a nagy mennyiségű
kérések megugrásait. A hirtelen ugrások kezeléséhez az olyan üzenetbrókerek, mint
az Apache Kafka vagy Spark, hasznosak lehetnek. Egy üzenetbróker folyamatokat
futtat egy sor írására és olvasására: egy folyamatot a sorban álló üzenetek írására és
egy másik folyamatot a sorból történő olvasásra. A kiszolgált modell periodikusan
csatlakozik az üzenetbrókerhez, hogy feldolgozza a bemeneti adat kötegeit a sorból,
hogy következtetéseket készítsen a köteg egyes elemeihez. A bemeneti adat kötegeinek
feldolgozása és az előrejelzések generálása után az előrejelzéseket beleírja a kimeneti sorba,
amelyet aztán elküldenek a felhasználóknak a kéréseik szerint.
A magyarázható monitorozási keretrendszer megvalósítása 281
Egy valós példa

Nézzünk meg egy közösségi médiatársaságot, amelynek több millió
felhasználója van. A vállalat egyetlen vagy közös ML modellt használ az
ajánló rendszerhez, hogy cikkeket vagy posztokat ajánljon a felhasználóknak.
Mivel a kérések mennyisége nagy, a sok felhasználó kiszolgálása érdekében
ez nem függhet egy REST API-alapú ML rendszertől (mivel az szinkron).
Egy streaming megoldás jobb, mivel aszinkron következtetést biztosít a cégnek,
hogy kiszolgálja a felhasználóit. Amikor egy felhasználó bejelentkezik az
alkalmazásban egy gépen futó fiókba (például egy közösségi médiatársaság
szervere), akkor a gépen futó alkalmazás következtet az ML modellel (azaz
az ajánló rendszerrel) egy streaming szolgáltatáson keresztül, hogy híreket
ajánljon a felhasználónak. Ehhez hasonlóan több ezer másik felhasználó
jelentkezik be ugyanekkor. A streaming szolgáltatás zökkenőmentesen
szolgálhatja ki az összes felhasználót. Vegye figyelembe, hogy ez nem lenne
lehetséges a REST API szolgáltatással. Azáltal, hogy egy streaming szolgáltatást
használ az ajánló rendszere modelljéhez, a közösségi médiatársaság képes valós
időben kiszolgálni a nagy mennyiségű felhasználót, elkerülve a jelentős késést.
A magyarázható monitorozási keretrendszer

megvalósítása
Az Explainable Monitoring Framework megvalósításához érdemes átismételni, miről
beszéltünk eddig, az elméleti felhasználási esetek megvalósításának tekintetében. Itt egy
összefoglaló arról, mit tettünk a felhasználási esetünk megvalósítása érdekében, beleértve
a problémát és a megoldást:
• A probléma kontextusa: Adatkutatóként dolgozik egy kis csapatban, három másik

adatkutatóval együtt egy teherszállítási cégnek, amelynek a székhelye a finnországi
Turku kikötőben van. A Finnországba importált termékek 90%-a teherhajókon
érkezik országszerte a különböző kikötőkbe. A teherhajózáshoz az időjárási
körülmények és a logisztika időnként kihívást jelenthet. Az esős idő hátráltathatja
a kikötői logisztikát és műveleteket, amely hatással lehet az ellátási lánc műveleteire.
Az esős idő előrejelzése lehetőséget ad, hogy optimalizálják az olyan erőforrásokat,
mint a humánerőforrás, logisztika és szállítási erőforrások a kikötői ellátási
lánc hatékony műveletei érdekében. Üzleti szempontból az esős idő előrejelzése
lehetőséget ad a kikötőknek, hogy nagyjából 20%-kal csökkentsék a működési
költségeiket a humánerőforrás, logisztika és szállítási erőforrások hatékony tervezése
és beosztása által a kikötői ellátási lánc műveleteinek esetében.
• Feladat vagy megoldás: Adatkutatóként azt a feladatot kapta, hogy fejlesszen egy
ML-alapú megoldást az időjárási körülmények 4 órás előrejelzésére a finnországi
Turku kikötőben. Ez lehetővé teszi a kikötőnek, hogy optimalizálja az erőforrásait,
amely akár 20%-os költségmegtakarítást tesz lehetővé. A kezdéshez megkapta az
elmúlt 10 év időjárásának adatkészletét Turku kikötőben (az adatkészlet a könyv
Git adatraktárában található). A feladata, hogy egy folytonos tanuláson alapuló
ML megoldást alakítson ki a Turku kikötőbeli műveletek optimalizálására.
Eddig kifejlesztettük az ML modelleket és telepítettük őket REST API végpontokként

egy Kubernetes klaszterben a http://20.82.202.164:80/api/v1/service/
weather-prod-service/score címen (az Ön végpontjának címe eltérő lehet).
Következőként le fogunk másolni egy valós következtetési szituációt ennél a végpontnál.
Ehhez a tesztadat-készletet fogjuk használni, amelyet felosztottunk és regisztráltunk a 4.
fejezet: Machine Learning folyamatok részben az Adatbevitel és funkciótechnika szakaszban.
Menjen az Azure ML munkaterületére és töltse le a test_data.csv adatkészletet
(amelyet test_dataset néven regisztráltunk) a Datasets részről vagy a Blob tárolóból,
amelyet a munkaterületéhez csatolt, ahogy az a 12.5 ábrán látható:
12.5 ábra: A validációs adatkészlet letöltése (amelyet korábba felosztottunk és regisztráltunk)

Készüljön fel a következtetésre a test_data.csv adatokon a REST API végponttal vagy

ML szolgáltatással. Menjen a 12_Model_Serving_Monitoring mappába és helyezze
el a letöltött adatkészletet (test_data.csv) a mappán belül. Következőként nyissa meg
az inference. py fájlt:
import json
import requests
import pandas as pd
data = pd.read_csv('test_data.csv')
data = data.drop(columns=['Timestamp', 'Location', 'Future_
weather_condition'])

url = 'http://20.82.202.164:80/api/v1/service/weather-prod-
service/score'
headers = {'Content-Type':'application/json'}

for I in range(len(data)):
inference_data = data.values[i].tolist()
inference_data = json.dumps(""dat"": [inference_
data]})
r = requests.post(url, data=inference_data,
headers=headers)
print(str(i)+str(r.content))
Az előző kódban a következő lépéseket hajtottuk végre:
1. Az inference.py fájlban kezdje a szükséges könyvtárak importálásával, mint

amilyen a json, requests és pandas.
2. Következőként importálja az adatkészletet (test_data.csv), amelyet
a végponttal végzett következtetéshez fog használni.
3. Törölje a következtetéshez nem szükséges oszlopokat, mint amilyen a Timestamp,
Location és Future_weather_condition (ezt az utolsó oszlopot a végpont
kérésével fogjuk előrejelezni).
4. Következőként mutasson rá a végpont URL-jére (ezt úgy találhatja meg, ha elmegy
az Azure ML Workspace | Endpoints | Weather-prod-service | Consume helyre).
Az egyszerűség kedvéért, mivel nincs beállított hitelesítésünk vagy kulcsaink a
szolgáltatásnál, egy kulcsok vagy hitelesítés nélküli címsorral rendelkező JSON/
alkalmazásunk lesz.
5. Végül visszacsatoljuk az adattömböt a tömbben lévő egyes elemek végponttal való

következtetésével. A szkript futtatásához egyszerűen lecseréljük az 'url' kifejezést
a végpontra és futtatjuk a következő parancsot a terminálban (a mappa helyéről)
a szkript végrehajtásához:
>> python3 inference.py
A szkript futása nagyjából 10-15 percbe telik, következtessen a következtetési adatok

összes elemével. Ezután monitorozhatjuk a következtetést és elemezhetjük a következtetési
adatok eredményeit. Monitorozzuk és elemezzük ezt, kezdve az adatvédelemmel.
Az Ön ML rendszerének monitorozása
A Monitor modul feladata az alkalmazás monitorozása az alkalmazásban (azaz az ML
modell kiszolgálása). A műveleti monitor modul a következő három funkcióval rendelkezik:
• Adatvédelem:
-A céladatkészlet regisztrálásához
-Egy adateltérés monitor létrehozásához
-Adateltérési elemzés végrehajtásához
-Jellemzőeltérési elemzés végrehajtásához
• Modelleltérés
• Alkalmazás teljesítménye
Nézzük meg részletesen az egyes funkciókat.
Adatvédelem
Az adatvédelem monitorozásához a következtetési adatoknál monitoroznunk kell az
adateltérést és jellemzőeltérést, hogy lássuk, van-e bármilyen rendellenes változás a bejövő
adatokban vagy bármilyen új minta:
• Adateltérés: Ez történik, amikor a független változók tulajdonságai változnak.

Például adatváltozás következhet be a szezonalitás vagy az új termékek hozzáadása
vagy a fogyasztói kívánságok vagy szokások változása miatt, ahogy az meg is történt
a COVID-19 járvány alatt.
• Jellemzőeltérés: Ez történik, amikor a jellemző(k) tulajdonságai változnak az idővel.

Például a hőmérséklet változik az évszakok változása miatt, azaz nyáron a hőmérséklet
melegebb a téli vagy őszi hőmérséklethez képest.
Az eltérések monitorozásához mérni fogjuk az a különbséget az alap adatkészlet és a cél

adatkészlet között. Az első lépés az alap adatkészlet és a cél adatkészlet meghatározása.
Ez felhasználási esetenként változik; a következő adatkészleteket fogjuk használni alap
és cél adatkészletként:
• Alap adatkészlet: Ez a tanítási adatkészlet.

• Cél adatkészlet: Ez a következtetési adatkészlet.
A tanítási adatkészletet fogjuk használni alap adatkészletként, amelyet korábban

a modelljeink tanításához használtunk. Azért tesszük ezt, mert következtetésre használt
modell nagyon jól ismeri a tanítási adatkészlet mintáit. A tanítási adatkészlet ideális hozzá,
hogy összehasonlítsuk, hogyan változik idővel a következtetési adat. Le fogjuk fordítani
a következtetés során gyűjtött összes következtetési adatot a következtetési adatkészletben,
és összehasonlítjuk ezt a két adatkészletet (azaz az alap adatkészletet és a cél adatkészletet),
hogy mérjük az adatok és jellemzők eltéréseit a cél adatkészletnél.
A céladatkészlet regisztrációja
A tanítási adatkészletet a 4. fejezet: Machine Learning folyamatok részben az Adatbevitel és
funkciótervezés szakaszban regisztráltuk. Regisztrálnunk kell a következtetési adatkészletet
az Azure ML munkaterület Datasets részén.
A következtetési adatok gyűjtése az azureml.monitoring SDK (a modelData-

Collector függvény) használatának eredménye. A monitorozási funkciók
engedélyezése által a modelDataCollector függvény használatával a pontozó fájljában
(a score.py, mint ahogy a 6. fejezet: Az Ön ML rendszerének telepítési alapelvei részben
tettük) tároljuk a következtetési adatokat egy idősoros adatkészlet formájában a Blob
tárolóban. Az Azure ML munkaterületéhez csatolt Blob tárolóban tároljuk a következtetési
adatokat a modeldata konténerben. A modeldata konténerben CSV fájlok formájában
tároljuk a következtetési adatokat (beleértve a bemeneteket és kimeneteket), amelyeket
a mappákon belül elkülönítettünk. Év, hónap és nap szerint rendeztük őket (amikor
rögzítették a következtetési adatokat a termelésben). Az elkülönített mappákban CSV
fájlokban tároljuk a következtetési adatokat, amelyeknek az inputs.csv és outputs.
csv nevet adtuk. Regisztrálnunk kell ezeket az input.csv fájlokat az adateltérés és
jellemzőeltérés monitorozásához. Kövesse ezeket a lépéseket az input.csv fájlok
regisztrálásához:
1. Menjen a Datasets részre és kattintson a Create dataset opcióra. Majd válassza

ki a From datastore opciót, ahogy a 12.6 ábrán látható:
12.6 ábra: A következtetéses adatkészlet regisztrációja

2. Nevezze el az adatkészletet (például: Inputs-Inference-Dataset),

válassza ki az adatkészlet típusának a Tabular opciót, és írjon egy megfelelő leírást
a Description nevű mezőbe, itt írja le az adatkészletének a célját. Kattintson
a Next gombra, hogy megadja az adattároló kiválasztását. Válassza ki a modeldata
adattárolót, ahogy a 12.7 ábrán látható:
12.7 ábra: Az adattároló kiválasztása (a bemenetek, következtetés, adatok regisztrációjához)

3. A modeldata adattároló kiválasztása után, meg kell adnia a fájl(ok) elérési

útvonalát. Kattintson a Browse gombra az útvonal megadásához. Kapni fog egy
listát a fájlokról a modeldata adatraktárában. Menjen arra a helyre, ahol egy
input.csv fájl található. Ezt a support vectorclassifier model
mappájában találhatja meg, amely azon a mappán belül van, amit úgy hívnak,
mint a szolgáltatását (például: prod-webservice). Majd menjen az almappákba
(az alapértelmezett a bemenetek és a mappák dátum szerint vannak rendezve),
és menjen az aktuális dátum mappájában, hogy megtalálj az input.csv fájlt.
Válassza ki a input.csv fájlt, ahogy a 12.8 ábrán látható:
12.8 ábra: Az input.csv fájl útvonalának kiválasztása (a bemenetek, következtetés, adatok

regisztrációjához)
4. Miután kiválasztott az input.csv fájlt, kattintson a Save gombra és módosítsa

az utolsó részt, beleértve a /**/inputs*.csv részt (ahogy a 12.9 ábrán látható).
Ez egy fontos lépés, amely az összes input.csv fájlra dinamikusan fog utalni
az inputs mappában. Az összes input.csv fájl hivatkozása nélkül csak egyetlen
input.csv fájlt különítünk el (amelyet korábban kiválasztottunk a 12.8 ábrán). Az
összes input.csv fájl hivatkozásával az összes bemeneti adatot (az input.csv
fájlok) le fogjuk fordítani a cél adatkészletbe (például: Inputs-
Inference-Data):
12.9 ábra: Az elérési út megjelölése az összes input.csv fájl dinamikus eléréséhez

5. Kattintson a Next gombra, hogy továbblépjen a Settings and preview részre:
12.10 ábra: Beállítások és előnézet (a következtetéses adatkészlet regisztrációjához)

Ahogy a 12.10 ábrán látható, konfigurálhatjuk a beállításokat és megtekinthetjük

az adatkészletet. Mutasson a helyes oszlop nevére azzal, hogy kiválasztja a Column
headers legördülő menüt, majd kiválasztja a Combine headers from all files opciót.
Ellenőrizze az oszlopnevek helyességét (például Temperature_C és Humidity).
Miután kiválasztotta a megfelelő oszlopneveket, kattintson a Next gombra, hogy
továbblépjen a következő ablakra. Válassza ki a megfelelő vázlatot úgy, hogy
kiválasztja az összes oszlopot, amit monitorozni szeretne, az adattípusaikkal együtt,
12.11 ábra: A vázlat kiválasztása (a következtetéses adatkészlet regisztrációja)

Győződjön meg róla, hogy kiválasztotta-e a Timestamp és Date tulajdonságokat

a $aml_dc_scoring_timestamp oszlopban, mivel ezek tartalmazzák a következtetés
időbélyegét. Ez a lépés fontos. Csak egy idősorozat formátumú adatkészlet
használható az eltérés számításához (az Azure eltérés modellnél); másképp nem
tudjuk kiszámítani az eltérést. A megfelelő vázlat összes oszlopon keresztüli
kiválasztása után kattintson a Next gombra, hogy megerősítse az összes szükséges
részletet (mint amilyen az adatkészlet neve, verziója, útvonala stb.).
6. Kattintson a Create gombra az adatkészlet létrehozásához. Amikor sikeresen
létrejött az adatkészlete, megtekintheti az adatkészletet az Azure ML munkaterület
Dataset részén. Menjen a Datasets részre, hogy ellenőrizze, létrejött-e az
adatkészlete. Azonosítsa be és kattintson rá a létrehozott adatkészletére.
A kattintással megnézheti a regisztrált következtetési adatkészletének részleteit,
12.12 ábra: A regisztrált következtetéses adatkészlet megtekintése

Láthatja az összes lényeges jellemzőjét a regisztrált adatkészletének a 12.12 ábrán.

Fontos megjegyezni, hogy a relatív útvonal dinamikus és az összes input.csv fájl
hivatkozására mutat. Az összes bemeneti fájl lehivatkozásának eredménye látható a Files
in dataset részen. Ez hosszú távon több fájlt fog mutatni (azaz 6 fájlt mutat az adatkészlet
6 napos regisztrációja után). Önnek ez lehet 1 fájl is, még csak az adatkészletet regisztrálta.
Az idő vagy napok múlásával az input.csv fájlok száma növekedni fog, ahogy egy
új input.csv jön létre a Blob tárolóban minden nap. Gratulálunk a következtetéses
adatkészlet regisztrációjához. Következőként az adateltérés monitort fogjuk konfigurálni.
Az adateltérés monitor létrehozása

Az adateltérés és jellemzőeltérés monitorozásához a beépített eltérésmonitorozó
funkciókat fogjuk használni az Azure ML munkaterületről a Datasets részen. Az eltérések
monitorozásához állítsunk be egy Data Drift Monitor funkciót az Azure ML
munkaterületünkön:
1. Menjen a Datasets részre a munkaterületén. Majd válassza ki a Dataset Monitors

opciót (jelenleg ez az előnézet módban van, mivel ez a funkció még tesztelés alatt
áll). Kattintson a Create opcióra, ahogy a 12.13 ábrán látható:
12.13 ábra: Az adateltérés monitor létrehozása

2. A Create gomb kiválasztásakor figyelmeztetést fog kapni, hogy hozzon létre egy új
adateltérés monitort. Válassza ki tetszés szerint a cél adatkészletet.
3. A Registering the target dataset részen regisztráltuk az inputs.csv fájlokat
Input-InferenceData-ként. Válassza ki cél adatkészletként a következtetési
adatkészletét, ahogy a 12.14 ábrán látható:
12.14 ábra: A cél adatkészlet kiválasztása

4. A cél adatkészlet kiválasztása után rá kell mutatnia az alap adatkészletére, amely
a tanítási adatkészlet kell legyen (ezt használtuk a telepített ML modell tanításához).
Válassza ki az alap adatkészletet, ahogy a 12.15 ábrán látható:
12.15 ábra: Az alap adatkészlet kiválasztása és a monitorbeállítások konfigurálása

5. Az alap adatkészlet kiválasztása után be kell állítania a monitorozás beállításait, mint
például az adateltérési monitor neve (például weather-Data-Drift), a számítási
célt az adateltérési feladatok futtatásához, az adateltérési feladatok gyakoriságát
(például naponta egyszer) és a küszöbértéket a monitorozási eltéréshez (például 60).
Egy e-mail címet is meg kell adnia, ahová az értesítések fognak érkezni, amikor az
adateltérés meghaladja a beállított küszöbértéket.
6. A beállítások konfigurálása után hozzon létre egy adateltérés monitort. Menjen

az újonnan létrehozott adateltéréshez (a Datasets részen, kattintson a Dataset
Monitors opcióra, hogy megtekintse az eltérési monitorokat), ahogy a 12.16 ábrán
látható:
12.16 ábra: Adateltérés áttekintése (jelenleg üres)

Amikor megnyitotta az adateltérési monitorját, azt fogja látni, hogy nincs ott
adat. Ez azért van, mert még nem számítottunk ki semmilyen eltérést. Egy eltérés
számításához szükségünk van egy számítási erőforrásra.
7. Menjen a Compute részre, nyissa meg a Compute clusters fület, és hozzon létre
egy új számítási erőforrást (például drift-compute – Standard_DS_V2 machine),
12.17 ábra: Egy számítási klaszter létrehozása az adateltérés számításához

8. A számítási klaszter létrehozása után menjen vissza az adateltérés monitorához
(például: Weather-Data-Drift). Következőként kiszámítjuk az adateltérést.
9. Kattintson az Analyze existing data opcióra és futtassa le, hogy elemezzen bármely
meglévő következtetési adatot, ahogy a 12.18 ábrán látható:
12.18 ábra: Egy futás beküldése az adateltérések elemzésére

10. Válassza ki a kezdő- és végdátumokat és a számítási célt (amelyet korábban
létrehoztunk, azaz a drift-compute). Majd kattintson a Submit gombra az
eltérés számításának futtatásához. Az adateltérés számítása és elemzése nagyjából
10 percet vesz igénybe általában. A futtatásainak folyamatát követheti az Azure ML
munkaterület Experiments részén.
Adateltérés elemzése: A futtatás sikeres befejezése után kiszámításra került az
adateltérés. Az eltérési áttekintés használatával monitorozhatjuk és elemezhetjük
az ML modelljének teljesítményét a termelésben, ahogy a 12.19 ábrán látható.
Megtekinthetjük az adateltérés mértékét és a funkciók szerinti eltéréseloszlást:
12.19 ábra: Az adateltérés terjedelmének trendje

Az Azure ML szolgáltatás úgy méri a modelleltérést, hogy egy külön eltérési
modellt használ (az Azure tartja fenn), amely megnézi az alapot és összehasonlítja
a következtetési adatokkal. Ez az összehasonlítás egy egyszerű statisztikai százalékot
vagy változási fokot eredményez az adatokban.
A 12.19 ábrán a Drift magnitude trend azt mutatja, hogy 3 napon voltak
következtetéseink a modellel (ezek: 03/23/21, 04/03/21 és 04/04/21).
Az elemzés azt mutatja, hogy az adateltérés ennél a három alkalomnál a 70%-os
küszöbérték alatt van (ez a piros vonal, ami a küszöbértéket jelzi). Az adateltérés
nagyjából 50% volt a 03/23/21 napon; nagyjából 44% a 04/03/21 napon; és 40%
a 04/04/21 napon. Ezzel kialakul bennünk egy kép a bejövő következtetési adatok
változási trendjéről a modellnél. Hasonlóan monitorozhatjuk a jellemzőeltérést.
• Jellemzőeltérés elemzése: Értékelheti az egyes jellemzőket és az eltérésüket,

ha legörget a Feature details részre és kiválaszt egy jellemzőt. Például megnézhetjük
a Temperature_C eloszlását az idő függvényében, ahogy a 12.20 ábrán látható:
12.20 ábra: A funkcióeltérési trend (Temperature_C)

A jellemző időben történő változásának monitorozásához kiválaszthatunk néhány
mérést a jellemzőhöz. Az olyan mérőszámok, mint a Mean value, Min value, Max
value, Euclidean distance vagy Wasserstein distance elérhetők a jellemzőeltérés
elemzéséhez. Válasszon ki egy tetszőleges mérőszámot (például: Mean value).
Kiválasztottuk a Mean value mérőszámot, hogy értékeljük a hőmérséklet
eltérését, ahogy a 12.20 ábrán látható. A Mean value mérőszám 14-ről 8-ra
változott az idő előrehaladtával; ez mutatja az eltérés változását a Temperature_C
jellemzőnél. Egy ilyen változás várható volt, mivel az évszakok változásával változik
a hőmérséklet. A jellemzőeloszlás változását is monitorozhatjuk, ahogy a 12.21
ábrán látható:
12.21 ábra: A funkcióeloszlási trend

Ha az eltérés drasztikus vagy rendellenes, ellenőriznünk kell a bemeneti adatok minőségét,
amellyel a rendszer következtetett. A jellemzőeltérés meglátásai lehetővé teszik, hogy
megértsük a változó adatokat és világot körülöttünk. Ehhez hasonlóan monitorozhatjuk
a modelleltérést, hogy megértsük a modell teljesítményét összefüggésben a változó
adatokkal és világgal.
Modelleltérés
A modelleltérés monitorozása lehetővé teszi, hogy ellenőrizzük a modellünk teljesítményét
a termelésben. Ott van modelleltérés, ahol a függő változók tulajdonságai változnak.
Például a mi esetünkben ez az időjárás osztályozásának eredménye (azaz esik-e vagy sem).
Pont ahogy beállítottuk az adateltérést az Adateltérési monitor létrehozása részben, úgy
beállíthatjuk a modelleltérési monitort is modell kimeneteinek monitorozására. Itt vannak
a magas szintű lépések a modelleltérés beállításához:
1. Regisztráljon egy új adatkészletet (például: Output-Inference-Data) úgy, hogy

hivatkozik az összes Outputs.csv fájlra. Az Outputs adatkészlet a Datasets
részen hozható létre. Amikor egy kimeneti következtetéses adatkészletet hoz létre,
válassza ki a fontos oszlopokat (például: Future_Weather_Condition) és alakítsa
át az adatkészletet táblázatos és idősoros formátumba (az eltérés csak idősoros
adatokban számítható) úgy, hogy kiválaszt egy oszlopot Timestamp-pal.
2. Hozzon létre egy új monitort (például modelleltérés monitort) a Dataset részen
és kattintson a Dataset Monitor opcióra. Válassza ki monitorozandó jellemzőt
(például: future weather condition) és állítson be hozzá egy küszöbértéket.
3. Elemezze a modelleltérést az áttekintésben (ahogy a 12.22 ábrán látható):
12.22 ábra: Egy futás beküldése az adateltérések elemzésére

Ha a modelleltérése meghaladta a beállított küszöbértéket, akkor az azt jelezheti, hogy
újra kell tanítania a modelljét, vagy összehasonlító eredményekkel kell tanítania egy
egyszerű statisztikai százalékban vagy az adatváltozás fokában. Amikor az adateltérés
átlépte a küszöbértéket (például 70%-ot), akkor értesíthetjük a rendszergazdát vagy
a terméktulajdonost e-mailben, vagy intézkedéseket tehetünk, például telepíthetünk egy
másik modellt vagy újrataníthatjuk a meglévő modellt. Okos intézkedések alkalmazásával
úgy irányíthatjuk az ML rendszereket, hogy a maximális értéket állítsák elő. A következő
fejezetben megismerjük az ML rendszerek irányításának módjait (13. fejezet: Az ML
rendszerek irányítása a folytonos tanuláshoz). Idáig megvalósítottuk az adateltérés,
jellemzőeltérés és modelleltérés beállítását. Következőként monitorozzuk az ML rendszer
alkalmazásának teljesítményét.
Alkalmazás teljesítménye
Telepítette az ML szolgáltatást REST API végpontok formájában, amelyet fogyaszthatnak
a felhasználók. Az Azure Application Insights (az Azure Monitor teszi lehetővé)
használatával monitorozhatjuk ezeket a végpontokat. Az alkalmazásunk teljesítményének
monitorozásához nyissuk meg az Application Insights vezérlőpultját, ahogy
a 12.23 ábrán látható. Menjen az Endpoints részre az Azure ML szolgáltatás
munkaterületén és válassza ki azt a REST API végpontot, amelyre az ML modelljét
telepítette. Kattintson az Application Insights url opcióra, hogy megnyissa az Application
Insights végpontot, amely csatlakozott az Ön REST API végpontjához:
12.23 ábra: Alkalmazás Meglátások Áttekintése

Az Application Insights Overview részen monitorozhatjuk és elemezhetjük

a kritikus alkalmazásteljesítmény információit az ML szolgáltatásunknál. Tovább
olyan információkat is monitorozhatunk, mint a sikertelen kérések, szerver válaszidő,
szerver kérések és elérhetőség, az Overview részen, ahogy a 12.24 ábrán látható:
12.24 ábra: Alkalmazás Meglátások Áttekintése

Ezen mérőszámok és információk alapján monitorozhatjuk az alkalmazás teljesítményét.

Ideális esetben nincs semmilyen sikertelen kérés vagy nagy szerver válaszidő.
Az alkalmazásunk teljesítményének mélyebb meglátásaihoz megnyithatjuk az alkalmazás
vezérlőpultját(ha rákattintunk a gombra a képernyő tetején), ahogy a 12.25 ábrán látható:
12.25 ábra: Az Alkalmazás vezérlőpult egy részletesebb teljesítményértékeléssel

Az alkalmazás vezérlőpultjából részletesebben monitorozhatjuk az alkalmazás
teljesítményét. Például monitorozhatjuk az alkalmazás használatát, megbízhatóságát
és egyéb információkat. A használat tekintetében a Unique sessions and users kritikus
információ az egyedi felhasználók számának monitorozására, akiket az alkalmazás
képes kiszolgálni. Továbbá az Average availability információ hasznos a szolgáltatás
felhasználók általi elérhetőségének értékeléséhez. Ezzel az információval méretezési
döntéseket hozhatunk, ha több erőforrás szükséges a felhasználók kiszolgálásához.
Monitorozhatjuk az alkalmazás megbízhatóságát az olyan információk értékelésével,
mint a sikertelen kérések, szerver kivételek és függőségi hibák. Monitorozhatjuk az
érzékenységet olyan információk felhasználásával, mint az átlagos szerver válaszidő és
a CPU kihasználtsága. Ideális esetben az alkalmazásnak nincsenek hibái, és ha vannak
hibái, akkor megnézhetjük alaposabban az alkalmazás naplóit, ahogy a 12.26 ábrán
látható, ha megnyitjuk a Transaction search részt vagy a naplókat:
12.26 ábra: A naplók elérése a hibák megértéséhez

Vethetünk egy közelebbi pillantást az alkalmazások naplóira, hogy megértsük a hibákat,
így kijavíthatjuk azokat az alkalmazásban és fenntarthatjuk az alkalmazás helyes
működését. Egy működő ML alkalmazás elégedett felhasználókat és maximális üzleti
hatást eredményez. Ezért az alkalmazások monitorozása jövedelmező lehet, hogy fény
derüljön a potenciális hibákra és fenntartsuk az alkalmazást, hogy a leghatékonyabb
módon szolgálja ki a felhasználókat.
Az Ön ML rendszerének elemzése
A termelésben lévő ML rendszerének valós idejű monitorozása és elemzése a kulcs ahhoz,
hogy megértse az ML rendszerének teljesítményét és biztosítsa annak robosztusságát
a maximális üzleti érték előállításához. Az emberek fontos szerepet játszanak
a modellteljesítmény elemzésében és az apró anomáliák és veszélyek észlelésében.
Elemezhetjük a modell teljesítményét, hogy észrevegyük az elfogultságokat vagy
veszélyeket, és megértsük, miért bizonyos minta szerint hozza a modell a döntéseket.
Ezt olyan fejlett technikák alkalmazásával érhetjük el, mint az adatok darabolása,
a rosszindulatú támadásokat megelőző technikák vagy a helyi és globális magyarázatok
megértése.
Adatok darabolása
A mi felhasználási esetünknél kihagyjuk az adatok darabolását, mivel nem túl változatosak
az adataink a demográfia vagy minták tekintetében (például nem, korcsoportok stb.).
A modell korrektségének méréséhez az elfogultság észlelésére fogunk koncentrálni.
Elfogultság és fenyegetés észlelése

A termelésben lévő modell elfogultságának meghatározásához használhatjuk az
elfogultság-variancia átváltási módszert. Ez egyszerűvé teszi a modell elfogultságának
vagy bármely más fenyegetésnek a monitorozását és észlelését. Mondanom sem kell, hogy
lehetnek jobb módszerek az elfogultság monitorozására, de itt fontos volt az egyszerűség,
mivel néha az egyszerűség a jobb és hatékonyabb.
A modellünk átlagos előrejelzése és az előre jelzendő megfelelő érték közötti különbség
az elfogultság. A variancia a modell becslésének változatossága egy adott adatpontra
vagy egy értékre, amely tájékoztat minket az adataink szórásáról. Az elfogultság és
variancia elemzése a telepített modell következtetési adatainál megmutatja, hogy az
elfogultság 20,1 és a variancia 1,23 (az elfogultság és variancia elemzéséről itt olvashat
továbbiakat: https://machinelearningmastery.com/calculate-the-bias-
variance-trade-off/). Ez azt jelenti, hogy a modellünknek magas az elfogultsága
és alacsony a varianciája; ezért jó ötlet lenne tanítani vagy újratanítani a modellünket
a következtetési adatokkal, hogy kiegyensúlyozzuk az elfogultság-variancia arányát.
Helyi és globális magyarázatok

A helyi és globális magyarázatok különböző perspektívákat kínálnak a modell
teljesítményéről. A helyi magyarázat egy igazolást ad a modell előrejelzéséhez egy adott
vagy egyedi bemenethez, míg a globális magyarázat a modell előrejelzési folyamatába
kínál belelátást egy adott bemenettől függetlenül. Korábban megnéztük a globális
magyarázatokat, amikor az eltérések monitorozását vizsgáltuk a 12.19 ábrán. Tovább
vizsgálhatjuk a jellemzőeloszlást, ahogy a 12.21 ábrán látható, hogy jobban megértsük
a helyi magyarázatokat.
Az ML rendszer korrektségének, elfogultságának, helyi és globális magyarázatainak
elemzése fontos meglátásokat ad a modell teljesítményéről, és felhasználhatjuk ezt az
információt az ML rendszerünk irányításához.
Az Ön ML rendszerének irányítása
Egy rendszer irányításának nagy része magába foglalja a minőségbiztosítást és irányítást,
a modell auditálását és jelentést, hogy meglegyen az end-to-end követhetőség és
a szabályozásoknak való megfelelőség. Az ML rendszerek hatékonysága (azaz egy
kívánt vagy szándékolt eredmény előállításának képessége) függ attól, hogyan irányítják
a maximális üzleti érték eléréséhez. Idáig monitoroztuk és elemeztük a telepített
modellünket a következtetési adatoknál:
Összefoglalás 309
12.27 ábra: Az Ön ML rendszerének irányításának összetevői

Egy ML rendszer hatékonysága okos intézkedések használatával meghatározható,
amelyeket a monitorozás és riasztás alapján kell meghozni. A következő fejezetben
megismerjük az ML rendszer irányítását a riasztások és intézkedések, modell QA és
irányítás illetve a modell auditálása és jelentések tekintetében.
Összefoglalás
Ebben a fejezetben az ML modellek felhasználóknak történő kiszolgálásának alapelveiről
tanultunk és arról, hogyan monitorozzuk őket a maximális üzleti érték eléréséhez.
Megismertük az ML modellek kiszolgálásának különböző módjait a modell fogyasztóinak
vagy felhasználóinak irányába, és megvalósítottuk a Magyarázható Monitorozási
keretrendszert egy elméleti üzleti felhasználási esetnél és egy telepített modellnél.
Azért hajtottuk végre a Magyarázható Monitorozási keretrendszernek a gyakorlati
megvalósítását, hogy mérjük az ML rendszerek teljesítményét. Végül megvitattuk az ML
rendszerek irányításának szükségességét, hogy biztosítsuk az ML rendszerek robosztus
teljesítményét.
A következő és egyben utolsó fejezetben még jobban megismerjük az ML rendszerek
irányítását és a folytonos tanulás elveit!
13
Az ML rendszerek
irányítása
a folytonos
tanuláshoz
Ebben a fejezetben reflektálni fogunk a gépi tanulási (ML) megoldásoknál a folytonos
tanulás szükségességére. Az adaptáció áll a gépi intelligencia középpontjában. Minél jobb
az adaptáció, annál jobb a rendszer. A folytonos tanulás a külső környezetre fókuszál és
adaptálódik hozzá. A folytonos tanulás lehetővé tétele az ML rendszereknél nagyszerű
előnyökkel járhat. Megnézzük, mi szükséges egy ML rendszer sikeres irányításához, ahogy
felderítjük a folytonos tanulást és megvizsgáljuk az Explainable Monitoring Framework
irányítási összetevőjét, amely segít nekünk irányítani az ML rendszert a maximális érték
eléréséhez.
El fogunk mélyedni az irányítás gyakorlati megvalósításában a riasztás és intézkedés
funkciók engedélyezésével. Következőként megnézzük a modellek minőségbiztosításának
és a telepítések irányításának módjait, valamint megtanuljuk a legjobb praktikákat
a modell auditok és jelentések generálására. Végül olyan módszerekről fogunk tanulni,
amelyek lehetővé teszik a modell újratanítását és a CI/CD folyamatok fenntartását.
312 Az ML rendszerek irányítása a folytonos tanuláshoz
Kezdésként reflektálunk a folytonos tanulás szükségességére és következő témák

felderítésével folytatjuk a fejezetben:
• A folytonos tanulás szükségességének értelmezése

• Egy ML rendszer irányítása az Explainable Monitoring használatával
• Modell újratanításának engedélyezése
• A CI/CD folyamat fenntartása
A folytonos tanulás szükségességének

értelmezése
Amikor nekikezdtünk az 1. fejezet: MLOps WorkFlow alapjai részben, akkor tanultunk
annak az okairól, hogy az MI alkalmazása miért hanyatlott vissza a szervezetekben. Az egyik
ok a folytonos tanulás hiánya volt az ML rendszerekben. Igen, folytonos tanulás! Ebben a
fejezetben leküzdjük ezt a kihívást, és feltétlenül megtanuljuk, hogyan tegyük elérhetővé ezt
a lehetőséget, ennek a fejezetnek a végére. Most pedig nézzük meg a folytonos tanulást.
Folytonos tanulás
A folytonos tanulás az adatokból, emberi szakértőktől és a külső környezettől történő
folyamatos tanulás elvén alapszik. A folytonos tanulás lehetővé teszi az élethosszig tartó
tanulást a központjában történő adaptációval. Lehetővé teszi az ML rendszereknek, hogy
idővel intelligenssé váljanak, hogy adaptálódjanak a feladathoz. Monitorozással, illetve a
környezettől és az ML rendszert támogató emberi szakértőktől történő tanulással valósítja
ezt meg. A folytonos tanulás egy erőteljes kiegészítése lehet egy ML rendszernek. Lehetővé
teheti, hogy idővel megvalósítsa egy MI rendszer maximális potenciálját. A folytonos
tanulás nagyon ajánlott. Nézzünk meg egy példát:
13.1 ábra: Egy kölcsön kibocsátási szituáció, egy hagyományos rendszer és egy ember által támogatott
ML rendszer
A folytonos tanulás szükségességének értelmezése 313
Számos előnye van egy modell telepítésének (amelyet a folytonos tanulás tett lehetővé)
egy hagyományos folyamattal összehasonlítva egy olyan szervezetben, amely teljesen
az emberi alkalmazottaktól függ. Például az előző ábrán egy bank kölcsönjóváhagyási
folyamatának lépéseit láthattuk két esetben. Az első szituációban csak emberi szakértők
végezték (mint egy hagyományos banki felépítésben). A második esetben a folyamatot egy
ML rendszer használatával javították vagy automatizálták, hogy figyelje az alkalmazásokat,
tárgyaljon, kölcsönalkalmazási véglegesítést biztosítson (ahol egy emberi szakértő
ellenőrzi az ML rendszer döntéseit és jóváhagyja vagy elutasítja azokat) és jóváhagyja
a hitelt. A hagyományos felépítésben a feldolgozási idő 1 hét, míg az ML rendszer
feldolgozási ideje (az emberi szakértővel együtt dolgozva) 6 óra.
Az ML rendszer gyorsabb és fenntarthatóbb a banknak, mivel folyamatosan tanul és
javul egy ember segítségével. Az emberi alkalmazottak foglalkoztatása egy cégnél vagy
munkánál véges. Amikor elmennek, a szakterületi tapasztalatuk is elmegy, és egy új
alkalmazott betanítása vagy felvétele ugyanarra a feladatra költséges. Másrészt egy ML
modell együtt dolgozva, vagy kiegészítve egy emberi szakértővel, ami folyamatosan
tanul az idő múlásával, megoldja a betanítás kérdését egy idő után, és a tudása örökre
megmarad (az idő tekintetében). Az ML rendszer folytonos tanulása (egy emberi
szakértővel) örökre megtartható a banknál a hagyományos megközelítéssel szemben, ahol
az emberi alkalmazottak folyamatosan változnak. A folytonos tanulás hatalmas értéket
adhat egy ML rendszerhez és az üzlethez, hosszú távon.
A folytonos tanulás szükségessége

A következő ábra néhány okot mutat, hogy miért van szükség a folytonos tanulásra,
és hogyan fogja javítani az ML rendszerét, hogy maximalizálja az üzleti értékét:
13.2 ábra: A folytonos tanulás előnyei

Vegyük át részletesen a folytonos tanulás előnyeit:
• Adaptáció: A legegyszerűbb alkalmazásoknál az adateltérés maradhat ugyanaz,

ahogy érkezik az adat. Azonban sok alkalmazásnál dinamikusan változik az
adateltérés, mint például az ajánló vagy anomália észlelő rendszereknél, ahol az
adat folyamatosan áramlik. Az ilyen esetekben, a folytonos tanulás fontos
az adaptációhoz és a pontos előrejelzésekhez. Így az adatok és a környezet
természetének változásához történő adaptáció fontos.
• Méretezhetőség: Az IDC adott ki egy tanulmányt (https://www.seagate.
com/files/www-content/our-story/trends/files/idc-seagate-
dataage-whitepaper.pdf), amely szerint 2025-re az adatgenerálás sebessége
160 ZB/évre fog nőni, és ezt nem leszünk képesek mind tárolni. A tanulmány azt
jósolja, hogy 3-12%-át fogjuk tudni tárolni. Az adatokat menet közben kell majd
feldolgozni; másképp elveszítjük őket, mivel a tárolási infrastruktúra nem tud lépést
tartani az előállított adatokkal. Itt a fő trükk az lesz, hogy egyszerre kell feldolgozni
a bejövő adatokat, csak a legfontosabb információkat tároljuk és a többitől
megszabadulunk.
• Relevancia: Az ML rendszerek előrejelzéseinek relevánsnak kell lenniük és
alkalmazkodniuk kell a változó kontextusokhoz. Folytonos tanulása van szükség,
hogy az ML rendszerek nagymértékben relevánsak és értékesek maradjanak
a változó kontextusok és környezetek közepette.
• Teljesítmény: A folytonos tanulás magas teljesítményt tesz lehetővé az
ML rendszernél, mivel erősíti az ML rendszer relevanciáját azzal, hogy adaptálódik
a változó adatokhoz és környezethez. Más szóval a nagyobb relevancia javítja az ML
rendszer teljesítményét, például a pontosság vagy más mérőszámok tekintetében a
tartalmasabb vagy értékesebb előrejelzések biztosításával.
Ezen okokból szükség van a folytonos tanulásra egy ML rendszerben. tehát a folytonos
tanulás nélkül nem érhetjük el a maximális értéket, amit egy ML rendszernek kínálnia
kellene. Más szóval a projektekre hibára ítéltek. A folytonos tanulás a kulcs az MI
projektek sikerében. Egy hatékony irányítási stratégia a Magyarázható Monitorozás
részeként lehetővé teheti a folytonos tanulást. A folytonos tanulás egyik fontos része
a modell újratanítása, így lépést tarthatunk a fejlődő adatokkal és releváns döntéseket
hozhatunk. Ehhez összeolvaszthatjuk a Magyarázható Monitorozást és a modell
újratanítását, hogy lehetővé tegyük a folytonos tanulást:
Magyarázható Monitorozás + Modell újratanítása = Folytonos tanulás
Továbblépve részletesebben megnézzük a folytonos tanulást. Most ismerjük meg, hogyan
vihetünk hatékony irányítást az ML rendszerekbe.
Magyarázható monitorozás, irányítás 315
Magyarázható monitorozás, irányítás

Ebben a részben megvalósítjuk az irányítási mechanizmusokat, amelyekről korábban
tanultunk a 11. fejezet: Az Ön ML rendszerének monitorozási alapelvei részben az üzleti
felhasználási esetnél, amelyen dolgozunk. Elmélyedünk egy ML rendszer irányításának
három összetevőjében, ahogy az a következő ábrán látható:
13.3 ábra: Az Ön ML rendszerének irányításának összetevői

Az ML rendszerek hatékonysága abból származik, hogyan irányítják őket az üzleti
érték maximalizálásához. A rendszer irányításához szükséges a minőségbiztosítás és
monitorozás, a modell auditálása és jelentés, hogy meglegyen az end-to-end követhetőség
és a törvényeknek való megfelelőség. Az ML rendszereket szabályozhatjuk a modell
kimeneteinek monitorozása és elemzése által. Az okos figyelmeztetések és a viselkedés
irányítása az üzleti érték optimalizálását szolgálja. Nézzük meg, hogyan kezeli az ML
rendszer irányítását a figyelmeztetések és viselkedés, a modell minőségbiztosítása és
irányítása, a modell auditálása és jelentések.
Riasztások és műveletek
A riasztásokat a körülmények észlelését szolgáló ütemezett ellenőrzések hozzák létre.
Egy feltétel teljesülésekor létrejön egy riasztás. A létrejött riasztás alapján intézkedéseket
hajthatunk végre. Ebben a részben ezekről fogunk tanulni, és hogy hogyan kell kezelni
őket egy ML rendszer irányításához.
Mi a riasztás?
A riasztás egy ütemezett feladat, ami a háttérben fut, hogy monitorozzon egy alkalmazást,
hogy ellenőrizze, fennállnak-e bizonyos feltételek. Egy riasztást három dolog vezérel:
• Ütemezés: Milyen gyakran kell ellenőrizni a feltételeket?

• Feltételek: Mit kell észlelni?
• Intézkedések: Mit kell tennünk, amikor észleltünk egy feltételt?
Az alkalmazás teljesítménye alapján riasztásokat hozhatunk létre, hogy olyan aspektusokat

monitorozzunk, mint a következők:
• Riasztások az elérhetőséghez egy küszöbérték alapján

• Riasztások a hibás kérésekhez egy küszöbérték alapján
• Riasztások a szerver válaszidejéhez egy küszöbérték alapján
• Riasztások a szerver elvárásaihoz egy küszöbérték alapján
• Riasztások az adateltéréshez egy küszöbérték alapján
• Riasztások a modelleltéréshez egy küszöbérték alapján
• Riasztások a hibák vagy elvárások alapján
Az ML rendszerek irányításának egy fontos területe a hibák kezelése, szóval fordítsuk

a figyelmünket a hibakezelésre.
Hibakezelés
Potenciális hibák mindig lehetnek egy alkalmazásban. Előre láthatjuk őket, ha kezeljük
az összes lehetséges peremesetet az ML alkalmazásunknál. A következő ábrán látható
keretrendszer használatával kezelhetjük ezeket a hibákat. Ezen keretrendszer célja
a peremesetek azonosítása és az automatizált hibaelhárítási módszerek a lehetséges hibák
megszüntetésére. Ez működésben tartja az ML szolgáltatást:
13.4 ábra: Keretrendszer a hibák kivizsgálásához és hibaelhárításhoz

Ahogy az előző ábrán látható, az erőforrások azonosításával kezdtük, hogy hol lehetnek
a hibák, és kiválasztottunk egy erőforrás a hiba kezeléséhez. Egy erőforrás kiválasztásakor
a magas kihasználtságú erőforrások és az erőforrás telítettség (egy erőforrás akkor telített,
amikora kapacitását teljesen kihasználják vagy a kapacitása átlépett egy küszöbértéket)
ellenőrzésével keressük a hibákat. Bármelyik probléma esetén kivizsgáljuk, amit találtunk
a naplók megvizsgálásával és kigondolunk egy megoldást a hibák kezelésére. Végső fokon
automatizáljuk a hibaelhárítást előre megírt szkriptek használatával, amelyek bármilyen
problémát kezelnek (ami akadályozza a rendszer optimális működését), például az
erőforrás újraindításával vagy egy függvény vagy fájl újbóli betöltésével, hogy az erőforrás
újra rendes állapotban fusson.
Az összes lehetséges peremeset kezelésével és az automatizált hibakezeléssel vagy
hibaelhárítással hibabiztossá tehetjük az alkalmazásainkat, hogy kiszolgálják
a felhasználóinkat. Egy hibabiztos alkalmazás lehetővé teszi a robosztusságot,
gondoskodik a felhasználók zökkenőmentes tapasztalatáról és értékéről, ami az ML
alkalmazás használatából származik. Amint azonosított egy hibát, kezelje azt úgy, hogy
kivizsgálja vagy létrehoz egy automatikus hibaelhárítási folyamatot és megoldja a hibát.
Végül is a megelőzés jobb, mint a gyógyítás. Így az összes lehetséges peremeset ellenőrzése
és azonnali kezelése jövedelmező lehet.
Kezelhetjük a potenciális hibákat a kivételkezelési funkciók használatával. A kivételkezelés

egy programozási technika, amelyet ritka szituációk kezelésére használnak, amelyek
speciális figyelmet igényelnek. A kivételkezelést sokféle hibánál könnyű megvalósítani
a Pythonban. Használhatjuk a try, except, else és finally függvényeket a hibák és
kivételek kezelésére, ahogy a következő ábrán látható:
13.5 ábra: A kivételek és szélsőséges esetek kezeléséhez

Minden utasítás azelőtt kerül végrehajtásra, hogy a try előírás egy kivételt találna.
A kivétel(eke)t, amit a try előírás talál, a except blokk csípi el és kezeli. Az else blokk
teszi lehetővé, hogy olyan részeket írjon, amelyek csak akkor futnak le, ha nincs kivétel
a try előírásban. A finally használatával olyan kódrészleteket futtathat, amelyeknek
mindenképpen le kell futniuk, akár volt kivétel, akár nem.
Itt van egy lista néhány lehetséges gyakori kivételről vagy hibáról, amelyeket keresni kell:
13.2 táblázat: A lehetséges gyakori kivételek vagy hibák, amelyeket keresni kell
Ezek a peremesetek vagy hibák gyakoriak és kezelhetők az alkalmazásban a try és

exception technikák használatával. Az a stratégia, hogy megszüntessük az olyan
szituációkat, ahol az ML rendszer nagyon egyszerűnek vagy naívnak tűnik a felhasználó
számára; például egy chatbot, ami hibaüzeneteket küld a chaten. Az ilyen esetekben
a hibák költsége magas, és a felhasználók elveszítik az ML rendszerbe vetett bizalmukat.
Meg fogunk valósítani néhány gyakori kivételt és hibakezelést az üzleti felhasználási
esetnél, amelyet eddig valósítottunk meg és intézkedéseket hajtunk végre a generált
riasztások alapján. Kezdjünk neki:
1. Az Azure DevOps projektjében menjen a könyvünk adatraktárába (korábban

klónoztuk az Azure DevOps projektben) és menjen a 13_Govenance_
Continual_Learning nevű mappába. Onnan nyissa meg a score.
py fájlt. Azzal kezdjük, hogy importáljuk a szükséges könyvtárakat. Most az
applicationinsights könyvtárat fogjuk használni az Application Insights
egyedi eseményeinek vagy kivételeinek követésére, amelyek csatlakoznak
a végponthoz:
import json
import numpy as np
import os
import pickle
import joblib
import onnxruntime
import logging
import time
from applicationinsights import TelemetryClient
from azureml.monitoring import ModelDataCollector
from inference_schema.schema_decorators import input_
schema, output_schema
from inference_schema.parameter_types.numpy_parameter_
type import NumpyParameterType
Ahogy az előző kódban látható, importáltuk a TelemetryClient függvényt

az applicationinsights könyvtárból. A TelemetryClient függvényt
fogjuk használni, hogy megnyissuk az Application Insights-t, amely csatlakozott
a végpontunkhoz. Adja meg a műszerezési kulcsát az Alkalmazás Ötletekből
a TelemetryClient függvénynek.
2. Ez az Instrumentation Key elérhető az Application Insights-ból, amelyet

csatlakoztatni kell az ML alkalmazáshoz, ahogy a következő képernyőképen látható:
13.6 ábra: Egy műszerezési kulcs megkeresése az Alkalmazás Ötletekből

3. Miután megszerezte a műszerezési kulcsát, adja meg a TelemetryClient
függvénynek, ahogy a következő kódban látható. Itt létrehozunk egy
TelemetryClient objektumot a tc változóban, amelyet az egyedi események
követésére használunk:
def init():
global model, scaler, input_name, label_name, inputs_
dc, prediction_dc, tc
tc = TelemetryClient('xxxxxxxx-xxxx-xxxx-xxxx-
xxxxxxxxxxxx')
DIR'),
'model-scaler/1/model-scaler.pkl')
# deserialize the model file back into a sklearn
model
try:
tc.track_event('FileNotFound', {'error_message':
str(e)},
{'ErrorCode': 101})
model_onnx = os.path.join(os.getenv('AZUREML_MODEL_
DIR'),
'support-vector-classifier/2/svc.onnx')
try:
None)
tc.track_event('FileNotFound', {'error_message':
str(e)},

{'ErrorCode': 101})
# variables to monitor model input and output data
inputs_dc = ModelDataCollector("Support vector
classifier model", designation="inputs", feature_
names=["Temperature_C", "Humidity", "Wind_speed_kmph",
"Wind_bearing_degrees", "Visibility_km", "Pressure_
millibars", "Current_weather_condition"])
prediction_dc = ModelDataCollector("Support vector
classifier model", designation="predictions", feature_
names=["Future_weather_condition"])
Két egyedi eseményt követtünk az init függvényben, hogy megfigyeljük,

bekövetkezik-e egy FileNotFound hiba, amikor betöltjük a scaler és model
tárgyakat. ha egy fájl nem található, a tc.track_events() függvény naplózza a
hibaüzenetet, amelyet a kivétel generált, és a 101 egyedi kódot kapja.
4. Ehhez hasonlóan megvalósítunk még néhány más egyedi eseményt:
ValueNotFound, OutofBoundsException és InferenceError a run
függvényben:
@input_schema('data', NumpyParameterType(np.
array([[34.927778, 0.24, 7.3899, 83, 16.1000, 1016.51,
1]])))
@output_schema(NumpyParameterType(np.array([0])))
def run(data):
try:
inputs_dc.collect(data)
tc.track_event('ValueNotFound', {'error_
message': str(e)},
{'ErrorCode': 201})
A try és except függvényeket használjuk a bejövő adatok összegyűjtésére

a modelladatgyűjtő funkció használatával. Ez összegyűjti és tárolja a bejövő adatokat
az Azure ML szolgáltatáshoz csatolt blob tárolóban. Ha a bejövő adat tartalmaz
néhány rendellenes adatot vagy egy hiányzó értéket, akkor egy kivétel képződik.
Egy ValueNotFound hibát küldünk a track_event függvény használatával,
így naplózhatjuk a kivétel üzenetét és az egyedi kódot (ebben az esetben egy random
vagy egyedi szám, 201, a hiba követéséhez). A bejövő adatok összegyűjtése után,
megpróbáljuk méretezni az adatot a következtetés előtt:
try:
# scale incoming data
data = scaler.transform(data)
tc.track_event('ScalingException',
{'ScalingError': str(e)},
{'ErrorCode': 301})
Az adat méretezése egy fontos lépés a következtetés előtt. Meg kell róla győződnünk,
hogy jól készült el, hibák nélkül. A try és except hasznos lehet ilyen esetekben,
mivel egy scaler fájl használatával próbáljuk méretezni az adatokat, amelyeket
betöltöttünk az init függvénybe.
Ha az adat méretezése sikertelen, akkor létrejön egy kivétel. Itt a track_
event függvényt használjuk a kivétel követésére az Application Insights-
ban. Egy ScalingError egyedi eseménynevet generálunk, ha kivétel volt.
Egy kivétel üzenet és egy 301 hibakód kerül naplózásra az Application Insights-
ban. Ehhez hasonlóan a pontozó fájl esetében a legfontosabb lépés a modell
következtetése, amelyet aprólékosan kell elvégezni.
Most megint a try és except függvényeket fogjuk használni, hogy gondoskodjunk

a kivételek nélküli sikeres következtetésről. Nézzük meg, hogyan tudunk kivételeket
kezelni ebben az esetben. Vegye figyelembe, hogy a 2 elemszámot nyitjuk meg
a model.run függvényhez. Ez egy hibát okoz a modell következtetésében,
mivel a lista egy helytelen vagy nem létező elemére hivatkozunk:
try:
# model inference
result = model.run([label_name], {input_
name:
data.astype(np.float32)})[2]
# this call is saving model output data into Azure Blob

prediction_dc.collect(result)
if result == 0:
output = "Rain"
else:
output = "No Rain"
return output
tc.track_event('InferenceException',
{'error_message':
str(e)}, {'InferenceError': 401})
output = 'error'
return output
Egy kivétel esetén, amikor a modell következtetett, használhatjuk a track_

event() függvényt, hogy egy InferenceError nevű egyedi eseményt
generáljunk. Egy hibaüzenet és egy 401 hibakód kerül naplózásra az Application
Insights-ban. Így naplózhatjuk az egyedi hibákat és kivételeket az Application
Insights-ban és intézkedéseket generálhatunk ezen hibák és kivételek alapján.
Most nézzük meg, hogyan vizsgálhatjuk meg ezeket a hibákat az Application Insights-ban
a hibanaplók használatával és generálhatunk intézkedéseket hozzájuk.
Intézkedések beállítása
Állíthatunk be riasztásokat és intézkedéseket a kivételesemények alapján, amelyeket
korábban hoztunk létre (a Hibák kezelése részben). Ebben a részben egy intézkedést
állítunk be egy e-mailes emlékeztető formájában egy általunk generált riasztás alapján.
Amikor létrejön egy kivétel vagy riasztás az Application Insights-ban, értesítést kapunk
róla egy e-mailben. Így kivizsgálhatjuk és megoldhatjuk azt.
Állítsunk be egy intézkedést (e-mail) egy riasztás fogadásakor úgy, hogy belépünk
az Application Insights-ba, amelyet csatlakoztatnunk kellett az ML rendszerünk
végpontjához. Az Application Insights-ot az Azure ML munkaterületén keresztül érheti el.
Kezdjünk neki:
1. Menjen az Endpoints részre és ellenőrizze az Application Insights-ot. Miután

megnyitotta az Application Insights vezérlőpultját, kattintson a Transaction search
opcióra, ahogy a következő képernyőképen látható, hogy ellenőrizze az egyedi
eseménynaplókat (például a következtetési kivételekét):
13.7 ábra: A szokásos események naplóinak ellenőrzése

2. Ellenőrizheti az egyedi eseményeket, amelyek kivételek és hibák miatt jöttek létre

a naplókban, majd állítsa be a riasztásokat és intézkedéseket ezekhez az egyedi
eseményekhez. Egy riasztás és intézkedés beállításához menjen a Monitoring
> Alerts részre és kattintson a New alert rule opcióra, ahogy a következő
13.8 ábra: Egy új riasztási szabály beállítása

3. Itt létrehozhatja az intézkedések feltételeit a riasztás alapján. Egy feltétel

beállításához kattintson az Add condition opcióra. Egy listát fog kapni a jelekről
vagy naplóeseményekről, amelyeket felhasználhat a feltételek készítéséhez. Válassza
ki az InferenceError opciót, ahogy a következő képernyőképen látható:
13.9 ábra: Egy feltétel konfigurálása

4. Miután kiválasztott a tetszőleges jelet vagy eseményt, konfigurálnia kell a feltétel

logikáját, ahogy a következő képernyőképen látható. Konfigurálja a feltételt
egy küszöbérték beállításával. Ebben az esetben egy 400-as küszöbértéket
adunk meg, mivel a hiba értéke 401 (mivel a 401 egyedi értéket adtuk meg az
InferenceError eseményhez). Amikor egy következtetési kivétel következik
be, az egy InferenceError hibát eredményez a fenti 400 értékkel (401, hogy
pontosak legyünk):
13.10 ábra: A feltételes logika és küszöbérték konfigurálása

5. A küszöbérték beállítása után más intézkedéseket is konfigurálnia kell, mint amilyen

egy Automation Runbook, Azure Function, Logic App, vagy Secure Webhook
futtatása, ahogy a következő képernyőképen látható. Most nem váltjuk ki ezeket az
intézkedéseket, de jó tudni, hogy vannak, mivel futtathatunk néhány szkriptet vagy
alkalmazást tartalék mechanizmusként a hibaelhárítás automatizálására:
13.11 ábra: Az automatikus hibaelhárítás műveletei (opcionális)

Így automatizálhatjuk a hibaelhárítást előre konfigurált szkriptek vagy alkalmazások
beállításával egy hiba bekövetkezésének esetére vagy a hibák megelőzésére. Végül is
a megelőzés jobb, mint a gyógyítás!
6. Végül létrehozunk egy feltételt. Kattintson a Review and create opcióra a feltétel
létrehozásához, ahogy az előző képernyőképen látható. Amint létrehozta ezt a
feltételt, látni fogja a Create alert rule panelen, ahogy a következő képernyőképen
látható. Következőként állítson be egy intézkedést úgy, hogy rákattint az Add action
groups majd Create action group opciókra:
13.12 ábra: Egy műveletcsoport létrehozása

7. Adjon meg egy e-mail címet, hogy megkaphassa az értesítéseket, ahogy a következő
képernyőképen látható. Itt elnevezheti az értesítését (az Alert rule name mezőben)
és megadhatja a szükséges információkat egy e-mailes riasztási intézkedés
beállításához:
12.13 ábra: E-mailes emlékeztetők konfigurálása

Miután megadta az összes szükséges információt, beleértve egy e-mail címet, kattintson
a Review + Create gombra, hogy konfigurálja az intézkedést (egy hibán alapuló e-mailt).
Végül adja meg a riasztási szabály részleteit, például: Alert rule name, Description és
Severity, ahogy a következő képernyőképen látható:
13.14 ábra: E-mailes emlékeztetők konfigurálása

8. kattintson a Create alert rule lehetőségre, hogy létrehozzon egy e-mailes riasztást
a hiba alapján (például: InferenceError). Ezzel létrehozott egy riasztást,
szóval itt az ideje tesztelni. Menjen a 13_Govenance_Continual_Learning
mappába és nyissa meg a test_inference.py szkriptet (cserélje le az URL-t a
saját végpont linkjével). Majd futtassa a szkriptet a következő paranccsal:
python3 test_inference.py
9. A szkript futtatása egy hibát fog adni. Állítsa le a szkriptet néhány következtetés
végrehajtása után. A hiba után 5-10 percen belül e-mailben értesítést fog kapni
a hibáról, ahogy a következő képernyőképen látható:
13.15 ábra: Egy termelési hiba e-mailes emlékeztetője

Gratulálok, sikeresen beállított egy e-mailes riasztást egy hibához! Így kivizsgálhatja,
amikor egy hibát találnak, hogy megoldhassa azt és a rendszer újra fusson.
Következőként nézzük meg, hogy gondoskodjunk a modellek minőségbiztosításáról, és

hogyan irányíthatjuk őket a maximális üzleti érték érdekében.
Modell QA és irányítás
A fejlődő vagy dinamikusan változó adat az előrejelzési hiba arányának növekedéséhez
vezet. Ennek oka lehet az adateltérés, mivel az üzlet és a külső környezet változik, vagy az
adatmérgezéses támadások. Ez növeli az előrejelzési hiba arányát, ami az ML modellek
újraértékeléséhez vezet, mivel újratanították őket (manuálisan vagy automatikusan),
így fedeztek fel új algoritmusokat, amelyek pontosabbak, mint az előzőek. Itt van néhány
irányelv az ML modellek új adatokkal történő teszteléséhez:
• Tegye lehetővé a folytonos tanulást a modelljeinek újratanítása és teljesítményük

értékelése által.
• Értékelje az összes modell teljesítményét egy új adatkészlettel, rendszeres
időközönként.
• Küldjön riasztást, amikor egy alternatív modell jobban teljesít, vagy pontosabb, mint
a meglévő modell.
• Tartson fenn egy modelljegyzéket, amely tartalmazza a legújabb információkat és
jelentéseket a teljesítményről.
• Tartsa fenn az összes modell end-to-end eredetét, hogy reprodukálhass őket vagy
megmagyarázhassa a teljesítményüket az érintetteknek.
Modell auditálása és jelentések

Egy periodikus auditálási és jelentési rendszer felállítása az MLOps-nál egy jó gyakorlat,
mivel lehetővé teszi egy szervezetnek, hogy end-to-end kövesse a műveleteit, valamint
megfeleljen a törvénynek és képes legyen megmagyarázni a műveleteit az érintettek
kérésére. Biztosíthatjuk, hogy az ML rendszer megfeleljen a társadalmi és állami szinten
kialakított szokásoknak. Az MLOps auditálásához és jelentéséhez az auditoroknak
ajánlott, hogy vegyék figyelembe egy audit alapjait, amely a következő képen látható:
13.16 ábra: Egy auditjelentés alapjai az ML műveletekhez

Adat audit
Az adat irányítja az ML rendszerek számos döntését. Emiatt az auditoroknak figyelembe
kell venniük az adatokat az auditálás és jelentés során, meg kell vizsgálniuk a tanítási
adatot, tesztelniük, következtetniük és monitorozniuk kell az adatot. Ez elengedhetetlen az
end-to-end követhetőséghez az adat felhasználásának követése érdekében (például, hogy
melyik adatkészletet melyik modell tanításához használták) az MLOps-nál. Egy Git for
Data típusú mechanizmus, amely verziókezeli az adatokat, lehetővé teheti az auditoroknak
az adatok hivatkozását, vizsgálatát és dokumentálását.
Modell audit (korrektség és teljesítmény)

Az ML rendszerek auditorainak olyan szemlélettel kell rendelkeznie, mint egy hekker,
hogy azonosítsa annak különböző módjait, hogyan mehet tönkre egy modell, és miért
nem ad korrekt következtetéseket. Először a tanítási adatokat vizsgálják meg és hasonlítják
össze a következtetés adataival a Magyarázható MI technikák használatával. Ez segíthet
az auditoroknak, a helyes ítéletek meghozásában az egyes modelleknél és azok egy
előrejelzéseinél egy egyedi szinten. A korrektség és teljesítmény értékelléséhez az egyes
modelleknél használhatunk adat darabolási technikákat, amelyek megmutathatják
az értékes információt egy értékelés elkészítéséhez. Emiatt érdemes az auditoroknak
elkérni az adatdarabolás eredményeit a szükséges demográfiákhoz és adatszeletekhez.
Egy kollektív értékelés elvégzéséhez, összehasonlíthatjuk a modelleket és értékelhetjük
a teljesítményüket. Ez egy másik szögből világíthatja meg az információt a korrektség és
teljesítmény értékeléseinél.
Ha egy modell auditálására kerül sor, az értékeli a modell bemeneteit (tanítási adatok),
magát a modellt és annak kimeneteit. Értékelni kell az adatok konzisztenciáját és
a lehetséges elfogultságokat. Például ha egy önéletrajz osztályozó modellt tanítottak
be a korábbi döntések alapján, ahol a jelentkezők megkapták az állásajánlatokat és a
dolgozókat előléptették, akkor gondoskodni akarunk róla, hogy a tanítási adatot ne
befolyásolják a korábbi toborzók és menedzserek belefoglalt elfogultságai. A versengő
modellek teljesítményértékelése, a statisztikai tesztek végrehajtása annak biztosítására,
hogy a modell a tanítás alapján általánosítson ismeretlen eredményekre, és a
legkorszerűbb technikák alkalmazása a modell értelmezéséhez, mind részei a modell
értékelési folyamatának.
Modell újratanításának engedélyezése 335
Projekt és irányítás audit

Szükséges mélyen érteni az MI modelleket az algoritmusok auditálásához? Bizonyára nem.
Egy MI rendszer auditja úgy zajlik, mint egy projektmenedzsment audit. Van egyértelmű
cél a kívánt eredményhez? Ez egy jó és egyenes kérdés, ha egy állami szerv valósított meg
MI-t egy adott környezetben. Továbbá van használható keretrendszer a modell kezelésére,
miután a fejlesztők elmentek, ha külsős fejlesztőket alkalmaztak az MI rendszerhez?
A speciális szaktudás igényének csökkentéséhez a vállalatnak kiterjedt dokumentációval
kell rendelkeznie a fogalomalkotásról és a személyzetnek ismernie kell a modellt. Így
a fejlesztési és irányítási gyakorlatok auditálása hosszú távon jövedelmező lehet.
Az adatkompenzáció, modell korrektség és teljesítmény, illetve a projektmenedzsment
és az ML rendszerek irányításának auditálása átfogó képet adhat az MLOps-ról.
A hibariasztások és intézkedések használatával időben hajthatjuk a végre a hibák
kivizsgálását, hogy a rendszer működjön, és néhány esetben még automatizált
hibaelhárítást is végezhetünk a hiba feloldásának és az MLOps-nak az automatizálására.
Végül a modell minőségbiztosítása, irányítása és auditálása révén biztosíthatjuk az
MLOps-unk hatékony irányítását. Következőként megnézzük, hogy engedélyezzük
a modell újratanítását, hogy folytonos tanulási lehetőségekkel rendelkezzen az ML
rendszerünk.
Modell újratanításának engedélyezése

Idáig beszéltünk arról, mi a modelleltérés és hogyan lehet felismerni. Tehát a kérdés
az, mihez kezdjünk vele? Ha egy modell előrejelzési teljesítménye romlott a környezet
változásai miatt, akkor a megoldás a modell újratanítása egy új tanítási készlet
használatával, amely az aktuális szituációt reprezentálja. Mennyire kell újratanítania
a modelljét? És hogyan tudja kiválasztani az új próbamunka tervét? A következő
diagram mutatja, ahogy a Model retrain függvény aktiválja a Build modult a Monitor
modul eredményei alapján. Két mód van a modell újratanítása függvény aktiválására.
Az egyik manuális, míg a másik a másik a modell újratanítása függvény automatizálása.
Nézzük meg, hogyan engedélyezhetjük mindkettőt:
13.17 ábra: A modell újratanítása engedélyezve egy MLOps munkafolyamatban

Modell manuális újratanítása

A terméktulajdonos vagy a minőségbiztosítási menedzser kötelessége a manuális
modell újratanítás sikerességének biztosítása. A modell manuális aktiválásának lépése
magába foglalja a modelleltérés értékelését, és ha az átlépi a küszöbértéket (Önnek
kell meghatároznia egy eltérési küszöbértéket, amely aktiválja a modell újratanítását),
akkor muszáj aktiválni a modell tanítási folyamatát azzal, hogy egy új adatkészlettel
tanítja a modellt (ez lehet az előző tanítási adatkészlet és a legújabb következtetési
adat). Így a termék tulajdonosa vagy a minőségbiztosítási menedzser teljes irányítással
rendelkezik a folyamat felett, és azt is tudja, mikor és hogyan kell aktiválni a modell
újratanítását ahhoz, hogy az ML rendszer a maximális értéket szállítsa.
Modell automatikus újratanítása

Ha teljesen automatizálni akarja az MLOps folyamatot, akkor a modelleltérés kezelésének
automatizálása egy ideális megközelítés lehet a termelési modell újratanításához.
A modelleltérés kezelésének automatizálása a tömeges munkák konfigurálásával végezhetők
el, amelyek az alkalmazás diagnosztikáját és a modell teljesítményét felügyelik. Aztán
aktiválnia kell a modell újratanítását. A modelleltérés kezelésének automatizálásánál az egyik
fő rész a küszöbérték beállítása, amely automatikusan aktiválni fogja a modell újratanítási
függvényét. Ha az eltérésmonitorozási küszöbértéket túl alacsonyra állítja, akkor fennáll
a kockázata, hogy túl gyakran történik újratanítás, amely magas számítási költségeket
eredményez. Ha a küszöbértéket túl magasra állítja, akkor azt kockáztatja, hogy nem történik
elég gyakran újratanítás, ami az optimálisnál rosszabbul teljesítő modelleket eredményez.
A megfelelő küszöbérték kitalálása trükkösebb lehet, mint amilyennek látszik, mivel ki kell
találnia, mennyi további tanítási adatra lesz szüksége, hogy az tükrözze az új valóságot. Akkor
is, ha a környezet megváltozott, annak nincs értelme, hogy egy meglévő modellt egy olyanra
cseréljen, aminek nagyon kicsi a tanítási készlete. Amint kitalálta a küszöbértéket, beállíthat
feladatokat (például a CI/CD folyamat részeként), amelyek rendszeresen összehasonlítják
az élő adatkészletek jellemzőeloszlásait a tanítási adatokéval (ahogy a 12. fejezet: Modellek
kiszolgálása és monitorozása részben tettük). Amikor nagy eltérést észlel (vagy a
meghatározott küszöbérték felett van), a rendszer ütemezheti a modell újratanítását és egy
új modell automatikus telepítését. Ez elvégezhető egy olyan feladatütemezővel, mint a Jenkins
vagy Kubernetes Jobs vagy CI/CD pipeline cron jobs. Így teljesen automatizálhatja az MLOps
folyamatot és a modell újratanítási részt.
Jegyezze meg, hogy nincs értelme újratanítani a modellt olyan esetekben, ahol kevés új
adat érkezik, vagy ahol néha tömeges következtetést végez (például 6 havonta). Taníthatja
a modell a következtetés előtt, vagy időszakosan, amikor szükség van rá.
A CI/CD folyamat fenntartása

Ha emlékszik, a 10 fejezet: A termelési kiadás lényeges részei részben említettük, hogy
a folyamat a termék, nem a modell. Így az automatizált vagy félig automatizált CI/CD
folyamatok beállítása után fontos monitorozni a folyamatunk teljesítményét. Ezt elvégezhetjük
a kiadások vizsgálatával az Azure DevOps-ban, ahogy a következő képernyőképen látható:
A CI/CD folyamat fenntartása 337
13.18 ábra: CI/CD folyamatkiadások fenntartása

Egy vizsgálat célja, hogy jó és robosztus állapotban tartsuk a CI/CD folyamatot. Itt van
néhány irányelv a CI/CD folyamatjó és robosztus állapotának megőrzéséhez:
• Ha egy kialakítás elromlott, végre kell hajtani egy fix it asap szabályzatot a csapattól.
• Integrálja az automatizált elfogadási teszteket.
• Kérjen pull kéréseket.
• Nézze meg a kód áttekintését minden történetnél vagy jellemzőnél.
• Auditálja rendszeresen a rendszernaplókat és eseményeket (ajánlott).
• Rendszeresen jelentsen minden csapattag számára látható mérőszámokat
(például slackbot vagy e-mailes értesítések).
Ezen gyakorlatok megvalósításával elkerülhetjük a magas hibaarányt, és robosztussá,

méretezhetővé és átláthatóvá tehetjük a CI/CD folyamatot az összes csapattag számára.
Összefoglalás
Ebben a fejezetben a folytonos tanulás fő alapelveiről tanultunk az ML megoldásokban.
Tanultunk a Magyarázható Monitorozásról (az irányítás összetevőről) a hibakezelés és az
ML rendszer fejlesztőinek e-mailes értesítések használatával történő riasztási műveletek
konfigurációjának gyakorlati megvalósításán keresztül. Végül megnéztük a modell
újratanításának módjait és a CI/CD folyamat fenntartását. Ezzel elláttuk Önt a kritikus
készségekkel az MLOps automatizálásához és irányításához az Ön felhasználási eseteihez.
Gratulálunk, hogy befejezte a könyvet! Az MLOps világa folyamatosan fejlődik. Már
készen áll rá, hogy az MLOps használatával segítse az üzlete gyarapodását. Remélem
élvezte a tanulást és olvasást a gyakorlatias MLOps megvalósításokon keresztül. Menjen,
és legyen olyan a változás, amilyet látni szeretne. A legjobbakat kívánjuk az MLOps
próbálkozásaihoz!
Packt.com
Iratkozzon fel az online digitális könyvtárunkra, hogy teljes hozzáférése legyen több, mint
7000 könyvhöz és videóhoz, valamint az iparágvezető eszközökhöz, amelyek segítenek
megtervezni az Ön személyes fejlődését és karrierépítését. További információkért, kérjük,
látogasson el weboldalunkra.
Miért érdemes feliratkozni?

• Töltsön kevesebb időt a tanulással és több időt a programozással a több, mint
4000 ipari szakértő gyakorlatias e-könyveivel és videóival
• Javítson a tanuláson a kifejezetten Önnek készült Készségtervekkel
• Minden hónapban ingyenes e-könyvet vagy videót kaphat.
• Teljesen kereshető, hogy könnyen hozzáférhessen a lényeges információkhoz
• Tartalmak másolása és beillesztése, nyomtatása és könyvjelzőzése
Tudta-e, hogy a Packt minden kiadott könyvnek az e-könyv változatát is kínálja, PDF-
és ePub-fájlok formájában? Korszerűsíthet az e-könyv verzióra a packt.com oldalon
és a nyomtatott könyv tulajdonosaként kedvezményre jogosult az e-könyv változatnál.
Lépjen velünk kapcsolatba a customercare@packtpub.com címen a további
részletekért.
A www.packt.com címen számos ingyenes műszaki cikket is olvashat, regisztráljon
az ingyenes hírlevelekre, és kapjon exkluzív kedvezményeket és ajánlatokat a Packt
könyvekre és e-könyvekre.
340 Egyéb könyvek, amiket ajánlunk
Egyéb könyvek,
amiket ajánlunk
Ha tetszett ez a könyv, lehet, hogy a Packt alábbi könyvei is érdekesek lehetnek az
Ön számára:
Fordítható gépi tanulás Pythonnal

Serg Masís
ISBN: 978-1-80020-390-7
• Ismerje meg a fordíthatóság üzleti jelentőségét

• Vizsgáljon meg valóban fordítható modelleket, mint például a lineáris modellek, döntési fák
és Naïve Bayes
• Váljon képzetté a modellek fordításában a modell-agnosztikus módszerekkel
• Képzelje el, hogyan működik egy képosztályozó és mit tanul meg
• Ismerje meg, hogyan lehet mérsékelni az elfogultság befolyását az adatkészletekben
• Fedezze fel, hogyan teheti megbízhatóbbá a modelleket ellentétes hibatűrő képességgel
• Használjon monoton kényszereket a biztonságosabb és igazságosabb modellek készítéséhez
Miért érdemes feliratkozni? 341
Azure Machine Learning mesterfokon

Christoph Körner , Kaijisse Waaijer
ISBN: 978-1-78980-755-4
• Telepítse az Azure Machine Learning munkaterületét az adatokkal végzett

kísérletekhez és vizualizációhoz
• Hajtson végre ETL-t, adatelőkészítést és funkciókinyerést az Azure legjobb
gyakorlatainak használatával
• Valósítson meg fejlett funkciókinyerést az NLP és Word bővítmények használatával
• Képezzen gradiens erősítésű fa-együtteseket, ajánlás motorokat és mély neurális
hálókat az Azure Machine Learning-en
• Használja a hiperparaméter-hangolást és az Azure Automated Machine Learning-et,
hogy optimalizálja az ML modelljeit
• Telepítse, működtesse és kezelje az ML modelljeit méretezetten
342
A Packt olyan szerzőket keres, mint Ön

Ha szeretne a Packt szerzőjévé válni, kérjük látogasson el a authors.packtpub.
com címre és jelentkezzen még ma. Több ezer Önhöz hasonló fejlesztővel és technikai
szakemberrel dolgoztunk együtt, hogy segítsünk nekik megosztani tudásukat a tech
világának globális közösségével. Beadhat általános jelentkezést, jelentkezhet egy konkrét
témakörre, amelyhez éppen szerzőket keresünk, vagy akár beküldheti saját ötletét is.
Írjon egy értékelést, tudassa más olvasókkal,

mit gondol
Kérjük, ossza meg másokkal gondolatait erről a könyvről: írjon egy véleményt azon
a webhelyen, ahonnan a könyvet megvásárolta. Ha a könyvet az Amazonról vásárolta,
kérjük, írjon egy őszinte véleményt a könyv Amazon-oldalára. Ez elengedhetetlen ahhoz,
hogy más potenciális olvasók is láthassák és használhassák az Ön elfogulatlan véleményét
a vásárlási döntések meghozatalához; hogy megtudhassuk, mit gondolnak vevőink
a termékeinkről; és hogy szerzőink megismerhessék a visszajelzését azzal a könyvvel
kapcsolatban, amelyet a Packttel közösen alkottak meg. Ez csupán néhány percet vesz el az
idejéből, de rendkívül értékes dolog a potenciális vásárlók, a szerzőink és a Packt számára
egyaránt. Köszönjük!
Index
A setting up 247, 248
artifactory triggers 188
A/B testing 123
artifacts
actions
connecting, to CI-CD
setting up 324, 326, 327,
pipeline 175, 176, 177
328, 330, 331, 332
AUC-ROC 111, 112
active learning models 37
automated model
Agile method
retraining 336
evolution 9, 10
automation 166
AI-centric applications 7, 8
Azure container instance (ACI)
alert 316
model, deploying on 146, 147,
analyze, Explainable Monitoring
148, 149, 150, 151, 152
Framework
Azure Container instance (ACI) 169
about 267
Azure DevOps 58
bias 269
used, for setting up CI-CD
data slicing 267, 268, 269
pipeline 168, 169
global explanations 270, 271
used, for setting up test
local explanations 270
environment 168, 169
threat detection 269
Azure Kubernetes Cluster (AKS) 169
API design 200, 201
Azure Kubernetes Service (AKS) 230
API development 200, 201
model, deploying on 153, 154,
API triggers 188
155, 156, 157, 158, 159, 160
application programming interface (API)
Azure Machine Learning SDK
about 192, 193
used, for provisioning Azure Kubernetes
testing 207, 208, 209, 210, 211
cluster for production 234, 235, 236
Area Under the Curve (AUC) 111
Azure Machine Learning workspace
Artifactory trigger
344
used, for provisioning Azure

Kubernetes cluster for
C
production 231, 232, 233, 234 CI/CD
Azure ML SDK testing 124, 125
installing 58 CI-CD pipeline
Azure ML Service artifacts, connecting to 175, 176, 177
about 54, 55 executing 185, 186, 187
resource group, creating 56 setting up, with Azure DevOps 168, 169
Azure ML service workspace testing 185, 186, 187
creating 57 CI/CD pipeline
Azure ML workspace maintaining 336, 337
extension, installing to production environment, setting
connect to 172, 173 up 237, 238, 240, 242
CI-CD pipeline, execution triggers
B about 188, 189, 190
API triggers 188
backdoor attacks 227 artifactory triggers 188
baseline datasets 285 Docker Hub triggers 188
batch testing 123 Git triggers 188
bias 119 schedule triggers 188
bias-variance trade-off method types 188
reference link 308 coefficient of determination 120
Bidirectional Encoder Representations components, of governing your ML system
from Transformers (BERT) 32 about 315
big data 7, 13 alerts and actions 315
big data ops 38, 40 model auditing and reports 333
bilingual evaluation understudy model QA and control 333
(BLEU) 114 compute resources
build module steps, MLOps pipeline configuring, for ML pipeline 82, 83, 84
model, packaging 19 confusion matrix 109, 110
model, registering 20 confusion matrix, context
model, testing 19 terms 110
model, training 18 containers 140, 141
business problem analysis 52, 54 continual learning 264
business problem, categorizing about 312, 313
about 52, 54 benefits 314
MLOps approach 53 need for 313, 314
model type 53 continuous delivery (CD)
345
about 167 missing data, calibrating 68

in MLOps 166 time series analysis 73
continuous deployment (CD) data registering 74, 75
about 168 data versioning 74, 75
in MLOps 166 deductive learning 35
continuous deployments (CD) 163 deep learning
continuous integration (CI) 163 evolution 5, 6
about 167 Deeplift 262
in MLOps 166 deployment pipeline
setting up, for test environment 174 setting up, for test environment 174
Continuous Integration/Continuous deployment targets, ML inference
Delivery (CI/CD) 217 in production
Continuous Integration/Continuous containers 140, 141
Deployment (CI/CD) 29 model streaming 143
continuous monitoring 252 serverless 142
enabling, for service 274 virtual machine 139, 140
convolutional neural network (CNN) 19 deploy module steps, MLOps pipeline
create, read, update, delete (CRUD) 199 Application Testing 21
cross-validation 106, 107 Production Release 22
DevOps method
D evolution 10
Dev Test stage
data configuring 179
ingesting, for training ML models 88, 89 distributed learning 6
data characteristics, machine learning Docker
accuracy 64 microservices, developing with 206, 207
completeness 64 Docker artifacts 129
relevance 64 Docker container 129
reliability 64 Dockerfile 129
timeliness 64 Docker Hub triggers 188
data drift 257, 284 Docker images 129
data preprocessing
about 66
data correlations 70, 72, 73
E
data, filtering 70, 72, 73 Elastic Compute Cloud 5
data quality assessment 66, 67 ensemble learning 33
Future_weather_condition 70 error rate 122
label encoding 68, 69 errors
346
dealing with 316, 318, 319, Generative Adversarial

320, 321, 322, 323 Networks (GANs) 32
evasion attack 226 Git triggers 188
Explainable AI governance audit 335
about 260 govern, Explainable Monitoring
explainability 263 Framework
model transparency 263 about 271
Explainable Monitoring 263, 264 actions 272
explainable monitoring framework alerts 271
implementation, issues and model auditing and reporting 273
solution 281, 282 quality assurance and control
implementing 281, 282, 283, 284 mechanism 272
Explainable Monitoring Framework
about 264
analyze 267
H
monitor module 265 hands-on deployment and inference
Extensible Markup language testing 217, 218, 219, 220,
string (XML) 139 221, 222, 223, 224
extract, transform, and load (ETL) 18 hands-on implementation of serving 199
hands-on ML model as API 199
F high bias 120
high-performance computing (HPC) 7
False Positive Rate (FPR=FPFP+TN) 111 human biases 121
FastAPI human biases, types
reference link 199 interaction bias 121
feature attribution methods latent bias 121
about 261 selection bias 122
Integrated Gradients 261 human-centered reinforcement
Local Interpretable Model-Agnostic learning models 36
Explanation (LIME) 261, 262 Human in the loop (HITL) models 104
SHapley Additive exPlanations Human-In-The-Loop (HITL) models
(SHAP) 261 about 29
feature drift 257, 285 active learning models 37
federated learning 34 human-centered reinforcement
f-score 108 learning models 36, 37
Future_weather_condition 70 Human in the loop (HITL)
models, metrics
G about 121
347
human bias 121 inference ready models 130

optimal policy 122 infrastructure
rate of automation 122 evolution 4, 5
risk rate 122 input attack 226
human test Integrated Gradients 261
versus machine test 114 interactive reinforcement learning 36
human, versus machine test interpretability metrics 104
bilingual evaluation understudy
(BLEU) 114
Recall-Oriented Understudy for
J
Gisting Evaluation (ROUGE) 115 JavaScript Object Notation (JSON) 139
hybrid MLOps 38, 41 JupyterHub 60
hybrid models
about 29, 31
ensemble learning 33
K
federated learning 34 K-fold cross-validation 107
multi-instance learning 32
multitask learning 32
reinforcement learning 32
L
self-supervised learning 32 label encoding 68, 69
semi-supervised learning 31 large-scale data ops 38
transfer learning 33 large-scale MLOps 41, 42
hybrid models, metrics learning models 30
about 114 about 29
human test, versus machine test 114 metrics 105
human, versus machine test 115 learning models, types
hyperparameter supervised learning models 30
optimizing 92 unsupervised learning models 30
Light Gradient boosting model
I (LightGBM) 118
Local Interpretable Model-Agnostic
implementation roadmap for MLOps Explanation (LIME) 261, 262
based solution, phases low bias 120
about 42
ML development 43
operations 44
M
transition to operations 44 machine learning
inductive learning 35 data quality 64, 65, 66
348
evolution 5, 6 ML in research, versus ML in production

training 92 about 136
Machine Learning 172 data 136, 137
Machine Learning (ML) 192 fairness 137
machine test interpretability 138
versus human test 114 performance 138
manual model priority 139
retraining 336 ML model evaluation 104
Matthews Correlation Coefficient ML model inference 132
(MCC) 112 ML models
mean 119 maintaining, in production 276
metrics monitoring, in production 276
defining 96 serving, as batch service 278, 279
microservices serving, in production 276
about 193, 194 serving modes, exploring 277, 278
developing, with Docker 206, 207 serving, to human user 279
microservices, using for machine learning serving, to machine 280, 281
about 195 training, with data ingestion 88, 89
hypothetical use case 195 training, with training dataset 90, 91
POC, for hypothetical use case 195, 196 ML models, packaging reasons
production ready application, for about 125
hypothetical case 196, 197 deployment agnosticity 126
mimic explainer 118 inference 126
missing data interoperability 126
calibrating 68 portability 125
ML adoption, trends ML models, packaging ways
in software development 13 about 126
ML application, securing containerizing 128
need for 214 microservice deployment 129
ML application, testing microservice generation 129
need for 214 packetizing 128
Mlflow serialized file 127
installing 54 ML models, testing with new data
MLflow 54 guidelines 333
used, for deploying service 161, 162 ML models types, categories
ML inference, in production Human-In-The-Loop (HITL) 29
deployment targets 139 learning models 29
types 139 statistical models 29
349
ML Operations setting up 54
reporting system 333 MLOps tools 47
MLOps 14, 15 Azure DevOps 58
characterizing 37 Azure ML Service 55
concepts 16 JupyterHub 60
continuous delivery (CD) 166 setting up 54
continuous deployment (CD) 166 MLOps tools, for business
continuous integration (CI) 166 problems implementation
intersection 14 Azure ML Service 53
MLOps based solution MLflow 53
implementation roadmap 42 MLOps workflow 16, 17
MLOps, characteries about 263
about 38 MLOps workflow, modules
big data ops 40 Drivers 24
hybrid MLOps 41 MLOps pipeline 16
large-scale MLOps 41, 42 ML pipeline
small data ops 39 basics 80, 81
MLOps, data scales compute resources, configuring
big-scale data 38 for 82, 83, 84
medium-scale data 38 data ingestion 88, 89, 90
small-scale data 38 implementing 85, 86, 87, 88
MLOps drivers model packaging 97, 98
about 16 model testing 96
artifacts 25 ML solution
code 25 securing, by design 224, 225
data 25 testing, by design 214
infrastructure 26 ML solution development process 28
middleware 26 ML solution, testing by design concepts
MLOps implementation data testing 214, 215
data, procuring 45, 46 deployment testing 217
requirements, procuring 46, 47 inference testing 217
MLOps infrastructures 47 model testing 215
MLOps pipeline pre-training tests 216
about 16 pro-training tests 216
build module 17, 18 ML system
deploy module 20 analyzing 307
monitor module 22 application performance 304, 306, 307
MLOps resources bias and threat, detecting 308
350
data drift monitor, creating 293, 294, model packaging 97, 98

295, 296, 297, 298, 299, 301 Model QA 333
data integrity 284 model retraining
data, slicing 307 enabling 335
global explanations 308 model streaming 143, 144
governing 308 model testing 96
local explanations 308 model transparency 258
model drift, monitoring 302, 303 model trust and explainability,
monitoring 284 components
monitoring, principles 256 model bias 258
target dataset, registering 285, model compilance 259
287, 289, 290, 291, 293 model drift 257
ML system, attack types model transparency 258
about 225 monitor module, Explainable
backdoor attacks 227 Monitoring Framework
evasion attack 226 about 265
input attack 226 application performance 266
poisoning attack 225 data integrity 265
reverse engineering 226 model drift 266
ML workspace monitor module steps, MLOps pipeline
connecting to 131 analyze 23
model govern 24
deploying, on ACI 146, 147, monitor 22, 23
148, 149, 150, 151, 152 Moore’s law 5, 7
deploying, on Azure Kubernetes multi-instance learning 32
Service (AKS) 153, 154, multitask learning 32
155, 157, 158, 159, 160
model artefacts
importing 131
N
model artifacts natural language explanations (NLE) 262
loading, for inference 131 non-feature attribution methods
model audit 333, 334 about 262
model bias 258 Deeplift 262
model compliance natural language explanations
about 259 (NLE) 262
drivers 259
model drift 23, 257
model evaluation 104
351
O version control 62
production artifacts
one-hot encoding 69 registering 100, 101, 102
OpenAPI Specification (OAS) 209 production environment
OpenOPI setting up, in CI/CD pipeline
reference link 199 237, 238, 240, 242
optimal policy 122 production infrastructure
setting up 230
P production-ready pipeline
testing 243, 244
Pearson correlation coefficient 70 production testing, methods
Permutation Feature Importance about 122
(PFI) 119 A/B testing 123
pipeline release management 250, 251 batch testing 123
pipeline triggers, configuring CI/CD, testing 124, 125
for automation shadow test 124
about 245 stage test 124
Artifactory trigger, setting up 247, 248 project audit 335
Git trigger, setting up 246 proof of concept (POC) 195
Schedule trigger, setting up 248, 249 Proof of Concept (PoC) 166
PoC (Proof of Concept) 163 purity 113
poisoning attack, ways
algorithm poisoning 225
dataset poisoning 225
Q
model poisoning 225 Quality Assurance (QA) 249
precision 107
principles of source code
management, for ML
R
about 60 rand index 113
clean code 61 Random Forest classifier
code readability 63 about 94
commenting and documentation 64 testing 97
error handling 62 training 94, 95
logging 62 Random Forest model
modularity 60 reference link 94
single task dedicated functions 61 rate of automation 122
structuring 61 Read and Docs
testing 61 URL 64
352
real-life business problem 48, 49 service

recall 108 continuous monitoring, enabling for 274
Recall-Oriented Understudy for Gisting defining, with MLflow 161, 162
Evaluation (ROUGE) 115 Service-Oriented Architecture (SOA) 193
Receiver Operating Characteristic service principal
(ROC) 111 creating 169, 171
recurrent neural network shadow test 124
(RNN) model 270 Shapley additive explanations (SHAP)
regret 116 about 117
reinforcement learning 32 working 117
reinforcement learning models 116 SHapley Additive exPlanations
remote procedure call (RPC) 193 (SHAP) 261
representational state transfer (REST) 198 silhouette coefficient 114
Representational State Transfer Simple Object Access Protocol
(REST) 193 (SOAP) 193
requirement.txt file small data ops 38, 39
code 206 small team ops 53
resource group, creating 56 software development
REST API based microservices 198, 199 evolution 4, 5, 8
return 116 ML adoption, trends 13
reverse engineering 226 solution
risk rate 122 infrastructure, mapping of 145
ROC curve 111 solutions
root mean square error (RMSE) 120 deploying 146
r-squared 120 stage test 124
standard deviation 119
S statistical models
about 29, 34
Schedule trigger deductive learning 35
setting up 248, 249 inductive learning 35
schedule triggers 188 transductive learning 35
self-supervised learning 32 statistical models, metrics
semi-supervised learning 31 about 119
serialized Random Forest Classifier model bias 119
registering 99, 100 mean 119
serialized Support Vector classifier model root mean square error (RMSE) 120
registering 99 r-squared 120
serverless computing 142 standard deviation 119
353
variance 120 transductive learning 35

stream processing 144 transfer learning 33
supervised learning models 30 True Positive Rate (TPR=TP/TP+FN) 111
supervised learning models, metrics Turing test 115
about 106 Type I error 110
AUC ROC 111, 112 Type II error 110
confusion matrix 109, 110
cross-validation 106, 107
f-score 108
U
Matthews Correlation unsupervised learning models 30
Coefficient (MCC) 112 unsupervised learning models, metrics
precision 107 about 112
recall 108 purity 113
Support Vector Classifier (SVC) 248 rand index 113
Support Vector Machine silhouette coefficient 114
reference link 92 upstream data changes 257
Support Vector Machine classifier
testing 96
Support Vector Machine (SVM) classifier
V
about 92 variables.py file
training 92, 93 code 201, 202
Swagger variance 120
URL 64 virtual machines 139
T W
target datasets 285 waterfall method
test environment 21 evolution 8
continuous integration (CI), weather_api.py file
setting up for 174 code 202, 203, 204, 206
deployment pipeline, setting up for 174
setting up 178, 179, 180, 182, 183, 184
setting up, with Azure DevOps 168, 169
Y
time series analysis 73 YAML (Yet Another Markup
traditional software development Language) 149
challenges 11, 12
training dataset
used, for training ML models 90, 91

Mérnöki MLOps

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Mérnöki MLOps

Uploaded by

Copyright:

Available Formats

Mérnöki MLOps

Gyorsan épít, tesztel és kezel nagy léptékű üzemkész

Csoport termékmenedzser: Kunal Parikh

Első kiadás: 2021. április

Kiadja a Packt Publishing Ltd.

Stephen Oladele az AgServer társalapítója, amely egy peer-to-peer tudásmegosztó

Emerson Bertolo egy adatkutató és szoftverfejlesztő, aki létrehozott egy létfontosságú

1. rész: Keretrendszer gépi tanulási

1. fázis: ML fejlesztés 43 Követelmények 46

Gépi tanulás tanítása és Modellcsomagolás  97

2. rész: Gépi tanulási modellek telepítése

Az ML következtetés típusainak A folytonos integráció

Tanítás utáni tesztek 216 Az Ön ML megoldásának

3. rész: Gépi tanulási modellek

Egyéb könyvek, amiket ajánlunk

Kinek szól a könyv?

Mit tartalmaz ez a könyv?

7. fejezet: Robosztus CI és CD folyamatok kialakítása, különböző CI/CD folyamat

Ahhoz, hogy a legtöbbet hozza ki ebből

A könyvben tárgyalt szoftver/

Ha a digitális verzióját használja ennek a könyvnek, azt javasoljuk, hogy gépelje

Töltse le a példa kódfájlokat

Töltse le a színes képeket

# Importing pre-processed dataset

A parancssori bemenetek vagy kimenetek az alábbi módon vannak szedve:

Tippel vagy fontos megjegyzések

Ez a rész megismerteti az olvasókat az MLOps és munkafolyamatok alapjaival,

• 1. fejezet: MLOps WorkFlow alapjai

Ebben a fejezetben a következő fő témákat érintjük:

• A szoftver- és infrastruktúrafejlesztés evolúciója

A gépi tanulás és mély-tanulás erősödése

Ezt az adoptációt az infrastruktúra fejlődése segítette, különösen a számítási kapacitás

1.1 ábra: A mély-tanulás kereslete az idő függvényében, a számítással támogatva

1.2 ábra: Megosztott munkaterheléseken futó alkalmazások

A HPC és MI kombinálásával elérhetővé tehetjük azokat a számítási előnyöket,

1.3 ábra: A szoftverfejlesztés evolúciója

• A teljes követelménykészletet meg kell adni a fejlesztés előtt; a projekt előrehaladása

• Kisebb az esély az újrahasználható komponensek létrehozására vagy

• A követelményeket a fejlesztés előtt határozzák meg, de bármikor módosíthatók.

A következő ábra mutatja a különbséget a vízesés és Agile módszerek között:

1.4 ábra: A különbség a vízesés és Agile módszerek között

A hagyományos szoftverfejlesztés kihívásai

1.5 ábra: Gépi tanulás = adat + kód

1.6 ábra: Az adat és kód haladása az idő múlásával

• Befektetések: 2019-ben a globális magán MI-nél a befektetések elérték a 70 milliárd

Ezek a fejlesztések az MI iparosításának erőteljes törekvését jelzik, és ez az ipar és kutatás

1.7 ábra: Az MLOps metszete

A metszet (MLOps) működésbe hozásához terveztem egy moduláris keretrendszert

1.8 ábra: Tervezéstudományi munkafolyamat

MLOps munkafolyamatai és elvei

1.9 ábra: MLOps munkafolyamat

• MLOps folyamat (kialakítás, telepítés és monitorozás: a felső réteg

A felső réteg az MLOps folyamat (kialakítás, telepítés és monitorozás), amelyet az olyan

Egy felhasználási mód megvitatása

• Adatok: Az állatsimogató hozzáférést adott az adattárolóhoz, amely 100000

Ez a felhasználási mód hasonlít az ML működésbe hozásának valós felhasználási

1.10 ábra: MLOps, kialakítási folyamat

• Adatbevitel: Ez a lépés aktiválja az ML folyamatot. Ez foglalkozik az adat

A felhasználási mód megvalósítása

• A modell regisztrációja: Ebben a lépésben az előző lépésben szerializált vagy

1.11 ábra: MLOps, telepítési folyamat

Ez is balról jobbra halad. Nézzük meg részletesen az egyes lépések működését:

• Alkalmazás tesztelése: Mielőtt telepítenénk egy ML modellt a termelésben,

• Termelési kiadás: A korábban tesztelt és jóváhagyott modelleket telepítik

1. fázis: ML fejlesztés 43 Követelmények 46

Gépi tanulás tanítása és Modellcsomagolás 97

Tanítás utáni tesztek 216 Az Ön ML megoldásának