В последнее время я как-то неожиданно для себя стал погружаться в тему машинного обучения. Про алгоритмы я читал и раньше, например, недавно я выкладывал пост про книгу, посвященному обучению нейронных сетей. Сейчас у меня дело дошло до попыток практического применения, правда, не нейронных сетей, а гауссовой регрессии. И мне довольно удачно подвернулась книга, которая посвящена не алгоритмам обучения, как могло бы показаться по ее основному названию, а тому, как создавать системы, которые используют машинное обучение. В этом посте речь пойдет о книге Валерия Бабушкина и Арсения Кравченко «Машинное обучение. Проектирование систем от идеи до реализации».

Это не учебник по машинному обучению, подразумевается, что читатель уже знает алгоритмы, которые собирается применять, он осознает, что данные делят на три кучки: на обучающую, валидационную и тестовую выборки, и в состоянии все это запрограммировать.

Эта книга построена по принципу развернутого чек-листа, с которым можно сверяться на всех этапах разработки, начиная от формулирования того, что мы вообще хотим создать, и до стадии эксплуатации уже запущенной в прод системы. Именно таким образом последовательно выстраиваются главы этой книги.

Отсюда возникает вопрос: существует ли отдельная должность, напрямую связанная с проектированием ML-систем? В настоящее время не существует позиции, полностью охватывающей весь объем работы, который мы будем рассматривать в этой книге. Но если вы все же встретите специалиста, выполняющего все перечисленные задачи, его должность, скорее всего, будет обозначена как «специалист data science».

В книге практически нет кода, а повествование строится вокруг постепенного создания дизайн-документов для двух придуманных проектов, которые используют разные виды машинного обучения. Первый проект реализует модель, которая прогнозирует объемы закупок в крупной сети магазинов с учетом спроса у покупателей на различные виды товаров. Второй проект — сервис фотостока, который с помощью машинного обучения хочет повысить релевантность поиска изображений у себя на сайте. Помимо этого в тексте книги встречаются врезки с описанием реальных проблем и их решений в проектах, над которыми работали авторы книги.

Первая часть книги будет самая скучная для тех, кто сразу с шашкой наголо бросается писать код, как только увидит задание от заказчика. На первых этапах важно сосредоточиться не на алгоритмах, следует понять, какую вообще проблему будущая система должна решать, причем это должна быть проблема заказчика, а не то, как ее интерпретировали для себя разработчики. В результате обсуждения с заказчиком может оказаться, что машинное обучение как таковое и не потребуется, а может оказаться, что проблема не решается в принципе.

Перед началом работы важно собрать как можно больше исходных данных о задаче. Например, насколько большая ожидается обучающая выборка, какие есть ограничения по времени обучения или при эксплуатации, насколько велика цена ошибки, ведь обученная система будет иногда ошибаться, насколько это критично. Нужно описать возможные типы ошибок и договориться, какие из них более критичны, а с какими можно смириться. Интересно, что некоторые вопросы, например, о том, сами мы будем реализовывать ту или иную часть системы, купим ее или отдадим ее разработку в аутсорс, во многом перекликаются с методологией предметно-ориентированного проектирования (DDD). И завершается первая часть книги объяснением того, почему необходимо писать дизайн-документ даже для казалось бы небольших проектов, и что этот документ должен содержать. Два дизайн-документа для описанных выше вымышленных примеров будут создаваться и дополняться на протяжении всей книги, в конце каждой главы эти документы будут обрастать новыми требованиями к различным этапам разработки и эксплуатации.

Специалистов по ML нанимают не просто так — компании нуждаются в них для создания, сопровождения, эксплуатации и улучшения систем, а не ради написания кода или закрытия тикетов в Jira. Бизнесу требуются надежные ML-системы для достижения определенных целей и решения конкретных задач.

Когда общие вопросы относительно того, что должна делать система, внесены в дизайн-документ, настает время поговорить о том, как мы будем оценивать успешность системы. Качество системы с точки зрения разработчика и заказчика — это часто не одно и то же. Необходимо определить, по каким метрикам будет оцениваться качество работы системы в целом с точки зрения пользователя, а затем, как от этих метрик перейти к целевой функции (функции потерь), которую будут оптимизировать алгоритмы. Это тоже должно быть отражено в дизайн-документе.

