Data science – необходимый инструмент для решения разного рода прикладных задач. Однако разработка проектов в данной сфере зачастую вызывает некоторые вопросы. Давайте попробуем рассмотреть на конкретных примерах, как оптимизировать процесс работы с data science.
Первая причина возникновения сложностей у начинающих специалистов data science заключается в отсутствии подходящей методологии, по которой мы привыкли действовать, используя традиционные технологии.
Самой популярной методологией, которой сегодня пользуются разработчики data science является CRISP-DM или Cross-Industry Standard Process for Data Mining, что переводится как «межотраслевой стандарт анализа данных». Существуют и другие более «свежие» аналоги CRISP-DM, но пока ни один из них не заслужил такой популярности среди разработчиков.
Итак, CRISP-DM разделяет процесс анализа данных на несколько основных составляющих, куда входят:
- понимание поставленной задачи,
- понимание данных,
- процесс подготовки данных,
- построение моделирования,
- оценка и развертывание системы (деплой).
Плюс методологии — в том, что на практически любом этапе возможен возврат к предыдущим ступеням.
Теперь поговорим подробнее о каждом из вышеперечисленных этапов:
Понимание задачи
Первая ступень к пониманию задач — четкая постановка цели проекта с максимально жесткими критериями для достижения заданной цели. Например, нужно четко определить, в чем будет измеряться эффективность от внедрения проекта для вашей компании.
Здесь сразу стоит отметить, что создание, разработка и переход компании на использование DS-решений — процесс довольно затратный, поэтому прежде чем принимать решение о проектировании нужно убедиться в том, что данное нововведение сможет окупиться.
Дело в том, что машинное обучение нужно далеко не каждой организации, а только тем, кому необходима автоматизация рутинных процессов, ведущих к накоплению огромного массива данных.
Например, data science может помочь компаниям, которые постоянно тратятся на целый штат сотрудников службы поддержки, в функции которой входит обработка внешних заявок. Однако, если вашей компании требуется обработка большого объема данных от случая к случаю, скорее всего дешевле будет справиться без автоматизации.
Поставленную бизнес-задачу нужно формулировать в виде задачи анализа данных, определив метрики, по которым будет математически оцениваться качество. Это может быть, например, точность, выраженная в доле определяемых правильно объектов.
На первой ступени разработки также появляется примерный план проекта, составляется приблизительный набор инструментов для анализа данных. Здесь нам необходимо определить насколько сложная требуется модель, сколько ресурсов мы готовы вложить и сколько денег потратить. Возможно, стоит остановиться на несложном традиционном, но проверенном алгоритме?
Как правило, недопонимания между заказчиком и разработчиком в проектах, связанных с data science, возникают гораздо чаще, чем при создании традиционных алгоритмов. Дело в том, что заказчику довольно сложно понять, что именно из себя представляет эта система и каковы ее реальные возможности. Снизить вероятность недовольства друг другом поможет обратная связь и умение специалистов понятно объяснять представителю заказчика сложные вещи.
Понимание данных
Данный этап подразумевает получение и анализ данных от заказчика, при этом важно, чтобы специалист понимал, с какими данными он работает, какова их природа и вероятность того, что в них есть ошибки.
Иногда из-за того, что в имеющихся данных процент ошибок слишком велик, применение алгоритма может вместо пользы принести обратный эффект. Данная проблема является довольно типичной, например, при разработке системы автоматических ответов для службы поддержки. В таких случаях часто используются реальные ответы операторов службы, но, как известно, сотрудники периодически ошибаются, а иногда и сознательно «халтурят». Использование некачественных данных может сильно испортить результат совместной работы заказчика и исполнителя.
Существует несколько способов избежать таких ситуаций:
- Можно заставить специалистов заказчика разметить копившиеся годами данные. Однако это отвлечет сотрудников от основной их работы и займет большое количество времени.
- Можно поручить работу внешним сотрудникам или аналитикам, но тогда может сильно пострадать качество, потому что люди со стороны не могут знать всех внутренних нюансов компании, а предусмотреть их в даже самых подробных инструкциях очень сложно.
- Можно применить все те же алгоритмы машинного обучения уже для поиска аномалий. Но подобный путь подойдет только в том случае, если процент ошибок не слишком большой, иначе алгоритм примет за аномалии правильные данные и тогда результат работы сведется к нулю.
Иногда при недопонимании заказчиком поставленных задач, исполнителям могут быть даны совсем неправильные данные, тогда целесообразно вернуться к первому этапу и обсудить требования с самого начала.
В конце концов, у компании может не оказаться вообще никаких данных. В таком случае использование алгоритмов машинного обучение невозможно, так вся их суть основана именно на анализе существующей информации. Сейчас многие специалисты говорят о важности развивать в компаниях «аналитическую культуру» — т. е. понимание необходимости накапливать и структурировать внутреннюю информацию.
Подготовка данных
Этот шаг подразумевает составление необходимых выборок, фильтрацию данных от «информационного мусора», приведение массива к нужному формату, а также конструирование признаков.
Сложности могут возникнуть при слиянии информации из разных источников, если заказчиком используется несколько баз данных.
Моделирование
На данном этапе определяются потенциально подходящие алгоритмы, после чего подбирается метод, с помощью которого будет оцениваться качество модели. Например, это может быть определенный показатель качества на тестовой выборке. Важно отметить, что тестовая выборка — это всегда новая, не «прогонявшаяся» через алгоритм, часть данных.
Далее происходит обучение и настройка моделей с помощью подбора параметров, дающих самый высокий уровень качества. По результатам, выбираются лучшие модели из всего пула.
На данном этапе наступает тот самый момент, когда теория сталкивается с реальностью, поэтому провал на этой точке будет самым значительным и болезненным. Нередки случаи, когда модель, которая в теории казалась почти идеальной, при использовании оказывалась неточной и малоэффективной. Единственным способом застраховаться от подобных коллизий, может быть плавный переход от простых, проверенных алгоритмов к более продвинутым.
Оценка
Для проверки эффективности модели «на полях» часто используют метод A/B-тестирования. Для этого берется две группы сотрудников, одна из которых начинает работать по новой методике, а другая — продолжает использовать привычную. Например, часть коллектива работает на автоматизированной системе, а часть продолжает обрабатывать данные вручную.
Через определенный период времени производится замер и сравнение показателей эффективности работы.
Можно тестировать модель на одной группе в разных временных отрезках и сравнивать результат «до» и «после».
Иногда заказчик может вообще отказаться от данного этапа, для того чтобы сэкономить время и средства. Однако стоит понимать, что пренебрежение оценкой при наличии не выявленных недостатков системы, может стоить в итоге гораздо больших денег.
Развертывание
Последний этап включает создание финального кода, утверждение итоговой модели и развертывание DS-решений в рамках компании.
На данном этапе, как ни странно, также могут скрываться подводные камни. Важно тестировать систему не только для проверки ее работы, но и для проверки адекватности итоговой модели. Для реализации таких проверок иногда требуются нестандартные подходы. Особенно эта проблема актуальна при отсутствии тестовой выборки. Ярким примером тому может служить разработка поисковых систем. Важно самостоятельно проверить, находит ли система правильные страницы по заданным фразам, иначе, если модель построена с ошибкой, алгоритм будет выдавать некорректные результаты и система будет разрушена.
Проверка на данном этапе не только дает информацию о корректности работы системы, но и упрощает процесс поддержки и развития алгоритма в дальнейшем.
Подводим итоги
Данная методология не является полной инструкцией по работе с data science. В ней опущены такие важные моменты, как распределение ролей в команде, весьма условно разделены этапы. Вопрос дальнейшей поддержки системы, который будет остро стоять перед заказчиками и исполнителями, также не включен в рамки методологии. Данная цепочка может работать только в идеале, ведь реальность постоянно меняется и в дальнейшем компании, как правило, требуются новые признаки или переменные, которые могут в корне менять работу алгоритма.
Переобучение модели — процесс сложный и трудоемкий, и универсального решения для его оптимизации быть не может.
Более того, помимо доработки и поддержки системы, важно регулярно продолжать ее тестировать, а также анализировать отзывы пользователей.
Узнав о трудностях работы с data science, многие, вероятно, вообще захотят отказаться от попыток внедрения в жизнь данных систем. На самом деле, если бы польза от данных систем не превышала затрат, они не набирали бы популярности с такой скоростью. Однако, важно помнить, что для достижения реальной эффективности моделирования, оно должно осуществляться без отрыва остальных блоков при решении прикладных задач.