Отслеживание множества объектов в 2026 году – DeepSORT, ByteTrack, OC-SORT и трекеры, которые работают в рабочей системе

TL;DR

Отслеживание множества объектов (multi-object tracking, MOT) – задача сохранить один и тот же идентификатор за одним и тем же человеком, машиной или предметом на серии кадров видео – это связующая ткань между покадровым детектором объектов и любой функцией, которой нужно рассуждать о траектории. Почти каждая продакшен-система в 2026 году выбирает один из четырёх открытых трекеров: DeepSORT, классику 2017 года, которая ввела в обиход эмбеддинги внешнего вида; ByteTrack, рабочую лошадку 2022 года на одних только bounding box-ах с показателем MOTA 80.3 на MOT17; OC-SORT, трекер 2023 года на одной только моторике, который чинит поведение ByteTrack на нелинейных траекториях; и BoT-SORT, трекер 2022/2023 года, добавляющий компенсацию движения камеры и эмбеддинги внешнего вида поверх ByteTrack и ставший дефолтным трекером в Ultralytics YOLO. Самое важное решение – не «какой алгоритм взять», а «насколько силён ваш детектор»: каждый современный трекер управляется детектором, и слабый детектор не спасёт никакая хитрая ассоциация. Эта статья проходит по конвейеру tracking-by-detection, четырём семействам трекеров, метрикам, которые реально стоит оптимизировать (HOTA, а не MOTA), и четырём типичным ошибкам, которые мы в Фора Софт переоткрываем заново на каждом проекте, где shipим трекинг в видеоконференции, видеонаблюдение, спортивную аналитику, ритейл и OTT-продукты.

Почему это важно

Если вашему видеопродукту нужно что-то посчитать, проследить за чем-то или порассуждать о пути – вам нужен трекер. Система видеонаблюдения, считающая людей в дверях, должна отличать трёх разных людей, прошедших один раз, от одного человека, прошедшего трижды. Ритейл-аналитика, считающая dwell time, должна знать, что покупатель у полки с хлопьями на секунде 12 и покупатель там же на секунде 47 – это один и тот же человек. Спортивная трансляция, накладывающая имена игроков на баскетбольную площадку, должна знать, что тело в майке номер 23 в кадре 1 – это та же майка номер 23 в кадре 1500, даже если двадцать третий на полсекунды зашёл за двенадцатого. UI видеоконференции, подсвечивающий активного говорящего, должен удержать рамку на нужном лице, когда два человека поменялись местами. Все эти фичи под капотом – одна и та же задача multi-object tracking, и все они ломаются одним и тем же способом, если трекер ошибается. Технологии MOT существуют с 90-х, но выбор моделей, режимы отказов, паттерны развёртывания и метрики оценки сильно сдвинулись с 2022 года, а документация, которую инженер читает в первый день проекта, обычно отстаёт на три года. Эта статья даёт картину 2026: какой трекер выбрать, почему ByteTrack и OC-SORT заменили DeepSORT в роли дефолта, что измеряет HOTA из того, что MOTA пропускала десятилетие, и как избежать четырёх продакшен-ошибок, на которых тонет большинство развёртываний.

Что такое multi-object tracking на самом деле

Видео – это последовательность кадров. Детектор объектов – YOLO, RT-DETR, Grounding DINO, что вы выбрали в уроке об open-vocabulary детекции – запускается на каждом кадре независимо и выдаёт список bounding box-ов, каждый со своим классом и confidence-скором. Детекции в кадре 1 и детекции в кадре 2 – это для детектора независимые объекты: он не помнит, что видел мгновением раньше. Трекер сидит поверх детектора и сшивает покадровые детекции в траектории. У каждой траектории – стабильный track ID, маленькое целое число, говорящее «это тот же объект, что я видел на прошлом кадре». Track ID – это та самая связующая ткань, которая превращает последовательность списков детекций в список траекторий, с которыми может работать downstream-код.

Зачем это нужно? Потому что почти ни одна полезная видеофункция не работает на покадровых детекциях без идентификаторов. Нельзя посчитать машины, пересёкшие линию, без устойчивых ID – каждая машина была бы посчитана десятки раз, пересекая несколько кадров. Нельзя оценить теннисную подачу без устойчивых ID – непонятно, какая детекция принадлежит подающему, какая принимающему. Нельзя зафиксировать драку в потоке CCTV без устойчивых ID – правило «одни и те же два человека находились в метре друг от друга больше двух секунд» работает только при сохранении идентичности. Любая видео-ИИ-фича, связанная с движением, ожиданием, подсчётом, хореографией или взаимодействием, – это downstream трекера.