Следующая часть книги посвящена данным. После понимания решаемой задачи пора задуматься о том, где мы будем брать данные, какого они будут качества, их можно будет использовать сразу или их предстоит предварительно обрабатывать, а если они будут обрабатываться, то каким образом. Будет ли необходимость данные каким-то образом предварительно размечать, если да, то кто этим будет заниматься — своя команда или эту работу отдадим внешним исполнителям? А как контролировать качество разметки? Хорошо бы еще на этом этапе предварительно оценить необходимый для достижения заданных показателей объем данных для обучения моделей.

Прежде всего, не все семплы одинаково полезны. Увеличение объема датасета оправданно только в том случае, если новые объекты позволяют модели обучаться чему-то новому и актуальному в рамках поставленной задачи.

После того, как мы определились с источниками данных, из всего массива данных следует выделить те данные, которые будут использоваться для валидации модели в процессе подбора ее метапараметров. Авторы предупреждают о проблемах, которые при этом могут возникнуть, и на что обращать внимание, чтобы их избежать. Описываются несколько алгоритмов, по которым можно отделять обучающие выборки от данных для валидации модели. Рассмотрены особенности, возникающие для данных, которые представляют собой временные ряды.

Еще мне понравилась одна мысль, которая заключается в том, что прежде чем начать делать полноценную модель, попробуйте сделать так называемую базовую модель, которая должна быть как можно более простой, но давать хоть какое-то нулевое приближение к решаемой задаче. Возможно, что базовая модель даже не будет использовать машинное обучение, а обойдется зашитой логикой. Во-первых, на такой базовой модели можно будет проверить какие-то предположения, которые затем можно будет перенести на большую и сложную модель. Во-вторых, уже даже такая простая модель может быть полезна заказчику, пока не будет готова основная модель. В-третьих, на базовую модель можно будет переключить прод в случае падения полноценной модели или возникновения с ней еще каких-то проблем.

Если представить, что ML-система — это конструктор Lego, то базовая модель — это способ как можно быстрее собрать все блоки.

Еще одна часть книги посвящена вопросам обучения модели. В идеале, чем больше обучающих данных мы подаем, тем меньше должно быть значение функции потерь, но в реальности у нас может случиться переобучение, функция в принципе может не сходиться, а могут возникать всплески. Авторы показывают несколько паттернов поведения кривой обучений и дают рекомендации, на что обратить внимание, если кривая обучения вашей модели ведет себя не идеальным образом. Затем говорится про еще один этап отладки модели — анализ остатков, то есть разницы между результатом, который выдает модель, и эталонными данными.

Анализ ошибок служит своеобразным компасом, направляющим итеративные обновления системы. Он помогает понять динамику ошибок во время фазы обучения (анализ кривой обучения) и распределение ошибок после этапа прогнозирования (анализ остатков).

Теперь, когда обучение модели заработало, настало время задуматься о выстраивании пайплайна обучения — последовательности действий, которые необходимо выполнить от момента получения сырых данных на входе и до выдачи готовой обученной модели на выходе. Это важно, поскольку в процессе работы с моделью могут появляться новые требования или возникать новые неожиданные данные, которые тоже должны учитываться, и если каждый раз модель обучать вручную, это будет занимать слишком много времени. Выделяют два вида пайплайнов — пайплайн обучения, на выходе которого получается новая обученная модель, и пайплайн инференса, для которого модель уже создана, а на выходе мы получаем прогноз. В разных главах книги говорится про оба этих пайплайна.

В книге описывается еще один термин, связанный с пайплайном обучения — MLOps, устоявшийся по аналогии с DevOps. MLOps — это область, которая объединяет в себе методы и инструменты для построения пайплайна обучения.

