DETR: Бесконечная история

Введение

Всем привет, с вами команда Layer!
Мы рады сообщить, что совсем скоро выйдет наша новая исследовательская работа, посвященная поиску моментов в видео, релевантных пользовательскому запросу. Мы хотим сделать эту работу как можно более доступной для каждого, кто хочет глубже разобраться в теме. Поэтому решили написать этот небольшой туториал, посвященный семейству моделей DETR, так как они используются не только для детекции котиков на картинках, но и в таких необычных доменах, как детекция моментов в видео. Мы уверены, что среди читателей многие знакомы с основами DETR, однако подозреваем, что не все могли следить за его развитием. Всё‑таки по сравнению с YOLO, DETRу пиара явно не достает. В этой статье мы предлагаем краткий обзор эволюции модели, чтобы помочь вам лучше ориентироваться в новых исследованиях. Если же вы впервые слышите о DETR или хотите освежить свои знания, то бегом читать — тык, если после прочтения остались вопросы, то можно ознакомиться с этими видео — тык, тык.

Давайте детальнее разберёмся, что ждёт вас в этом туториале. Сначала мы рассмотрим недостатки оригинальной версии DETR, а затем перейдём к архитектурным улучшениям, которые либо устранили эти проблемы, либо заметно их сгладили. Начнём с Deformable DETR — модели, которая оптимизировала вычисления. Затем обратим внимание на Conditional DETR и DAB DETR — архитектуры, которые существенно переосмыслили роль queries в модели. Далее мы погрузимся в особенности DN‑DETR, который стабилизирует one‑to‑one matching. После этого детально разберём DINO DETR — модель, которая объединяет и улучшает идеи DN‑DETR и DAB‑DETR, а также переизобретает RPN для детекционных трансформеров. И в завершение нашего путешествия мы познакомимся с CO‑DETR, который объединил классические детекторы, такие как ATSS, Faster RCNN, и модели типа DETR, установив новые SOTA метрики на COCO.

Недостатки Vanilla DETR

Итак, начнём с перечисления недостатков архитектуры, которая была предложена Николасом Кэррионом и Франциско Массой в 2020 году.

1. Авторы адаптировали архитектуру трансформера для решения задачи детекции. Другими словами, мы начали полагаться на механизм внимания, а следовательно, добро пожаловать в мир квадратичной сложности по входной последовательности. Важно понимать, что при детекции существует прямая зависимость между разрешением входного изображения и качеством распознавания на выходе, особенно когда речь идёт о маленьких объектах. Следовательно, в общем случае мы хотим подавать картинки в высоком разрешении. Кроме того, необходимо использовать FPN для анализа изображений на различных масштабах. Однако если использовать и картинки в высоком разрешении, и FPN, то количество токенов, которые приходят на вход в механизм внимания, становится слишком большим. Поэтому авторы в ванильной имплементации отказались от использования FPN. В итоге, при сравнении DETR с Faster RCNN удалось существенно повысить качество распознавания крупных объектов ( +7.8), но сильно пострадало качество детекции маленьких объектов ( -5.5).

2. Ещё один значительный недостаток — долгое схождение модели: требуется около 500 эпох, чтобы добиться хорошего качества, в то время как Faster RCNN сходится примерно за 100. Этот недостаток нельзя однозначно связать с какой‑то одной архитектурной особенностью; скорее, это результат совместного влияния всех блоков модели. Тем не менее особую роль в этом сыграли стандартный self‑attention в энкодере и случайно инициализированные queries в декодере.

3. Следующая проблема не столь очевидна, как предыдущие, и связана с нестабильностью в работе one‑to‑one матчинга. Оказывается, что в начале обучения довольно распространена следующая картина: отдельно взятый query на эпохе N матчится на объект А, а на эпохе N+1 — на объект B, который сильно отличается от А. Понятно, что такое поведение не добавляет устойчивости схождению сети.

4. Ещё более неочевидная проблема также связана с one‑to‑one матчингом. Было показано, что, сопоставляя каждому query только один объект, мы довольно сильно разрежаем позитивный сигнал, который доходит до энкодера. Это приводит к тому, что признаки, порождаемые энкодером, становятся менее дискриминативными.

Теперь, когда мы понимаем, какие недостатки были заложены в архитектуру ванильного DETR, давайте посмотрим, как они были исправлены в более поздних работах.

Deformable DETR

Первой работой, которую мы рассмотрим, будет Deformable DETR. Ознакомиться с ней можно по этой ссылке. К сожалению, формат этой статьи не позволяет нам подробно разобрать работу, однако мы сосредоточимся на главной идее, которая сделала её популярной среди исследователей. Сюйчжоу Чжу и Вэйцзе Су предложили модификацию механизма внимания, которая приближает вычислительную сложность традиционного self‑attention к линейной. Таким образом, решается первая из описанных выше проблем ванильного DETR. Теперь мы можем спокойно подавать в модель изображения с высоким разрешением, а также использовать FPN.

