Добрый день, вы правы. Полностью "мои" ответы будут крайне кратки, и скорей всего, не совсем полны(или вежливы). Так что использую нейросети для развёртывания/приведения в общепринятую норму, достаточно часто.
Может и выглядит "не так", зато понятно и в большинстве никого не обидит ¯\_(ツ)_/¯
Подтверждение известных паттернов — это лишь первый шаг. Хоть и он лично мне важен, очень часто в комментариях Пикабу сомневаются(в грубой форме) в возрасте брони. Теперь это подтверждено не только исследованиями в Интернете, но и лично.
Настоящая "глубина", о которой вы говорите, лежит в области предиктивной аналитики и ML, и этот проект — как раз подготовка плацдарма для нее.
Например, теперь, имея этот датасет, можно построить модель, которая ответит на неочевидный вопрос: "Что важнее для высокого рейтинга — популярный автор или популярный тег?". Или, как я упомянул в статье, проанализировать токсичность комментариев и найти корреляцию между темой поста и уровнем агрессии в обсуждении. Вот это уже будут те самые неочевидные факты. Этот дашборд — лишь первый шаг к ним.
Она там есть, но более "Лёгкий" вариант, без технического и всякого такого. Техническими деталями/подобным решил поделится на Хабре, как более профильном ресурсе.
Спасибо за вопрос! Все дело в целях проекта. Главной задачей было создание сверхлегкой (<10 МБ) и быстрой модели для CPU. CNN — это проверенный и самый эффективный инструмент именно для этого. Трансформеры были бы слишком тяжелыми, а нейроэволюция (NEAT) — избыточно сложной для такой классической задачи.
Спасибо за добрые слова) Очень приятно слышать, что моя статья и репозиторий оказались для вас полезным "шаблоном" и подтверждением ваших выводов. Именно ради таких моментов и стоит делиться своей работой с сообществом. Уверен, с таким подходом у вас все получится!
Выбор YOLOv8n был в первую очередь прагматичным решением для MVP, поскольку я уже имел с ней опыт работы. Цель этого проекта была не в поиске самой лучшей модели для этой задачи, а в том, чтобы проверить жизнеспособность идеи и построить полный каркас MVP
@Tumbao, извиняюсь мисскликнул и отклонил комментарий.
Спасибо за отличный и очень правильный вопрос. Вы абсолютно правы, исторически RNN/LSTM — это "золотой стандарт" для работы с последовательностями, и это был первый подход, который я рассматривал.
Однако для задачи классификации целого текста (а не, скажем, sequence-to-sequence перевода) архитектуры на базе CNN (в частности, 1D-сверток) показывают себя на удивление хорошо, и у них есть несколько ключевых преимуществ, которые для меня были решающими:
Параллелизм и скорость: В отличие от рекуррентных сетей, которые должны обрабатывать текст последовательно, слово за словом, свертки могут обрабатывать все n-граммы в тексте параллельно. Это делает и обучение, и инференс значительно быстрее.
Извлечение ключевых признаков: Идея в том, что свертка работает как "детектор n-грамм". Она "скользит" по тексту и ищет ключевые комбинации слов ("ты ведешь себя как", "полный дурак"), которые являются сильными сигналами токсичности, независимо от их положения в предложении. Для задачи классификации этого часто бывает более чем достаточно.
Простота и легковесность: CNN-архитектура для текста часто получается проще, имеет меньше параметров и быстрее сходится, чем сложная LSTM-модель.
В моем проекте, где одной из главных целей были скорость на CPU и легковесность модели, именно CNN оказалась идеальным компромиссом между качеством и производительностью.
Надеюсь, я смог прояснить ход своих мыслей! Еще раз спасибо за интересный вопрос.
Да, использовал, и довольно активно. Мой принцип — ИИ как "второй пилот", а не как автор.
В коде он писал шаблонные вещи и комментарии, позволяя мне фокусироваться на архитектуре. Для статьи и README — выступал в роли стилиста, улучшая форму(иногда слишком и нужно было упрощать, но как говорится "ломать - не строить"), но не суть.
Работая над проектом в одиночку, ИИ действительно становится незаменимым "спарринг-партнером" для отладки и проверки идей. Это интересный и очень продуктивный опыт.
И для одиночного разработчика, когда тебе не у кого спросить/посоветоваться/обсудить и есть только статьи по теме и тех.документация, ИИ достаточно полезен, главное понимать, что ИИ врут достаточно часто, и относится к его ответам критически, хотя бы в рамках своих знаний.
Да, вы правы. YOLO работает с 640х640, нагрузка от работы нейросети что для 480, что для 1080 особо не изменится. А вот привидение к этим 640х640 для 1080 будет несколько "дороже" по ресурсам.
А в целом по затратам ресурсов, проект сейчас MVP с достаточно "топорной" реализацией, предполагал оптимизировать уже под конкретные задачи/реализации)
Спасибо за критику по существу. Вы абсолютно правы, результат не идеален, и статья действительно выиграет от более честного анализа. Позвольте уточнить пару моментов.
1. Про ошибку на видео и контекст задачи. Вы совершенно верно подметили ошибку OCR. Я специально выбрал такой сложный кадр из "живого" трафика, чтобы продемонстрировать пределы возможностей MVP.
Изначально система проектировалась для более простых условий — статичных камер в автосервисе, где машины неподвижны. Как вы и сказали, для такой задачи текущего качества (с небольшим дообучением на целевых данных) уже достаточно.
Что касается фикса ошибки на видео, то здесь действительно два пути:
ML-подход: Дообучить OCR-модель с более "агрессивными" аугментациями (перспективные искажения, размытие).
CV-подход: Улучшить алгоритм препроцессинга, добавив, например, более сложную стабилизацию изображения перед распознаванием.
2. Про 100 эпох и переобучение YOLO. Это очень грамотное замечание. Риск переобучения при таком количестве эпох действительно существует. К счастью, в данном случае его удалось избежать, что подтверждается графиками обучения: кривые ошибок для train и val выборок идут почти в унисон, без значительного расхождения. Современные фреймворки, как ultralytics, имеют хорошие встроенные механизмы регуляризации, которые с этим помогают. Но вы правы в главном: пик метрики mAP@0.5-0.95 был достигнут значительно раньше (примерно на 70-80 эпохе), и для экономии ресурсов можно было смело останавливать обучение тогда. 100 эпох были скорее для "чистоты эксперимента".
Отличный вопрос. Точное количество сильно зависит от разрешения камер, FPS и количества машин в кадре.
На моем i7-9700KF одна камера ~480p@30fps загружала процессор на ~90%. Использовалось видео с "живого" регистратора.
С учетом оптимизаций (пропуск кадров, детектор движения) можно ожидать, что такой процессор уверенно "потянет" 2-3 камеры с разрешением 720p или 1-2 камеры 1080p. Для большего количества уже настоятельно рекомендуется использовать GPU.
Добрый день, вы правы. Полностью "мои" ответы будут крайне кратки, и скорей всего, не совсем полны(или вежливы). Так что использую нейросети для развёртывания/приведения в общепринятую норму, достаточно часто.
Может и выглядит "не так", зато понятно и в большинстве никого не обидит ¯\_(ツ)_/¯
В Markdown-разметке и по ней соответственно делил/разбивал на Чанки
Скриншотами, так как думаю так компактней
Организаторы Хакатона не разрешили в публичный доступ выкладывать, к сожалению
Подтверждение известных паттернов — это лишь первый шаг. Хоть и он лично мне важен, очень часто в комментариях Пикабу сомневаются(в грубой форме) в возрасте брони. Теперь это подтверждено не только исследованиями в Интернете, но и лично.
Настоящая "глубина", о которой вы говорите, лежит в области предиктивной аналитики и ML, и этот проект — как раз подготовка плацдарма для нее.
Например, теперь, имея этот датасет, можно построить модель, которая ответит на неочевидный вопрос: "Что важнее для высокого рейтинга — популярный автор или популярный тег?". Или, как я упомянул в статье, проанализировать токсичность комментариев и найти корреляцию между темой поста и уровнем агрессии в обсуждении. Вот это уже будут те самые неочевидные факты. Этот дашборд — лишь первый шаг к ним.
В будущем я этим займусь и реализую
Она там есть, но более "Лёгкий" вариант, без технического и всякого такого. Техническими деталями/подобным решил поделится на Хабре, как более профильном ресурсе.
Спасибо за вопрос! Все дело в целях проекта. Главной задачей было создание сверхлегкой (<10 МБ) и быстрой модели для CPU. CNN — это проверенный и самый эффективный инструмент именно для этого. Трансформеры были бы слишком тяжелыми, а нейроэволюция (NEAT) — избыточно сложной для такой классической задачи.
Спасибо за добрые слова) Очень приятно слышать, что моя статья и репозиторий оказались для вас полезным "шаблоном" и подтверждением ваших выводов. Именно ради таких моментов и стоит делиться своей работой с сообществом. Уверен, с таким подходом у вас все получится!
Так же поделюсь источником-вдохновением - https://habr.com/ru/articles/432444/
Вы абсолютно правы, MAE не показывает всей картины, а "худший случай" — очень важная метрика.
Мне и самому стало интересно посмотреть, и я пересчитал результаты. Вот что получилось по максимальному отклонению (Max Error):
Получается, что даже в самый неудачный день ошибка кастомной LSTM в 2-3 раза ниже, чем у остальных.
Обновил код добавив для удобства новое в 10 Ячейку ноутбука и обновил гит
Выбор YOLOv8n был в первую очередь прагматичным решением для MVP, поскольку я уже имел с ней опыт работы. Цель этого проекта была не в поиске самой лучшей модели для этой задачи, а в том, чтобы проверить жизнеспособность идеи и построить полный каркас MVP
@Tumbao, извиняюсь мисскликнул и отклонил комментарий.
Спасибо за отличный и очень правильный вопрос. Вы абсолютно правы, исторически RNN/LSTM — это "золотой стандарт" для работы с последовательностями, и это был первый подход, который я рассматривал.
Однако для задачи классификации целого текста (а не, скажем, sequence-to-sequence перевода) архитектуры на базе CNN (в частности, 1D-сверток) показывают себя на удивление хорошо, и у них есть несколько ключевых преимуществ, которые для меня были решающими:
Параллелизм и скорость: В отличие от рекуррентных сетей, которые должны обрабатывать текст последовательно, слово за словом, свертки могут обрабатывать все n-граммы в тексте параллельно. Это делает и обучение, и инференс значительно быстрее.
Извлечение ключевых признаков: Идея в том, что свертка работает как "детектор n-грамм". Она "скользит" по тексту и ищет ключевые комбинации слов ("ты ведешь себя как", "полный дурак"), которые являются сильными сигналами токсичности, независимо от их положения в предложении. Для задачи классификации этого часто бывает более чем достаточно.
Простота и легковесность: CNN-архитектура для текста часто получается проще, имеет меньше параметров и быстрее сходится, чем сложная LSTM-модель.
Этот подход — не моя выдумка, а хорошо известный метод, который был популяризирован, например, в статье Yoon Kim "Convolutional Neural Networks for Sentence Classification".
В моем проекте, где одной из главных целей были скорость на CPU и легковесность модели, именно CNN оказалась идеальным компромиссом между качеством и производительностью.
Надеюсь, я смог прояснить ход своих мыслей! Еще раз спасибо за интересный вопрос.
Да, использовал, и довольно активно. Мой принцип — ИИ как "второй пилот", а не как автор.
В коде он писал шаблонные вещи и комментарии, позволяя мне фокусироваться на архитектуре. Для статьи и README — выступал в роли стилиста, улучшая форму(иногда слишком и нужно было упрощать, но как говорится "ломать - не строить"), но не суть.
Работая над проектом в одиночку, ИИ действительно становится незаменимым "спарринг-партнером" для отладки и проверки идей. Это интересный и очень продуктивный опыт.
И для одиночного разработчика, когда тебе не у кого спросить/посоветоваться/обсудить и есть только статьи по теме и тех.документация, ИИ достаточно полезен, главное понимать, что ИИ врут достаточно часто, и относится к его ответам критически, хотя бы в рамках своих знаний.
Да, это поможет сэкономить от 30 до 50% общей нагрузки процессора
Да, вы абсолютно правы. Для 200 камер потребуется совершенно другой подход к архитектуре и "железу".
Этот проект вырос из небольшого фриланс-задания для автосервиса, поэтому и фокус в статье был на максимальной оптимизации под CPU.
Но если говорить о масштабировании на сотни камер, то архитектура решения кардинально меняется - без GPU уже не обойтись
Да, вы правы. YOLO работает с 640х640, нагрузка от работы нейросети что для 480, что для 1080 особо не изменится. А вот привидение к этим 640х640 для 1080 будет несколько "дороже" по ресурсам.
А в целом по затратам ресурсов, проект сейчас MVP с достаточно "топорной" реализацией, предполагал оптимизировать уже под конкретные задачи/реализации)
Спасибо за критику по существу. Вы абсолютно правы, результат не идеален, и статья действительно выиграет от более честного анализа. Позвольте уточнить пару моментов.
1. Про ошибку на видео и контекст задачи.
Вы совершенно верно подметили ошибку OCR. Я специально выбрал такой сложный кадр из "живого" трафика, чтобы продемонстрировать пределы возможностей MVP.
Изначально система проектировалась для более простых условий — статичных камер в автосервисе, где машины неподвижны. Как вы и сказали, для такой задачи текущего качества (с небольшим дообучением на целевых данных) уже достаточно.
Что касается фикса ошибки на видео, то здесь действительно два пути:
ML-подход: Дообучить OCR-модель с более "агрессивными" аугментациями (перспективные искажения, размытие).
CV-подход: Улучшить алгоритм препроцессинга, добавив, например, более сложную стабилизацию изображения перед распознаванием.
2. Про 100 эпох и переобучение YOLO.
Это очень грамотное замечание. Риск переобучения при таком количестве эпох действительно существует. К счастью, в данном случае его удалось избежать, что подтверждается графиками обучения: кривые ошибок для train и val выборок идут почти в унисон, без значительного расхождения. Современные фреймворки, как ultralytics, имеют хорошие встроенные механизмы регуляризации, которые с этим помогают. Но вы правы в главном: пик метрики mAP@0.5-0.95 был достигнут значительно раньше (примерно на 70-80 эпохе), и для экономии ресурсов можно было смело останавливать обучение тогда. 100 эпох были скорее для "чистоты эксперимента".
Отличный вопрос. Точное количество сильно зависит от разрешения камер, FPS и количества машин в кадре.
На моем i7-9700KF одна камера ~480p@30fps загружала процессор на ~90%. Использовалось видео с "живого" регистратора.
С учетом оптимизаций (пропуск кадров, детектор движения) можно ожидать, что такой процессор уверенно "потянет" 2-3 камеры с разрешением 720p или 1-2 камеры 1080p. Для большего количества уже настоятельно рекомендуется использовать GPU.
Плохо достаточно, для YOLO и OCR использовались датасеты с номерами в один ряд, MVP всё же. Для двурядных/квадратных надо дообучать