Привет, меня зовут Валентин Ульянов, я разработчик, в IT около 10 лет, последние два занимался разработкой инструментов и бэкэндом, а сейчас в компании Р7 делаю редакторы документов типа ворда и экселя, еще делаю свой опенсорс проект, выступаю на конференциях, веду айти-сообщества в Питере на 800 плюс человек. А это новый выпуск кейсов, подкастов, в котором нет ведущего и каждый раз меняются гости, рассказывая о своих кейсах. В этот раз кейсом с вами делиться буду я. Поехали.
Я буду рассказывать про кейс со своей предыдущей работы в компании 4Spaces. Там я был бэкэнд-разработчиком.
Дело было в 2022 году, когда в опенсорс вышла нейронка Stable Diffusion для генерации картинок. Из интересного, что помимо того, что она умела генерировать по тексту картинки, была возможность достаточно просто ее дообучить на каких-то своих фотографиях. Например, свои фотки в этом процессе к ней закинуть, и можно было попросить сгенерировать себя в какой-то ситуации, например, на пляже или еще где-то. И на основе всего этого сетапа мы решили попробовать сделать продукт. Суть его была в том, что это такое получалось ios-приложение, в котором пользователь загружал свои фотографии, нейронка на них дообучалась, и дальше он мог написать, что, допустим, «хочу свое фото на коне в костюме супермена». Ну и, соответственно, нейронка генерировала ему фото на коне, да? Но даже более частый кейс использования, когда человек выбирал из каких-то предопределенных сетапов, допустим, себя в виде эльфа или себя накачанного, соответственно, такие картинки он получал. Из интересного в этом кейсе в том, что мы этот продукт выпустили и в какой-то момент залетели с ним в топ-5 App Store Бразилии. Об этом пойдет рассказ. Будет как техническая часть, поскольку сам я разработчик, так и сначала продуктовая. Будет рассказано о том, что именно нам помогло добиться этих результатов, ну и какие-то основные детали о проекте.
С продуктовой стороны, конечно, скорее для кого-то будет база, но давайте попробуем. И первое из такого, очевидно, что нам помогло, то, что мы сразу раскатывали это все на межнар. и в Бразилию в том числе. Соответственно, у нас был перевод приложения на разные языки. Причем из интересного то, что перевод у нас, благодаря другому нашему продукту, локализация получилась относительно дешевой, но довольно качественной. То есть мы получали очень хороший автоперевод, который потом аппрувили либо исправляли реальные люди. И вот такая довольно неплохая локализация позволяла нам как минимум получать трафик из другой страны, поскольку когда у вас приложение переведено на другой язык, соответственно, люди его могут спокойно найти в своем сторе, в своем регионе и загрузить. Как-то воспользоваться, да? Даже простая локализация – это уже неплохой источник трафика, но когда она сделана чуть лучше, чем Google, это тоже дает определенное преимущество, да? И мы вот таким образом его получили. Хорошо. Следующий момент касался в том, что… Тоже, наверное, одна из банальных вещей, но которую делают не все, а именно то, что у нас были метрики, и мы регулярно на них смотрели. На различные доменные события отправляли какую-то аналитику и смотрели, допустим, что пользователь сохранил картинку сгенерированную, допустим, пользователь как-то перешел с пуша, приложения, ну и так далее, да, вот такие отдельные вещи.
И поскольку мы следили за метриками, у нас была возможность четко видеть, оправдываться или нет нашей гипотезы, да, по каким-то фичам, потому что у нас, например, как это обычно бывает, придумали какую-то фичу, подумали, что вот сейчас она там нам что-то поможет поднять, допустим, повысить ретеншн или еще что-то, а по факту это оказывается какой-то галлюцинацией нашей. И вот как раз метрики нам это четко показывали. И были даже моменты, и вот ровно такие моменты были, когда мы сделали интересную, на наш взгляд, фичу, например,
что пользователю в какой-то момент автоматически генерировались картинки на какую-то тему.
Допустим, три дня он не посещал наше приложение, и ему по расписанию прилетала какая-то картинка, что вот посмотри, что мы тут там про тебя нагенерировали. У нас была гипотеза, что это хорошая фича для поднятия ретеншена, и какое-то время это у нас поработало, вот этот функционал. Он при этом отъедал какое-то количество ресурсов, о чем я расскажу в технической части чуть позже. Но, как выяснилось дальше по метрикам, пользы он принес мало, и мы в какой-то момент его просто выпилили, да. Это вот тоже один из инсайтов, про которые не все знают, что фичи можно удалять, если они бесполезные, да.
Соответственно, вот как раз метрики тоже в этом всем помогают нам. И третий такой момент, это такой немного общий, о том, что стоит брать не количеством фич, а правильно их продавать, да, чтобы они принесли результат. И вот мы как раз с этой проблемой столкнулись, что в какой-то момент фич достаточно много напилили, но из-за того, что не умели их правильно продавать, результатов особо не было, да, то есть прибыли и предложения приносило меньше, чем хотелось бы, да, ну и по сути не зарабатывало, то есть тогда в какой-то момент мы, соответственно, сделали фичи-фриз и начали консилировать только вот на том, чтобы правильно построить их продажу, да, то есть на нужных каналах, допустим, делать правильную рекламу, допустим, изготавливать правильные креативы с генерированными артами, с каким-то правильным посылом, нужную аудиторию, и, соответственно, так, чтобы получалась хорошая конверсия.
На это все люди приходили, покупали и так далее. Как раз благодаря тому, что мы в эту сторону правильно пошли, через какое-то время какое-то количество клиентов Попыток. Нам удалось научиться это продавать как раз-таки в Бразилии. И приложение начало зарабатывать. Хорошо, это была продуктовая часть. Сейчас немного поговорим про технические детали. Ну и в том числе, как именно нам удалось попасть в топ-5. Я буду чуть больше рассказывать про бэкэнд, поскольку я сам им занимался, да, хотя у нас была большая часть команды ios-разработчики, но все-таки на бэкэнде тоже много чего интересного было.
Итак, первый момент касается того, что вся инфраструктура у нас была в облаке, то есть облачного провайдера, AWS. Да, я знаю, что правильно говорить AWS, но так для простоты будем немножко по-колхозному. Вот в AWS у нас была вся инфраструктура, да, то есть благодаря чему нам не нужны были специально обученные DevOps, и практически любой сложности, там, сервера, еще что-то такое, можно было накликать себе, да. Понятно, что это тоже надо уметь в этом всем разбираться, но это было намного проще, чем если бы человек какой-то отдельный нам настраивал кубер и, ну, все вот эти вещи, что немаловажно.
В большинстве случаев ты платишь у облачного провайдера только за ресурсы, которые используешь. И, соответственно, в самом начале, когда мы это только настраивали, и инфраструктура у нас стояла, мы не платили ничего. Когда у нас там 3 человека на старте приходило, ну, несколько больше, но все равно мы платили сильно меньше, чем если бы мы сразу развернули свои серваки. Хорошо, следующий момент касался как раз-таки... Немножко продолжение первого. То, что мы использовали серверлесс-архитектуру. Если чуть более конкретно лямбды, такой сервис AWS лямбда, на всякий случай поясню.
Суть его в том, что мы можем запускать какие-то наши функции, какую-то нашу логику на серверах провайдера по определенным триггерам. допустим, по запросу на API, по таймеру, да, или там еще по каким-то событиям в базе, например, ну, то есть там множество вариантов этих самых триггеров. Здесь точно так же, что у нас не крутились какие-то сервера, да, лямбды, они запускались по запросу и стоили, то есть пока у тебя нагрузка маленькая, они стоят копейки, то есть сильно дешевле, чем если бы у тебя бежали свои сервера. И как раз нам это в начальном этапе хорошо подходило.
И даже немного забегая вперед, когда к нам как раз-таки пошли пользователи, когда мы в этот самый топ поднялись App Store, был момент, когда к нам приходило по 10 тысяч плюс пользователей в день. вполне себе лямбды не так сильно много у нас денег отнимали, да, инфраструктура, наш бэкэнд спокойно с этим всем справлялась. Вот хотя, как правило, с определенного размера нагрузки лямбды становятся дешевле, чем сервера, которые постоянно у тебя бегут. Третий момент, который нам помог здесь, это то, что тут немного погружусь в специфику вообще, как работала вся эта генерация картинок, что у нас был, соответственно, этап, когда пользователь к нам приходил, изначально у нас был этап до обучения вот этой вот исходной модели из Table Diffusion, чтобы она умела именно с участием пользователя картинки создавать.
Это первый момент. И второй момент был сам процесс генерации картинок. То есть он называется «инференс». Ну, это не только с картинками, а вообще, то есть когда модель что-то генерирует, это называется «инференс». Так вот, проблема была изначально в том, что этот, во-первых, процесс обучения, он длился, сейчас уже точно не вспомню, но минут 15, наверное, минимум. Иногда даже больше, в зависимости от каких-то входных параметров. Соответственно, человек, когда к нам только приходил, ему надо было... во-первых, качество, некоторое количество там штук, хотя бы 5 фотографий качественных своих выбрать, да, и еще потом ждать, пока вот это вот обучение модели закончится, да, то есть это первый момент, который немного ухудшал юзер-экспириенс, и второй, то, что вот эти вот обученные модели, они весили немало места, да, там по гигабайта 3 точно, возможно, даже побольше, и вот, соответственно, каждого пользователя нужно было хранить вот такую модель, да, что было, ну, Достаточно печально.
На начальном этапе, да, мы так делали. Но когда как раз-таки в Бразилии у нас пошли объемы пользователей, мы стали что-то думать, как с этим быть. Потому что с большим объемом на каждого человека по 3 гигабайта хранить, это проблематично. Ну и в принципе, что люди будут ждать, это такое себе. У нас даже... Ведь еще важный момент, что обучение проходит... Для того, чтобы происходило обучение, вот до обучения этих моделей, нужны сервера с мощными видеокартами. И был даже момент, когда у нас много людей пришло, в AWS закончились по нужной нам цене, собственно, сервера с этими видеокартами, чтобы обучались эти модели.
Соответственно, вот такая еще проблема была. И тогда мы придумали интересное решение, которое заключалось в том, тогда у нас уже была ML-команда, решение было в том, чтобы в принципе убрать этап до обучения модели, а сделать так, чтобы генерировалась какая-то исходная картинка по запросу, где, допустим, был какой-то другой человек. И в самом конце из выбранных пользователей фотографий своих подставлялось какое-то среднестатистическое лицо его на сгенерированную картинку. То есть, по сути, сгенерировалась картинка с каким-то человеком, и в нее просто подставлялось достаточно качественно лицо пользователя.
И это просто кратно ускоряло и оптимизировало весь процесс, но, конечно же, качество немного ухудшалось. Картинок в том плане, что, допустим, тело человека могло совершенно не совпадать с тем, что у него было в реальности на сгенерированной картинке. Но в некоторых местах наоборот. Качество лица улучшилось, и там какой-то крупный план, он давал лучший эффект. И вот как раз-таки, когда мы оптимизировали вот этот процесс, перешли на схему генерации картинок без обучения, тогда мы смогли сильно больше пользователей обрабатывать, да, и довольно в скором времени поднялись вот это самое топ-5, да.
И в этом случае у нас уже спокойно наш бэкэнд обрабатывал те самые 10 тысяч плюс пользователей в день. Так оно, в принципе, и получилось. Причем этот продукт, он все еще жив, работает. Приложение называется AI Boost. Его можно найти как в App Store, так уже есть веб-версия и попробовать, в принципе, на себе, как оно работает. Вот такой кейс. На этом у меня все. Если вам интересно посотрудничать с Fosspaces, контакты для связи с представителем будут в описании. Ну и мой сайт 150.lv. Это ссылка на все ссылки. Подписывайтесь на телеграм-канал, ставьте звезды на гитхабе. Ну и, конечно же, слушайте другие выпуски кейсов. Всем пока!
Телеграм-канал: https://t.me/blog150
Сайт: https://150.lv/
CEO 4spaces: https://t.me/AlexeyBalchunas
Реклама
ИНН: 246315389791
Erid: 2Vtzqv1CbYq
