TAPe‑детекция против COCO и SOTA: как мы обошли RF‑DETR и YOLO, с легкостью уложившись в 100k параметров (вместо 100M)

Мы довели TAPe‑детекцию на COCO до уровня лучших SOTA‑моделей по точности, но с двумя порядками выигрыша по параметрам и радикально меньшими требованиями к данным и ресурсам. При этом модель держит 7–8 мс на изображение при mAP50 на уровне RF‑DETR‑2XL и работает почти одинаково быстро на GPU и CPU. В этом финальном посте нашего «дневника» мы подведем итоги эксперимента, покажем ключевые бенчмарки и объясним, почему TAPe‑подход позволяет реально экономить данные, железо и время разработки.

Если вы тут впервые, сначала можно посмотреть:

• базовую статью про TAPe+ML — TAPe + ML: универсальная архитектура компьютерного зрения

• FAQ по TAPe‑детекции — FAQ по TAPe‑детекции объектов (как мы учимся детектить объекты одномоментно и в десятки раз эффективней/дешевле ML)

• как TAPe чувствует себя против SOTA — Как наш «домашний» НИИ обошёл DINOv2, ViT и десятки ML‑моделей в видео‑разметке с помощью TAPe

Предыдущие части «дневника» TAPe‑детекции на COCO:

• День 1. TAPe и YOLO

• День 2. 115k параметров у нас vs 2 млн+ у YOLO

• День 3. Почему нам не нужен градиентный спуск

• День 4. Датасет COCO. Начало.

• День 5. 98% на 2% COCO, меньше “фона” и первые боксы

• День 6. Синтетика, эмбеддинги и первый уход от трансформеров

• День 7. Первый уход от трансформеров и “почти бесплатная” сегментация

• День 8. Сегментация по границам, 77% классификации и первые бенчмарки против YOLO

Этот текст — финальная часть дневника. Мы подвели TAPe‑детекцию на COCO до рабочего состояния, получили сравнимую с лучшими SOTA‑моделями точность и заодно проверили, насколько далеко можно уехать, если у вас не 100+ млн параметров, а сильно меньше 100k.

Немного напоминания: что такое TAPe и зачем он нам

TAPe (Theory of Active Perception) — это математическая теория и технология, которая описывает (и моделирует) механизм активного восприятия: она разбивает изображение на устойчивые признаки и задаёт структуру связей между ними. В TAPe+ML мы используем эти элементы и далее работаем уже с ними, а не с сырыми пикселями.

В рамках TAPe+ML TAPe‑алгоритмы превращают изображение в элементы TAPe — структурированные “строительные блоки” с известными связями, давая компактное, структурированное векторное представление вместо сырых пикселей, на котором уже можно строить self‑supervised задачи в духе DINO/iBOT, классические ML‑методы и детекцию объектов на COCO.

В итоговой детекционной модели у нас меньше 100 000 параметров — примерно в 10 раз меньше, чем у ближайших «облегчённых» моделей уровня YOLO, и примерно в 1000 раз меньше, чем у сильных DETR‑подходов вроде RF‑DETR с 127 млн параметров.

Четыре главных достижения

Наши ключевые результаты можно собрать в четыре пункта:

1. Скорость работы.

2. Скорость тренировки.

3. Необходимое количество данных для тренировки.

4. Ресурсная лёгкость модели.

И всё это — при «SOTA‑подобной» точности на COCO.

Приоритет этих пунктов зависит от сценария:

• 1‑й и 3‑й пункты критичны для небольших команд и стартапов, у которых нет ресурсов на собственные гигантские датасеты и парк дорогого железа.

• 2‑й и 4‑й пункты особенно важны для крупных компаний, интегрирующих модель в тяжёлую инфраструктуру (через API или локально) и считающих стоимость каждого процента загрузки GPU/CPU.

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

Базовые бенчмарки

Мы провели набор базовых бенчмарков, не завязанных на COCO‑метриках, а показывающих «поведение» модели.

1. Классификация без наведения (oracle)

Точность классификации без ошибки наведения (oracle‑классификация — когда бокс объекта уже корректен) достигает 87.3%. Это говорит о том, что TAPe‑эмбеддинги сами по себе несут достаточно информации, а задача классификатора уже относительно простая.

