AI в eCommerce: как превратить разрозненные товарные данные в надёжный каталог

AI может написать описание товара за несколько секунд.

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

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

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

При этом результат модели всё равно нельзя принимать без проверки.

Где AI действительно полезен

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

Сложнее работать с информацией, смысл которой зависит от контекста.

Например, один поставщик передаёт материал товара отдельным атрибутом. Другой упоминает его только в описании. Третий использует сокращение или собственную систему наименований.

Все эти случаи можно покрывать отдельными правилами. Но чем больше источников и форматов, тем сложнее такую систему поддерживать.

AI может помочь:

• извлекать атрибуты из неструктурированного текста;
• сопоставлять разные формулировки с единой внутренней моделью;
• преобразовывать описания в заданный набор полей;
• предлагать или ранжировать категории из существующей таксономии;
• подготавливать и адаптировать товарный контент.

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

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

Даже после корректного маппинга остаётся проверить, верно ли модель поняла исходные данные.

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

Допустим, модель получает описание товара и возвращает материал, цвет и тип застёжки в структурированном виде. Проверить формат ответа недостаточно.

Нужно также убедиться, что:

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

Последний пункт особенно важен. Leather может быть допустимым значением в справочнике материалов, но это ещё не доказывает, что конкретный товар сделан из кожи.

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

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

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

Языковая модель способна вернуть убедительный и хорошо структурированный ответ даже при недостатке исходной информации.

Например, она может:

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

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

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

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

Хороший prompt важен, но основной контроль обеспечивает процесс вокруг модели.

Как встроить AI в контролируемый процесс

В упрощённом виде схема выглядит так:

Перед отправкой запроса модели система должна определить:

• какие данные получает модель;
• какую операцию она выполняет;
• какие поля ей разрешено изменять;
• какие значения допустимы;
• в каком формате должен вернуться ответ;
• что делать при отсутствии информации.

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

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

Структурированный ответ позволяет программно проверить обязательные поля, типы данных и формат.

Однако соответствие схеме ничего не говорит о фактической правильности содержимого.

Поэтому валидацию лучше проводить на нескольких уровнях:

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

После валидации данные уже можно передавать в commerce-платформу. Дальше важен сам способ интеграции и то, как он учитывает структуру каталога.

Способ передачи данных зависит от конкретной архитектуры, но роль модели от этого не меняется. Модель остаётся одним из этапов обработки и не отвечает за конечное состояние каталога.

AI нужно проверять до запуска

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

Нескольких удачных примеров для этого мало.

Процесс нужно протестировать на репрезентативной выборке реальных товарных данных, для которых заранее известны правильные результаты. Такая проверка позволяет увидеть:

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

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

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

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

Эти проверки помогают понять, можно ли использовать результат AI в рабочем процессе. Но даже после этого остаются вопросы уже не к модели, а к самой commerce-архитектуре: в каком виде данные должны поступать в Magento, какая система ими владеет и где должна находиться логика преобразований.

Именно здесь начинается зона экспертизы Foxycom.

Что происходит после AI: Magento-перспектива Foxycom

Какие данные должна получать Magento?

В идеале к моменту передачи данных в Magento их интерпретация уже должна быть завершена. Magento должна получать товарную запись в собственной модели каталога: canonical SKU, явно определённые product type и attribute set, назначения категорий, attribute codes, разрешённые значения select- и multiselect-атрибутов, а также правильный store-view context для полей с соответствующим scope.

Для configurable products также должны быть заранее известны дочерние SKU, configurable attributes и значения их опций. Типичные ошибки на этом этапе обычно связаны уже не с AI, а с маппингом: отсутствующим option value, атрибутом вне назначенного attribute set, некорректным category ID, неполными идентификаторами товара или store-scoped значением, записанным не в том контексте.

Magento должна валидировать и сохранять товарную запись. Ей не следует самостоятельно определять, что именно подразумевалось во входящих данных.

Где должна проходить граница между Magento и внешним слоем?

Мы проводим эту границу так, чтобы интерпретация, обогащение и нормализация происходили за пределами Magento, а сама Magento применяла commerce-правила каталога при сохранении данных.

Внешний слой может извлекать атрибуты, нормализовывать терминологию, сопоставлять категории и значения атрибутов, дедуплицировать исходные записи и подготавливать canonical product payload. Magento затем применяет платформенные правила, связанные с товарами, категориями, связями, scope и целостностью каталога.

Не менее важно явно определить владельца каждого поля. Внешний content pipeline может отвечать за описания, обогащённые с помощью AI, тогда как цена и остатки могут принадлежать ERP или Magento в зависимости от общей архитектуры. Для каждого поля должен быть понятен source of truth и направление обновления.

То же относится к mapping logic. Сопоставления категорий, атрибутов и значений должны храниться в одном месте. Если одинаковые правила независимо реализованы в middleware и Magento import scripts, со временем они начнут расходиться. Результатом могут стать конфликтующие обновления, ошибки синхронизации и feedback loops между системами.

Что определить перед внедрением AI

Перед добавлением модели в процесс работы с товарными данными стоит ответить на несколько вопросов.

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

AI должен решать конкретную задачу

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

На практике ценность появляется тогда, когда роль модели ограничена конкретной операцией, а итоговое решение остаётся за системой. Модель может извлечь, структурировать или предложить значение, но правила, по которым оно становится частью каталога, должны оставаться контролируемыми.