Машинното обучение (ML) се превърна в една от най-критичните способности за растеж и конкурентоспособност на съвременния бизнес днес. От автоматизиране на вътрешни процеси до оптимизиране на процесите на проектиране, създаване и маркетинг зад почти всеки консумиран продукт, моделите на ML са проникнали в почти всеки аспект от нашата работа и личен живот — а за бизнеса залогът никога не е бил по-висок. Неуспехът да се приеме ML като основна компетентност ще доведе до големи конкурентни недостатъци, които ще определят следващите пазарни лидери.
Поради това лидерите в бизнеса и технологиите трябва да внедрят модели на ML в цялата си организация, обхващащи широк спектър от случаи на употреба. Това чувство за неотложност обаче, съчетано с нарастващ регулаторен контрол, създава нови и уникални предизвикателства в управлението, които в момента са трудни за управление. Например:Как моите модели влияят на услугите, предоставяни на крайни клиенти? Все още ли спазвам както държавните, така и вътрешните разпоредби? Как правилата ми за сигурност ще се преведат в моделите в производство?
Освен регулаторни или правни проблеми, има редица причини да има процеси и процедури на управление за машинното обучение. Примерите включват начини за повишаване на производителността (като повторно използване на активи като модели и функции), контролиране и поддържане на модели в много различни бизнес линии, за да се гарантира, че критичните за бизнеса приложения правят това, което са предназначени (или намират тези, които не са) и виждате история на модели и прогнози, включително оттеглени активи.
При справянето с тези предизвикателства си струва да определим какви модели и характеристики представляват концептуално (виж фигура 1). Съществуват много различни дефиниции, но като цяло моделът е всеки самостоятелен пакет, който взема функции, изчислени от входни данни, и произвежда прогноза (или резултат) и метаданни. Този пакет може да приеме много форми, но винаги включва математическо представяне, код, бизнес логика и данни за обучение. Прогнозите на модела се консумират надолу по веригата от системите или потребителите.
Много предприятия работят с инфраструктура за модел на ML с различни размери и зрялост, така че се нуждаят от инструменти, които да им помогнат да управляват своите модели. В крайна сметка нуждите от управление на МО могат да бъдат дестилирани в следните ключови области:видимост; и обяснимост, интерпретируемост и възпроизводимост на модела.
Фигура 1
Видимост на модели и функции в екипи и в организации
Основно изискване за управление на модела е да даде възможност на екипите да разберат как машинното обучение се прилага в техните организации. Това изисква каноничен каталог с модели и функции. При липсата на такъв каталог много организации не са наясно с техните модели и функции, къде са разположени, какво правят и т.н. Това води до преработка, непоследователност на модела, функции за повторно изчисляване и други неефективност.
Обяснимост, интерпретируемост и възпроизводимост на модела
Моделите често се разглеждат като черна кутия:влизат данни, нещо се случва и излиза прогноза. Тази непрозрачност е предизвикателство на редица нива и често е представена в слабо свързани термини като:
- Обяснимост :описание на вътрешната механика на ML модел в човешки термини
- Интерпретируемост :способността а) да се разбере връзката между входните данни, характеристиките и изходите на модела и б) да се предвиди реакцията на промените във входните данни.
- Възпроизводимост :способност за възпроизвеждане на изхода на модел по последователен начин за едни и същи входни данни.
Всичко това изисква обща функционалност, включително връзка с изходните данни, ясно разбиране на вътрешните елементи на моделите, като код и данни за обучение, и други методи за изследване и анализиране на самите модели.
Метаданни на модела с пример
За да се справим с проблемите на управлението, дефинирани по-горе, нека започнем с един пример. Помислете за уебсайт за доставка на храна. Компанията иска да използва машинното обучение, за да изчисли времето за доставка.
Наборът от данни за обучение се състои от регистрационни файлове на събития от предишни доставки, които съдържат времената на доставка за всяка извършена в миналото доставка. Тези данни се използват за обучение на модел за оценка на бъдещите времена за доставка.
Регистърът на събитията може да изглежда така:
Поръчка е била направена в 10 сутринта за вземане на храна от loc1 и доставка до loc2. Куриерът го взе от ресторанта в 10:15 ч. и го достави в 10:55 ч., което отнема общо 55 минути от поръчката до доставката
Да приемем, че loc1 и loc2 са улични адреси. Това е съкратено тук, за да е кратко и лесно за четене.
Регистраторите на събитията се съхраняват в HBase. Инженерната архитектура за разработване на модела е както следва:
- Инженерите на данни идентифицират времевия прозорец на регистрационните файлове за събития, които да се използват за решаване на проблема. Нова структурирана таблица Hive се създава чрез синтактичен анализ на необработените дневници на събития с идентифицирания времеви прозорец.
- Инженерите на функции (това може да бъде роля в учените по данни или инженерите за ML) идентифицират и разработват нови функции:
- Функция в час пик:Функция за идентифициране дали съществуват условия в час пик, като се има предвид местоположение и час.
- Характеристика на „заетостта“ на ресторанта:Функция за идентифициране дали даден ресторант изпитва дълго време на чакане въз основа на исторически данни. Тези исторически данни се събират отделно.
- Идентифицираните по-горе функции след това се създават като библиотека на python за повторна употреба.
- Тази библиотека се използва за прилагане на функцията към структурираната таблица Hive за създаване на нова таблица, която ще бъде окончателният набор от данни за обучение. Ред в новата таблица изглежда така:
Да приемем, че loc1 и loc2 са улични адреси. Това е съкратено тук, за да е кратко и лесно за четене.
- Учените за данни извършват линейна регресия на набора от данни за обучение, за да предскажат времето за доставка. В този момент те трябва да използват същата библиотека с функции, която е била използвана за извличане на функциите в набора от данни за обучение.
- Моделът се внедрява като крайна точка Function-as-a-Service (FaaS), използвана от уеб приложението за предвиждане на времето за доставка.
Имайте предвид, че моделът трябва да изчисли характеристиките за прогнозиране в реално време. Тези функции са библиотеки, които се използват вътрешно от модела. Визуализация на различните извършени дейности и артефакти, генерирани в този пример, може да изглежда така:
Сините полета представляват ML обекти (съществителни), като код, проект, компилации, внедряване и т.н. Зелените полета представляват процеси (глаголи), които действат върху обекти и произвеждат други обекти.
Визуализацията и връзките, които дефинират трансформациите в структурата на данните, се наричат общо като родословие . В света на базата данни добавянето на нова колона към таблица ще промени нейния произход. В света на машинното обучение преквалификацията на модел чрез използване на функции и набори от данни ще промени рода. За уебсайта за доставка на храна, за да отговорим на въпроса:„има ли разлика между извличането на характеристиките по време на обучение и точкуването“, имаме нужда от информацията за родословието. Това е само един пример за полезността на метаданните по рода в света на машинното обучение.
Apache Atlas като инструмент за управление
Очевидно е, че изграждането на пълна линия от край до край за работните потоци за ML – от набори от обучителни данни до внедряване на модели – се превръща в ключово изискване за справяне с идентифицираните проблеми с управлението. Интегрирането на управлението на данни и машинното обучение трябва да даде възможност за обяснимост, интерпретируемост и възпроизводимост.
Събирането, съхранението и визуализирането на метаданни за ML се нуждае от стандартна бекенд софтуерна система. Една отворена и разширяема дефиниция на метаданни ще позволи стандартизиране на операциите по управление, независимо от това къде се разработват или обслужват моделите. Очевидният кандидат за Cloudera (и нашите клиенти) е Apache Atlas.
Apache Atlas вече е набор от широко използвани инструменти за управление с предварително дефинирани типове метаданни за управление на данни. В контекста на управлението на ML, той е много подходящ за дефиниране и улавяне на метаданните, необходими за концепциите за машинно обучение. Освен това Apache Atlas предоставя разширени възможности като класификации, интеграция с Apache Ranger (за оторизация и маркиране), за да назовем само няколко, и има разширяема система за добавки, която позволява на общността да си сътрудничи и постепенно да дефинира интеграции към различни други инструменти в ML пространство. Остава като упражнение на читателя да изследва потребителския интерфейс на Apache Atlas и да види как да използва тези възможности.
Определение на метаданните на ML в Apache Atlas
Системата за тип Apache Atlas отговаря на всички наши нужди за дефиниране на обекти с метаданни на ML. Той е с отворен код, разширяем и има предварително изградени функции за управление. Типът в Atlas е дефиниция за това как се съхранява и осъществява достъп до определен тип обект с метаданни. Той също така представлява един или повече атрибути, които определят свойствата на обекта с метаданни. За управление на ML, Atlas Type System може да се използва за дефиниране на нови типове, улавяйки ML обекти и процеси като обекти с метаданни на Atlas. В допълнение към дефиницията на типовете, връзката между обектите и процесите също е необходима за визуализиране на потока от край до край.
Ако свържем това с примера на уебсайта за доставка на храна, описан по-рано, системата Atlas Type предоставя добра основа за дефиниране на линията на машинното обучение. Обобщена система за ML линия се визуализира по следния начин:
Както е видно от диаграмата по-горе, дефиницията на метаданните за машинно обучение следва тясно действителния работен процес на машинно обучение. Наборите от данни за обучение са отправната точка за потока на модела. Тези набори от данни могат да бъдат таблици от склад за данни или вграден csv файл. След като наборът от данни бъде идентифициран, родословието следва обучение, изграждане и внедряване на модела.
Разработването на функции за ML е паралелна и специализирана дейност, която може да се нарече инженеринг на функции (различно от моделното инженерство). Днес в много случаи двете дейности (инженеринг на модели и инженеринг на характеристики) се извършват от едно и също лице или екип. С демократизацията и индустриализацията на функциите това може да се промени в бъдеще със специализирани екипи за разработване на модели и функции.
Системата от типове ML вече може да бъде дефинирана чрез следните нови типове:
„Създаване на проект за машинно обучение“ и „Проект за машинно обучение“
Един проект за машинно обучение представлява един случай на бизнес употреба. Проектът за машинно обучение представлява контейнера с файлове и други вградени активи. Най-малкото метаданните на проекта съдържат:
- Списък на файловете, използвани в модела
- Историческа версия на всички файлове
- Най-простата реализация би била да се поддържа проектът като git хранилище, като се разчита на Git за поддържане на историята на всички файлове.
„Набор от данни за обучение“
Подтип на DataSet в Atlas, който представлява набор от данни за обучение. Обектът Набор от данни за обучение се използва в процеса на обучение на модела. Тя може да бъде свързана с характеристика, ако генерираните данни са резултат от прилагане на извличане (или трансформиране) на характеристики към друг набор от данни.
„Обучете и изградете“
Процес, който представлява действието на обучение и изграждане на модел. Включва провеждане на експерименти, настройка и финализиране на избора на алгоритъм за обучение. Процесът на обучение и изграждане може по избор да консумира изхода от изграждане на функция; например библиотечна функция, дефинираща извличане на характеристики, използвана вътрешно от модела.
„Изграждане на модел“
Моделът е закален и версиян, след като специалист по данни приключи експериментирането и обучението на модела. Тази обработка води до изграждане на модел, което е неизменим артефакт, който формира градивния елемент за производство на модели. Изображението на Docker е пример за обект за изграждане на модел.
„Разгръщане на модел“ и „Разгръщане на модел“
Изграждането на модел преминава през процес на разгръщане, който създава разгръщане на модел. Разгръщането на модела представлява активно инстанциране на модел. Базирана на Kubernetes REST услуга (разгръщане в стил FaaS) е пример за обект за разгръщане на модел.
„Функция за функции“
Функцията за машинно обучение има две интерпретации:1) Функция на функциите и 2) Трансформиран набор от данни.
Обектът Feature Function е персонализирана функция (изразена в код), която дефинира как да се извлече идентифициран елемент от вход. Това представлява кода за функции, подобно на това как ML Project представлява контейнера за ML код.
Функцията Feature първо е пакетирана като библиотека (версия и закалена). След това библиотеката се използва и прилага към даден набор от данни, за да се трансформира в нов набор от данни (с извлечени характеристики). Трансформираният набор от данни е представен от обекта на набора от данни за обучение, дефиниран по-горе.
„Функция на пакета“ и „Изграждане на функции“
Кодът във функцията Feature е пакетиран за споделяне (с други модели) или за оценка по време на изпълнение. Тези пакети се наричат Feature Builds. Например, Feature Build може да съдържа пакетирана библиотека (в python) или jar файл (в Java). Този пакет може да бъде усвоен по време на процеса на обучение на модела и изграждане, за да се гарантира, че същата функция се използва по време на извличане, както и при прогнозиране.
Изпробвайте и се включете в дефинирането на бъдещето на дефиницията на метаданни за ML
Започнахме работа по ATLAS-3432, което е първата реализация на системата за машинно обучение, използваща Cloudera Data Science Workbench (CDSW) като пилотен клиент. Благодарим на Na Li от инженерния екип на Cloudera за ръководенето на работата по изграждането на интеграцията на CDSW. ATLAS-3432 ще позволи метаданните на модела от CDSW екземпляр да бъдат пренасочени към екземпляр на Apache Atlas за изследване на родословието. CDSW понастоящем не поддържа функции (или магазин за функции), така че родословието, свързано с функции, ще бъде недостъпно.
В Cloudera не искаме просто да решаваме този проблем за нашите клиенти – вярваме, че дефинициите на метаданни за ML трябва да бъдат универсални, подобно на това как таблиците, колоните и т.н. са много стандартни за структурите от данни. Надяваме се, че общностите ще допринесат за дефинирането на този стандарт, за да помогнат на компаниите да извлекат максимума от своите платформи за машинно обучение.
Имате ли случай на използване на управление на машинно обучение, който не се вписва в модела на метаданните? Присъединете се към разговора, като публикувате вашите предложения на [email protected].