2. Детекция с классификацией

При детекции с классификацией (боксы + классы) точность ожидаемо ниже — 84.2%. Основная проблема — классы с маленькими объектами: их трудно идеально обвести, модель иногда просто «не видит» такие объекты.

Эта проблема есть и у YOLO, и у других моделей. Она исправима и, по нашим предварительным экспериментам и оценкам, не будет проявляться на кастомных классах: в COCO просто мало примеров маленьких объектов, поэтому качество их описаний хуже. Зато модель ведёт себя более консервативно и почти не даёт ложных срабатываний — это проще донастроить, чем сильно шумную модель.

3. Скорость работы

Скорость работы на GPU — в среднем около 157 кадров в секунду без какой‑либо серьёзной оптимизации кода под видеокарту.

На CPU скорость почти такая же — 134 кадра в секунду. Кроме того, на CPU мы можем обрабатывать батчи до 8 изображений без потери FPS: те же 134 обработки в секунду, но уже 1072 изображения в секунду. Дополнительные оптимизации тут точно возможны.

4. Потребление памяти

В состоянии покоя модель занимает меньше мегабайта оперативной памяти. Для сравнения:

• YOLO: минимум около 9.9 МБ, максимум — порядка 209 МБ.

• RF‑DETR: минимум ~116 МБ, максимум ~484 МБ.

Размер напрямую зависит от числа параметров, поэтому такая разница закономерна. В продакшене часто используют квантованные версии моделей (легче и быстрее примерно в 2 раза) — это релевантно для YOLO и RF‑DETR. Но из-за нашего подхода квантовка в целом не подходит – как минимум потому, что часть весов изначально уже в int8.    

Во время обработки необходимое количество памяти возрастает примерно на мегабайт на каждое изображение — этого достаточно, чтобы спокойно помещаться в L2/L3‑кэш современных процессоров. В YOLO и RF‑DETR эти цифры выглядят примерно так:

• YOLO26n: ~30 МБ

• YOLO26s: ~60 МБ

• YOLO26m: ~100 МБ

• YOLO26x: ~200 МБ

• RF‑DETR Nano/Med/Base: примерно 35–50 МБ

• RF‑DETR Large: примерно 70–100 МБ

5. Сколько данных нужно на новый класс

Мы отдельно померили чувствительность к количеству данных на новый класс. Лучший режим получился при:

• 20 изображениях для обучения нового класса;

• 10 изображениях для валидации.

20 изображений — реалистичное число (в COCO есть классы с таким количеством картинок). Важно, чтобы они были достаточно разнообразными, а не копиями одной сцены.

Мы проверяли это так: заново обучали модель на 75 классах и потом доучивали её на последних 5 классах. В этом режиме полная тренировка на новые классы занимает меньше минуты.

Бенчмарки на COCO

COCO‑бенчмарки заняли больше всего времени, потому что нужно было подвести формат выходов TAPe‑детектора под ожидаемый COCO интерфейс и аккуратно реализовать метрики.

Поведение по эпохам

Графики точности по эпохам:

Графики точности по эпохам выглядят ожидаемо, поэтому покажем только ключевые моменты:

• В oracle‑классификации начальная точность около 34% объясняется тем, что эмбеддинги TAPe уже содержат много информации ещё до того, как классификация учится под них.

• «Просадки» на ~50‑й и ~60‑й эпохах появляются из‑за градиентного спуска, который мы используем в классификации: мы намеренно «выбиваем» модель из слишком стабильного состояния, чтобы уйти из локальных минимумов.

Точность при дообучении на новых классах в среднем ровная между классами, но один класс — бутылки — из‑за маленького размера объектов оказался сложнее. На малом количестве изображений он тянул общую точность вниз и «догнал» остальные только при достаточном разнообразии примеров.

Метрики COCO: mAP50 и mAP50‑95

В детекции COCO используются две основные метрики: mAP50 и mAP50‑95.

• mAP50 — средняя точность детекции при пересечении предсказанного бокса с GT‑боксом не меньше 50%. Эту метрику понижают и ложные срабатывания, и ошибки по классу.

