MLOps-munkafolyamatok az Azure Databricksben

Ez a cikk azt ismerteti, hogyan használható az MLOps a Databricks platformon a gépi tanulási (ML) rendszerek teljesítményének és hosszú távú hatékonyságának optimalizálásához. Általános javaslatokat tartalmaz az MLOps-architektúrához, és egy általános munkafolyamatot ír le a Databricks platform használatával, amelyet modellként használhat az ml-fejlesztés éles folyamatához.

További részletekért lásd az MLOps nagy könyvét.

Mi az az MLOps?

Az MLOps folyamatokat és automatizált lépéseket tartalmaz a kód, az adatok és a modellek kezeléséhez. Egyesíti a DevOps, a DataOps és a ModelOps funkcióit.

Az ml-eszközök, például a kód, az adatok és a modellek olyan fázisokban vannak kifejlesztve, amelyek a korai fejlesztési szakaszoktól kezdve nem rendelkeznek szigorú hozzáférési korlátozásokkal, és amelyeket nem tesztelnek szigorúan egy köztes tesztelési szakaszon keresztül egy szigorúan ellenőrzött végső éles fázisba. A Databricks platform lehetővé teszi, hogy ezeket az eszközöket egyetlen platformon, egységes hozzáférés-vezérléssel kezelje. Ugyanazon a platformon fejleszthet adatalkalmazásokat és ml-alkalmazásokat, csökkentve az adatok áthelyezésével járó kockázatokat és késéseket.

Az MLOps általános ajánlásai

Ez a szakasz néhány általános javaslatot tartalmaz az MLOps on Databricks szolgáltatásra vonatkozóan, és további információkra mutató hivatkozásokat tartalmaz.

Külön környezet létrehozása minden fázishoz

A végrehajtási környezet az a hely, ahol a modelleket és az adatokat kód hozza létre vagy használja fel. Minden végrehajtási környezet számítási példányokból, futtatókörnyezetekből és kódtárakból, valamint automatizált feladatokból áll.

A Databricks azt javasolja, hogy hozzon létre külön környezeteket az ML-kód és a modellfejlesztés különböző szakaszaihoz, világosan meghatározott átmenetekkel a szakaszok között. A cikkben ismertetett munkafolyamat ezt a folyamatot követi a szakaszok gyakori neveinek használatával:

• Fejlesztés
• Átmeneti
• Éles

Más konfigurációk is használhatók a szervezet adott igényeinek kielégítésére.

Hozzáférés-vezérlés és verziószámozás

A hozzáférés-vezérlés és a verziószámozás minden szoftverműveleti folyamat kulcsfontosságú összetevői. A Databricks a következőket javasolja:

• A Git használata verziókövetéshez. A folyamatokat és a kódot a Gitben kell tárolni a verziókövetéshez. Az ML-logika fázisok közötti áthelyezése ezután úgy értelmezhető, hogy a kód a fejlesztési ágból az előkészítési ágba, a kiadási ágba kerül. A Databricks Git-mappákkal integrálhatja a Git-szolgáltatót, és szinkronizálhatja a jegyzetfüzeteket és a forráskódot a Databricks-munkaterületekkel. A Databricks további eszközöket is biztosít a Git-integrációhoz és a verziókövetéshez; lásd Fejlesztői eszközök és útmutatást.
• Adatok tárolása egy lakehouse-architektúrában Delta-táblák használatával. Az adatokat egy lakehouse-architektúrában kell tárolni a felhőfiókban. A nyers adatokat és a funkciótáblákat egyaránt Delta-táblákként kell tárolni, amelyek hozzáférés-vezérléssel határozzák meg, hogy ki olvashatja és módosíthatja őket.
• Modellfejlesztés kezelése az MLflow használatával. Az MLflow használatával nyomon követheti a modellfejlesztési folyamatot, és mentheti a kód pillanatképeit, modellparamétereit, metrikáit és egyéb metaadatait.
• A Modellekkel a Unity Katalógusban kezelheti a modell életciklusát. Modellek használata a Unity Katalógusban a modellek verziószámozásának, szabályozásának és üzembe helyezésének állapotának kezeléséhez.