Задача звучит просто – сопоставить боксы в кадре t с боксами в кадре t+1, – но быстро становится сложной. Объекты загораживают друг друга; модель промахивается на отдельных кадрах; объекты двигаются неравномерно; камера двигается; два похожих объекта обмениваются ID; один объект распадается на две детекции; две детекции одного объекта слипаются. История MOT – это в основном история того, как становиться устойчивее ко всему перечисленному.

Нажмите, чтобы увеличить

Tracking-by-detection – конвейер, который победил

К 2022 году почти каждый опубликованный значимый трекер сошёлся к одному и тому же скелету – tracking-by-detection. У конвейера четыре этапа, и почти каждый современный трекер – это просто другой выбор на каждом из них.

Первый этап – детекция. Современный детектор выдаёт по одному bounding box на объект на кадр, с классом и confidence-скором. Качество детектора доминирует над всем downstream: трекер поверх детектора с recall 95 процентов и трекер поверх детектора с recall 80 процентов живут в разных вселенных, и зазор между ними гораздо больше любого алгоритмического выигрыша от ассоциации. Каждая статья после 2022 года репортит результаты трекера поверх фиксированного публичного детектора (часто YOLOX-X или сопоставимая модель) именно для того, чтобы сравнение измеряло качество трекера, а не детектора.

Второй этап – предсказание движения. Для каждого существующего трека трекер предсказывает, где объект окажется в следующем кадре, на основе истории движения. Канонический предсказатель – фильтр Калмана, алгоритм 1960 года, который моделирует состояние объекта (обычно (x, y, aspect_ratio, height, dx, dy, dh, dr)) как гауссиану с обновляемыми покадрово средним и ковариацией под моделью постоянной скорости. Современные трекеры все используют фильтр Калмана или ближайших родственников; различаются вектор состояния и шумовые параметры, а не сам алгоритм.

Третий этап – ассоциация. Имея предсказанные позиции треков и новые детекции, трекер вычисляет матрицу стоимости между каждым существующим треком и каждой новой детекцией, а затем решает задачу о назначении. Стоимость может быть геометрической (IoU между предсказанным боксом и боксом детекции), внешней (косинусное расстояние между глубокими признаками двух боксов) или взвешенной комбинацией. Назначение решает алгоритм Венгерского метода (Kuhn, 1955), который находит оптимальное матчинг один-к-одному за O(n³) и работает за микросекунды на тех масштабах, которые интересуют трекинг.

Четвёртый этап – управление жизненным циклом треков. Новые детекции, не привязавшиеся к существующим трекам, становятся новыми треками. Существующие треки, не нашедшие совпадения, помечаются неподтверждёнными, и после нескольких кадров неподтверждённости – убиваются. Только что родившиеся треки обычно помечаются tentative и должны пережить несколько кадров стабильной детекции, прежде чем стать confirmed. Параметры жизненного цикла – порог рождения, порог смерти, максимум неподтверждённых кадров – настройки, которые значат больше, чем обычно думают.

Каждый трекер ниже – это другой выбор внутри этого четырёхэтапного скелета. ByteTrack меняет, как применяется порог детекции на третьем этапе. OC-SORT меняет поведение фильтра Калмана после пропущенной детекции. DeepSORT добавляет глубокие признаки внешнего вида в матрицу стоимости. BoT-SORT добавляет компенсацию движения камеры в фильтр Калмана и эмбеддинги в стоимость. Скелет тот же; мышцы разные.

Четыре семейства трекеров, которые важны в 2026

Любое продакшен-развёртывание в 2026 году выбирает одно из четырёх открытых семейств. Идём в хронологическом порядке, потому что каждое следующее решало проблему, наследованную от предыдущего.

DeepSORT – классика 2017 года, давшая эмбеддинги внешнего вида

