Как мы автоматизировали модерацию карточек товаров с помощью Computer Vision в Wildberries

Привет! Я Дмитрий Колесников, Team Lead DS-команды «Платформа модерации» в Wildberries & Russ. В этой статье по мотивам моего доклада на HighLoad расскажу, как у нас получилось превратить сотни Computer Vision моделей в единый масштабируемый пайплайн, который ежедневно обрабатывает 15 млн карточек товаров (50+ млн изображений и 500K видео).

Что еще будет в статье?

• Computer Vision‑архитектура системы модерации Wildberries: как мы унифицировали модели через TensorRT и DALI, перешли к шаблонной архитектуре «общий бэкбон – легкие головы» и построили ансамбль в Triton, чтобы снизить нагрузку и ускорить деплой.

• Описание актуального процесса создания моделей: от постановки задачи до автоматизированного ретроскоринга и деплоя моделей в продакшен. Включая прогнозирование нагрузки на модерацию и применение Visual Language Models для проверки предсказаний.

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

Дисклеймер: в статье не будет сложной математики (DL‑концепты будут объяснены на пальцах) и описания NLP‑модерации (речь только о компьютерном зрении).

Немного о масштабах платформы Wildberries:

• 10 стран присутствия – и количество растет;

• 81 млн уникальных пользователей ежемесячно;

• 20+ млн заказов товаров в сутки;

• больше 1 млрд запросов в сутки обеспечивает внутренняя IT‑инфраструктура.

Что такое модерация и зачем она нужна

Главная задача модерации – это обеспечение безопасности площадки. А именно:

1. Автоматическое выявление запрещённых товаров и контента в карточках (например, никотиносодержащая продукция, оружие, запрещенные медикаменты, товары для взрослых без указания плашки 18+ и так далее).

2. Поддержка честной и добросовестной конкуренции среди продавцов (у всех селлеров единые условия согласно оферте).

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

Каждый день через модерацию проходит около 15 млн карточек товаров. Это порядка: 50-75 млн фотографий и 500к видео в сутки.

Как работает команда модерации

Мы являемся молодой продуктовой DS‑командой, сумевшей выстроить с нуля масштабируемую систему модерации.

Мы пришли к созданию этой системы через постоянное развитие и доработку. На ранних этапах у каждого разработчика была возможность самому привносить лучшие практики в работу и поддержку своих моделей: под каждую модель создавался свой сервис, архитектуры моделей и подходы к деплою различались. Это давало гибкость и позволяло проводить множество DS-экспериментов, но создавало вызовы при масштабировании.

Разработка каждой модели включала большой пласт работ: от исследований архитектуры нейросетей и подходов к обучению до написания бэкенд-сервиса. Каждая новая модель требовала повторения этого полного цикла.

Вот как выглядел процесс разработки:

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

Остановлюсь на том, как именно менялись наши решения и как мы пришли к итоговой архитектуре DS-модерации.

Первые улучшения

Triton Inference Server уже был проверенным решением с хорошей репутацией. Он использовался для запуска моделей, и это дало надежную основу для наших изменений.

Triton Inference Server:

1. Даёт единый API для моделей из любых фреймворков.

2. Позволяет отделять бэкенд (CPU) от инференса (GPU), упрощая масштабирование и снижая связность команд. Все нейронки располагаются именно на GPU‑тачках, там происходит их inference, в то время как основной бэкенд, который получает кадры, обрабатывает их, принимает итоговое решение и отправляет его – это CPU‑бэкенд.

3. Поддерживает автобатчинг (критично при асинхронной нагрузке). Вместо обработки фото по одному сервис собирает асинхронные запросы в батчи и отправляет их в Triton Inference Server вместе. Это ускоряет инференс и повышает пропускную способность системы.

Унификация в Triton Inference Server

В Triton использовались модели в разных форматах: от PyTorch до ONNX. Это создавало проблемы:

• Разная производительность;

• Сложности в поддержке.

Не все модели можно было сразу привести к единому высокопроизводительному формату. Одной из наших задач стал постепенный перевод всех моделей на TensorRT.

Что дает TensorRT

TensorRT – фреймворк от компании NVIDIA, позволяющий делать модель ещё более оптимизированной и быстро работающей на конкретном железе.

TensorRT берёт всё главное преимущество конкретной видеокарты, на которой на проде инференсится модель. Например, если использовать видеокарту A100, то тогда он возьмёт все аспекты и преимущества A100 и преобразует граф вычислений нейронной сети, чтобы дать выигрыш. Получается:

