Модель для генерации изображений YandexART применяют пользователи «Шедеврума», Алисы и других сервисов, чтобы визуализировать свои идеи и делиться ими с друзьями и знакомыми. С прошлого года YandexART можно встраивать в свои приложения и сервисы. А что если интерес людей к нейросетям может помочь в создании подарков с персональным визуальным посланием? С этой гипотезой мы в Yandex Cloud вместе с «Золотым Яблоком» запустили совместный проект: клиенты бьюти‑ритейлера могут самостоятельно генерировать изображения для электронных подарочных карт с помощью моделей от Яндекса.
На связи команда «Золотого Яблока». В этой статье мы расскажем, как компания знакомилась с YandexART, интегрировала его через API в свои сервисы, какие особенности может быть важно учесть другим разработчикам приложений, если они захотят повторить этот опыт. А именно:
как оптимизировать трафик, чтобы получить гарантированное время ответа пользователю;
почему этика нейросети — это не философская проблема, а вполне конкретная техническая задача;
что можно протестировать заранее и «подкрутить» в модели, чтобы получить нужный результат без переобучения.
Как подружить маркетинговые и технические задачи в одном проекте
У «Золотого Яблока», как у любого бренда, есть визуальный стиль: цветовая палитра из лаймового зелёного, фиолетового, розового, акцент на ярких деталях. Он транслируется во всех сообщениях, включая IT‑сервисы и приложения. Так что в проекте с подарочными картами участвовали не только разработчики: мы работали в команде с дизайнером, продуктовым лидом и аналитиком. Для всех участников это был эксперимент: хотелось убедиться, что использование нейросетей может быть не только развлечением, но и повышать интерес к продукту. Поэтому ключевыми метриками успеха считали средний чек с дизайном от нейросети и конверсию в заказ карты. Позднее можно также отслеживать долю покупателей, которые будут возвращаться и создавать карты повторно.
Помимо этого было в целом интересно посмотреть, что будут генерировать клиенты, какие промты использовать. Жёстких KPI на этапе пилота мы не задавали, скорее исследовали.
Для компании всё осложнялось тем, что к моменту старта проекта в начале 2024 года открытых API таких нейросетей ещё не было ни у кого из вендоров. Так что продакты «Золотого Яблока» просто написали в Яндекс и стали одними из первых тестовых пользователей YandexART: публичный API к нему появился только через пару месяцев весной в Yandex Foundation Models. Чужого примера перед глазами тоже не было, так что мы все очень оптимистично надеялись создать простой MVP за два спринта (спойлер — так не вышло).
Какие при этом возникали сомнения и риски:
Не хотелось, чтобы пользователи относились к сервису как к лаборатории для генерации картинок. Было важно подумать об ограничениях, в том числе антифродовых.
Мы стремились, чтобы сгенерированные изображения соответствовали брендбуку: например, учитывали фирменные цвета. Ну или хотя бы несли в себе близкую эстетику — всё-таки тема красоты очень чувствительная, и нежелательно, чтобы от имени «Золотого Яблока» люди дарили подарочные карты со спорными изображениями.
С первым пунктом более понятно: для пилотного проекта нужно было интегрировать нейросеть с веб‑приложением, где был более умеренный и предсказуемый трафик, а также сразу задать ограничение для количества генераций на одну подарочную карту.
А вот предусмотреть стилистику не удавалось: разработчики пробовали добавить промты на бэкенде, например, задать стиль Kawaii с милыми животными, но получалось не так интересно, как хотелось бы.
Со временем стало очевидно, что основная ценность нейросети в этом сценарии — это как раз возможность «чистого листа», чтобы пользователь был свободным в творчестве и реализации идей, так что ограничивать генерацию одной стилистикой не стали.
Какие шаги нужно было пройти
Постепенно сформировался простой и ясный план: сначала необходимо доработать сервис и добавить к нему нейрогенерацию на вебе, затем собрать и проанализировать накопленные данные, а на их основе добавить функциональность в основных мобильных платформах к праздничному сезону. Сама схема работы выглядела так:
Клиент заходит на страницу создания подарочной карты, выбирает нейрогенерацию и получает возможность сгенерировать не более трёх уникальных изображений в течение двух часов.
Для генерации можно ввести свой промт, а можно воспользоваться предложенным в сервисе списком подсказок для промтов.
После нажатия кнопки «Сгенерировать» сервис дёргает «ручку» в API к YandexART и возвращает пользователю превью карты с изображением.
Пользователь может выбрать сгенерированный дизайн или ввести следующий промт. Все сгенерированные изображения сохранятся в Media нашего сервиса.
Если клиент не выбрал ни одного изображения из трёх, он может вернуться через пару часов и попробовать ещё раз. Старые генерации удалятся по таймеру.
Для реализации такого алгоритма разработчикам нужно было как минимум задать преднастроенные промты, с помощью которых можно быстрее привести клиента к результату.
Но первые эксперименты показали, что помимо настройки самой модели понадобится ещё и промежуточный этап: система управления трафиком с хорошим мониторингом. А также оптимизация некоторых частей самого сервиса. Расскажем по порядку.
Что важно учесть с точки зрения мониторинга и управления трафиком
Для первой пробы разработчики взяли коммунальную модель YandexART с общим для всех пропускным каналом, которым пользуются и посетители «Шедеврума». А это означало, что не будет гарантированного времени ответа на запрос пользователя. Первые же генерации в тестовой среде обещали проблемы: время ожидания могло быть и 15 секунд, и более двух минут. При покупке подарка никто две минуты ждать не будет.
Следовательно, чтобы добиться фиксированного прогнозируемого времени ответа, нужна выделенная инсталляция модели (dedicated) в Yandex Cloud с возможностью управлять объёмом трафика. В свою очередь, для этого важно понять, как отслеживать и вовремя предупреждать узкие места. А заодно было бы здорово ещё на этапе тестового бесплатного доступа сориентироваться, какие мощности понадобятся в будущем: сколько GPU и так далее. И для того, и для другого не помешает система мониторинга.
Мониторинг разработчики строили на базе стека Elastic APM, визуальную составляющую и пользовательские метрики отобразили в Grafana. В эту систему постепенно добавляли новые метрики. В режиме реального времени отслеживали длительность генерации, а также количество генераций с разбивкой: общее число, количество успешных и неуспешных генераций, долю неуспешных по отношению к общему числу.
Поскольку запрос на генерацию проходит сразу через несколько сервисов на стороне компании, постепенно удалось разделить метрику времени запроса на составляющие: сколько времени проходит от запроса в Yandex Cloud до того, как пользователь получит ответ, и какое количество времени нужно, чтобы выдать результат на фронтенде.
С одной стороны, это позволяло увидеть ситуации, когда есть какая‑то аномалия или просто всплеск трафика: например, запустили акцию, где‑то проанонсировали сервис, и это привлекло много посетителей. На этот случай разработчики определяли порог, после которого подключали дополнительные ресурсы. Если в системе возникают пики трафика, когда не удалось спрогнозировать и спланировать достаточно ресурсов, всё равно можно выдать пользователю результат за счёт деления потока: дополнительный трафик просто отправляется в коммунальный канал, где запрос может задержаться чуть дольше, но картинка всё равно сгенерируется.
С другой стороны, такой детальный мониторинг помогает выделить и те проблемы, которые вызваны внешними обстоятельствами, и те, что необходимо решить на стороне сервиса.
За время дальнейшего тестирования наибольшего внимания потребовали две задачи:
тестирование и доработка стилистики самой модели;
упавшие генерации и ошибки по разным причинам, которые нужно было классифицировать.
Расскажем о каждой.
Как научить модель учитывать наши требования
С одной стороны, в ходе проекта мы пришли к тому, что генерация картинок исключительно в лаймово‑фиолетовой гамме по брендбуку может быть не так интересна покупателям подарочных карт. С другой стороны, на первых экспериментах разработчики увидели, что тестовые промты не всегда приводят к желаемому результату.
Простой и невинный пример: если в пользовательском тексте встречается слово «котик», то скорее всего нейросеть создаст изображение морского котика, а наш покупатель чаще ожидает обычного домашнего кота.
Или ещё одно интересное наблюдение: если пользователь хочет сгенерировать большую компанию людей, скорее всего, нейросеть сгруппирует их так, что будет выделен один центральный персонаж, а остальные будут не так хорошо прорисованы. Это тоже не всегда может соответствовать цели.
Команда боялась более рискованных ситуаций. Разумеется, у YandexART есть своя встроенная этика и правила использования, благодаря чему он не выдаёт общепринято неприемлемые результаты. Но бьюти-ритейлеру было важно предусмотреть больше возможных случаев, которые могут восприниматься нормально в обычной жизни, но неуместны, если речь идёт о подарках. Так сформировалось два направления тестирования:
тестирование самой генерации изображений: поиск тех случаев, когда при генерации что-то пошло не так и картинка отклонилась от условной нормы;
тестирование классификатора, который помогает отсеивать неподходящие изображения.
Для первого направления было нужно сначала определить, что считать нормой и подходящей картинкой, а что — отклонением от этой нормы. Сначала специалисты QA просто играли с моделью и формировали своеобразный блэклист того, что стоит запретить дополнительно. Но в какой‑то момент разработчики поняли, что не могут обойтись без собственного лексикона, который нужно добавлять к промту клиента, чтобы сделать результат более предсказуемым. Из‑за этого команде понадобилось потратить время на сбор лексем, которые будут соответствовать требованиям. Так в проекте появился отдельный микросервис, который позволяет конфигурировать входные параметры для генерации изображений дополнительно к тому, что просит клиент.
Второе направление тестирования — формирование классификатора для фильтрации неприемлемого содержания. Для этого тестировщикам «Золотого Яблока» потребовалось не только опираться на здравый смысл, но и детальнее ознакомиться с законодательством, которое может касаться запрещённого контента в этом сценарии, и проверить различные неоднозначные случаи. Эта задача также оказалась объёмной: нужно было предусмотреть все возможные вхождения, в том числе на русском, и на английском языке. Здесь стоит отдать должное пользователям — многое из того, что пришло в голову тестировщикам, даже пока ни разу не фильтровалось, так как у покупателей чаще всего добрые намерения.
Но если спорный запрос из блэклиста всё же будет введён, генерация упадёт — в этом случае важно корректно сообщить об этом пользователю:
Падающие генерации на мониторинге в таких случаях вполне ожидаемы. Но иногда ошибки случались и по другой причине, и вот здесь уже пришлось разбираться в отдельных ситуациях.
Что ещё важно предусмотреть в самом сервисе
Первая трудность, с которой столкнулись разработчики — это интерпретация кодов ошибки для пользователя сервиса. К сожалению, коды ошибок от YandexART оказались не универсальными для этого сценария, и понадобилось некоторое время, чтобы перевести их на язык бренда и вывести ясное сообщение для клиента.
Второй трудностью оказалась обработка картинок в Media на стороне сервиса. Начнём с того, что по умолчанию YandexART в то время генерировал только изображения с соотношением сторон 1:1. Для подарочных карт нужна была горизонтальная картинка, так что потребовалась доработка.
Помимо этого, медиаресурсы на стороне «Золотого Яблока» изначально разрабатывались для других задач. Поэтому пригодился мониторинг: отслеживание времени, за которое изображение проходит через все сервисы, помогало находить то, что может повысить эффективность.
Так, оптимизировать запросы к YandexART со стороны сервиса удалось за счёт вебхуков. Вместо того, чтобы регулярно спрашивать API, готово ли изображение, разработчики настроили вебхук на завершение генерации.
Каких результатов уже достигли
В скором времени команда приступит к детальному анализу обратной связи от клиентов: для этого планируется использовать несколько методов, в том числе и такие качественные, как интервью. Возможно, это также поможет лучше оценить и усовершенствовать сервис со словарём промтов и помочь пользователям получать нужный результат.
Поскольку сезон не завершился, в части сбора количественной информации команда ещё ждёт накопления данных для анализа. Пока давать точные цифры рано, но можно сказать, что:
интерес к фиче колоссальный — кликабельность раздела (таба) с нейросетью достигает 50%;
доля использования нейросети постоянно растёт;
средний чек имеет более высокие показатели по сравнению с обычным дизайном карт (+8%)
конверсия в заказ для сегмента заказов с картами нейросети также имеет более высокие показатели по сравнению со средними показателями.
Влияние на повторные покупки, и виральность продукта ещё предстоит оценить команде на длительном сроке.
Возможно, пригодятся и дополнительные данные, которые изначально не планировали собирать. Например, для каждой подаренной карты пользователи могут оставлять эмодзи‑реакцию — эту информацию тоже можно проанализировать. Также разработчики замечают рост некоторых косвенных метрик, например, времени использования сервиса.
Если же говорить о технических характеристиках, то созданный сервис с выбранной системой управления трафиком уже позволил компании пережить несколько пиковых периодов, например, в зимние праздники. В самый горячий сезон в минуту могло осуществляться по 150 генераций, и разработчики постоянно мониторили, как с нагрузкой справляется система. Но даже в пике сгенерированную подарочную карту удавалось передать пользователю за 13–15 секунд.
По результатам этого опыта команда «Золотого Яблока» порекомендовала бы другим разработчикам учитывать самые важные тонкости:
для доработки стиля генерации под вашу задачу стоит заложить достаточно времени на тестирование промтов и, возможно, даже на составление специального словаря;
если в вашей задаче нужно генерировать картинки с определённым соотношением сторон, особенно нестандартным — здесь тоже может потребоваться доработка;
к сожалению, генерации иногда могут падать по разным причинам, от этики до сетевых проблем, и к этому нужно быть готовыми;
стоит иметь в виду, что коды ошибок при генерации довольно специфичны, их тоже стоит изучить и затем перевести в понятные сообщения для ваших пользователей;
для самых важных показателей лучше предусмотреть мониторинг ещё на этапе создания сервиса, это поможет сделать тестирование более точным и целенаправленным;
для тех, кому также важно следить за объёмом трафика в сторону API модели, мы также рекомендуем посмотреть в сторону dedicated‑инсталляции модели — настроенный мониторинг во время тестов поможет определиться с количеством необходимых ресурсов. Если у вас нет задачи генерировать изображения в режиме реального времени, мы бы рекомендовали также попробовать создавать картинки по расписанию ночью — трафик в это время гораздо ниже.