Почему пилот – основа «нормального» полёта проекта по разметке данных для решения ML-задач?

На сегодняшний момент рынок сбора и разметки данных находится в стадии устойчивого роста. Согласно отчету Research and Markets от 22 августа 2022 года [1]: 2,13 млрд долларов США в 2022 году (12,75 млрд долларов США к 2030 году). Данная тенденция обуславливается не только интенсификацией внедрения ML-алгоритмов как агентов увеличения эффективности осуществляемой деятельности в рамках различных сфер экономики, но и их количественным ростом. К примеру, импульсивным скачком развития датамаркета стал пандемийный период, что привело к общемировому росту капиталовложений в AI и ML для оперативной и качественной реализации средств детекции заболевания, сопутствующих заболеваний, а также разработки вакцины. В целом, COVID-19 оказал кумулятивный эффект по отношению к рынку искусственного интеллекта в области медицины и закономерно повлиял на все придаточные, включая датамаркет.

Опираясь на то, что «нейросетевые решения» – это модно и эффективно, необходимо адекватно оценивать, что из себя представляют те самые «данные», посредством которых осуществляется их обучения. Также необходимо понимать, «как» эти данные можно было бы получить.
Представим, что Вы – компания, которая предполагает интеграцию ML-алгоритмов в структуру деятельности, или Вы разрабатываете продукт, где необходимо их участие. Для их реализации Вы вынуждены располагать уникальным набором данных (датасетом), который непосредственно задействован в обучении. Где его взять? Есть три варианта развития событий:

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

Краудсорс-решения. Из названия понятно, что для реализации задач сбора и разметки данных, Вы привлекаете третьих лиц. Таким образом, компания интенсифицирует ресурсы в содержание высококвалифицированных специалистов по работе с готовым датасетом, при этом делегируя процессы его подготовки на соответствующие платформы. Что за платформы такие? Не нужно расклеивать в лифтах объявления о сборе и разметке данных, достаточно просто посетить соответствующие ресурсы и разместить задачку в качестве работодателя. Преимуществ такого подхода довольно много. Во-первых, это намного дешевле для компании нежели вышеописанный подход. Крауд-платформы наращивают свои обороты с колоссальной скоростью, что приводит к закономерному снижению ценовых показателей услуг разметки третьими лицами, а это, в свою очередь, приятно сказывается на бюджете создания датасета. Также следует отметить оперативность крауда как подхода в целом. Вы как компания, в теории, можете трудоустроить сотню-другую сотрудников, но экономическая целесообразность этого действия для конкретного проекта оставляет вопросы. Делегирование третьим лицам предполагает, что вашей задачей будут заниматься фрилансеры 24/7 из любой части мира. Это отлично с точки зрения сроков реализации готового результата, но, конечно, есть и существенные минусы. Качество… Да, это безоговорочный недостаток. Дело не в том, что 100% результатов будет неприменимыми для реализации. Просто надо предполагать, что не все фрилансеры выполняют свою работу с должной ответственностью и вовлеченностью в процесс, что является автоматическим атрибутом «внутренней» подготовки датасета. Может дело в цене за единицу данных, может техническое задание с Вашей стороны как заказчика составлено не совсем корректно, а может попался такой человек. В любом случае, требуемое качество формирует необходимость в дополнительных валидационных ресурсах.

Если кому-то будет интересно, приведу пару ссылок на популярные крауд-платформы (не реклама):
https://www.mturk.com/
https://www.clickworker.com/
и т.д.