• Ускорение инференса в 1.5 раза и больше за счёт оптимизации графа вычислений;

• Поддержка квантизации – сокращение потребления GPU‑памяти и рост RPS (запросов в секунду). Квантизация позволяет снижать потребление видеопамяти и увеличить пропускную способность каждой из моделей.

Процесс конвертации моделей в такой формат включает несколько этапов. Сначала обучение происходит в PyTorch – нашем основном инструменте. Затем модель экспортируется в ONNX – универсальный формат для представления вычислительного графа, который позволяет стандартизировать и оптимизировать модель. Финальный шаг – конвертация в TensorRT для максимальной производительности на GPU.

Все модели были переведены на TensorRT с fp16 квантизацией, что обеспечило ускорение вычислений и эффективное использование памяти при сохранении качества предсказаний.

Стандартизация препроцессинга

Что происходит с изображением на инференсе? Перед подачей на модель изображение должно преобразоваться, привестись к нужному виду, которое пригодно для нейросети. Это, например, перевод из uint8 в fp16, приведение до квадратного вида (ресайз), нормализации и прочие вещи, которые использовались в процессе обучения.

Тогда возникает вопрос: где осуществлять всю эту предобработку? Можно ли прямо в бэкенде взять фотографию, ресайзить, нормализовать, привести к нужному формату?

Реализация возможна, но бэкенд оказывается сильно связанным с конкретной версией модели. При смене модели необходимо обновлять бэкенд и Triton Server одновременно, иначе нарушится контракт на входные данные. Ошибка в препроцессинге на бэкенде = невалидный вход для модели = некорректный ответ или падение сервиса

Какое здесь может быть решение? Сделать целиком аспект инференса модели и реализации предобработок зоной ответственности DS‑команды. И вся эта логика будет располагаться там же, где и модель – на стороне Triton Inference Server.

Для реализации предобработки изображений мы используем DALI – инструмент от NVIDIA, который позволяет создавать компилируемые пайплайны с необходимыми трансформациями компьютерного зрения. 

Преимущества DALI:

• Увеличивает пропускную способность за счёт того, что эти операции происходят на стороне GPU;

• Поддержка батчей и основных трансформаций;

• Компилируемый пайплайн, встроенный в Triton.

А для оркестрации всего процесса мы используем Triton Ensemble. В ансамбле сначала идёт DALI-препроцессинг, а далее уже подача на TensorRT‑модель. Y (ответ модели) отправляется на сторону бэкенда, где уже потом сравнивается с порогами и принимается итоговое решение по конкретному изображению.

Пора браться за бэкенд

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

Помимо объединений сервисов, появилась ещё одна классная возможность – объединить и админки для моделей. Раз теперь сервис один, и он покрывает кучу моделей, то для удобного взаимодействия можно сделать единый UI‑интерфейс, через который можно с этими моделями взаимодействовать.

Чего удалось добиться благодаря объединенным сервисам:

• Все запросы на модерацию идут через один шлюз;

• Хорошее логирование и мониторинг сервиса;

• Упрощено управление моделями через единую админку.

В админке можно:

• Редактировать конфигурации моделей (под капотом в MongoDB располагаются все эти конфигурации);

• Видеть все модели сразу – не нужно лазить по множеству разрозненных интерфейсов;

• Быстро включать и выключать модели, менять пороги, приоритеты, режимы работы.

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

Как мы справились с высокой нагрузкой на модерацию

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

Какие были ключевые вызовы:

1. Количество моделей продолжало расти, требуя всё больше вычислительных ресурсов

2. Каждая модель потребляла около 1.75 ГБ VRAM (свыше 85 млн параметров на модель), а таких моделей за пару лет накопилось несколько десятков

Использование VRAM vs число моделей

На графике ниже видно, что с ростом числа моделей растёт и потребление видеопамяти, на 100 моделях это порядка 175 ГБ памяти. Один А100 – это примерно 80 ГБ видеопамяти, и получается, что нужно минимум 3 А100 только для того, чтоб поднять все модели в одном инстансе, что очень дорого с точки зрения ресурсов.

Зачем нужны такие большие модели? Дело в том, что простыми такое решать довольно трудно. Контент Wildberries слишком разнообразный:

• Огромное количество разных по качеству фото: от студийных изображений до снимков «на телефон в гараже»;

• Разный фон, освещение, ракурсы, обрезки;

• Много визуального шума;

