Рекомендации для групп по науке о данных

Введение

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

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

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

Оглавление:

Я. Оптимальная структура команды по обработке и анализу данных: список определений ролей

II. Как нанять специалиста по обработке и анализу данных: процесс собеседования

III. Как разработать эффективный процесс адаптации новых специалистов по обработке и анализу данных

IV. Как провести техническую комплексную проверку для оценки проекта по науке о данных

В. Проблемы и передовой опыт в процессе разработки продуктов для обработки и анализа данных

VI. Манифест внедрения науки о данных: как спроектировать различные подкомпоненты конвейера реализации

Давайте обсудим каждую тему в отдельном разделе в остальной части статьи.

I. Оптимальная структура команды по обработке и анализу данных: список определений ролей

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

Младшие специалисты по обработке и анализу данных.

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

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

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

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

Старшие специалисты по обработке и анализу данных.

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

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

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

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

Наконец, эта группа специалистов по данным также должна постоянно отчитываться перед руководителем группы.

Ведущий специалист по данным (руководитель группы)

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

Все проекты должны выполняться под техническим контролем ведущего специалиста по данным. На жаргоне GitHub вы могли бы думать об этом человеке как о последнем шаге, на котором мы объединяем ветку с мастером. Если команда использует Github в качестве системы контроля версий, руководитель группы должен отвечать за управление репозиторием кода и организовывать его в команде.

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

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

Менеджер проекта

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

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

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

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

Инженер данных

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

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

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

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

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

Аналитик продукта

Аналитик продукта — это член команды, который отвечает за разработку экспериментов и проведение A/B-тестирования для оценки производительности моделей в реальных условиях использования.

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

Внешний разработчик

Для многих приложений и моделей для обработки и анализа данных требуется панель инструментов, чтобы представлять все результаты в одном месте в более привлекательной форме. Я считаю, что это самый эффективный подход к продаже продуктов команды остальному сообществу в компании. Предположим, что ваша команда работала над несколькими прогностическими моделями, которые производят множество пользовательских данных, таких как оценка риска оттока, вероятность покупки, оценка риска мошенничества, прогнозируемый возраст, прогнозируемый пол, этап жизненного цикла клиента, рекомендуемые продукты и т. д. По сути, мы могли бы нарисовать прогнозирующий профиль пользователя 360 с использованием результатов множества различных моделей машинного обучения. Тем не менее, некрасиво все время представлять эти результаты в виде слайдов. Таким образом, разработчик внешнего интерфейса должен создать для команды информационную панель Data Science Dashboard, тесно сотрудничая с аналитиком продукта для визуализации данных и построения графиков.

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

Руководитель отдела науки о данных

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

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

Самая важная обязанность этой роли — быть мостом между мирами Business/Product и Data Science. Следовательно, требуется способность сопоставлять бизнес-задачу с существующим решением для обработки данных и наоборот. Таким образом, у команды будет шанс установить двусторонние отношения с бизнесом. Вместо того, чтобы постоянно ожидать запросов на продукт со стороны бизнеса, они могли бы также предоставить бизнесу информацию о том, что можно сделать с использованием текущих инструментов и алгоритмов обработки данных. Это сделает команду более заметной в компании. Таким образом, изменение мышления C-level или деловых людей в сторону науки о данных можно считать еще одной спецификацией этой роли.

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

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

II. Как нанять специалиста по данным: процесс собеседования по науке о данных

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

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

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

ПРИМЕРЫ

В общей сложности 3 тематических исследования сделают то, что мы хотели бы сделать, чтобы квалифицировать специалиста по данным для роли в команде:

Случай 1. Обращение к специалисту по обработке и анализу данных с просьбой представить одну из его предыдущих работ.

Ожидается всестороннее понимание того, что было сделано в этом проекте, включая все технические и нетехнические этапы.

Случай 2. Обращение к специалисту по обработке и анализу данных с просьбой предложить комплексное решение проблемы, с которой в последнее время столкнулась ваша команда.

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

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

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

III. Как разработать эффективный процесс адаптации новых специалистов по данным