DeepSORT опубликован в 2017 году Николаем Вёйке, Алексом Бьюли и Дитрихом Паулюсом как расширение SORT (2016). Сам SORT – Simple Online and Realtime Tracking – был уже приличной базой: фильтр Калмана для предсказания движения, IoU-дистанция для ассоциации, венгерский алгоритм для матчинга. SORT работал на сотнях fps на CPU, но терял идентичности при перекрытиях, потому что использовал только геометрию. Вклад DeepSORT – добавить вторую матрицу стоимости поверх IoU: косинусное расстояние между глубокими свёрточными признаками внешнего вида детекции и галереей признаков каждого трека. Признаки внешнего вида извлекала маленькая CNN, обученная на person re-identification на датасете MARS. Результат – первый трекер, который удерживал идентичность через короткие перекрытия, и он доминировал в литературе следующие четыре года.

Показатели DeepSORT на MOT17 – стандартном бенчмарке pedestrian tracking – это 60.3 MOTA, 61.2 IDF1 и 48.8 HOTA в паре с сильным детектором YOLOX-X. Это цифры в современной форме (HOTA опубликован в 2020); сама метрика тогда ещё не существовала, но ретро-оценка – то, как поле сейчас сравнивает.

В 2026 году у DeepSORT две практические роли. Первая: это трекер, который использует каждый учебник, и тот, к которому первым тянется junior-инженер. Вторая: паттерн appearance-features, который он ввёл, – фундамент, на котором стоят BoT-SORT, StrongSORT и Deep OC-SORT. Оригинальный DeepSORT, однако, больше не дефолт для новых проектов. Трекеры 2022 года ниже бьют его по каждой метрике и одинаково просты в развёртывании.

ByteTrack – рабочая лошадка 2022 года на детекциях

ByteTrack опубликован на ECCV 2022 Ифу Чжаном и коллегами. Это самая влиятельная статья в tracking-by-detection после DeepSORT. Вклад обманчиво мал: ассоциируй каждую детекцию, а не только уверенные.

Каждый предыдущий трекер выкидывал детекции ниже порога confidence (обычно 0.5) до ассоциации. Наблюдение ByteTrack: низко-уверенные детекции – это обычно всё ещё реальные объекты, объекты, которые детектор «увидел еле-еле» из-за частичного перекрытия, motion blur или необычной позы. Выкидывание этих детекций отбрасывает ровно те боксы, которые трекеру нужнее всего для удержания идентичности через перекрытие. Процедура ByteTrack: сначала ассоциировать высоко-уверенные детекции с существующими треками по IoU; затем взять несопоставленные треки и попытаться сопоставить их с низко-уверенными детекциями, снова по IoU. Высоко-уверенные детекции без матча становятся новыми треками; низко-уверенные без матча отбрасываются.

Полный алгоритм – меньше пятидесяти строк Python. Никаких признаков внешнего вида, никакой глубокой нейросети, кроме самого детектора, никаких обучаемых компонентов. Просто меняется порядок использования детекций. Результат на MOT17 – 80.3 MOTA, 77.3 IDF1, 63.1 HOTA – побил каждый предыдущий трекер, включая DeepSORT, всех предшественников BoT-SORT и весь класс трекеров с appearance-эмбеддингами. Урок: детектор всё это время делал большую часть работы, и умный каскад по confidence-у улавливал большую часть оставшегося value.

ByteTrack – правильный дефолт для любого проекта, где детектор силён, объекты не сильно меняют внешний вид и в сцене нет агрессивного движения камеры. Он примерно вдвое быстрее DeepSORT (потому что не запускает feature-extractor) и в 3-5 раз быстрее BoT-SORT. Reference-реализация – github.com/ifzhang/ByteTrack под MIT, и она встроена в Ultralytics YOLO в виде bytetrack.yaml.

OC-SORT – трекер 2023 года, чинящий нелинейные траектории

OC-SORT – Observation-Centric SORT – опубликован на CVPR 2023 Цзинкуном Цао и коллегами. Статья называет конкретный режим отказа любого трекера на основе Калмана, включая ByteTrack: после нескольких кадров перекрытия предсказанная Калманом позиция дрейфует, потому что фильтр продолжает протаскивать предположение о постоянной скорости, пока нет новых наблюдений для коррекции. Когда объект вновь появляется и трекер должен ассоциировать его, предсказанная позиция уже уехала от истинной, и матчинг проваливается.

Решение OC-SORT – observation-centric re-update. Когда потерянный трек заново ассоциирован с детекцией после k кадров пропуска, трекер не просто обновляет Калмана новым наблюдением. Он возвращается, восстанавливает траекторию между последним наблюдением и новым, используя оба конца, и переобновляет фильтр так, будто всё это время видел согласованные наблюдения. Состояние в момент re-association основано на двух реальных концах разрыва, а не на дрейфующем предсказании. В статье также добавлен член observation-centric momentum, использующий направление недавних наблюдений прямо в матрице стоимости.

