Тъй като ML се развива от изследвания към бизнес приложения, така и ние трябва да подобрим ефективността на неговите оперативни процеси.

Стартираща компания наскоро нае Хари като специалист по данни. Неговата работа е да използва придобитите си знания за машинното обучение (ML), за да изгради прогнозен модел, за да определи дали имотите може да имат застрахователни искове през определен период. Хари изгражда добър модел и всички показатели за ефективност изглеждат страхотно, демонстрациите карат челюстите да паднат и ръководителите да питат колко скоро Хари може да разработи модел в производство.

Мислите си, че трябва да е доста бързо. В края на краищата, Хари вече е решил всички сложни dy/dx проблеми, така че всичко, което остава, е рутинна ИТ работа. Колко трудно може да бъде?

Доста трудно, оказва се.

Според доклад на Algorithmia „„2020 State of Enterprise Machine Learning““, много компании не са разбрали как да постигнат целите си за ML/AI. Тъй като преодоляването на празнината между изграждането на ML модел и практическите внедрявания все още е предизвикателна задача. Има фундаментална разлика между изграждането на ML модел в модела на преносим компютър Jupyter и внедряването на ML модел в производствена система, която генерира бизнес стойност. Въпреки че бюджетите за AI се увеличават, само 22 процента от компаниите, които използват машинно обучение, са внедрили успешно ML модел в производство.

Какво го прави толкова трудно? И какво трябва да направим, за да подобрим ситуацията?

„Създаването на надеждни системи за машинно обучение на производствено ниво води до множество проблеми, които не се срещат в примери за малки играчки или дори големи офлайн изследователски експерименти.“ — Резултатът от теста за ML: Рубрика за готовност за производство на ML и намаляване на техническия дълг

ПРЕДИЗВИКАТЕЛСТВА

Нека започнем с обсъждане на настоящите предизвикателства, пред които са изправени учените за данни, когато привеждат в действие своите модели и ги предоставят в производство.

  1. проследяването на смисловите модели, които сме обучили, е трудно.
  2. следене на различните версии на кода, стойности за различните хипер параметри в показателите, които оценяват.
  3. следене кои идеи са били изпробвани, кои са работили и кои не. (методология)
  4. Възпроизвеждайте го и го стартирайте на пълни производствени данни. Възпроизводимостта е основен проблем, тъй като има учени, които искат да могат да пуснат отново най-добрия модел с по-обширен анализ на параметрите.
  5. Освен това, за производствено приложение, моделът трябва да се актуализира редовно, когато постъпват нови данни, така че проследимостта става от първостепенно значение.

ПРЕМОСТЯВАНЕ НА РАЗЛИКИТЕ В РАЗГЛЕЖДАНЕ

Нека разгледаме проект за машинно обучение по начина, по който би направил оперативен човек. В един ред разглеждате цялата система по отношение на време, ресурси и качество. Как да намалите времето между анализирането на проблема, създаването на моделите и внедряването на решението, като същевременно поддържате качеството на изхода. В софтуерното инженерство този подход се нарича DevOps. Можем да заимстваме термина в машинното обучение и да го наречем MLOps.

DevOps направиха възможно изпращането на софтуера до производство за минути и поддържането му да работи надеждно. DevOps разчита на инструменти, автоматизация и работни процеси, за да абстрахира случайната сложност и да позволи на разработчиците да се съсредоточат върху действителните проблеми, които трябва да бъдат разрешени. Този подход е толкова успешен, че много компании вече са умели в него, така че защо не можем просто да продължим да правим същото за ML?

Причината е, че разработката на базирани на машинно обучение приложения е фундаментално различна от разработката на традиционния софтуер. Пълният процес на разработка включва три нива на промяна: Данни, ML модел и Код. Това означава, че в системите, базирани на машинно обучение, тригерът за изграждане може да бъде комбинацията от промяна на кода, промяна на данните или промяна на модела. Това е известно още като принципа „Промяната на всичко променя всичко“.