Большинство компаний либо пропускают, либо игнорируют этот процесс адаптации своих новых специалистов по обработке и анализу данных. Такие процессы есть лишь в нескольких компаниях, но в основном это беглые и неорганизованные обучающие занятия. Лично я считаю эти учебные занятия жизненно важными для новых специалистов по данным, чтобы они могли видеть общую картину яснее и быстрее. Поэтому компаниям не жалко потратить даже целый месяц на обучение новых сотрудников и знакомство их с бизнесом и самим продуктом. Это действительно важно, особенно для команды Data Science, по следующим причинам:

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

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

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

ОБУЧЕНИЕ ПОЛЬЗОВАТЕЛЯМ: ГЛУБОКОЕ ПОНИМАНИЕ ПОЛЬЗОВАТЕЛЕЙ НА РЫНКЕ

У нас есть две основные группы пользователей на наших торговых площадках: покупатели и продавцы. Если вы находитесь на нашей платформе, чтобы купить товар, то вы являетесь покупателем, но если вы посещаете нашу платформу, чтобы опубликовать объявление о продаже товара, то вы являетесь продавцом. В этом сеансе продукта вы должны попросить своего нового сотрудника сначала действовать как покупатель, а затем как продавец на платформе.

Случай 1. Вы покупатель

Создайте учетную запись → Просмотрите различные категории → Просмотрите различные списки → Добавьте объявление в избранное → Перейдите на «Мою страницу», чтобы просмотреть избранные списки → Введите что-нибудь в строке поиска → Просмотрите результаты поиска → Уточните эти результаты, используя другую комбинацию поисковых фильтров → Сохранить «уточненный поиск» для последующего использования → Попасть на определенную страницу со списком товаров → Сделать ставку на нее → Отправить сообщение продавцу

Случай 2. Вы продавец

Создайте учетную запись → Выберите товар для продажи на платформе → Выполните поиск в списке категорий, чтобы найти наиболее подходящую категорию для вашего товара → Заполните соответствующие атрибуты товара, который вы продаете, такие как размер, цвет, цена и т. д. → Опубликуйте свое объявление и проверьте, получили ли вы электронное письмо с подтверждением → После того, как ваш товар появится на платформе, перейдите на страницу «Мои объявления», чтобы просмотреть свой товар. → Постарайтесь собрать некоторые показатели эффективности для ваших объявлений, например, сколько людей уже просмотрели ваш товар или добавили его в избранное → Получите сообщение от покупателя → Проведите достойную и долгую беседу с покупателем → Удалите свое объявление с платформы

IV. Как провести техническую комплексную проверку для оценки проекта по науке о данных

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

Деловые вопросы

Какую бизнес-задачу должна решить эта система?
Каково формальное определение «успешного поиска» для бизнеса? (например, релевантность против семантического сходства или разнообразия в верхних результатах поиска)
Как работает текущая базовая система поиска?
Каковы основные болевые точки базовой линии?
Ожидается ли применение каких-либо предопределенных бизнес-правил к новой системе ранжирования поиска? (РИСК! Необходимо учитывать определенные правила и запреты в бизнесе.)
Какой бизнес-показатель мы будем стремиться улучшить с помощью этого нового поиска?

Сбор данных

К каким входным наборам данных подключен этот конвейер? (например, показы, клики, результаты поиска и т. д.)
Где находится входной набор данных? Любое разбиение на этот набор данных?
Насколько велики входные данные? (РИСК! Нам может понадобиться агрегация данных постепенно, путем создания набора заданий по преобразованию данных.)
Предназначен ли этот конвейер для пользователей одной платформы (например, только для Интернета) или для пользователей нескольких платформ (например, для Интернета и мобильных устройств)? (РИСК! Вероятно, поисковые характеристики веб-пользователей отличаются от характеристик мобильных пользователей, и с ними нужно работать по-другому.)
Это анализ для только что вошедших пользователей или всех пользователей, включая анонимных? (ПРЕДЛОЖЕНИЕ: рассмотрите возможность использования более широких пользовательских функций для вошедших в систему пользователей)
Является ли сбор входных данных потоковым заданием в реальном времени или пакетным заданием? (ПРЕДЛОЖЕНИЕ: определите следующую воронку и частоту заданий соответственно)
Были ли предприняты какие-либо предварительные исследования данных для извлечения из данных некоторых идей? (РИСК! Возможно, 80 % данных о результатах поиска поступают только от 5 % пользователей, а остальные 20 % — от 95 % пользователей. → Предвзятое ранжирование в поиске.)
Были ли какие-либо предыдущие задания по очистке данных перед генерацией обучающих данных? (РИСК! Исключите из анализа все непреднамеренно полученные результаты поиска и кликбейты. ИЛИ Исключите из анализа уже удаленные элементы.)

