Меня зовут Вера Романцова, я работаю в 2ГИС в команде компьютерного зрения. Мы создаём ML-модели и сервисы, которые автоматизируют работу с картами и данными. 

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

В этой статье я расскажу:

1. Кто такой менеджер данных и чем он занимается.

2. Как эта роль помогла нашей команде ML-инженеров.

3. Когда такой специалист может понадобиться вам.

4. Как найти подходящего кандидата на эту позицию.

Работа с данными в ML-команде: как было раньше

Любая задача машинного обучения строится на трёх китах:

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

2. Продумать архитектуру модели и разработать её. 

3. Создать сервис, чтобы внедрить модель в продакшн.

И раньше для каждой своей задачи ML-инженер должен был сделать все этапы сам: 

• продумать архитектуру модели,

• написать инструкцию (или инструкции) для разметки, отдать в разметку данные и оценить качество разметки,

• сделать сервис для готовых моделей.

ML-инженеры отлично справлялись с решениями касательно архитектуры сетки, без проблем делали сервис, но всё-таки часть работ вызывала определённые трудности. Всё дело в том, что написание инструкций для исполнителей, планирование бюджета, а также контроль качества данных — это организационная работа, требующая иных навыков. Более того, процесс сбора датасетов — это объёмный процесс, на который инженеры тратили порой до 80% времени от объёма всей задачи, и это мешало им сосредоточиться на том, чтобы качественно сделать модель и сервис. Так происходит, потому что в данных очень много краевых случаев и в них можно так погрузиться, что до модели в нужные сроки добраться ML-инженер просто не успевает. 

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

• взаимодействовать с заказчиками,

• координировать работу исполнителей,

• управлять бюджетами,

• контролировать качество разметки,

• оптимизировать и автоматизировать работу команды процессов.

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

Роль менеджера данных

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

Взаимодействие с заказчиком

Всё начинается с работы с заказчиком. И включает в себя этапы, начиная от постановки требований и заканчивая процессом приёмки готовой фичи:

• проработка требований и уточнение нюансов и тонкостей проекта;

• проработка альтернативных решений;

• организация регулярного процесса получения обратной связи.

Согласование деталей с ML-инженером

Тесное взаимодействие с ML-инженером важно как на начальных этапах, так и в процессе работы над датасетом. На старте необходимо:

• определить предполагаемую  архитектуру модели;

• оценить объём данных для начального этапа.

К ML-инженеру я также постоянно обращаюсь и в процессе работы над датасетом: 

• на этапе ресёча данных уточняю, какие кейсы можно покрыть с помощью модели;

• обращаюсь за помощью, когда хочу оптимизировать или масштабировать процесс разметки. 

Планирование бюджета

Собрав данные от ML-инженера, менеджер по данным оценивает стоимость датасета и планирует бюджет, чтобы в нужный момент у нас были необходимые ресурсы. И теперь таких случаев как: «Мы хотели разметиться на крауд-платформе, а деньги будут только через неделю» у нас нет.

Организация разметки и работа с исполнителями

Дальше я организую процесс разметки, который может выполняться различными исполнителями:

• крауд-платформами;

• аутсорсингом;

• внутренними ресурсами компании.

Мы работаем со всеми видами разметки, и моя задача — выбрать оптимальный способ разметки для конкретной задачи: 

• Чувствительные данные нужно размечать только с помощью аутсорсинга или внутренних ресурсов. 

• А объёмные и простые с точки зрения постановки задачи можно отдавать на краудсорсинг, где разметка идёт быстро и легко масштабируется. 

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

Контроль качества

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

• готовлю контрольные примеры, чтобы контролировать качество разметки,

• слежу за качеством,

• дорабатываю датасет на тех кейсах, где модель даёт сбои.

Зона ответственности менеджера данных

Для более ясного представления того, какие шаги мне, как менеджеру данных, необходимо учитывать при сборе любого датасета (даже простой классификации), я выделила основные моменты в виде чек-листа:

• уточнить требования у заказчика;

• сделать pipeline и поделить на подзадачи, так как классов много и требования класса достаточно объёмные (результат этого этапа — дерево разметки);

• составить инструкцию для каждого этапа, понятную для исполнителей;

• подготовить контрольные примеры;

• создать проект для разметки;

• следить за выполнением задач, например, через тестовые запуски;

• следить за бюджетом и скоростью разметки;

• внести корректировки в процесс, если разметка тестового запуска не устроила;

• ответить на вопросы разметчиков;

• добрать данные, где модель ошибается;

• автоматизировать разметку.

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

Пример бизнес-задачи: разметка фото ресторанов

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

• внутри,

• снаружи,

• меню,

• атмосфера,

• еда и напитки. 

Вроде всё понятно — обычная задача классификации, однако на практике возникло множество нюансов.

Формирование команды

На планировании мы выбрали, кто будет решать эту задачу со стороны датасетов и со стороны ML. Это рабочая команда, ответственная за результат и над задачей будет работать вместе.