Има три често срещани проблема, които влияят на стойността на ML моделите, след като са в производство.

Първият е качеството на данните: тъй като ML моделите са изградени върху данни, те са чувствителни към семантиката, количеството и пълнотата на входящите данни.

Второто е упадъкът на модела: производителността на ML моделите в производството се влошава с времето поради промени в данните от реалния живот, които не са били наблюдавани по време на обучението на модела.

Третият е местоположението: когато прехвърляте ML модели на нови бизнес клиенти, тези модели, които са били предварително обучени за различни потребителски демографски данни, може да не работят правилно според показателите за качество .

Тъй като ML/AI се разширява в нови приложения и оформя нови индустрии, изграждането на успешни ML проекти остава предизвикателна задача. Както е показано, има нужда от установяване на ефективни практики и процеси около проектирането, изграждането и внедряването на ML модели в производство.

ДАННИ И ML ТРЪБОПРОВОД

Най-важната концепция на Data Engineering е Data pipeline. Тръбопроводът за данни е поредица от трансформации, които се прилагат към данни, преди да могат да бъдат използвани от ML модел. Събирането на добри данни играе основна роля в производителността и качеството на ML модел.

Конвейерът за инженеринг на данни включва последователност от операции върху наличните данни. Крайната цел на тези операции е да се създадат набори от данни за обучение и тестване за алгоритмите за машинно обучение. Повечето ML модели ще изискват две версии на тръбопровода: една за обучение и една за обслужване.

ML Pipeline е артефакт от чист код, независим от конкретни екземпляри на данни. Това означава, че е възможно да се проследяват версиите му в контрола на източника и да се автоматизира внедряването му с обикновен CI/CD тръбопровод, основна практика в DevOps.

Целта на CI/CD е автоматично да изгражда, тества и безопасно внедрява вашето приложение, така че да можете да повтаряте бързо, когато разработвате нов софтуер.

CI/CD IN ML

Това също се нарича CI/CD и означава непрекъсната интеграция / непрекъсната доставка.

ML моделите могат да бъдат внедрени като микроуслуга. Ако лесно искате да създадете микроуслуга, трябва да използвате Docker. Можете да контейнеризирате приложението си. Това означава, че можете да сте сигурни, че работи по абсолютно същия начин във вашата локална машина.

Непрекъсната интеграция

Когато изграждате вашата микроуслуга, вие създавате Docker Image. Това е шаблон, който казва на Docker точно как да изгради вашата микроуслуга от вашия код. Тук можете да стартирате частта CI (непрекъсната интеграция) от парадигмата CI/CD.

Тук можете да тествате качеството на вашия код, да изпълнявате тестове на единици и да измервате времето за прогнозиране на вашите модели. Само след като тези тестове са преминали успешно, вие изграждате и натискате своя Docker образ. Това гарантира, че вашата микроуслуга работи правилно.

Непрекъснато внедряване

След като създадохте вашите промени и успешно изградихте и качихте вашето Docker изображение, време е да стартирате страхотната си нова ML микроуслуга. Няма значение къде работи вашето приложение. Може да е в облака, локална машина или на ръба, процесът на внедряване винаги е един и същ.

Изпълнение на множество микроуслуги

Повечето пъти в производството имате множество контейнери, работещи заедно, които също трябва да комуникират помежду си. Това е мястото, където ще ви е необходим оркестратор на контейнери. Kubernetes е чудесен инструмент за това. След няколко минути можете да създадете работещ клъстер Kubernetes в Google Cloud Platform или Azure.

ПРОВЕРКА НА ДАННИ И МОДЕЛИ

