Что действительно сделал Mystore

Индийская площадка Mystore помогает небольшим продавцам размещать товары в сети ONDC. В опубликованном Google Cloud кейсе её сооснователь Раджив Кумар говорит, что согласование карточки, прежде занимавшее один-два дня, теперь укладывается менее чем в час. Он же оценивает рост операционной эффективности этого процесса в 60–70%. Это показатели самой компании в материале поставщика облака, а не независимо проверенный результат и не обещание для другого магазина.

Задача здесь шире генерации красивого описания. Продавцы загружают неоднородные фотографии и неполные сведения; площадке нужно получить заголовок, категорию, атрибуты и корректное изображение, затем проверить соответствие правилам каталога. По описанию Google Cloud, Mystore использует Gemini через Vertex AI для подготовки названий, описаний, категорий и индийских товарных кодов HSN по изображению. Отдельный инструмент очищает фон и центрирует фото. Контроль качества и соответствия требованиям ONDC встроен в согласование карточки.

В этом кейсе важна граница: материал не раскрывает точную долю автоматических одобрений, методику расчёта 60–70%, цену обработки карточки и частоту ошибок в обязательных атрибутах. «Менее часа» — время процесса по сообщению Mystore, а не гарантированная задержка каждого товара. Российскому магазину стоит перенять устройство процесса, а не переносить эти цифры в бизнес-план.

Как разложить задачу на проверяемые шаги

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

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

Такой конвейер отличается от команды «напиши описание по картинке». Модель может уверенно назвать материал, мощность или комплектацию, которые на фото не видны. В исследовании GAVEL, опубликованном в материалах ACL, извлечение атрибутов рассматривается как отдельная измеряемая задача; результаты там относятся к своим наборам товаров и языкам, а не подтверждают точность решения Mystore или любого локального пилота. Для собственного каталога нужна своя размеченная проверочная выборка.

Где уместен локальный ИИ

Mystore использует облачную архитектуру Google; кейс не доказывает, что его показатели воспроизводимы локально. Но сам процесс можно перенести в защищённый контур, если фотографии поставщиков, закупочные условия или внутренние справочники нельзя передавать внешнему API. Для этого понадобятся доступ к каталогу и очереди карточек, хранилище оригинальных файлов, справочник допустимых атрибутов, журнал решений, система ролей и среда запуска мультимодальной модели. Мощность сервера выбирают после замера на своих изображениях и требуемом потоке, а не по одному бенчмарку.

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

Интеграция с PIM, CMS или маркетплейсом должна отделять чтение от записи. Сначала система формирует предложение в отдельной очереди; затем после проверки отправляет разрешённые поля через штатный API. Нужны идентификатор операции для защиты от повторов, журнал исходных значений и возможность откатить изменение карточки. Для товаров с маркировкой, сертификатами, медицинскими или иными регулируемыми свойствами автоматическое заполнение без документального подтверждения особенно рискованно.

Экономика без чужих процентов

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

Модельный пример, не результат Mystore: если оператор вручную тратит 8 минут на карточку, а проверка ИИ-черновика занимает 3 минуты, экономия на 1000 принятых карточек составит около 83 часов до учёта повторной обработки, инфраструктуры и ошибок. Если половина черновиков возвращается на доработку по 6 минут, это ещё 50 часов работы; ожидаемый эффект резко уменьшается. Подставлять в расчёт следует свои замеры, а не 60–70% из чужого кейса.

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

Пилот, который можно закончить за две недели

Выберите одну товарную категорию и 200–300 уже обработанных карточек с исходными фотографиями и проверенными атрибутами. Отложите часть товаров для финальной проверки и не используйте её при настройке подсказок. Заранее задайте критические поля и ошибки, которые нельзя пропускать. На первой неделе проверьте извлечение и правила без записи в рабочий каталог; на второй — дайте редактору сравнивать предложенный черновик с исходниками.

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

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