Этот текст не претендует на «академический» обзор TAPe и не заменяет будущие формальные бенчмарки на COCO‑подобных датасетах. Скорее это рабочие ответы на самые частые вопросы инженеров и исследователей, которые всерьёз присматриваются к проекту.
О чем речь
Мы делаем TAPe‑модель (вот здесь понятней, о чем речь: тыц, другой тыц) под задачи детекции объектов на COCO‑подобных данных, с возможностью добавлять свои классы и кастомизировать под конкретного заказчика. TAPe работает не с пикселями и не с жёсткой N×N‑сеткой, как YOLO, а с осмысленными регионами (патчами) в TAPe‑представлении. В экспериментах стремимся к тому, чтобы за один «ход» модель отсекала точно неинтересные области и выделяла кандидатов, где вообще есть смысл что‑то детектировать.
На маленьком датасете из 4 классов и 1256 изображений с частично шумной разметкой пилотный TAPe‑детектор с ≈115k параметров даёт 98.94% попаданий по объектам по прикладной метрике «центроид бокса в 32 пикселя от центра разметки», причём без аугментаций. В роли baseline’а брали YOLO11s (линейка Ultralytics/YOLOv8‑s): на том же датасете она плохо сходилась, давала низкую детекцию и много ложных срабатываний. Впрочем, выводы пока делать рано.
TAPe‑архитектура за несколько итераций ушла от громоздкого (для нас) dictionary‑подхода с 100k+ параметров к более компактной схеме без классического градиентного спуска: описания классов собираются из TAPe‑векторов и сжимаются через k‑means, а не обучаются как отдельная нейросеть. И это в том числе, кстати, позволяет нам обучать модель на CPU, а не GPU.
На подмножестве COCO (около 2% датасета, ~2400 изображений) эта же компактная модель без спецоптимизаций даёт 60.59% попаданий по центрам объектов — для такого размера детектора это неожиданно много и хороший аргумент в пользу того, что TAPe‑данные позволяют «маленьким» моделям сходиться там, где стандартные подходы ожидаемо захлёбываются.
Почему пишем
Пока работаем над демо-моделью, посильно ведем дневники разработчика. К нашим “TAPe‑дневникам” (раз, два, три, четыре) к нам в личку (в комментариях здесь пока не густо потому что никто ничего не понимает) прилетело много технических вопросов от наших потенциальных заказчиков/лидов/приятелей/фанатов: что именно мы детектируем, почему не считаем IoU/mAP, как устроен датасет и откуда взялись 98.94% «попаданий». Вместо того чтобы отвечать точечно и кусочно, собрали всё в одном месте — в формате компактного FAQ по текущему пилоту TAPe‑детекции объектов.
Собственно, FAQ
1. Какую задачу вы формально решаете: detection, segmentation или что‑то ещё?
По постановке задача ближе всего к instance segmentation. Нас интересует не только факт наличия нужного объекта на изображении, но и локализация его области: мы хотим понять, где именно он находится, а не просто ответить «есть/нет».
2. Что такое TAPe‑объект в этих экспериментах?
В этих экспериментах TAPe‑представление для детектора — это вектор, описывающий некоторый регион изображения, а не отдельный пиксель. То есть модель работает на уровне осмысленных областей (patch’ей/регионов), представленных TAPe‑векторами.
3. Почему вы не используете IoU/mAP и какую метрику качества применяете?
На данном датасете объекты маленькие, разметка местами неполная, а задача пилота формулируется как «нашли или не нашли объект на изображении», поэтому привычные IoU/mAP здесь не очень показательны.
Сейчас мы используем прикладную метрику:
-
считаем, что объект «найден», если центроид предсказанного бокса попадает в окрестность 32 пикселей от центра размеченного объекта;
-
средний размер объекта по диагонали — около 96 пикселей, так что 32 пикселя — это разумное окно вокруг центра;
-
итоговая цифра 98.94% — это accuracy по задаче «найден ли объект на изображении» при таком критерии, плюс контроль на отсутствие заведомо слишком больших боксов (чтобы модель не пыталась «закрасить всё»).
В более «академических» экспериментах (например, на COCO‑подобных выборках) планируем использовать классические IoU/mAP.
4. Как вы решаете, какие регионы «интересные», а какие нет? Что значит порог «80% похожести»?
Фильтр «интересный/неинтересный регион» основан на близости TAPe‑вектора к одному из прототипов искомого объекта.
-
Для каждого прототипа объекта есть эталонное TAPe‑описание.
-
Регион считается кандидатом, если его похожесть на прототип не ниже 80% по нашей внутренней TAPe‑метрике.
-
Во всех показанных бенчмарках порог стоял именно на 80%, что даёт высокое покрытие, но и заметное число ложных срабатываний.
Если поднимать порог, ложных срабатываний становится меньше, но модель пропускает больше объектов. Этот trade‑off мы отдельно изучаем и в будущем покажем как зависимость качества от порога.
5. Сколько параметров у детектора и почему цифры меняются?
Архитектура детектора активно развивалась, поэтому количество параметров менялось:
-
в первые дни это было 100k+ параметров сверх TAPe‑представления;
-
сейчас за счёт переработки архитектуры мы достигли в разы меньше числа параметров.
В экспериментах, описанных в ранних дневниках (Day 2), мы использовали условно TAPe‑эмбеддинги, полученные на основе TAPe-представлений и правил. Эти эмбеддинги применялись к изображению послойно: крупные патчи с перекрытием, затем рекурсивное «распадение» кандидатов на более мелкие патчи и т.д.
Этот подход уже признан далеким от идеала, и текущая архитектура существенно другая и компактнее. Для новых публичных сравнений (в том числе на других датасетах) будем использовать более «конечную» версию модели.
6. Что за датасет вы использовали для объектов?
-
4 класса;
-
1256 изображений;
-
стандартный split 70/30 (train/test);
-
miss‑images (картинки без нужных объектов) также входят в датасет и распределены по тому же принципу (70/30), учитываются при подсчёте ложных срабатываний.
Важно, что разметка неполная: на части изображений размечена только один объект, хотя фактически их несколько. Это делает классический градиентный спуск очень чувствительным к «шумным» лейблам, и это одна из причин, почему мы ушли от стандартного чисто нейросетевого training‑loop’a в пользу TAPe‑специфичных алгоритмов.
7. Почему вы почти не используете аугментации и как контролируете overfitting?
Аугментации помогают архитектурам на пикселях найти в них структуру, но при этом усложняют тренировку. У нас же структура есть изначально, её нужно только правильно показать.
На этом конкретном датасете аугментации ухудшали обучение: при таком небольшом объёме данных и специфике объектов они вносили больше шума, чем пользы. В то же время, отражение объектов по оси, например, или же маленькие повороты, уже покрываются смыслом TAPe-данных. Аугментации в некоем смысле только начали приводить к большему overfitting’у.
Overfitting мы контролируем жёстким разделением train/test (валидация не попадает в обучение), а также тем, что test‑часть включает примеры, значительно отличающиеся от train‑изображений.
8. Как именно YOLO «не справлялась» на вашем датасете?
В качестве baseline’а мы брали YOLO11s (линейка Ultralytics, ранее YOLOv8‑s) из официального репозитория Ultralytics, делали fine‑tuning на нашем датасете объектов.
На таком малом и частично шумном датасете YOLO плохо сходилась при обучении, показывала низкую детекцию и давала много ложных срабатываний.
Именно это мы имеем в виду под формулировкой «YOLO не справляется с задачей» в рамках данного пилота. Отдельно планируем оформить более формальные сравнения (mAP, Recall, FPS) на открытых или специально подготовленных датасетах, где YOLO/Detectron2 чувствуют себя привычнее.
9. Можно ли увидеть примеры правильных/ложных срабатываний TAPe‑модели и YOLO на одном и том же наборе изображений?
Да, это возможно. Вопрос только в том, какую версию архитектуры показывать:
-
ранние версии (100k+ параметров, dictionary‑подход);
-
или более новые, компактные, которые мы считаем «более конечными».
Плюс имеет смысл продублировать такой разбор на каком‑нибудь открытом или похожем датасете (например, на подмножестве COCO или близком по типу данных), чтобы любой желающий мог воспроизвести эксперимент. Правда, отвлекаться на такой пиар-маркетинг нам не хочется, ибо некогда. Но, возможно, иногда это необходимо. Подумаем.
Если вам интересны дополнительные технические детали (формальные метрики, сравнение с YOLO/Detectron2 на открытых бенчмарках, структура текущей модели), напишите в комментариях, какие именно аспекты стоит оформить в следующих техрепортах в первую очередь.
Автор: oopatow
