TAPe‑дневник, день 6: синтетика, эмбеддинги и первый уход от трансформеров

В этой статье продолжаем онлайн‑дневник экспериментов с TAPe‑подходом к компьютерному зрению ^[1] на COCO. Здесь – про обучение ^[2] эмбеддингов на полностью синтетических TAPe‑данных, 74% точности классификации на 5k val‑изображениях и первые выводы о том, почему стандартные трансформеры нам не подходят.

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

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

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

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

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

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

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

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

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

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

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

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

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

Две задачи: эмбеддинги и классификация

Добились очень хорошего прогресса со стороны образования эмбеддингов – пока самый лучший результат из проводимых нами на COCO (но улучшений возможных очень много). Конкретно – тренировали модель на двух задачах. Одна для получения эмбедингов, другая – для классификации.

Эмбединги мы получаем из задачи, подобной iBOT, построенной полностью на синтетических данных, созданных по правилам TAPe. Современным моделям данных не хватает, но у нас такой проблемы нет: мы их просто сами генерируем, потому что работаем с структурированными данными изначально. Генеративные же модели работают с пикселями и не справляются с созданием реалистичных изображений, достаточных для решения задачи. Плюс изображения генерируются без подписей, где находятся контуры объектов, что делает их использование бесполезным – потому что все равно нужна ручная работа для отметок.

Классификационная задача классическая: имея описание патча в каком-то из видов (будь это несколько патчей, или один) – классифицировать как один из 80 классов COCO.

Маленький, но сложный COCO‑датасет

В нашем же случае, благодаря TAPe, мы позволяем модели научиться уже на первом этапе такому большому количеству структуры, что тренировка на задачах COCO (например), происходит быстро, а главное – сходится даже на маленьком количестве данных. К примеру, та же YOLO не сходится на 5 тыс. изображениях – для нее даже 100 тыс. изображений COCO недостаточно. Лучшую версию они тренируют заранее на датасете ImageNet, иначе их backbone просто не хватает данных. Мы же можем стандартную тренировку проводить вообще в обратную сторону: тренироваться на маленьком датасете, а затем проверять на большом, потому что структуры нам хватает.

Маленький датасет – сейчас это val-изображения датасета COCO, их всего 5 тыс.: 3,5 тыс. мы используем для тренировки и 1,5 тыс. – для проверки. Это помогает сразу получить хорошее распределение классов (для проверки все классы присутствуют в COCO), а также достаточно сложный датасет, потому что val всегда сложнее, чем train-изображения COCO, которых чуть больше 100 тыс..

Результаты: 82% реконструкции и 74% классификации

Первая задача во время тренировки сходилась очень хорошо, достигая точности условной реконструкции патча 82%. Это более чем достаточно для решения задач, но улучшать дальше можно и нужно. Но в первой версии пока так.

В классификации результат точности – 74%. Это тоже уже очень высокий процент, особенно для первой версии: у лучших моделей для COCO этот показатель около 79% (судя по их графикам).

Временная архитектура: стандартные трансформеры

В архитектуре присутствовали некоторые проблемы, но пути улучшения были понятны сразу. Проблемы состоят в том, что пока что используются стандартные трансформеры для связи между патчами – так намного быстрее экспериментировать. Эксперименты в общем-то и приводят к конечной архитектуре. Здесь дело больше в последовательности:

• Для выбора масштабного подхода намного проще использовать стандартные, пусть и не совсем правильные, архитектурные решения, чтобы удостовериться, что с масштабным подходом нет проблем и этот подход подводит к тому, что нам нужно;

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

Трансформеры известны в нашем случае как что-то, что очень портит сами данные (и очень медленные), но подходят для цели проверки подхода в наших экспериментах. В чем именно проблема с трансформерами? Если упрощать, то стандартно трансформеры/внимание – это три матрицы весов, между которыми происходит интерактив особым образом, для того, чтобы “рассказать” патчам данных о том, как выглядит каждый из них, и как они могут зависеть друг от друга (модели это и нужно разузнать в общем-то).

К тому же сходимость очень медленная по временным масштабам для полного датасета COCO (данные тяжелые). Плюс трансформеры подразумевают использование градиентного спуска (если конечно не идти в сторону RL, но RL – это отдельная ветвь, которая нам не очень нравится лично из логики), что понятное дело также вносит свои неудобства. При этом альтернатив RL, стандартно установленных, не так много.

Почему в TAPe внимание “лишнее” и что дальше

В нашем случае внимание ^[12] в конечном итоге как таковое не нужно, потому что в наших данных уже присутствуют зависимости патчей, но архитектурно всё равно нужно подумать о том, как это технически образовать.

В итоге мы планируем уйти от трансформеров к чему-то TAPe-пригодному, что не портило бы данные.