Можно подобрать количество эпох исходя из размера батча и размера датасета, подсчитав количество суммарных итераций за всё обучение, как правило при обучении YOLO как раз эта цифра решает. Я бы посоветовал начинать с 50-100 тысяч итераций для первого обучения и поставить patience на 15-25% от датасета, чтобы в случае, если сеть начала переобучение на train, мы перестали дальше обучать. Например, если у нас 32 тысячи изображений и батч 32, то ставим от 50 до 100 эпох и patience 10-25 эпох. Если хочется побыстрее обучить, то меняем SGD на AdamW и тренировка займёт в несколько раз меньше эпох.
Один и тот же датасет может давать сильно разные результаты в зависимости от аугментаций и гиперпараметров. Аугментации могут как натолкнуть сеть на понимание в каких случаях детекции должны быть, так и наоборот, сбить её с верного пути.
В проекте уже есть модели, которые работают на CelebaSpoof с напечатанными изображениями, значит спуф с большой вероятностью не пройдёт. К тому же при неудачной попытке прохождения валидации изображения генерируется событие, так что такие попытки обмануть камеру становятся рискованными занятием, которое может повлечь последствия.
Нашей задачей не было повторить успех idrnd за несколько месяцев располагая совсем другими бюджетами, нашей целью было недопустить попытки спуфов и сделать их детектируемыми. Никто в здравом уме не будет экспериментировать как обмануть камеру, если всё это отлавливается больше чем в 99% случаев.
Если вы хотите повысить уровень безопасности, то валидацию уже нужно делать на видео, где приложение даёт команды и человек их выполняет. Неспроста банкинги, биржи, где нужна максимальная надёжность, изспользуют именно такой подход, а не 2D.
Анти-спуфинг сделан для КПП, куда большой монитор пронести весьма проблематично)) Также и виртуальную камеру не подключишь, используется только наша камера внутри приложения.
Собрать вручную датасет с распечаткой большая проблема, те модели что мы уже нашли работают с ней достаточно хорошо (проверяли на CelebaSpoof), нашей же задачей было покрыть самый популярный и ожидаемый вид атак через использования дисплея.
Чтобы добиться более стабильной работы на всех вариантах спуфов нужно уже смотреть на варианты такие как ИК и стерео камеры – и это уже в планах на будущее)
В планах расписать подробнее про непосредственно создание датасета и тренировку модели для распознавания. Подписывайтесь на ТГ, указанную в статье, буду там давать анонсы)
Письменный иврит, думаю, та еще задачка)) В нашем случае, клиенту нужно было распознавание именно печатных символов, страниц документов. Если будет кейс по рукописному ивриту -- поделюсь опытом))
Да, классная идея. Если синтетических данных не будет хватать, то действительно можно использовать нейронные сети для генерации изображений. Но это уже после использования SynthText, который предназначен как раз для генерации данных OCR. О нем упоминал в статье: https://github.com/ankush-me/SynthText
GPT помогает мне расставлять знаки препинания (не моя сильная сторона, к сожалению)
так что, да, использую чат) но не для написания текста
Можно подобрать количество эпох исходя из размера батча и размера датасета, подсчитав количество суммарных итераций за всё обучение, как правило при обучении YOLO как раз эта цифра решает. Я бы посоветовал начинать с 50-100 тысяч итераций для первого обучения и поставить patience на 15-25% от датасета, чтобы в случае, если сеть начала переобучение на train, мы перестали дальше обучать. Например, если у нас 32 тысячи изображений и батч 32, то ставим от 50 до 100 эпох и patience 10-25 эпох. Если хочется побыстрее обучить, то меняем SGD на AdamW и тренировка займёт в несколько раз меньше эпох.
Один и тот же датасет может давать сильно разные результаты в зависимости от аугментаций и гиперпараметров. Аугментации могут как натолкнуть сеть на понимание в каких случаях детекции должны быть, так и наоборот, сбить её с верного пути.
Да, мы думали про «зоопарк браузеров», но основной пойнт задачи был в другом — отсеять битые Lottie ещё на фронте, чтобы вообще не дёргать бэкенд.
Во-первых, это экономит ресурсы (и наши, и клиента), во-вторых, даёт мгновенный фидбэк пользователю, что файл кривой.
А массовую проверку в разных окружениях можно будет докрутить, если придёт много анимаций от сторонних команд.
В проекте уже есть модели, которые работают на CelebaSpoof с напечатанными изображениями, значит спуф с большой вероятностью не пройдёт. К тому же при неудачной попытке прохождения валидации изображения генерируется событие, так что такие попытки обмануть камеру становятся рискованными занятием, которое может повлечь последствия.
Нашей задачей не было повторить успех idrnd за несколько месяцев располагая совсем другими бюджетами, нашей целью было недопустить попытки спуфов и сделать их детектируемыми. Никто в здравом уме не будет экспериментировать как обмануть камеру, если всё это отлавливается больше чем в 99% случаев.
Если вы хотите повысить уровень безопасности, то валидацию уже нужно делать на видео, где приложение даёт команды и человек их выполняет. Неспроста банкинги, биржи, где нужна максимальная надёжность, изспользуют именно такой подход, а не 2D.
@Alex-Freemanrandomsimplenumber
Анти-спуфинг сделан для КПП, куда большой монитор пронести весьма проблематично))
Также и виртуальную камеру не подключишь, используется только наша камера внутри приложения.
@Kamil_GR @ivazhu отвечу сразу одним комментом)
Собрать вручную датасет с распечаткой большая проблема, те модели что мы уже нашли работают с ней достаточно хорошо (проверяли на CelebaSpoof), нашей же задачей было покрыть самый популярный и ожидаемый вид атак через использования дисплея.
Чтобы добиться более стабильной работы на всех вариантах спуфов нужно уже смотреть на варианты такие как ИК и стерео камеры – и это уже в планах на будущее)
О, спасибо за совет. Обязательно посмотрю
спасибо за оценку)) как обычно, не хватает времени все тщательно вычитать)
В планах расписать подробнее про непосредственно создание датасета и тренировку модели для распознавания. Подписывайтесь на ТГ, указанную в статье, буду там давать анонсы)
Письменный иврит, думаю, та еще задачка)) В нашем случае, клиенту нужно было распознавание именно печатных символов, страниц документов. Если будет кейс по рукописному ивриту -- поделюсь опытом))
Да, классная идея. Если синтетических данных не будет хватать, то действительно можно использовать нейронные сети для генерации изображений. Но это уже после использования SynthText, который предназначен как раз для генерации данных OCR. О нем упоминал в статье: https://github.com/ankush-me/SynthText