• Бывают синтетические ИИ‑фото.

Весь этот шум усложняет работу обычных моделей, таких как свёрточные, которые ищут базовые, очень простые признаки локального типа. Поэтому лучше использовать ViT (Visual Transformer), что позволяют работать на более разнообразном контенте с меньшим количеством ложных срабатываний.

Еще одна проблема – чем больше моделей на одну карточку товара, тем больше сетевых запросов (тяжёлый payload из‑за отправки фото по АРІ в Triton). Например, если одно фото отправить не на одну модель, а на 100-200 моделей, то это, по сути, 100-200 идентичных сетевых запросов. Внутри каждого такого gRPC запроса в Triton целиком отправляется фотография, а она довольно «тяжёлая». В результате возникает большое количество лишних отправок одного и того же контента.

Также будет явное снижение RPS при увеличении числа моделей. Если фото отправить на 5 ML-моделей или на 100, пропускная способность будет разной. Через 5 моделей протащить его проще, чем через 100. Поэтому пропускная способность снижается с ростом числа таких моделей. Это очень важная метрика, учитывая, что поток порядка 15 млн карточек товаров в день.

А что если…

…попробовать все проблемы решить разом, чтобы обеспечить дальнейший рост бизнеса без пропорционального увеличения затрат на инфраструктуру?

• Во‑первых, отправлять фотографию один раз и получать сразу ответ от всех моделей, то есть тем самым убрать сетевую нагрузку.

• Во‑вторых, что‑то сделать на стороне самого инференса, чтобы повысить пропускную способность, и дублирующие и похожие операции между всеми моделями унифицировать.

Делаем единый ансамбль моделей

Первое решение следующее: берём фотографию, отправляем её в Triton один раз, а ответы получаем от всех благодаря увеличению размера тритон-ансамбля. На выходе получится не один Y, а уже целая куча, то есть все модели возвращают ответы при одном вызове.

Теперь можно всю предобработку делать всего один раз. На вход Triton Server приходит изображение, один раз преобразовывается и отправляется на все модели. 

Тем самым:

1. Снижается сетевая нагрузка.

2. Увеличивается RPS (пропускная способность) из‑за параллелизма и общей предобработки.

Но кое‑что так и остается нерешенным: GPU‑память расходуется так же (ведь каждая модель ≥ 85 млн параметров). Например, если есть 100 моделей, значит 100 нужно умножить на 85 млн параметров. Объем вычислений получается внушительным.

К тому же и пропускную способность можно еще поднять. Пока ведь общим стал лишь DALI-пайплайн. Сами модели никак не изменились.

Бэкбон и головы: как разделить модель

Для того, чтобы побороть эту проблему, нужно углубиться в математику и идею работы нейросети.

Любая нейросеть работает следующим образом. Входящая фотография обрабатывается при помощи различных математических операций, после чего выделяется ее смысл. Нейронка не отвечает на вопрос, а пока просто понимает смысл изображения, тем самым формируя некоторые признаки – числа, характеризующие смысл фотографии, отправленной на вход. В конце этой нейронной сети ставится специальный модуль, который принимает итоговое решение на основе признаков. Тем самым, порядка 95-99% сети занимает вытягивание признаков, а уже последняя часть принимает финальное решение.

Эти вещи можно разделить, оставив вытягивание признаков отдельно от части финального предсказания.

Вытягивание признаков – это бэкбон (backbone). Он выдаёт по фотографии некий вектор, числовые параметры, которые характеризуют смысл представленного изображения. Для человека, конечно, они непонятны, выглядят как рандомный набор чисел, но для модели это важные признаки.

Остаётся повесить наверх лишь голову (head) – итог, выходную часть сети. Обычно это полносвязная часть сети, которая занимает не так много параметров. Если бэкбон – это 85 млн параметров, то голова – это порядка там 250-500 тысяч параметров. И именно голова и принимает решение на основе хороших признаков.

Для того, чтобы получить выигрыш, нужно попытаться сделать так, чтобы бэкбон был единый. До этого уже был сделан единый DALI-пайплайн, который позволяет делать общую предобработку фотографий. А теперь помимо унифицированного пайплайна предобработки нужно иметь унифицированный бэкбон, такой, чтобы он был хорош для всех моделей модерации. Тем самым 85 млн параметров будут заморожены, а обучаться будут только лишь головы.

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

Как обычно обучаются модели