Kód üzembe helyezése, nem modellek

A legtöbb esetben a Databricks azt javasolja, hogy az ml-fejlesztési folyamat során a kódot a modellek helyett az egyik környezetből a másikba léptesse elő. A projektegységek ilyen módon történő áthelyezése biztosítja, hogy az ml-fejlesztési folyamat összes kódja ugyanazon a kódellenőrzési és integrációs tesztelési folyamaton megy keresztül. Emellett biztosítja, hogy a modell éles verziója éles kóddal legyen betanítve. A lehetőségek és a kompromisszumok részletesebb ismertetését a modell üzembehelyezési mintáiban találja.

Ajánlott MLOps-munkafolyamat

A következő szakaszok egy tipikus MLOps-munkafolyamatot írnak le, amely a három fázis mindegyikére kiterjed: fejlesztés, előkészítés és éles környezet.

Ez a szakasz az "adatelemző" és az "ML-mérnök" kifejezést használja archetikus személyként; az MLOps-munkafolyamat adott szerepkörei és feladatai csapatok és szervezetek között eltérőek lesznek.

Fejlesztési fázis

A fejlesztési szakasz középpontjában a kísérletezés áll. Az adattudósok funkciókat és modelleket fejlesztenek, és kísérleteket futtatnak a modell teljesítményének optimalizálásához. A fejlesztési folyamat kimenete az ML-folyamat kódja, amely magában foglalhatja a funkciószámítást, a modell betanítását, a következtetést és a monitorozást.

A számozott lépések a diagramon látható számoknak felelnek meg.

1. Adatforrások

A fejlesztési környezetet a Unity Catalog fejlesztői katalógusa képviseli. Az adattudósok olvasási-írási hozzáféréssel rendelkeznek a fejlesztői katalógushoz, mivel ideiglenes adatokat és funkciótáblákat hoznak létre a fejlesztési munkaterületen. A fejlesztési szakaszban létrehozott modellek regisztrálva vannak a fejlesztői katalógusban.

Ideális esetben a fejlesztői munkaterületen dolgozó adattudósok írásvédett hozzáféréssel rendelkeznek az éles adatokhoz a prod katalógusban. Ha lehetővé teszi az adatelemzők számára az éles adatokhoz, a következtetési táblákhoz és a metrikatáblákhoz való hozzáférést a prod katalógusban, lehetővé teszi számukra az aktuális éles modell előrejelzéseinek és teljesítményének elemzését. Az adattudósoknak képesnek kell lenniük arra is, hogy éles modelleket töltsenek be kísérletezésre és elemzésre.

Ha nem lehet írásvédett hozzáférést biztosítani a prod katalógushoz, az éles adatok pillanatképe a fejlesztői katalógusba írható, hogy az adatelemzők fejleszthessék és értékelhessék a projektkódot.

2. Feltáró jellegű adatelemzés (EDA)

Az adattudósok egy interaktív, iteratív folyamat során tárják fel és elemzik az adatokat jegyzetfüzetek használatával. A cél annak felmérése, hogy a rendelkezésre álló adatok képesek-e megoldani az üzleti problémát. Ebben a lépésben az adatelemző megkezdi a modellbetanítás adatelőkészítési és featurizálási lépéseinek azonosítását. Ez az alkalmi folyamat általában nem része olyan folyamatnak, amelyet más végrehajtási környezetekben fognak üzembe helyezni.

A Databricks AutoML felgyorsítja ezt a folyamatot azáltal, hogy alapmodelleket hoz létre egy adatkészlethez. Az AutoML próbaidőszakokat hajt végre és rögzít, és egy Python-jegyzetfüzetet biztosít az egyes próbaidőszakok forráskódjával, így áttekintheti, reprodukálhatja és módosíthatja a kódot. Az AutoML emellett kiszámítja az adathalmaz összesítő statisztikáit, és ezeket az információkat egy áttekinthető jegyzetfüzetbe menti.

