Nyereség:
- Képes felismerni az ML speciális kihívásait a kód-adat-modell trióval és a csomaggal kapcsolatban, és a modellt online vagy kötegelt bemutatni az üzleti igényeknek megfelelően.
- Lehetőség fokozatos és visszaállítási minták megvalósítására (árnyék, kanári, A/B, visszagörgetés), és tesztelt visszaállítási terv hozzáadása minden egyes telepítéshez
- A gyártásba kerülő modell adat-kód-metrikus kapcsolatának nyomon követhetősége a kiértékelési küszöb-vezérelt CI/CD-vel és a modellnyilvántartással
Egy olyan modell beszerzése, amely 95%-os pontosságot ér el a notebookban, csak a történet fele. A másik fele – gyakran a legnehezebb – a modell megbízható, méretezhető és karbantartható módon való eljuttatása a valódi felhasználókhoz. Az MLOps (Machine Learning Operations: az ML-modellek termelésbe helyezésének, üzemeltetésének és karbantartásának tudománya) a szoftverfejlesztés DevOps gyakorlatát ötvözi az ML egyedi kihívásaival. Ebben az egységben bemutatjuk a modell gyártásba lépésének lépéseit és azt, hogy a mesterséges intelligencia hogyan segít ebben a folyamatban.
Miért különbözik az ML a hagyományos szoftverektől?
A szokásos szoftverekben a viselkedés a kódban van; Ha a kód nem változik, a viselkedés nem változik. Az ML-ben a viselkedés kódtól, adattól és modelltől is függ. Ez a három dimenzió teremti meg az MLOps extra kihívásait:
- Adatsodródás: A termelésben lévő adatok idővel eltávolodnak a képzésben lévő adatoktól; a modell elavulttá válik.
- Három dolgot kell verzióba hoznia: kód, adat és modell – mindhárom.
- Csendes meghibásodás: A modell összeomlás nélkül, hibaadás nélkül is meghibásodhat, egyszerűen hibás előrejelzések előállításával. Ennek elkapása monitorozást igényel.
Ezért van nagy különbség a „működő modell” és a „gyártásra kész modell” között.
Modell csomagolás és bemutatás
A modell gyártásba lépésének első lépése a csomagolás: a modellfájl, a szükséges könyvtárak, az előfeldolgozási kód és a verzióinformációk reprodukálható egészként. A konténerezés (pl. Docker: az alkalmazás egy elszigetelt dobozba helyezése annak minden függőségével együtt) itt szabványos; Megszünteti a "működött a gépemen" problémát.
A modell kiszolgálásának két alapvető mintája:
- Online/valós idejű (online): A modell egy API mögé ül, azonnali előrejelzést adva vissza minden bejövő kérésre. Az alacsony késleltetés kritikus.
- Kötegelt: A modell rendszeres időközönként nagy adatkészleteket dolgoz fel (pl. éjszaka pontszámokat generál minden ügyfél számára). A késleltetés lényegtelen, a hatékonyság fontos.
Hogy melyik a megfelelő, az üzleti igényektől függ: azonnali online ajánlás, havi kockázati pontszám kötegben.
Tipp: A „valós idejű” költség, nem az alapértelmezett. A köteg sokkal olcsóbb és egyszerűbb, ha az eredményt órákon belül felhasználják. Tényleg azonnali válaszra van szüksége? Ezt kérdezd meg először.
Biztonságos terjesztési stratégiák
Egy új modell közvetlen megnyitása a teljes forgalom számára kockázatos; Ha rossz, mindenki érintett. Biztonságos elosztási minták:
- Shadow deployment: Az új modell éles forgalmat kap, de előrejelzései nem jelennek meg a felhasználó számára, csak naplózzák. Összehasonlítják a régi modellel, hogy kiderüljön, biztonságos-e a valós adatokban.
- Kanári bevetés: Az új modellt először a forgalom kis százalékára (pl. 5%) vezetik be; Ha nincs probléma, fokozatosan növeljük.
- A/B tesztelés: Két modell párhuzamosan kerül bemutatásra a valós felhasználónak, és összehasonlítják az üzleti mutatókat (konverzió, kattintások).
- Visszaállítás: Gyorsan vissza lehet térni a régi verzióhoz, ha az új modell rossznak bizonyul. Minden telepítésnek rendelkeznie kell egy visszaállítási tervvel.
Vigyázat: A visszaállítási terv nélküli központi telepítés nem fejeződött be. Az, hogy perceken belül vissza lehet térni a régi verzióra, megvédi a felhasználót, ha az új modell váratlanul viselkedik a gyártás során. Tesztelje ezt a telepítés előtt.
Gyenge megközelítés / Erős megközelítés
Gyenge: "A modell jó volt a tesztelésben, élesben indultunk, mindenkinek megnyitottuk."
Güçlü: "Konténerbe helyeztük a modellt, verzióként címkéztük. Először 3 napig árnyékos módban futtattuk, éles forgalommal, összehasonlítva az előrejelzéseket a régi modellel – az eltérés elfogadható volt. Aztán megnyitottuk 5%-os kanárival, figyeltük az áteresztőképességi mutatókat és a késleltetést. Amikor nem volt probléma, fokozatosan 100%-ra növeltük a visszagörgetést."
A különbség: az erős megközelítés fokozatos, mért és visszafordítható. A kockázat minden lépésben korlátozott.
CI/CD és automatizálás
A CI/CD (Continuous Integration / Continuous Deployment: a kód automatikus tesztelésének és kiadásának folyamata) az ML-ben nem csak a kódot fedi le, hanem az adatok és a modell lépéseit is. Egy jó ML CI/CD folyamat: teszteket futtat, ha a kód megváltozik, elvégzi az adatok érvényesítését, újratanítja a modellt (ha szükséges), ellenőrzi a kiértékelési küszöbértékeket, és csak akkor viszi előre a telepítést, ha a küszöbértékek érvényesek. Az „a képzés automatikus, a bevezetés küszöb alapú” elve megakadályozza, hogy a rossz modell csendben kiszivárogjon a gyártásba.
Az AI nagyon hasznos ezeknek a folyamatoknak a beállításakor: konfigurációs fájl (YAML) vázlatok, tesztesetek, telepítési szkriptek írása. De Ön határozza meg az elosztási küszöbértékeket (bármilyen mérőszám meghaladja a közzétett értéket) és a visszaállítási irányelvet; ezek üzleti kockázati döntések.
Reprodukálhatósági infrastruktúra
Egy modell működésének reprodukálása érdekében a modellnyilvántartás: egy rekord, amely megőrzi, hogy melyik modellt milyen adatokkal és kódokkal betanították, és milyen mérőszámokat kapott. Minden éles modell esetében a következőknek kell nyomon követhetőnek lenniük: betanítási adatok verziója, kódverzió (git commit), hiperparaméterek, értékelési pontszámok és telepítési dátum. Ha probléma merül fel, meg kell tudni válaszolni a kérdést: "melyik modell hozta létre ezt az előrejelzést, milyen adatokkal?" perceken belül. Ezt elmélyítjük a 11. egységben.
három mini tok
1. eset – A problémát az árnyékeloszlás fogta el. Egy ajánlási modell felülmúlta a régit a tesztelés során. Az éles forgalom árnyék módban történő futtatása nagyon gyenge ajánlásokat eredményezett a felhasználók egy bizonyos szegmensére (új felhasználókra) – a tesztadatok alulreprezentáltak ezt a szegmenst. A modellt anélkül javították, hogy valaha is megjelenítették volna a felhasználó számára. Ha közvetlenül megnyitná, az új felhasználói élmény megszakadna.
2. eset – Visszavonhatatlan elosztás. Egy csapat új árazási modellt vezetett be a teljes forgalom számára, visszavonási tervek nélkül. A modell néhány terméket váratlanul nagyon olcsón árazott. A régi verzióra való visszaállítás órákig tartott, mert a folyamat nem volt kész. Komoly bevételkiesés történt. Ezt követően minden telepítéshez kötelező visszaállítási tesztet adtunk.
3. eset – Csendes adatsodródás. A csalási minta hónapokig hiba nélkül jelent meg. Ám a csalók taktikája megváltozott (adatsodródás), és a modell visszahívása csendben lecsökkent. Senki nem vette észre, mert nem volt megfigyelés. Miután létrehoztak egy előrejelzési eloszlást figyelő panelt, a sodródás korán láthatóvá vált. A megfigyelést a 8. egységben fogjuk kitérni.
Másolható sablonok
Írjon egy telepítési tervet ehhez a modellhez. Modell: [mit csinál], használat: [online vagy kötegelt?] Tartalmaznia kell: 1) Csomagolás (tároló, verziószámítás) 2) Növekményes telepítési stratégia (árnyék/kanári/A-B) és miért3) Nyomon követendő mutatók (üzleti + technikai + késleltetés) 4) Visszaállítási terv és a tesztelés módja5) A telepítési határértékek mekkora értéket kell meghaladniuk (hol)
Ellenőrizze ezt az ML CI/CD folyamatot:1) Az adatok érvényesítése a sorban?2) Folytatódhat a telepítés az értékelési küszöb betartása nélkül (nem szabad)?3) Automatikus a visszagörgetés?4) Nyomon követik az adatokat+kódot+metrikákat a modellnyilvántartásban?Pline konfiguráció: [config]
Segítsen eldönteni, hogy az online vagy a kötegelt prezentáció megfelelő-e ehhez a modellhez. Meddig lesz felhasználva az eredmény: [azonnali / perc / óra / nap]Várható kérés mennyisége: [szám]Van-e késleltetési megkötés: [ms]Költség és összetettség szempontjából melyiket javasolná, és miért?
Írjon visszaállítási eljárást ehhez a modellhez.- Milyen mérőszám/küszöb vált ki gyenge teljesítményt?- Mik a visszaállítás lépései?- Mennyi ideig tartson a visszaállítás (cél)?- Hogyan tesztelhetem ezt az eljárást a gyártás előtt?
Bemutató minta táblázat
kritérium
Online (valós idejű)
Batch
késleltetés
Kritikus (ms)
jelentéktelen
Használat
Azonnali válasz szükséges
Periodikus pontszám
Költség
magas
alacsony
összetettsége
magas
alacsony
példa
Élő ajánlás, átverés
Havi kockázati pontszám
Gyakori hibák
- Terjesztés előhívási terv nélkül. A rossz modell az egész felhasználót érinti.
- Közvetlenül a 100%-os forgalom előtt. Korlátozza a kockázatot lépcsőzetes elosztással.
- Nem hoz létre felügyeletet. A modell hibátlanul, hiba nélkül produkál hibákat.
- Redundáns valós idejű prezentáció. Míg a kötegelés elegendő, a költségek és a bonyolultság megnövekszik.
- Nem kapcsolja össze a modell-adat-kód verziókat. Nem reprodukálhatja a problémát.
- Automatikus kiadás terjesztési küszöb nélkül. A rossz modell némán besurran.
Összefoglalva
A modell gyártásba helyezése más és gyakran nehezebb mérnöki feladat, mint a betanítás. Az ML extra fegyelmet igényel, mert a kód-adat-modell hármastól függ: csomagolás és verziókészítés, az üzleti igényeknek megfelelő szállítási minta (online/kötegelt), fokozatos és visszafordítható telepítés, küszöb-vezérelt CI/CD és modell regisztráció. A mesterséges intelligencia hatékony segítség az infrastruktúra kódjának és konfigurációjának létrehozásában; de az elosztási küszöbök, a visszakövetelési politika és a kockázati döntések az Öné. A visszaállítási terv nélküli terjesztés nem teljes.
Pályázati feladat
Tegye konténerbe (Docker) egy modellt, és címkézze fel a verziót. Döntse el, hogy online vagy kötegelt kínál-e az üzleti igényei alapján, és írja meg az indoklást. Dokumentáljon egy szakaszos telepítési tervet (árnyékos vagy kanári) és egy tesztelt visszaállítási eljárást. Ügyeljen arra, hogy rögzítse az adatok verzióját, a kód véglegesítését és az értékelési pontszámokat a modellnyilvántartásban.
ellenőrző lista
- [ ] A modell csomagolt és verziószámmal rendelkezik (tároló + címke).
- [ ] A prezentációs mintát (online/kötegelt) az üzleti igényeknek megfelelően választottuk ki.
- [ ] Szakaszos telepítési stratégia (árnyék/kanári) végrehajtva.
- [ ] Visszagörgetési eljárás megírva és tesztelve.
- [ ] A CI/CD nem viszi előre a telepítést az értékelési küszöb elérése előtt.
- [ ] A modellnyilvántartás tartalmazza az adat+kód+metrikus hivatkozást.