- Mon 28 August 2023
- обучение
- #mlsystemdesign
Первая лекция открытого курса "Дизайн систем машинного обучения (2023)", "Машинное обучение на практике".
Слайды можно скачать тут mlsysd23-01.pdf
Текстовая расшифровка лекции:
Привет! Меня зовут Дмитрий Колодезев, и это первая лекция курса «Дизайн систем машинного обучения». Про меня можно прочитать на сайте kolodezev.ru. Я работаю в компании «Промсофт», веду этот курс уже второй раз. Вместе со мной этот курс делали много людей, и не все из них попали на слайд, к сожалению.
О чем мы будем рассказывать? Во-первых, делать модели машинного обучения легко, но трудно делать хорошие модели машинного обучения. А еще труднее сделать так, чтобы эти модели работали в составе системы, которая включает в себя сбор данных, обработку, хранение, выдачу предсказаний, и чтобы ей пользовались живые люди. На этом пути мы сталкиваемся с интересными проблемами, очень далекими от того, что обычно рассказывают на курсах по машинному обучению. Мы будем изучать ML-системы, как они работают в реальной жизни, с какими проблемами сталкиваются, и какие вызовы перед нами открываются с точки зрения кода, оборудования и бизнеса.
В курсе нет рассказов про алгоритмы машинного обучения, дизайн интерфейса, нет обучения программированию, не раскрываются проблема «вкатиться в IT», и, если вам нужно пройти собеседование по system design, то лучше идите на курс Карпова по system design, они вас подготовят гораздо лучше.
План курса.
Первая лекция, которую сейчас вы слушаете – «Машинное обучение на практике» – это постановка проблем, которые мы будем решать.
Дальше «Основы проектирования ML-систем» – перечисляются основные подходы к решению этих проблем.
ML-системы невозможны без обучающих данных, и в третьей лекции мы разберем, как данные собираются, хранятся и обрабатываются.
Для того, чтобы данные были полезны, нам нужно превратить данные в признаки, и этому посвящена четвертая лекция.
Затем нам нужно обучить ML-модель, и после того, как мы обучили ML-модель, зачастую качество нас не устраивает.
Есть вариант дорабатывать саму модель, но обычно более практичный способ – это дорабатывать данные, на которых модель училась, data-centric AI, и вот об этом мы поговорим в шестой лекции, «Улучшение модели через данные».
В седьмой лекции мы разберем оценку качества модели, в восьмой развертывание ее в продуктовое окружение, в девятой – диагностику ошибок и отказов.
В десятой лекции мы посмотрим немножко сверху на весь процесс и разберем жизненный цикл модели, от ее рождения до смерти и утилизации, замены.
Далее мы разберем несколько специальных вопросов. В одиннадцатой лекции это то, как работать с потоковыми данными, а в двенадцатой мы коснемся языковых моделей – невозможно их игнорировать, сейчас все про них говорят, и все их используют, поэтому мы под них выделили отдельную лекцию.
В тринадцатой лекции мы разберем временные ряды и графы, в четырнадцатой – вопросы этики, безопасности и интерпретируемости.
Курс закончит пятнадцатая лекция про интеграцию в бизнес-процессы.
Курс очень большой и делается волонтерами в свободное время, поэтому, к сожалению, мы включаем режим варвара в форумах, чатах и так далее, то есть мы не имеем технической возможности спорить, дискутировать. Мы можем отвечать на вопросы, мы можем читать лекции, размещать материалы, но как только дело доходит до споров в форумах, у нас, к сожалению, одно решение проблемы – это бан. Мы постараемся сделать все, чтобы вам было комфортно, интересно и полезно учиться на этом курсе, но если мы что-то сделали не так – к сожалению, жаловаться некому.
Зачем вам может понадобиться этот курс?
Самое очевидное – это в рамках курса запустить свой проект для портфолио или, чем черт не шутит, запустить свой стартап. Может быть полезным попробовать слушать курс и применять то, что я буду рассказывать, к проекту, который делается на работе, но тут есть некоторые трудности, поскольку в рамках курса мы будем обсуждать проекты и выкладывать их в открытый доступ. Не все могут это сделать. Но, тем не менее, лучше всего слушать курс, применяя услышанное сразу к какому-то живому проекту.
Главное назначение курса – это расширение кругозора. Не научить чему-то, не дать какие-то секретные техники или рассказать какие-нибудь базовые подходы, а просто расширить ваш кругозор и почему это важно.
Как люди проектируют системы?
Люди задают вопросы тем, кому эта система нужна, люди изучают и ставят факты под сомнение – так ли действительно, как им сказал заказчик или пользователь. Они оценивают имеющиеся ресурсы и выбирают, что у них есть и что можно использовать для решения проблемы. Они вспоминают, как сделали на прошлой работе – и на самом-то деле это половина успеха, наверное. Ну или можно так сказать, что половина успеха – это выяснение ограничений, а вторая половина успеха – это применение типовых решений в условиях выявленных ограничений.
Однако во время построения систем, построенных на машинном обучении, мы сталкиваемся с интересными проблемами. Не все работает так, как должно, и для некоторых вещей нам нужны какие-то базовые подходы, техники, которые редко встречаются в учебнике. Поэтому важна насмотренность, чтобы вы увидели какую-то ситуацию и узнали ее, сказали – ага, я ее видел уже.
Ну и, на мой взгляд, зрелого проектировщика систем отличает способность выходить из тупиков – после того, как он выяснил ограничения, имеющиеся ресурсы, понял, что задача нерешаема в существующих ограничениях и имеющимися ресурсами, и, тем не менее, какие-то ограничения были ослаблены, какие-то ресурсы были затребованы, и все-таки проект был успешно завершен. То есть четвертая половина успеха – это умение выходить из тупиков.
И этот курс даст вам немножко насмотренности, немножко типовых решений, немножко техники выявления ограничений и, может быть, чем черт не шутит, немножко навыков как выходить из тупиков.
Мы стоим на плечах гигантов. Этот курс первоначально зародился как продолжение идей Chip Huyen из курса Computer Science 329 Стэнфордского Machine Learning System Design. Chip выпустила книгу по мотивам этого курса, эта книга была переведена на русский язык, и, в принципе, наверное, если у вас есть возможность прочитать эту книгу и не слушать видеолекции, это все решит.
Каковы предварительные требования к курсу? Во-первых, это основы статистики. Хороший курс Карпова, еще есть на степике бесплатный курс по основам статистики, дает базовые навыки, которые нужны для того, чтобы понимать, о чем мы говорим.
Желательно уметь программировать, поскольку в рамках курса мы будем разрабатывать проекты. Уметь программировать нельзя научиться быстро. Если вы не умеете программировать – наверное, этот курс не для вас. На Хабре есть хороший курс от Яндекса «Современная разработка на питоне». Он действительно хороший.
Вам придется понимать, что такое машинное обучение и как им пользоваться. И, опять же, на Хабре есть старый ODS-овский курс, старый, но не бесполезный, где разбираются базовые подходы к тому, как строить модели машинного обучения и применять их к задачам реальной жизни.
Хорошо бы иметь практический опыт программирования в консоли. Есть "курс про то, что вам забыли рассказать". Это первоначально был MIT-овский курс, в котором заполняли базовые пробелы в подготовке студентов - работа с git, работа с командной строкой, работа по SSH с удаленным сервером и так далее.
Желательно, чтобы вы умели работать с нейронками. Большинство промышленных ML-систем, которые сейчас строятся, так или иначе используют нейронки. Я лично использую PyTorch везде, где это можно. Есть отличные курсы от HuggingFace, где разбираются пошаговые руководства – делай раз, делай два, делай три, – по обработке звука, по обработке текста, по reinforcement learning.
Andrew Ng, один из основателей Coursera, запустил на Deep Learning AI серию коротких курсов, они сейчас пока все бесплатные, по работе с большими языковыми моделями, построению моделей, основанных на промптах ChatGPT и так далее и тому подобное. На Deep Learning AI посмотрите, если эта тема вас интересует.
Что будет у нас в рамках курса?
Во-первых, будут видеолекции, примерно такие же, как эта, выкладываться по понедельникам – это ориентировочный срок, потому что, может быть, мы не всегда будем успевать.
Раз в неделю будут семинары в 2 часа дня по Москве в четверг. Мы будем собираться в Spatial Chat и обсуждать вопросы, которые были непонятны на лекциях.
Участники курса будут делать доклады на темы – список тем мы дадим позже.
У курса будет канал в Telegram, где будут объявления, можно будет задавать вопросы, отчитываться о статусе проектов.
Вам нужно будет делать проект в рамках курса – это не обязательно, но, если вы будете делать проект, то курс будет гораздо полезнее для вас. Раньше мы предлагали темы проектов, из которых можно выбрать. В этом году мы не предлагаем темы проектов – берите проект, который вам нравится, и делайте.
Параллельно разработке проекта мы просим вас создавать и дорабатывать ML дизайн документ. Это документ, в котором описано, чего вы хотите достичь, как вы планируете это сделать и как вы поймете, что вы этого достигли.
Будут лабораторные работы, ну, я надеюсь, что будут. Они еще не записаны, но мы работаем над этим.
Будут дополнительные материалы к каждой лекции и будет публичный лидерборд. Я думаю, что он будет обновляться с некоторой задержкой, но мы постараемся, чтобы это было как можно быстрее.
Про лекции. Раз в неделю на странице курса будет выкладываться новая лекция на полчаса-час, как получится. На kolodezev.ru я буду выкладывать текстовые расшифровки лекций. Примерно наполовину это будет повторение прошлого курса, поэтому можно начинать его смотреть. Записи будут в общем доступе и они будут в общем доступе вечно, пока работают машины.
За работу на лекциях будут присваиваться баллы. Один балл будет за хороший вопрос в чате или хороший ответ на чужой вопрос. Два балла за огонь вопрос или за огонь ответ на чужой вопрос. Буквально, если вы задали хороший вопрос, то я поставлю смайлик в телеграмме, палец вверх. Если вы задали огонь вопрос, я поставлю огонек. И потом мы посчитаем пальчики и огоньки.
За одну неделю нельзя получить больше двух баллов. То есть оценивается один лучший вопрос или один лучший ответ. То есть если вы десять раз ответили хорошо, все равно вы получите два балла, ничего не поделаешь. И эти баллы будут назначаться каждую неделю, а в конце суммироваться.
На семинарах мы будем обсуждать доклады участников. Мы будем отвечать на вопросы, это будет примерно на час. Записей семинаров не будет. Они будут каждый четверг в 2 часа дня по Москве в Spatial Chat.
Мы просим участников курса делать доклады по темам, связанным с курсом. Все темы мы не можем разобрать, поэтому по части тем доклады будут делать участники. Я постараюсь к четвергу выложить список тем для докладов. Можно взять свою тему – какую-нибудь интересную библиотеку, фреймворк, сервис или подход к построению систем. Формат – примерно 10-минутный рассказ или туториал, статья на хабре, статья на медиум или открытый репозиторий с кодом и презентацией в Markdown.
Доклад оценивается от 0 до 20 баллов. Если вы сделали несколько докладов, то оценивается один лучший. Качество материала – 10 баллов, подача – 5 баллов и качество дополнительных материалов – еще 5 баллов. Пожалуйста, согласовывайте выступление или тему заранее, чтобы мы включили их в план.
У нас будет канал в Телеграме, где будут еженедельные отчеты о проектах, можно будет задавать вопросы к лекциям, будут объявления. Неактивные участники будут удаляться из канала. Скорее всего, если вы ничего не постили в канал 2 или 3 недели, то вас из канала удалят. Добавить кого-то, кто не проходит курс, нельзя.
Как попасть в канал? Всем, кто указал свой аккаунт в Телеграме, придет инвайт. Если кто-то не получил инвайта в канал до конца недели – пожалуйста, напишите Татьяне или мне, мы что-нибудь сделаем.
В рамках работы над курсом вы будете делать проекты, и вам предстоит придумать самим тему. Выберите проект, которым вы хотели бы заниматься после окончания курса. Проект должен делаться группой от 2 до 5 человек, одному делать нельзя.
У проекта должен быть репозиторий на гитхабе, и к этому репозиторию должен быть доступ у меня и у волонтеров, которые помогают вести курс.
Оценки за проект выставляются одинаково всей команде. Еженедельно до четверга вы должны скоммитить в репозитории результат и прислать в чат отчет. Если коммит будет хороший и нетривиальный, это 1 балл за неделю. Коммит и хороший отчет – 2 балла. Коммит, отчет и интересный результат, то есть вы что-то сделали, что было интересно читать или смотреть – 3 балла.
Так каждую неделю, кроме самой последней недели, то есть у нас курс будет идти 15 недель, последняя неделя посвящена подготовке к защите, соответственно можно 14 раз получить баллы за проект.
В рамках проекта вам нужно будет писать ML дизайн документ.
Это отдельный раздел в репозитории, или отдельный репозиторий, или, допустим, документ в Google Docs – как вам удобнее. С ответами – что хотим построить и зачем, как поймем, что проект успешен, ограничения и возможности, подходы к построению системы. Они оцениваются так же, как проекты. Чтобы не было споров по оценкам, лучше хранить его в репозитории в git, чтобы можно было смотреть прогресс.
Как писать дизайн док – мы с Ириной Голощаповой записали лекцию для студентов ИТМО. Она доступна по ссылке. На GitHub есть шаблон дизайна документа. Он рассчитан на большие организации, изначально он разрабатывался для сети магазинов Лента, поэтому какие-то формулировки там могут быть пугающие. Упрощайте его, сохраняя общую идею. В прошлом году были лекции про дизайн док, их тоже можно посмотреть.
Мы постараемся сделать 4 лабораторные работы – примерно после 3, 6, 9 и 12 лекций. Они не будут оцениваться. Это будут практические задачи из серии «Давайте заведем проект на Weights & Biases, обучим модель, посмотрим на графики, поймем, как это работает». Это практические задачи на попробовать, и результаты лабораторных мы будем обсуждать на семинарах.
К каждой лекции будут дополнительные материалы – статьи для самостоятельной проработки. Я ориентируюсь на объем 50 печатных страниц. Они будут в телеграм-канале после каждой лекции. Все статьи будут либо в открытом доступе, либо доступ к ним будет согласован и они будут предоставлены всем участникам. По дополнительным материалам можно будет задавать вопросы в телеграм-канале. Я постараюсь на них ответить как можно оперативнее.
Дополнительные материалы важнее лекций. Поскольку в курсе заключен в основном мой опыт, я постарался расширить его дополнительными материалами людей из ведущих организаций отрасли, и это поможет вам получить цельную картину того, как все это устроено.
Как я уже говорил, за курс будут назначаться баллы.
В принципе непонятно, зачем вам баллы на открытом курсе, но если вы хотите быть вверху лидерборда и как-нибудь перед своим будущим работодателем или знакомым похвастаться этим фактом, то все-таки какая-то балльная оценка нужна.
Работа на лекциях может дать вам максимум 30 баллов – 15 лекций до 2 баллов на каждой. Доклады студентов – до 20 баллов. Работа над проектом 14 недель – до 42 баллов. Дизайн документ – 42 балла максимум. Защита проекта – 40 баллов.
Дизайн документ, работа над проектом и защита проектов – это командные баллы, то есть они назначаются всем членам команды одинаково. Работа на лекциях и доклады – это личные баллы.
Для себя можно оценить, что меньше 60 баллов за курс – это двойка, меньше 90 – это тройка, меньше 110 – четверка. Больше 140 – это рекомендательное письмо от меня.
ODS.AI предоставит участникам сертификаты и какой-то мерч, но условия этого будут уточнены позже.
Итак, собственно к лекции.
Дизайн систем машинного обучения – это процесс принятия решений про интерфейс, алгоритмы, данные, программную инфраструктуру и оборудование, чтобы соответствовать требованиям и ограничениям, налагаемым на систему.
Какие могут быть требования? Требования по надежности, масштабируемости, обслуживаемости, адаптируемости.
Проектирование системы начинается с выявления ограничений. При этом, даже если вам дали ограничения как вводные, их надо ставить под сомнение, потому что, как правило, самое главное вам забыли сказать. Кроме этого – у стейкхолдеров, то есть тех, кто заинтересован в успехе проекта, есть разные требования, разные ограничения, и еще они основываются на своем опыте, который может быть достаточно смещенным. Поэтому требования – это всегда предположения. Заказчик может хотеть одно, но нуждаться в другом. Просто он не знает, что это возможно, доступно или достижимо.
Как работать с ограничениями? Предположите что-нибудь. Мы предполагаем, что система ограничена вот так. Мы предполагаем, что для инференса нам нельзя использовать GPU. Мы предполагаем, что у нас будет тысяча человек в день. Мы предполагаем...
Вот эти предположения нам нужно будет задокументировать и обязательно обсудить их со всеми заинтересованными лицами. Постараться найти подтверждение этим гипотезам. Попытаться понять, как проверить предположения.
То есть если у нас тысяча пользователей, то можно посмотреть на текущую статистику похожей системы или уже работающей системы, чтбоы увидеть, сколько там пользователей в день. Их может быть как десять, так и пятьдесят тысяч на самом деле. Тысяча это могла быть цифра из головы.
И это итеративный процесс – то есть вы узнаете какой-то новый факт, который не укладывается в вашу картину мира, и уточняете все предположения, которые с ним не стыкуются.
Какие предположения обычно выдвигает машинное обучение?
Машинное обучение – это автоматизированный подход к выявлению сложных шаблонов в имеющихся данных и использованию этих шаблонов для предсказания на новых данных.
Тут каждый кусок фразы имеет смысл.
Мы предполагаем, что мы можем выявлять шаблоны. Это не всегда так. Например, в высокочастотной торговле акциями мы зачастую не можем выявлять шаблоны. То есть кто-то может, но скорее всего мы не можем. Еще мне попадались проекты, где люди анализируют с помощью машинного обучения шифры. При том, что это в принципе возможно, в большинстве случаев эти шаблоны нам не удастся выявить с помощью машинного обучения.
Далее, что шаблоны сложные. Если шаблоны простые, то нам не нужно машинное обучение, мы скорее всего можем обойтись какими-нибудь простыми правилами.
Мы предполагаем, что у нас имеются какие-то данные, что у нас есть доступ к данным, причем этих данных нам достаточно для того, чтобы выявить эти сложные шаблоны.
Мы предполагаем, что из тех данных, которые нам будут доступны, мы сможем что-то предсказать.
И мы предполагаем, что у нас будут новые данные, и они будут в то время, когда нам нужно будет сделать предположение. Последнее – совершенно неочевидное утверждение, например, очень часто в промышленном ML я сталкиваюсь с проблемой, когда в принципе модель построить можно, но вот те данные, на которых ее можно построить прямо в тот момент, когда нам нужно решение, недоступны. Они доступны чуть позже, то есть они поступают с некоторой задержкой. То есть в принципе модель возможна, но конкретно в этом практическом случае мы ее сделать не можем.
Когда следует делать ML?
Не все проблемы в жизни нужно решать с помощью машинного обучения.
Машинное обучение идеально подходит для решения часто повторяющихся задач. Например, нам нужно принять решение на конвейере, когда цена ошибки невелика. Цена ошибки невелика – это не значит, что в принципе процесс нас не интересует, а когда цена каждой конкретной ошибки модели невелика, может быть исправлена на следующем этапе и так далее. То есть если у вас модель должна принять решение, от которого зависит жизнь человека, и никто потом не сможет ее проверить – ну, тут надо осторожно с ML.
ML модели делать и внедрять дорого, поэтому они окупаются на большом масштабе, когда вам нужно этих решений принимать очень много.
И еще, поскольку ML – это автоматизированное выявление шаблонов, оно в полной мере раскрывается, когда шаблоны, которые мы анализируем, постоянно меняются. То есть если у нас шаблон статичный, мы на самом деле можем делать не ML, а мы можем построить какую-нибудь модель на правилах, статистическую модель, и вшить ее насмерть в систему, пусть она работает. А вот когда шаблоны, по которым нужно принимать решение, постоянно меняются, тут-то и нам нужно машинное обучение.
Когда не стоит делать ML?
Я для себя как-то давно решил, что есть вещи, которые делать просто неэтично. Например, можно построить систему, которая выявляет людей, наиболее подверженных обману, и обманывать их. То есть звонить им, предлагать что-нибудь интересное или рассказывать, что вы из техподдержки Сбербанка. Но это неэтично, и делать этого не надо.
Не надо делать ML, когда простое правило решает проблему. То есть задачи нужно решать самым простым способом. Если ML – не самый простой способ, его не надо применять.
Зачастую данные недоступны, и не надо пытаться делать машинное обучение, если нет данных.
Иногда цена ошибки очень высока. Тут мы идем на удорожание принятия решения, когда решение принимается людьми, пусть даже им рекомендацию выдает ML, но решение принимается людьми. И вот в таких случаях, когда от решения зависит жизнь и смерть, пока лучше не использовать ML.
Я думаю, что в ближайшее время это изменится, и ML можно будет использовать в высокорискованных приложениях. Есть, кстати, хорошая книга «Машинное обучение в высокорискованных приложениях». Я не знаю, переведена ли она на русский язык. Там эти вопросы разбираются подробно.
Не надо делать ML, когда вам каждое решение, которое вы приняли, придется объяснять. Тут скорее подойдут правила или статистика. В машинном обучении есть хорошо проработанные технологии интерпретации моделей машинного обучения, но пока они не дотягивают до объяснения, которое нам способны дать люди.
Ну и не надо делать ML, когда дешевле нанять человека. Так очень часто бывает.
Для того, чтобы продвинутые техники анализа работали, организации должны сделать домашнее задание.
То есть для того, чтобы у вас заработал deep learning, обычно вам нужно построить систему сбора данных, логирования, генерации контента, организовать хранение этих данных, потоки данных, затем организовать процесс очистки, детекции аномалий, после чего вы получите возможность делать какие-то дашборды, собирать метрики, агрегировать признаки и готовить обучающие данные. После того, как у вас будут данные, вы сможете делать A/B-тестирования, использовать простые ML алгоритмы, делать эксперименты.
И когда вы прошли этот путь, вы можете доставать свой deep learning и делать чудесные вещи.
На самом-то деле, благодаря тому, что много больших организаций сделало за нас работу по подготовке и обучению моделей, зачастую мы можем пропустить часть этих этапов. Но для того, чтобы построить хорошую ML-систему, эту схему желательно держать в голове.
Про пропустить часть этапов – я имею в виду, что есть предобученные модели, например, для распознавания объектов на фото от Google, и вы можете использовать их, не заморачиваясь с обучением моделей и анализом, а просто прикрутить вашу камеру к готовой ML-модели, доступной через RestAPI, и начать получать пользу.
Есть некоторое противостояние индустриального и промышленного ML.
В индустрии акцент делается на инженерные навыки, и ученые упрекают инженеров в том, что они не знают основ, используют алгоритмы, лишь бы они работали, и не проверяют базовые статистические предположения, и это правда.
С другой стороны, сами ученые обычно не умеют писать код, их решения не воспроизводятся, большинство находок в статьях – просто удивительные, прекрасные находки, совершенно неприменимые на практике. Я на стороне индустрии.
Что важно в исследованиях?
В исследованиях вам нужно сделать что-то такое, что можно опубликовать.
Вам нужно быстро посчитать, данные у вас обычно даны свыше, не меняются, вам не так важна интерпретированность, вам не придется поддерживать это решение, и у вас один и тот же масштаб решения.
У вас есть какое-то количество данных, вы на них обучили модель, может быть один раз, может быть 50 раз, но такого, чтобы сегодня у вас было 1000 человек, а через год у вас был миллион человек, в исследованиях, скорее всего, у вас не будет.
В индустрии все немножко сложнее.
Разные люди и структуры внутри организации выдвигают разные требования.
Обычно приоритет к вычислениям в индустрии – это быстрый инференс, низкая задержка, то есть как можно быстрее отдавать ответ. Хотя это тоже не всегда так.
Обычно в индустрии постоянно меняется внешняя среда, и поэтому идет постоянный сдвиг данных.
В некоторых приложениях интерпретируемость для индустрии очень важна, то есть важно понимать, почему модель принимает такое решение. Это связано с тем, что большинство бизнес-процессов – это командная игра, и другим участникам бизнес-процесса хорошо бы понимать, почему это решение было принято именно так.
В индустрии определяющей метрикой при выборе модели может быть не качество модели, а то, насколько ее легко будет поддерживать на проде, или то, насколько ее легко можно будет масштабировать.
Про разные интересы – есть хорошая иллюстрация из Стэнфордского курса про разные интересы стейкхолдеров проекта.
ML-команда думает, что главное в проекте – это точная модель.
Продажники, которые будут пользоваться моделью – им хотелось бы продать больше рекламы.
Product Owner хочет, чтобы модель выдавала предсказания как можно быстрее, пусть и не так качественно, потому что если пользователь будет ждать лишние 0,1 секунды, то 10% их уйдет.
Ну а менеджер, стоящий над ними – ему хотелось бы максимизировать прибыль от всего проекта, и одним из путей максимизации прибыли может быть просто уволить ML-команду и сделать все на простых правилах.
ML-системы – это подмножество обычных программных систем, компьютерных систем, и в принципе разработка ML-систем – это обычная разработка IT-систем, но некоторые особенности у ML-систем есть.
Во-первых, это данные, во-вторых, это немножко другое управление проектом, и в-третьих, большой акцент на мониторинг.
Что не так с данными?
ML-модель сцеплена с данными.
То есть, когда мы пишем программу, обычно наш продукт – это, собственно, программный код. И если кто-то туда положил неправильные данные, то он сам виноват.
Наш продукт разработки ML-системы – это программный код, сцепленный с данными. То есть, успех работы ML-системы зависит от данных так же или даже больше, чем от кода.
И в отличие от кода, который у нас всегда лежит в системах контроля версии (у психически здоровых людей код лежит в системе контроля версии), данные обычно не версионируются. Есть подходы, при которых данные версионируются, например, DVC, но при этом вы все равно версионируете какие-то данные при разработке. На проде идут потоки данных, и для них у вас версий обычно нет. На проде обычно версионируют схему данных. Сами данные могут измениться, и сегодня у них одна схема, завтра у них другая схема. Данные могут исправить задним числом, найдя какую-нибудь ошибку. Это большая проблема.
Кроме того, данных обычно сильно больше, чем кода. То есть, в ML-системе может быть тысяча строк кода, а может быть миллион строк кода. Это довольно большая ML-система. База данных с миллионом строк – это крошечная база.
И таким образом, если у вас что-то не так пошло с кодом, вы можете сравнить версии кода между собой и посмотреть, какая строчка все сломала. Если же у вас что-то не так с данными, то вам трудно сделать diff данных, которые были месяц назад и сейчас, и понять, что же в них сейчас не так.
Есть технологии для построения дифов на данных, та же самая Great Expectations библиотека, которые позволяют документировать статистические предположения о данных. Но в целом диф на данных обычно не работает.
И для того, чтобы наша ML-система работала, нам нужно сделать какие-то предположения о данных, о формате данных, об объеме данных, о потоке данных. И эти предположения могут быть неверны, их нужно проверять, и это само по себе трудно.
Данные важны, потому что модели выявляют шаблоны в данных, и если в данных нет шаблонов, если в данных плохие шаблоны, если шаблоны в данных трудно выявить – то и система будет работать неправильно.
Нормальный поток работы – это мы определяем, что мы хотим достичь, собираем какие-то данные, обучаем модель, потом дообучаем данные для того, чтобы улучшить модель, потому что для модели оказалось, что данных не хватило. Потом мы выгружаем модель на прод, выясняем, что она работает плохо, дособираем данные, дообучаем модель, с прода нам приходят новые данные. Вся жизнь крутится не вокруг обучения модели обычно, а вокруг сбора и подготовки данных.
Andrew Ng предложил разделять подходы к доработке модели на Model-Centric View и Data-Centric View. Model-Centric View – это поиск способа настроить модель или подобрать архитектуру модели так, чтобы улучшить производительность системы в целом. А Data-Centric View – это что нам нужно сделать с нашими данными - добавить новые примеры, аугментировать, как-то переразметить их - чтобы улучшить качество работы нашей системы.
У Эндрю есть программная речь на YouTube, если вы владеете английским, обязательно посмотрите.
Из этого видео пример, как они решали проблемы качества модели. Одна из моделей делала предсказание дефектов в стали - там было видео, на нем искали трещины и неоднородности в стальном прокате, а вторая модель искала дефекты в солнечных панелях. И так получилось, что они смогли работать разными командами, одни команды работали модель-центричным подходом, вторые дата-ориентированным подходом.
Тут статистика аж на двух точках, улыбнемся, но тем не менее дата-ориентированный подход в этом конкретном случае дал прирост, и на самом деле весь мой опыт это подтверждает – что данные важнее моделей, работа над данными окупается.
Что в данных не так – они меняются.
То есть то, что у нас вчера было модной одеждой или модным товаром, сегодня уже не модно.
Позавчера люди ходили без масок, вчера люди ходили в масках, сегодня опять они ходят без масок.
Курс доллара меняется, меняется экономическая ситуация, появляются новые бизнес-процессы и бизнес-модели.
Все это приводит к тому, что шаблоны, которые мы нашли в данных, устаревают. Нам нужно мониторить данные, нам нужно мониторить производительность моделей на данных, и нам нужно делать это как во время разработки, так и во время эксплуатации моделей.
Ну и относительно управления проектами.
Когда вы делаете ML-модель, вам трудно управлять качеством. Вы опираетесь на шаблоны, необозримые и не всегда понятные людям. Поэтому, когда вам говорят – ну вот хорошо, давайте вот это же самое, но на 2% лучше, – может так получиться, что вы уперлись в потолок качества, и эти самые 2% теоретически недостижимы.
Потом, нам трудно управлять сроками. Говоря по-честному, мы не знаем, как достичь результата. То есть есть какие-то шаблонные подходы к решению задач, но обычно все реальные задачи осложнены какими-нибудь мелкими подробностями, которые мешают этот шаблонный подход из коробки применить. Поэтому, когда нас спрашивают, сколько у вас займет времени на эту разработку, мы честно можем ответить – не знаем. И почему? Потому что непонятные границы возможны. То есть во многих случаях, когда мы делаем ML-системы, неизвестно, можно ли достичь результата, который мы решили достичь.
Еще проблема с управлениями ML-проектами в том, что дефекты возникают не только в коде. То есть у нас все может быть хорошо с кодом, но есть какая-нибудь проблема в подготовке данных, в пайплайне данных. Причем данные можем готовить не мы, а Data Engineering команда, заказчик или вообще какой-нибудь внешний поставщик. То есть, например, внешний поставщик мог изменить формат данных, который он отдает по API, и у вас все сломается. То есть дефекты возникают не в коде. Но править их вам придется в коде.
Поэтому в ML-проектах важен мониторинг, важен контроль качества того, что вы получаете на входы данных. И самая удобная модель для построения ML-систем – это двухфазная Discovery и Delivery модель.
На этапе Discovery мы примерно как отсюда и до обеда, то есть, скажем, месяц или два, или полгода, смотря у кого сколько ресурсов, копаем задачи, пытаясь найти работающие подходы. При этом никаких требований к качеству этих подходов мы не можем предъявить, мы на самом деле не знаем, что ищем и чего можем найти. Поэтому копаться тут можно бесконечно, и правильный подход тут – ограничивать по времени. Например – ребята, сейчас месяц мы экспериментируем, потом все наши эксперименты мы документируем, рассматриваем и из них делаем Delivery Backlog, то есть это уже нормальная разработка программного обеспечения. Мы выяснили, что вот этот подход скорее всего работает, теперь давайте его реализовывать. Delivery проект может делаться по Scrum, итерациями, водопадом, как угодно. Главное, чтобы ему предшествовал этап Discovery.
Иногда этим занимаются разные команды. Discovery команда выявляет, что возможно, и пополняет Delivery Backlog, а Delivery команда сталкивается с неразрешимыми проблемами и пополняет Discovery Backlog. То есть какие решения существуют для этих задач.
Поскольку у нас ML-модели будут все время ломаться из-за данных, из-за библиотек, из-за того, что мир меняется, из-за того, что система обычно на стыке нескольких систем, их очень важно мониторить.
Тут есть особенность ML-моделей – они ломаются незаметно. Если у вас сломался автомобиль, то он начал шуметь, стучать, может быть загорелся или встал на ровном месте. ML-модель вместо этого выдает чуть-чуть другую вероятность предсказаний. И во многих случаях у конечного пользователя нет возможности понять, что она сломалась. То есть в случае грубых ошибок он это узнает, но иногда у нас медленная обратная связь, то есть какое на самом деле должно быть предсказание, мы узнаем через месяц, два, три или полгода, как это бывает в Финтехе, например.
Мы можем столкнуться с проблемами просто выяснения, правильно ли работает ML-модель или нет, работает ли она сейчас лучше или нет. Бывают анекдотические случаи, когда модель сразу после деплоя не работает, и этого никто не замечает неделю или две.
У нас обязательно будут проблемы с данными, аномалии, выбросы, у нас обязательно будет меняться распределение данных, у нас возникнут проблемы с метриками, и у нас будет много программных, аппаратных, организационных отказов.
Программное – это когда у нас ошибка в коде. Аппаратное – это когда у нас отвалился какой-нибудь сервер или видеокамеры сгорели. Организационное – это когда мы не договорились со смежниками и кто-нибудь что-нибудь сделал не так. То есть в принципе у нас все работает, но система в целом не живет. Это надо мониторить.
Есть вроде бы как простое правило, что половину эффекта от ML-модели можно достичь без ML-модели. В прошлом году я советовал регулярки и правила. Сейчас, наверное, вместо регулярок можно использовать готовые API или очень простую модель из учебника – раз, два, три, сделали, запустили.
В любом случае, прежде чем делать сложную модель, нужно сделать простой бейзлайн, который делается на коленке, результат которого можно измерить, с которым можно сверяться. Потому что это типичная ошибка, когда люди начинают делать, допустим, нейронную сеть для классификации текстов и не проверили, насколько хорошо этот текст классифицируется в логистической регрессии. Логистическая регрессия зачастую очень хорошо классифицирует текст, прямо-таки на удивление.
Если эксперт не видит в данных закономерности, то ML-модель, скорее всего, тоже их не увидит. Это тоже не всегда так, но часто, если вы говорите - вот люди не могут найти тут закономерности, давайте вы ML-м поищите, – то это не получится, потому что для того, чтобы ML-модель выявляла какие-то закономерности, ей нужна разметка, а разметку делают люди, и если люди не увидели закономерности, то у вас и разметки не будет.
Большинство проблем, не только ML, но вообще большинство всех проблем, оно на границах систем. То есть, вот эта классическая фраза, за которую бьют джунов по рукам - у меня все работает, на моем компьютере все работает, - это как раз пример того, как не учтено взаимодействие внутренних и внешних систем. То есть, ML-система стоит в середине каких-нибудь потоков данных, то есть, ей приходят данные от каких-то систем, она отправляет предсказания в какие-то системы, и когда там что-то меняется, вы ломаетесь. То есть, большинство проблем следует искать на границе.
Основная затрата на построение ML-систем – это сбор и подготовка данных. ML-метрики, которые мы так любим – F1, accuracy и так далее, – они не важны заказчику.
Для простоты можно сказать, что заказчику важны только метрики, выраженные в деньгах. На самом деле это не всегда так. Зачастую заказчику важна скорость принятия решений или скорость сбора аналитики. Но метрики, важные заказчику, придется поискать.
Скорее всего, то, как сам заказчик сформулирует целевые метрики - это какой-нибудь отклик какого-нибудь каргокульта. Он где-нибудь прочитал, что такие метрики достижимы, и их можно попросить достичь. Почему они именно в его случае важны и нужны, как они ему помогают – не всегда очевидно.
Для выявления этих проблем как раз и пишется ML дизайн док, который должен связать метрики, подходы, ограничения и имеющиеся ресурсы.
Хороший программист быстро научится запускать NLP-модели с HuggingFace.
Хорошему исследователю обычно трудно хорошо программировать в том смысле, в каком это понимают в промышленности, то есть сделать какую-нибудь переиспользуемую надежную систему.
Ни тот, ни другой не принесут бизнесу никакой пользы, если мы не сможем вытащить их модель на прод. То есть без DevOps-инженера часто они оба бесполезны.
И есть статистика, она немножко устарела, новой статистики, к сожалению, нет, но в 2020 году было исследование, из него следовало, что больше половины моделей выводятся на прод по полгода и больше. И значительная часть моделей, которые сделали – хорошие, качественные модели, на которые было потрачено много ресурсов, - так и не доходят до прода. Их могут сделать, но не могут внедрить.
Поэтому, начиная делать ML, сразу думайте, как вы будете внедрять эту модель, почему у вас получится внедрить ее, почему у вас получится дотащить ее на прод. И это тоже нужно описать в ML дизайн документе.
В качестве дополнительных материалов к этой лекции я предлагаю три статьи. Одна – Rules of ML. Это старые гугловские скрижали, в которых описано, как делать правильно и как не делать неправильно.
Есть хорошая статья «Скрытый технический долг в системах машинного обучения», в которой разбираются многие из вещей, упомянутых в этой лекции.
И специально для людей, пришедших из академии, которых учили делать статистику и ML, но не учили его применять на практике, есть хорошая короткая статья «Как избегать базовых ошибок при построении модели машинного обучения».
Все эти материалы будут в канале курса, будут доступны на странице курса. Ну а я с вами прощаюсь до следующей недели. Удачи!
Дополнительные материалы к лекции: