[Из песочницы] Подводные камни в управлении Machine Learning проектом
Уже полтора года я занимаю у себя в компании позицию основного ML-разработчика. Полгода управляю небольшой командой. Я накопил опыт, которым хочу поделиться. Делать это буду в формате топа заблуждений и потенциальных трудностей.
Хотим нейросеть!
Очень многие сейчас слышали хоть что-нибудь об искусственном интеллекте и достижениях нейронных сетей. Некоторые хотят использовать в бизнесе нейросети уже только потому, что это популярно. Вот вы решили какую-нибудь небольшую задачу по анализу текста и уже смело можете заявлять всем подряд, что в вашем бизнесе используются самые современные технологии искусственного интеллекта.
При этом практически никто не понимает сильных и слабых сторон нейронных сетей. Ведь из-за высокого ресурсопотребления они далеко не всегда являются оптимальной моделью.
Довольно часто алгоритмы вроде бустинга, k-ближайщих соседей или показывают более высокие показатели качества в решении бизнес-задач (если речь идет оклассическом сценарии фичи → значение), чем нейронные сети. Это при том, что они гораздо более легковесные.
Если клиент говорит вам: «Нам нужна нейросеть для решения такой-то задачи», то скорее всего он просто не знает, какими именно инструментами эту задачу лучше решать. Но ему кажется, что тут нужны какие-то сложные алгоритмы и единственное, что приходит ему на ум — это нейронная сеть.
Так что вы можете решить задачу и через какую-то более лайтовую модель.
Звучит очевидно, но на деле после такого запроса от клиента вы можете потратить время на перебор различных архитектур нейронных сетей прежде чем поймете, что задачу можно было решить гораздо проще.
Утром данные, вечером эстимейты
Довольно часто вас будут просить дать сроки по выполнению экспериментов/выкатыванию решения в прод. Причем в качестве основы для таких эстимейтов могут предоставить лишь абстрактное описание задачи. Например: «Мы хотим нейронную сеть которая будет по медицинским снимкам ставить человеку диагноз заболевания. Сколько времени это займет?». Люди не работавшие с МЛ (а иногда и работавшие) слабо понимают концепцию экспериментов. Многие подходят к разработке МЛ решения как к разработке стандартного ПО. Но это все ошибки. ML-разработка ближе к науке чем к разработке (особенно на начальных этапах). Большую часть времени требуется на анализ данных и эксперименты. И люди редко это понимают.
Если вам повезет и у вас будет например опытный PM, то вам не придется иметь дело с такими проблемами. Он сам объяснит всё заказчику. Но бывает и наоборот — когда PM сам не понимает специфику ML, прогибается под клиента и на пару с ним начинает вас пинать требуя сроки через пару дней или неделю после получения запроса от клиента. Иногда даже до получения данных. Тогда, вам скорее всего придется назвать какие-то сроки (ну или поменять место работы, что тоже неплохой вариант в такой ситуации). Но будьте осторожны если всё же решите делать оценку сроков без достаточного количества информации. Выдилете время на эксперименты с запасом.
Точность модели в предварительном эксперименте 99.99999%
Даже если на предварительных экспериментах или при испытании прототипа вы получили высокие значения метрик, это не повод сразу сообщать их клиенту. Но все, что вы скажете, может быть использовано против вас.
Если вы получили высокие значения оценок качества модели на предварительных экспериментах, можно сказать клиенту, что задача однозначно решаема, но заранее радовать его цифрами, которые могут оказаться не такими хорошими на новых порциях данных, не стоит. Либо же можно назвать метрики, но с обязательной оговоркой, что вы не можете гарантировать, что в других условиях качество останется таким же. Оно может как улучшиться, так и ухудшиться. Всегда остается вариант что вы банально ошиблись при выполнении экспериментов (неправильно написали генератор например и часть данных утекла из обучения в тест).
Как вариант, вы можете фиксировать разную оплату в контракте для разного финального качества вашей модели.
Вообще говоря, люди обычно доверяют конкретным примерам больше, чем абстрактным цифрам. Небольшая демонстрация работы вашей модели придаст клиенту больше уверенности, чем заявления о 99% точности.
С серверами проблем не будет
В какой-то момент начинал замечать, что работа модели часто упирается в её размеры. Например, когда тебе нужно сделать классификатор на 5 миллионов классов, даже самые простые модели могут оказаться слишком ресурсозатратными. Тогда естественным образом встает вопрос спецификации сервера, на что клиент может отмахнуться чем-то вроде: «С серверами проблем не будет — выберем что-нибудь на облачных сервисах».
Проблема в том, что он может совсем не представлять масштабов модели. Например, датасет будет весить 2 терабайта, а матрица весов обученной модели еще 500 гб. Чтобы юзать такую модель, вам нужно 68–128 гб оперативной памяти. Снимать такую машину может стоить клиенту от нескольких тысяч, до нескольких десятков тысяч долларов в месяц (если ещё GPU будут нужны). И вот тут уже не многие согласятся оплачивать такие сервера.