Довольно подробно разбирается тема генерации признаков для модели, говорится о том, как можно оценить качество признаков, на что обратить внимание при их отборе и генерации. Подчеркивается, что много признаков — это не всегда хорошо, а скорее путь к переобучению модели. Авторы рассматривают вопросы, связанные с хранением признаков и интерпретируемости модели, поскольку часто прозрачная модель, для которой по значениям признаком можно понять, почему она выдала тот или иной прогноз, имеет худшие характеристики по сравнению с моделью для которой, интерпретировать значения признаков человеком проблематично.

Процессы генерации и отбора признаков в ML можно сравнить с садоводством. Подобно садовникам, которые высаживают в землю различные семена, мы создаем множество признаков, исследуем новые источники данных, экспериментируем с различными преобразованиями признаков и генерируем идеи, которые могут улучшить производительность модели.

Еще одна проблема, о которой довольно подробно говорится, это оценка качества модели. Поскольку надо понимать, дает ли разработанная модель какое-то статистически значимое улучшение с точки зрения бизнеса, одним из основных способов это выяснить — A/B-тестирование, когда часть пользователей начинает работать с новой моделью, а другая часть — со старой версией модели или вообще без моделей, использующих машинное обучение. Важно правильно анализировать полученные результаты с точки зрения статистики. Например, важно понимать, собрано ли уже достаточное количество данных, чтобы результаты можно корректно интерпретировать. Планированию таких экспериментов и анализу полученных таким образом результатов уделено достаточно много внимания со скидкой на то, что это все-таки не учебник по статистике, и на эту тему пишут целые книги.

Завершающие главы книги посвящены вопросам, возникающим, когда модель готова и ее пора встраивать в рабочий процесс, возможно, как отдельный сервис в составе более сложной системы. Здесь речь пойдет об аккуратном проектировании API с учетом того, что модель будет развиваться, API может меняться, и надо сохранять обратную совместимость с сервисами, которые используют API старой версии. При этом авторы советуют предусмотреть механизм отключения модели или прозрачного переключения на более простую модель (например, ту же базовую модель, о которой говорилось ранее), если с новой моделью возникнут какие-то проблемы.

А проблемы с моделью могут возникать не только технического характера, модели могут устаревать со временем. Могут происходить так называемые дрейфы данных и концепции, связанные с изменением входных данных или связи между входом и выходом модели по какой-либо причине (эпидемии, войны, изменения в законодательстве). В этом случае важно вовремя заметить, что модель стала вести себя менее адекватно, а для этого нужен постоянный мониторинг результатов работы модели, после чего требуется заново переобучить модель с учетом изменений во входных данных.

Далее рассматриваются вопросы, связанные с сопровождением и оптимизацией работы моделей. Для оптимизации рассматриваются разные пути — это упрощение модели (уменьшение числа параметров), использование распараллеливания, кэширование. Коротко говорится о «бессерверной» архитектуре (serverless).

И в завершение снова рассматриваются организационные вопросы, но связанные уже не с разработкой, а со все тем же сопровождением. Например, говорится об организации дежурств на случай сбоев на сервере или при возникновении внезапных проблем с моделью. Затем еще раз обсуждается тема документации, но уже на более высоком уровне, сколько видов документации должно быть и для кого они пишутся.

Я перечислил только некоторые наиболее крупные темы, которые обсуждаются в книге, каждая из них достойна отдельной книги или как минимум большой статьи. Авторы постарались обозначить как можно больше проблем, которые могут возникнуть на всех этапах от разработки требований до сопровождения сервисов, использующих модели машинного обучения. При этом авторы дают направление, в какую сторону копать при возникновении описываемых проблем, приводят большое количество ссылок, в том числе на научные статьи.

В целом книга полезная, читается она легко. Ее не обязательно читать последовательно, можно заглядывать в нужные главы, которые относятся к той сфере, которой вы сейчас занимаетесь. Но надо иметь в виду, что это не учебник по машинному обучению, здесь рассматриваются проблемы на более высоком уровне. Эта книга ориентирована на тех, кто работает в команде, которая применяет машинное обучение для своих сервисов, и это не только программисты.

PS. Вы можете подписаться на новости сайта через RSS, Группу Вконтакте или Канал в Telegram.