Обогащение карточек товаров малыми моделями без лишних затрат

Почему карточки товаров быстро теряют качество

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

Проблема начинается на входе. Поставщики присылают данные в разном виде: где-то цвет лежит в отдельном поле, где-то спрятан в названии, а где-то указан как "ассорти". Один и тот же параметр пишут по-разному: "черный", "чёрный", black, blk. Для человека это одно и то же. Для каталога - уже нет.

Часто в одном названии смешано все сразу: бренд, тип товара, цвет, размер, материал и артикул. Например: "Nike Hoodie M Black Cotton 2024". Если такую строку никто не разбирает по полям, магазин получает карточку, где атрибуты как будто есть, но фильтры и поиск их не видят.

Ручное заполнение тоже быстро добавляет хаос. Один менеджер пишет "XL", другой - "50", третий оставляет поле пустым, потому что размер уже есть в названии. То же происходит с материалами, сезонами и стилем. Через месяц в каталоге уже живут несколько правил, и ни одно не соблюдают до конца.

От этого страдают не только карточки. Покупатель открывает фильтр по цвету и не видит часть товаров. Поиск по запросу "синяя рубашка linen" пропускает позиции, где цвет остался в названии, а материал не заполнен. Магазин теряет показы не потому, что товара нет, а потому что каталог описан неровно.

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

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

Что малая локальная модель делает хорошо

Малая локальная модель хорошо справляется там, где товар не нужно "понимать" глубоко, а нужно аккуратно разобрать по понятным правилам. Если в названии и характеристиках уже есть сигнал, модель быстро вытаскивает бренд, материал, объем, вес, размер и другие простые атрибуты.

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

Хороший пример - одежда и бытовые товары. Из строки вроде "Футболка жен. хлопок 95%, эластан 5%, р-р M, черн." модель обычно без проблем собирает нормальный набор полей: женская футболка, размер M, материал "хлопок 95%, эластан 5%", цвет "черный".

Она так же уверенно ведет себя в категориях, где теги строятся по простым правилам. Если товар попал в раздел "кофе", модель может поставить теги вроде "зерновой", "250 г", "средняя обжарка", когда эти признаки есть в тексте или таблице.

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

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

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

Если команде нужны хранение данных внутри страны и низкая задержка, такой сценарий особенно удобен на локально размещенных open-weight моделях. У AI Router для этого есть собственный хостинг таких моделей, поэтому поток с атрибутами, тегами и короткими описаниями можно держать ближе к внутренним системам и не усложнять схему без причины.

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

Где локальная модель начинает ошибаться

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

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

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

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

Еще одна слабая точка - длинные правила совместимости. Когда нужно учесть год выпуска, ревизию, размер крепления, региональную версию и исключения, модель теряет часть условий. Она может сократить фразу так, что смысл меняется. Например, вместо "подходит для моделей 2021-2023, кроме версии Pro" остается просто "подходит для моделей 2021-2023".

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

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

Какие данные стоит дать на вход

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

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

Категорию и бренд тоже лучше передавать явно, отдельными полями. Это сильно сужает выбор слов. Если модель знает, что перед ней не просто "Nike Air", а "кроссовки" бренда Nike, она реже путает тип товара, пол, сезон и стиль.

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

Хорошо помогает и набор образцов. Для каждой категории стоит показать 5-10 удачных примеров с тем форматом ответа, который вы хотите получить. Один пример для обуви, один для футболок и один для сумок - слабая схема. Модель лучше держит стиль и структуру, когда примеры похожи на текущий товар.

Если у вас поток одежды, дайте модели такой контекст: название "Женская рубашка oversize", категория "рубашки", бренд, описание поставщика, подпись к фото "длинный рукав, хлопок, белый цвет" и список разрешенных значений для цвета, материала и силуэта. В таком виде она обычно выдает аккуратный JSON и не лезет в догадки про то, чего нет в карточке.

Перед запуском входные данные стоит почистить. Уберите дубли, обрывки HTML, служебные артикулы в описании, мусорные слова вроде "новинка топ хит" и склеенные поля из выгрузки. Если в каталоге три одинаковых описания с разными SKU, модель начнет повторять старые ошибки быстро и массово.

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

Как запускать по шагам

Для начала не пытайтесь заполнить все сразу. Лучше выбрать 3-5 полей, где ответ легко проверить по источнику за минуту. Для первого запуска обычно подходят атрибуты с понятным набором значений: цвет, материал, сезон, тип товара.

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

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

{
  "attributes": {"color": "", "material": "", "season": ""},
  "tags": [],
  "short_description": "",
  "needs_review": false
}

После этого проверьте все на небольшой выборке. Не берите 10 идеальных карточек от одного поставщика. Возьмите 100-200 товаров с разным качеством исходных данных, чтобы увидеть реальные ошибки до запуска в каталог.

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

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

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

Пример на потоке одежды

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

Например, в выгрузке приходит запись: "Футб жен oversize молоч 95хл 5эл L арт 1842". Человеку смысл понятен, но в каталог такую строку ставить нельзя. Модель разбирает ее на простые атрибуты и кладет их в нужные поля.

На выходе магазин получает уже не сырой текст, а структуру: пол "женский", материал "хлопок 95%, эластан 5%", цвет "молочный", размер L и тип товара "футболка".

После этого та же модель может поставить теги для каталога и поиска. Обычно хватает короткого набора без фантазии: "женская одежда", "футболка", "oversize", "хлопок", "базовая". Это лучше, чем длинный список почти одинаковых тегов, который только засоряет фильтры.

Короткое описание тоже можно сгенерировать локально, если держать задачу узкой. Нормальный вариант звучит так: "Женская футболка свободного кроя из хлопка с добавлением эластана. Мягкая ткань, молочный цвет, размер L". Здесь есть смысл, но нет рекламного шума, лишних обещаний и случайных слов про "премиум".

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

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

Какие ошибки команды делают чаще всего

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

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

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

Многие команды еще и слабо тестируют результат. Они смотрят на 20 случайных карточек, видят, что "в целом нормально", и запускают поток. Потом выясняется, что на дублях, сокращениях и продавцовом жаргоне модель сыпется. "ХБ" и "хлопок", "муж" и "мужской", "48 RU" и "L" часто разъезжаются по разным полям, хотя смысл один.

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

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

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

Быстрый чек перед запуском

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

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

Для каждого поля заранее зафиксируйте допустимые значения. Если поле "цвет" должно принимать только значения из вашего справочника, модель не должна писать "светло-графитовый с холодным подтоном", когда в системе есть только "серый". Свободный текст оставляйте лишь там, где он действительно нужен, например для короткого описания товара.

Что проверить на тесте

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

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

Сразу определите маршрут для ручной проверки. Кто смотрит сомнительные карточки, сколько времени уходит на одну, и при каком пороге вы отправляете результат человеку. Если ревьюер тратит даже 20-30 секунд на карточку, это уже заметная строка расходов на большом потоке.

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

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

Что делать дальше

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

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

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

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

Если у вас смешанная схема, где часть задач идет на локальные open-weight модели, а часть во внешние API, лучше не собирать отдельную обвязку под каждый маршрут. Проще держать единый вход для обеих сторон. В этом сценарии можно использовать AI Router или api.airouter.kz: сервис дает один OpenAI-совместимый эндпоинт, через который удобно разводить трафик между локальными моделями и внешними провайдерами без смены SDK, кода и промптов.

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

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