Мы в Statzilla занимаемся анализом данных, и зачастую самая большая часть проекта — это сбор этих самых данных и их разметка. В большинстве случаев на этом этапе не обойтись без ручного труда: если сбор данных еще можно автоматизировать, то разметку и обогащение автоматизировать сложнее, а часто и дороже, чем отдать эту работу операторам. Расскажем как нам удалось оптимизировать этот процесс.
Разметка и обогащение данных - это когда каждой единице информации мы либо добавляем недостающий кусок (например, “в скольких фильмах играл этот актер?”), либо как-то ее характеризуем (“голос на аудиозаписи женский или мужской?”). По сути каждый из нас немного занимается разметкой данных, отвечая на вопросы captcha про светофоры и мосты на картинках Google.
Есть целые агрегаторы таких задач (Яндекс.Толока). Нам разметка данных в большинстве случаев нужна для того, чтобы мы могли строить модели прогноза на основе размеченных данных, где в качестве правильного ответа - ответ от человека-оператора. А потом наш алгоритм, научившись на человеческой разметке, сможет решать такие вопросы самостоятельно.
В зависимости от масштаба проекта, на ручную обработку данных подбираются команды операторов от 4 до 50 человек, обрабатывать приходится сотни тысяч строк. И на этом фоне остро встают вопросы менеджмента этого процесса, в котором мы выделяем 3 этапа:
- рекрутинг (подбор и инструктаж команды операторов)
- проверка качества работы
- справедливая оплата проделанной работы
Изначально во всех этих этапах роль менеджера проекта была очень высока, особенно на этапе проверки качества. Очевидно, что проверять задание, выполняемое вручную, может только другой человек :) но также очевидно, что бессмысленно делать двойную работу и перепроверять вручную все сделанные строки. Можно периодически брать выборки из данных и проверять качество работы на них. Собственно, так мы и делали поначалу. Но при таком подходе не хватает системности и, коль скоро мы анализируем данные, за пару десятков проектов мы изобрели и внедрили следующую автоматизацию процессов.
Рекрутинг
У нас есть регулярный костяк команды операторов, но для некоторых проектов мы набираем людей дополнительно (например, если сбор данных нужно осуществлять в других регионах или для большей скорости нужно распараллелить процесс).
Под каждую задачу выдаем кандидату (и “старому”, и “новому”) инструкцию и тестовое задание на 10-30 строк в Google sheets, которое он должен выполнить до того, как будет запущен “в поля”. В проверочном файле часть этих строк выполнена нашим менеджером-экспертом, а вторая часть - другим оператором.
По результатам выполненного теста автоматически проверяется пересечение ответов оператора 1 с правильными ответами от эксперта и другого оператора 2. Причем, если оператор 1 успешно прошел проверку эксперта (его ответы совпали с ответами эксперта на 95%+), то считаем, что он проверил работу оператора 2. Таким образом, каждый кандидат на проект проходит перекрестную оценку с другим оператором и сравнение с экспертом.
По итогам этих оценок с кандидатом связывается менеджер, и он либо приглашается на текущий проект, либо нет.
Профит:
менеджер тратит время только на тех людей, которые прошли тест. В процессе перекрестной проверки убиваем двух зайцев: отбираем подходящих кандидатов и выполняем строки задания.
Проверка качества работы
В каждом проекте мы вводим некий показатель эффективности работы, который релевантен в данном случае (например, если наша задача - обогатить данные компаний их ИНН, наш показатель эффективности - % нахождения ИНН от числа просмотренных сайтов). Результативность менеджера операторов - нашего эксперта - мы принимаем за стартовый эталон (например, он находит ИНН в 70% случаев). По мере выполнения задания мы собираем статистику по каждому оператору в режиме реального времени и вычисляем наш KPI.
Чтобы отслеживать перфоманс команды в динамике, мы построили дэшборд в Google Data Studio, в котором собираются:
- показатель эффективности каждого оператора,
- средний показатель эффективности,
- медиана показателя эффективности,
- показатель эффективности эксперта.
- скорость, с которой происходит обработка строк
Причем разбивка идет с агрегацией по количеству обработанных им строк, например каждые 50 строк, что позволяет нам отслеживать в динамике работу оператора (см. рис).
Дальше возможны разные сценарии = сигнальные ситуации:
- KPI оператора или среднее время на выполнение строк хуже эталона, но сопоставимы со средним значением по другим операторам: стоит убедиться, что все операторы хорошо поняли задание и инструкцию по его выполнению, возможно, нам стоит ее детализировать.
- KPI оператора ниже не только эталона, но и среднего по операторам: вероятно, оператор недопонял инструкцию или выполняет задачу некачественно. Стоит провести с ним отдельную работу.
- KPI оператора выше эталона/среднего по операторам: возможно также неправильное выполнение задания. В нашем примере с поиском ИНН такие случаи бывали, когда оператор искал инн по названию компании и, естественно, почти всегда находил несколько вариантов (так как названия юр. лиц не уникальны), поэтому его процент нахождения был выше, чем реалистичный.
- Время на выполнение уменьшилось по сравнению с прошлыми показателями оператора: в большинстве случаев означает, что человек стал работать на количество, а не на качество. Если после дополнительной проверки это подтверждается и становится систематическим, то оператор прекращает работу.
Помимо обработки сигнальных ситуаций мы устраиваем периодические перекрестные проверки стабильности качества по операторам:
- каждые 1000 строк
или
- если метрики показали значительную динамику (рост или падение)
Тогда оператору 1 автоматически выдается порция обработанных строк другого оператора 2, показатель которых значительно выбивается от среднего качества оператора 2.
Профит:
За счет пересекающихся проверок все данные помечаются с точки зрения достоверности этой разметки. И можно перепроверять только те данные, в которых отсутствует достаточный уровень уверенности.
Так как проверка основана на сопоставлении одних и тех же строк, выполненных разными людьми, мы отслеживаем статистически значимое отклонение качества (прим. для любителей статистики: с помощью сравнения независимых выборок), а также статистически значимую динамику качества (с помощью сравнения зависимых выборок). Это нивелирует тот факт, что в разных кусках данных показатель эффективности может различаться по объективным причинам (в нашем примере с ИНН в начале файла находятся крупные компании, а ближе к концу - микропредприниматели, многие из которых работают без юр лица/ИП, и найти их реквизиты почти невозможно).
Оплата проделанной работы
За несколько лет мы много экспериментировали: вводили систему штрафов за ошибки, оплату только проверенных строк, доп проверки перед оплатой, но в конце концов пришли к выводу, что оптимальный путь - оплата за всю проделанную работу, а уже на нашей стороне стоит ответственность построить такую систему, чтобы эта работа была полезной. Поэтому в каждой задаче человек просто получает заранее озвученную сумму денег за сделанную строку. Причем все, что мы показали выше, увеличивает объем работы на 12-15%, т.е всего 12 строк из 100 будут дополнительно и перекрестно проверены, но при этом в результате точность собранных данных совпадает с экспертом более чем на 92%.
Профит:
Мы платим за работу, выполненную качественно, с наценкой за проверку в 12-15%, которая существенно ниже, чем была при ручной проверке до внедрения системы. Оператор видит прозрачность системы, мотивирован поддерживать высокое качество работы и чувствует, что оплата справедлива. В итоге все счастливы.
Бонусом после того, как человек закончил работу, его метрики позволяют менеджеру определить, насколько он хорош для выполнения такого типа задач по сравнению с остальными операторами.
Итого:
В задаче ручной обработки данных мы пытались максимально автоматизировать процесс. Естественно, мы не исключили ручную проверку выборок проделанной работы, но делаем ее теперь более осмысленно. Отслеживая динамику KPI, мы получили четверной эффект:
Во-первых, мы с самого начала предотвращаем неправильное выполнения задания (убедились, что все одинаково поняли инструктаж) и можем откорректировать работу отдельных людей до того, как они сделают большой объем работы с ошибками.
Во-вторых, мы отслеживаем изменения качества: был ли эффективен наш дополнительный инструктаж (сравниваем качество операторов отдельно и среднее качество до инструктажа и после).
В-третьих, мы нивелируем снижение качества от усталости: даже у самого внимательного оператора к концу рабочего дня может снижаться качество работы - тогда мы можем уделить проверке этого куска больше внимания нашего менеджера или попросить самого оператора вернуться к этой работе позже.
В-четвертых, мы экономим ресурс менеджера, направляя его энергию в первую очередь на работу с теми кандидатами, которые уже прошли проверку и принесли профит, проверив других операторов. А для проверки менеджер привлекается только в тех участках, где KPI вызывает вопросы. Кажется, что такой подход можно применять и для менеджмента в других областях: отдел продаж, колл-центр, промоутеры, тестировщики (?)
Если у вас был похожий опыт или есть идеи на этот счет, будем рады обсудить в комментах!
#машинноеобучение #анализданных #автоматизациябизнеса