Первичный анализ и уточнения

Для начала я смотрела на неразмеченные данные и пыталась поставить себя на место разметчика, куда бы он отнёс тот или иной класс. На этом этапе, как правило, у меня появляется ворох вопросов в стиле: «А это куда?» или «А что, если?» Это потенциальные кейсы, которые будут вызывать вопросы и у разметчиков в будущем. Моя задача — узнать, что ожидает увидеть заказчик в них. Поэтому я сразу шла к продакт-менеджеру и задавала эти вопросы ему.

Например, мне было непонятно, что ожидает увидеть заказчик в классе «Атмосфера». 

• Групповое фото людей, где люди смотрят в камеру, или танцующие люди, которые вообще не смотрят в камеру? 

• Очереди — это тоже атмосфера? 

• А собачка, которая смотрит на фото, ну и рядом тоже еда крупным планом — это тоже атмосфера или не атмосфера? 

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

А если возникало подозрение, что фото должны быть в разных классах, но модель может не выучить такие примеры, то я уточняла у ML-инженера, можем ли одно отличить от другого. 

Написание инструкции и подготовка контрольных примеров

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

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

У некоторых читателей может возникнуть вопрос, а зачем так углубляться в разметку, когда можно сразу сделать задание «на коленке»? Приведу несколько примеров, как могли бы разметить исполнители без качественной инструкции.

Пример 1 

Как модель будет колбасить на таких разных ответах – можно и не объяснять. Поэтому в инструкции нужно подсвечивать такие ситуации или даже разбивать на несколько этапов, чтобы задание не было слишком сложным для исполнителя. 

Пример 2

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

Пример 3

Глядя на варианты ответов исполнителей, мы призадумались, хотим ли вообще видеть такое в «еде».

Пример 4

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

Предложение альтернативных решений 

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

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

Формирование pipeline

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

Подготовка контрольных примеров 

Казалось бы все круто: проработала все кейсы и написала инструкцию. Но теперь наступает самый ответственный момент: нужно, чтобы сложные кейсы запомнили и исполнители.  

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

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

Автоматизация разметки

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

Чуть выше я показывала пример реального дерева разметки, и если вы хотите сделать процесс максимально прозрачным и масштабируемым, то нужно автоматизировать процессы запуска и получения результатов. Например, на Яндекс-Заданиях (или ЯТолоке) есть специальные библиотеки, и я оптимизирую время, автоматизируя эти процессы.

Инструментарий менеджера данных

В управлении процессами можно еще многие другие задачи автоматизировать, поэтому я использую следующие инструменты:

1. ClearML — для проверки эффективности модели в процессе работы. Позволяет добавлять данные, тренировать модель и анализировать метрики.

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

3. Segment Anything в CVAT — для задач сегментации и детекции, а также для подготовки инструкций и примеров. Повышает скорость разметки.

4. Визуализация результатов на стейджинге.

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

Когда нужен менеджер данных

Возникает вполне резонный вопрос, а всегда ли нужен менеджер по данным? 

Я рекомендую выделить отдельную роль менеджера по данным, если 

• много задач по разметке;

• данные поступают итеративно;

• ML-инженер тратит много времени на задачи по данным;

• хочется превратить разметку в процесс, и чтобы он был прозрачным и масштабируемым;

• нужно следить за высоким качеством разметки и хочется непрерывно его повышать;

Как выбрать подходящего кандидата

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

1. Знание Python. Ищите человека, который знает Python хотя бы на уровне написания скриптов. Умеет пользоваться такими библиотеками, как pandas, numpy, matplotlib, opencv. Знает метрики на уровне понимания разницы между Precision и Recall. 

2. Управленческий опыт снизит административную нагрузку, так как такие специалисты легче взаимодействуют со стейкхолдерами и выстраивают процессы. 

3. Опыт работы на крауд-платформах, таких как Толока/Яндекс Задания. 

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

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

6. Любовь к данным. Ищите человека, который любит работать с данными, а не только с моделями. 

В процессе найма нужно быть готовым к сложностям, например: 

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

• На рынке практически нет специалистов на такие роли, поэтому ищите по навыкам, которые описали выше. Как правило, для таких специалистов нет общепринятого названия должности, это может быть data quality analyst, crowd solutions architect или просто менеджер по данным. 

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

Итоги и выгоды от такого подхода

Появление менеджера по данным в 2ГИС помогло нам улучшить качество разметки, ускорить процессы и разгрузить ML-инженеров. Теперь:

• ML-инженер не отвлекается на задачи по данным, его задачи теперь более очерчены.

• Задачи на разметку более простые и понятные.

• Разметка итеративна, прозрачна и масштабируема.

• ML-инженер не занимается административными вопросами.

• Ускорили вывод моделей в продакшн.

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

Эта новая роль оказалась полезной в нашей команде, и, возможно, станет полезной в вашей. 

Если захотите работать в 2ГИС, то пока открыты вакансии Data Scientist, но могут появится ещё. Смотреть всё можно здесь.