Извлечение признаков/обучающие данные

Какие функции генерируются из записей данных и сколько их всего?
Какова была стратегия маркировки показателя релевантности? Как маркировать данные обучения? (РИСК!: Утечка ярлыка → Функции из каждого результата поиска должны быть извлечены до даты проведения конкретного поиска)
Как принять решение об использовании окончательного набора функций в производстве?
Новый подход к рассмотрению: добавление функций персонализации, если они не рассматриваются → более персонализированное ранжирование в поиске.
Новый подход к рассмотрению: используйте стратегию встраивания для создания функций вместо использования явных функций, настроенных вручную.

Обучение и оценка / Модели

Как формулируется часть моделирования? (например, двоичный, многоклассовый, регрессионный и т. д.)
Какой алгоритм машинного обучения использовался и почему он выбран?
Что такое функция оптимизации потерь?
Как проводится валидация модели? (например, перекрестная проверка или отдельные наборы обучающих/действительных/тестовых данных) → РИСК! Для таких задач, как поисковое ранжирование, важно разделить ваши данные на обучающие/действительные/тестовые в соответствии с их временными метками. Должно быть в таком порядке: Train → Valid → Test.
Как выбрать лучшую модель? На каких параметрах алгоритма выполняется настройка гиперпараметров поиска по сетке?
Как решить, какие функции являются наиболее важными на этапе моделирования? (ПРЕДЛОЖЕНИЕ: графики частичной зависимости повышают объяснимость моделей.)

Производственные вопросы

Сколько компонентов/работ работает в производстве?
Как часто выполняется задание по обучению?
Является ли эта учебная работа отдельной работой, такой как целый блокнот Jupyter Python, или серией более мелких заданий? (РИСК! Одиночное задание всегда более подвержено ошибкам и его трудно отслеживать в производственной среде.)
Как решить проблему холодного запуска? Какой-то особый поток для новых добавленных записей?
Где вы храните обучающие данные и модели, работающие в производственной среде?
Какова конечная точка API поиска?
Как провести A/B-тестирование этого продукта? Какой показатель использовался для оценки производительности?
Что вы отслеживаете в отношении всего этого трубопровода? (РИСК! Рекомендуется отслеживать все наборы данных, включая входные и все промежуточные наборы данных, чтобы обнаружить аномалию в данных.)

V. Проблемы и лучшие практики в процессе доставки продуктов для обработки и анализа данных

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

Основное отличие науки о данных от разработки программного обеспечения заключается в ее экспериментальном характере. Таким образом, обычные стандарты разработки программного обеспечения могут не всегда работать для групп, занимающихся наукой о данных. Это другая дисциплина, и с ней нужно обращаться деликатно. Внедрение модели машинного обучения в производство также имеет свои уникальные проблемы, отличные от других продуктов. Таким образом, при обсуждении общих проблем и лучших практик в науке о данных мне нужно разбить их на две основные части, чтобы вы могли легко понять и не отклоняться от курса. Я назову часть I как: Экспериментальная (Разработка) и часть II как Производство (Развертывание).

Часть I. Экспериментальная часть (разработка)

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

Методология Agile может использоваться в качестве основы для цикла разработки в проекте Data Science. Тем не менее, его необходимо настроить, чтобы он лучше соответствовал собственной природе науки о данных. Теперь давайте обсудим, какие принципы Agile хорошо работают в этой относительно новой области и какие другие принципы необходимо изменить.

