Философия построения machine learning pipeline

Философия построения machine learning pipeline

Введение

Этим постом мы открываем цикл статей о методологиях построения pipeline в машинном обучении. Здесь вы не найдете погружение в конкретные детали. Наша цель - верхнеуровнево понять, что есть хорошо, а что - плохо. Наша повесть - не о machine learning, а об инфраструктуре, которой вы должны окружить вашу модель для достижения конкретной цели, для удовлетворения бизнес-потребности. Речь пойдет не про ажурные и утонченные архитектуры, красивые сами в себе. Мы поговорим о молотке, которым можно будет забивать гвозди.

Что делает решение успешным?

Можно заметить, что зачастую применение простой baseline модели, с умом конечно же, дает ~95% точности суперзаточенного решения под конкретную область. Ниже представлены подходы, которые дают стабильное улучшение. Итак к сути, что же делает конкретное решение эффективным:

Знание множества state-of-the-art алгоритмов?

Увлечение инструментом вместо решения задач может создать проблему: мы можем начать забивать гвозди микроскопом. Да и надо ли это - все, что новое имеет под собой долю неопределенности, несет за собой опасность. Будь то это новая архитектура модели, новых фреймворк или еще что-то. Другое дело, это проверенные временем инструменты (молоток)! Здесь все все еще опасно, так как машинное обучение относительно молодая отрасль, но это лучше чем ничего.

Знание как применить 3-4 стандартных алгоритмов?

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

Правильно подобранная метрика?

Несомненно да! Мы конкретизируем цели, формализуем. Этот прием можно назвать основополагающим, так как целеуказание задаст вектор всего нашего дальнейшего развития в любую сторону и хорошо, если хоть как-то сонаправленную с нашей “реальной” целью.
Для примера, наша задача - “Мир во всем мире”.
Как мы поймем, что мы этого достигли? Какая здесь метрика?  Давайте будем мерить по среднему уровню эндорфина в крови каждого человека?
А дальше нам нужна реализация нашего плана. Раз уж пошло дело, давайте и рассмотрим state-of-the-art модель: “Способ заключается в употреблении перца чили. Подержите его на языке какое-то время, и вы не только почувствуете себя лучше, но и получите прилив эндорфина”
Модель и метрика ясна. Следовательно, все люди должны положить под язык перец чили и тогда наступит “Мир во всем мире”. Увы, думаю, это не сработает.

Количество данных?

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

Валидация правильности и чистоты исходных данных?

Несомненно да! В computer science даже существует такое выражение GIGO (garbage in - garbage out). Но без имеющего уже решения, человеку оценить качество датасета бывает трудно.
Для примера - есть миллионы фотографий и каждая тысячная плохого качество. Если отфильтровывать руками - это титанический и бессмысленный труд. Самое простое решение - построить хоть какую-то модель и посмотреть на каких примерах совершаются очень грубые ошибки. При рассмотрении таких случаев мы придем к выводу:
На каких-то данных модель отрабатывает плохо.
Какие-то данные просто плохие.
И первое и второе знание очень ценно.

Понимание особенностей данных и понимание специфики сложных для модели данных?

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

Настройка гиперпараметров модели?

Это то, что нужно делать в последнюю очередь (вспомните GIGO принцип).

Валидация результатов?

Этот пункт - несомненно в плюс! Нет понимания качества вашей модели - как правило, нет результата, а точнее он есть, только не тот, что вы ожидаете.

Написание unit-тестов, в адаптированном виде для машинного обучения?

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

Как можно быстрее получить понимание о качестве выстроенного pipeline? 

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



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

Этими узкими местами, как-раз могут быть пункты указанные выше.

Вывод

Так что суммируя все описаное выше, для построение успешного machine learning pipeline нужно все и сразу и еще что-то!