Мы собрали модель, которая одновременно решает детекцию, классификацию и сегментацию, и при этом остается радикально легче и экономичнее по ресурсам, чем любые современные SOTA‑архитектуры. На COCO и RF100‑VL мы получаем качество детекции уровня крупных transformer‑детекторов при сотнях раз меньшем числе параметров, а на LVIS – покрытие и точность масок, недостижимые для YOLO‑семейства без переобучения, все это в режиме близком к real‑time на массовом железе.

В терминах «качество / параметры / латентность» наша модель находится в области, где у крупных конкурентов просто нет сопоставимых точек: либо они хуже по качеству при сопоставимой скорости, либо требуют на порядки больше параметров и железа, чтобы выйти на похожие цифры.

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

Дисклеймер

Мы уже рассказывали про TAPe+ML – наше единое ядро распознавания (единственное в мире), которое делает детекцию и классификацию на, скажем, новых единицах информации (мы их прозвали T-bits), гораздо информативней, чем сырые пиксели, при этом обходясь моделью размером меньше 100 тысяч параметров и показывая результаты, превосходящие SOTA. Следующим шагом мы закрыли последний пробел в нашей архитектуре – сегментацию. И сделали это не как отдельную надстройку, а как встроенную часть того же ядра.

Как устроена сегментация внутри TAPe+ML

Стандартный путь для большинства детекторов – иметь отдельную «голову» сегментации, которая либо генерирует маску из фиксированного набора прототипов (как в YOLO‑seg), либо использует полноценный transformer‑decoder (как в RF‑DETR‑Seg или Mask DINO). Обе схемы работают, но обе платят цену: либо разрешением маски, либо количеством параметров и латентностью. Мы можем себе позволить (потому что знаем его) другой путь – маски пиксельного уровня, без роста числа параметров и без отдельного тренировочного цикла.

В нашей архитектуре сегментация – это замена отдельной субмодели поиска заднего фона. Раньше эта субмодель просто отделяла «что не фон» от «что фон»; теперь она делает то же самое, но контурным образом – рисует замкнутые границы объектов на уровне пикселей, и именно эта область становится тем, на что «смотрят» остальные субмодели для наведения и классификации.

Субмодель сегментации работает в три этапа:

• Сначала на фичах backbone отмечаются все потенциальные границы изображения через обученный контекстный механизм, который восстанавливает даже слабые или размытые границы, если они контекстуально значимы (например, тень от объекта модель не считает границей, а слабо видимый край предмета на похожем по цвету фоне – считает).

• Дальше эти границы, по сути ломаные линии, объединяются в контуры. Если набор линий не складывается в замкнутый контур, он отбрасывается – модель не оставляет «висящих» и незамкнутых кусков.

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

Технически все это – отдельная голова сегментации, у промежуточных слоев которой во время тренировки есть свои дополнительные головы (для отдельной оптимизации каждого из трех этапов), а в инференсе все это отбрасывается – остается только финальный контурный выход. При этом маски строятся без привязки к конкретному классу объекта. Задача этой субмодели – найти осмысленные закрытые контуры вообще, а не выучить форму маски для каждого класса отдельно, как это часто устроено в детекторах с фиксированным набором категорий.

Один общий граф обучения для детекции и сегментации

Сегментация напрямую связана с остальными субмоделями TAPe+ML: у всей системы один общий loss с несколькими компонентами, и скоринг каждого компонента считается по своей отдельной задаче, но оптимизация идет совместно. Это значит, что обучение детекции автоматически обучает и сегментацию, и наоборот – без дополнительного тренировочного пайплайна и без дополнительных данных сверх того, что уже нужно для детекции.

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

Обратный эффект – объединение разрозненных сегментов. Если человек на фото стоит за перилами, сегментация видит несколько отдельных областей, разделенных перилами, а детекция использует эту информацию, чтобы понять, что это все же один объект, и нарисовать один общий bounding box.

В результате, обучая модель сегментации, мы улучшили показатели и детекции – которые и без того превосходили SOTA.

Почему мы выбрали LVIS, а не COCO

Для сегментации нам нужны были пиксель‑перфект маски, поэтому мы использовали LVIS как основной датасет для обучения масок. Маски в LVIS размечены с высокой точностью, без грубых аппроксимаций и без «наездов» полигонов друг на друга. В COCO instance segmentation маски исторически заданы упрощенными полигонами, которые не всегда идеально огибают контур объекта и иногда физически неправильно пересекаются между разными объектами – то есть сам датасет плохо подходит как эталон для тренировки точной по контуру сегментации.

Но у LVIS есть особенность: это федеративный датасет – на каждом изображении размечены не все объекты, только часть. Из-за этого нельзя просто взять «все, что не размечено» и считать это фоном: там могут быть реальные объекты, которые просто не попали в аннотацию. Поэтому LVIS дает нам только положительные маски (где точно есть граница объекта), а для отрицательных примеров (где границ точно быть не должно) мы использовали panoptic COCO – там все изображение разбито на сегменты полностью, без пропусков, и можно безопасно выбрать категории, в которых объектов нашего типа заведомо не может быть. Эта смешанная стратегия нужна только на этапе предтренировки backbone; после нее для дальнейшего обучения на новых датасетах уже не требуется повторять эти манипуляции – модель сохраняет зависимость от качества масок LVIS, но не от самого датасета LVIS.

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

LVIS: покрытие 97–98% объектов и точность масок на уровне AP@75