Agile лучше всего проявляется, когда мы применяем его к быстро меняющимся циклам разработки и если требования проекта могут сильно меняться на протяжении всего цикла. Это также отчасти верно для науки о данных, что всегда есть возможность изменения требований. Это может произойти даже в конце проекта, если ожидания не были четко сформулированы в самом начале. Однако требования проекта по науке о данных относительно стабильны по сравнению с любым другим программным проектом. Это момент, когда нам нужно изменить принцип Agile для Data Science. В отличие от гибкого принципа о минимизации объема предварительного планирования и проектирования, подробная документация и предварительное планирование жизненно важны для проекта по науке о данных. В начале проекта нам нужно потратить достаточно времени, чтобы убедиться, что специалисты по данным и заинтересованные стороны бизнеса находятся на одной волне. Это потому, что разработка модели машинного обучения в значительной степени основана на этих первоначальных отзывах и деталях продукта, поступающих со стороны бизнеса. Другими словами, даже на разработку модели и технические решения будут влиять эти согласованные связи между бизнесом и командой по обработке и анализу данных в начале проекта. Это красота, но также и одна из самых больших проблем в мире науки о данных. Позвольте мне привести пример, чтобы сделать его более понятным для усвоения. Предположим, что мы хотим создать модель решения задачи прогнозирования мошенничества. Такая информация, как четкое определение мошенничества или то, что может быть признаком того, что пользователь является мошенником на платформе, должна поступать со стороны бизнеса. Это обсуждение, в котором также ожидается участие бизнеса, чтобы проложить путь для специалистов по данным.
Микроуправление, возможно, может быть худшим, что когда-либо случалось с командой специалистов по данным. Нелегко разбить проект по науке о данных на подзадачи, такие же маленькие, как в случае с разработкой программного обеспечения. Это невозможно из-за уникальной экспериментальной природы науки о данных.
Не нужно сильно давить, чтобы проводить ежедневные стендапы в командах по науке о данных. В противном случае вы можете услышать, как специалист по данным сообщает команде одно и то же в течение недели, например: «Я все еще работаю над оптимизацией параметров моей модели». Вместо этого для команды по науке о данных лучше проводить не более двух быстрых встреч в неделю.
Что касается вышеупомянутого экспериментального характера науки о данных, планирование задач или принцип Scrum Poker также должны по-другому применяться к команде по науке о данных. Вместо того, чтобы оценивать усилия, необходимые для каждой небольшой задачи, как в случае разработки программного обеспечения, следует заранее установить периоды времени для каждого этапа проекта. Сколько времени член команды должен инвестировать в конкретный этап проекта? Для этапа A проекта владелец проекта по анализу данных потратит максимум X дней и перейдет к этапу B, используя наилучший возможный результат в пределах временных рамок, установленных для этапа A. Вот забавный факт о науке о данных: специалист по данным может потратить даже целый год только на то, чтобы подумать о новых функциях, которые нужно добавить в модель, чтобы улучшить ее, или на настройку параметров алгоритма машинного обучения, чтобы в итоге выбрать лучший. Это предложение резюмирует эту «экспериментальную» сторону науки о данных и объясняет, почему мы называем ее «наукой».
Бэклоги также могут быть разработаны по-разному в проекте по науке о данных. Специалист по данным должен создать несколько резервных планов для каждого шага проекта в виде невыполненных задач. Эти незавершенные работы могут быть расставлены по приоритетам таким образом, чтобы в каком порядке были опробованы другие алгоритмы или функции машинного обучения, если в модели потребуется какое-либо дальнейшее улучшение. Например, если текущий набор функций не дает желаемого результата, то следующее, что нужно сделать, — это использовать другой источник данных для расширения набора функций. Эти незавершенные задачи должны быть специфичны для проекта или владельца. В отличие от обратного случая в программной инженерии, ожидающая задача невыполненной работы не может быть назначена ни одному специалисту по данным в команде. Это потому, что большую часть времени проект возглавляет только один специалист по данным. Это еще одно важное различие между циклами разработки программного обеспечения и науки о данных, о котором стоит упомянуть.
Принцип Agile, предполагающий личные встречи и постоянное информирование заинтересованных сторон во время разработки проекта, также хорошо согласуется с наукой о данных. Тем не менее, «меньше совещаний, больше документации» будет лучшей стратегией для повышения производительности в команде. Достаточно провести 2 стендапа и 1 внутреннюю встречу команды в неделю. Кроме того, глава отдела обработки данных и менеджер проекта должны проводить периодические личные встречи с представителями бизнеса на протяжении всего проекта по двум основным причинам: во-первых, информировать бизнес о текущем статусе проекта. Во-вторых, что более важно, убедитесь, что бизнес делает то, что от него ожидается, до выпуска продукта, например, придумывает более конкретные варианты использования для конечного продукта. Например, если команда разрабатывает прогностическую модель для более персонализированного таргетинга на пользователей с помощью маркетинга по электронной почте, бизнес должен разработать и доработать шаблоны электронной почты, которые будут использоваться после того, как модель будет готова. Поэтому крайне важно использовать политику встреч лицом к лицу Agile для науки о данных.
Для команды по науке о данных спринты, как правило, занимают больше времени, чем для команды разработчиков программного обеспечения. Эффективнее планировать спринты до 1 месяца, чем на неделю или две недели. Конечно, всегда полезно проводить ретроспективные встречи после каждого спринта, чтобы увидеть, хорошо ли работает команда и не отстает ли от графика или сроков проекта.

