Каждая корпоративная ИТ-организация сталкивается с трудностями при развертывании и поддержке моделей машинного обучения (ML) в производственной среде. После нескольких громких неудач они осознали, что для реализации бизнес-отдачи от своих инвестиций в ИИ им нужна другая инфраструктура и процессы. Им нужны операции машинного обучения или MLOps.

MLOps — это быстро развивающаяся область, и даже так называемые эксперты расходятся во мнениях относительно основных принципов. Я обнаружил, что легче понять MLOps, начав с «почему». С этой целью я собираюсь объяснить, что вы можете ожидать от своих инициатив ML, если вы попытаетесь развернуть и использовать их, используя традиционные ИТ-подходы, а не MLOps. Я начну с представления подхода, который я называю антипаттерном MLOps.

Антипаттерн MLOps

Антишаблон – это распространенное неэффективное решение повторяющейся проблемы. Антишаблон может даже привести к результату, которого вы не хотите. Антипаттерн MLOps — это неэффективный, немасштабируемый и в конечном итоге дорогостоящий подход к развертыванию и поддержке приложений, основанных на машинном обучении. Корпоративные ИТ-организации обычно попадают в антипаттерн MLOps. Они предполагают, что могут развертывать и поддерживать модели машинного обучения, используя традиционные шаблоны разработки программного обеспечения.

Антипаттерн MLOps начинается с ошибочного предположения о том, как специалисты по данным строят модели машинного обучения. В этом антипаттерне специалист по данным разрабатывает модель в автономном режиме и передает ее ИТ-отделу для развертывания. ИТ-специалисты обращаются с моделью так же, как с любой другой сторонней программной библиотекой, то есть «просто с двоичным кодом». Они пишут его в интерфейсе прикладного программирования (API) и вызывают из другой функции.

Чем привлекателен антипаттерн MLOps

Антипаттерн MLOps привлекателен по нескольким причинам:

  • Он изолирует науку о данных от ИТ: большинству специалистов по данным не хватает знаний в области разработки программного обеспечения для разработки решений для производства. И наоборот, ИТ-инженерам не хватает знаний в области машинного обучения, чтобы понять, как разрабатываются модели. Поскольку антишаблон MLOps обещает четкое разграничение ролей, это естественный выбор для команд, работающих в изолированных отделах.
  • Это упрощает отчетность:ИТ (по понятным причинам) не хотят нести ответственность за результат или точность модели, которую они не разрабатывали. Модель, изолированная интерфейсами, разделяет ответственность.
  • Это позволяет избежать инвестиций в новую инфраструктуру.Когда ИТ-команда рассматривает машинное обучение как «просто двоичный файл», у них есть возможность развернуть машинное обучение в любой современной инфраструктуре данных. Никаких новых инструментов или облачных платформ не требуется.

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

Пример. Классификация текста с использованием обработки естественного языка

Чтобы проиллюстрировать проблемы с антипаттерном MLOps, я приведу пример. Одним из наиболее распространенных бизнес-приложений для современного ИИ является чтение и классификация документов с использованием обработки естественного языка (NLP). (Дополнительную информацию о приложениях НЛП на основе ИИ см. в нашей книге Стать компанией ИИ за 90 дней.)

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

Вот шаги для создания и развертывания решения NLP на основе антипаттерна MLOps:

  1. Специалисты по данным встречаются с юристами, чтобы определить ключевые слова и условия поиска, имеющие отношение к их проверке правовых рисков.
  2. Специалисты по данным обучают модели преобразователя NLP автоматически определять правильные разделы контракта.
  3. Специалисты по данным предоставляют ИТ-отделу обученную модель и инструкции по ее использованию.
  4. ИТ-отдел развертывает модель, создавая интерфейсы для вызова модели и отображения результатов для юристов.

Эта упрощенная диаграмма иллюстрирует решение.

