Меня зовут Александра Царева. Я и мои коллеги работаем над проектами в сфере компьютерного зрения в Центре машинного обучения компании «Инфосистемы Джет». Мне хочется поделиться нашим опытом разработки и внедрения проектов в сфере компьютерного зрения.

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

Сразу оговорю два важных пункта:

1. Эти шаги касаются практически любого датасайнс-проекта. Но некоторые моменты вызваны эффектом хайпа вокруг CV, некоторой славой «серебряной пули» у компьютерного зрения и желанием заказчика, «чтоб было с нейросетью».
2. Я говорю о том, что эти шаги в первую очередь проходит сам датасайнтист, но некоторые из них хочется делегировать — менеджеру проекта, бизнес-аналитику или иному коллеге. С моей точки зрения, стоит исходить из предпосылки, что этого коллеги или нет (маленькая компания, другая структура работы и т.п.) или он в любом случае не знает так хорошо ограничения машинного обучения и нейросетей, как профильный специалист — то есть нуждается в консультации и совместном разборе каких-то вопросов.

Шаг первый: а правда ли нужно компьютерное зрение для решения задачи?

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

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

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

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

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

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

Шаг второй: как будем решать CV-задачу и оценивать успешность решения?

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

Есть ли известные решения, нейросети, которые могут решать такую задачу? Может быть, даже коробочный продукт? Если задача новая — может быть, есть публикации, на которые мы сможем опереться и предварительно оценить достижимое качество?

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

Работа с данными иногда начинается одновременно с согласованием решения и метрик, но для удобства выделим ее в отдельный шаг.

Шаг третий: изучаем и понимаем наши данные

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

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

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

Шаг четвертый: разрабатываем модель-прототип

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

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

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

Анализ результатов пилота помогает принять решение о дальнейшей судьбе проекта. Может оказаться, что у заказчика очень высокие требования к уровню точности: например, 99% ответов должны быть верными, и на предыдущих шагах нам казалось, что это принципиально достижимо. Но на пилоте мы достигли точности 93% и, понятное дело, не можем обещать гарантированный 6%-ный прирост. Логично обсудить варианты развития проекта при имеющихся результатах пилота с заказчиком — о сборе дополнительных данных, снижении требуемой метрики или даже заморозке проекта до новых прорывов в CV-сфере.

Первые четыре шага можно показать такой схемой:



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

Шаг пятый: делаем всё остальное ;)

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


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

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