Описание товара с помощью нейросети: из проверенных характеристик в готовую карточку

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

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

Когда нейросеть полезна для описаний товаров

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

Важно разделить три операции:

1. Сотрудник или согласованный импорт собирает и проверяет характеристики.
2. Нейросеть готовит формулировки только из разрешённых полей.
3. Редактор или формальная проверка сопоставляет карточку с исходной строкой.

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

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

Как подготовить исходную таблицу

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

SKU должен быть стабильным идентификатором, а не случайным названием товара. Единицу измерения храните отдельно от числа: значение 20 без л/мин нельзя безопасно использовать. В поле источника укажите, откуда взята характеристика: утверждённая карточка поставщика, технический документ или запись ответственного сотрудника. Само наличие значения ещё не означает, что оно проверено, поэтому статус нужен отдельно.

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

Фотография помогает описать только видимые признаки: цвет, форму, расположение элементов или надписей, если изображение достаточно ясное и относится к нужному SKU. По фотографии нельзя подтверждать материал корпуса, мощность, внутреннее устройство или гарантию. Даже если поверхность похожа на металл, слово «стальной» не должно попадать в карточку без разрешённого источника.

Как задать шаблон карточки и ограничения канала

Разделите результат на четыре части:

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

Для каждого блока задайте разрешённые поля. Например, название может использовать тип товара и модель, но не рекламное обещание. В характеристиках допустимы только пары «атрибут — значение», прошедшие проверку. В описании разрешены нейтральные редакторские связки, но запрещены новые технические свойства, гарантии, сценарии применения и сравнения, которых нет в таблице.

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

Google Merchant Center — пример отдельного канала, а не общая норма для всех площадок. В его документации идентификатор товара, название и описание входят в спецификацию данных, а для структурированных дополнительных характеристик предусмотрен атрибут product_detail. Документация также предупреждает, что неверные, неточные или отсутствующие сведения могут привести к отклонению, ограничению показа или неправильному отображению товара. Это не доказывает рост позиций или продаж и не заменяет проверку требований сайта либо конкретного маркетплейса.

Перед подключением канала нужно отдельно сверить актуальный формат, доступный способ передачи данных и права. Упоминание Google Merchant Center здесь не означает проверенную совместимость будущего решения Switch On AI с аккаунтом или тарифом заказчика.

Как генерировать и проверять текст

Удобно разделить элементы карточки на три группы.

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

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

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

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

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

Как публиковать, версионировать и обновлять карточки

Свяжите каждый SKU с единственным назначенным адресом карточки. Название для этой связи не подходит: его можно отредактировать, перевести или дополнить, не меняя сам товар. Перед публикацией процесс ищет запись по стабильному SKU. Если запись существует, он готовит обновление; если нет — создаёт новую карточку по согласованному правилу.

Для каждой операции сохраняйте:

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

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

Учебный пример карточки насоса с неизвестным материалом

Ниже — синтетический пример для объяснения правил. Это не файл поставщика, не клиентский кейс и не результат внедрения Switch On AI.

Исходная строка ревизии R1:

• SKU: N-20;
• название: «Насос N-20»;
• питание: 220 В;
• расход: 20 л/мин;
• материал корпуса: неизвестно;
• гарантия: неизвестно;
• источник: учебные данные;
• ревизия: R1.

Допустимое описание:

Насос N-20 рассчитан на питание 220 В. Указанный расход — 20 л/мин. Материал корпуса и гарантийный срок в исходных данных не указаны; перед публикацией этих характеристик требуется подтверждение.

Отклонённый вариант: «Стальной насос N-20 с гарантией два года». В исходной строке нет ни материала, ни срока гарантии. Поэтому оба утверждения выдуманы. При исправлении важно сохранить подтверждённые значения 220 В и 20 л/мин, а не удалить всю полезную информацию вместе с ошибкой.

Если каналу нужен расход в м³/ч, преобразование должно быть прозрачным: 20 л/мин × 60 мин/ч ÷ 1000 л/м³ = 1,2 м³/ч. В карточке сохраняется исходное значение 20 л/мин, а 1,2 м³/ч помечается как вычисленное представление, а не как новая независимая характеристика.

Теперь появляется ревизия R2: SKU остаётся N-20, а расход меняется с 20 до 25 л/мин. Пересчёт даёт 25 × 60 ÷ 1000 = 1,5 м³/ч. Процесс находит существующую карточку по SKU, обновляет расход и сохраняет R1 в истории. Второй товар не создаётся. Если изменилось только название, правило остаётся тем же: владельцем карточки служит SKU, а не текст заголовка.

Как принять процесс и запустить пилот

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

Минимальный набор проверок:

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

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

Switch On AI разрабатывает ИИ-помощников, ботов и интеграции для отдельных операций. Для этого процесса можно согласовать ограниченный пилот: получить разрешённую таблицу, сформировать карточки, показать источники утверждений и проверить обновление одного SKU. Конкретный тип решения выбирают после проверки данных и API: при фиксированном маршруте может быть достаточно обычной интеграции, а ИИ-помощник нужен для подготовки формулировок в заданных границах.

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