Исследователи дополнили CLS-токен DINOv2 областями интереса для поиска изображений

Авторы препринта arXiv:2610.10991 предлагают способ выжать из DINOv2-reg больше, чем даёт один вектор [CLS]. К пяти семантическим токенам модели (глобальному [CLS] и четырём register-токенам) они добавляют локальные ROI-токены. Поиск строится по схеме multi-vector, вдохновлённой ColBERT. Вместо одного дескриптора на картинку получается небольшой набор, при этом хранить эмбеддинги всех патчей не требуется. Код опубликован на GitHub.

Почему один дескриптор не справляется

Стандартный пайплайн поиска изображений на vision transformer прост: прогоняем картинку, берём [CLS], сравниваем по косинусной близости. Для грубого семантического поиска («найди пляжи») этого хватает. Для fine-grained задач (близкие виды животных, модели техники, похожие товары) всё сложнее. Различия сидят в мелких деталях, а глобальный вектор вынужден упаковать в себя всё содержимое кадра сразу. Авторы прямо пишут, что такое сжатие вредит качеству поиска.

Разные идеи решают эту проблему через внешние детекторы, bounding box'ы или saliency-модули. Это лишние компоненты, лишние ошибки и дополнительная разметка. Здесь выбран другой путь.

Как устроен метод

Опора метода: DINOv2-reg, вариант DINOv2 с register-токенами. По наблюдению авторов, эти токены в процессе обучения сами начинают кодировать объекты и их части. Каждый из пяти семантических токенов ([CLS] и четыре register) работает как «подсказка» (cue). Для неё подбирается «напарник» (buddy), патч-токен, лучше всего соответствующий пространственной области, которую эта подсказка описывает. Вокруг напарника берётся окно N×N патчей, и оно агрегируется в локальный ROI-токен.

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

Далее вступает идея ColBERT. Запрос и документ представлены наборами векторов, а сходство считается через пообъектное выравнивание токенов (late interaction). Так сохраняется тонкое сопоставление, но индекс не раздувается до сотен патч-эмбеддингов на изображение.

• Бэкбон: DINOv2-reg, пять семантических токенов ([CLS] + 4 register).
• Для каждой «подсказки» строится свой ROI-токен из области N×N патчей.
• Детекторы, bounding box'ы и saliency-модули не нужны.
• Поиск: multi-vector с пообъектным выравниванием, как в ColBERT.
• Код открыт, репозиторий указан в аннотации.

Что показали эксперименты

Авторы формулируют три вывода. Первый: register-токены действительно хранят полезные мелкие детали и дополняют [CLS]. Второй: автоматически пулингованные ROI-токены дополнительно улучшают различение близких классов. Третий: multi-vector поиск с малым числом токенов превосходит одновекторный базовый вариант на DINOv2-reg и остаётся приемлемым для крупномасштабного поиска.

Ограничение стоит назвать сразу. В аннотации нет конкретных метрик, ни прироста Recall@K, ни mAP, ни названий бенчмарков. Оценить масштаб эффекта можно только по полному тексту и таблицам статьи. Заявление о «tractable» масштабе тоже требует проверки на собственных объёмах данных.

Где это можно применить

Практический интерес у метода у тех, кто строит визуальный поиск по каталогам: e-commerce, коллекции музеев, биологические и медицинские архивы. Там именно мелкие различия отделяют нужный результат от почти правильного. Плюс подхода в том, что он надстраивается над готовым DINOv2-reg: переобучать бэкбон с нуля не обязательно, достаточно добавить этап выделения токенов.

Цена известна заранее: вместо одного вектора на изображение придётся хранить несколько. Если ROI-токен строится для каждой из пяти подсказок, это порядка десяти векторов (оценка по описанию метода, точное число зависит от конфигурации). Индекс вырастет, а векторная база должна поддерживать multi-vector запросы с MaxSim-подобным скорингом. Перед внедрением имеет смысл прогнать репозиторий на своём датасете и сравнить прирост точности с ростом стоимости хранения и задержки.