Давайте на пальцах разберёмся, как это работает. В традиционном self‑attention (например, в оригинальном DETR) для каждого элемента внимание вычисляется по всем возможным элементам входа. Это приводит к квадратичной вычислительной сложности, что особенно проблематично для изображений с большим количеством пикселей.

Deformable Attention решает эту проблему, фокусируясь не на всём изображении, а на небольшом, но важном подмножестве точек (или ключей). Эти точки выбираются динамически для каждого элемента на основе их пространственной значимости.

Посмотрим на картинку, описывающую Deformable Attention, приведённую выше. У нас есть исходная карта признаков (Input Feature Map), которую мы получили, прогнав изображение через энкодер (и, возможно, через FPN). Также есть та же карта признаков, но к каждому её элементу добавлен позиционный эмбеддинг, — так формируются Query Features.

Для каждого запроса (query) из Queries Features, механизм Deformable Attention выбирает предзаданное количество ключевых точек (sampling points) из Input Feature Map, а если точнее из проекций этой Feature Map, которые мы получаем, пропуская ее через M независимых линейных слоев, где M — это количество голов. Эти точки выбираются на основе предсказанных смещений относительно позиции запроса. Смещения (offsets) динамически вычисляются с помощью MLP блока или просто линейного слоя. Получается, что Deformable Attention позволяет динамически адаптировать фокус внимания к различным масштабам и положениям объектов, что улучшает способность модели к детекции объектов разных размеров и в разных местах изображения.

Для каждой из выбранных точек вычисляется коэффициент внимания. Эти коэффициенты определяют, насколько каждая точка важна для данного запроса. После вычисления внимания по выбранным точкам, признаковые значения этих точек взвешиваются согласно коэффициентам внимания для формирования выходного признака для данного запроса.

Описанная архитектура механизма внимания существенно ускоряет инференс сети, снижает количество эпох, необходимых для сходимости модели, а также повышает качество распознавания всех объектов, особенно улучшая метрики для маленьких объектов.

Кроме того, авторы использовали iterative bounding box refinement, где каждый уровень декодера подправляет боксы на основе предыдущих прогнозов. Они также предложили two‑stage вариант Deformable DETR: сначала энкодер делает первичные предсказания, а затем декодер доводит их до финального результата, используя предсказания энкодера в качестве queries. Эта идея впоследствии будет усовершенствована в статье DINO DETR.

DAB DETR

Далее перейдем к рассмотрению двух работ, которые тесно связаны между собой: Conditional DETR и DAB DETR. Фактически, DAB DETR является своего рода продолжением идей, заложенных в Conditional DETR, поэтому в этом разборе мы уделим больше внимания именно DAB DETR.

Авторы этих работ пытаются решить вторую проблему vanilla DETR — очень долгое схождение. В DAB DETR выдвигаются две гипотезы, которые могут объяснить, почему модель медленно сходится при использовании механизма cross‑attention с обучаемыми queries в декодере:

1. Самый очевидный вариант — модели просто сложно выучить правильные queries, так как это сложная оптимизационная задача.

2. Более интересный вариант — существует разница в способе кодирования позиционной информации в обученных queries по сравнению с синусоидальным позиционным кодированием, которое используется для признаков изображения.

Для проверки первой гипотезы авторы обучают DETR с нуля, извлекают из него обученные queries, заново инициализируют веса модели, но в качестве queries используют веса, полученные с предыдущей итерации, и замораживают их. Далее, если гипотеза 1 верна, модель должна сходиться быстрее, так как queries уже выучены. Однако, как видно на картинке ниже, модель обучается так же долго, как и раньше. Следовательно, гипотеза не подтверждается.

Далее проверяется вторая гипотеза. Авторы визуализируют позиционное внимание между позиционными queries и позиционными keys в блоке cross‑attention декодера DETR, Conditional DETR и DAB‑DETR.

Карты внимания оригинальной модели могут смотреть куда угодно и быть сложной формы. В Conditional DETR позиционные эмбеддинги queries закодированы так же, как и позиционные эмбеддинги для image features, а также содержат информацию о центре объекта. Видно, что они представляют собой некоторые гауссианы, которые довольно чётко концентрируются на объектах. В DAB DETR также наблюдаются гауссианы, но они могут быть разного размера и, кроме того, вытянутыми по одному из измерений, поскольку, кроме центра объекта, также учитываются размеры объектов.

