Контент-конвейер для большого каталога — это не массовый вызов генеративной модели. Это производственный процесс, который превращает проверенные мастер-данные в версии карточек для разных каналов и не позволяет тексту расходиться с характеристиками, остатками, ценой и юридическими ограничениями.
Единицей управления должен быть не файл и не промпт. А задача по SKU с состоянием: данные готовы, генерация выполнена, проверки пройдены, требуется редактор, утверждено, опубликовано, отклонено. Тогда любую карточку можно воспроизвести, объяснить и безопасно обновить при изменении источника.
Как я собираю поток
Входом служат PIM/ERP, медиатека, справочники бренда и правила площадки. Сначала данные нормализуются и проверяются: категория, единицы измерения, вариант, обязательные атрибуты, допустимые заявления. Только после этого формируется канал-специфичное задание на заголовок, описание, характеристики и alt-тексты.
Результат проходит машинные проверки и выборочную редактуру. Публикационный адаптер собирает фид или API-запрос, а обратная синхронизация фиксирует статус площадки. Ошибка конкретного канала не должна блокировать остальные и тем более не должна изменять мастер-данные обратным импортом.
Что я проверю до первой партии
Кейс из каталожного потока · Gimba. У Gimba каталог примерно из 30 000 товаров, а ежемесячно добавляется около 300 новых позиций от разных производителей и в разных форматах. Компания собрала AI-платформу, обучив ожидаемый стандарт на выборке из 900 хорошо описанных товаров; время регистрации одной позиции сократилось с 13 до 2 минут. Что здесь можно забрать в поток: кейс показывает зрелый content conveyor: сначала эталон и нормализованные данные, затем генерация, а не наоборот. Источник: AWS ↗
Шаблон контента состоит не только из текста инструкции. Он включает схему входа, список разрешённых фактов, правила канала, примеры допустимого результата и автоматические тесты.
Версия шаблона меняется вместе с тестами. Это позволяет ответить, почему две карточки одного SKU различаются, и безопасно воспроизвести старую поставку.
Пакетная обработка нуждается в backpressure. Если канал начал отклонять запросы или QA обнаружил системный дефект, новые партии приостанавливаются. А уже подготовленные не смешиваются с исправленными.
Статус хранится на уровне SKU и канала. Повторная отправка выполняется идемпотентно и не создаёт дубликаты публикаций.
Редактору показывают не весь каталог, а приоритетную очередь. В неё попадают новые категории, изменения критичных атрибутов, низкая уверенность, конфликт фактов и выборочная контрольная доля.
Одобрение сохраняется как решение по конкретной версии. Если мастер-данные изменились позже, старое согласование не считается действующим автоматически.
Что должно быть единицей работы
- Master data first. Факты поступают из систем учёта; модель не создаёт цену, состав, габариты или совместимость.
- Версия шаблона. Каждый результат связан с версией правил бренда, канала и генерации.
- Разделение факта и текста. Характеристики хранятся структурированно, а описание является их представлением.
- Канал-специфичность. Один SKU получает разные допустимые представления, а не один текст, скопированный повсюду.
- Инкрементальные обновления. Перегенерируются только поля и каналы, затронутые изменившимися данными.
Как данные проходят через конвейер
Оркестратор получает событие изменения SKU и создаёт задачи по каналам. Валидатор мастер-данных останавливает неполные записи. Генератор получает только разрешённый контекст, после чего lint-слой проверяет длину, запрещённые слова, соответствие атрибутам и формат.
Хранилище версий содержит входные данные, шаблон, результат, правки и публикационный ответ. Оно позволяет сравнить две версии и откатить неудачную поставку. Для изображений действует такой же принцип: исходный asset отделён от канал-специфичного экспорта и его кропов.
Где ставить QA
На этой партии критерий: риск нужно связывать с наблюдаемым сигналом и заранее определённым действием. Для потока я бы задала правило: наблюдаемый сигнал заранее связываем с действием, чтобы после инцидента команда не угадывала причину вручную.
| Риск | Как проявляется | Контроль |
|---|---|---|
| Галлюцинация свойства | В тексте появилось преимущество, которого нет в данных | Генерация только из allowlist полей и факт-чек каждого утверждения |
| Смешение вариантов | Цвет или размер одного SKU попал в другой | Жёсткие variant IDs и изоляция контекста |
| Массовая ошибка шаблона | Плохое правило затронуло весь каталог | Canary-пакет, лимит партии и быстрый rollback |
| Расхождение каналов | Фид и страница показывают разные цену или наличие | Единый источник и мониторинг расхождений |
| Потеря правок редактора | Повторная генерация затирает ручное исправление | Блокировки полей и политика merge |
Как я измеряю здоровье каталога
Перед первой партией я снимаю baseline потока. Для потока я бы задала правило: считаем метрики по завершённому бизнес-результату и отдельно по сценарию, версии и причине исключения. Одно среднее скрывает деградацию.
| Метрика | Что показывает | Как разрезать |
|---|---|---|
| Проходимость first pass | доля SKU без возврата на исправление | по категории и шаблону |
| Стоимость опубликованного SKU | генерация, проверки и редактура | по каналу |
| Время от данных до публикации | полный lead time | P50/P95 |
| Доля расхождений | конфликты страницы, фида и мастер-данных | по полям |
| Rollback rate | частота откатов пакетов | по версии правила |
Как запускать партиями
- 01
Выбрать одну категорию и описать каноническую схему атрибутов.
- 02
Зафиксировать правила каждого канала и запрещённые утверждения.
- 03
Собрать версионируемый шаблон и контрольный набор SKU.
- 04
Добавить машинные проверки до этапа редактора.
- 05
Публиковать canary-партиями с журналом ответа площадки.
- 06
После стабильного first pass расширять категории и объём партии.
Короткий QA перед масштабированием
На этой партии критерий: перед включением реального потока команда проходит короткий операционный чек-лист. Для потока я бы задала правило: считаем пункт закрытым только когда есть проверяемый артефакт: настройка, тест, журнал или назначенный ответственный.
- Товар, вариант и предложение имеют разные идентификаторы
- Модель получает только разрешённые факты текущего SKU
- Каждый результат связан с версиями входа и шаблона
- Ошибка канала не блокирует публикацию в другие каналы
- Ручные правки защищены от случайной перегенерации
- Есть canary-партия и процедура отката
Вопросы про SKU, правила и исключения
Можно ли генерировать сразу весь каталог?
Технически можно, но безопаснее начинать с категории и малых партий: ошибка шаблона масштабируется так же быстро, как удачный процесс.
Где хранить промпты?
Как версионируемый код или конфигурацию рядом с правилами и тестами, а не в личных заметках оператора.
Нужен ли человек на каждой карточке?
Не обязательно. Доля проверки зависит от риска категории, стабильности шаблона и результатов автоматических проверок.
С какой партии я бы начала
На диагностике я фиксирую узкое место, данные, ручную нагрузку, QA и реалистичную первую партию.
Источники и правила каналов
- Product data specificationGoogle Merchant Center
- Introduction to Product structured dataGoogle Search Central
- Product detail attributeGoogle Merchant Center
- Set up structured data for Merchant CenterGoogle Merchant Center
- ProductSchema.org
- OfferSchema.org
- GS1 Data Quality Framework for Brand OwnersGS1
- Merchant Center product data specification update 2024Google Merchant Center
Источники и методическая база
- Product data specificationGoogle Merchant Center
- Introduction to Product structured dataGoogle Search Central
- Product detail attributeGoogle Merchant Center
- Set up structured data for Merchant CenterGoogle Merchant Center
- ProductSchema.org
- OfferSchema.org
- GS1 Data Quality Framework for Brand OwnersGS1
- Merchant Center product data specification update 2024Google Merchant Center
- Gimba adopts generative AI on AWS to enhance its product catalogAWS
