Автотегирование товарного каталога это повторяющаяся задача с проверяемым результатом: есть описание товара, есть фиксированная схема из девяти категорий, и нужно разложить одно в другое. Проверяемость меняет правила игры. Там, где ответ сверяется программно, открытая модель среднего размера после дообучения обходит универсальный API по стоимости обработки и по попаданию в вашу схему меток.
Ниже разбор того, как выглядит кастомизация Qwen3-8B в Amazon SageMaker через serverless-обучение: сначала supervised fine-tuning (SFT) на размеченных парах «товар, набор тегов», затем reinforcement learning with verifiable rewards (RLVR) с алгоритмом Group Relative Policy Optimization (GRPO) и детерминированной reward-функцией. Дальше деплой на асинхронный инференс с инстансом ml.g6.2xlarge и пакетная разметка каталога.
Короткий ответ на главный вопрос: специализированная 8B-модель выгоднее frontier API там, где задача повторяется, схема меток стабильна и результат можно проверить кодом. Экономика решается на масштабе: дообученная на своих данных модель реже уходит в долгие рассуждения там, где нужен короткий структурированный ответ, и снижает стоимость обработки одной позиции. Отдельный плюс это контроль над стеком сервинга: провайдеры, обслуживающие одни и те же открытые веса, различаются по скорости из-за ядер, квантизации, железа и планирования батчей.
Зачем дообучать Qwen3-8B вместо frontier API: суть задачи автотегирования
Frontier-модель через API запускается за вечер: пишете промпт со схемой категорий, прогоняете каталог, получаете теги. Проблемы начинаются на объеме. Платите за каждый токен, каждая правка схемы означает новый прогон, а описания товаров уходят на сторону. Для разовой задачи это нормальный выбор. Для конвейера, который работает годами, нужны другие аргументы.
Qwen3-8B это открытая модель с 8 миллиардами параметров, которую можно дообучить под конкретную схему и запускать в своем контуре. Размер здесь не недостаток: задача сводится к сопоставлению текста с фиксированным набором меток, а не к свободным рассуждениям на длинном контексте.
Когда специализированная 8B-модель выгоднее frontier API
Рабочий набор критериев выглядит так:
- задача повторяется часто: разметка каталога идет пакетами каждую неделю или чаще;
- схема меток стабильна, набор категорий меняется раз в квартал, а не каждую неделю;
- разметка есть или ее реально собрать: несколько тысяч корректных примеров закрывают основу;
- стоимость и задержки критичны на масштабе, а не для одного запроса;
- описания товаров не должны покидать ваш контур.
Если хотя бы два пункта не выполняются, выигрыш от кастомизации размывается стоимостью поддержки. Разметка, обучение и валидация требуют времени инженеров, а вызов API требует одного промпта.
Экономика работает предсказуемо. Универсальные модели дают универсальное качество: они не знают ваших внутренних договоренностей о том, что аксессуар для геймпада попадает в электронику, а не в игровые товары. Дообученная модель усваивает эти правила один раз и применяет их без длинных пояснений в промпте на каждом вызове, а значит расходует меньше токенов на тот же результат. На каталоге из сотен тысяч позиций разница накапливается.
Собственный стек сервинга добавляет управляемости. Когда модель работает в вашем контуре, скорость и стоимость зависят от вашей квантизации и вашего инстанса, а не от чужого решения о емкости. Как сравнивать открытые и закрытые модели на длинной дистанции, разобрано в материале про open source LLM и гонку с Astra.
Что именно предсказывает модель: схема из девяти категорий
Формально задача это multi-label классификация: на вход подается название и описание товара, на выходе получается подмножество тегов из фиксированного списка девяти категорий. Пример: «беспроводные наушники с активным шумоподавлением, Bluetooth 5.3, до 30 часов работы» превращается в набор «электроника, аудио, Bluetooth, шумоподавление». Один товар получает один или несколько тегов, поэтому выход это множество, а не одно значение.
Конкретные названия категорий задает бизнес: схема из девяти пунктов в разборе Amazon взята как рабочая предпосылка, а не как отраслевой стандарт. Важна не формулировка, а закрытость списка. Конечность схемы делает результат проверяемым: набор предсказанных тегов сравнивается с эталонным программно, без человека-судьи и без LLM-оценщика.
Отсюда вырастает главное условие применимости обучения с подкреплением: если ответ нельзя проверить кодом, RLVR не сработает. Для свободного текста вроде «напиши продающее описание» такой сигнал награды не построить, потому что не с чем сравнивать.
Пайплайн кастомизации в SageMaker: от serverless SFT до RLVR
Общая последовательность: подготовка размеченного датасета, SFT, затем RLVR с GRPO, затем оценка на отложенной выборке и деплой. На этапе обучения Amazon SageMaker берет на себя инфраструктуру: serverless-кастомизация позволяет запускать job, не поднимая и не администрируя GPU-кластер самостоятельно. Платят за время обучения, а не за простой инстансов между запусками.
Такой цикл ложится на принцип, по которому работают команды с сильными ML-практиками: сначала оценивают рабочий процесс и только потом обучают, относятся к обучению как к повторяющемуся циклу и владеют инфраструктурой. Кастомизация под задачу разметки это не разовая акция: схема, данные и веса reward-функции будут меняться вместе с каталогом.
SFT: дообучение на схеме из девяти категорий
SFT это обучение с учителем на парах «товар, правильный набор тегов». Модель усваивает две вещи сразу: формат вывода (какие теги и в каком виде перечислять) и связь между текстом описания и метками. Датасет должен покрывать все девять категорий и, что важнее, их комбинации, потому что именно пересечения дают больше всего ошибок.
Именно SFT дает основной прирост качества. Это не промежуточный шаг перед «настоящим» обучением, а этап, который определяет базовое поведение модели. Размер датасета и гиперпараметры зависят от каталога: универсальной цифры нет, а публичных значений бенчмарков для этой конкретной задачи не приводится. Ориентир простой: если модель уверенно воспроизводит схему и не путает близкие категории на отложенной выборке, база готова к следующему этапу.
RLVR и GRPO: как работает обучение с проверяемыми наградами
RLVR (reinforcement learning with verifiable rewards) это обучение с подкреплением, где награду считает программа, а не человек и не языковая модель-судья. Такой сигнал дешев, воспроизводим и не приносит собственных ошибок оценки. Ограничение очевидно: награда должна быть вычислима, иначе учить не на чем.
GRPO (Group Relative Policy Optimization) это алгоритм оптимизации политики, который для одного входа генерирует группу ответов (rollout), оценивает каждый и подкрепляет те, что набрали больше баллов относительно среднего по группе. Отдельная value-модель, как в классическом PPO, не нужна. Для тегирования это выглядит так: модель несколько раз размечает один и тот же товар, reward-функция ставит оценки, политика сдвигается в сторону вариантов с лучшим набором меток.
Практический смысл второго этапа в тонкой настройке предпочтений, которые сложно описать примерами, но легко проверить сравнением. Если бизнесу важнее не потерять тег, чем избежать лишнего, это закладывается в веса награды, а не в инструкции промпта.
Детерминированная reward-функция: баланс recall и precision
Reward-функция сравнивает предсказанное множество тегов с эталонным и раскладывает расхождения на три части: верные попадания (TP), лишние теги (FP) и пропущенные теги (FN). Типовая конструкция выглядит так:
score = w_tp * TP - w_fp * FP - w_fn * FN
score = score / (TP + FP + FN)Веса w_tp, w_fp и w_fn задают приоритет бизнеса. Рост штрафа за пропуск (w_fn) поднимает полноту: модель начинает вешать теги охотнее. Рост штрафа за лишний тег (w_fp) смещает баланс в точность: модель чаще оставляет товар с меньшим набором.
Детерминированность означает, что одинаковый вход всегда дает одинаковую награду: никаких случайных сэмплов, обращений к внешней модели или человеческих оценок в цикле. Такой сигнал легко отлаживать и переносить между запусками, а поведение модели становится объяснимым: видно, за что именно она получила баллы.
Риск в другом: неверно подобранные веса ломают одну из метрик. Перекос в полноту превращает каталог в набор лишних тегов, перекос в точность заставляет терять половину полезных фильтров. Веса стоит подбирать на отложенной выборке и проверять на отдельном наборе, который не участвовал ни в SFT, ни в RLVR.
Что показали метрики: SFT дает основной прирост, GRPO смещает баланс в полноту
Итог walkthrough Amazon укладывается в одну фразу: основной прирост качества дает SFT, а GRPO добавляет небольшое смещение в сторону полноты тегов. После второго этапа модель чаще находит редкие и неочевидные метки, а точность при этом слегка проседает или остается на месте. Количественных значений в разборе не приводится, поэтому бюджет стоит планировать по качественному выводу, а не по ожиданию кратного роста метрик.
Как читать recall и precision в задаче автотегирования
Recall (полнота) это доля найденных тегов среди всех эталонных. Precision (точность) это доля верных тегов среди предсказанных. Для каталога выбор приоритета упирается в то, как теги используются дальше.
- Высокий recall нужен, если теги управляют поиском, фильтрами и подборками: пропущенный тег означает, что товар не найдется по нужному запросу.
- Высокий precision нужен, если теги формируют рекомендации и блоки на карточке: лишний тег раздражает покупателя и портит выдачу.
Компромисс задает бизнес, и reward-функция должна его отражать. Метрики, снятые один раз, не гарантируют качество через полгода: они описывают состояние на момент запуска, а состав каталога и поведение покупателей меняются. Как условия запуска и версии искажают сравнение моделей, разобрано в материале про сравнение DeepSeek, Qwen и GLM.
Почему GRPO не заменяет SFT
Соблазн пропустить первый этап понятен: если есть reward-функция, зачем тратить силы на разметку? Ответ в природе сигнала. RLVR требует, чтобы модель уже выдавала осмысленные варианты: если базовые ответы случайны, все варианты в группе получат примерно одинаковую низкую награду, и обучение либо не сойдется, либо потребует кратно больше вычислений на поиск работающей стратегии.
SFT задает базовое распределение, GRPO его уточняет. Простая аналогия: SFT это выучить язык задачи, RLVR это отточить стиль ответа под конкретные требования. Порядок не переставляется.
Деплой: асинхронный инференс на ml.g6.2xlarge для пакетной обработки каталога
После обучения модель разворачивается на инстансе ml.g6.2xlarge: это GPU-инстанс с одним ускорителем серии NVIDIA L4, которого достаточно для инференса 8B-модели при квантизации. Режим инференса выбран асинхронный, а не real-time.
Почему асинхронный режим, а не real-time endpoint
Real-time endpoint держит запрос открытым и отвечает за доли секунды: это нужно для чатов и интерактивных подсказок. Асинхронный режим принимает запрос, ставит его в очередь, обрабатывает пакетами и складывает результат в хранилище, например в S3. Клиент забирает готовый ответ позже.
Для разметки каталога задержка отдельного товара значения не имеет: никто не ждет теги в браузере. Значение имеет пропускная способность и стоимость обработки целого каталога. Асинхронный режим позволяет набивать очередь десятками тысяч позиций и не держать оплаченный инстанс включенным ровно под всплеск.
Пропускная способность и цена такого решения зависят от квантизации и конфигурации сервинга: те же веса можно обслуживать быстрее или медленнее в зависимости от ядер, формата квантизации и планирования батчей. Конкретные значения throughput для этой сборки в разборе не приводятся, и подставлять чужие цифры в бюджет смысла нет.
Как встроить разметку в существующий каталог-пайплайн
Схема, которая работает без ручного вмешательства на каждом шаге:
- Выгрузка новых и изменившихся товаров из PIM или каталога в S3.
- Формирование батч-запросов к асинхронному endpoint с описанием товара и инструкцией по схеме.
- Парсинг ответа и проверка тегов на соответствие девяти категориям.
- Запись валидных тегов в каталог, отправка невалидных позиций в очередь ручной проверки.
Шаг с валидацией часто пропускают, и зря. Модель, даже дообученная, иногда возвращает тег вне схемы или пустой набор. Без программной проверки такой ответ уедет в каталог и сломает фильтры. Простое правило: если выход не проходит валидацию по схеме, товар уходит человеку, а не в прод. Долю таких случаев стоит измерять отдельно, потому что она показывает, где именно модель расходится с вашей разметкой.
Стоимость, ограничения и подводные камни подхода
Слабые места начинаются с данных. SFT требует размеченных примеров, а разметка стоит денег и времени. Синтетика помогает расширить покрытие редких комбинаций тегов, но шум в ней напрямую переносится в модель. Serverless-обучение снижает порог входа, но не делает процесс бесплатным: платят за вычислительное время, а несколько итераций по данным и весам награды умножают счет.
RLVR добавляет инженерную сложность ради скромного прироста. Если задача допускает погрешность в пару процентов, второй этап может не окупиться: поддерживать reward-функцию, следить за балансом метрик и перепроверять веса после каждой правки схемы это отдельная работа.
Отдельно про гарантии качества. Метрики, снятые при запуске, описывают состояние на тот момент. Каталог меняется, поставщики приносят новые типы товаров, схема категорий уточняется, и модель, показавшая хороший результат в марте, к осени может требовать переобучения. Планируйте цикл, а не разовое обучение. О том, как оценивать модели и не попадаться на расхождения между тестами и реальной работой, есть материал про чтение model card и evaluation awareness.
Где подход не сработает
- Категории меняются каждую неделю: каждое изменение схемы требует нового цикла обучения, и экономика ломается.
- Результат нельзя проверить программно: оценка «качества описания» или «уместности тона» верифицируемой наградой не описывается.
- Размеченных данных мало и они противоречивы: модель выучит шум.
- Задача требует длинных рассуждений на большом контексте: 8B-модель здесь проигрывает крупным, и дообучение этого не компенсирует.
Альтернативы: frontier API, другие open-weight модели, классические ML-подходы
Frontier API остается разумным стартом: нулевая настройка, сильное поведение на редких категориях, оплата по факту. Дорого на миллионах товаров, и описания уходят наружу.
Другие open-weight модели дают выбор по размеру: модель меньше 8B дешевле в инференсе, но хуже разбирается в неструктурированных описаниях; модель крупнее точнее, но требует больше памяти и денег на обработку. Для чистой multi-label классификации по структурированным полям классические модели вроде дообученных BERT-подобных классификаторов остаются конкурентоспособными: они быстрее и дешевле, но проигрывают на свободном тексте и плохо переносят смену формулировок. Общий чек-лист по оценке новинок без шума вокруг релизов собран в материале как не потеряться в потоке запусков AI-моделей.
Кому и когда стоит повторять этот подход
Проверьте свою задачу по списку. Кастомизация Qwen3-8B в SageMaker с SFT и RLVR оправдана, если:
- задача повторяется регулярно и ее объем растет;
- результат проверяется программно по фиксированной схеме;
- разметка есть или ее можно собрать в обозримые сроки;
- схема меток стабильна хотя бы на квартал;
- стоимость вызовов frontier API на вашем объеме заметна в бюджете;
- в команде есть человек, который будет вести цикл обучения, а не только первичный запуск.
Если выполняется меньше половины пунктов, начните с API и вернитесь к кастомизации, когда накопите данные и объем. Логика SFT плюс RLVR переносится и на другие задачи с проверяемым результатом: модерацию контента по формальным правилам, маршрутизацию обращений, извлечение структурированных полей из документов. Критерий один: ответ можно посчитать, а не оценить на вкус.
Практический первый шаг, который стоит сделать до любого обучения: соберите 300-500 товаров, разметьте их по своей схеме и проверьте, сколько ошибок дает текущий вызов frontier-модели или базовая Qwen3-8B без дообучения. Эта выборка станет и аргументом в пользу кастомизации, и первым фрагментом датасета для SFT, и отложенным набором для проверки reward-функции.