Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 16
Честно говоря, ничего непонятно. Основная аудитория Хабра, конечно, имеет базовые представления об обычной свёрточной нейросети, но полагать, что все знают новые модные RetinaNET, EfficientNet и PANet, не стоит. А без этого знания (и отсылкам к статьям про них) понять, что там за «узлы» на рисунках с архитектурой сети, что с чем складывается (какие матрицы) — увы, не получается. Было бы хорошо, если бы всё было объяснено более «на пальцах», базируясь на известных понятиях типа свёрточного слоя, полносвязного слоя, операции пулинга, и дальше уже объяснить что там за узлы в новой архитектуре и как устроены.
Без этого статья получается ультра узконаправленной и понятной не просто только специалистам по машинному обучению, а только специалистам в компьютером зрении, да и то не всем, думаю.
В оригинальной статье авторов (не поленился и открыл) — всё понятнее, так как хотя бы приведены формулы слоёв и больше деталей.
Без этого статья получается ультра узконаправленной и понятной не просто только специалистам по машинному обучению, а только специалистам в компьютером зрении, да и то не всем, думаю.
В оригинальной статье авторов (не поленился и открыл) — всё понятнее, так как хотя бы приведены формулы слоёв и больше деталей.
Очень жаль, что моя статья показалась вам сложной, но спасибо, что написали об этом, в ближайшее время я займусь её рефакторингом: добавлю формулы, распишу поподробнее. А пока что: RetinaNet — это же обыкновенный ResNet (ну, его-то должны знать?), к которому приделана пирамида признаков (FPN — вроде, тоже достаточно известная штука), EfficientNet — это сеть, состоящая из свёрточных слоёв, которые можно масштабировать, да, пожалуй, про неё можно отдельно написать, с PANet я впервые познакомилась близко в этой статье, но мне хватило его схемы, чтобы понять основные особенности.
В статье 10 страниц мелкого шрифта — конечно, там больше деталей! :)
В статье 10 страниц мелкого шрифта — конечно, там больше деталей! :)
Спасибо за разбор.
А как авторы сравнивались с конкурентами?
Гиперпараметры и тренировочная схема интересуют. Иногда бывает, что авторы «забывают» об удачно подобранных гиперпараметрах конкурентов и сравнение получается не очень честным.
А как авторы сравнивались с конкурентами?
Гиперпараметры и тренировочная схема интересуют. Иногда бывает, что авторы «забывают» об удачно подобранных гиперпараметрах конкурентов и сравнение получается не очень честным.
Есть ли код, реализующий EfficientDet?
Код (не мой) можно посмотреть, например, тут:
github.com/toandaominh1997/EfficientDet.Pytorch
github.com/toandaominh1997/EfficientDet.Pytorch
Спасибо автору, что знакомит российскую аудиторию с современными достижениями ИИ.
Несколько уточнений:
1. Официальный код на TensorFlow: github.com/google/automl/tree/master/efficientdet
2. Эта хитрая функция называется — ReLU
3. BiFPN использует weighted multi-input Residual connections, в которых сумма весов равна 1 (нормализованы). Это обычные Residual connections из ResNet-сетей, но:
— I. На вход подается не 2, а от 2 до 4 выходов предыдущих слоев
— II. Входы не просто складываются, а умножаются на вес (1 вес на каждый вход). Т.е. если на вход подается 3 слоя, то:
Тогда как для обычного Residual connection: out[i] = in1[i] + in2[i]; out[i+1] = in1[i+1] + in2[i+1];
4. Авторы EfficientDet разработали эффективную с точки зрения формальных параметров BFLOPS, но не эффективную с точки зрения производительности, поэтому в Google отказались от большинства фич, которые радикально уменьшают BFLOPS, а именно отказались от: Swish, Depthwise convolution и Squeeze-and-excitation block
ai.googleblog.com/2019/08/efficientnet-edgetpu-creating.html
5. Авторы EfficientDet в таблице 2 уточняют, что FPS-скорость для Yolov3 они взяли из yolo-статьи, где её измеряли на TitanX/M40 maxwell, а FPS-скорость для EfficientDet они измеряли на TitanV volta, которая на 2 поколения новее и в несколько раз быстрее. Только поэтому EfficientDet получилась чуть лучше по скорости и точности, чем старая Yolov3.
6. Авторы EfficientNet/Det из Google AI использовали AutoML/NAS для автоматического подбора оптимальных гиперпараметров/разрешения/глубины/количества-параметров для конкретных датасетов ILSVRC2012-classification / MSCOCO-detection.
nni.readthedocs.io/en/latest/TrialExample/EfficientNet.html
ai.googleblog.com/2019/05/efficientnet-improving-accuracy-and.html
Несколько уточнений:
1. Официальный код на TensorFlow: github.com/google/automl/tree/master/efficientdet
Также в EfficientDet используется хитрая фунцкия вместо SoftMax, в основе которой лежит метод быстрой нормализации слияния,
2. Эта хитрая функция называется — ReLU
3. BiFPN использует weighted multi-input Residual connections, в которых сумма весов равна 1 (нормализованы). Это обычные Residual connections из ResNet-сетей, но:
— I. На вход подается не 2, а от 2 до 4 выходов предыдущих слоев
— II. Входы не просто складываются, а умножаются на вес (1 вес на каждый вход). Т.е. если на вход подается 3 слоя, то:
out[i] = in1[i]*w1 + in2[i]*w2 + in3[i]*w3;
out[i+1] = in1[i+1]*w1 + in2[i+1]*w2 + in3[i+1]*w3; ...Тогда как для обычного Residual connection: out[i] = in1[i] + in2[i]; out[i+1] = in1[i+1] + in2[i+1];
4. Авторы EfficientDet разработали эффективную с точки зрения формальных параметров BFLOPS, но не эффективную с точки зрения производительности, поэтому в Google отказались от большинства фич, которые радикально уменьшают BFLOPS, а именно отказались от: Swish, Depthwise convolution и Squeeze-and-excitation block
ai.googleblog.com/2019/08/efficientnet-edgetpu-creating.html
5. Авторы EfficientDet в таблице 2 уточняют, что FPS-скорость для Yolov3 они взяли из yolo-статьи, где её измеряли на TitanX/M40 maxwell, а FPS-скорость для EfficientDet они измеряли на TitanV volta, которая на 2 поколения новее и в несколько раз быстрее. Только поэтому EfficientDet получилась чуть лучше по скорости и точности, чем старая Yolov3.
6. Авторы EfficientNet/Det из Google AI использовали AutoML/NAS для автоматического подбора оптимальных гиперпараметров/разрешения/глубины/количества-параметров для конкретных датасетов ILSVRC2012-classification / MSCOCO-detection.
nni.readthedocs.io/en/latest/TrialExample/EfficientNet.html
ai.googleblog.com/2019/05/efficientnet-improving-accuracy-and.html
2 ReLU используется повсеместно (и уже не новая) как функция активации, потому что дает более быстрое обучение. Она не может служить заменой SoftMax. Вы что-то путаете
Спасибо за уточнения и, пользуясь случаем, Ваш вклад в области компьютерного зрения и локализации объектов, Алексей!
Хотел бы добавить по некоторым пунктам:
4. Это действительно так, но, как можно судить, справедливо больше для исполнения моделей на Edge TPU и, можно ожидать, других специализированных аппаратных средствах для нейромоделей. Эта проблема также довольно подробно обсуждается авторами модели Pelee и в части, касающейся Edge TPU, статьи о MobileNetv3. Но, например, на оконечных устройствах NVIDIA семейства Jetson используются, фактически, традиционные видеоядра, и там зависимость быстродействия от количества операций более прямая. В моих собственных экспериментах на Jetson Nano вариант MobileNetv3-small показывает ещё несколько более впечатляющие результаты.
5. Как можно судить, в титульной реализации EfficientDet, похоже, вообще не очень-то преисполнялись темой быстродействия, поскольку вот автор одной из недавних реализаций на PyTorch заявляет о более высоком уровне в его экспериментах. Это, конечно, не официальные результаты и не объективные измерения, но автор достаточно авторитетен своими реализациями моделей на PyTorch, поэтому некоторое дополнительное представление его результаты, тем не менее, дать могут.
Успехов Вам в будущих разработках!
Хотел бы добавить по некоторым пунктам:
4. Это действительно так, но, как можно судить, справедливо больше для исполнения моделей на Edge TPU и, можно ожидать, других специализированных аппаратных средствах для нейромоделей. Эта проблема также довольно подробно обсуждается авторами модели Pelee и в части, касающейся Edge TPU, статьи о MobileNetv3. Но, например, на оконечных устройствах NVIDIA семейства Jetson используются, фактически, традиционные видеоядра, и там зависимость быстродействия от количества операций более прямая. В моих собственных экспериментах на Jetson Nano вариант MobileNetv3-small показывает ещё несколько более впечатляющие результаты.
5. Как можно судить, в титульной реализации EfficientDet, похоже, вообще не очень-то преисполнялись темой быстродействия, поскольку вот автор одной из недавних реализаций на PyTorch заявляет о более высоком уровне в его экспериментах. Это, конечно, не официальные результаты и не объективные измерения, но автор достаточно авторитетен своими реализациями моделей на PyTorch, поэтому некоторое дополнительное представление его результаты, тем не менее, дать могут.
Успехов Вам в будущих разработках!
В моих собственных экспериментах на Jetson Nano вариант MobileNetv3-small показывает ещё несколько более впечатляющие результаты.
4. На GPU (и Jetson) ещё больше проблем с Grouped/Depthwise-conv используемых в EfficientDet.
— MobileNetv3-small — 16.1% AP arxiv.org/pdf/1905.02244v5.pdf
— YOLOv4-416 — 41.2% AP и 30 FPS на Jetson Xavier AGX если запустить на OpenCV или tkDNN-TesnorRT batch=1
— MobileNetv3 — оптимальна только для CPU / мобильных-CPU / устройств 5-летней давности
— YOLOv4 full/tiny — оптимальна для GPU и NPU/VPU/TPU
— EfficientDet — ни для чего не оптимальна
вот автор одной из недавних реализаций на PyTorch заявляет о более высоком уровне в его экспериментах.
Потому что тестируют с batch=64 github.com/rwightman/efficientdet-pytorch/issues/28#issuecomment-636532299
Если YOLOv4 запустить хотя бы с batch=4, то мы уже получаем более 400 FPS на той же RTX 2080Ti, с гораздо большей точностью чем у D0:
5. Как можно судить, в титульной реализации EfficientDet, похоже, вообще не очень-то преисполнялись темой быстродействия,
5. Google это коммерческая компания, с большими зарплатами, которые там не платят просто за написание статьи. Сказать что им не важна скорость — это сказать, что им не важны деньги. Допустим Apple заплатила $200 M за то, чтобы Yolo работала побыстрее с небольшим падением точности: news.crunchbase.com/news/apple-acquires-ai-on-the-edge-startup-xnor-ai-for-around-200m
Researchers at Xnor.ai developed an object detection model they called You Only Look Once (aka YOLO), which the company licensed to enterprise customers including internet-connected home security camera company Wyse.
EfficientDet разрабатывала команда Google Brain, для того, чтобы использовать её как на TPU-Edge-devices, так и внутри Google, и от скорости зависит сколько они потратят на Hardware в масштабах Google, например, $10 M или $20 M. Так же зависит их репутация от фейкового сравнения со старой Yolov3.
Поэтому они сразу кинулись допиливать код и исправлять статью, а именно таблицу 2:
— было 3 Apr 2020: arxiv.org/pdf/1911.09070v4.pdf
— стало 24 May 2020: arxiv.org/pdf/1911.09070v5.pdf
1. Убрали Latency/FPS для Yolov3
2. Бросились увеличивать скорость потому, что как оказалось, на самом деле самая быстрая EfficientDet-D0 даже медленнее, чем самая медленная старая Yolov3-608 :)
Было D0-512 — 62 FPS — 33.8% AP — 52.2% AP50
Стало D0-512 — 98 FPS — 33.8% AP — 52.2% AP50
Когда
YOLOv4-416 — 96 FPS — 41.2% AP — 62.8% AP50
YOLOv4-320 — 123 FPS — 38% AP — 60% AP50
Yolov3-416 — 100 FPS — 31% AP — 55% AP50
Т.е. по AP50, даже старая (2018 год) Yolov3-416 быстрее и точнее, чем даже улучшенная (2020 год) версия EfficientDet-D0. Т.е. вообще занавес.
4. На GPU (и Jetson) ещё больше проблем с Grouped/Depthwise-conv используемых в EfficientDet.Результаты на AGX Xavier, полагаю, для int8? В любом случае, конечно, впечатляюще.
— MobileNetv3-small — 16.1% AP arxiv.org/pdf/1905.02244v5.pdf
— YOLOv4-416 — 41.2% AP и 30 FPS на Jetson Xavier AGX если запустить на OpenCV или tkDNN-TesnorRT batch=1
Тем не менее, мой опыт экспериментов на Jetson Nano даёт несколько иные результаты: модель на основе Tiny-YOLOv3 (416x416, fp16) смогла заработать в DeepStream 4.04 с частотой 32-33 кадра в секунду, на основе MobileNetv3-small+SSDLite (300x300, fp16) — 63-64 кадра в секунду при схожем уровне производительности. Не берусь рассуждать, насколько это отражает объективную картину, да и подтвердить заявление о производительности моделей мне нечем, набор данных рабочий, закрытый, а вот сравнение быстродействия доступно: пример с YOLO находится в комплекте с DeepStream 4, а реализацию на базе MobileNet я использовал эту.
Потому что тестируют с batch=64Очень любопытно, спасибо, что уточнили! Я, увидев FPS, сразу неявно предположил, что действительно с batch-size=1 указано, а так это, конечно, меняет дело.
Если YOLOv4 запустить хотя бы с batch=4, то мы уже получаем более 400 FPS на той же RTX 2080Ti, с гораздо большей точностью чем у D0Ну, в варианте выше, как я понимаю, mixed precision использовался, быстродействие в нём мне не известно, но всё-таки с fp16, наверное, напрямую трудно сравнивать. Хотя Вы правы, разница тут, в общем, очевидна.
— MobileNetv3 — оптимальна только для CPU / мобильных-CPU / устройств 5-летней давности
— YOLOv4 full/tiny — оптимальна для GPU и NPU/VPU/TPU
— EfficientDet — ни для чего не оптимальна
5. Google это коммерческая компания, с большими зарплатами, которые там не платят просто за написание статьи. Сказать что им не важна скорость — это сказать, что им не важны деньги.Без всякого сарказма: у Вас есть объяснение тому, что при всём при этом разработки архитектур EfficientDet и MobileNetv3 вообще покинули стены лаборатории? Я в своих оценках могу основываться только на результатах, приведённых в статьях, которые, по Вашим словам, местами, мягко говоря, не без предвзятости (о чём, в общем, и в других источниках время от времени упоминается), хотя архитектурные решения EfficientDet мне кажутся элегантными. Неужели NIH-синдром? И считаете ли Вы базовую модель, EfficientNet, также не совсем удачной или с ней дела лучше?
коммент ниже
В гугле работают десятки команд (если не сотни конечно), причём многие параллельно над одними и теми же задачами. Конечно же, совершенно точно, что многие из них работают над перспективными направлениями, без ожидания вот прямо сейчас коммерческой отдачи. Многие вещи делают просто как proof of concept.Согласен, внешне подчас так всё и выглядит. Мой вопрос был связан с тем, что из оценок Алексея можно сделать вывод, что представляемые отличительные особенности последних MobileNet и EfficientDet выглядят не просто спорно, а и чем-то близким к тупиковому пути развития, что, следуя этой мысли, могло быть очевидно ещё в процессе работы над моделями. У меня нет возможностей и наработок проверить на практике приведённые результаты, поэтому было интересно узнать, чем, согласно этому мнению, вообще руководствовались авторы. Думаю, мы все видели и очень высокие оценки, к примеру, EfficientDet, многие взялись за реализацию и применение, но было бы неудивительно, если бы это оказалось лишь следствием популярности, мощи и авторитета Google в этой области, да и разговоры о правдивости результатов в публикациях в целом по-прежнему идут, поэтому и с критическими отзывами полезно подробно ознакомиться.
И, я готов поспорить, что с высоты гугла yolo (особенно с учётом того, как её исторически трудно было тренировать, и из-за использования, скажем так, специфического и редкого фреймворка даркнет) — это просто одна из редких сеточек для детекции, которой кто-то где-то далеко наверное пользуется, но которая не стоит усилий, чтобы с ней детально сравниваться.Я имею очень мало опыта работы с YOLO, и, честно говоря, не испытываю к ней особенного интереса, но мне она вовсе не кажется каким-то малозаметным изобретением, не говоря уже о том, что, если я не ошибаюсь, современная история однотактных моделей локализации объектов, фактически, с неё и началась. Но в сути Вы, наверное, правы: мы видим только результаты, которые было решено раскрыть для широкой общественности, а цели, которые перед собой ставят команды таких больших и авторитетных компаний могут быть совершенно различными.
4. На GPU (и Jetson) ещё больше проблем с Grouped/Depthwise-conv используемых в EfficientDet.
— MobileNetv3-small — 16.1% AP arxiv.org/pdf/1905.02244v5.pdf
— YOLOv4-416 — 41.2% AP и 30 FPS на Jetson Xavier AGX если запустить на OpenCV или tkDNN-TesnorRT batch=1
Результаты на AGX Xavier, полагаю, для int8?
Везде FP32/16. Если использовать int8, то надо и точность для int8 писать.
И не особо важно, как что-то работает на старой Jetson Nano (Maxwell), гораздо важнее как что-то работает на современных Jetson Xavier / TPU-Edge / Intel Myriad X и на будущих устройствах.
Очень любопытно, спасибо, что уточнили! Я, увидев FPS, сразу неявно предположил, что действительно с batch-size=1 указано, а так это, конечно, меняет дело.
На это и расчет.
— MobileNetv3 — оптимальна только для CPU / мобильных-CPU / устройств 5-летней давности
— YOLOv4 full/tiny — оптимальна для GPU и NPU/VPU/TPU
— EfficientDet — ни для чего не оптимальна
5. Google это коммерческая компания, с большими зарплатами, которые там не платят просто за написание статьи. Сказать что им не важна скорость — это сказать, что им не важны деньги.
Без всякого сарказма: у Вас есть объяснение тому, что при всём при этом разработки архитектур EfficientDet и MobileNetv3 вообще покинули стены лаборатории? Я в своих оценках могу основываться только на результатах, приведённых в статьях, которые, по Вашим словам, местами, мягко говоря, не без предвзятости (о чём, в общем, и в других источниках время от времени упоминается), хотя архитектурные решения EfficientDet мне кажутся элегантными. Неужели NIH-синдром? И считаете ли Вы базовую модель, EfficientNet, также не совсем удачной или с ней дела лучше?
1. А вы как думаете, почему они сначала написали, а потом удалили из своей статьи FPS/latency для Yolov3?
2. И почему EfficientDet и MobileNetv3 вообще покинули стены лаборатории?
На NAS-сети потратили десятки миллионов долларов на разработки и TPU для AutoML / Hyper-parameter Tuning.
Плюс надеются, что grouped/depthwise-conv когда-то все таки оптимизируют именно на NPU, а не на GPU, поэтому и мы от этого полностью не отказываемся, о чем и написали в статье.
Все данные в статье EfficientDet верны, и там написано, что EfficientDet не лучше, чем старая Yolov3, просто большинство людей читать не умеют — на это и расчет )
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Новая архитектура нейросети — EfficientDet