Цифры OC-SORT на MOT17 – 78.0 MOTA, 77.5 IDF1, 63.2 HOTA – сидят рядом с ByteTrack по заголовочным метрикам, но относительный прирост гораздо больше на бенчмарках с нелинейной моторикой. На DanceTrack, где встречаются акробатика и танец, нарушающие предположение о постоянной скорости, OC-SORT бьёт ByteTrack больше чем на десять HOTA-пунктов. Результат на DanceTrack – это тот, что важен для любого продукта с нелинейным движением: танцевальные уроки, гимнастика, паркур, дрон-съёмка, трекинг животных, всё, что в спортивной трансляции связано со сменами направления.

OC-SORT тоже не использует признаки внешнего вида. Как и ByteTrack, он управляется детектором и работает со скоростью самого детектора. Reference-реализация – github.com/noahcao/OC_SORT под MIT. Deep OC-SORT, расширение 2023 года от Маджолино и коллег, добавляет адаптивный признак внешнего вида сверху и достигает 64.9 HOTA на MOT17 – долгое время опубликованный SOTA.

BoT-SORT – трекер 2022 года, ставший дефолтом в Ultralytics

BoT-SORT опубликован в 2022 году Ниром Ахароном, Роем Орфайгом и Бен-Ционом Бобровским. Это, по словам авторов, «более сильный SORT» – построенный на том же скелете, что и ByteTrack, но с двумя апгрейдами. Первый – camera-motion compensation: перед применением Калмановой модели движения трекер оценивает, как камера сдвинулась между двумя кадрами (через разреженный оптический поток и алгоритм выравнивания изображений ECC), и трансформирует предсказанное состояние с поправкой на это смещение. Этот один шаг – то, что заставляет BoT-SORT работать на handheld и дрон-съёмках, где предположение о постоянной скорости ломается не из-за объектов, а из-за движущегося относительно объектов мира. Второй апгрейд – appearance embeddings: BoT-SORT-ReID, вариант с внешним видом, добавляет re-identification feature extractor (BoT-S50, обученный на стандартных датасетах person Re-ID) и добавляет appearance-cost к ассоциации.

Цифры BoT-SORT на MOT17 – 80.5 MOTA, 80.2 IDF1, 65.0 HOTA – на момент публикации SOTA по всем трём заголовочным метрикам. Reference-реализация – github.com/NirAharon/BoT-SORT под MIT. Гораздо важнее для продакшен-команд: c 2024 года BoT-SORT – дефолтный трекер в Ultralytics YOLO, конфиг лежит в ultralytics/cfg/trackers/botsort.yaml. Если вы зовёте model.track() на Ultralytics-модели без указания трекера – запускается BoT-SORT. Сообщество проголосовало: BoT-SORT-ReID – продакшен-дефолт для general-purpose pedestrian и vehicle tracking.

Цена – throughput. BoT-SORT-ReID примерно на 30 процентов медленнее ByteTrack из-за feature-extractor-а и оценки движения камеры. Для большинства продакшен-развёртываний эта надбавка приемлема – одиночный поток pedestrian/vehicle tracking на современном CPU всё ещё работает на 30+ fps, – но в плотных сценах или при многих одновременных потоках стоимость накапливается.

Нажмите, чтобы увеличить

Метрики, которые на самом деле важны – MOTA, IDF1 и почему HOTA пришла на смену

Десятилетие сообщество ранжировало трекеры по MOTA – Multiple Object Tracking Accuracy. MOTA введена в 2008 Бернардином и Штифельхагеном как одно число, объединяющее false positives, false negatives и identity switches. Метрика работала достаточно хорошо, чтобы стать заголовочной на MOTChallenge – доминирующем бенчмарке pedestrian tracking – и тем числом, которое видно сверху каждой статьи о трекерах с 2008 по 2020.

У MOTA был известный дефект: она сильно перекошена в сторону качества детекции. Трекер, идеально детектирующий, но обменивающийся идентификаторами на каждом перекрытии, набрал бы почти столько же, сколько трекер, никогда не путающий ID, – потому что член identity-switch в формуле MOTA мал по сравнению с членами false-positive и false-negative. Сообщество ответило, введя IDF1 – F1-меру по идентичности, которая наказывает обмены ID гораздо жёстче. IDF1 – правильная метрика для приложений, где идентичность критична (multi-target re-identification, трекинг конкретного человека), но она перешла в другую крайность: игнорировала качество детекции.