Например, стоит задача определить, кто на фото – кошка или собака. Нейронка выдаёт ответ, далее cледует коррекция параметров модели (весов) для того, чтобы модель правильно определила животное.

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

Используем датасет из пар: описание + фото

А что, если в качестве вердикта будет не просто выбор между кошкой или собакой, а описание самой фотографии? Ведь текстовое описание фотографии больше подойдет в качестве таргета.

Ниже – три фотографии. На всех был бы вердикт «кошка». Но, как вы видите, на самом деле на изображении не просто кошка. Это важно в контексте выявления нарушений на WB, ведь на первый взгляд фото может выглядеть приемлемо, но где‑нибудь сбоку может случайно оказаться то, что запрещено по правилам площадки. Нужно понять целиком всё изображение, а не только что‑то значимое, что находится по центру.

Текстовое описание – идеальный таргет для обучения моделей. Если фотография и текст находятся в одном пространстве рядом, значит смысл легко понять, а также вытащить из изображения хорошие признаки.

CLIP идея обучения

На такую парадигму обучаются специальные CLIP‑модели. Они берут тексты и изображения и пытаются их смэтчить.

Идея следующая: одна модель получает вектор из текста, а другая модель векторизует фото. Потом делается мэтчинг. Так, похожий текст с похожими фотографиями должен давать похожие вектора. Это похоже на попытку объединить векторное пространство фотографий и текстов.

За счёт этого можно сделать следующее. Из двух моделей – векторизации фото и векторизации текста – оставляем лишь ту, которая отвечает за векторизацию фотографий. Так и получается идеальный бэкбон. Image Encoder станет нашим бэкбоном, потому что он выдаёт признаки универсально под любую фотографию. Притом CLIP‑модель обучалась вообще на всём Интернете, включая около 2 млрд пар текст‑фото.

Что делать с головами?

С бэкбоном разобрались, а что теперь делать с головами? Головы – это очень маленькая сущность, именно голова принимает решение, в ней параметров довольно мало, поэтому и решать задачу она должна максимально простую.

Здесь не стоит выбирать многоклассовую или мультилейбл‑классификацию, потому что это довольно сложная задача. Лучше выбрать самую простую – бинарную. Идея её в том, чтобы просто взять фото и выдать вердикт «да» или «нет».

Например, на фото сигара с вероятностью 97%. Голова выдаёт число от 0 до 1. И дальше можно играться с порогами. Например, если уверенность больше, чем 60%, тогда считаем, что это причина, чтобы забанить изображение. Если процент меньше, то всё нормально – хорошая фотография.

Делаем единый ансамбль в Triton

Что в итоге получилось: на уровне Triton располагается DALI‑преобразование (приведение фотографии в нужный вид). Там же происходит прогон через бэкбон, который вытягивает признаки, получает вектора, и эти вектора отправляются на маленькие головы, работающие параллельно.

Один запрос – один проход бэкбона – десятки ответов голов.

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

Преимущества подхода с головами:

1. Снижена сетевая нагрузка (1 запрос на все модели классификации).

2. Увеличен RPS (самая тяжелая часть сети отрабатывает 1 раз) + головы параллельны.

3. GPU‑память расходуется на порядок меньше (новая голова в ансамбле добавляет максимум 30 МБ к VRAM).

VRAM: до и после оптимизации

Вот как изменилось потребление видеопамяти после оптимизации. Если ранее при добавлении каждой новой модели был довольно сильный подъём, то теперь каждая модель (а точнее её голова) добавляет всего лишь по несколько мегабайт. Чем больше моделей, тем более заметна экономия памяти, которой удалось добиться при переходе на головы.

RPS: до и после оптимизации

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

Преимущества подхода с головами

1. Масштабируемость: головы «весят» почти ничего (в среднем 15 МБ VRAM) + практически не снижают RPS на проде.

2. Модели меньше переобучаются. Находить датасеты в сфере модерации довольно сложно, примеров нарушений мало. Поэтому всегда есть риск того, что модель может просто выучится на конкретные примеры. Если же обучаемых параметров очень много, то шанс найти ложную закономерность довольно высокий. А в случае, если обучить только лишь голову, где параметров мало, шансов переобучиться становится меньше, потому что физически невозможно маленькой голове зазубрить весь датасет наизусть. Тем самым она находит более верную закономерность, и это крайне важно с точки зрения снижения случайных срабатываний.

3. Шаблонный код обучения. Раз состоялся переход на парадигму голов и есть фиксированный бэкбон на всю команду, можно сделать фиксированные подходы к обучению моделей. В настоящий момент все это уже переведено в UI, уже есть UI‑инструменты по обучению таких голов.

