Pracovní postupy MLOps v Azure Databricks
Tento článek popisuje, jak můžete pomocí MLOps na platformě Databricks optimize výkon a dlouhodobou efektivitu systémů strojového učení (ML). Zahrnuje obecná doporučení pro architekturu MLOps a popisuje generalizovaný pracovní postup pomocí platformy Databricks, kterou můžete použít jako model pro proces vývoje a produkčního procesu ML. Úpravy tohoto pracovního postupu pro aplikace LLMOps najdete v pracovních postupech LLMOps.
Další podrobnosti najdete v tématu Velká kniha MLOps.
Co je MLOps?
MLOps je set procesů a automatizovaných kroků pro správu kódu, dat a modelů za účelem zlepšení výkonu, stability a dlouhodobé efektivity systémů ML. Kombinuje DevOps, DataOps a ModelOps.
Prostředky ML, jako jsou kód, data a modely, se vyvíjejí ve fázích, které se vyvíjejí od raných fází vývoje, které nemají úzká omezení přístupu a nejsou pečlivě testovány prostřednictvím přechodné fáze testování do konečné fáze výroby, která je přísně řízena. Platforma Databricks umožňuje spravovat tyto prostředky na jedné platformě s jednotným řízením přístupu. Na stejné platformě můžete vyvíjet datové aplikace a aplikace ML, což snižuje rizika a zpoždění spojená s přesouváním dat.
Obecná doporučení pro MLOps
Tato část obsahuje některá obecná doporučení pro MLOps v Databricks s odkazy na další informace.
Vytvoření samostatného prostředí pro každou fázi
Spouštěcí prostředí je místo where modely a data se vytvářejí nebo využívají kódem. Každé spouštěcí prostředí se skládá z výpočetních instancí, jejich modulů runtime a knihoven a automatizovaných úloh.
Databricks doporučuje vytvářet samostatná prostředí pro různé fáze vývoje kódu ML a modelu s jasně definovanými přechody mezi fázemi. Pracovní postup popsaný v tomto článku se řídí tímto procesem pomocí běžných názvů fází:
Další konfigurace se dají použít také ke splnění konkrétních potřeb vaší organizace.
Řízení přístupu a správa verzí
Řízení přístupu a správa verzí jsou klíčovými komponentami jakéhokoli procesu softwarového provozu. Databricks doporučuje následující:
- Použijte Git pro správu verzí. Kanály a kód by měly být uložené v Gitu pro správu verzí. Přesun logiky ML mezi fázemi je pak možné interpretovat jako přesun kódu z vývojové větve do přípravné větve do větve vydané verze. Pomocí složek Git Databricks můžete integrovat s vaším poskytovatelem Gitu a sync poznámkové bloky a zdrojový kód s pracovními prostory Databricks. Databricks také poskytuje další nástroje pro integraci Gitu a správu verzí; viz Vývojářské nástroje.
- Uložit data v architektuře lakehouse s použitím Delta tables. Data by se měla ukládat v architektuře lakehouse ve vašem cloudovém účtu. Nezpracovaná data i tables funkcí by se měly ukládat jako delta tables s řízením přístupu, abyste zjistili, kdo je může číst a upravovat.
- Správa vývoje modelů pomocí MLflow Pomocí MLflow můžete sledovat proces vývoje modelu a ukládat snímky kódu, parametersmodelu, metriky a další metadata.
- Ke správě životního cyklu modelu použijte modely v Unity Catalog. Pomocí modelů v Unity Catalog můžete spravovat správu verzí modelu, zásad správného řízení a stavu nasazení.
Nasazení kódu, ne modelů
Ve většině situací databricks doporučuje, abyste během procesu vývoje STROJOVÉho učení propagovali kód místo modelů z jednoho prostředí na další. Přesun prostředků projektu tímto způsobem zajišťuje, že veškerý kód v procesu vývoje ML prochází stejnými procesy kontroly kódu a procesu testování integrace. Také zajišťuje, aby produkční verze modelu byla natrénována v produkčním kódu. Podrobnější diskuzi o možnostech a kompromisech najdete v tématu Vzory nasazení modelu.
Doporučený pracovní postup MLOps
Následující části popisují typický pracovní postup MLOps, který pokrývá každou ze tří fází: vývoj, přípravu a produkci.
Tato část používá termíny "datový vědec" a "technik ML" jako archetypal personas; konkrétní role a zodpovědnosti v pracovním postupu MLOps se budou mezi týmy a organizacemi lišit.
Vývojová fáze
Cílem fáze vývoje je experimentování. Datoví vědci vyvíjejí funkce a modely a spouští experimenty pro optimize výkon modelu. Výstupem procesu vývoje je kód kanálu ML, který může zahrnovat výpočty funkcí, trénování modelu, odvozování a monitorování.
Číslovaný postup odpovídá číslům uvedeným v diagramu.
1. Zdroje dat
Vývojové prostředí je reprezentováno dev catalog v Unity Catalog. Datoví vědci mají přístup pro čtení a zápis do vývojového catalog, protože vytvářejí dočasná data a funkce tables ve vývojovém pracovním prostoru. Modely vytvořené ve fázi vývoje jsou registrovány do dev catalog.
V ideálním případě mají datoví vědci pracující ve vývojovém pracovním prostoru také přístup jen pro čtení k produkčním datům v produkčním catalog. Umožněním datovým vědcům přístup pro čtení k produkčním datům, odvození tablesa metrikám tables v prod catalog mohou analyzovat predikce a výkon aktuálního produkčního modelu. Datoví vědci by také měli být schopni načíst produkční modely pro experimentování a analýzu.
Pokud není možné grant zajistit přístup jen pro čtení k produkčnímu catalog, lze snímek produkčních dat zapsat do vývojového catalog, aby datoví vědci mohli vyvíjet a vyhodnocovat kód projektu.
2. Průzkumná analýza dat (EDA)
Datoví vědci prozkoumávají a analyzují data v interaktivním iterativním procesu pomocí poznámkových bloků. Cílem je posoudit, jestli dostupná data mají potenciál k vyřešení obchodního problému. V tomto kroku začne datový vědec identifikovat kroky přípravy a featurizace dat pro trénování modelu. Tento ad hoc proces obecně není součástí kanálu, který se nasadí v jiných spouštěcích prostředích.
AutoML tento proces zrychluje generováním standardních modelů pro datovou sadu. AutoML provádí a zaznamenává set zkušebních verzí a poskytuje poznámkový blok Pythonu se zdrojovým kódem pro každé zkušební spuštění, abyste mohli kód zkontrolovat, reprodukovat a upravit. AutoML také vypočítá souhrnnou statistiku datové sady a uloží tyto informace do poznámkového bloku, který si můžete prohlédnout.
3. Kód
Úložiště kódu obsahuje všechny kanály, moduly a další soubory projektu pro projekt ML. Datoví vědci vytvářejí nové nebo aktualizované kanály ve vývojové ("vývojové") větvi úložiště projektu. Počínaje EDA a počátečními fázemi projektu by datoví vědci měli pracovat v úložišti za účelem sdílení kódu a sledování změn.
4. Trénování modelu (vývoj)
Datoví vědci vyvíjejí přípravu modelu ve vývojovém prostředí pomocí tables z vývojového nebo produkčního catalogs.
Tento kanál zahrnuje 2 úlohy:
Trénování a ladění. Proces trénování protokoluje model parameters, metriky a artefakty na server pro sledování MLflow. Po trénování a ladění hyperparametrů je koncový artefakt modelu zaznamenán na sledovací server, aby zaznamenal propojení mezi modelem, vstupními daty, na kterých byl natrénován, a kódem použitým k generate.
Vyhodnocení: Vyhodnoťte kvalitu modelu testováním uložených dat. Výsledky těchto testů se protokolují na server pro sledování MLflow. Účelem vyhodnocení je určit, jestli nově vyvinutý model funguje lépe než aktuální produkční model. Vzhledem k dostatečným oprávněním je možné do vývojového pracovního prostoru načíst jakýkoli produkční model zaregistrovaný v produkčním catalog a porovnat ho s nově natrénovaným modelem.
Pokud požadavky vaší organizace na zásady správného řízení obsahují další informace o modelu, můžete ho uložit pomocí sledování MLflow. Typické artefakty jsou popisy prostého textu a interpretace modelů, jako jsou grafy vytvořené pomocí SHAP. Konkrétní požadavky zásad správného řízení můžou pocházet od pracovníka zásad správného řízení dat nebo obchodních zúčastněných stran.
Výstupem trénovacího kanálu modelu je artefakt modelu ML uložený na serveru pro sledování MLflow pro vývojové prostředí. Pokud se kanál spustí v pracovním nebo produkčním pracovním prostoru, artefakt modelu se uloží na server sledování MLflow pro tento pracovní prostor.
Po dokončení trénování modelu zaregistrujte model do Unity Catalog. Set kód kanálu pro registraci modelu do catalog odpovídající prostředí, ve které byl kanál modelu spuštěn; v tomto příkladu dev catalog.
S doporučenou architekturou nasadíte pracovní postup Multitask Databricks, ve kterém první úlohou je trénovací kanál modelu, následovaný ověřením modelu a úlohami nasazení modelu. Úloha trénování modelu poskytuje identifikátor URI modelu, který může použít úloha ověření modelu. K předání tohoto identifikátoru URI do modelu můžete použít úkol values.
5. Ověření a nasazení modelu (vývoj)
Kromě kanálu trénování modelu se v vývojovém prostředí vyvíjejí i další kanály, jako je ověření modelu a kanály nasazení modelu.
Ověření modelu Kanál ověřování modelu přebírá URI modelu z výcvikového kanálu modelu, načte model z Unity Cataloga provádí ověřovací kontroly.
Kontroly ověření závisí na kontextu. Můžou zahrnovat základní kontroly, jako je potvrzení formátu a požadovaná metadata, a složitější kontroly, které mohou být vyžadovány pro vysoce regulovaná odvětví, jako jsou předdefinované kontroly dodržování předpisů a potvrzení výkonu modelu u vybraných datových řezů.
Primární funkcí kanálu ověření modelu je určit, jestli má model pokračovat krokem nasazení. Pokud model projde kontrolami před nasazením, může být v Unity přiřazen alias Challenger Catalog. Pokud kontroly selžou, proces skončí. Pracovní postup můžete nakonfigurovat tak, aby uživatelům upozorňovat na selhání ověření. Podívejte se na Přidat oznámení na úlohu.
Nasazení modelu Kanál nasazení modelu obvykle buď přímo podporuje nově natrénovaný model "Challenger" na "Champion" status pomocí aliasu update, nebo usnadňuje porovnání mezi existujícím modelem "Champion" a novým modelem "Challenger". Tento kanál může také set libovolnou požadovanou infrastrukturu odvozování, jako jsou koncové body obsluhy modelů. Podrobné informace o krocích, které jsou součástí kanálu nasazení modelu, najdete v části Produkční.
6. Potvrzení kódu
Po vývoji kódu pro trénování, ověřování, nasazení a další kanály potvrdí datový vědec nebo inženýr ML změny vývojové větve do správy zdrojového kódu.
Přípravná fáze
Cílem této fáze je testování kódu kanálu ML, aby se zajistilo, že je připravený pro produkční prostředí. Veškerý kód kanálu ML se v této fázi testuje, včetně kódu pro trénování modelu a také kanálů přípravy funkcí, odvozování kódu atd.
Inženýři STROJOVÉho učení vytvoří kanál CI pro implementaci testů jednotek a integrace spuštěných v této fázi. Výstupem přípravného procesu je větev verze, která aktivuje systém CI/CD pro spuštění produkční fáze.
1. Data
Testovací prostředí by mělo mít vlastní catalog v Unity Catalog pro testování ML pipeline a registraci modelů do Unity Catalog. Tento catalog je v diagramu zobrazen jako „přípravný" catalog. Data zapsaná do tohoto catalog jsou obecně dočasná a uchovávají se jen do té doby, než je testování dokončeno. Vývojové prostředí může také vyžadovat přístup k testovacímu catalog pro účely ladění.
2. Sloučit kód
Datoví vědci vyvíjejí výukovou pipeline modelu ve vývojovém prostředí s využitím tables z vývojového nebo produkčního catalogs.
Žádost o přijetí změn Proces nasazení začíná při vytvoření žádosti o přijetí změn v hlavní větvi projektu ve správě zdrojového kódu.
Testy jednotek (CI). Žádost o přijetí změn automaticky sestaví zdrojový kód a aktivuje testy jednotek. Pokud testy jednotek selžou, žádost o přijetí změn se odmítne.
Testy jednotek jsou součástí procesu vývoje softwaru a průběžně se spouštějí a přidávají do základu kódu během vývoje libovolného kódu. Spouštění testů jednotek v rámci kanálu CI zajišťuje, že změny provedené ve vývojové větvi neporušují stávající funkce.
3. Integrační testy (CI)
Proces CI pak spustí integrační testy. Integrační testy spouštějí všechny kanály (včetně přípravy funkcí, trénování modelů, odvozování a monitorování), aby se zajistilo, že fungují správně společně. Přípravné prostředí by se mělo shodovat s produkčním prostředím tak, jak je přiměřené.
Pokud nasazujete aplikaci ML s odvozováním v reálném čase, měli byste vytvořit a otestovat obslužnou infrastrukturu v přípravném prostředí. To zahrnuje aktivaci kanálu nasazení modelu, který vytvoří koncový bod obsluhy v přípravném prostředí a načte model.
Aby se zkrátila doba potřebná ke spuštění integračních testů, některé kroky se můžou odměňovat mezi věrností testování a rychlostí nebo náklady. Pokud jsou například modely nákladné nebo časově náročné na trénování, můžete použít malé podmnožina dat nebo spustit méně trénovacích iterací. V závislosti na požadavcích na produkční prostředí můžete v integračních testech provádět kompletní zátěžové testování nebo můžete testovat jen malé dávkové úlohy nebo požadavky na dočasný koncový bod.
4. Sloučení do přípravné větve
Pokud všechny testy projdou, nový kód se sloučí do hlavní větve projektu. Pokud testy selžou, měl by systém CI/CD upozornit uživatele a publikovat výsledky na žádost o přijetí změn.
V hlavní větvi můžete naplánovat pravidelné integrační testy. To je vhodné, pokud se větev často aktualizuje souběžnými žádostmi o přijetí změn od více uživatelů.
5. Vytvoření větve vydané verze
Po dokončení testů CI a sloučení vývojové větve do hlavní větve vytvoří inženýr ML větev vydané verze, která aktivuje systém CI/CD pro update produkční úlohy.
Produkční fáze
Inženýři strojového učení vlastní produkční prostředí where, kde se nasazují a spouštějí pipeliney ML. Tyto kanály aktivují trénování modelu, ověřují a nasazují nové verze modelu, publikují předpovědi do podřízených tables nebo aplikací a monitorují celý proces, aby se zabránilo snížení výkonu a nestabilitě.
Datoví vědci obvykle nemají v produkčním prostředí přístup k zápisu ani výpočetnímu výkonu. Je však důležité, aby měli přehled o výsledcích testů, protokolech, artefaktech modelu, stavu produkčního potrubí a monitorování tables. Tato viditelnost jim umožňuje identifikovat a diagnostikovat problémy v produkčním prostředí a porovnat výkon nových modelů s modely, které jsou aktuálně v produkčním prostředí. Pro tyto účely můžete datovým vědcům poskytnout přístup jen pro čtení k prostředkům v produkčním grantcatalog.
Číslovaný postup odpovídá číslům uvedeným v diagramu.
1. Trénování modelu
Tento kanál je možné aktivovat změnami kódu nebo automatizovanými úlohami opětovného natrénování. V tomto kroku jsou tables z výrobního catalog používány pro následující kroky.
Trénování a ladění. Během trénování se protokoly zaznamenávají do produkčního prostředí serveru MLflow Tracking. Mezi tyto protokoly patří metriky modelu, parameters, značky a samotný model. Pokud používáte vlastnost tables, model je zapsán do MLflow prostřednictvím klienta Databricks Feature Store, který model zabalí s informacemi o vyhledávání vlastností, které se používají při inferenci.
Během vývoje mohou datoví vědci testovat mnoho algoritmů a hyperparametrů. V produkčním trénovacím kódu je běžné zvážit pouze možnosti s nejvyšším výkonem. Omezení ladění tímto způsobem šetří čas a může snížit odchylku od ladění při automatizovaném přetrénování.
Pokud mají datoví vědci k produkčnímu catalogpřístup pouze pro čtení, mohou být schopni určit optimální set hyperparametrů pro model. V tomto případě je možné kanál trénování modelu nasazený v produkčním prostředí spustit pomocí vybraného set hyperparametrů, které jsou obvykle součástí kanálu jako konfiguračního souboru.
Vyhodnocení: Kvalita modelu se vyhodnocuje testováním uložených produkčních dat. Výsledky těchto testů se protokolují na server pro sledování MLflow. Tento krok používá metriky vyhodnocení určené datovými vědci ve fázi vývoje. Tyto metriky můžou zahrnovat vlastní kód.
Zaregistrujte model. Po dokončení trénování modelu je modelový artefakt uložen jako registrovaná verze modelu na zadané cestě modelu v produkčním catalog v Unity Catalog. Úloha trénování modelu poskytuje identifikátor URI modelu, který může použít úloha ověření modelu. K předání tohoto identifikátoru URI do modelu můžete použít úkol values.
2. Ověření modelu
Tento kanál používá identifikátor URI modelu z kroku 1 a načte model z Unity Catalog. Potom provede řadu ověřovacích kontrol. Tyto kontroly závisí na vaší organizaci a případu použití a můžou zahrnovat například základní ověřování formátu a metadat, vyhodnocení výkonu u vybraných datových řezů a dodržování předpisů s požadavky organizace, jako jsou kontroly dodržování předpisů pro značky nebo dokumentaci.
Pokud model úspěšně projde všemi kontrolami ověření, můžete přiřadit alias "Challenger" verzi modelu v Unity Catalog. Pokud model neprojde všemi ověřovacími kontrolami, proces se ukončí a uživatelé můžou být automaticky upozorněni. Značky můžete použít k přidání atributů klíč-hodnota v závislosti na výsledku těchto ověřovacích kontrol. Můžete například vytvořit značku "model_validation_status" a set hodnotu na "NA ČEKÁNÍ", když se provádějí testy, a poté ji update na "SPLNĚNÉ" nebo "NEÚSPĚŠNÉ", když je proces dokončen.
Vzhledem k tomu, že je model zaregistrovaný v Unity Catalog, mohou datoví vědci pracující ve vývojovém prostředí načíst tuto verzi modelu z produkčního catalog a zjistit, jestli model selže při validaci. Bez ohledu na výsledek se výsledky zaznamenávají do registrovaného modelu v produkčním prostředí označeném jako catalog pomocí anotací k verzi modelu.
3. Nasazení modelu
Stejně jako kanál ověření závisí kanál nasazení modelu na vaši organizaci a případ použití. V této části se předpokládá, že jste nově ověřenému modelu přiřadili alias Challenger a že stávající produkční model má přiřazený alias Šampion. Prvním krokem před nasazením nového modelu je potvrzení, že provádí alespoň aktuální produkční model.
Porovnejte model CHALLENGER s modelem CHAMPION. Toto porovnání můžete provést offline nebo online. Offline porovnání vyhodnocuje oba modely proti uchovávaným datům set a sleduje výsledky pomocí serveru MLflow Tracking. Pro poskytování modelu v reálném čase můžete chtít provádět delší spouštění online porovnání, jako jsou testy A/B nebo postupné zavedení nového modelu. Pokud verze modelu "Challenger" v porovnání funguje lépe, nahradí aktuální alias "Champion".
Aplikace Mosaic AI Model Serving a monitorování Databricks Lakehouse umožňují automaticky shromažďovat a monitorovat inference tables, které obsahují data požadavků a odpovědí pro koncový bod.
Pokud neexistuje žádný model "Champion", můžete model "Challenger" porovnat s heuristickým nebo jiným prahovým plánem firmy jako směrný plán.
Zde popsaný proces je plně automatizovaný. Pokud jsou vyžadovány kroky ručního schvalování, můžete je set pomocí oznámení pracovního postupu nebo zpětného volání CI/CD z kanálu nasazení modelu.
Nasazení modelu Kanály odvozování služby Batch nebo streamování je možné set až po použití modelu s aliasem Champion. V případě použití v reálném čase musíte set infrastrukturu, aby se model nasadil jako koncový bod rozhraní REST API. Tento koncový bod můžete vytvořit a spravovat pomocí obsluhy modelu Mosaic AI. Pokud se koncový bod už používá pro aktuální model, můžete update koncový bod s novým modelem. Služba Mosaic AI Model Serving dosahuje nulového výpadku update tím, že nechává stávající konfiguraci běžet, dokud není nová připravená.
4. Obsluha modelu
Při konfiguraci koncového bodu obsluhy modelu zadáte název modelu v Unity Catalog a verzi, která se má použít. Pokud byla verze modelu natrénována pomocí vlastností z tables v Unity Catalog, model ukládá závislosti pro vlastnosti a funkce. Obsluha modelů automaticky používá tento graf závislostí k vyhledání funkcí z příslušných online obchodů v době odvozování. Tento přístup se dá použít také k použití funkcí pro předběžné zpracování dat nebo k výpočtu funkcí na vyžádání během vyhodnocování modelu.
Můžete vytvořit jeden koncový bod s více modely a určit rozdělení provozu koncových bodů mezi tyto modely, což vám umožní provádět online porovnání "Šampion" a "Challenger".
5. Odvozování: dávka nebo streamování
Kanál odvozování čte nejnovější data z produkčního catalog, spouští funkce pro výpočty funkcí na vyžádání, načte model "Champion", vyhodnočí data a vrátí předpovědi. Odvozování služby Batch nebo streamování je obecně nákladově nejefektivnější možností pro vyšší propustnost a vyšší případy použití latence. Pro scénáře where jsou vyžadovány předpovědi s nízkou latencí, ale pokud lze předpovědi vypočítat offline, tyto dávkové předpovědi lze publikovat do online úložiště typu klíč-hodnota, jako je DynamoDB nebo Cosmos DB.
Na zaregistrovaný model v Unity Catalog odkazuje jeho alias. Kanál odvozování je nakonfigurovaný tak, aby načetl a použil verzi modelu Champion. Pokud se verze "Champion" aktualizuje na novou verzi modelu, kanál odvozování automaticky použije novou verzi pro další spuštění. Tímto způsobem je krok nasazení modelu oddělený od kanálů odvozování.
Dávkové úlohy obvykle zveřejňují předpovědi do tables v produkčním catalog, do prostých souborů nebo přes připojení JDBC. Úlohy streamování obvykle publikují předpovědi do Unity Catalogtables nebo do front zpráv, jako je Apache Kafka.
6. Monitorování lakehouse
Monitorování Lakehouse monitoruje statistické vlastnosti, jako je posun dat a výkon modelu, vstupních dat a předpovědí modelu. Na základě těchto metrik můžete vytvářet upozornění nebo je publikovat na řídicích panelech.
- Příjem dat. Tento kanál čte protokoly z dávkového, streamovaného nebo online odvozování.
- Zkontrolujte přesnost a posun dat. Kanál vypočítá metriky o vstupních datech, predikcích modelu a výkonu infrastruktury. Datoví vědci určují metriky dat a modelů během vývoje a technici STROJOVÉho učení určují metriky infrastruktury. Vlastní metriky můžete definovat také pomocí monitorování Lakehouse.
- Publikujte metriky a upozornění označené set. Potrubí zapisuje do tables v produkčním prostředí catalog pro analýzu a tvorbu zpráv. Tyto tables byste měli nakonfigurovat tak, aby byly čitelné z vývojového prostředí, aby datoví vědci měli přístup k analýze. Databricks SQL můžete použít k vytvoření řídicích panelů monitorování ke sledování výkonu modelu a set úlohu monitorování nebo nástroj řídicího panelu k vydání oznámení, když metrika překročí zadanou prahovou hodnotu.
- Opětovné trénování modelu triggeru Při monitorování metrik indikují problémy s výkonem nebo změny vstupních dat, může datový vědec potřebovat vytvořit novou verzi modelu. Můžete set upozorňovat výstrahy SQL, které upozorní datové vědce, když k tomu dojde.
7. Přeučování
Tato architektura podporuje automatické přetrénování pomocí stejného trénovacího kanálu modelu výše. Databricks doporučuje začít s naplánovaným, pravidelným opakovaným vytrénováním a přechodem na aktivaci opětovného natrénování v případě potřeby.
- Plánované: Pokud jsou nová data k dispozici pravidelně, můžete vytvořit naplánovanou úlohu pro spuštění trénovacího kódu modelu na nejnovějších dostupných datech. Viz Automatizace úloh pomocí plánů a triggerů
- Aktivované: Pokud kanál monitorování dokáže identifikovat problémy s výkonem modelu a odesílat výstrahy, může také aktivovat opětovné trénování. Pokud se například distribuce příchozích dat výrazně změní nebo pokud dojde ke snížení výkonu modelu, může automatické opětovné trénování a opětovné nasazení zvýšit výkon modelu s minimálním zásahem člověka. Toho lze dosáhnout prostřednictvím upozornění SQL a zkontrolovat, jestli je metrika neobvyklá (například kontrola posunu nebo kvality modelu proti prahové hodnotě). Výstrahu lze nakonfigurovat tak, aby používala cíl webhooku, který následně může aktivovat pracovní postup trénování.
Pokud kanál opětovného natrénování nebo jiné kanály vykazují problémy s výkonem, může se datový vědec muset vrátit do vývojového prostředí, aby mohl problém vyřešit další experimentování.