3. Kód

A kódtár tartalmazza az ML-projekt összes folyamatát, modulját és egyéb projektfájlját. Az adattudósok új vagy frissített folyamatokat hoznak létre a projektadattár fejlesztési ("dev") ágában. Az EDA-tól és a projekt kezdeti fázisaitól kezdve az adatelemzőknek egy adattárban kell dolgozniuk a kód megosztásához és a változások nyomon követéséhez.

4. Modell betanítása (fejlesztés)

Az adattudósok fejlesztési környezetben fejlesztik a modell betanítási folyamatát a fejlesztői vagy a fejlesztői katalógusokból származó táblák használatával.

Ez a folyamat 2 feladatot tartalmaz:

• Betanítás és hangolás. A betanítási folyamat naplózza a modellparamétereket, metrikákat és összetevőket az MLflow Tracking-kiszolgálón. A hiperparaméterek betanítása és finomhangolása után a rendszer naplózza a végső modellösszetevőt a nyomkövetési kiszolgálóra a modell, a betanított bemeneti adatok és a létrehozáshoz használt kód közötti kapcsolat rögzítéséhez.

• Kiértékelés. Értékelje ki a modell minőségét a visszatartott adatok tesztelésével. Ezeknek a teszteknek az eredményeit a rendszer naplózza az MLflow Tracking-kiszolgálóra. Az értékelés célja annak meghatározása, hogy az újonnan kifejlesztett modell jobban teljesít-e, mint a jelenlegi üzemi modell. A megfelelő engedélyek birtokában a prod katalógusban regisztrált összes éles modell betölthető a fejlesztési munkaterületre, és összehasonlítható egy újonnan betanított modellel.

  Ha a szervezet szabályozási követelményei további információkat tartalmaznak a modellről, mentheti az MLflow-nyomkövetés használatával. A tipikus összetevők egyszerű szöveges leírások és modellértelmezések, például az SHAP által létrehozott diagramok. A konkrét szabályozási követelmények az adatszabályozási tisztviselőtől vagy az üzleti érdekelt felektől származhatnak.

A modell betanítási folyamatának kimenete egy ml-modellösszetevő, amely a fejlesztési környezet MLflow Tracking-kiszolgálójában van tárolva. Ha a folyamat az előkészítési vagy éles munkaterületen van végrehajtva, a modellösszetevő az adott munkaterület MLflow Tracking-kiszolgálójában lesz tárolva.

Ha a modell betanítása befejeződött, regisztrálja a modellt a Unity Catalogban. Állítsa be a folyamatkódot úgy, hogy regisztrálja a modellt annak a környezetnek megfelelő katalógusban, amelyben a modellfolyamatot végrehajtották; ebben a példában a fejlesztői katalógust.

Az ajánlott architektúrával üzembe helyezhet egy többfeladatos Databricks-munkafolyamatot, amelyben az első feladat a modellbetanítási folyamat, majd a modellérvényesítési és modelltelepítési feladatok. A modellbetanítási tevékenység olyan modell URI-t eredményez, amelyet a modellérvényesítési tevékenység használhat. A tevékenységértékek használatával továbbíthatja ezt az URI-t a modellnek.

5. Modell ellenőrzése és üzembe helyezése (fejlesztés)

A modell betanítási folyamatán kívül más folyamatokat is fejlesztenek, például a modellérvényesítést és a modelltelepítési folyamatokat a fejlesztési környezetben.

