Векторный поиск в модерации контента. Как поместить 200+ моделей в один ансамбль?

Привет, я Лев Нечаев. Когда-то я работал на заполярной атомной станции, а теперь руковожу командой «Автоматическая модерация методами ИИ» в RWB. В этой статье расскажу, как мы (успешно) применяем детекторы на основе векторного поиска в модерации контента на маркетплейсе.

Начнём с предпосылок, первых моделей и сбора данных. Вместе пройдём путь от обучения до оценки качества детекторов в работе на реальных потоках данных.

Будни команды автоматической модерации

Наша миссия — повышать доверие пользователей к Wildberries. Мы создаём специализированные решения на основе машинного обучения для модерации контента во всех продуктах экосистемы.

Автоматическая модерация работает с очень большими объёмами данных. Мы модерируем более 20 типов сущностей, каждая из которых представляет собой определённую часть продукта (пример — карточки товаров или видеоролики Wibes). Обрабатываем 400+ запросов с разной модальностью (изображения, текст, видео, аудио) в секунду. Ежедневно модерацию проходит 12+ млн карточек товаров — это более 70 млн изображений. Чтобы осознать масштаб, вообразите, что все жители Мурманской области в один день выложили где-то по 20 карточек товаров, и их все необходимо проверить модерацией.

Запросы модерации обрабатываются в автоматическом режиме с помощью 70+ моделей классов ViT, BERT, VideoMAE и, конечно, детекторов объектов YOLO. И да, при такой загрузке нам удаётся обеспечивать качество детекции (Precision) не менее 90%.

С какими вызовами мы сталкиваемся в модерации?

1. Низкий Time to market для модерационных проверок (Time to Market, TTM). Модерация должна быстро реагировать на изменения в законодательстве и запросы регуляторов.

2. Постоянно меняющийся контент. Что было актуально вчера — сегодня может устареть. Модерация должна быстро адаптироваться к контенту, созданному как людьми, так и генеративными моделями, которые постоянно развиваются.

3. Новые страны и продукты. Как вы знаете, Wildberries выходит на новые рынки, запускаются новые продукты, и модерация должна обеспечивать соответствие законам разных стран и адаптироваться под новые регламенты продуктов.

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

Какой подход выбрать для модерации брендов и лиц

Вообще, есть три возможных варианта:

• Обучаемые картиночные классификаторы,

• Few-shot (подход, при котором модели достаточно нескольких примеров нового объекта),

• Детекторы объектов.

На первый взгляд кажется, что подойдёт обычный обучаемый классификатор. Но модель не будет устойчиво распознавать разные представления, например, лорда Фаркуада. Она переобучится под определённые изображения, но в общем многомиллионном потоке будет выдавать высокую долю ошибок. С Few-shot проблема не решается: модель сможет находить очень похожие варианты, но, скорее всего, не сможет обобщить всех лордов Фаркуада или же отличить логотип малоизвестного бренда.

Значит, будем использовать детекторы объектов.

Можно ли просто обучить такой детектор?

Представим сценарий: менеджер ставит задачу модерировать определенный бренд и применять модерационное решение. Мы обучаем отдельную YOLO-модель на один класс, выкатываем в прод — всё работает. Но через несколько часов появляется запрос добавить ещё 10, 20 или 30 брендов. Перед нами два пути: обучать каждую модель отдельно или обучить одну модель с множеством классов.

1. Обучение отдельной модели для каждого бренда. Достаточно гибкий подход, но растущее количество моделей будет потреблять много ресурсов графического процессора (GPU).

2. Обучение одной большой модели со множеством классов. Выглядит привлекательнее, но создаёт другую проблему. Качество распознавания уже существующих брендов может неконтролируемо падать при переобучении модели. Для таких больших потоков данных, как у Wildberries, это огромный риск.

При выборе любого из двух подходов мы сталкиваемся со следующими проблемами:

• Высокий TTM. Сбор данных и валидация на суточных объёмах данных — длительный и ресурсоёмкий процесс.

• Трудности поддержки. Модели необходимо постоянно переобучать, но невозможно бесконечно повторять цикл «запрос → переобучение». Кроме того, логотипы и лица имеют свойство меняться. Когда компания делает ребрендинг, мы должны исключить из обучения старый логотип и сделать новую разметку.

• Ограничения вычислительных ресурсов. Если заниматься безумием и безгранично увеличивать количество моделей, мы просто упрёмся в потолок возможностей GPU.

Наша модерационная команда DS решила эти проблемы, объединив два подхода: детекторы объектов и векторный поиск.

Как мы построили свой детектор логотипов

Давайте начнем с построения детекционной части (детектора объектов). Для этой задачи нам требовалось значительно больше данных, чем обычно необходимо для обучения небольшой YOLO-модели.

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

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

Также мы применили VLM-разметку (Vision-Language Model). Разметили собственный поток данных, применили некоторые эвристики и получили датасет.

Данные есть! Но прежде чем отправить их на обучение, нужно провести дополнительные преобразования: дедупликацию и сэмплирование.

1. Дедупликация. Удаляем повторяющиеся изображения, чтобы не обманывать ни себя, ни модель и повысить чистоту данных.

2. Сэмплирование по брендам. Обеспечиваем равномерное распределение, чтобы, например, логотипы брендов одежды значительно не преобладали над логотипами электроники.

Наш результат: датасет объёмом более 200 тысяч изображений, содержащий около 400 тысяч объектов класса «лого», 20+ доменов и 220+ брендов.

Переходим к обучению модели детекции!