Развязка пришла в 2020 году с HOTA – Higher Order Tracking Accuracy, предложенной Джонатоном Луйтеном и коллегами. HOTA – это явная сбалансированная комбинация detection score (DetA, насколько хорошо трекер вообще детектирует) и association score (AssA, насколько хорошо он поддерживает идентичность между детекциями, попавшими на один и тот же ground-truth объект). Две части объединены геометрически – HOTA – это корень из DetA × AssA, – поэтому трекер с высоким одним и низким другим штрафуется. HOTA также репортит два sub-score отдельно, и статья может показать, по какой оси новый трекер прирос.

К 2026 году HOTA – метрика, по которой репортит поле. MOTA по-прежнему встречается в каждой таблице, но лидерборды MOTChallenge, DanceTrack и SportsMOT все ранжируют трекеры по HOTA. Если читать одну цифру из сравнения – читайте HOTA.

Цифры с лидерборда MOTChallenge (MOT17 test set, private detection) для четырёх обсуждаемых трекеров:

Цифры говорят то же, что сказано выше: ByteTrack и OC-SORT почти идентичны на MOT17; BoT-SORT-ReID на ступеньку выше; DeepSORT – историческая база. На DanceTrack история другая – OC-SORT уходит от ByteTrack на десять с лишним HOTA-пунктов. На SportsMOT BoT-SORT-ReID-овские appearance-features значат больше всего. Правильный трекер зависит от данных, а не от заголовочной строки лидерборда.

Выбор подходящего трекера – пошаговый разбор

Вот дерево решений, которое мы в Фора Софт используем, когда проект просит фичу трекинга. Четыре вопроса.

Первый вопрос: движется ли камера? Если камера на телефоне, дроне, body-cam, dashcam или любом подвижном креплении, фильтр Калмана с предположением о постоянной скорости в ядре ByteTrack и OC-SORT будет дрейфовать, потому что предсказания делаются в координатах изображения, а не мира. Camera-motion-compensation в BoT-SORT – лекарство. Берите BoT-SORT для любой подвижной камеры.

Второй вопрос: нарушает ли движение предположение о постоянной скорости? Танцы, гимнастика, паркур, движение животных, быстрый спорт, всё, где объекты резко меняют направление, ломает шаг предсказания Калмана. Observation-centric re-update в OC-SORT – лекарство. Берите OC-SORT для танцев, спорта, animal-tracking и любых сцен с резкими сменами направления.

Третий вопрос: сколько одновременных потоков и насколько плотна сцена? Трекеры на основе внешнего вида (BoT-SORT-ReID, Deep OC-SORT, StrongSORT) извлекают глубокий признак на каждую детекцию на каждом кадре. На CPU это доминирующая часть стоимости – BoT-SORT-ReID на шестнадцати потоках 1080p загружает сервер целиком. Если бюджет говорит «много потоков, скромное железо» – берите ByteTrack: он не делает appearance-работы, работает со скоростью детектора и правилен для плотной retail-аналитики и крупного видеонаблюдения.

Четвёртый вопрос: насколько важно сохранение идентичности через длинные перекрытия? Если приложение терпит короткие свопы ID (подсчёт машин, dwell time, плотность толпы) – motion-only трекеры (ByteTrack, OC-SORT) подходят. Если идентичность должна жить через пять и более секунд перекрытия (трекинг person-of-interest, спортивная графика, multi-camera handoff) – нужны трекеры на основе внешнего вида (BoT-SORT-ReID, Deep OC-SORT, StrongSORT). Берите BoT-SORT-ReID для удержания идентичности через длительные перекрытия.

По нашему опыту, восемьдесят процентов проектов приходят к ByteTrack (быстрейший, простейший, работает) или к BoT-SORT-ReID (чуть медленнее, точнее, дефолт Ultralytics). OC-SORT – особый случай. DeepSORT редко правильный ответ в 2026 – каждая задача, в которой он был хорош, теперь решена лучше одним из трёх перечисленных.

Численный пример – стоимость трекинга на видео 1280 × 720 при 30 fps

Считаем для одного потока на современном Intel-серверном CPU, с детектором YOLOv8-S и двадцатью пешеходами в кадре.