• Modell érvényesítése. A modellérvényesítési folyamat a modell betanítási folyamatából veszi át a modell URI-t, betölti a modellt a Unity Catalogból, és érvényesítési ellenőrzéseket futtat.

  Az érvényesítési ellenőrzések a környezettől függenek. Ilyenek lehetnek például az alapvető ellenőrzések, például a formátum és a szükséges metaadatok megerősítése, valamint a szigorúan szabályozott iparágak esetében esetleg szükséges összetettebb ellenőrzések, például az előre meghatározott megfelelőségi ellenőrzések és a modell teljesítményének megerősítése a kiválasztott adatszeleteken.

  A modellérvényesítési folyamat elsődleges funkciója annak meghatározása, hogy a modellnek folytatnia kell-e az üzembe helyezési lépést. Ha a modell megfelel az üzembe helyezés előtti ellenőrzéseknek, hozzárendelhető a "Challenger" aliashoz a Unity Catalogban. Ha az ellenőrzések sikertelenek, a folyamat véget ér. A munkafolyamatot úgy konfigurálhatja, hogy értesítse a felhasználókat az érvényesítési hibáról. Lásd: E-mail- és rendszerértesítések hozzáadása feladateseményekhez.

• Modell üzembe helyezése. A modell üzembehelyezési folyamata általában közvetlenül előlépteti az újonnan betanított "Challenger" modellt "Champion" állapotra aliasfrissítéssel, vagy megkönnyíti a meglévő "Champion" modell és az új "Challenger" modell összehasonlítását. Ez a folyamat bármilyen szükséges következtetési infrastruktúrát is beállíthat, például modellkiszolgáló végpontokat. A modelltelepítési folyamat lépéseinek részletes ismertetését az Éles környezet című témakörben találja.

6. Kód véglegesítése

A betanítási, érvényesítési, üzembehelyezési és egyéb folyamatok kódjának fejlesztése után az adatelemző vagy az ML-mérnök véglegesíti a fejlesztési ág módosításait a forráskövetésben.

Előkészítési szakasz

Ennek a fázisnak a középpontjában az ML-folyamat kódjának tesztelése áll, hogy biztosan készen álljon az éles üzemre. Ebben a szakaszban az ml-folyamat összes kódját teszteljük, beleértve a modell betanítására szolgáló kódot, valamint a funkciótervezési folyamatokat, a következtetési kódot stb.

Az ML mérnökei létrehoznak egy CI-folyamatot az ebben a szakaszban futtatott egység- és integrációs tesztek implementálásához. Az előkészítési folyamat kimenete egy kiadási ág, amely elindítja a CI/CD rendszert az éles fázis elindításához.

1. Adatok

Az előkészítési környezetnek saját katalógussal kell rendelkeznie a Unity Katalógusban az ML-folyamatok teszteléséhez és a modellek Unity Catalogban való regisztrálásához. Ez a katalógus a diagram "előkészítési" katalógusaként jelenik meg. A katalógusba írt objektumok általában ideiglenesek, és csak a tesztelés befejezéséig maradnak meg. A fejlesztési környezet hibakeresési célokból hozzáférést is igényelhet az előkészítési katalógushoz.

2. Kód egyesítése

Az adattudósok a fejlesztési környezetben fejlesztik a modell betanítási folyamatát a fejlesztési vagy éles katalógusokból származó táblák használatával.

• Lekéréses kérelem. Az üzembe helyezési folyamat akkor kezdődik, amikor lekéréses kérelem jön létre a projekt fő ágán a forrásvezérlőben.

• Egységtesztek (CI). A lekéréses kérelem automatikusan létrehozza a forráskódot, és elindítja az egységteszteket. Ha az egységtesztek sikertelenek, a rendszer elutasítja a lekéréses kérelmet.

  Az egységtesztek a szoftverfejlesztési folyamat részét képezik, és minden kód fejlesztése során folyamatosan végrehajtják és hozzáadják a kódbázishoz. Az egységtesztek CI-folyamat részeként történő futtatása biztosítja, hogy a fejlesztési ágban végrehajtott módosítások ne szegik meg a meglévő funkciókat.

