Strojové učení (ML) se dnes stalo jednou z nejdůležitějších schopností moderních podniků pro růst a udržení konkurenceschopnosti. Od automatizace interních procesů až po optimalizaci procesů návrhu, tvorby a marketingu za prakticky každým spotřebovaným produktem, modely ML pronikly téměř do všech aspektů našeho pracovního a osobního života – a pro podniky nebyly nikdy vyšší sázky. Nepřijetí ML jako hlavní kompetence bude mít za následek velké konkurenční nevýhody, které budou určovat další lídry na trhu.
Z tohoto důvodu musí obchodní a technologickí lídři implementovat modely ML v celé své organizaci, pokrývající široké spektrum případů použití. Tento pocit naléhavosti v kombinaci s rostoucí regulační kontrolou však vytváří nové a jedinečné výzvy v oblasti správy, které je v současnosti obtížné zvládnout. Například:Jak moje modely ovlivňují služby poskytované koncovým zákazníkům? Dodržuji stále jak vládní, tak interní předpisy? Jak se moje pravidla zabezpečení promítnou do modelů ve výrobě?
Kromě regulačních nebo právních záležitostí existuje řada důvodů, proč mít procesy a postupy řízení pro strojové učení. Příklady zahrnují způsoby zvýšení produktivity (jako je opětovné použití aktiv, jako jsou modely a funkce), ovládání a údržba modelů napříč mnoha různými obchodními liniemi, aby bylo zajištěno, že kritické obchodní aplikace dělají to, co mají dělat (nebo vyhledávají ty, které ne) a zobrazení historie modelů a předpovědí včetně zastaralých aktiv.
Při řešení těchto problémů stojí za to definovat, jaké modely a funkce jsou koncepčně (viz obrázek 1). Existuje mnoho různých definic, ale obecně je modelem jakýkoli samostatný balíček, který přebírá vlastnosti vypočítané ze vstupních dat a vytváří předpověď (nebo skóre) a metadata. Tento balíček může mít mnoho podob, ale vždy obsahuje matematickou reprezentaci, kód, obchodní logiku a trénovací data. Předpovědi modelu jsou spotřebovávány systémy nebo uživateli.
Mnoho podniků provozuje modelovou infrastrukturu ML v různých velikostech a vyspělosti, takže potřebují nástroje, které jim pomohou řídit jejich modely. V konečném důsledku lze potřeby řízení praní peněz rozdělit do následujících klíčových oblastí:viditelnost; a vysvětlitelnost, interpretovatelnost a reprodukovatelnost modelu.
Obrázek 1
Viditelnost modelů a funkcí v týmech a napříč organizacemi
Základním požadavkem na řízení modelů je umožnit týmům porozumět tomu, jak se v jejich organizacích používá strojové učení. To vyžaduje kanonický katalog modelů a funkcí. Při absenci takového katalogu mnoho organizací neví o svých modelech a funkcích, o tom, kde jsou nasazeny, co dělají atd. To vede k přepracování, nekonzistenci modelu, funkcím přepočítávání a dalším neefektivitám.
Vysvětlitelnost, interpretovatelnost a reprodukovatelnost modelu
Modely jsou často vnímány jako černá skříňka:data přicházejí, něco se stane a vyjde předpověď. Tato netransparentnost je náročná na mnoha úrovních a často je reprezentována volně souvisejícími pojmy, jako například:
- Vysvětlitelnost :popis vnitřní mechaniky modelu ML v lidských pojmech
- Interpretovatelnost :schopnost a) porozumět vztahu mezi vstupy, funkcemi a výstupy modelu ab) předvídat odezvu na změny ve vstupech.
- Reprodukovatelnost :schopnost reprodukovat výstup modelu konzistentním způsobem pro stejné vstupy.
To vše vyžaduje společnou funkcionalitu včetně propojení se zdrojovými daty, jasné porozumění vnitřním prvkům modelů, jako jsou kód a trénovací data, a další metody pro zkoumání a analýzu samotných modelů.
Metadata modelu s příkladem
Abychom se vypořádali s problémy správy definovaných výše, začněme uvažováním o příkladu. Zvažte webovou stránku pro rozvoz jídla. Společnost chce využít strojové učení k odhadu času doručení.
Tréninková datová sada se skládá z protokolů událostí z předchozích dodávek, které obsahují dodací lhůty pro každou dodávku uskutečněnou v minulosti. Tato data se používají k trénování modelu pro odhad budoucích dodacích lhůt.
Protokol událostí může vypadat nějak takto:
V 10:00 byla zadána objednávka na vyzvednutí jídla z místa 1 a doručení na místo 2. Kurýr to vyzvedl z restaurace v 10:15 a doručil v 10:55, celkem to trvalo 55 minut od zadání objednávky po doručení
Předpokládejme, že loc1 a loc2 jsou adresy ulic. Toto je zde zkráceno, aby bylo krátké a snadno čitelné.
Protokoly událostí jsou uloženy v HBase. Inženýrská architektura pro vývoj modelu je následující:
- Datoví inženýři identifikují časové okno protokolů událostí, které mají být použity k vyřešení problému. Nová strukturovaná tabulka Hive se vytvoří analýzou nezpracovaných protokolů událostí s identifikovaným časovým oknem.
- Inženýři funkcí (může to být role v rámci datových vědců nebo techniků ML) identifikují a vyvíjejí nové funkce:
- Funkce dopravní špičky:Funkce pro zjištění, zda existují podmínky dopravní špičky v dané lokalitě a čase.
- Funkce „zaneprázdněnosti“ restaurace:Funkce pro zjištění, zda daná restaurace na základě historických údajů zažívá vysoké čekací doby. Tato historická data se shromažďují samostatně.
- Výše identifikované funkce jsou poté vytvořeny jako knihovna python pro opětovné použití.
- Tato knihovna se používá k aplikaci funkce na strukturovanou tabulku Hive k vytvoření nové tabulky, která bude konečným souborem tréninkových dat. Řádek v nové tabulce vypadá takto:
Předpokládejme, že loc1 a loc2 jsou adresy ulic. Toto je zde zkráceno, aby bylo krátké a snadno čitelné.
- Datoví vědci provádějí lineární regresi na sadě školicích dat, aby předpověděli čas doručení. V tomto okamžiku musí použít stejnou knihovnu funkcí, která byla použita k extrahování funkcí v sadě tréninkových dat.
- Model je nasazen jako koncový bod Function-as-a-Service (FaaS), který webová aplikace používá k předpovídání času doručení.
Všimněte si, že model potřebuje vypočítat funkce pro predikci v reálném čase. Tyto funkce jsou knihovny, které model používá interně. Vizualizace různých prováděných činností a artefaktů generovaných v tomto příkladu může vypadat takto:
Modrá políčka představují entity ML (podstatná jména), jako je kód, projekt, sestavení, nasazení atd. Zelená políčka představují procesy (slovesa), které působí na entity a vytvářejí další entity.
Vizualizace a vztahy, které definují transformace ve struktuře dat, se souhrnně nazývají lineage . Ve světě databází změní přidání nového sloupce do tabulky její původ. Ve světě strojového učení změní linii přeškolení modelu spotřebováním funkcí a sad dat. Abychom mohli odpovědět na otázku:„Existuje rozdíl mezi extrakcí funkcí během tréninku a bodováním“, potřebujeme pro webovou stránku rozvozu jídla informace o původu. Toto je jen jeden příklad užitečnosti metadat o linii ve světě strojového učení.
Apache Atlas jako nástroj správy
Je zřejmé, že vybudování kompletní linie pro pracovní postupy ML – od školicích datových sad až po nasazení modelů – se stává klíčovým požadavkem pro řešení zjištěných problémů s řízením. Integrace správy dat a strojového učení musí umožnit vysvětlitelnost, interpretovatelnost a reprodukovatelnost.
Shromažďování, ukládání a vizualizace metadat ML vyžaduje standardní backendový softwarový systém. Otevřená a rozšiřitelná definice metadat umožní standardizaci operací správy bez ohledu na to, kde jsou modely vyvíjeny nebo kde jsou poskytovány. Zřejmým kandidátem na Cloudera (a naše zákazníky) je Apache Atlas.
Apache Atlas je již sadou široce používaných nástrojů pro správu dat s předdefinovanými typy metadat pro správu dat. V kontextu správy ML se dobře hodí pro definování a zachycení metadat požadovaných pro koncepty strojového učení. Kromě toho Apache Atlas poskytuje pokročilé funkce, jako jsou klasifikace, integrace s Apache Ranger (pro autorizaci a označování), abychom jmenovali alespoň některé, a má rozšiřitelný systém doplňků, který umožňuje komunitě spolupracovat a postupně definovat integrace s různými dalšími nástroji v ML. prostor. Je ponecháno jako cvičení pro čtenáře, aby prozkoumali uživatelské rozhraní Apache Atlas a zjistili, jak tyto funkce používat.
Definice metadat ML v Apache Atlas
Systém Apache Atlas Type System vyhovuje všem našim potřebám pro definování objektů metadat ML. Je open source, rozšiřitelný a má předem vytvořené funkce správy. Typ v Atlasu je definicí toho, jak je určitý typ objektu metadat uložen a zpřístupněn. Představuje také jeden nebo více atributů, které definují vlastnosti pro objekt metadat. Pro správu ML lze Atlas Type System použít k definování nových typů, zachycujících entity a procesy ML jako objekty metadat Atlasu. Kromě definice typů je k vizualizaci toku linie end-to-end vyžadován také vztah mezi entitami a procesy.
Pokud to vztáhneme k výše popsanému příkladu webové stránky s rozvozem jídla, systém Atlas Type System poskytuje dobrý základ pro definování linie strojového učení. Zobecněný systém linie ML je vizualizován následovně:
Jak je zřejmé z výše uvedeného diagramu, definice metadat pro strojové učení úzce sleduje skutečný pracovní postup strojového učení. Tréninkové datové sady jsou výchozím bodem pro tok modelové linie. Tyto datové sady mohou být tabulky z datového skladu nebo vložený soubor csv. Jakmile je soubor dat identifikován, následuje linie školení, budování a nasazení modelu.
Vývoj funkcí ML je paralelní a specializovaná činnost, kterou lze nazvat jako inženýrství funkcí (odlišné od modelového inženýrství). Dnes v mnoha případech tyto dvě činnosti (modelové inženýrství a feature engineering) provádí stejná osoba nebo tým. S demokratizací a industrializací funkcí by se to mohlo v budoucnu změnit, se specializovanými týmy pro vývoj modelů a vývoj funkcí.
Systém typů ML lze nyní definovat pomocí následujících nových typů:
„Vytvořit projekt strojového učení“ a „Projekt strojového učení“
Jeden projekt strojového učení představuje jeden případ obchodního použití. Projekt strojového učení představuje kontejner souborů a dalších vložených prostředků. Metadata projektu obsahují minimálně:
- Seznam souborů použitých v modelu
- Historická verze všech souborů
- Nejjednodušší implementací by bylo udržovat projekt jako git repozitář spoléhající na Git, který udržuje historii všech souborů.
„Soubor dat pro školení“
Podtyp datové sady v Atlasu, který představuje trénovací datovou sadu. Entita Training Data Set se používá v procesu trénování modelu. Může být spojen s prvkem, pokud jsou vygenerovaná data výsledkem aplikace extrakce (nebo transformace) prvku na jinou sadu dat.
„Train and build“
Proces, který představuje akci školení a budování modelu. Zahrnuje spouštění experimentů, ladění a dokončování výběru tréninkového algoritmu. Proces Train and Build Process by mohl volitelně spotřebovávat výstup sestavení funkce; například knihovní funkce definující extrakci prvků používanou interně modelem.
„Sestavení modelu“
Model je zpevněn a verzován, jakmile datový vědec dokončí experimentování a trénování modelu. Výsledkem tohoto zpracování je sestavení modelu, což je neměnný artefakt, který tvoří stavební blok pro produkci modelů. Obrázek Dockeru je příkladem entity Model Build.
„Model nasazení“ a „Nasazení modelu“
Sestavení modelu prochází procesem nasazení, který vytvoří nasazení modelu. Model Deployment představuje aktivní konkretizaci modelu. Služba REST založená na Kubernetes (nasazení ve stylu FaaS) je příkladem entity Model Deployment.
„Funkce funkcí“
Funkce strojového učení má dvě interpretace:1) Funkce funkce a 2) Transformovaná sada dat.
Entita Feature Function je vlastní funkce (vyjádřená v kódu), která definuje, jak extrahovat identifikovaný prvek ze vstupu. Toto představuje kód pro funkce, podobně jako ML Project představuje kontejner pro kód ML.
Funkce Feature je nejprve zabalena jako knihovna (verzovaná a zesílená). Knihovna je poté spotřebována a aplikována na danou sadu DataSet k její transformaci na novou sadu DataSet (s extrahovanými funkcemi). Transformovaná datová sada je reprezentována výše definovanou entitou tréninkové datové sady.
„Funkce balíčku“ a „Sestavení funkce“
Kód ve funkci Feature Function je zabalen pro sdílení (s jinými modely) nebo pro hodnocení za běhu. Tyto balíčky se nazývají Feature Builds. Feature Build může například obsahovat zabalenou knihovnu (v pythonu) nebo soubor jar (v Javě). Tento balíček může být absorbován během procesu modelování vlaku a sestavení, aby bylo zajištěno, že stejná funkce bude použita během extrakce i předpovědi.
Vyzkoušejte a zapojte se do definování budoucnosti definice metadat ML
Zahájili jsme práce na ATLAS-3432, což je první implementace systému Machine Learning Type System využívající Cloudera Data Science Workbench (CDSW) jako pilotního klienta. Děkuji Na Li z inženýrského týmu Cloudera za vedení práce na budování integrace CDSW. ATLAS-3432 umožní přenesení metadat modelu z instance CDSW do instance Apache Atlas za účelem prozkoumání linie. CDSW v současné době nepodporuje funkce (nebo úložiště funkcí), takže linie související s funkcemi nebudou k dispozici.
Ve společnosti Cloudera tento problém pro naše zákazníky nechceme jednoduše vyřešit – věříme, že definice metadat ML by měly být univerzální, podobně jako jsou tabulky, sloupce atd. velmi standardní pro datové struktury. Doufáme, že komunity přispějí k definování tohoto standardu a pomohou společnostem co nejlépe využít jejich platformy ML.
Máte případ použití řízení strojového učení, který nezapadá do modelu metadat? Zapojte se do konverzace zasláním svých návrhů na adresu [email protected].