Жизненный цикл ML в боевых условиях.
Часть 1

Суровая действительность Data Science решения и план преодоления преград

В реальном внедрении Machine Learning само обучение занимает от силы четверть усилий. Остальные три четверти — подготовка данных через боль и бюрократию, сложный деплой часто в закрытом контуре без доступа в интернет, настройка инфраструктуры, тестирование и мониторинг. Документы на сотни листов, ручной режим, конфликты версий моделей, open source и суровый enterprise — все это ждет data scientist’а. 

Мастер на все руки

Первая частая ситуация — data scientist или data engineer имеет доступ на прод, поэтому ему говорят:

«Ты все это сделал, ты и ставь».

Человек берет Jupyter Notebook или пачку notebook, рассматривает их исключительно как артефакт деплоя и начинает радостно тиражировать на каких-то серверах.

Кажется, все хорошо, но не всегда. Позднее расскажу почему.

Беспощадная эксплуатация

Вторая история заковыристее, и обычно случается в компаниях, в которых эксплуатация достигла состояния легкого маразма. Data scientist приносит свое решение в эксплуатацию. Там открывают эту черную коробку и видят нечто ужасное:

• notebooks;
• pickle разных версий;
• ворох скриптов: непонятно где и когда их запускать, где сохранять данные, которые они порождают.

В этом пазле эксплуатация сталкивается с несовместимостью версий. Например, data scientist не указал конкретную версию библиотеки, и эксплуатация взяла последнюю. Спустя время прибегает data scientist:

— Вы поставили scikit-learn не той версии, теперь все метрики поехали! Нужно откатиться на предыдущую версию.

Это полностью ломает прод, и эксплуатация страдает.

Бюрократия

В компаниях с зелёными логотипами, когда data scientist приходит в эксплуатацию и приносит модель, обычно в ответ получает документ на 800 листов:

«Следуй этой инструкции, иначе твое изделие никогда не увидит свет».

Грустный data scientist уходит, бросает все на полпути, а потом увольняется — ему не интересно этим заниматься.

Деплой

Предположим, data scientist прошел все круги и в итоге все задеплоил. Но понять, что все работает как надо, он не сможет. По моему опыту в тех же благословенных банках нет мониторинга продуктов data science.

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

Когда бизнес и data scientist просто верят, что все замечательно и отлично работает, это выливается в неудачные кейсы.

МФО

Как-то мы разрабатывали скоринговый движок для одной большой микрофинансовой организации. Они не пускали на прод, а просто взяли от нас каскад моделей, поставили и запустили. Результаты тестирования моделей их удовлетворили. Но спустя 6 месяцев пришли обратно:

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

При этом доступ напрямую к модели опять не дают. Месяц выгружали логи, причем шестимесячной давности. Выгрузку мы еще месяц изучали и пришли к выводу, что в какой-то момент IT-подразделение МФО изменило входные данные, и вместо документов в json стали присылать документы в xml. Модель ожидала json, а получала xml, грустила и считала, что данных на входе нет.

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

Новая версия, каскад и тесты

Часто мы сталкиваемся с тем, что модель хорошо работает, но зачем-то разработана новая версия. Модель опять же нужно как-то принести, и заново пройти все круги ада. Хорошо, если версии библиотек как в прошлой модели, а если нет — деплой начинается заново…

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

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

Как решать такие проблемы?

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

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

В суровом enterprise, люди не хотят заморачиваться всякими Питонами, Юпитерами и пр. Они говорят:

— Давайте купим IBM SPSS, поставим и все будет замечательно. Проблемы с версионированием, с источниками данных, с деплоем там как-то решены.

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

Open Source — противоположность предыдущего подхода. Разработчики прошерстили интернет, нашли массу Open Source решений, которые в разной степени решают их задачи. Это отличный способ, но для себя мы не нашли решений, которые бы удовлетворяли нашим требованиям 100%.

Поэтому мы выбрали классический вариант — свое решение. Свои костыли, велосипеды, все свое, родное.

Что хотим от своего решения?

Не писать все самостоятельно.

Хотим взять компоненты, особенно инфраструктурные, которые хорошо себя зарекомендовали и знакомы эксплуатации в тех учреждениях, с которыми работаем. Мы лишь напишем окружение, которое позволит легко изолировать работу data scientist от работы DevOps.

Обрабатывать данные в двух режимах: как в пакетных — Batch, так и real-time.

Наши задачи предусматривают оба режима работы.

Легкости деплоя, причем в закрытом периметре.

Во время работы с чувствительными приватными данными, выхода в интернет нет. В это время все должно быстро и аккуратно доезжать до продакшна. Поэтому мы стали смотреть в сторону Gitlab, CI/CD pipeline внутри него и Docker.

Модель — не самоцель. Мы не решаем задачу построения модели, мы решаем бизнес-задачу.

Внутри pipeline должны присутствовать правила и конгломерат моделей с поддержкой версионированности всех компонентов pipeline.

Что подразумевается под pipeline? В России действует ФЗ 115 о противодействии отмыванию доходов и финансированию терроризма. Только оглавление рекомендаций ЦБ занимает 16 экранов. Это простые правила, которые банк может выполнить, если у него есть такие данные, или не может, если данных нет.

Оценка заемщика, финансовых транзакций или другой бизнес-процесс — это поток данных, которые мы обрабатываем. Поток должен пройти через подобного рода правила. Эти правила простым способом описывает аналитик. Он не data scientist, но хорошо знает закон или иные наставления. Аналитик садится и понятным языком описывает проверки для данных.

Строить каскады моделей.

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

Быстро проверять гипотезы.

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

Легкую возможность переиспользования.

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