3. Integrációs tesztek (CI)

A CI-folyamat ezután futtatja az integrációs teszteket. Az integrációs tesztek az összes folyamatot futtatják (beleértve a funkciófejlesztést, a modell betanítását, a következtetést és a monitorozást) annak biztosítása érdekében, hogy megfelelően működjenek együtt. Az előkészítési környezetnek a lehető legközelebb kell illeszkednie az éles környezethez.

Ha valós idejű következtetéssel helyez üzembe egy ML-alkalmazást, az előkészítési környezetben létre kell hoznia és tesztelnie kell a kiszolgáló infrastruktúrát. Ez magában foglalja a modell üzembehelyezési folyamatának aktiválását, amely létrehoz egy kiszolgáló végpontot az előkészítési környezetben, és betölt egy modellt.

Az integrációs tesztek futtatásához szükséges idő csökkentése érdekében bizonyos lépések a tesztelés megbízhatósága és a sebesség és a költségek közötti kompromisszumot jelenthetik. Ha például a modellek költségesek vagy időigényesek a betanításhoz, előfordulhat, hogy kis adathalmazokat használ, vagy kevesebb betanítási iterációt futtat. A modellszolgáltatáshoz az éles követelményektől függően teljes körű terheléstesztelést hajthat végre az integrációs tesztekben, vagy csak kis kötegelt feladatokat vagy kéréseket tesztelhet egy ideiglenes végponton.

4. Egyesítés az előkészítési ághoz

Ha minden teszt sikeres, az új kód egyesül a projekt fő ágával. Ha a tesztek sikertelenek, a CI/CD rendszernek értesítenie kell a felhasználókat, és közzé kell tennie az eredményeket a lekéréses kérelemben.

Rendszeres integrációs teszteket ütemezhet a fő ágon. Ez akkor hasznos, ha az ágat gyakran frissítik több felhasználó egyidejű lekéréses kéréseivel.

5. Kiadási ág létrehozása

A CI-tesztek elvégzése és a fejlesztői ág fő ágba való egyesítése után az ML-mérnök létrehoz egy kiadási ágat, amely aktiválja a CI/CD rendszert az éles feladatok frissítéséhez.

Éles fázis

Az ml-mérnököké az az éles környezet, ahol az ML-folyamatok üzembe helyezése és végrehajtása történik. Ezek a folyamatok elindítják a modell betanítását, új modellverziók érvényesítését és üzembe helyezését, előrejelzések közzétételét az alsóbb rétegbeli táblákban vagy alkalmazásokban, valamint a teljes folyamatot figyelik a teljesítménycsökkenés és az instabilitás elkerülése érdekében.

Az adattudósok általában nem rendelkeznek írási vagy számítási hozzáféréssel az éles környezetben. Fontos azonban, hogy láthatóak legyenek az eredmények, a naplók, a modellösszetevők, az éles folyamat állapota és a figyelési táblák teszteléséhez. Ez a láthatóság lehetővé teszi számukra az éles környezetben felmerülő problémák azonosítását és diagnosztizálását, valamint az új modellek teljesítményét az éles környezetben lévő modellekkel való összehasonlításhoz. Ezekhez a célokhoz csak olvasási hozzáférést biztosíthat az adatelemzőknek az éles katalógusban lévő objektumokhoz.

A számozott lépések a diagramon látható számoknak felelnek meg.

1. Modell betanítása

Ezt a folyamatot kódmódosítások vagy automatikus újratanítási feladatok aktiválhatják. Ebben a lépésben az éles katalógusból származó táblákat a következő lépésekhez használjuk.