Наш результат на LVIS – 82.5% AP по LVIS‑методологии, посчитанный на связке val + minival сплитов. Minival мы включили в валидацию, чтобы не использовать его в тренировке, потому что minival – это валидационные изображения COCO, и тренировка на них привела бы к загрязнению результатов COCO. Мы не можем выделить minival как что-то, что мы использовали только для валидации, потому что val мы точно также используем только для валидации. 

Более наглядная и, на наш взгляд, более честная метрика – это не сам AP, а то, сколько объектов вообще получают осмысленную маску и с какой точностью. Мы сравнили себя с YOLO без дообучения на LVIS (то есть в равных условиях zero-shot по отношению к этому датасету), на одном и том же val-сплите (~25 тыс. изображений), с одной и той же метрикой Mask IoU / AP@75 (доля объектов, чья маска попадает в границы реального объекта с точностью IoU ≥ 0.75).

*Чуть выше конечных значений, потому что в IoU не включена классификация.

**Рост после дополнительной тренировки скромный именно потому, что стартовые значения уже высокие – основной прирост идет на маленьких объектах, где ошибка даже в один пиксель по контуру сразу превращается в десятки процентов потери IoU (просто потому, что у маленького объекта мало пикселей в принципе).

Причина такой разницы в покрытии в первую очередь архитектурная. YOLO‑seg строит маску не как самостоятельную сущность, а как комбинацию фиксированного набора обученных прототипов (в типичной конфигурации – 32 штуки), имеющих разрешение примерно в четверть от исходного изображения – то есть, например, 160×160 для входа 640×640. Дальше эта грубая прото-маска растягивается до финального разрешения. В сочетании со stride’ами feature map (обычно 2–4× сжатие на разных уровнях) итоговая точность границы масок у таких моделей оказывается в пределах примерно 8–16 пикселей – контур в этом смысле не «находится», а восстанавливается интерполяцией довольно грубой сетки. Наша модель работает по-другому: контур строится напрямую на пиксельном уровне через описанные выше три этапа, а не через растяжение прототипов, поэтому и получается принципиально другое покрытие и точность.

Результаты TAPeML на COCO и RF100‑VL: SOTA‑качество без SOTA‑размеров

Сегментация тренируется только на LVIS (плюс panoptic COCO для отрицательных примеров), но при этом переносится на другие датасеты без какой-либо дополнительной масочной разметки. 

Наша модель с сегментацией дает 85.2% mAP50 и 67.3% mAP50‑95 на COCO detection, а на RF100‑VL – 68.3% mAP50‑95 (единственная метрика, которая приводится в таблицах RF100‑VL). Для контекста: сильнейшая крупная модель из семейства RF‑DETR, RF‑DETR‑2XL, показывает 60.1% mAP50‑95 на COCO и 63.2% mAP50‑95 на RF100‑VL при значительно большем числе параметров (126.9M против ~0.1M у нас).

Наши цифры покрытия и точности контура (97–98% / 72–74%) считались по методике LVIS mask coverage / AP@75, а не по стандартной COCO instance segmentation Mask AP, которая используется, например, для RF‑DETR‑Seg (49.9% Mask AP на 2XL) или для крупных нереал-таймовых моделей типа Mask DINO Swin‑L (54.7% Mask AP) и Co‑DETR (57.1% Mask AP). Это разные метрики, измеряющие разные вещи, и прямое сопоставление «наш % против их Mask AP» было бы нечестным.

COCO Instance Segmentation: RF‑DETR, YOLO26 и TAPe+ML

На COCO instance segmentation мы сравниваемся с сильными real‑time моделями, которые специально позиционируются как SOTA по маскам: RF‑DETR‑Seg 2XL и YOLO26‑X‑Seg.

При тех же стандартных COCO‑метриках (Mask AP50 и Mask AP50‑95) наши числа выглядят так:

Эта таблица подчеркивает, что наша единая TAPe+ML‑модель с встроенной сегментацией дает заметно более высокий Mask AP как по AP50, так и по AP50‑95, чем специализированные крупные модели RF‑DETR‑Seg‑2XL и YOLO26‑X‑Seg, оставаясь при этом на порядок легче по числу параметров и ресурсам.

Скорость: 15 мс на весь пайплайн

Отдельная ценность нашей сегментации – она не платит за точность скоростью. Средняя скорость всего пайплайна (от входного изображения до финальных масок и боксов, включая backbone, детекцию, классификацию, сегментацию и постобработку) – около 15 мс. Измерения делались на изображениях в исходном разрешении COCO с ограничением по длинной стороне в 1024 пикселя (чтобы панорамные снимки не искажали статистику), на видеокарте GTX 1070Ti 8GB. На продовом CPU скорость остается примерно того же порядка, потому что вычисления параллелизируются похожим образом.

При увеличении числа объектов на сцене скорость падает, но незначительно – потому что все операции сегментации выполняются в рамках одного GPU‑kernel, а на CPU используется сопоставимая параллелизация. Это делает модель пригодной для edge‑ и онлайн‑сценариев, где нужна одновременно и точность контура, и реальное время отклика.

Сегментация в этой архитектуре не проверялась количественно на сценариях "только боксы, без масочной разметки" – качественная проверка устойчивости через отдельную модель классификации частей объекта существует, но формального числового бенчмарка для этого сценария в нашей фактуре нет.

TAPe+ML v3 можно проверить/потестить самостоятельно на стенде.