Разные алгоритмы трекинга мы делаем последние лет 12. Зачастую это очень простые алгоритмы трекинга. Иногда очень сложные и накрученные, как в Cherry. Если честно, то очень часто мы собирали их с нуля руками. Что такое фильтр Калмана понимаем, как сделать выбор лучшего соответствия в целом тоже.
Но, если честно, недавно бомбануло. Я увидел, как в двух разных фирмах для трекинга используют это – https://www.pyimagesearch.com/2018/10/29/multi-object-tracking-with-dlib/ (или аналоги с того же сайта). Для тех кто не хочет читать вкратце: детекция за счёт MobileNet-ssd, а связывание объектов за счёт трекера Dlib (или вариантов cv2). В одной из таких фирм это даже заработало каким-то чудом.
Но… Не надо так. Не надо использовать бажный оптический трекер. Править все его ошибки это гигантская работа, на которую нет OpenSource исходников. Я решил рассказать как сделать проще и стабильнее в несколько кликов.
Статья несколько более инженерная чем обычно. Без рассказов почему ML не работает;) Но зато, на мой взгляд, может помочь многим людям для их прототипов и домашних хоббийных проектов которые используют какой-то Computer Vision на embedded железках.
Натолкнулся на весьма интересное мнение что использование DL в браузере это никому не нужные игрушки. Но, как ни странно, на сегодняшний день это достаточно уникальный способ инференса моделей. Этот способ поддерживает телефоны, intel, amd, nvidia и всё-всё-всё. Конечно, производительность не максимальная. Но вам не нужно заботится о том что что-то у кого-то не пойдёт. Примерно 90% устройств будут поддержаны, и всё будет работать там. Сделал краткий обзор на тему того почему это не страшно:)
И внезапно я понял что нигде ранее я не затронул тему рисков в построении договора. Но это одна из краеугольных тем всего взаимодействия. Столько сил не уходит ни в одно из других обсуждений. Возможно поэтому и не писал. Каждый раз после очередного обсуждения рисков — не хочется об этом думать следующие пару дней.
Итак. О чём это. Это о KPI договора. Приходит заказчик и говорит: «Мы хотим делать детектирование объекта X с вероятностью 95%». Что с этим делать?
Этой осенью попал на две разные конференции по машинному обучению и его применению. Одну организовывал Роман (UseData – она была акцентирована скорее на разработчиков/тимлидов), вторая AiStories – она была скорее для бизнеса, о том как и куда внедрять.
Это не первые конференции на которых я был. Бывал и на более научных, и на более практических (хакатонах, семинарах). Но в глаза бросается сразу несколько вещей:
Может я скажу банальную вещь. Но очень часто натыкаюсь на то что многие люди этого не делают. Процесс берёт верх над результатом. И люди не используют критическое мышление. А ведь критическое мышление – это именно то что требуется от человека который должен делать Data Scince | Computer Vision.
Человек написал статью на Хабре о том как по какому-то датасету получил точность на порядок выше чем любой другой исследователь. Причём как получил… Взял очередной ML-автообучатель, написал пять строчек запуска – получил результат. Его (а так же кучу читателей) не смутило что:
В фреймворке нет ничего нового по сравнению с другими решениями
Есть другие решения на базе той же сетки с точностью сильно ниже
Все остальные решения +-сходились к одной и той же точности
Если бы это был единичный случай… Но я видел много таких примеров в продакшне. Человек делает явно ошибочную метрику/решению и начинает затирать какой он классный вместо того чтобы искать ошибку. Например в CherryLabs я очень долго добивался чтобы все члены команды машинного обучения относились критично к любой проделанной работе. Причём это проблема чаще всего свойственна тем кто в своей жизни не делал ничего кроме машинного обучения.
Правильная тактика, на мой взгляд, сомневаться вообще во всём. В любом утверждении. Это во многом противоестественно, но сильно помогает. Причём помогает в многих вариантах. Недавно Александр (автор сайта https://spark-in.me/ и соответствующего телеграмм канала ) прислал такое видео (человек сделал детектор оружия и предлагает гонять его для камер безопасности в школах):
Я долго ржал с этой идеи, ответив вот этим кадром:
Не говоря уже о том что оружие с момента того как его используют проще обнаружить детектором выстрела (эта система реализована в нескольких городах мира). Точности там сильно выше.
Короче. Это должен был быть краткий пост с общим посылом – “будьте критичнее”. И краткий набор советов:
Смотрите как решают задачу другие люди. Используйте это в качестве референса.
Вы сделали что-то на порядок круче? Ищите ошибку. Проверьте все возможные варианты прежде чем утверждать это.
Никто не решает вашу задачу? Хотите стать первопроходцем? Обычно это очень плохая идея. Скорее всего есть скрытые причины почему вашу задачу никто не смог решить. Вообще это очень плохая идея делать что-то первым. С вероятностью 90% вы обречены на провал.
Сделайте прототип в котором вместо алгорита работает человек. Цена такого прототипа в миллион раз меньше чем у системы на базе машинного обучения. Не надо собирать базу/размечать/настраивать. Зато соберёте самую важную метрику – “максимально допустимая точность”. Это критичный параметр в котором нельзя сомневаться (кстати, для того примера с пневманией, с которого я начал – этот параметр более менее известен: человек по рентгенограммам ошибается примерно в 5-7% случаев).
Нашли новую модель которая на голову лучше старой? Исследуйте граничные условия и консистентность датасета. Например, из практики. OpenPose и AplhaPose – две самых популярных модели для поиска скелета человека. AlphaPose сильно точнее по открытым датасетам… Но вот только есть такой момент. В открытых датасетах люди обычно большие и хорошо видны. И OpenPose во многих примерах даёт точность на порядки выше за счёт лучшего потенциала детекции. Помните что “универсальные метрики” – нифига не универсальны.
Сомневайтесь в любом утверждении пока не проверите его.
Всегда когда я разговариваю с человеком который хочет сделать новую систему распознавания я рассказываю о том что машинное обучение неидеально. Что всегда есть ошибки. Что всегда что-то будет идти не так. И что цель – не обучить один раз систему распознавания. А цель – выстроить систему которая будет стабильна к любым ошибкам распознавания.
Где-то с прошлого года у меня лежали две недописанные статьи. На прошлой неделе собрался с силами и в выходные их добил. Одна статья про то, как каждый день я сталкиваюсь с хренью в своей работе. И о том насколько бажет человеческое восприятие когда дело доходит до технологий.
Статья традиционно на хабре – https://habr.com/ru/company/recognitor/blog/446038/
Вторая статья – экспериментальная. Она про то, что машинное обучение – очень сложная штука, зачастую в современных реалиях чересчур сложная – и её не нужно лепить направо и налево. Статья экспериментальная в том числе потому что публикую её на платформе где ни разу раньше не писал – https://vc.ru/life/63227-mashinnoe-zrenie-ne-nuzhno-o..
Обе немного не в формате блока, так что тут только ссылка.
