В этом посте продолжаем дневник TAPe‑детекции на COCO: добавляем сегментацию по контрастным патчам на границе объектов, дорабатываем классификацию, избавляемся от learning rate и смотрим, как ведёт себя YOLO на нашем маленьком датасете.
Если вы тут впервые, сначала можно посмотреть:
-
базовую статью про TAPe+ML — TAPe + ML: универсальная архитектура компьютерного зрения
-
FAQ по TAPe‑детекции — FAQ по TAPe‑детекции объектов (как мы учимся детектить объекты одномоментно и в десятки раз эффективней/дешевле ML)
-
как TAPe чувствует себя против SOTA — Как наш “домашний” НИИ обошёл DINOv2, ViT и десятки ML‑моделей в видео‑разметке с помощью TAPe
-
предыдущие части dear дневника TAPe‑детекции на COCO:
Небольшое напоминание: что такое TAPe и зачем он нам
TAPe (Theory of Active Perception) — это математическая теория и технология, которая описывает (и моделирует) механизм активного восприятия: она разбивает изображение на устойчивые признаки и задаёт структуру связей между ними. В TAPe+ML мы используем эти элементы и далее работаем уже с ними, а не с сырыми пикселями.
В рамках TAPe+ML TAPe‑алгоритмы превращают изображение в элементы TAPe — структурированные “строительные блоки” с известными связями между ними, давая компактное векторное представление вместо сырых пикселей. На этих представлениях мы уже строим эксперименты: от self‑supervised задач в духе DINO/iBOT до классических ML‑методов (кластеризация, поиск, классификация) и детекции объектов на COCO, за которыми как раз следим в этом дневнике.
Поехали.
Сегментация по контрастным патчам на границе объектов
Добавили новую подзадачу, а именно: деление на сегменты через выбор контрастных патчей на границе объектов (настоящей границы, а не просто боксов), как ограничений самих объектов. Это стремительно улучшило результаты и в итоге получилось формировать адекватные объединения для каждого объекта.
Теперь – осталась задача классификации.
Архитектурные эксперименты, которые не “дружили” с TAPe‑данными
Много экспериментировали с разными архитектурными решениями: были попытки добавления новых голов и использования других подходов выбора похожих сегментов. Но они не увенчались успехом по простой причине того, что не “дружили” с TAPe-данными, потому что пытались их менять, нежели чем просто использовать.
Как превью результата, который получался на этом этапе при создании бокса:
Задание классификации расширит этот бокс, но как уже видно, обведение с контекстуальной стороны задачи отличное.
Классификация и проблема пропущенных сегментов
Решение задачи классификации оказалось чуть сложнее, чем ожидалось, но в любом случае достаточно “рутинная”.
Что сделало её сложнее – это локализованные случаи пропуска сегментов патчей. Так, иногда попадаются случаи, где один или несколько патчей не оказываются ассоциированы с нужным сегментом. Это в свою очередь приводит к тому, что их не получается классифицировать, потому что они условно ни на что не похожи. Эту проблему решали улучшением сегментации одновременно с классификацией – но это не должно было замедлить окончание задачи. Мы применили несколько улучшенный подход нахождения правильных связей между патчами для их объединения – а именно путём симуляции пошагового решения во время тренировки (то есть роста сегмента из 1 патча), для полного повтора того, что происходит во время инференции.
Связка с SSL и “неростущие” регионы
В целом решали задачу лучшей связки с SSL задачами, связанными с TAPe-подобными данными, параллельно дальше доводя архитектуру до лучшей связки. На данный момент единственная проблема, которая остается – это отсутствие роста некоторых регионов, что приводит к ошибкам классификации, по причине отсутствия достаточного контекста для ответа на вопрос “что это”. Эту проблему исправляем тем, что во время работы модели в таких случаях проверяются соседние регионы для сглаживания контекста.
Финальные штрихи архитектуры и подготовка демо
Это уже финальные работы для окончания архитектуры плюс её оптимизация для получения быстрой работы и возможности выкатить первое демо. Классификация отрабатывает хорошо, но также страдает в случаях маленьких сегментов, потому что оба действия (классификация и сегментация) тесно связаны. Есть большая вероятность, что работа с SSL задачами это исправит.
Каскадное избавление от гиперпараметров и отказ от learning rate
Улучшение работы сегментации в связке с классификацией выходит немного каскадной – в попытке избавиться от одного гиперпараметра, который что-то портит, приходится избавляться от нескольких, что позволяет приводить модель к более правильному виду. Например, избавлялись от зависимости от такой вещи как learning rate – то есть скорости обучения. Этот параметр всегда присутствует в градиентном спуске (именно он и контролирует насколько градиенты должны меняться), но при этом его подбор очень проблематичен – неправильный выбор (который меняется от эпохи к эпохе) грозит тому, что модель не сойдется, а вместо этого найдет локальное решение. Избавление от этого параметра привело к необходимости в очередной раз избавиться от градиентного спуска, что мы и сделали, использовав известные нам методы. Это также увеличило нашу точность классификации на 3%. На данный момент наша точность классификации 77%.
В YOLO этой информации нет конкретно (они говорят только о детекции), но в DETR – модели, которая является самой точной из моделей для решения COCO на данный момент времени, они отметили свою точность классификации как 79%. DETR использует напрямую предтренированный на ImageNet (и внутренних датасетах Meta*) DinoV2 для своего backbone, и уже на этой основе тренирует детекцию COCO. Сложно сказать, включает ли цифра в 79% ошибки детекции (они об этом не говорят), но это цифра на которую мы полагаемся.
Наша цель – улучшить классификацию до 80+% как минимум (не прогоняли пока полные тесты, они достаточно долгие, всё таки 100 тыс+ изображений).
Первые бенчмарки против YOLO
Также провели первые бенчмарк тесты, чтобы было прямое сравнение с YOLO. Интересная вещь, не уходя в конкретные цифры: YOLO не сходится совершенно для датасета, который мы используем для тестов. Напомним, что для тестов мы используем разделенный 70/30 датасет для тестов изображений COCO. То есть – 5 тыс. изображений, 3500 из них для тренировки, 1500 для тестов. Для COCO этого количества данных не хватает катастрофически – процент детекции на уровне ~1%.
Что дальше
Сегментация по границам объектов, классификация и отказ от градиентного спуска “сошлись” в одну TAPe‑модель, которая уже умеет детектировать объекты на COCO и работать на маленьком датасете, где YOLO просто не сходится. В следующем, финальном посте TAPe‑дневника соберём все результаты в одном месте: покажем базовые и COCO‑бенчмарки, сравнения с YOLO и RF‑DETR по точности (mAP50/mAP50‑95), скорости, числу параметров и требованиям к данным, а заодно чуть подробнее поговорим про аннотацию и то, почему нам хватает десятков изображений на класс там, где другим нужны сотни тысяч:)
Автор: oopatow
