{"id":14274,"url":"\/distributions\/14274\/click?bit=1&hash=fadd1ae2f2e07e0dfe00a9cff0f1f56eecf48fb8ab0df0b0bfa4004b70b3f9e6","title":"\u0427\u0435\u043c \u043c\u0443\u0440\u0430\u0432\u044c\u0438\u043d\u044b\u0435 \u0434\u043e\u0440\u043e\u0436\u043a\u0438 \u043f\u043e\u043c\u043e\u0433\u0430\u044e\u0442 \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u0438\u0441\u0442\u0430\u043c?","buttonText":"\u0423\u0437\u043d\u0430\u0442\u044c","imageUuid":"6fbf3884-3bcf-55d2-978b-295966d75ee2"}

Computer Vision - что может пойти не так

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

Причин почему это происходит - масса. Иногда - так как алгоритмы не идеальны. Иногда - так как CV работает по одному кадру, а не по видео. А бывает, что задачу вообще нельзя решить по данным с камеры.
Большая часть статей по ML - о том как что-то удалось сделать. Но мало статей о том что не работает. Я хочу восполнить этот пропуск и немножко рассказать именно о проблемах.

Пару слов о том откуда истории.
Мы с друзьями занимаемся Computer Vision где-то года с 2008. Часть проектов - дошли до продукта. Часть - исследовательские и экспериментальные. Часть - наши собственные эксперименты.
За прошлые лет десять накопилось за полсотни проектов в которых принимали участие. И сотни рассказов о том как это происходило у людей в поле зрения.

Плохое качество картинки

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

История 1. Где-то году в 2016-2017 мы перенесли наш старый алгоритм распознавания автономеров на нейронные сети (на тот момент это было редкостью).

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

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

Наш алгоритм работал даже на простых вычислителях, таких как RaspberryPI (5 т.р.) и JetsonTX1 (40 т.р.), что было куда дешевле специального оборудования. И обрабатывал куда более плохие номера чем классические алгоритмы.
Было понятно, что через несколько лет мощности будет даже больше. И эту производительность можно было “конвертировать” в более хорошее качество

Провели 3-4 пилота с разными фирмами. И... Всё оказалось прозаично. Был небольшой процент машин когда номер не видно. Да, мы читали грязные номера. Но бывают настолько грязные, что считать нельзя. Бывают пересвеченные и засвеченные, когда номер вообще не виден. Бывают установленные так, что их не видно с камеры.

В дорогих комплексах часть таких номеров вытаскивалось за счёт хорошего света.
Но даже там проблема одна и та же: что делать с теми 5% когда номера не видно? Шлагбаум не откроется. Заставить человека идти мыть номер/выключать фары/ждать пока солнце перестанет слепить камеру/перевешивать номер?

Конечно нет. Нужен оператор/брелок/открытие по номеру телефона в качестве резерва. И остаётся один вопрос… А зачем тогда распознавание номеров?

История 2. Параллельно с этой статьей я опубликовал статью на Хабре. Вкратце: сделал автоматическую видеоняню. Алгоритм определяет когда ребёнок открыл глаза и присылает уведомление. Штуку с самого начала делал именно для развлечения. Но он является хорошим примером того что такое “не идеально установленная камера”. Ребёнок может отвернуться от камеры, может закрыть лицо руками. Иногда не хватает освещения:

И если освещение всё же можно выправить, то объяснить ребёнку что лицо закрывать и отворачиваться не надо - никак не получится.

История 3. Мы делали несколько задач для фирм которым требовалось распознавание товаров на полках. Как сделать чтобы модели перестали работать? Просто снять товар так чтобы не была видна этикетка. Не специально. Таких товаров будет 10-15% по умолчанию:

Можно ли догадаться что за товар там стоит? Иногда да (например зная окружение). Иногда нет.

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

История 4. Каски/перчатки. Одна из самых популярных задач с которой регулярно приходят - “А сделайте нам распознавание безопасности для предприятия. Например перчаток на руках, или крепление чего-нибудь куда-то”.

Ни разу не брались за эту задачу, так как всегда видно что по тем видео что есть у заказчика - решить её только через ComputerVision невозможно.Можно ли её решить в принципе? Конечно. Только система должна быть на порядок сложнее, включать в себя операторов, возможно монтаж камер. И прочее и прочее. Кто таким занимается? Например CherryLabs. Но есть и другие ребята.

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

