Да, это очень валидное опасение. Но наши эксперименты показывают, что "универсальный рецепт" действительно отрабатывает весьма качественно на возникающих у нас проектах из разных доменов.
"Всё зависит от размера датасета" – это не совсем тот вывод, что мы сделали. Правильно он звучит так: "чем меньше датасет, тем больше влияют параметры обучения". И наш вариант их параметризации в зависимости от размера датасета дает очень неплохой прирост на малых данных.
При этом, конечно, для получения не 90% accuracy, а 95+ нужно больше данных и больше подстраиваться под конкретный домен - что мы и делаем в настоящий момент, создавая кастомные претрейны (об этом когда-нибудь тоже напишу). Ну и в планах у нас сравнить полученные рецепты с тем, что нам мог бы дать autoresearch, подбирающий всё под конкретную задачу.
Сходила к людям, ответственным за внедрение с вашими вопросами, чтобы точно не наврать.
Тут зависит от выбранной архитектуры внедрения, если на объект выносим только раскадровку (детекция+трекинг) и выбор лучших кадров за трек, то можно и в одноплатник уместиться. Если нужно оценить транспортный поток по типам ТС прям на месте, то понадобится больше мощности. Очень индивидуально и зависит от задачи.
Как уже писали, не обязательно передавать отдельные изображения на удаленный сервер, но если предположить, что выбрали такую архитектуру, то кажды отдельный кроп машины занимает ~500 Кбайт, включая отдельный кроп номера в полном разрешении. Вот в зависимости от интенсивности транспортного потока можно оценить нагрузку на канал передачи данных.
Тут зависит от того, что войдет в архитектуру решения. Если интересно за сколько api выполняет отдельный запрос - например детекции ТС/распознавания атрибутов, то тут у нас каждая из сеток работает <50 ms на CPU. На GPU, конечно, в 20-30 раз быстрее.
Привет! Отличный вопрос :) Если говорить про лица, то подобные трюки в хороших системах не прокатят, потому что там есть проверка Liveness - действительно ли перед камерой находится настоящий человек или происходит подлог с помощью фотки лица/экрана телефона и лицом и тд. Как такие технологии используются можно почитать в посте моей коллеги https://habr.com/ru/companies/ru_mts/articles/834100/
Если говорить про машинки, то для них Liveness-а явного у нас нет, видимо потому что ещё никто бумажками шлагбаумы не пытался обмануть, но практика показывает, что детекторы ТС и номеров всякие поддельные штуки и бумажки вместо номеров не очень любит находить, а если объект не задетектился - то и события нет.
Привет! В нашем случае мы сделали классификацию на 4 класса: огонь, темный дым, светлый дым, ничего интересного. Такой был запрос со стороны продукта, в том числе для более удобного осмотра свалок и лесополос с дронов, так как темный дым сигналазует об активном возгорании, а светлый уже о тлении. Цветной дым, кажется, обычно в увесилительных целях появляется, на него запроса не было (и при разметке мы его относили к темному).
Да, это очень валидное опасение. Но наши эксперименты показывают, что "универсальный рецепт" действительно отрабатывает весьма качественно на возникающих у нас проектах из разных доменов.
"Всё зависит от размера датасета" – это не совсем тот вывод, что мы сделали. Правильно он звучит так: "чем меньше датасет, тем больше влияют параметры обучения". И наш вариант их параметризации в зависимости от размера датасета дает очень неплохой прирост на малых данных.
При этом, конечно, для получения не 90% accuracy, а 95+ нужно больше данных и больше подстраиваться под конкретный домен - что мы и делаем в настоящий момент, создавая кастомные претрейны (об этом когда-нибудь тоже напишу). Ну и в планах у нас сравнить полученные рецепты с тем, что нам мог бы дать autoresearch, подбирающий всё под конкретную задачу.
Добрый день! Спасибо за фидбэк :)
Сходила к людям, ответственным за внедрение с вашими вопросами, чтобы точно не наврать.
Тут зависит от выбранной архитектуры внедрения, если на объект выносим только раскадровку (детекция+трекинг) и выбор лучших кадров за трек, то можно и в одноплатник уместиться. Если нужно оценить транспортный поток по типам ТС прям на месте, то понадобится больше мощности. Очень индивидуально и зависит от задачи.
Как уже писали, не обязательно передавать отдельные изображения на удаленный сервер, но если предположить, что выбрали такую архитектуру, то кажды отдельный кроп машины занимает ~500 Кбайт, включая отдельный кроп номера в полном разрешении. Вот в зависимости от интенсивности транспортного потока можно оценить нагрузку на канал передачи данных.
Тут зависит от того, что войдет в архитектуру решения. Если интересно за сколько api выполняет отдельный запрос - например детекции ТС/распознавания атрибутов, то тут у нас каждая из сеток работает <50 ms на CPU. На GPU, конечно, в 20-30 раз быстрее.
Рада слышать (читать) :)
Привет! Отличный вопрос :)
Если говорить про лица, то подобные трюки в хороших системах не прокатят, потому что там есть проверка Liveness - действительно ли перед камерой находится настоящий человек или происходит подлог с помощью фотки лица/экрана телефона и лицом и тд. Как такие технологии используются можно почитать в посте моей коллеги https://habr.com/ru/companies/ru_mts/articles/834100/
Если говорить про машинки, то для них Liveness-а явного у нас нет, видимо потому что ещё никто бумажками шлагбаумы не пытался обмануть, но практика показывает, что детекторы ТС и номеров всякие поддельные штуки и бумажки вместо номеров не очень любит находить, а если объект не задетектился - то и события нет.
Привет, согласна!
Подумаю, смогу ли в будущем какое-нибудь конкретнее внедрение с этой точки зрения осветить.
Привет!
В нашем случае мы сделали классификацию на 4 класса: огонь, темный дым, светлый дым, ничего интересного.
Такой был запрос со стороны продукта, в том числе для более удобного осмотра свалок и лесополос с дронов, так как темный дым сигналазует об активном возгорании, а светлый уже о тлении. Цветной дым, кажется, обычно в увесилительных целях появляется, на него запроса не было (и при разметке мы его относили к темному).