Эта статья (Почему проектами машинного обучения так сложно управлять? Лукаса Бевальда заставила меня задуматься о некоторых других проблемах, которые затрудняют управление проектами машинного обучения. Вот несколько наблюдений, которые я сделал.

Управление ожиданиями

Как упоминалось в статье Лукаса, установление ожиданий само по себе является проблемой. При установлении ожиданий необходимо учитывать несколько аспектов:

  • Ваши клиенты (внутренние или внешние), скорее всего, слышали только об удивительных успехах машинного обучения, а не о его неудачах. Поэтому ожидается, что их проблема не должна быть такой сложной, если у вас действительно хорошая команда.
  • Если бюджет установлен, ожидается, что у вас будет возможность обосновать, как был потрачен каждый час или доллар. Утверждение, что «мы пробовали X, Y и Z, но все они потерпели неудачу», может вызвать ответ, что это должна была быть деятельность по разработке, а не исследовательская деятельность, проводимая в рамках этого бюджета.
  • Иногда бывает трудно указать разумные и обоснованные сроки для выполнения проекта машинного обучения. Могу ли я всегда сказать, что даже такое простое действие, как очистка данных, определенно будет выполнено за 2 недели? Часто можно оценить время только после изучения данных.
  • Команда ML не может быть экспертом в предметной области. Это приводит к проблемам двумя способами: (i) мы получаем модель, работающую хорошо, только для того, чтобы SME (эксперт в предметной области) сообщал нам, что данные не должны были включать некоторые функции, и (ii) мы застреваем на производительность, но понятия не имею, могли ли мы действительно использовать еще несколько функций, которые должны были быть доступны. Ожидания относительно знаний предметной области внутри команды машинного обучения могут быть разными у разных заинтересованных сторон.
  • Члены вашей команды могут столкнуться с трудностями, пытаясь справиться с неопределенностью результатов. От них не всегда легко ожидать по двум причинам: (i) менеджеры не всегда могут знать, возможен ли лучший результат, и (ii) менеджеры не всегда могут знать, насколько лучше могут быть достигнуты результаты.
  • Трудно справиться с (предполагаемой) неудачей. Достаточно сложно оправдать неудачу для ваших клиентов, но еще труднее оправдать ее для себя (или провести честный постфактум анализ). Как менеджер вы не всегда можете объективно сказать, что ваша команда была недостаточно хороша или что вы недостаточно старались. Вы можете ожидать, что с каждым выполняемым проектом будете становиться лучше, но этого не всегда можно ожидать.

Вот некоторые из способов решения этих проблем:

  • Получите одобрение со стороны клиента, что в худшем случае это может быть просто исследовательский эксперимент. Что даже приложив максимум усилий, мы можем закончить с отрицательным результатом.
  • Объясните покупателю, какие проблемы могут быть сложными и почему. Информируйте их о состоянии дел в решении связанных проблем. Объясните им, почему результаты по кажущимся схожим задачам на самом деле могут не подходить.
  • Как можно раньше проинформируйте клиента, если данных, которые они предоставляют команде, может быть недостаточно для получения результатов. В качестве простого примера: любое ожидание хорошего результата для задачи классификации без достаточного количества помеченных данных должно быть решительно рассмотрено.
  • Как можно чаще взаимодействуйте с клиентом, чтобы понять его данные, и сообщите им о каждом подходе, который вы, возможно, исчерпали в поисках лучшей производительности.
  • Будьте честны, когда чувствуете, что можете застрять в производительности.

Модельная инженерия

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

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

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

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

Я надеюсь, что усовершенствования инструментов со временем решат многие из этих проблем управления.

Другие вопросы

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

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

Было бы интересно узнать, сталкивались ли другие из нас с этими проблемами и как они их решали.