• Betanítás és hangolás. A betanítási folyamat során a rendszer rögzíti a naplókat az éles környezet MLflow Tracking-kiszolgálójának. Ezek a naplók modellmetrikákat, paramétereket, címkéket és magát a modellt tartalmazzák. Ha funkciótáblákat használ, a rendszer a Databricks Feature Store-ügyféllel naplózza a modellt az MLflow-ba, amely a modellt a következtetési időpontban használt funkciókeresési adatokkal csomagolja be.

  A fejlesztés során az adattudósok számos algoritmust és hiperparamétert tesztelhetnek. Az éles betanítási kódban gyakori, hogy csak a legjobban teljesítő lehetőségeket veszi figyelembe. Az ily módon történő hangolás korlátozása időt takarít meg, és csökkentheti az automatizált újratanítás finomhangolásának varianciáját.

  Ha az adattudósok írásvédett hozzáféréssel rendelkeznek az éles katalógushoz, lehet, hogy meg tudják határozni a modell optimális hiperparaméter-készletét. Ebben az esetben az éles környezetben üzembe helyezett modellbetanítási folyamat a kiválasztott hiperparaméter-készlettel hajtható végre, amely általában konfigurációs fájlként szerepel a folyamatban.

• Kiértékelés. A modellminőség kiértékelése a visszatartott éles adatok tesztelésével történik. Ezeknek a teszteknek az eredményeit a rendszer naplózza az MLflow nyomkövetési kiszolgálóra. Ez a lépés a fejlesztési szakaszban az adattudósok által megadott értékelési metrikákat használja. Ezek a metrikák tartalmazhatnak egyéni kódot is.

• Modell regisztrálása. Ha a modell betanítása befejeződött, a rendszer regisztrált modellverzióként menti a modellösszetevőt a Unity katalógus éles katalógusában megadott modellútvonalon. A modellbetanítási tevékenység olyan modell URI-t eredményez, amelyet a modellérvényesítési tevékenység használhat. A tevékenységértékek használatával továbbíthatja ezt az URI-t a modellnek.

2. Modell érvényesítése

Ez a folyamat az 1. lépésben szereplő modell URI-t használja, és betölti a modellt a Unity Catalogból. Ezután ellenőrzési ellenőrzések sorozatát hajtja végre. Ezek az ellenőrzések a szervezettől és a használati esettől függenek, és tartalmazhatnak például alapszintű formátum- és metaadat-érvényesítéseket, a kiválasztott adatszeleteken végzett teljesítményértékeléseket, valamint a szervezeti követelményeknek való megfelelést, például a címkék vagy dokumentáció megfelelőségi ellenőrzését.

Ha a modell sikeresen megfelel az összes ellenőrzési ellenőrzésnek, hozzárendelheti a "Challenger" aliast a Modellverzióhoz a Unity Katalógusban. Ha a modell nem felel meg az összes ellenőrzési ellenőrzésnek, a folyamat kilép, és a felhasználók automatikusan értesítést kapnak. Címkék használatával kulcs-érték attribútumokat adhat hozzá az ellenőrzés eredményétől függően. Létrehozhat például egy "model_validation_status" címkét, és beállíthatja a "FÜGGŐBEN" értéket a tesztek végrehajtásakor, majd a folyamat befejezésekor frissítse a "PAS Standard kiadás D" vagy a "FAILED" értékre.

Mivel a modell regisztrálva van a Unity Catalogban, a fejlesztési környezetben dolgozó adattudósok betölthetik ezt a modellverziót az éles katalógusból annak vizsgálatához, hogy a modell ellenőrzése sikertelen-e. Az eredménytől függetlenül a rendszer az eredményeket az éles katalógusban szereplő regisztrált modellre rögzíti a modellverzióhoz tartozó széljegyzetek használatával.

3. Modell üzembe helyezése

Az érvényesítési folyamathoz hasonlóan a modell üzembehelyezési folyamata a szervezettől és a használati esettől függ. Ez a szakasz feltételezi, hogy az újonnan ellenőrzött modellt a "Challenger" aliashoz rendelte, és hogy a meglévő éles modellhez a "Champion" alias lett hozzárendelve. Az új modell üzembe helyezése előtt első lépésként győződjön meg arról, hogy legalább az aktuális üzemi modellhez hasonlóan teljesít.