Я видел работающие продукты в этой сфере. Более того, ещё году в 2014, первая интеграция нашего алгоритма автоматического распознавания номеров была именно для помощи заполнения полей в приложении.
Но далеко не все понимают, что качество может упираться в 70-80% для таких юзкейсов. Не снимают суровые работяги так чтобы видно всё было. И такие алгоритмы почти нельзя использовать как отчёт о проделанной работе. Работники начинают их обманывать, что зачастую неустранимо.

Недостаточная точность модели

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

Пример 1. Опять же, из статьи на Хабре. Используемая модель плохо работает на детях, даже когда лицо открыто (лица детей отличаются от взрослых). Обучить на одном ребёнке можно. Но чтобы стабильно работали на всех детях - надо сильно увеличивать датасет. Можно это сделать? Можно. Но это уже нельзя сделать если у вас небольшая фирма без ресурсов к сбору датасетов. До тех пор пока вы пользуетесь предобученной моделью - вы не сможете получить хорошее качество.

Пример 2. Очень большое разнообразие входных данных, но мало примеров. Нейронные сети могут обобщать. И есть ситуации в которых они обобщают почти идеально (поиск товаров на полках, поиск ценников). Но есть задачи где разнообразие может быть слишком большим и примеров будет недостаточно. Я видел такое в двух местах. Первое - робототехника и эксплуатация конвейеров. Там очень дорого набирать датасет на каждое изменение. Второе - распознавание действий. Для успешного распознавания действий нужно очень много вариаций каждого действия. А такие датасеты очень большие и сложно собирать.Сейчас развиваются подходы когда можно сделать что-то хитрее. Но пока таких подходов мало, а их внедрение не глубоко.

Пример 3. Трекинг. Про то, почему трекинг - сложная задача в современном ComputerVision у меня есть большая статья на Хабре. Но это очень хороший пример когда идеальная точность алгоритма почти невозможна.

Неправильно заложенная производительность

Одна из замечательных проблем, которую все забывают - рассчитать производительность. Нейронные сети едят много. И одно дело - выполнять задачи на кластерах (GPU/VPU), и совсем другое - на Edge устройствах. Сейчас я не буду вдаваться в платформы и их особенности(почитать можно например тут). Но расскажу пару примеров куда может привести неправильный рассчёт:

История 1. Однажды, ещё до появления нейронных сетей в нашей практике, мы разработали алгоритм анализа биометрических признаков для одного из заказчиков. Классический CV, контурные анализы/пороговые обработки, .и.т.д.
В какой-то момент заказчик оценил производительность алгоритма, и решил использовать более бюджетный вычислитель, где производительности хватало в упор. Только вот проблема. Через какое-то время эксплуатации выяснилось, что аппаратура не закрывает 100% потребностей - нужен дополнительный алгоритм для анализа ошибок.Только вот производительности уже не было. В результате задачу, конечно, решили. Только вот она требовала раз в пять больше времени на разработку, чем можно было бы, если бы производительность была заранее заложена.

Так что очень советую - не берите вычислитель в упор. 30-50% запаса позволит вам делать апгрейды.

История 2. Как то к нам пришёл заказчик из одной европейской компании. И предложил нам поучаствовать в конкурсе по созданию системы машинного зрения. Система должна была была работать на JetsonNano. Со скоростью порядка 10fps, детектировать людей/машины/распознавать номера/пол и возраст людей/трекать найденные объекты, замазывать лица, и.т.д. На вопрос “а почему не использовать AGX, где производительности хотя бы в теории хватит?”, было сказано что-то в стиле "ТЗ уже написано, и вопрос не в том какую аппаратуру использовать, а в том чтобы реализовать требуемый функционал".Ну, как вы понимаете, в конкурсе мы отказались принимать участие.

История 3. Однажды реализовали систему поиска и оценки параметров некоторой специфической аппаратуры с телефона. Всё замечательно работало и заказчику понравился результат. Заказчик вернулся спустя несколько месяцев с новой задачей - расширить список поддерживаемых телефонов, введя более дешёвые модели, где производительности было где-то в 3-4 раза меньше.

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

Выводы

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

Больше моих статей можно найти в telegram-канале, или в сообществе.

0
1 комментарий

Комментарий удален модератором

Развернуть ветку
Александр Столыпин

Для AI нужна бигдата. А для этого инвестиции. Но в россии это не работает. Если хотите успеха - езжайте в америку за деньгами

Ответить
Развернуть ветку
-2 комментариев
Раскрывать всегда