4. Быстрое обучение. Обучение головы явно быстрее, чем обучение всей гигантской модели. Количество обучаемых параметров меньше. К тому же количество эпох для обучения тоже нужно меньше, потому что исходно бэкбон уже обучен и хорошо знает мир, поэтому обучать нужно только лишь голову.

Весь процесс в итоге выглядит так:

Как итог, удалось значительно снизить Time to Market разработки и внедрения в продакшен новых моделей.

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

Раз больше не страшно добавлять новые головы, пусть будет четыре – отдельно под сигары, отдельно под обычные сигареты, отдельно под вейпы и кальяны. Если в какой‑то момент деградирует качество, например, по кальянам (ведь контекст со временем может меняться, может быть, модель начнёт что‑то пропускать), в таком случае не будет проблемы обучить модель только лишь на кальяны. Тем самым при повторном обучении не пострадают, например, вейпы. Так возникает независимость между сущностями, и их можно легко улучшать. Плюс это более удобный и надёжный подход, потому что правила могут меняться (например, что‑то стало разрешено), тогда можно отключить только одну модель, в то время как раньше пришлось бы переобучать все.

Пайплайн разработки и внедрения Computer Vision модели модерации

Теперь рассмотрим, как выглядит разработка новых моделей в команде модерации.

Что делает DS‑команда:

1.Получает Т3 от менеджеров. Разбирает его, обсуждает, рассматривает кейсы, согласовывает, что делать, что есть нарушение и как конкретно оно выглядит.

2.Определяет, как разбить одну модель на множество (то есть на отдельные головы).

3.Выбирает тип модели. С точки зрения бэкенда типы моделей – это отдельные бэкенд‑сервисы со своими админками. С точки зрения DS – это разные подходы по обучению и сбору датасета.

Какие существуют типы моделей?

Классификация изображений и кадров видео

Система берёт все изображения и видео из карточки товара, разбивает видео на кадры и прогоняет каждый визуальный элемент через модель отдельно: на одно фото/кадр – один независимый ответ.

Для этой задачи как раз и применяется ViT модель, разделенная на бэкбон и головы.

Классификация видео

Данный подход применяется лишь для видео-контента в особых случаях.

Бывает, что обнаружить по кадру какое‑либо нарушение невозможно. Некоторые из них являются действиями, и определить их просто по одному стоп‑кадру нельзя. В таких случаях применяется специальная разновидность моделей, которая позволяют учитывать аспект изменения между кадрами. Например, у вас фотография двери, которая открыта, и вас спрашивают: «Скажите, вот по этой фотографии эта дверь закрывается или открывается?» Это нельзя понять по фотографии. А если у вас есть уже набор фотографий, то вы легко поймёте.

Для таких задач мы используем VideoMAE модели (у этих моделей тоже используем подход с разделением на общий бэкбон и множество голов). На вход такой модели подаем несколько соседних кадров видео за раз.

Детекция объектов

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

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

Сейчас по такому принципу работают модели распознавания лиц и логотипов. Первая модель – детектор. Он находит координаты логотипа, потом логотип вырезается, векторизуется через специальную модель, и по векторной базе данных можно найти, на что он похож. В данном случае – на Nike.

Что происходит дальше после выбора типа модели:

4.Запуск ClearML пайплайна по обучению моделей и конвертации их в TensorRT.

Когда датасет уже собран и подготовлен, можно приступать к обучению модели. У нас есть возможность запустить обучение прямо из UI – достаточно нажать кнопку и дождаться завершения процесса.

Обучение проходит в ClearML пайплайне, где каждый этап запускается в отдельном контейнере в dev окружении:

1. Подготовка данных – предобработка датасета, настройка аугментаций, разделение данных на train/test с учетом правильных категорийных пропорций.

2. Обучение модели – тренировка головы с выбранным числом параметров.

3. Анализ результата – оценка качества модели на тестовой выборке по итогу обучения.

4. Конвертация в TensorRT – компиляция модели под конкретную видеокарту для оптимизации производительности.

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