• mAP50‑95 — усреднение mAP по порогам IoU от 50% до 95% с шагом 5%. Чтобы иметь высокие значения по этой метрике, нужно попадать боксами почти пиксель‑в‑пиксель в разметку COCO.

Наш результат:

• mAP50 = 78.1% — примерно на уровне RF‑DETR‑2XL (78.5%). У YOLO эта метрика заметно ниже, около 69%.

• mAP50‑95 ≈ 58.9% — примерно на уровне YOLO26X. У RF‑DETR лучший результат — около 60.1%, мы немного ниже.

Мы специально не оптимизировали модель под сверхточное совпадение боксов с COCO: наша цель в этой итерации — показать, что можно выйти на SOTA‑уровень по mAP50, оставаясь радикально легче и быстрее. Подгонка под mAP50‑95 — задача следующих версий.

Где TAPe выигрывает однозначно

Самый однозначный выигрыш — во времени исполнения и ресурсах.

Мы выигрываем за счёт:

• низкого числа параметров,

• TAPe‑данных, позволяющих считать патчи в O(1) относительно размера изображения,

• очень малого числа слоёв, что убирает глубокую «пошаговость» и даёт плоский, быстро считаемый пайплайн.

В среднем время исполнения у нашей модели — 7–8 мс на изображение. У YOLO26X — 500+ мс в сопоставимых условиях. На самых маленьких вариантах YOLO время на GPU может быть лучше (до ~2 мс), но мы держим 7–8 мс там, где точность уже сравнима с тяжёлыми моделями, которым нужно ~500 мс.

Аннотация данных и зачем вообще всеми этим заниматься

Сейчас одна из главных проблем в ML в целом: большим моделям катастрофически не хватает данных. Чтобы выжать максимум из DINO‑подобных моделей, нужны монструозные датасеты.

Например, DINO‑модели Meta (запрещена в РФ) обучаются на собственном датасете в 142 млн изображений (против 1 млн в классическом ImageNet). Это происходит как минимум по двум причинам.

1. Число параметров.
   При огромном количестве параметров модели сложно свести решение к компактному набору правил, которые покрывают все изображения. В итоге многие правила дублируются в слегка разных формулировках, чтобы покрыть вариативность, и для этого нужны гигантские датасеты. Условная аналогия: вместо «глаза человека могут быть круглыми, овальными и вытянутыми» модель хранит сотни вариантов «глаза могут быть круглыми, но не слишком круглыми», «очень круглыми», «почти круглыми» и т.д.

2. Тип исходных данных — сырые пиксели.
   Пиксели крайне нестабильны и плохо структурированы. Их трудно привести к устойчивому представлению, поэтому приходится компенсировать нестабильность размером датасета, чтобы модель не скатывалась в простые переобученные решения. Для количественного ощущения: один пиксель в RGB имеет 16.7 млн возможных значений. Типичный маленький объект в COCO — примерно 30×50 пикселей. Простое пространство значений такого прямоугольника — это уже 16.7 млн¹⁵⁰⁰ возможных комбинаций — и это только для самых маленьких объектов.

В TAPe‑подходе мы «перехватываем» изображение до этапа пикселей, приводя его к стабильным, структурированным элементам. Это уменьшает число необходимых параметров, потребность в данных и делает аннотацию человечески «подъёмной» даже для небольших команд.

Где мы сейчас и что дальше

На данный момент мы уже вышли на уровень лучших моделей детекции по ключевым метрикам, при этом:

• модель укладывается в <100k параметров,

• работает за 7–8 мс на изображение,

• занимает меньше мегабайта в оперативной памяти в покое,

• доучивается на новые классы за минуты и на десятке–двух картинок.

И при этом это только первая полноценная итерация TAPe‑детектора на COCO. Скорость, требование к данным и ресурсы уже близки к финальному виду, а точность детекции мы пока рассматривали как параллельную задачу, на которой получили «очень сильное начало», а не запечатанный результат.

Дальше очевидный вектор — дооптимизация боксов под mAP50‑95, более агрессивная работа с маленькими объектами и перенос этой архитектуры в реальные продакшен‑кейсы, где важна не только метрика, но и стоимость инфраструктуры и аннотации.