TAPe‑дневник, день 8: сегментация по границам, 77% классификации и первые бенчмарки против YOLO

В этом посте продолжаем дневник TAPe‑детекции на COCO: добавляем сегментацию по контрастным патчам на границе объектов, дорабатываем классификацию, избавляемся от learning rate и смотрим, как ведёт себя YOLO на нашем маленьком датасете.

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

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

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

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

• предыдущие части dear дневника TAPe‑детекции на COCO:

  • День 1. TAPe и YOLO ^[4]

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

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

  • День 4. Датасет COCO. Начало. ^[7]

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

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

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

Небольшое напоминание: что такое TAPe и зачем он нам

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

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

Поехали.

Сегментация по контрастным патчам на границе объектов

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

Теперь – осталась задача классификации.

Архитектурные эксперименты, которые не “дружили” с TAPe‑данными

Много экспериментировали с разными архитектурными решениями: были попытки добавления новых голов и использования других подходов выбора похожих сегментов. Но они не увенчались успехом по простой причине того, что не “дружили” с TAPe-данными, потому что пытались их менять, нежели чем просто использовать.

Как превью результата, который получался на этом этапе при создании бокса:

Задание классификации расширит этот бокс, но как уже видно, обведение с контекстуальной стороны задачи отличное.

Классификация и проблема пропущенных сегментов

Решение задачи классификации оказалось чуть сложнее, чем ожидалось, но в любом случае достаточно “рутинная”.

Что сделало её сложнее – это локализованные случаи пропуска сегментов патчей. Так, иногда попадаются случаи, где один или несколько патчей не оказываются ассоциированы с нужным сегментом. Это в свою очередь приводит к тому, что их не получается классифицировать, потому что они условно ни на что не похожи. Эту проблему решали улучшением сегментации одновременно с классификацией – но это не должно было замедлить окончание задачи. Мы применили несколько улучшенный подход нахождения правильных связей между патчами для их объединения – а именно путём симуляции пошагового решения во время тренировки (то есть роста сегмента из 1 патча), для полного повтора того, что происходит во время инференции.

Связка с SSL и “неростущие” регионы

В целом решали задачу лучшей связки с SSL задачами, связанными с TAPe-подобными данными, параллельно дальше доводя архитектуру до лучшей связки. На данный момент единственная проблема, которая остается – это отсутствие роста некоторых регионов, что приводит к ошибкам классификации, по причине отсутствия достаточного контекста для ответа на вопрос “что это”. Эту проблему исправляем тем, что во время работы модели в таких случаях проверяются соседние регионы для сглаживания контекста.

Финальные штрихи архитектуры и подготовка демо

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

Каскадное избавление от гиперпараметров и отказ от learning rate

Улучшение работы сегментации в связке с классификацией выходит немного каскадной – в попытке избавиться от одного гиперпараметра, который что-то портит, приходится избавляться от нескольких, что позволяет приводить модель к более правильному виду. Например, избавлялись от зависимости от такой вещи как learning rate – то есть скорости обучения ^[12]. Этот параметр всегда присутствует в градиентном спуске (именно он и контролирует насколько градиенты должны меняться), но при этом его подбор очень проблематичен – неправильный выбор (который меняется от эпохи к эпохе) грозит тому, что модель не сойдется, а вместо этого найдет локальное решение. Избавление от этого параметра привело к необходимости в очередной раз избавиться от градиентного спуска, что мы и сделали, использовав известные нам методы. Это также увеличило нашу точность классификации на 3%. На данный момент наша точность классификации 77%.

В YOLO этой информации нет конкретно (они говорят только о детекции), но в DETR – модели, которая является самой точной из моделей для решения COCO на данный момент времени, они отметили свою точность классификации как 79%. DETR использует напрямую предтренированный на ImageNet (и внутренних датасетах Meta*) DinoV2 для своего backbone, и уже на этой основе тренирует детекцию COCO. Сложно сказать, включает ли цифра в 79% ошибки ^[13] детекции (они об этом не говорят), но это цифра на которую мы полагаемся.

Наша цель – улучшить классификацию до 80+% как минимум (не прогоняли пока полные тесты, они достаточно долгие, всё таки 100 тыс+ изображений).

Первые бенчмарки против YOLO

Также провели первые бенчмарк тесты, чтобы было прямое сравнение с YOLO. Интересная вещь, не уходя в конкретные цифры: YOLO не сходится совершенно для датасета, который мы используем для тестов. Напомним, что для тестов мы используем разделенный 70/30 датасет для тестов изображений COCO. То есть – 5 тыс. изображений, 3500 из них для тренировки, 1500 для тестов. Для COCO этого количества данных не хватает катастрофически – процент детекции на уровне ~1%.

Что дальше

Сегментация по границам объектов, классификация и отказ от градиентного спуска “сошлись” в одну TAPe‑модель, которая уже умеет детектировать объекты на COCO и работать на маленьком датасете, где YOLO просто не сходится. В следующем, финальном посте TAPe‑дневника соберём все результаты в одном месте: покажем базовые и COCO‑бенчмарки, сравнения с YOLO и RF‑DETR по точности (mAP50/mAP50‑95), скорости, числу параметров и требованиям к данным, а заодно чуть подробнее поговорим про аннотацию и то, почему нам хватает десятков изображений на класс там, где другим нужны сотни тысяч:)