Часть II. Производство (развертывание)

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

Давайте начнем с перечисления самых больших проблем, с которыми сталкивается команда специалистов по обработке и анализу данных во время развертывания продукта. Существует уровень науки о данных, в котором есть все инструменты, фреймворки, IDE или языки программирования, используемые командой. Существует также уровень рабочей среды, в котором находится озеро данных и выполняются приложения. Однако неправильная связь между этими двумя уровнями создает много проблем для команд, и этот разрыв между специалистами по данным и производственной средой необходимо заполнить, чтобы повысить эффективность команды специалистов по данным. Вот где MLOps вступает в игру.

MLOps появились как средство от следующих проблем:

После передачи новой обученной модели инженеру данных для внедрения ее в производственную среду специалисты по данным больше не имеют жесткого контроля над своими собственными моделями. Даже если простое изменение модели занимает слишком много времени. Специалисты по обработке и анализу данных должны как можно скорее увидеть влияние своих последних изменений на модель. Это то, что мы называем «Непрерывное развитие/эксперимент».
Каждой команде необходимо использовать «репозиторий кода», такой как Github, для хранения всех реализаций проектов. Эти коды должны соответствовать некоторым стандартам или соответствовать манифесту реализации команды, который заранее определен главой отдела обработки данных и ведущим специалистом по данным. Мы обсудим это подробно в следующем разделе.
Версионность модели играет здесь решающую роль. Было бы здорово увидеть историю модели проекта или эксперименты по отслеживанию, которые были проведены ранее, чтобы в итоге получить лучшую окончательную модель. Например, специалист по данным, вероятно, будет пробовать разные наборы функций, разные модели машинного обучения и разные комбинации параметров для каждой из моделей. Это огромное количество испытаний и требует логики управления версиями. В конце рабочие модели-кандидаты регистрируются в центральном «репозитории моделей».
В большинстве случаев проекты по науке о данных будут иметь общие характеристики и вдохновляться друг другом. Они могут даже использовать один и тот же набор функций, но эволюционировать в разные решения, имея разные сопоставления между функциями и целями. Например, модель оттока и модель мошенничества имеют много общего по своей природе. Они могут использовать аналогичные пользовательские функции, чтобы предсказать, будет ли пользователь уходить или будет угрозой мошенничества. Здесь вступает в игру важность наличия центрального «репозитория функций». У команды должно быть хранилище функций, в котором находятся некоторые промежуточные наборы данных и хранятся некоторые точки данных высокого уровня. Это значительно улучшит взаимодействие внутри команды.
«Непрерывный поток обучения» — одна из основных частей потока проекта по науке о данных. Это означает, что задания для обучающих моделей должны выполняться автоматически, многократно и непрерывно. Это может быть выполнено с помощью периодическихзапланированных заданий обучения, выполняемых ежедневно/еженедельно, или инициироваться некоторыми другими факторами, например каждый раз, когда доступны новые данные обучения. Этот поток выведет новые обученные модели и сохранит их в центральном репозитории моделей, где хранятся все запущенные модели в производстве.
Использование обученной модели для создания прогнозов в производственной среде требует «непрерывного потока прогнозов». Эти прогнозы должны генерироваться и обслуживаться в режиме реального времени с помощью запланированных заданий по прогнозированию. Этот поток будет выводить новые прогнозы, наполняя модели самыми свежими и актуальными данными, и сохранять результат в хранилище данных, которое служит для производства.
Лично я считаю средство мониторинга MLOps наиболее важным среди всех остальных. После запуска модели в производство жизненно важно постоянно отслеживать данные и моделировать, чтобы выявлять проблемы и быстро их решать. В необработанных или промежуточных наборах данных может быть некоторый перекос данных по всему конвейеру из-за проблемы, возникающей при сборе данных или задании, создающем эти промежуточные наборы данных. Некоторые статистические данные, такие как среднее, максимальное, минимальное или процентильное распределение столбца, должны быть согласованными в безошибочной производственной среде. Если в какой-то точке данных произойдет внезапный всплеск или изменение, это повлияет на все последующие компоненты и вызовет проблемы в окончательной таблице результатов обслуживания. Поэтому требуется сразу увидеть, уловить и решить эти проблемы. Здесь происходит «мониторинг данных». Например, если конвейер вашего проекта начинается с данных уровня кликов и возникает проблема в задании сбора потоковых данных, это, вероятно, повлияет на весь конвейер данных до конца. Большую часть времени эти потоковые задания по сбору данных управляются другими командами, но специалист по данным может, по крайней мере, отслеживать статистику данных и сравнивать ее с ранее сгенерированной, чтобы решить, что с данными что-то пойдет не так. Это можно сделать и для наборов данных промежуточного уровня. Отслеживайте их и смотрите, есть ли что-то неправильное в задании, которое создало этот набор данных промежуточного уровня. Например, если у вас есть задача преобразовать данные об уровне попадания в агрегированные данные на уровне пользователя, рекомендуется также выполнить проверку работоспособности данных на уровне пользователя. Другим примером этого может быть преобразование этих данных пользовательского уровня в функции обучающих данных высокого уровня. Этот набор функций необходимо постоянно контролировать, чтобы специалист по данным знал, правильно ли работает задание по созданию обучающих данных.
Мониторинг также необходим, чтобы показать производительность модели и внезапные изменения показателей модели. Это называется «мониторинг модели». Это даст вам некоторые подсказки о вменяемости модели и работы по моделированию.
Точно так же нам нужен «мониторинг прогнозов», чтобы знать, происходит ли какой-либо внезапный перекос в распределении окончательных прогнозов, чтобы предотвратить проблемы в работе прогнозирования.