Шаг 1. Нельзя просто взять датасет и обучить на нем модель, необходимо разделить его на обучающую, валидационную и тестовую выборки в стандартном соотношении 80/10/10. При этом соблюдали важное условие: бренды не должны пересекаться между выборками. Это позволит проверить модель на брендах, которые она никогда раньше не видела.

Шаг 2. Выбрали для детекции YOLO — потому что команда имела опыт адаптации этого класса под огромные потоки данных. Провели 5+ экспериментов (40–50 часов), и все они версионировались в фреймворк для трекинга экспериментов по машинному обучению ClearML.

А теперь выберем эмбеддер для векторного поиска

Эмбеддер в композиции с детектором объектов обеспечит низкий TTM и максимальную точность, используя сравнение референсов и поступающих изображений кандидатов по косинусному сходству. Мы остановились на визуальной части модели CLIP, которая обучена на большом объёме изображений и подходит для наших задач.

Для отбора эмбеддера мы сформулировали два требования. Во-первых, модель должна корректно искать логотипы разных представлений. Например, если пользователь загрузил знак Nike, система должна находить и графический символ, и текстовое написание. Во-вторых, эмбеддер должен обладать высокой разделяющей способностью.

Соединяем всю архитектуру

На вход в детектор подаётся карточка товара. Перед началом поиска менеджер или дата-сайентист через административную панель Admin UI загружает логотип, который необходимо найти. Изображение проходит через CLIP-эмбеддер, мы получаем эмбеддинг, и он сохраняется в Faiss Vector Storage.

Логотип загружен, карточка на входе — можно запускать детекцию логотипов!

Все изображения проходят через YOLO-модель, которая выделяет потенциальные логотипы. Далее каждый кандидат преобразуется в эмбеддинг с помощью CLIP. Получаем нормализованные векторы и переходим к самому векторному поиску.

Поскольку все эмбеддинги нормализованы, достаточно скалярно перемножить векторы и получить косинусное сходство, на основе которого мы определим, что логотип относится к ранее загруженному в данном случае бренду Nike.

Оцениваем производительность

Первое — инференс моделей. Все модели развёрнуты в Triton Inference Server. Для каждой картиночной модели реализован свой пайплайн DALI препроцессинга, модели конвертированы в формате TensorRT (FP16), и это даёт прирост производительности в три-четыре раза.

Второе — векторный поиск логотипов. Сначала мы использовали PGVector, но с ростом числа запросов на модерацию и логотипов перешли на Faiss Vector Storage. В начале мы использовали таблицу с одним индексом: если один и тот же логотип загружался два раза, первый мог перестать работать после косинусного сравнения. А ещё PGVector просто не выдерживал наши нагрузки.

Сейчас в Faiss для каждого бренда строится свой индекс, мы получаем безопасный векторный поиск и выдерживаем рост нагрузки. 

Оцениваем качество

Каждую модель, детектор мы проверяем локально на многомиллионных потоках данных, и автоматически размечается с помощью VLM. На выходе получается поверхность управления, которая позволяет маневрировать порогами и получать соответствующие метрики качества.

На практике вместо 3D-визуализации мы используем таблицу представления поверхности — это гораздо удобнее. Ещё до запуска модели можно прогнозировать качество и число срабатываний, что особенно важно в сложных сценариях с участием ручной модерации. Мы ведь не хотим завалить модераторов запросами!

Кроме того, появляется гибкая категорийная настройка. Если в определенной категории вероятность появления бренда минимальна, можно повысить порог срабатывания. Если бренд встречается часто — сделать настройки более чувствительными. Наш детектор логотипов обеспечивает среднюю точность свыше 90%, и иногда мы даже искусственно ограничиваем его, чтобы соответствовать задачам бизнеса.

Где ещё применить эту архитектуру?

В векторном детекторе лиц!

Пользователь загружает фотографию лица или персонажа через Admin UI. На вход в детектор поступают карточки товара или фреймы видео. Они обрабатываются YOLO-моделью, предобученной распознавать лица. Далее используем векторизатор ArcFace и получаем отличное качество детекции лиц.

Как еще можно применить детекторы представленной архитектуры?

1. Как часть более сложных каскадных решений. Например, перед запуском поиска логотипа Nike можно отсечь часть очевидных ложных срабатываний на Adidas с помощью текстовых инструментов.

2. Использование VLM-проверки. Если необходимо учитывать контекст изображения, используем VLM и повышаем качество детекции почти на треть.

3. Автоматическая разметка данных. Сам детектор, который уже работает с точностью более 90%, можно использовать как наработчик разметки высокого качества. Мы планируем использовать эти данные для дообучения детекционной части.

Достойные результаты: 500+ лиц и логотипов!

Когда я писал эту статью, мы преодолели отметку в 500 логотипов и лиц. А сейчас, когда вы её читаете, преодолели и >800!

Главный результат — низкий TTM. От момента поступления запроса до применения модерационного решения проходит менее 25 минут. Мой личный рекорд составляет 13-14 минут.

При этом качество остаётся стабильно высоким. Мы обеспечиваем среднюю точность свыше 90% и покрытие для более чем 20 доменных зон.

Векторный поиск значительно экономит ресурсы. 2 векторных детектора заменяют 800+ моделей детекции YOLO по потреблению GPU. Представьте, сколько нужно времени, чтобы обучить 800 моделей с учётом разметки и валидации… А мы справляемся менее чем за 25 минут.

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

Больше про машинное обучение — в telegram-канале RWB делает ML. Подписывайтесь!