«SFT даёт основной прирост»: AWS показала конвейер разметки товаров на Qwen3-8B и SageMaker

Задача: грязный каталог и узкая цель

Отправная точка описана одной фразой: розничные каталоги редко приходят в виде чистых структурированных атрибутов. Названия, описания и пути категорий собираются из разных источников и постоянно меняются, а поиск, рекомендации и навигация зависят от согласованных тегов. Ручная разметка тысяч SKU идёт медленно и трудно удерживается в одном стандарте.

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

Конвейер разбит на три части: подготовка данных, серверная кастомизация модели и инференс. Обучающие этапы выполняются в Amazon SageMaker serverless model customization, а оптимизированная модель разворачивается отдельно — на Amazon SageMaker Asynchronous Inference для пакетного обогащения каталога.

Оговорку AWS выносит отдельным предложением: «серверное» здесь относится только к пути обучения, а сам асинхронный эндпоинт работает на выделенном инстансе ml.g6.2xlarge.

Данные и схема: девять категорий

В разборе используется публичный Amazon Sales Dataset (более 1 000 товарных записей) — либо собственный каталог, преобразованный в ту же схему «промпт/цель». Подготовка вынесена в задачу Amazon SageMaker Processing: скрипт читает файл из Amazon S3, нормализует текст и пути категорий, удаляет непригодные строки, отображает данные в существующую схему из девяти категорий, делит выборку на обучающую и валидационную и записывает JSONL обратно в S3.

Полученные файлы регистрируются как версионированные датасеты в Amazon SageMaker AI Registry — тренер потребляет именно ARN версии, а не обычный обучающий канал. В каждой строке SFT — массив messages: системное сообщение «Use the nine-category schema.», ввод пользователя с названием и категорией товара и ответ ассистента, который служит целью обучения.

Отдельно подчёркнута гигиена доступа: права по принципу минимальной достаточности и короткоживущие учётные данные (например, через AWS IAM Identity Center), без root-доступа и долгоживущих ключей. Ещё одна практическая деталь: собственный образ vLLM нужен только для инференса, а серверные SFT и RLVR кастомного обучающего образа не требуют.

SFT: LoRA и серверная мощность

Первый этап учит модель самой схеме разметки. В Python SDK v3 за это отвечает SFTTrainer: он подбирает поддерживаемый рецепт для Qwen3-8B, применяет Low-Rank Adaptation (LoRA), использует зарегистрированные ARN датасетов и публикует результат в группу пакетов моделей.

Ключевая деталь конфигурации — отсутствие аргумента с вычислительными ресурсами: если compute не задан, Amazon SageMaker сам подбирает и освобождает обучающую мощность, так что клиенту не нужно выбирать GPU-инстанс. AWS сравнивает это с прежним примером Qwen3-8B в репозитории amazon-sagemaker-examples, где использовались Amazon SageMaker Training Jobs с выбранными заказчиком инстансами и кастомными обучающими образами.

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

RLVR и GRPO: награда без модели-судьи

После SFT модель уже соблюдает формат, но всё ещё может пропускать ожидаемые атрибуты или добавлять лишние, поэтому второй этап оптимизирует компромисс, а не учит формат заново. RLVR подходит здесь потому, что результат разметки структурен и сравним с эталоном без отдельной большой языковой модели-судьи.

Награда детерминированная: она проверяет формат девяти категорий и сравнивает предсказанные теги с эталоном нечётким сопоставлением с порогом 0,5. В посте приведена и сама формула: Overall = 0,30 × recall + 0,30 × precision + 0,30 × accuracy + 0,05 × match_quality + 0,05 × formatting.

Гиперпараметры названы полностью: rollout_n = 8 (восемь кандидатов на каждый промпт), global_batch_size = 128, max_epochs = 4, learning_rate = 1e-5, max_prompt_length = 2048. GRPO считает групповые относительные преимущества, а KL-регуляризация ограничивает уход от SFT-референса.

Расписание награды сознательно меняется по ходу обучения: на ранних итерациях акцент на recall, чтобы модель не теряла ожидаемые атрибуты, на поздних — на precision, чтобы она не добавляла неподтверждённые теги. Так бизнес-компромисс между «пропустить» и «добавить лишнее» оказывается выражен в награде, а не оставлен в промпте.

Результаты: 0,354 → 0,6827 → 0,6941

Итоговая таблица отделяет эффект обучения от эффекта донастройки: базовый вариант — Overall 0,354, recall 0,327, precision 0,397, accuracy 0,327; после SFT — Overall 0,6827, recall 0,6689, precision 0,652, accuracy 0,6689; после GRPO — Overall 0,6941, recall 0,703, precision 0,638, accuracy 0,686.

Читать это AWS предлагает так: SFT — основной драйвер качества, он поднимает взвешенную оценку с 0,354 до 0,6827 и заметно улучшает и полноту, и точность. GRPO даёт более узкий компромисс: Overall и recall растут, precision немного снижается. Вывод для команды каталога сформулирован в посте: GRPO полезен, когда пропустить корректный атрибут дороже, чем добавить несколько лишних тегов; если лишние теги вреднее, веса награды стоит сместить в пользу precision.

Ещё одно предупреждение важно для интерпретации: метрики измеряют качество разметки, а не бизнес-конверсию. Проверять эффект AWS советует на показателях самого каталога — полноте атрибутов, доле ручных правок, покрытии поиска и фильтров и качестве рекомендаций ниже по потоку.

Инференс, отслеживание и ограничения

На этапе обслуживания запросы к асинхронному эндпоинту ставятся в очередь, а результаты записываются в Amazon S3. Вызов делается по InputLocation с последующим опросом OutputLocation; для стабильной генерации в разборе используются temperature = 0,1 и max_tokens = 1024.

Требование к квоте хостинга для ml.g6.2xlarge названо отдельно, и там же зафиксировано разделение инфраструктуры: обучение и инференс в примере сознательно разведены, а кастомный образ vLLM нужен только для обслуживания. GitHub-каталог amazon-sagemaker-examples упомянут в посте как источник воспроизводимых ноутбуков по SFT, RLVR, AI Registry и сквозным сценариям.

Чего в разборе нет, стоит сказать прямо: стоимости обучения и инференса, замеров задержки, сравнения с фронтирными моделями по цене запроса и независимых прогонов — все числа в таблице получены внутри самого примера AWS. Для воспроизводимости AWS советует фиксировать гиперпараметры, веса награды, метрики и происхождение модели через MLflow и группы пакетов моделей.

Отдельный пункт — уборка ресурсов: после проверки примера нужно удалить эндпоинт, его конфигурацию, модель, Lambda-функцию награды и evaluator, версии датасетов, группы пакетов моделей, префиксы S3 и образ в ECR, предварительно сверив имена общих ресурсов.

Кому подходит такой путь

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

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

Для того, кто решает, повторять ли этот путь, полезно держать в голове два факта из первоисточника: основной прирост даёт обычный SFT, а RLVR с GRPO — это тонкая настройка компромисса между полнотой и точностью, которая добавила к Overall около 1,1 пункта.