5. Ретроскоринг. Когда вы хотите обучить модель на какое‑то нарушение, вы парсите много разных данных из разных ресурсов, и обучаете модель. Распределение в рамках процесса трейнинга отличается от итогового распределения нарушений на маркетплейсе. Потому что в реальности некоторые нарушения на маркетплейсе случаются так редко, что вероятность нарушений на все карточки Wildberries может быть меньше, чем 0,01%. Получается, что при трейне использовалась более высокая вероятность нарушений, а на финальном проде – другая. Для того чтобы выкатить модель на прод, нужно сначала оценить её качество на реальном распределении данных, то есть запустить ретроскоринг – тестирование модели на исторических данных для прогнозирования количества срабатываний на реальной продакшн‑среде. Например, надо посмотреть, как бы вела себя модель, будь она запущена на исторических данных всей прошлой недели в Wildberries.

Для этого существует отдельный UI инструмент. Прямо на сайте можно запустить ретроскоринг и смотреть результаты срабатывания как только он завершится.

А еще прямо из интерфейса можно сделать предразметку итогов ретроскоринга и получить полную precision аналитику модели. На основе итогов ретроскора можно определять продовый порог модели, точно зная, сколько будет ежедневных TP и FP срабатываний у нее.

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

6. Настройка правил и порогов срабатывания модели в админке. После обучения модели и подбора оптимального порога срабатывания её можно запустить в продакшене через админку. Однако здесь важен баланс: если установить слишком строгие пороги, модель начнёт ошибочно помечать безопасный контент как нарушение. А это серьёзная проблема – мы не можем рисковать блокировками добросовестных продавцов.

Учитывая масштаб (более 50 млн изображений в день, а с кадрами из видео до 100 млн), полностью избежать ложных срабатываний невозможно. Поэтому мы используем дополнительные механизмы проверки, которые можно настроить в админке моделей модерации:

1. Ручная модерация – асессоры просматривают срабатывания модели и принимают финальное решение о наличии нарушения.

2. LLM-ассессмент – автоматизированная проверка с помощью языковых моделей, о которой мы расскажем далее.

Как устроен LLM‑ассесмент:

Благодаря данному инструменту можно значительно снизить нагрузку на ручную модерацию. На сегодняшний день LLM‑ки могут обрабатывать не только тексты, но и фотографии (Visual Language Models). Загружаете фотку, задаёте вопрос, например: «Правда ли, что на фотографии есть нарушение?» И модель отвечает.

Но тогда возникает вопрос: а что мешает весь поток Wildberries отправить на эту LLM‑ку? Все просто – модель очень тяжелая. Её пропускная способность намного меньше, чем у лёгких голов. Поэтому, конечно же, отправить весь поток на LLM – это максимально неэффективная стратегия. А вот отправить поток срабатываний, то есть то, что модель забанила и считает нарушением, на LLM – это довольно хорошая практика, которая позволяет снизить долю ложных срабатываний и увеличить итоговый precision-модели.

Как работает LLM‑асессор? Подаём на вход фотографию и просим модель определить, есть ли нарушение. Ответ должен быть в формате 1 (нарушение есть) или 0 (нарушения нет). LLM работает как классификатор токенов, поэтому мы получаем не просто ответ, а вероятность каждого токена. Это позволяет оценить не только результат, но и уверенность модели в своём ответе.

Как реализована модерация

Модерация выглядит таким образом: берётся карточка товара, из неё вытягиваются кадры, они проходят через Triton Ensemble, модели выдают результаты и принимается итоговое решение о том, было ли нарушение. В зависимости от итоговой настройки дальше всё отправляется либо на ручную модерацию, либо на LLM‑асессора, и по итогу принимается решение по карточке.

Помимо блокировки карточки, как результат еще возможны hide (скрытие карточек в конкретной стране), также есть blur, например, в «товарах для взрослых», когда сначала нужно подтвердить свой возраст, чтобы увидеть изображение.

Подведём итоги

1. Был пройден огромный путь к масштабируемой системе.

2. Созданы универсальные сервисы для разных типов моделей модерации с удобными админками для каждого из них.

3. Благодаря шаблонизации DS‑пайплайна удалось снизить многократно Time to Market разработки и деплоя моделей.

4. Теперь можно контролировать и оценивать объём работ на ручную модерацию и определять необходимость в LLM‑асессоре ещё до запуска модели.

А узнать ещё больше интересных кейсов и методов справляться с проблемами в сфере высоконагруженных систем вы сможете в июне на конференции развития Saint HighLoad++! 

«Онтико» кардинально меняет рынок IT-мероприятий в этом году, представляя конференции развития – инструмент решения задач, а не потребления контента. Это практикум, а не лекции, и вы – участник, а не просто слушатель (послушать можно и YouTube). Присоединяйтесь!