Аутсорс-решения. Данный подход похож на предшествующий, но предполагает привлечение «конкретных» лиц к проекту. По сути, аутсорсером является фрилансер, который как подрядчик-профессионал выполняет поставленную задачу по созданию датасета. Преимущества паритетно перетекают из крауда, дополняясь более высокими показателями качества результата. Однако закономерным недостатком станет необходимость в привлечении большего объема материальных ресурсов для реализации результата в требуемый срок с требуемым качеством. При этом необходимо грамотно оценивать компетенции привлекаемого лица, доходчиво формировать техническое задание и быть в «постоянном контакте», тем самым отслеживать стадии реализации задачи по созданию датасета. В рамках данного подхода абсолютными доминантами с точки зрения качества и своевременности результата выступают аутсорс-компании. Вы вверяете свою задачу «под ключ» авторитетному участнику рынка сбора и разметки данных, и, фактически, снимаете всю головную боль со своей стороны. Преимущества уже описал выше, но в качестве недостатка следует отметить, что это более дорогие решения.
Платформы для привлечения «конкретных» фрилансеров, думаю, всем известны (апворки всякие). Примеры аутсорс-компаний могу привести, но сочтёте за рекламу. Рамблерите сами: «Разметка данных…» ????
После описания основополагающих процессов, не отвлекаясь на такие технические особенности реализации создания датасета, как синтетика, автоматическая разметка и другие, я бы хотел затронуть один из менее очевидных, но крайне важных этапов – пилотирование проекта. Вне зависимости от принятой формы реализации.
Тематика статьи в большей степени затрагивает тонкие процессы менеджмента проектов по сбору и разметке данных. Начальная часть лишь характеризует современные реалии в данном направлении.

Тематика статьи в большей степени затрагивает тонкие процессы менеджмента проектов по сбору и разметке данных. Начальная часть лишь характеризует современные реалии в данном направлении.
В основе любой проектной деятельности лежит базовая взаимосвязь сгруппированных процессов «ИПРЗ» (см. рисунок 1) [2].

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

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

1. Когда завершается проект?

Датирование ключевых этапов, включая финальный, регламентировано из предшествующих процессов инициации, а именно из концептуального и ресурсного определения в соответствии с результатами целеполагания.
2. Что требует реализация проекта?
Предполагает собой привязку экономических затрат к этапам проекта как движителя прогресса, включая техническое и ресурсное обоснование.
3. Как оценить результаты проекта?
Строится из идентификации требуемого результата на этапе проработки концепции. Ожидаемый результат приравнивается к качественному, а по завершении производится сверка с установлением меры отклонений.
4. Как осуществить переход от начального к конечному состоянию проекта?
Предусматривает декомпозицию списка требований на список конкретных задач с распределением на компетентном и приоритетном уровнях.

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

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

Теперь хотелось бы более подробно акцентировать внимание на процессах реализации. Для удобства восприятия проецируем этап на «Проект по разметке котят на фотографиях». Моделируем, что со стороны заказчика был представлен регламентируемый перечень условий выполнения разметки, освещаются технические моменты исполнения, а также представлен датасет первичных данных – набор фотографий различного содержания, которые содержат искомые объекты (котяток) в рамках изображений.

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

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

Перед переходом к процессу запуска менеджер собственноручно осваивает принципы разметки в пределах небольшого объема представленного датасета, что и является «пилотом» проекта. И вот, первый момент, который входит в рассогласование – считаем ли мы изображение котенка внутри изображения с котенком в рамках данной задачи объектом, подлежащим разметке. Так как предполагается реализация ML-алгоритма, необходимо очень доходчиво видеть и представлять цель реализации, которой основной заказчик крайне редко делится по конфиденциальным соображениям. Если у подрядчика отсутствует представление о целеполагании в рамках первичной документации, подобный момент должен освещаться отдельно в техническом задании. Предположим, что подлежат разметке только физические котята, представленные на изображении, согласно принципам целеполагания. Моделируем работу проектной команды без пилотирования – размечены все котята на изображениях, включая тех, которые находятся во внутреннем составе (на билбордах). Итоги работы – споры… Технически работа была выполнена в прямом соответствии с установленными требованиями, однако заказчиком закладывался иной смысл. Результат таких споров в 95% случаев – доработка результатов, в остатке – поиск нового подрядчика для доработки. Оба исхода плохо отражаются на процессах планирования как заказчика, так и подрядчика. Что позволяет сделать пилотирование в такой ситуации? Пилот позволяет предохранить проект от возможного рассогласования результатов. Именно на основе результатов пилота техническая документация дорабатывается до состояния соответствия концептуальных решений и ожидаемого результата.

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

Таким образом, можем рассмотреть ключевые факторы проектов с пилотированием и без него.
Проект «без пилота»:

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

Проект «с пилотом»:

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

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