Вот рабочий процесс:

  1. Контракты хранятся в системе управления документами компании или в файловой системе. Всякий раз, когда новый контракт сохраняется, функция отправляет его на этап предварительной обработки.
  2. Контракт предварительно обрабатывается, чтобы его можно было использовать в модели. Например, контракт PDF преобразуется в текстовый файл и разбивается на фрагменты текста.
  3. Модель обрабатывает эти фрагменты текста и классифицирует их на основе регуляторного риска.
  4. Полученные фрагменты классифицированного текста сохраняются в базе данных.
  5. IT создает инструмент поиска для юридического отдела.

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

Но через несколько недель после запуска приложения начинают появляться проблемы:

  • Модели классификации контрактов на практике работают плохо. После того, как весь юридический отдел начинает использовать приложение, юристы обнаруживают, что модель ошибочно помечает многие разделы контракта как опасные. Вместо того, чтобы экономить время, решение создает дополнительную работу для юристов, поэтому они перестают его использовать.
  • Устранение проблемы займет гораздо больше времени, чем ожидалось. Специалисты по данным считают, что проблема решаема, но им необходимо переобучить модель с обновленными ключевыми словами и дополнительными документами. Специалистам по данным необходимо собрать дополнительные контракты, обновить код обработки документов для учета новых форматов, встретиться с юристами, чтобы собрать новые ключевые слова, обновить рабочий процесс обучения слабому надзору, переобучить модель и получить больше отзывов от юридического отдела. По оценкам специалистов по данным, им потребуется не менее 10 недель, чтобы переобучить модель.
  • Текучесть кадров еще больше задерживает реализацию проекта. Ученый по обработке и анализу данных, обучивший первоначальную модель, принимает предложение о работе с более высокой оплатой. (См. наш бесплатный отчет Win the War for Data Science Talent для получения советов по найму и удержанию специалистов по данным.) Другой специалист по данным берет на себя проект, но изо всех сил пытается воссоздать предыдущую работу. Она обнаруживает, что исследователь исходных данных не смог задокументировать многие эксперименты. И он оставил разные версии моделей, экспериментальный код и наборы данных, разбросанные по многочисленным системам и папкам. Новый специалист по данным считает, что ей понадобится месяц или больше, чтобы разобраться с проблемами.
  • Командный Agile-процесс нарушается. Скрам-мастер встречается с командой разработчиков, чтобы спланировать работу на следующий спринт. Но планы терпят неудачу, потому что специалисты по обработке и анализу данных не могут свести экспериментальный характер своей работы к формату, согласующемуся с остальной частью команды. В результате проектная группа не может предсказать следующий выпуск приложения с улучшенной моделью.
  • Приложение не может обрабатывать новую партию контрактов. Компания рассматривает возможность приобретения и должна проверить тысячи контрактов на юридические риски в рамках процесса комплексной проверки. Команда юристов ожидала, что решение по классификации контрактов поможет ускорить этот процесс, но решение не может с этим справиться. Команда специалистов по данным объясняет, что они не ожидали распространения решения на другие форматы контрактов, и им потребуется перезапустить весь процесс обучения модели.
  • Приложение не масштабируется для других документов и вариантов использования. Хуже всего то, что руководство осознало, что проект был инициирован на основе неверного предположения о том, что решение можно использовать для других типов документов. Группа обеспечения соответствия требованиям хочет классифицировать электронную почту и документы на основе потенциальных нарушений. Служба поддержки клиентов хочет классифицировать документы политики на основе сегментов клиентов. HR хочет классифицировать резюме на основе соответствия должности. Ни один из этих вариантов использования невозможен без запуска совершенно нового проекта.

Каждая компания сталкивается с такими проблемами. Если вы не заложите основу для надежного решения MLOps, вы столкнетесь с теми же или похожими проблемами.

Почему не работает антипаттерн MLOps

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

Модели машинного обучения требуют итерации

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

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

Оценка – это организационная работа

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

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

Модели выходят из строя тихо и внезапно

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

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

Управление версиями может привести к перегрузке операций

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

  • Администраторам необходимо несколько версий модели для использования в качестве запасных вариантов.
  • Данные для обучения модели необходимо поддерживать и обновлять вместе с самими моделями.
  • Инструменты разработки данных, такие как блокноты Jupyter, не поддаются управлению версиями.

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

Будьте открыты для изменений

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

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

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