YOLOv8-S детекция (640 × 640 input, 20 детекций): ~14 миллисекунд на кадр. ByteTrack ассоциация (20 детекций, 20 активных треков): ~0.4 мс на кадр. BoT-SORT-ReID extraction внешних признаков (BoT-S50, 20 кропов): ~18 мс на кадр. BoT-SORT-ReID ассоциация: ~0.6 мс на кадр.

Итоги пайплайна на кадр: ByteTrack: 14 + 0.4 = 14.4 мс на кадр. BoT-SORT-ReID: 14 + 18 + 0.6 = 32.6 мс на кадр.

В секунду: ByteTrack = 432 мс CPU; BoT-SORT-ReID = 978 мс CPU.

Один поток ByteTrack использует ~43 процента одного ядра. Один поток BoT-SORT-ReID – почти целое ядро. Шестнадцатиядерный сервер тогда тянет тридцать пять одновременных ByteTrack-потоков или шестнадцать BoT-SORT-ReID. Разница падает прямо в облачный счёт: при ценах AWS c7i.4xlarge (16 vCPU, ~$0.71/час on-demand), ByteTrack стоит ~$0.020/поток-час, BoT-SORT-ReID – ~$0.044/поток-час. Обе цифры малы в абсолюте, но отношение становится важным при масштабе тысяч камер.

Если нужно больше потоков на сервер, правильный ход не «сменить трекер на лёгкий», а снизить fps трекинга. Большинство трекинг-фич (подсчёт, dwell, fall detection) прекрасно работают на 10 fps. Запуск трекера на каждом третьем кадре с интерполяцией ID между сокращает стоимость в 3× практически без потери точности.

Где запускать – браузер, edge или сервер

Решение о топологии развёртывания применяется к трекерам так же, как к моделям поз в уроке об отслеживании позы. Одну и ту же модель можно развернуть в трёх разных местах с тремя очень разными trade-off-ами.

В браузере трекер работает внутри вкладки пользователя в WebAssembly. Ни у одного из четырёх рассматриваемых трекеров нет first-party браузерной реализации, но ByteTrack и OC-SORT – motion-only и компактные – портированы на JavaScript и ONNX Runtime Web. Подходит для browser-based жестовых и эргономических фич. BoT-SORT-ReID с appearance-features в 2026 году слишком тяжёл для типичных браузерных бюджетов.

На edge трекер крутится на компактном устройстве рядом с камерой – NVIDIA Jetson Orin Nano, Intel NUC или Hailo-8L ИИ-ускоритель. Все четыре трекера комфортно влезают на Jetson Orin Nano рядом с детектором YOLOv8-S. ByteTrack – выбор по throughput (больше потоков на устройство). BoT-SORT-ReID – выбор по точности (один-два потока, но выше идентичность). Edge – дефолт для AI security camera, intelligent video analytics, ритейла и industrial computer vision.

На сервере трекер работает в облаке рядом с детектором. RT-DETR или YOLOv11 на GPU плюс ByteTrack или BoT-SORT-ReID на CPU – рабочая схема. Latency определяется сетевым round-trip (обычно 30-100 мс) плюс временем инференса. Серверный режим – дефолт для платформ спортивной аналитики, broadcast contribution, batch processing записанного материала и любых фич, которым нужны самые крупные детекторы.

Выбор между тремя обычно не близок. Use case диктует топологию, а топология диктует трекер.

Нажмите, чтобы увеличить

Четыре продакшен-ошибки, которые топят фичи трекинга

Мы в Фора Софт зашипили много трекинг-фич в видеопродукты. Четыре режима отказа всплывают раз за разом. Они не новые – каждая команда переоткрывает их, – но цена переоткрытия высока, поэтому стоит назвать их вслух.

Первая ошибка – винить трекер за то, что на самом деле проблема детектора. Когда трекер теряет идентичности или ошибается в подсчёте, инстинкт – менять трекер. Лечение обычно не в нём, а в детекторе. YOLOv8-N, обученный на COCO, упустит большинство мелких пешеходов на 1080p, и никакой трекер на свете не сошьёт идентичность через пропущенные детекции. Сначала всегда профилируйте детектор: если recall на ваших данных ниже девяноста процентов, чините детектор, прежде чем трогать трекер. Переход с ByteTrack на BoT-SORT-ReID добавит пару HOTA-пунктов; переход с YOLOv8-N на YOLOv8-X добавит десять.