Един добър канал за данни трябва да започне с валидиране на входните данни. Общата проверка включва файлов формат и размер, типове колони, нулеви или празни стойности и невалидни стойности. Всички те са необходими за обучение и прогнозиране на ML, в противен случай може да се окажете с неправилно работещ модел и да се почешете по главата, търсейки причината. Поради това е препоръчително да съхранявате вашите очаквания за функции в схема или yaml файл. Докато традиционният софтуер може да разчита на модулни тестове и интеграционни тестове на кода, тук се опитваме да добавим достатъчен набор от тестове на данните.

ML моделите са по-трудни за тестване, защото никой модел не дава перфектни резултати. Това означава, че тестовете за валидиране на модела трябва да бъдат статистически по природа, вместо да имат твърдения. За да решите дали даден модел е достатъчно добър за внедряване, трябва да вземете решение за правилните показатели за проследяване и прага на техните приемливи стойности, обикновено емпирично и често чрез сравнение с предишни модели или бенчмаркове.

В допълнение към основните валидации, които всеки тръбопровод за данни изпълнява, тръбопроводите за ML трябва също така да валидират статистически свойства на по-високо ниво на входа. Например, ако средното или стандартното отклонение на характеристика се промени значително от един набор от данни за обучение в друг, това вероятно ще повлияе на обучения модел и прогнозите. Това може да е отражение на действителна промяна в данните или може да е аномалия, причинена от начина на обработка на данните, така че е важно да проверите и изключите системни грешки като причини, които биха могли да замърсят модела, и да ги коригирате, ако е необходимо

МОНИТОРИНГ

В производството искате да сте сигурни, че производителността на вашия модел не намалява. Ефективността на ML модела трябва да се наблюдава въз основа на реални и невиждани преди това данни. MLflow е добра рамка за наблюдение на ефективността на модела. С MLflow можете лесно да регистрирате информация за входа на модела (хиперпараметри) и вашия показател за ефективност.

По-специално, ние се интересуваме от специфични за ML сигнали, като отклонение на прогнозата от представянето на предишния модел. Тези сигнали могат да се използват като тригери за повторно обучение на модела.

Точно както имаме CI/CD в традиционната разработка на софтуер, MLOs също имат CT/CM практики.

  • Непрекъснатото обучение (CT) е уникално свойство на ML системите, което автоматично преобучава моделите на ML за повторно внедряване.
  • Непрекъснатият мониторинг (CM) се занимава с мониторинг на производствените данни и показателите за ефективност на модела, които са обвързани с бизнес показателите.

MLOps ИНФРАСТРУКТУРЕН СТЕК

Изграждането на ML модели е итеративен подход. Това изисква интензивно количество експерименти. Преди който и да е ML модел да може да бъде разгърнат в производство, той трябва да е преминал през много експериментални цикли, за да се идентифицира правилният ML модел, който постига бизнес целите.

Тази фаза на експериментиране добавя допълнителна сложност към всеки ML проект, тъй като включва три основни артефакта: Данни, Модел и Код. За да управляваме тази сложност, имаме нужда от добре дефинирани структури, процеси и подходящи софтуерни инструменти, които управляват ML артефакти и обхващат цикъла на машинно обучение.

Технологичният стек MLOps трябва да включва инструменти за следните задачи:

  • инженеринг на данни,
  • контрол на версиите на данни, ML модели и код,
  • непрекъсната интеграция и непрекъснати тръбопроводи за доставка,
  • автоматизиране на внедрявания и експерименти,
  • оценка на ефективността на модела и
  • мониторинг на модела в производството.

В зависимост от изискванията или ограниченията, организациите могат да внедрят своя собствена MLOps система чрез комбиниране на съществуващи библиотеки с отворен код. За да се изгради такава система, човек трябва да има преглед на ландшафта на инструментите MLOps.

РЕЗЮМЕ

MLOps е нова област и най-добрите практики все още не са там. Тъй като машинното обучение узрява от изследвания до случаи на бизнес употреба, трябва да подобрим оперативните процеси.

Споделете и вашите мисли.

Ако имате въпроси, можете да ме намерите тук:

ПРЕПРАТКИ