Публичной статистики о том, как продавцы маркетплейсов реально пользуются нейросетями, почти нет: обзоры пересказывают друг друга, а цифры остаются внутри сервисов. Мы делаем banan.wtf — сервис, который из одного фото товара собирает карточку для Wildberries и Ozon, — и решили показать свои данные.
Под катом: почему «идеальный промпт» — миф и пользователи мыслят диффами, а не промптами; в какое время суток селлеры на самом деле делают контент; что случилось со спросом этим летом — и как устроен пайплайн, который всё это переживает: fan-out на подзадачи, каскад моделей с фолбэком и realtime-прогресс через Redis pub/sub.
Дисклеймер: мы — заинтересованная сторона, поэтому в статье нет сравнений с конкурентами и «рейтингов». Только наши агрегированные данные и инженерные детали.
Откуда данные и что мы считали
Всё, что ниже, — обезличенные агрегаты сервиса за декабрь 2025 — июль 2026: суммарно более 7 500 генераций изображений. «Задачей» мы называем цепочку «исходное фото + все его правки»; статистику итераций и времени суток считали по последним 90 дням — это около 1 300 задач.
Никакие пользовательские изображения и тексты запросов не анализировались и не публикуются; часть цифр намеренно округлена. И важная оговорка: это данные одного сервиса с его аудиторией — переносить их на «весь рынок» стоит с осторожностью.
Миф об идеальном промпте
Самая устойчивая находка в данных — то, как на самом деле выглядит работа с генератором.
71% задач закрываются первой же генерацией: пользователь загрузил фото, выбрал шаблон или описал задачу — и результат сразу ушёл в карточку. Но оставшиеся 29% — самое интересное. Это не «неудачные» генерации: это нормальный рабочий процесс, где человек доводит результат серией коротких правок. Внутри таких цепочек — в среднем 3,4 генерации на задачу.
Реальные правки выглядят не как переписанный промпт, а как императивы: «замени фон», «убери тень», «сделай текст крупнее», «другой формат». Пользователь мыслит диффами к результату, а не описаниями с нуля.
Из этого следуют два вывода. Продуктовый: правки должны быть first-class операцией — UX в стиле «не понравилось? напиши новый промпт» заставляет начинать заново и проигрывает по времени. Экономический: одна карточка — это не одна генерация; в среднем по всем задачам выходит ≈1,7 генерации на результат, и это стоит закладывать и в мощности, и в юнит-экономику.
Инженерное следствие менее очевидно: контекст задачи — исходник, промежуточные версии, история правок — должен жить на сервере как единая сущность. Мы храним цепочку целиком: каждая правка ссылается на общий корень, оригиналы никогда не перезаписываются, а «регенерация» одного слайда просто добавляет версию в массив. Это дёшево и снимает целый класс багов вида «пользователь откатился, а откатываться некуда».
Когда селлеры делают карточки
Распределение по часам двугорбое: первый пик — 15:00, второй — 19:00 по Москве. Рабочий интервал 11:00–19:00 даёт чуть больше половины объёма, но каждая восьмая генерация происходит после 22:00, а ~5% — глубокой ночью.
Интерпретация простая: для большинства владельцев небольших магазинов контент — это «вторая смена». Днём — закупки, логистика и операционка, а карточки доделываются вечером, после основной работы.
Для нас это имело прямое инфраструктурное следствие: пиковая нагрузка приходится не на «офисные» часы, на которые по умолчанию калибруют мониторинг и дежурства, а на вечер. Если ваш продукт для малого бизнеса — проверьте свои графики нагрузки, там может жить такой же сюрприз.
Лето, когда спрос проснулся
Абсолютные объёмы мы не раскрываем, но динамику показать можем: после спокойной весны объём генераций вырос в несколько раз за один месяц — июнь 2026 стал рекордным за историю сервиса, и июль идёт с опережением. Всплеск совпал с двумя вещами: волной интереса к image-моделям нового поколения (то самое семейство, которое в рунете прозвали «нано-банана») и подготовкой селлеров к осеннему сезону.
Видео — формат, который пока никто не забрал
Видеообложки и короткие ролики из фото — пока малая доля генераций. При этом на самих площадках видео в карточке — один из самых недоиспользованных форматов: конкуренция ниже, внимание покупателя выше. Наша ставка: к концу 2026 года этот сегмент вырастет кратно — и по нашим данным, и по поведению площадок, которые всё активнее продвигают видеоконтент в выдаче.
Как это устроено под капотом
Теперь инженерная часть — три решения, которые держат описанную выше нагрузку.
Fan-out: комплект из одной загрузки
«Комплект карточки» — это 5–7 изображений (главное фото 3:4, инфографика, lifestyle-слайды) плюс видеообложка из одной пользовательской загрузки. Внутри это устроено как fan-out: серверный анализ товара порождает набор подзадач с готовыми промптами, подзадачи уходят в очередь и обрабатываются воркерами параллельно, отдельно от API-процесса. Состояние живёт в MongoDB, воркер и веб-часть — разные процессы с общими моделями данных.
Ключевое решение — промпты собираются на сервере, а не в клиенте. Это даёт три вещи: единый стиль комплекта, возможность молча улучшать промпты для всех пользователей сразу и защиту от случайного «сломал сам себе шаблон».
Каскад моделей: фолбэк только на инфраструктурных ошибках
Провайдеры image-моделей регулярно отдают таймауты, 5xx и модерационные отказы — это данность, под которую надо проектировать. Ретраить ту же модель при инфраструктурной ошибке почти бессмысленно: если у провайдера деградация, вы просто встанете в очередь за ошибкой.
У нас порядок моделей задаётся конфигом, и при инфраструктурном или сейфти-отказе задача каскадом уходит на следующую модель списка. Два принципа, которые выстраданы практикой:
-
фолбэк — только на технических ошибках. Никогда — на «результат не понравился»: иначе стиль комплекта становится непредсказуемым, а расходы — неконтролируемыми;
-
каскад должен покрывать и подзадачи комплекта. Если из семи изображений упало одно, перегенерировать нужно ровно его — на резервной модели, не трогая остальные.
Realtime вместо поллинга
Генерация занимает от двадцати секунд до полутора минут, комплект — несколько минут. Показывать пользователю спиннер всё это время нельзя, поллить список результатов раз в секунду — жалко и бэкенда, и батарейки.
Прогресс устроен так: воркер публикует события в Redis pub/sub, web-api подписан на канал и пробрасывает события в браузер по WebSocket. Карточки комплекта появляются в интерфейсе по мере готовности, а не все разом в конце.
Две грабли, на которые мы наступили и которые стоит обойти вам:
-
события должны нести готовый DTO, а не только id. Иначе клиент бежит за данными в REST и начинаются гонки «событие пришло раньше, чем запись стала видна»;
-
realtime-снапшот списка обязан повторять видимость REST-выдачи — те же фильтры, та же агрегация. У нас однажды push-обновление «раскрывало» элементы, которые REST скрывает, и список визуально ломался.
Кириллица на инфографике
Исторически текст на изображениях — ахиллесова пята генераторов, а кириллица — вдвойне. Для карточек маркетплейсов это блокер: инфографика без читаемых надписей бесполезна.
Что сработало у нас: модели нового поколения (у которых с текстом стало радикально лучше) плюс жёсткие серверные правила в промптах — количество слов на слайд, требования к контрасту и размеру кегля, запрет декоративных шрифтов. И третье, неочевидное: дешёвые правки. Если «сделай текст крупнее» стоит одно сообщение и полминуты, редкие огрехи перестают быть проблемой. Чистота надписей стала у нас одним из главных критериев при выборе и смене моделей — и, судя по данным о правках, для пользователей это тоже критично: текстовые правки — один из самых частых типов.
Что из этого следует
Если вы делаете продукт с генерацией изображений — вот выжимка из наших данных:
-
Итеративность — норма, а не сбой. Проектируйте правки как основную операцию и считайте экономику из ≈1,7 генерации на результат, а не из одной.
-
Ваши пики — не ваши рабочие часы. У аудитории малого бизнеса нагрузка живёт вечером и ночью; калибруйте мониторинг под неё.
-
Каскад моделей — обязателен, но фолбэк только на инфраструктурных ошибках, иначе потеряете предсказуемость.
-
Видео из фото — открытая ниша 2026 года на маркетплейсах: спрос уже виден в данных, конкуренция на площадках пока низкая.
Статистику обновляем ежеквартально; расширенная версия с методологией — в нашем блоге. Вопросы по методологии и данным — в комментарии, отвечу.
ссылка на оригинал статьи https://habr.com/ru/articles/1057938/