• Hasonlítsa össze a "CHALLENGER" és a "CHAMPION" modellt. Ezt az összehasonlítást offline vagy online is elvégezheti. Az offline összehasonlítás kiértékeli mindkét modellt egy fenntartott adatkészleten, és nyomon követi az eredményeket az MLflow Tracking-kiszolgálóval. A valós idejű modellek kiszolgálásához érdemes lehet hosszabb ideig futó online összehasonlításokat végezni, például A/B-teszteket vagy az új modell fokozatos bevezetésének végrehajtását. Ha a "Challenger" modell verziója jobban teljesít az összehasonlításban, akkor a jelenlegi "Champion" aliast váltja fel.

  A Databricks-modellkiszolgáló és a Databricks Lakehouse monitorozása lehetővé teszi, hogy automatikusan gyűjtsön és monitorozza a végpontokra vonatkozó kérés- és válaszadatokat tartalmazó következtetési táblákat.

  Ha nincs meglévő "Champion" modell, a "Challenger" modellt üzleti heurisztikus vagy más küszöbértékhez hasonlíthatja alapkonfigurációként.

  Az itt leírt folyamat teljesen automatizált. Ha manuális jóváhagyási lépésekre van szükség, ezeket munkafolyamat-értesítések vagy CI/CD-visszahívások használatával állíthatja be a modell üzembehelyezési folyamatából.

• Modell üzembe helyezése. A kötegelt vagy streamelési következtetési folyamatok beállíthatók úgy, hogy a modellt a "Champion" aliassal használják. Valós idejű használati esetek esetén be kell állítania az infrastruktúrát a modell REST API-végpontként való üzembe helyezéséhez. Ezt a végpontot a Databricks modellkiszolgálóval hozhatja létre és kezelheti. Ha egy végpont már használatban van az aktuális modellhez, frissítheti a végpontot az új modellel. A Databricks Model Serving nulla állásidő-frissítést hajt végre úgy, hogy a meglévő konfiguráció addig fut, amíg az új készen nem áll.

4. Modell kiszolgálása

A modellkiszolgáló végpont konfigurálásakor meg kell adnia a modell nevét a Unity Katalógusban, valamint a kiszolgálni kívánt verziót. Ha a modell verziója a Unity Catalog tábláinak funkcióival lett betanítve, a modell tárolja a funkciók és függvények függőségeit. A modellkiszolgáló automatikusan ezt a függőségi gráfot használja a megfelelő online áruházak funkcióinak következtetési időpontban történő kereséséhez. Ezzel a módszerrel függvényeket is alkalmazhat az adatok előfeldolgozásához vagy igény szerinti funkciók kiszámításához a modell pontozása során.

Létrehozhat egyetlen végpontot több modellel, és megadhatja a végpontok közötti forgalom felosztását ezek között a modellek között, így online "Champion" és "Challenger" összehasonlításokat végezhet.

5. Következtetés: köteg vagy streamelés

A következtetési folyamat beolvassa a legújabb adatokat az éles katalógusból, végrehajtja a függvényeket az igény szerinti funkciók kiszámításához, betölti a "Champion" modellt, pontszámot ad az adatoknak, és előrejelzéseket ad vissza. A kötegelt vagy streamelési következtetés általában a legköltséghatékonyabb lehetőség a nagyobb átviteli sebesség és a nagyobb késésű használati esetek esetében. Olyan forgatókönyvek esetében, ahol alacsony késésű előrejelzésekre van szükség, de az előrejelzések offline módon is kiszámíthatók, ezek a kötegelt előrejelzések közzétehetők egy online kulcs-érték tárolóban, például a DynamoDB-ben vagy a Cosmos DB-ben.