Давайте рассмотрим, что из себя представляют позиционные queries в DAB DETR. Вместо абстрактного вектора, который используется в vanilla DETR для позиционного query, мы используем старые добрые анкоры, которые представлены в виде координат центра объекта и его размеров: . Для того, чтобы прокидывать их в self‑attention или cross‑attention, используется синусоидальный энкодинг. Кроме того, в cross‑attention блоке мы не складываем позиционную часть эмбеддинга с контентной, как делали это ранее, а конкатенируем оба вектора. Так мы разделяем вклад content и positional частей в сходство между нашим query и фичей картинки. Кроме того, используя мы модулируем аттеншн, заставляя его учитывать масштаб объектов. В процессе декодирования анкоры обновляются, уточняя предположения модели о местоположении и размере объекта.

На рисунке ниже представлена детальная схема блока декодера DAB DETR. На первый взгляд она может показаться запутанной, но если вы будете держать в голове то, что только что прочитали, и немного разберётесь с текстом статьи, никаких проблем с пониманием возникнуть не должно.

Теперь можно посмотреть на следующую картинку: видно, что DAB DETR, как и Conditional DETR, обучаются примерно в 10 раз быстрее, чем vanilla DETR, и сходятся к более высоким метрикам.

DN-DAB-DETR

Теперь рассмотрим следующую модель, которая также направлена на решение проблемы медленного схождения DETR. Однако, в отличие от предыдущих подходов, которые в основном фокусировались на архитектуре модели, Фэн Ли и Хао Чжан предлагают новый взгляд на проблему. Они полагают, что причина медленного обучения кроется в нестабильности процесса сопоставления в двудольных графах. Иными словами, авторы утверждают, что проблема связана с дискретным характером механизма сопоставления объектов, который на начальных этапах обучения крайне нестабилен. В результате для одной и той же картинки один и тот же query может быть сопоставлен с совершенно разными объектами.

Авторы предлагают добавить в процесс обучения модели небольшую дополнительную задачу. Идея заключается в том, чтобы подавать в декодер зашумленные GT‑боксы и заставлять модель их денойзить. Хотя это не влияет на процесс матчинга напрямую, такая задача позволяет модели справляться с менее сложной задачей в начале обучения, что обеспечивает более плавное схождение.

Известно, что процесс обучения моделей DETR можно разделить на две основные стадии:

• Выучивание хороших анкоров.

• Выучивание хороших оффсетов для этих анкоров к объектам.

Проблема заключается в том, что на начальных этапах обучение нестабильно, и анкоры часто привязываются к различным объектам на разных позициях, что делает задачу обучения оффсетов особенно сложной. Здесь на помощь приходит задача денойзинга: зашумленные GT‑боксы можно воспринимать как «идеальные» анкоры. К тому же, оказывается, что при таком обучении оффсеты начинают обладать важным свойством — они становятся более локальными и не тянут анкоры к далеким объектам. Вот визуализация, которая демонстрирует вышеописанное:

На изображении слева представлены предсказанные оффсеты из DAB‑DETR, а на изображении справа — оффсеты из DN‑DAB‑DETR. Чем больше оффсет, тем краснее стрелка. Можно заметить, что на левом изображении красных стрелок значительно больше, чем на правом.

Кроме того, матчинг становится стабильнее. На картинке показано количество изменений в матчинге между двумя соседними эпохами.

Давайте кратко опишем архитектуру блока декодера модели. Авторы используют две группы queries. Первая группа идентична той, что используется в DAB‑DETR: она состоит из обучаемых анкоров и служит для решения задачи матчинга. Вторая группа — это денойз queries, которые состоят из зашумленных GT‑боксов. Эти queries не участвуют в матчинге, так как заранее известно, к какому боксу они должны быть привязаны. Авторы маскируют блок cross‑attention таким образом, чтобы денойз‑группы были изолированы друг от друга, тем самым предотвращается утечка информации.

DINO DETR

Статья DINO DETR, которую вы можете прочитать по этой ссылке, во многом повторяет разобранные выше работы, стоят на плечах гигантов, не иначе:) Загибаем пальцы:

1. Следуя подходу Deformable DETR, они применяют deformable attention из‑за его вычислительной эффективности.

2. Следуя подходу DAB‑DETR, они формулируют queries в декодере в виде динамических anchor boxes и поэтапно уточняют их на каждом слое декодера.

3. Следуя подходу DN‑DETR, они используют группы denoise queries при обучении, чтобы стабилизировать матчинг.

Однако авторы не останавливаются на достигнутом и развивают идеи коллег дальше.

Чтобы повысить точность one‑to‑one matching и улучшить способность модели предсказывать «нет объекта» для якорей, где объектов действительно нет, авторы вводят концепцию контрастных денойз‑групп. Внутри каждой такой группы на каждый таргет бокс накладываются два уровня шума: один слабее, другой — сильнее. После добавления шума к одному и тому же истинному боксу, бокс с меньшим уровнем шума отмечается как положительный, а с большим — как отрицательный. Этот механизм наглядно представлен на визуализации ниже.

