Добици:
- Способност препознавања посебних изазова МЛ везаних за трио и пакет код-подаци-модел и представљање модела онлајн или у пакету у складу са пословним потребама.
- Способност имплементације постепених и поништавајућих образаца примене (сенка, канаринац, А/Б, враћање) и додавање тестираног плана враћања у свако примену
- Способност да се веза података-код-метрика модела стављена у производњу може пратити помоћу ЦИ/ЦД-а и регистра модела који контролише праг евалуације
Добијање модела за постизање 95% тачности у бележници је само пола приче. Друга половина — често најтежи део — је да се тај модел доведе до стварних корисника на поуздан, скалабилан и одржив начин. МЛОпс (Операције машинског учења: дисциплина стављања, рада и одржавања МЛ модела у производњу) комбинује ДевОпс праксе софтверског инжењеринга са јединственим изазовима МЛ. У овој јединици покривамо кораке премештања модела у производњу и како вештачка интелигенција помаже у овом процесу.
Зашто се МЛ разликује од обичног софтвера?
У обичном софтверу, понашање је у коду; Ако се код не промени, понашање се не мења. У МЛ, понашање зависи и од кода, и од података и од модела. Ове три димензије стварају додатне изазове МЛОпс-а:
- Померање података: подаци у производњи се временом удаљавају од података у обуци; модел постаје застарео.
- Потребно је да верзије три ствари: код, подаци и модел—све три.
- Тихи неуспех: Модел може да пропадне без пада, без давања грешака, једноставно стварајући нетачна предвиђања. Ухватити ово захтева праћење.
Зато постоји велика разлика између „радног модела” и „модела спремног за производњу”.
Паковање и презентација модела
Први корак у пуштању модела у производњу је његово паковање: фајл модела, неопходне библиотеке, код за претходну обраду и информације о верзији заједно као поновљива целина. Контејнеризација (нпр. Доцкер: стављање апликације у изоловану кутију са свим њеним зависностима) је овде стандардна; То елиминише проблем "радио је на мојој машини".
Два основна обрасца послуживања модела:
- На мрежи/у реалном времену (онлине): Модел се налази иза АПИ-ја, враћајући тренутно предвиђање за сваки долазни захтев. Мала латенција је критична.
- Група: Модел периодично обрађује велике скупове података (нпр. генерише резултате за све купце ноћу). Латенција је небитна, ефикасност је важна.
Који је прави зависи од пословне потребе: тренутна препорука на мрежи, месечна оцена ризика у групи.
Савет: „У реалном времену“ је трошак, а не подразумевани. Серија је много јефтинија и једноставнија ако се резултат искористи у року од неколико сати. Да ли вам је заиста потребан тренутни одговор? Прво то питај.
Сигурне стратегије дистрибуције
Отварање новог модела директно за сав саобраћај је ризично; Ако је погрешно, сви су погођени. Сигурни обрасци дистрибуције:
- Примена у сенци: Нови модел прима производни саобраћај, али његова предвиђања се не приказују кориснику, већ се само евидентирају. Упоређује се са старим моделом да би се видело да ли је безбедан у стварним подацима.
- Примена Цанари: Нови модел се прво примењује на мали проценат саобраћаја (нпр. 5%); Ако нема проблема, постепено се повећава.
- А/Б тестирање: Два модела се паралелно представљају стварном кориснику и пореде се пословни показатељи (конверзија, кликови).
- Враћање: Могућност брзог враћања на стару верзију ако се покаже да је нови модел лош. Свака имплементација треба да има план враћања.
Опрез: Примена без плана враћања није довршена. Могућност да се вратите на стару верзију у року од неколико минута штити корисника када се нови модел неочекивано понаша у производњи. Тестирајте ово пре постављања.
Слаб приступ / Снажан приступ
Слаб: „Модел је био добар у тестирању, изашли смо уживо, отворили смо га свима.“
Гуцлу: „Модел смо контејнерисали, означили га као верзију. Прво смо га покренули у режиму сенке са производним саобраћајем 3 дана, упоређујући предвиђања са старим моделом — одступање је било прихватљиво. Затим смо га отворили са 5% канаринца, пратили метрику протока и кашњење. Када није било проблема, постепено смо повећали команду пре 100%.
Разлика: снажан приступ је постепен, одмерен и реверзибилан. Ризик је ограничен на сваком кораку.
ЦИ/ЦД и аутоматизација
ЦИ/ЦД (Цонтинуоус Интегратион / Цонтинуоус Деплоимент: цевовод за аутоматско тестирање и објављивање промена кода) у МЛ-у покрива не само код већ и податке и кораке модела. Добар МЛ ЦИ/ЦД цевовод: покреће тестове када се код промени, врши проверу ваљаности података, поново обучава модел (ако је потребно), проверава прагове евалуације и само напредује у примени ако се прагови држе. Принцип „обука је аутоматска, примена је заснована на прагу“ спречава да лош модел тихо процури у производњу.
АИ је од велике помоћи приликом подешавања ових цевовода: писање нацрта конфигурационих датотека (ИАМЛ), тест случајева, скрипти за примену. Али ви одређујете прагове дистрибуције (који год показатељ премашује објављену вредност) и политику враћања; то су одлуке о пословном ризику.
Инфраструктура репродуктивности
Да би се репродуковало понашање модела у производњи, регистар модела: запис који чува који модел је обучен са којим подацима и кодом, и које метрике је примио. За сваки производни модел требало би да се прати следеће: верзија података за обуку, верзија кода (гит урезивање), хиперпараметри, резултати евалуације и датум примене. Када се појави проблем, требало би да будете у могућности да одговорите на питање "који модел је произвео ово предвиђање, са којим подацима?" у року од неколико минута. Ово ћемо продубити у јединици 11.
три мини кофера
Случај 1 – Проблем ухваћен дистрибуцијом сенке. Препоручени модел је победио стари у тестирању. Утврђено је да његово покретање са производним саобраћајем у режиму сенке даје веома лоше препоруке за одређени сегмент корисника (нови корисници) — подаци теста нису били довољно репрезентативни за овај сегмент. Модел је поправљен, а да никада није био приказан кориснику. Ако би се отворио директно, ново корисничко искуство би било поремећено.
Случај 2 - Неопозива дистрибуција. Тим је увео нови модел цена за сав саобраћај, без планова за враћање. Модел је неочекивано ценио неке производе веома јефтино. Враћање на стару верзију трајало је сатима јер процес није био спреман. Дошло је до озбиљног губитка прихода. Након тога, обавезно тестирање враћања је додато свакој имплементацији.
Случај 3 - Нечујни дрифт података. Образац преваре се јављао месецима без икаквих грешака. Али тактика превараната се променила (померање података) и опозив модела је тихо опао. Нико није приметио јер није било праћења. Када је успостављен панел за праћење дистрибуције прогнозе, одступање је постало видљиво рано. Обрадићемо мониторинг у јединици 8.
Шаблони који се могу копирати
Напишите нацрт плана примене за овај модел. Модел: [шта ради], употреба: [онлајн или групни?] Требало би да укључује:1) Паковање (контејнер, верзија)2) Стратегију инкременталне примене (сенка/канаринац/А-Б) и зашто3) метрике за праћење (пословни + технички + кашњење)4) План враћања назад и како тестирати5) метричка вредност која треба да премаши (коју вредност треба да пређе)
Проверите овај МЛ ЦИ/ЦД цевовод: 1) Да ли је валидација података у линији? 2) Може ли се имплементација наставити без задржавања прага евалуације (ако не би требало)? 3) Да ли је враћање аутоматски? 4) Да ли се подаци+код+метрика прате у регистру модела? Конфигурација линије: [цонфиг]
Помозите ми да одлучим да ли је онлајн или групна презентација погодна за овај модел. Колико дуго ће се користити резултат: [тренутак / минут / сат / дан] Очекивани обим захтева: [број]Да ли постоји ограничење одлагања: [мс]Које бисте препоручили у смислу цене и сложености и зашто?
Напишите процедуру враћања за овај модел.- Која метрика/праг покреће лоше перформансе?- Који су кораци враћања?- Колико дуго треба да траје враћање (циљ)?- Како да тестирам ову процедуру пре производње?
Табела узорака презентације
критеријум
онлајн (у реалном времену)
Батцх
кашњење
критично (мс)
безначајан
Употреба
Потребан је тренутни одговор
Периодични резултат
Цост
висока
ниско
сложеност
висока
ниско
пример
Препорука уживо, превара
Месечни резултат ризика
Уобичајене грешке
- Дистрибуирајте без плана преузимања. Погрешан модел погађа целог корисника.
- Отварање директно за 100% саобраћај. Ограничите ризик са степенастом дистрибуцијом.
- Неуспостављање мониторинга. Модел производи грешке тихо, без грешке.
- Сувишна презентација у реалном времену. Док је серија довољна, трошкови и сложеност расту.
- Не повезује верзије кодова модела-података. Не можете да репродукујете проблем.
- Аутоматско отпуштање без прага дистрибуције. Лош модел се нечујно ушуња.
Укратко
Пребацивање модела у производњу је другачији и често тежи инжењерски задатак од обуке. МЛ захтева додатну дисциплину јер зависи од тројке код-подаци-модел: паковање и верзија, образац испоруке (онлине/батцх) који одговара пословним потребама, постепено и реверзибилно примену, ЦИ/ЦД контролисан прагом и регистрација модела. Вештачка интелигенција је моћна помоћ у генерисању кода и конфигурације ове инфраструктуре; али прагови дистрибуције, политика поврата и одлуке о ризику су ваши. Дистрибуција без плана враћања није потпуна.
Задатак апликације
Контејнезујте (Доцкер) модел и означите га као верзију. Одлучите да ли ћете понудити онлајн или групно на основу ваших пословних потреба и напишите своје образложење. Документујте фазни план примене (сенка или канаринац) и тестирану процедуру враћања. Обавезно запишите верзију података, урезивање кода и резултате евалуације у регистру модела.
контролна листа
- [ ] Модел је упакован и верзионисан (контејнер + етикета).
- [ ] Образац презентације (онлине/батцх) је изабран према потребама пословања.
- [ ] Стратегија постепене примене (сенка/канаринац) имплементирана.
- [ ] Процедура повратка написана и тестирана.
- [ ] ЦИ/ЦД не напредује у примени пре него што се достигне праг евалуације.
- [ ] Регистар модела садржи везу подаци+код+метрика.