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

Это особенно важно для дистрибьюторов, ритейлеров и производителей. Один поставщик укажет упаковку как «12 x 500 ml», другой — «6 L», третий — «24 шт. по 500 мл». ИИ способен обнаружить связь между этими значениями, но не должен без доказательств решать, что именно является продаваемой единицей, транспортной коробкой или уровнем упаковки.

Задача — не прочитать файл, а управляемо принять мастер-данные товара

Файлы поставщиков отличаются языком, заголовками колонок, классификацией, единицами измерения, структурой упаковки и полнотой данных. В одной таблице могут быть GTIN и артикул производителя, но отсутствовать габариты. В PDF критичная характеристика может быть в абзаце, примечании или на сканированном изображении. Название «Pro Clean 5L» само по себе не доказывает, является ли 5L нетто-объёмом, объёмом коробки или частью наименования линейки.

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

  1. Зафиксировать файл, поставщика, дату получения и версию.
  2. Извлечь таблицы, текст и данные вложений в набор кандидатных полей.
  3. Сопоставить запись с существующим товаром по разрешённым идентификаторам.
  4. Привязать поля поставщика к каноническим атрибутам и схеме категории.
  5. Нормализовать единицы, форматы, справочные значения и словарь терминов.
  6. Проверить полноту, согласованность, дубликаты и межполевые правила.
  7. Направить исключения ответственному сотруднику вместе с доказательствами.
  8. Создать или обновить одобренную запись в PIM/ERP и только затем открыть публикацию по каналам.

Подход GS1 Global Data Model показывает, почему единого набора обязательных полей недостаточно: часть атрибутов зависит от категории товара и рынка. На практике матрица требований должна учитывать тип продукта, географию, канал продаж и уровень упаковки.

Что должен делать ИИ, а что оставлять человеку

Извлекать предложения по атрибутам

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

Она может распознать, что «24 × 330 ml», «0.33 L x 24» и «7.92 L/case» связаны. Но нужно сохранить исходное значение, правило преобразования и контекст. Если источник не подтверждает, является ли case продаваемой единицей или логистической тарой, запись должна стать исключением для проверки, а не автоматически заполненным фактом.

Нормализовать значения и предлагать категорию

На этапе нормализации SKU-атрибутов с ИИ можно привести «cm», «centimetre» и локальные варианты обозначений к утверждённому представлению, обработать десятичные разделители, регистр, цвета, материалы и собственные термины поставщика. Модель также может предложить категорию по названию и характеристикам.

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

Создавать описания только из одобренных фактов

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

Такой контроль предотвращает появление неподтверждённых фраз вроде «премиальное качество», «экологичный», «высокая производительность» или «идеально подходит для профессионального использования». Редакционный текст можно согласовывать отдельно, но неполные данные поставщика не должны превращаться в неподтверждённые маркетинговые заявления.

Прослеживаемость источника: откуда взялось каждое значение

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

  • поставщик, идентификатор файла, версия и время загрузки;
  • лист, строка и колонка в Excel либо страница и область текста в PDF;
  • исходное значение или фрагмент, подтверждающий атрибут;
  • извлечённое значение и каноническое нормализованное значение;
  • версия правила сопоставления, преобразования и проверки;
  • уровень уверенности и причина исключения;
  • сотрудник, решение, время и причина ручного переопределения.

Например, для предложенного брутто-веса 12 кг проверяющий должен увидеть исходное «12,0 KG», понять, как была нормализована запись, и проверить соответствие уровню упаковки. Ответ ИИ без доступного для проверки источника не является достаточным мастер-данным товара.

Порог уверенности — это сигнал маршрутизации, а не универсальная истина

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

  • Автоматическая подготовка черновика: надёжно сопоставлен идентификатор, есть источник, заполнены обязательные поля и нет нарушений правил.
  • Быстрая проверка человеком: неуверенное предложение категории, описания или низкорискового атрибута.
  • Обязательное одобрение специалистом: GTIN, продаваемая единица, нетто/брутто-вес, габариты, безопасность, регулируемые поля и перезапись уже утверждённых данных.
  • Блокировка: источники противоречат друг другу, идентичность неясна, арифметика упаковки не сходится или отсутствуют обязательные доказательства.

Рамка NIST AI RMF подчёркивает необходимость определённых ролей человека, документированного контроля и мониторинга после запуска. Для товарного каталога это означает ясные ответы на вопросы: кто утверждает запись, кто вправе изменить извлечённое значение, какие исключения эскалируются и как измеряется качество решений.

Защитный слой интеграции PIM и ERP

Интеграция с системой управления товарной информацией (PIM) должна чётко разделять владение данными. Во многих компаниях PIM отвечает за обогащённый контент и готовность к каналам продаж, а ERP — за операционные, закупочные, финансовые или складские поля. Конкретная модель зависит от архитектуры, но ИИ-слой не должен иметь неограниченное право менять оба источника данных.

В производственной интеграции необходимы:

  • стратегия идентификации: внутренний SKU, GTIN, код поставщика и уровень упаковки;
  • раздельные права на создание, обновление, объединение и публикацию;
  • владение на уровне поля: например, закупочная единица из ERP, веб-описание из PIM;
  • проверки типов, диапазонов, справочников, единиц и взаимосвязанных полей;
  • сравнение изменений и approval до замены утверждённого значения;
  • идемпотентные API-операции, повторы и очередь исключений;
  • проверки полноты по каждому каналу перед публикацией.

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

Как начать с практического пилота

  1. Выберите одного поставщика, одну товарную группу и ограниченный набор атрибутов.
  2. Опишите целевую схему, справочники, требования каналов и владельцев полей.
  3. Соберите из исторических файлов эталонный набор с известными правильными решениями.
  4. Измеряйте отдельно извлечение, сопоставление, нормализацию, валидацию и одобрение.
  5. Дайте reviewer-ам экран с источником, предложенным значением, различиями и групповыми действиями.
  6. Начните с создания черновиков, а не с прямой публикации.
  7. Отслеживайте долю принятых записей, ручные правки, причины исключений, дефекты по поставщикам и время обработки.

POLADO может спроектировать такой контролируемый процесс в рамках AI-решений и автоматизации: от приёма файлов поставщиков и фиксации доказательств до очередей проверки, правил и безопасной интеграции PIM/ERP. Для рабочего интерфейса reviewer-а важны UI/UX и продуктовый дизайн, а для надёжной публикации на сайте или B2B-портале — веб-платформы и приложения.

Если ваша команда вручную очищает каталоги поставщиков, повторно проверяет одни и те же SKU или исправляет ошибки уже после публикации, начните с консультации POLADO. Можно ограничить первый этап анализом образцов файлов, целевой модели атрибутов, правил проверки, владельцев PIM/ERP и маршрутов одобрения. Цель первого пилота — измеримое качество проверки и безопасный процесс, а не бесконтрольный бот для публикации каталога.