VI. Манифест внедрения науки о данных: как спроектировать различные подкомпоненты конвейера реализации

Для большинства специалистов по данным обычной практикой является записывать все коды в один блокнот и работать с ним до конца. Я не думаю, что это удобный и эффективный способ реализации проекта моделирования машинного обучения. Работа с блокнотом может быть полезна только в том случае, если вы продолжаете исследовать данные и пытаетесь получить первоначальные результаты работы с доказательством концепции (POC). Однако вам придется использовать более организованную и пошаговую методологию при реализации, прежде чем переходить к производственной интеграции. Каждому члену группы по науке о данных необходимо предложить следовать заранее установленным рекомендациям по написанию кода о том, как разрабатывать этапы реализации внутреннего командного проекта.

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

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

Это уменьшит сложность всего конвейера. В большинстве случаев, если у вас есть настоящие большие данные, запуск всего в одном задании невозможен. Масштабирование этих инфраструктур также невозможно. Поэтому вы всегда должны искать возможность разделить поток на достаточное количество более мелких заданий.
Это сделает конвейер более управляемым, так что любое изменение в конкретном компоненте вступит в силу быстрее. Благодаря пошаговому конвейеру реализации теперь у вас есть общая картина всех подкомпонентов и вы знаете, как одно обновление на определенном этапе влияет на следующие шаги. Это позволяет автоматизировать этот процесс обновления как цепочку событий и не запускать все заново с нуля.
Это позволит нам хранить промежуточные наборы данных. Каждое задание выводит набор данных, чтобы передать его в качестве входных данных для следующего этапа конвейера. Если мы сохраним эти наборы данных где-нибудь, это улучшит сотрудничество в команде. Например, если у вас есть подкомпонент только для преобразования данных на уровне обращений в агрегированные данные на уровне пользователя, какой-то другой член команды может использовать эти данные на уровне пользователя для своего собственного проекта.
Будет легче поймать и исправить производственную ошибку. Вы легко определите точный проблемный компонент или задание, а затем непосредственно займетесь этой конкретной частью конвейера.
Это также упростит мониторинг и сделает его более управляемым. Вы можете проверить работоспособность своих промежуточных наборов данных и моделей, сравнив ранее сгенерированный с вновь сгенерированным. Эти задания мониторинга должны сохранять эти файлы журналов сравнения где-то в вашей системе. Затем вы даже можете создать свою собственную панель мониторинга, просто представив эти файлы журналов в виде причудливых графиков.

На приведенной ниже диаграмме я покажу вам высокоуровневый поток общих компонентов в производственном конвейере науки о данных.

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

Рекомендации для групп по науке о данных