Далее авторы дорабатывают идею использования RPN в архитектурах, подобных DETR. Как мы помним, авторы Deformable DETR уже пытались внедрить нечто подобное, однако результат оказался не самым успешным. А вот в DINO DETR удалось успешно интегрировать и запустить «RPN здорового человека». На рисунке ниже представлены три варианта инициализации queries.

В первом варианте queries инициализируются стандартно — статично. Во втором подходе обе части queries — как контентная, так и позиционная — инициализируются с помощью RPN. Однако оказалось, что наиболее эффективно оставлять контентные queries статичными, а использовать RPN исключительно для генерации позиционной части.

Что касается самой RPN, её архитектура довольно проста и включает всего несколько линейных слоёв. С их помощью мы предсказываем objectness score и координаты объекта. Затем, основываясь на objectness score, выбираем топ K предсказаний и передаём полученные координаты в декодер. Также применяем one‑to‑one matching и loss на выходы энкодера, аналогично тому, как это делается с выходами декодера.

И последняя особенность, которая была представлена в этой статье, — это подход Look Forward Twice. Суть его показана на картинке ниже.

Обычно, для стабилизации обучения, мы блокируем течение градиентов по референс‑поинтам (анкорам) от слоя к слою. Однако авторы предложили новую стратегию, позволяющую градиентам протекать через два слоя вместо одного. Ранее процесс выглядел следующим образом: мы брали изначальный анкор, пропускали его через слой декодера, получали уточнение для этого анкора, применяли его, и результат отправлялся в loss как выход слоя. Этот же результат затем поступал в следующий слой декодера, где градиенты блокировались, и процесс повторялся. Стратегия Look Forward Twice предполагает немного иной подход. Мы берём изначальный анкор, находим смещение и применяем его. Полученный результат отправляем в loss, а также создаём его копию с отрезанными градиентами. Эту копию передаём в следующий слой, находим для неё смещения и применяем их к анкору, у которого градиенты остаются активными, и уже его отправляем в loss. Далее процесс повторяется до тех пор, пока не кончатся слои декодера.

Казалось бы, на этом эволюция DETR‑моделей должна завершиться — ведь все ключевые проблемы архитектуры решены. Но, как оказалось, это ещё не конец.

CO-DETR

Давайте вспомним, что такое one‑to‑one matching. Это стратегия, при которой одному query соответствует только один объект. А теперь подумаем, к чему это может привести. Такая стратегия может существенно ослабить позитивный сигнал, который получают выходы из энкодера, что, в свою очередь, негативно сказывается на дискриминативной способности как энкодера, так и декодера. В своей статье DETRs with Collaborative Hybrid Assignments Training (CO‑DETR), доступной по ссылке, Чжуофан Зонг и Гуанлу Сун исследуют эту проблему и предлагают очень интересное решение.

Для начала давайте разберёмся, к чему приводит использование one‑to‑one matching. Представим, что мы обучили модель. Далее подаем на вход изображение и берём выходной слой из энкодера с размерностью CxHxW. Затем считаем L2-норму по оси C, что даст нам feature map размером HxW. Визуализируем полученный результат.

Далее поочерёдно применим несколько порогов thresholds к полученной карте признаков, посчитаем Intersection over Foreground и Intersection over Background для каждого порога, и получим следующие кривые:

Видно, что дискриминативная способность энкодера в моделях, использующих one‑to‑many matching, существенно выше. На основании этого авторы делают вывод, что в пайплайн нужно добавить дополнительные головы детекторов, которые будут обучаться по схеме one‑to‑many — например, ATSS или Faster R‑CNN, — и передавать достаточно позитивного сигнала в энкодер.

Кроме того, декодер также страдает из‑за недостаточного количества позитивных queries. Поэтому мы берем координаты позитивных анкоров, отобранных дополнительными головами, и передаем их в декодер в качестве позитивных запросов. В результате получаем SOTA‑детектор. Ура!

Послесловие

На этом мы завершаем наш краткий обзор моделей семейства DETR. В него не вошли статьи, направленные на ускорение модели, но теперь, когда у вас есть глубокое понимание базовых блоков, не должно возникнуть трудностей в изучении других работ, посвящённых этой замечательной архитектуре.

Если вам понравился этот разбор, подписывайтесь на телеграм‑канал нашей команды — тык, а, также, канал SberDevices — тык. Скоро там будет опубликована ссылка на работу, в которой мы использовали DETR‑like архитектуру для детекции релевантных пользовательскому запросу моментов в видео.

Спасибо за внимание!