Печалби:
- Способност за разпознаване на специалните предизвикателства на ML, свързани с триото код-данни-модел и пакет и представяне на модела онлайн или на партида според бизнес нуждите.
- Възможност за внедряване на модели за постепенно и връщане назад (shadow, canary, A/B, връщане) и добавяне на тестван план за връщане към всяко внедряване
- Възможност за поддържане на връзката данни-код-метрика на модела, пуснат в производство, проследима с CI/CD с контролиран праг на оценка и регистър на модела
Получаването на модел за постигане на 95% точност в ноутбука е само половината от историята. Другата половина – често трудната част – предоставя този модел на реални потребители по надежден, мащабируем и поддържаем начин. MLOps (Операции за машинно обучение: дисциплината за въвеждане, управление и поддържане на ML модели в производство) съчетава DevOps практиките на софтуерното инженерство с уникалните предизвикателства на ML. В този раздел ние разглеждаме стъпките на преместване на модела в производство и как изкуственият интелект помага в този процес.
Защо ML е различен от обикновения софтуер?
В обикновения софтуер поведението е в кода; Ако кодът не се промени, поведението не се променя. В ML поведението зависи от кода, данните и модела. Тези три измерения създават допълнителни предизвикателства на MLOps:
- Дрейф на данните: Данните в производството се отдалечават от данните в обучението с течение на времето; моделът остарява.
- Трябва да версирате три неща: код, данни и модел – и трите.
- Тих отказ: Един модел може да се провали, без да се срине, без да дава грешки, просто като произвежда неправилни прогнози. Улавянето на това изисква наблюдение.
Ето защо има голяма разлика между "работещ модел" и "готов за производство модел".
Опаковане и представяне на модела
Първата стъпка при пускането на модела в производство е опаковането му: файлът на модела, необходимите библиотеки, кодът за предварителна обработка и информацията за версията заедно като едно възпроизводимо цяло. Контейнеризацията (напр. Docker: поставяне на приложението в изолирана кутия с всичките му зависимости) тук е стандартна; Това елиминира проблема „работеше на моята машина“.
Два основни модела на сервиране на модела:
- Онлайн/в реално време (онлайн): Моделът стои зад API, връщайки незабавна прогноза за всяка входяща заявка. Ниската латентност е критична.
- Партида: Моделът периодично обработва големи набори от данни (напр. генерира резултати за всички клиенти през нощта). Забавянето е без значение, ефективността е важна.
Кой от тях е правилният зависи от нуждите на бизнеса: незабавна препоръка онлайн, месечен риск на партида.
Съвет: „В реално време“ е цена, а не по подразбиране. Партидата е много по-евтина и по-лесна, ако резултатът се използва в рамките на часове. Наистина ли имате нужда от незабавен отговор? Попитайте първо това.
Сигурни стратегии за разпространение
Отварянето на нов модел директно за целия трафик е рисковано; Ако не е наред, всички са засегнати. Безопасни модели на разпространение:
- Внедряване в сянка: Новият модел получава производствен трафик, но прогнозите му не се показват на потребителя, а само се регистрират. Сравнява се със стария модел, за да се види дали е безопасен в реални данни.
- Разгръщане на Canary: Новият модел първо се разпространява до малък процент от трафика (напр. 5%); Ако няма проблем се увеличава постепенно.
- A/B тестване: Два модела се представят на реалния потребител паралелно и се сравняват бизнес показателите (конверсия, кликвания).
- Връщане назад: Възможност за бързо връщане към старата версия, ако новият модел се окаже лош. Всяко внедряване трябва да има план за връщане назад.
Внимание: Внедряване без план за връщане назад не е завършено. Възможността за връщане към старата версия в рамките на минути защитава потребителя, когато новият модел се държи неочаквано в производството. Тествайте това преди внедряване.
Слаб подход / Силен подход
Слаб: „Моделът беше добър при тестване, пуснахме го на живо, отворихме го за всички.“
Güçlü: „Ние контейнеризирахме модела, етикетирахме го като версия. Първо го пуснахме в режим на сянка с производствен трафик в продължение на 3 дни, сравнявайки прогнозите със стария модел — отклонението беше приемливо. След това го отворихме с 5% canary, наблюдавахме показателите за пропускателна способност и латентността. Когато нямаше проблеми, постепенно го увеличихме до 100%. Бяхме тествали командата за връщане преди това.“
Разликата: силният подход е постепенен, премерен и обратим. Рискът е ограничен на всяка стъпка.
CI/CD и автоматизация
CI/CD (Непрекъснато интегриране/Непрекъснато внедряване: тръбопровод за автоматично тестване и освобождаване на промени в кода) в ML обхваща не само кода, но и данните и стъпките на модела. Добър ML CI/CD тръбопровод: изпълнява тестове, когато кодът се промени, извършва валидиране на данни, преобучава модела (ако е необходимо), проверява праговете за оценка и само напредва в внедряването, ако праговете се задържат. Принципът на „обучението е автоматично, внедряването е базирано на прагове“ предотвратява тихото изтичане на лошия модел в производството.
AI е много полезен при настройването на тези конвейери: писане на чернови на конфигурационен файл (YAML), тестови случаи, скриптове за внедряване. Но вие определяте праговете на разпространение (какъвто и показател да надвишава публикуваната стойност) и политиката за връщане назад; това са бизнес рискови решения.
Инфраструктура за възпроизводимост
За да се възпроизведе поведението на модел в производството, регистър на модела: запис, който пази кой модел е бил обучен с какви данни и код и кои показатели е получил. За всеки производствен модел трябва да може да се проследи следното: версия на данните за обучение, версия на код (git commit), хиперпараметри, оценки за оценка и дата на внедряване. Когато възникне проблем, трябва да можете да отговорите на въпроса "кой модел е произвел тази прогноза, с кои данни?" в рамките на минути. Ще задълбочим това в блок 11.
три мини калъфа
Случай 1 - Проблем, уловен от разпределението на сенките. Модел на препоръка победи стария при тестване. Установено е, че стартирането му с производствен трафик в режим на сянка дава много лоши препоръки за конкретен сегмент от потребители (нови потребители) — тестовите данни не са достатъчно представителни за този сегмент. Моделът беше фиксиран, без изобщо да бъде показан на потребителя. Ако се отвори директно, новото потребителско изживяване ще бъде нарушено.
Случай 2 - Неотменимо разпределение. Екип пусна нов модел на ценообразуване за целия трафик, без планове за връщане назад. Моделът неочаквано постави някои продукти много евтино. Връщането към старата версия отне часове, защото процесът не беше готов. Имаше сериозна загуба на доходи. След това към всяко внедряване беше добавено задължително тестване за връщане назад.
Случай 3 - Безшумен дрейф на данни. Модел на измама се появи в продължение на месеци без никакви грешки. Но тактиката на измамниците се промени (дрейф на данните) и изтеглянето на модела тихо падна. Никой не забеляза, защото нямаше наблюдение. След като беше създаден панел за наблюдение на разпространението на прогнозата, дрейфът стана видим рано. Ще покрием мониторинга в блок 8.
Копируеми шаблони
Напишете проект на план за внедряване на този модел. Модел: [какво прави], използване: [онлайн или пакетно?] Трябва да включва: 1) Опаковка (контейнер, версии) 2) Стратегия за постепенно внедряване (shadow/canary/A-B) и защо 3) Метрики за проследяване (бизнес + технически + латентност) 4) План за връщане назад и как да се тества 5) Прагове за внедряване (кой показател трябва да надвишава каква стойност)
Проверете този ML CI/CD тръбопровод: 1) Валидирането на данните в линията ли е? 2) Може ли внедряването да продължи без задържане на прага за оценка (не трябва ли)? 3) Автоматично ли е връщането назад? 4) Проследени ли са данни + код + показатели в регистъра на модела? Конфигурация на Pline: [config]
Помогнете ми да реша дали онлайн или груповата презентация е подходяща за този модел. Колко дълго ще се използва резултатът: [момент / минута / час / ден] Очакван обем на заявката: [номер] Има ли ограничение за забавяне: [ms] Кое бихте препоръчали по отношение на цена и сложност и защо?
Напишете процедура за връщане назад за този модел.- Какъв показател/праг предизвиква лоша производителност?- Какви са стъпките за връщане назад?- Колко време трябва да отнеме връщането назад (цел)?- Как да тествам тази процедура преди производство?
Таблица с шаблони за представяне
критерий
Онлайн (в реално време)
Партида
забавяне
Критичен (ms)
незначителен
Използване
Необходим е незабавен отговор
Периодичен резултат
цена
високо
ниско
сложност
високо
ниско
пример
Препоръка на живо, измама
Месечен рисков рейтинг
Често срещани грешки
- Разпространете без план за извличане. Грешен модел засяга целия потребител.
- Отваряне директно на 100% трафик. Ограничаване на риска със стъпаловидно разпределение.
- Без установяване на мониторинг. Моделът генерира грешки тихо, без грешка.
- Излишно представяне в реално време. Въпреки че групирането е достатъчно, цената и сложността нарастват.
- Без свързване на версии на модел-данни-код. Не можете да възпроизведете проблема.
- Автоматично освобождаване без праг на разпространение. Лошият модел се промъква безшумно.
В обобщение
Преместването на модела в производство е различна и често по-трудна инженерна задача от обучението му. ML изисква допълнителна дисциплина, тъй като зависи от триото код-данни-модел: опаковане и версии, модел на доставка (онлайн/партида), който отговаря на нуждите на бизнеса, постепенно и обратимо внедряване, CI/CD с контролиран праг и регистрация на модела. Изкуственият интелект е мощна помощ при генерирането на кода и конфигурацията на тази инфраструктура; но праговете за разпространение, политиката за връщане на средства и решенията за риска са ваши. Разпределение без план за връщане назад не е пълно.
Задача за приложение
Контейнеризирайте (Docker) модел и го етикетирайте като версия. Решете дали ще предлагате онлайн или групово въз основа на вашите бизнес нужди и напишете своята обосновка. Документирайте план за поетапно внедряване (shadow или canary) и тествана процедура за връщане назад. Уверете се, че записвате версията на данните, предаването на кода и оценките за оценка в регистъра на модела.
контролен списък
- [ ] Моделът е опакован и версииран (контейнер + етикет).
- [ ] Моделът на представяне (онлайн/партида) е избран според нуждите на бизнеса.
- [ ] Внедрена е стратегия за поетапно внедряване (сянка/канаре).
- [ ] Написана и тествана процедура за връщане назад.
- [ ] CI/CD не ускорява внедряването, преди да бъде достигнат прагът за оценка.
- [ ] Регистърът на модела съдържа връзката данни+код+метрика.