Добивки:
- Способност да се препознаат посебните предизвици на ML поврзани со триото и пакетот код-податоци-модел и да се презентира моделот онлајн или во серија според деловните потреби.
- Способност да се имплементираат шаблони за постепено и враќање назад (сенка, канари, A/B, враќање) и додавање на тестиран план за враќање на секое распоредување
- Способност да се одржи врската податоци-код-метрички на моделот пуштен во производство, со CI/CD контролирани со праг на евалуација и регистар на модели
Да се добие модел за постигнување 95% точност во тетратката е само половина од приказната. Другата половина - честопати напорниот дел - е да се добие тој модел до вистинските корисници на сигурен, скалабилен и одржуван начин. MLOps (Операции за машинско учење: дисциплина на ставање, работење и одржување на ML модели во производство) ги комбинира практиките на DevOps на софтверското инженерство со уникатните предизвици на ML. Во оваа единица, ги покриваме чекорите за преместување на моделот во производство и како вештачката интелигенција помага во овој процес.
Зошто ML се разликува од обичниот софтвер?
Во обичниот софтвер, однесувањето е во кодот; Ако кодот не се промени, однесувањето не се менува. Во ML, однесувањето зависи и од кодот, податоците и моделот. Овие три димензии создаваат дополнителни предизвици на MLOps:
- Поместување на податоците: Податоците во производството се оддалечуваат од податоците во обуката со текот на времето; моделот станува застарен.
- Треба да верзијата на три работи: код, податоци и модел - сите три.
- Тивко неуспех: моделот може да пропадне без да падне, без да дава грешки, едноставно со производство на неточни предвидувања. Фаќањето на ова бара следење.
Затоа има голема разлика помеѓу „работен модел“ и „модел подготвен за производство“.
Модел пакување и презентирање
Првиот чекор во ставањето на моделот во производство е негово пакување: датотеката за моделот, потребните библиотеки, кодот за претходна обработка и информациите за верзијата заедно како целина што може да се репродуцира. Контејнеризацијата (на пр. Docker: ставање на апликацијата во изолирана кутија со сите нејзини зависности) е стандардна овде; Го елиминира проблемот „работи на мојата машина“.
Два основни модели на сервирање на моделот:
- Онлајн/во реално време (онлајн): Моделот стои зад API, враќајќи инстант предвидување за секое дојдовно барање. Ниската латентност е критична.
- Серија: Моделот периодично обработува големи збирки податоци (на пр. генерира резултати за сите клиенти ноќе). Латентноста е ирелевантна, ефикасноста е важна.
Кој е во право зависи од деловните потреби: инстант препорака онлајн, месечен резултат на ризик во серија.
Совет: „Во реално време“ е трошок, а не стандарден. Серијата е многу поевтина и поедноставна ако резултатот ќе се искористи за неколку часа. Дали навистина ви треба моментален одговор? Прашај го тоа прво.
Сигурни стратегии за дистрибуција
Отворањето нов модел директно за целиот сообраќај е ризично; Ако е погрешно, сите се засегнати. Модели за безбедна дистрибуција:
- Распоредување во сенка: Новиот модел добива производствен сообраќај, но неговите предвидувања не се прикажуваат на корисникот, туку само евидентирани. Се споредува со стариот модел за да се види дали е безбеден во реални податоци.
- Распоредување на Канари: Новиот модел најпрво е претставен на мал процент од сообраќајот (на пр. 5%); Ако нема проблем, постепено се зголемува.
- А/Б тестирање: На вистинскиот корисник паралелно му се презентираат два модели и се споредуваат деловните метрики (конверзија, кликови).
- Враќање: Способност за брзо враќање на старата верзија ако новиот модел се покаже дека е лош. Секое распоредување треба да има план за враќање.
Внимание: распоредувањето без план за враќање не е завршено. Можноста за враќање на старата верзија за неколку минути го штити корисникот кога новиот модел се однесува неочекувано во производството. Тестирајте го ова пред распоредувањето.
Слаб пристап / Силен пристап
Слаб: „Моделот беше добар во тестирањето, отидовме во живо, го отворивме за сите“.
Güçlü: "Го контејнеризиравме моделот, го означивме како верзија. Прво, го работевме во режим на сенка со производствен сообраќај 3 дена, споредувајќи ги предвидувањата со стариот модел - отстапувањето беше прифатливо. Потоа го отворивме со 5% канари, ги следевме метриките на пропусната моќ и доцнењето. Кога немаше проблеми, постепено го зголемивме 0 наназад на команда пред 1%.
Разликата: силниот пристап е постепен, измерен и реверзибилен. Ризикот е ограничен на секој чекор.
CI/CD и автоматизација
CI/CD (Континуирана интеграција / Континуирано распоредување: цевковод за автоматско тестирање и ослободување на промените на кодот) во ML го опфаќа не само кодот, туку и чекорите на податоците и моделот. Добар ML CI/CD гасовод: извршува тестови кога кодот се менува, врши валидација на податоците, го преквалификува моделот (доколку е потребно), ги проверува праговите за евалуација и го унапредува распоредувањето само ако праговите стојат. Принципот на „тренингот е автоматски, распоредувањето е засновано на праг“ го спречува лошиот модел тивко да протече во производство.
Вештачката интелигенција е многу корисна при поставувањето на овие цевки: пишување нацрти за конфигурациска датотека (YAML), тест случаи, скрипти за распоредување. Но, вие ги одредувате праговите на дистрибуција (која и да е метрика ја надминува вредноста што е објавена) и политиката за враќање назад; ова се одлуки за деловниот ризик.
Инфраструктура за репродуктивност
Со цел да се репродуцира однесувањето на моделот во производството, регистар на модели: запис кој води кој модел бил обучен со кои податоци и код, и кои метрики ги добил. За секој производствен модел, следново треба да може да се следи: верзија на податоци за обука, верзија на код (git commit), хиперпараметри, оценки за евалуација и датум на распоредување. Кога ќе се појави проблем, треба да можете да одговорите на прашањето „кој модел го произведе ова предвидување, со кои податоци? во рок од неколку минути. Ова ќе го продлабочиме во единицата 11.
три мини футроли
Случај 1 - Проблем фатен со дистрибуција на сенка. Модел со препораки го победи стариот при тестирањето. Утврдено е дека пуштањето со производствен сообраќај во режим на сенка дава многу лоши препораки за одреден сегмент на корисници (нови корисници) - податоците од тестот не го претставуваа овој сегмент. Моделот беше поправен без никогаш да му се прикаже на корисникот. Доколку се отвори директно, новото корисничко искуство би било нарушено.
Случај 2 - Неотповиклива распределба. Тим претстави нов модел на цени за целиот сообраќај, без планови за враќање. Моделот неочекувано цени некои производи многу евтини. Враќањето на старата верзија траеше со часови бидејќи процесот не беше подготвен. Имаше сериозна загуба на приход. Потоа, задолжителното тестирање за враќање беше додадено на секое распоредување.
Случај 3 - Тивко поместување на податоци. Шема за измама се појавуваше со месеци без никакви грешки. Но, тактиката на измамниците се смени (повлекување на податоците) и отповикувањето на моделот тивко падна. Никој не забележа бидејќи немаше мониторинг. Откако беше воспоставен панел за следење на дистрибуцијата на прогнозите, наносот стана видлив рано. Мониторингот ќе го опфатиме во единица 8.
Шаблони за копирање
Напишете нацрт план за распоредување за овој модел. Модел: [што прави], употреба: [онлајн или серија?] Треба да вклучува: 1) Пакување (контејнер, верзии) 2) Стратегија за постепено распоредување (сенка/канари/А-Б) и зошто3) Метрика за следење (деловен + технички + латентност) 4) план за враќање и како да се тестира 5) која треба да ја надмине старата вредност на распоредувањето
Проверете ја оваа линија ML CI/CD:1) Дали валидацијата на податоците е во линијата?2) Дали распоредувањето може да продолжи без да се задржи прагот за евалуација (да не треба)?3) Дали враќањето е автоматско?4) Дали податоците+код+метриката се следат во регистарот на модели? Конфигурација на Pline: [config]
Помогнете ми да одлучам дали онлајн или сериската презентација е погодна за овој модел. Колку долго ќе се користи резултатот: [инстант / минута / час / ден] Очекуван волумен на барање: [број] Дали има ограничување за доцнење: [ms]Кое би го препорачале во однос на трошоците и сложеноста и зошто?
Напишете постапка за враќање назад за овој модел.- Која метрика/праг предизвикува слаби перформанси?- Кои се чекорите за враќање назад?- Колку долго треба да трае враќањето назад (цел)?- Како да ја тестирам оваа постапка пред производството?
Табела со шаблони за презентација
критериум
Онлајн (во реално време)
Серија
одложување
Критични (ms)
незначителен
Употреба
Потребен е моментален одговор
Периодичен резултат
Цена
високо
низок
сложеност
високо
низок
пример
Препорака во живо, измама
Месечен резултат за ризик
Вообичаени грешки
- Дистрибуирајте без план за пронаоѓање. Погрешен модел го погодува целиот корисник.
- Отворање директно до 100% сообраќај. Ограничете го ризикот со скалеста дистрибуција.
- Не воспоставување мониторинг. Моделот произведува грешки тивко, без грешка.
- Непотребна презентација во реално време. Додека сериите се доволни, цената и сложеноста се зголемуваат.
- Не се поврзуваат верзии на модел-податоци-код. Не можете да го репродуцирате проблемот.
- Автоматско ослободување без праг на дистрибуција. Лошиот модел нечујно се прикрадува.
Сумирано
Преместувањето на моделот во производство е поинаква и често потешка инженерска задача отколку обуката. ML бара дополнителна дисциплина бидејќи зависи од триото код-податоци-модел: пакување и верзии, шема на испорака (онлајн/серија) што одговара на деловните потреби, постепено и реверзибилно распоредување, CI/CD контролирани со праг и регистрација на модел. Вештачката интелигенција е моќна помош за генерирање на кодот и конфигурацијата на оваа инфраструктура; но ваши се праговите за дистрибуција, политиката за повраток и одлуките за ризик. Дистрибуцијата без план за враќање не е целосна.
Задача за апликација
Контејнеризирајте (Docker) модел и означете го како верзија. Одлучете дали ќе понудите онлајн или серија врз основа на вашите деловни потреби и напишете го вашето оправдување. Документирајте фазен план за распоредување (сенка или канари) и тестирана процедура за враќање назад. Погрижете се да ја запишете верзијата на податоците, обврзувањето на кодот и резултатите од евалуацијата во регистарот на модели.
листа за проверка
- [ ] Моделот е спакуван и изведен (контејнер + етикета).
- [ ] Шемата за презентација (онлајн/серија) беше избрана според деловните потреби.
- [ ] Спроведена е стратегија за распоредување во фаза (сенка/канари).
- [ ] Постапката за враќање назад напишана и тестирана.
- [ ] CI/CD не го унапредува распоредувањето пред да се исполни прагот за евалуација.
- [ ] Регистарот на модели ја содржи врската податоци+код+метричка.