A Unity Catalog regisztrált modelljére az alias hivatkozik. A következtetési folyamat úgy van konfigurálva, hogy betöltse és alkalmazza a "Champion" modell verzióját. Ha a "Champion" verzió egy új modellverzióra frissül, a következtetési folyamat automatikusan az új verziót használja a következő végrehajtáshoz. Ily módon a modell üzembe helyezési lépése leválasztva van a következtetési folyamatokról.

A Batch-feladatok általában az éles katalógus tábláiban, egybesimított fájlokban vagy egy JDBC-kapcsolaton keresztül tesznek közzé előrejelzéseket. A streamelési feladatok általában a Unity Catalog tábláiban vagy üzenetsorokban, például az Apache Kafkában tesznek közzé előrejelzéseket.

6. Lakehouse Monitorozás

A Lakehouse monitorozása figyeli a bemeneti adatok és a modellek előrejelzéseinek statisztikai tulajdonságait, például az adateltolódást és a modell teljesítményét. Riasztásokat hozhat létre ezek alapján a metrikák alapján, vagy közzéteheti őket az irányítópultokon.

• Adatbetöltés. Ez a folyamat naplókban olvas be kötegelt, streamelési vagy online következtetésből.
• Ellenőrizze a pontosságot és az adatok eltérését. A folyamat metrikákat számít ki a bemeneti adatokról, a modell előrejelzéseiről és az infrastruktúra teljesítményéről. Az adattudósok a fejlesztés során adat- és modellmetrikákat, az ml-mérnökök pedig infrastruktúrametrikákat határoznak meg. Egyéni metrikákat a Lakehouse Monitorozással is definiálhat.
• Metrikák közzététele és riasztások beállítása. A folyamat az éles katalógus tábláiba ír elemzés és jelentéskészítés céljából. Ezeket a táblákat úgy kell konfigurálnia, hogy olvashatók legyenek a fejlesztői környezetből, hogy az adatelemzők hozzáférhessenek az elemzéshez. A Databricks SQL használatával monitorozási irányítópultokat hozhat létre a modell teljesítményének nyomon követéséhez, és beállíthatja a monitorozási feladatot vagy az irányítópult eszközt, hogy értesítést küldjön, ha egy metrika túllép egy megadott küszöbértéket.
• Triggermodell újratanítása. Ha a monitorozási metrikák teljesítményproblémákat vagy a bemeneti adatok változásait jelzik, előfordulhat, hogy az adatelemzőnek új modellverziót kell kidolgoznia. Beállíthat SQL-riasztásokat az adattudósok értesítésére, ha ez történik.

7. Újratanítás

Ez az architektúra a fenti modell betanítási folyamatával támogatja az automatikus újratanítást. A Databricks azt javasolja, hogy az ütemezett, rendszeres újratanítással kezdődjön, és szükség esetén váltsa át az aktivált újratanítást.

• Ütemezett. Ha az új adatok rendszeresen elérhetők, létrehozhat egy ütemezett feladatot a modell betanítási kódjának a legújabb rendelkezésre álló adatokon való futtatásához.
• Triggerrel indított. Ha a monitorozási folyamat képes azonosítani a modell teljesítményével kapcsolatos problémákat, és riasztásokat küld, újratanítást is aktiválhat. Ha például a bejövő adatok eloszlása jelentősen megváltozik, vagy ha a modell teljesítménye csökken, az automatikus újratanítás és újratelepítés minimális emberi beavatkozással növelheti a modell teljesítményét. Ez egy SQL-riasztással érhető el annak ellenőrzéséhez, hogy egy metrika rendellenes-e (például ellenőrizze az eltérést vagy a modell minőségét egy küszöbértéken). A riasztás konfigurálható webhook-célhely használatára, amely később elindíthatja a betanítási munkafolyamatot.

Ha az újratanítási folyamat vagy más folyamatok teljesítményproblémákat mutatnak, előfordulhat, hogy az adatelemzőnek vissza kell térnie a fejlesztési környezetbe a problémák megoldásához szükséges további kísérletezéshez.