Вторая ошибка – использование DeepSORT в 2026 году. DeepSORT был правильным ответом в 2018. Сейчас – редко. Каждая задача, на которой он был хорош, теперь решается лучше через ByteTrack (быстрее, точнее) или BoT-SORT-ReID (точнее, столь же прост в развёртывании). Причина выживаемости DeepSORT – тьюториалы, которые junior находит на первом проекте, обычно трёхлетние. Дефолт для новых проектов – ByteTrack; дефолт, если нужны appearance-features – BoT-SORT-ReID. Мы переписали DeepSORT-пайплайны в ByteTrack-пайплайны для трёх клиентов за последние два года, и каждый раз это был чистый апгрейд по latency, throughput и HOTA одновременно.

Третья ошибка – оставить гиперпараметры фильтра Калмана и lifecycle на дефолтах на данных, под которые трекер не настроен. Каждый рассмотренный трекер опубликован с гиперпараметрами, выкрученными под MOT17: пешеходы, преимущественно прямое движение, хорошее освещение, статичные камеры. Применяешь эту конфигурацию к дрон-съёмке спорта или к CCTV-машинам на шоссе – шумовые члены Калмана неверны, max-unconfirmed-frames неверен, appearance-threshold неверен. Лечение – тюнить. Конкретно: track_buffer (как долго потерянный трек жив на случай возвращения) и match_thresh (порог IoU для второго прохода ассоциации) – две ручки, двигающие больше всего. Мы привычно делаем grid-search по ним на отдельно взятой записи реального развёртывания перед shipом.

Четвёртая ошибка – доверять track ID на стыке камер. Track ID локален к одной камере и одному запуску трекера. Тот же человек, переходящий с камеры A на камеру B, получит разные ID от двух трекеров, и никакая ловкость single-camera-трекинга это не починит. Cross-camera identity – отдельная задача, person re-identification или multi-camera multi-target tracking, – она требует выделенной Re-ID модели, общей feature-галереи и глобального графового решателя. Мы покроем cross-camera в будущем уроке; пока – если ваше приложение пересекает камеры, не делайте вид, что single-camera трекер это умеет.

Нажмите, чтобы увеличить

Где здесь Фора Софт

Мы в Фора Софт зашипили трекинг в полдюжины категорий продуктов. В видеоконференциях используем лёгкий ByteTrack на стороне SFU для удержания устойчивых ID на участниках, меняющих ракурс камеры в середине звонка – ID питают downstream-фичи, такие как активный-говорящий и автоматические резюме встреч. В ритейле и intelligent video analytics используем BoT-SORT-ReID на Jetson edge-боксах для dwell-time, queue-length и out-of-stock-детекции – здесь важен внешний вид, потому что покупатели заслоняют друг друга и appearance-модель снимает идентификационную неоднозначность. В OTT и broadcast contribution – BoT-SORT-ReID на облачных GPU для спортивных оверлеев и трекинг-дэшбордов игроков, где перекрытия длиннее и ставки выше. В e-learning – ByteTrack для отслеживания нескольких студентов в видео класса с подачей траекторий в фичи мониторинга внимания. В видеонаблюдении и безопасности – BoT-SORT-ReID для детекции падений, драк и проникновений: appearance-features удерживают идентичность через длительные перекрытия на статичной камере. На каждом проекте трекер – это решение номер два; решения нулевое и первое – детектор и топология.

Ключевые выводы

• Tracking-by-detection – доминирующая парадигма; все современные трекеры – один и тот же скелет с разными мышцами.
• ByteTrack – дефолт 2026: быстрый, простой, motion-only, MIT.
• BoT-SORT-ReID – выбор по точности и дефолт Ultralytics в 2024-2026.
• OC-SORT – для нелинейной моторики (танцы, спорт, животные).
• DeepSORT – историческая база; не дефолт для новых проектов.
• HOTA – не MOTA – метрика для оптимизации; она балансирует детекцию и ассоциацию.
• Качество трекера – downstream качества детектора; сначала чините детектор.

Что читать дальше

• YOLO в продакшене – v8, v9, v10, v11, v12 – детектор, кормящий трекер.
• OpenPose, MediaPipe Pose, RTMPose, ViTPose – стек отслеживания позы для видео в 2026 – пайплайн позы, использующий ByteTrack как третий этап.
• Latency, развёртывание и real-time vs batch – фреймворк выбора топологии, который мы применяем.