Сцена, которую мы видим на проектах чаще всего. Компания заказала модель машинного обучения, дата-сайентисты показали красивую точность на тестах, модель торжественно запустили. Через три месяца прогнозы поехали, а на вопрос «почему» никто не может ответить. И вот что важно: код при этом никто не трогал.
В индустрии кочует оценка, что до 80% ML-проектов вообще не доживают до реальной работы. Точную цифру проверить трудно, но направление верное: обучить модель гораздо проще, чем удержать её в строю. Именно про «удержать в строю» и есть MLOps.
Обученная модель ещё ничего не гарантирует
Кажется, что когда точность на тестах достигнута, тяжёлое позади. На самом деле пройдена только половина пути. Обычную программу пишут один раз, и она ведёт себя одинаково хоть через год. С моделью иначе. Она принимает решения на основе данных, а данные меняются вместе с рынком: приходят другие клиенты, сдвигаются цены, меняется поведение. Модель, обученная на прошлогодней картине мира, потихоньку слепнет, даже если в неё не внесли ни строчки правок. Этот эффект называют дрейфом, и он стоит за большинством историй про «модель работала, а потом перестала».
Мы в Tess Technology формулируем это так: модель нельзя внедрить и забыть, её нужно вести. Как ведут любую критичную систему, от которой зависят деньги.
Что на самом деле делает MLOps
За аббревиатурой стоят четыре довольно приземлённые вещи. Первая: воспроизводимость. В любой момент вы должны знать, на каких данных и с какими настройками обучена та модель, что сейчас работает. Без этого разбор инцидента превращается в спиритический сеанс. Вторая: автоматический вывод новой версии в работу вместо ручной выгрузки файла раз в квартал. Третья: мониторинг, причём не только «жив ли сервис», но и качества предсказаний. Четвёртая: понятное правило, когда модель переобучают и как откатывают, если новая версия оказалась хуже старой.
Обратите внимание на пропорцию. Три задачи из четырёх относятся к жизни модели после запуска. Здесь и рвётся: строить модели команды научились, а сопровождать их — редко.
История про склад, который забился сам собой
Показательный случай. Модель предсказывала спрос и подсказывала, сколько закупать. Первые месяцы всё сходилось, склад разгрузили, закупщики выдохнули. Потом поставщик обновил ассортимент, у части позиций сменились артикулы, и на вход модели пошли данные, которых она в глаза не видела при обучении. Сервис при этом отвечал за миллисекунды, в логах чисто. А прогнозы тихо поехали. Заметили это не по алерту, а по горе излишков, которая через несколько недель выросла на складе.
Настроенный мониторинг входных данных поймал бы смену артикулов в первые дни и поднял тревогу до того, как это превратилось в замороженные деньги. Разница между «узнали через полгода по убыткам» и «система предупредила на первой неделе» и есть та сумма, ради которой MLOps затевают.
Что мониторить, если руки не доходят до всего
Начать стоит с входных данных. Именно там ломается чаще всего: сменился формат, появились пропуски, поехали распределения. Такой мониторинг дёшев и ловит львиную долю проблем. Дальше добавляют одну-две метрики качества самих предсказаний. Качество отслеживать тяжелее, потому что правильный ответ часто приходит с задержкой: отток клиента предсказали сегодня, а подтвердится он через месяц. Поэтому строят отложенную проверку и следят за косвенными признаками, не дожидаясь полной правды.
Простой тест на зрелость. Если вы не можете назвать метрику, по которой поймёте, что модель начала врать, значит модель не под контролем. Как бы уверенно она ни выглядела в день запуска.
Сколько времени это экономит
Разница между зрелым и незрелым MLOps считается в неделях. По отраслевым оценкам, без отлаженных конвейеров вывод ML-проекта в работу занимает около семи месяцев. Команды с настроенным процессом укладываются в две-четыре недели. Застревают проекты в предсказуемых местах: подготовка обучающих данных (её называют барьером примерно в 41% случаев), сборка продакшн-пайплайнов (около 38%) и доказательство отдачи для бизнеса (около 34%). Ни один из трёх барьеров не про алгоритмы.
С чего начать среднему бизнесу
Тяжёлую платформу поднимать необязательно. Сначала зафиксируйте, какая модель и на каких данных сейчас работает. Это стоит копейки и снимает половину будущей боли. Потом подключите базовый мониторинг входа и пары метрик с оповещением ответственного. Потом введите регламент переобучения по расписанию или по сигналу, с обязательной проверкой новой версии до замены старой. Полноценная MLOps-платформа понадобится позже, когда моделей станет много.
И один организационный момент, который решает больше, чем любой инструмент. У модели должен быть живой хозяин с именем и фамилией. Модель без хозяина деградирует так же надёжно, как гниёт бесхозный забор. Технология тут ни при чём.
MLOps не про моду на новые инструменты. Это признание того, что модель живёт в меняющемся мире и требует ухода. Компании, которые это приняли, доверяют своим прогнозам управленческие решения. Остальные однажды принимают решение на основе тихо сломавшейся модели и даже не узнают об этом.
Источник: