Мы довели 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 млн параметров.
Четыре главных достижения
Наши ключевые результаты можно собрать в четыре пункта:
- Скорость работы.
- Скорость тренировки.
- Необходимое количество данных для тренировки.
- Ресурсная лёгкость модели.
И всё это — при «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). Это происходит как минимум по двум причинам.
- Число параметров.При огромном количестве параметров модели сложно свести решение к компактному набору правил, которые покрывают все изображения. В итоге многие правила дублируются в слегка разных формулировках, чтобы покрыть вариативность, и для этого нужны гигантские датасеты. Условная аналогия: вместо «глаза человека могут быть круглыми, овальными и вытянутыми» модель хранит сотни вариантов «глаза могут быть круглыми, но не слишком круглыми», «очень круглыми», «почти круглыми» и т.д.
- Тип исходных данных — сырые пиксели.Пиксели крайне нестабильны и плохо структурированы. Их трудно привести к устойчивому представлению, поэтому приходится компенсировать нестабильность размером датасета, чтобы модель не скатывалась в простые переобученные решения. Для количественного ощущения: один пиксель в RGB имеет 16.7 млн возможных значений. Типичный маленький объект в COCO — примерно 30×50 пикселей. Простое пространство значений такого прямоугольника — это уже 16.7 млн1500возможных комбинаций — и это только для самых маленьких объектов.
В TAPe‑подходе мы «перехватываем» изображение до этапа пикселей, приводя его к стабильным, структурированным элементам.Это уменьшает число необходимых параметров, потребность в данных и делает аннотацию человечески «подъёмной» даже для небольших команд.
Где мы сейчас и что дальше
На данный моментмы уже вышли на уровень лучших моделей детекции по ключевым метрикам, при этом:
- модель укладывается в <100k параметров,
- работает за 7–8 мс на изображение,
- занимает меньше мегабайта в оперативной памяти в покое,
- доучивается на новые классы за минуты и на десятке–двух картинок.
И при этом это только первая полноценная итерация TAPe‑детектора на COCO.Скорость, требование к данным и ресурсы уже близки к финальному виду, а точность детекции мы пока рассматривали как параллельную задачу, на которой получили «очень сильное начало», а не запечатанный результат.
Дальше очевидный вектор — дооптимизация боксов под mAP50‑95, более агрессивная работа с маленькими объектами и перенос этой архитектуры в реальные продакшен‑кейсы, где важна не только метрика, но и стоимость инфраструктуры и аннотации.
