Connect with us

Статьи

Могут ли цифровые продукты быть безвременными?

“Решает ли он проблему?”, “Это полезно?”, “Легко ли понять этот дизайн?” – эти вопросы часто приходили мне на ум, но никогда за свою карьеру я не интересовался: “Вечен ли этот дизайн?”.

Анна Гуляева

Опубликовано

/

     
     

Главный дизайнер в HODINKEE Адам Копек написал статью о том, может ли знаковый цифровой дизайн однажды попасть в музей и почему мы не воспринимаем отлично сделанные цифровые продукты так, как воспринимаем Rolex или Porsche.

Работая в HODINKEE, я вижу канонические, нестареющие дизайны почти каждый день. От винтажных часов и объектов дизайна, которые попадают на мой стол, до классических автомобилей, на которых я езжу по выходным – мне повезло быть окруженным вневременным дизайном.

Однако до начала работы здесь, “канонический” и “безвременный” не были словами, которые я бы использовал для описания цифровых продуктов, сделанных за годы моей работы со стартапами. “Решает ли он проблему?”, “Это полезно?”, “Легко ли понять этот дизайн?” – эти вопросы приходили мне на ум, но никогда за свою карьеру я не интересовался: “Вечен ли этот дизайн?”.

Rolex Submariner, вечный дизайн

Что такой вневременный дизайн?

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

Во-вторых, он должен быть знаковым, то есть устанавливать новый критерий для своей области и быть моментально узнаваемым.

Затем (и это решающая часть) ему необходимо время, чтобы доказать, что он так же хорош или даже лучше, чем 10, 20, или 50+ лет назад. Нелегкая задача!

И так я подумал: хотя доступному интернету почти 30 лет на момент написания статьи, почему мы никогда не думаем о цифровом дизайне как о “вневременном”?

Препятствие для цифрового дизайна

Многие цифровые дизайны никогда не задумывались как вечные изначально. Веб – это живая среда и, возможно, наиболее быстро меняющаяся из всех, с которыми работают дизайнеры. Целые сдвиги и изменения парадигм могут произойти за одну ночь, платформы приходят и уходят, а дизайн может быть перевернут с ног на голову для выживания бизнеса.

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

Porsche 911 vs главная страница Google

Базовый дизайн Google почти не изменился за 20 лет

Давайте взглянем на два продукта: Porsche 911 и заглавную страницу Google. В конце 90-х, когда соперники Google (MSN, Yahoo!) пытались стать целевыми сайтами для каждого, Google оставался сфокусированным на одной вещи – создании лучшего поиска.

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

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

Тогда почему Porsche вызывает чувство неподвластности времени, а Google нет?

Даже у безвременных дизайнов бывают провалы.

Безвременность в цифровой среде?

Присуща ли магия в большей степени физическим объектам? Может быть, что-то теряется в двумерном пространстве? Но тогда, что насчет вечного графического дизайна? Или логотипов? Определенно существуют вечные двумерные примеры, о которым мы можем вспомнить.

Может быть, 911 просто более очарователен? Или больше волнует? Но и Google индексирует данные со всего мира и показывает вам в удобоваримом виде со скоростью света (довольно очаровательная вещь!).

И это ещё не упоминая их очаровательные дудлы. Так в чем же дело?

Можно поспорить, что трехмерные продукты имеют преимущество материалов, которые позволяют им становиться вечными. В буквальном смысле. Их создатели выбрали материалы, которые приятны на ощупь, долговечны и становятся лучше со временем: корпус Leica M сделан из латуни, которая постепенно темнеет. Кожаные блокноты Moleskin становятся мягче при использовании. Двигатель Porsche лучше работает, а часы Rolex покрываются налетом и лучше показывают время.

Почему цифровые продукты не вызывают того же восхищения? Facebook и Twitter показывают вам тем все лучший контент по мере использования. Главная страница Reddit и лента “Интересное” в Instagram отображают персонализированные материалы, когда вы проводите много времени в этих сервисах. Рекомендательный движок Amazon становится все более точным с каждой вашей покупкой. Ваше приложение камеры наполняется приятными воспоминаниями. Pinterest становится вашим главным источником вдохновения.

Вечный дизайн?
Можно поспорить, стал ли контент в Facebook лучше со временем, но дизайн новостной ленты остался почти неизменным.

Предвкушение

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

Я верю, что цифровые дизайнеры должны гнаться за изменчивостью. Но у зрелых интернет-компаний, вроде Facebook и Google, есть достаточно времени, чтобы проявить себя, как Porsche и Leica – я думаю, что мы, как дизайнеры и потребители, посмотрим в прошлое и увидим, что цифровые дизайны проявили себя как безвременные.

И однажды эти дизайны найдут место в наших сердцах и в музеях рядом со своими трехмерными собратьями.

 

 

Комментарии
Если вы нашли опечатку - выделите ее и нажмите Ctrl + Enter! Для связи с нами вы можете использовать info@apptractor.ru.
Advertisement
Click to comment

You must be logged in to post a comment Login

Leave a Reply

Вовлечение пользователей

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

Александр Юсупов, Traffic Team Lead в Getloyal, рассказал нам, как сегментировать пользователей для travel, food delivery, e-commerce, F2P-гейминг, subscription service вертикалей.

AppTractor

Опубликовано

/

Автор:

Привлечение новых пользователей в мобильное приложение (User Acquisition) уступает новому сильному тренду мобильного маркетинга: ретаргетингу.

Тенденции User Acquisition не столь радужны и оптимистичны: количество рекламодателей растет при относительно не растущем мобильном рекламном рынке. Цены на привлечение нового пользователя растут вдвое. Кроме этого, информационное поле потребителя перегружено, и завоевать внимание рекламой становится все сложнее. Да и пользовательская база многих приложений и игр давно перевалила за миллионы, что означает, привлечение новых пользователей становится просто проблематичным.

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

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

В этой статье рассмотрим особенности сегментации и подходы работы с сегментами в travel, food delivery, e-commerce, F2P-гейминге, сервисов с подпиской.

Общие сегменты пользователей

Эффективным подходом сегментации ретаргетинговой кампании — сегментация на основе истории покупок и покупательского поведения пользователей. Пользователей любого сервиса условно можно разделить на 4 категории:

  1. Активный плательщик. От сервиса к сервису может разниться, но обычно это юзер, который пользуется приложением регулярно и недавно совершал покупку (не менее 30 дней назад), или не одну.
  2. Активный неплательщик. Это юзер, который активно пользуется приложением, но ни разу еще не совершал покупку.
  3. Спящий плательщик. Когда-то давно пользователь совершил покупку (больше 30 дней назад), но сейчас он либо забросил приложение, либо иногда пользуется, но не платит.
  4. Неактивный неплательщик. Самый большой пласт пользователей любой пользовательской базы любого приложения. Почти или ничего не сделал в приложении. Самый труднодоступный для ретаргетинга. По цене может обойтись, как привлечение нового.

Каждый из этих обобщенных сегментов требует индивидуального подхода и решения. Рассмотрим сегменты и подходы работы с ними на конкретных примерах вертикалей.

Сегментация в travel, food delivery сервисе

Самые популярные вертикали в ретаргетинге.

  1. Пользователи, которые уже совершали бронирование, заказ или платеж в приложении. К каждому сегменту ниже можно применять фильтры по давности, частоте и сумме платежа.
  • Пользователи, которые недавно совершили платеж (10, 20, 50 дней назад) и активны в последние дни. Решение: вы предлагаете им доп.услуги, специальные предложения, особые условия, новинки.
  • Пользователи, которые совершили платеж больше 90 дней назад и не проявляли активности. Решение: напоминание о существовании сервиса, спец.предложение, промокод.
  • Пользователи, которые давно покупали (90 дней назад) и недавно были активны в вашем приложении (7 и менее дней назад, например), но не купили/заказали. Решение: скорее всего они заинтересованы в услуге, ваша задача допродать. Можно и нужно дробить пользователей по контенту поиска.
  1. Пользователи, которые не платили и активно пользуются в последнее время. Чаще всего, это новые юзеры, которым надо дорассказать и допродать сервис. Можно сегментировать по частоте и давности.
  • Искали что-то (10, 20,30 дней назад) и не купили. Скорее всего, они заинтересованы в покупке, остается только напомнить о себе и замотивировать. Решение:  хорошо работает полу-динамика. Вы выбираете сегмент пользователей по схожим условиям поиска и делаете под них рекламный контент. Отлично подойдут динамические баннеры, которые в реальном времени создаются на основе пользовательского запроса и показываются в максимально релевантный момент. Такой формат лучше реализовывать с профессионалами Getloyal.
  • Проявили интерес к одной из категорий или добавили в избранное/корзину в последние дни. Решение: вы делите аудиторию по общему признаку предмета поиска или категории и напоминаете пользователю рекламой, что он интересовался данными вещами (полу-динамика). Или запускаете с Getloyal динамические баннеры.
  1. Пользователи, которые установили ваше приложение и не произвели ни одного события. Самая сложная группа для возврата. К ней стоит приступить, если вы научились мотивировать вторую группу на совершение платежа. Не факт, что у пользователя все еще установлено ваше приложение, поэтому путь к контенту приложения будет построен, как и для нового.

Решение: самое простое — это брать таких юзеров по давности установки. Юзер установил (10, 20, 30, 60, 90 дней назад) и не сделали ничего в приложении. Чем ближе дата установки, тем больше вероятность, что ему еще можно дорассказать про сервис: скидки, описание фичей, промокод. Чем дальше дата, тем меньше будет конверсия в реаттрибуцию.

Сегментация в мобильном e-commerce

Опыт плательщиков можно перенимать из описанных сегментов travel и доставки еды. Только в e-commerce отлично работают связки товаров. Пользователь в течение последних 7 дней купил товар A, с которым по статистике чаще всего покупают товары B, C, D, E. И вы создаете аудиторию из купивших А с баннерами дополнительных товаров.

Что касается неплательщиков, то можно выделить следующие сегменты:

  1. Те, кто недавно просматривал определенный товар или категорию товаров и не купили. Решение: выделяете пользователей по категориям поиска и делаете полу-динамические кампании на конкретные категории. Хорошо, если диплинки будут вести прямо в категорию, из которой искал пользователь.
  2. Те, кто недавно добавили в корзину и не купили. Ретаргетинг — отличный способ допродажи, особенно с рабочими диплинками, ведущими в корзину пользователя. Решение: отлично подойдет динамический ретаргетинг с фотографиями добавленных товаров на баннере.

Хорошо, если у вас получается воронка, и вы подталкиваете юзера на каждом ее этапе. Отлично, если Cost per new customer < LTV.

Сегментация в F2P-гейминге

Опыт создания сегментов из платящих можно брать из предыдущих вертикалей. Отлично подойдет разбивка по давности и сумме платежа. Всегда интереснее вернуть, так называемых “китов”, которые забросили играть. Сделайте, например, сегмент: платили больше N-суммы и не заходили 30 дней. Им отлично подойдут новости об апдейтах в игре, новых механиках, новых картах, уровнях и тп.

Для неплатящих есть несколько иных решений:

  • Вы “тащите” пользователя по уровневой цепочке: достиг 1, но не достиг 2; достиг 3, но не достиг 4 и тд. Хорошо работает, если у вас есть понимание, после какого условного “уровня”, пользователь скорее всего продолжит играть и в конце концов заплатит.
  • Тоже самое, что и первое, но с Retention. Вы, например, знаете, что после Retention 28 дня отвал пользователей почти прекращается. Поэтому вы натаскиваете пользователя в определенные дни жизни (1/7/14/28) и пытаетесь поднять Retention и % платящих.
  • По остаточным ресурсам. Например, у пользователя закончился какой-то ресурс в игре, и вы предлагаете ему гифт или акцию с этим ресурсом. Отлично работает с возможностью кастомизированных акций и подарков.
  • Крутые акции. Бывает так, что в игре проходят отличные акции на очень выгодных условиях. Таргетировать рекламу данного оффера на тех, кто активно играл последнее время, не платил, но в последние дни не заходит и может пропустить акцию.

Сегментаций у сервисов с подпиской

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

Данный сегмент можно возвращать следующим образом:

  • Дата окончания триальной подписки. Предположим, продолжительность пробной подписки – 14 дней. Вы создаете сегмент пользователей, активировавших пробную подписку больше 14 дней назад и не совершил события продления. Допродаете сервис. Можно пойти дальше и таргетировать тех, кто кликнул по кампании и все равно не активировал: вы можете предложить скидку, если такое предусмотрено сервисом.
  • Второй сегмент тех, кто оплатил после пробной, но не продлил во второй раз. Дата активации — время действия вашей подписки + отсутствие события продления. Вы пытаетесь напомнить пользователю, что он был счастлив этот период, отлично, если пользователей так много, что вы сможете разделить их по частоте использования. Так вы сможете выделить тех, кто продлит с наибольшей вероятностью + замерить показатели на той или иной аудитории.
  • Обширный сегмент может получиться из тех, кто установил приложение и ни разу не заходил или проявил малую активность. Самое время предложить им вашу пробную подписку, за время которой пользователь поймет, что жизнь до подписки была не жизнь.

Ретаргетинг GetLoyal: выжать максимум из существующих пользователей

Комментарии
Продолжить чтение

Разработка

Интересные материалы для разработчика мобильных приложений #193 (4-10 декабря)

В новом дайджесте мы обсуждаем учебные проекты, странную покупку старого Mac Mini, самые популярные приложения, потерю данных 31 миллиона пользователей одной из мобильных клавиатур, правильные продуктовые метрики и многое другое.

Леонид Боголюбов

Опубликовано

/

8 учебных проектов

Предлагаем 8 вариантов проектов, которые можно сделать «по фану», дабы получить реальный опыт разработки.

Зачем я купил Mac Mini (Late 2012) накануне 2018 года?

После смены старого MacBook Pro на еще более древний Mac Mini, объем оперативной памяти увеличился с 8 GB до 16 GB и маленький 13” экран сменился на два 22”. Осталось разобраться с производительностью.

14-й опрос Developer Economics

Этот опрос создан разработчиками для разработчиков и прольет свет на будущее индустрии программного обеспечения.

 iOS

 Android

 Разработка

 Аналитика, маркетинг и монетизация

 Устройства, IoT, AI

Комментарии
Продолжить чтение

Программирование

Правила, которые я выработал по результатам 1000 code review

Леонид Боголюбов

Опубликовано

/

Во время работы в LinkedIn большая часть моей работы состояла из проверки кода. Были определенные ситуации, которые постоянно возникали снова и снова, поэтому я решил составить список, которым и поделился с командой.

Вот мои 3 (+1 бонус) наиболее распространенных правки, которые я делал во время code review.

Правка 1: Генерирование исключения, когда что-то идет не так

Обычно я видел такое:

List<String> getSearchResults(...) {
  try {
    List<String> results = // make REST call to search service
    return results;
  } catch (RemoteInvocationException e) {
    return Collections.emptyList();
  }
}

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

Если бы вместо этого API выбросил исключение, то наша система мониторинга немедленно подобрала бы его, обработала и мы ошибку исправили.

Во многих случаях возникает соблазн просто вернуть пустой объект после того, как вы поймали исключение. Примерами пустых объектов в Java являются Optional.empty(), нулевой или пустой список. Хорошим примером того, где это все встречается постоянно, является парсинг URL. Вместо того, чтобы возвращать null, если URL-адрес не может быть получен из строки, спросите себя: «Почему URL-адрес неправильно сформирован? Является ли это проблемой данных, которую мы должны исправить где-то выше?».

Пустые объекты не являются подходящим инструментом для работы. Если случилось что-то исключительное, то вы должны выбросить исключение.

Правка 2: Использование наиболее конкретного типа

Это предложение в основном противоречит строгому типизированному программированию.

Слишком часто я видел код, подобный этому примеру:

void doOperation(String opType, Data data); 
// where opType is "insert", "append", or "delete", this should have clearly been an enum

String fetchWebsite(String url);
// where url is "https://google.com", this should have been an URN

String parseId(Input input);
// the return type is String but ids are actually Longs like "6345789"

Использование наиболее конкретного типа позволяет избежать целого класса ошибок и, в основном, является основной причиной выбора строго типизированного языка, такого как Java.

Внимание, вопрос: как опытные программисты в конечном итоге пишут плохой типизированный код? Ответ: потому что внешний мир не сильно типизирован. Есть несколько разных мест, откуда берутся строки, например:

  • параметры запроса и пути в URL-адресах
  • JSON
  • Базы данных, которые не поддерживают enum
  • Плохо написанные библиотеки

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

// Step 1: Take a query param representing a company name / member id pair and parse it
// example: context=Pair(linkedin,456)
Pair<String, Long> companyMember = parseQueryParam("context");
// this should throw an exception if malformed

// Step 2: Do all the stuff in your application
// MOST if not all of your code should live in this area

// Step 3: Convert the parameter back into a String at the very end if necessary
String redirectLink = serializeQueryParam("context");

Это дает ряд преимуществ. Неправильные данные немедленно обнаруживаются; в случае возникновении проблем приложение падает раньше. Кроме того, вам не нужно сохранять исключения для парсинга по всему приложению, так данные проверяются один раз. Кроме того, сильные типы сами по себе более полно описывают методы и вам не надо писать javadocs для каждого метода.

Правка 3: Использование Optionals вместо null

Одна из лучших функций Java 8 – это класс Optional, который представляет собой объект, который может существовать или не существовать.

Вопрос на миллион долларов: какое единственное исключение имеет собственную аббревиатуру? Ответ: NPE или Null Pointer Exception. Это, безусловно, самое распространенное исключение в  Java и, конечно, ошибка, которая стоит миллион долларов.

Optional позволяет вам полностью устранить NPE. Однако его следует использовать правильно. Вот некоторые советы по работе с Optional:

  • Не надо просто называть .get () в любое время, когда вам надо использовать Optional. Вместо этого внимательно подумайте о том случае, когда Optional не представлен, и придумайте разумное значение по умолчанию.
  • Если у вас еще нет разумного значения по умолчанию, тогда такие методы, как .map () и .flatMap (), позволяют отложить это решение.
  • Если внешняя библиотека возвращает значение NULL, чтобы указать на пустой случай, сразу же оберните значение с помощью параметра Optional.ofNullable (). Поверьте мне, вы поблагодарите себя позже. Нули имеют тенденцию «всплывать» внутри программ, поэтому лучше остановить их в первоисточнике.
  • Используйте Optional как возвращаемый тип в методах. Это здорово, потому что вам не нужно будет читать javadoc, чтобы выяснить, возможно ли, чтобы значение было пустым.

Бонус: Использование Unlift методов, когда это возможно

Вы должны избегать методов, которые выглядят следующим образом:

// AVOID:
CompletableFuture<T> method(CompletableFuture<S> param);
// PREFER: 
T method(S param);

// AVOID:
List<T> method(List<S> param);
// PREFER:
T method(S param);

// AVOID: 
T method(A param1, B param2, Optional<C> param3);
// PREFER:
T method(A param1, B param2, C param3);
T method(A param1, B param2);
// This method is clearly doing two things, it should be two methods
// The same is true for boolean parameters

Что общего у всех этих методов? Они используют контейнерные объекты, такие как Optional, List или Task как параметры методов. Еще хуже, когда  возвращаемый тип является тем же самым (т.е. метод принимает Optional и возвращает Optional).

Почему это плохо?

  1. Promise<A> method(Promise<B> param)
    менее гибко, чем просто
  2. A method(B param)

Если у вас есть Promise <B>, вы можете использовать 1, или вы можете использовать 2 путем «подъема» функции с помощью .map. (т.е. promise.map(method)).

Однако, если у вас есть только B, вы можете легко использовать 2, но вы не можете использовать 1, что делает 2 гораздо более гибким вариантом.

Мне нравится называть это «неподъемным», потому что это противоположность общепринятому функциональному методу «подъем». Применение этих знаний делает методы более гибкими и удобными для использования.

 

Комментарии
Продолжить чтение

Статьи

Настоящее и будущее машинного обучения на устройствах

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

Анна Гуляева

Опубликовано

/

Как вы, конечно, заметили, машинное обучение на устройствах сейчас все больше развивается. Apple упомянула это около ста раз во время WWDC 2017. Неудивительно, что разработчики хотят добавить машинное обучение в свои приложения.

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

Нейросеть для определения лиц, встроенная в смартфон

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

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

Машинное обучение сегодня

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

iOS использует несколько моделей глубокого обучения на устройствах: распознавание лиц на фото, фразы «Привет, Siri» и рукописных китайских иероглифов. Но все эти модели ничему не учатся от пользователя.

Почти все API машинного обучения (MPSCNN, TensorFlow Lite, Caffe2) могут делать предсказания на основе пользовательских данных, но вы не можете заставить эти модели узнавать новое из этих данных.

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

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

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

Зачем нужно обучение на устройстве?

Существует несколько преимуществ обучения на устройстве:

  • Приложение может учиться на данных или поведении пользователя.
  • Данные будут оставаться на устройстве.
  • Перевод любого процесса на устройство экономит деньги.
  • Модель будет обучаться и обновляться непрерывно.

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

На iOS-устройствах это уже делают некоторые приложения:

  • Клавиатура учится на основе текстов, которые вы набираете, и делает предположения о следующем слове в предложении. Эта модель обучается конкретно для вас, а не для других пользователей. Так как обучение происходит на устройстве, ваши сообщения не отправляются на облачный сервер.
  • Приложение «Фото» автоматически организует изображения в альбом «Люди». Я не совсем уверен, как это работает, но программа использует API распознавания лиц на фото и размещает похожие лица вместе. Возможно, это просто неконтролируемая кластеризация, но обучение все равно должно происходить, так как приложение позволяет вам исправлять его ошибки и совершенствуется на основе вашей обратной связи. Вне зависимости от вида алгоритма это приложение — хороший пример кастомизации пользовательского опыта на основе их данных.
  • Touch ID и Face ID учатся на основе вашего отпечатка пальца или лица. Face ID продолжает учиться со временем, поэтому, если вы отрастите бороду или начнете носить очки, оно по-прежнему будет узнавать ваше лицо.
  • Обнаружение движения. Apple Watch изучает ваши привычки, например, изменение биения сердца во время разных активностей. Опять же, я не знаю, как это работает, но, очевидно, обучение должно происходить.
  • Clarifai Mobile SDK позволяет пользователям создавать свои модели классификации изображений при помощи фотографий предметов и их обозначения. Обычно классификационная модель требует тысячи изображений для обучения, но этот SDK может научиться всего на нескольких примерах. Возможность создавать классификаторы изображений из ваших собственных фото, не будучи экспертом в машинном обучении, имеет много практических применений.

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

Модель клавиатуры достаточно проста, и обучение может происходить в режиме реального времени. Приложение «Фото» обучается медленнее и расходует много энергии, поэтому обучение происходит, когда устройство находится на зарядке. Многие практические применения обучения на устройстве находятся между этими двумя крайностями.

Другие существующие примеры включают в себя определение спама (ваш email-клиент учится на письмах, которые вы определяете как спам), коррекцию текста (она изучает ваши наиболее частые ошибки при наборе текста и исправляет их) и умные календари, вроде Google Now, которые учатся распознавать ваши регулярные действия.

Насколько далеко мы можем зайти?

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

Вот забавный пример: нейронная сеть превращает рисунки в эмодзи. Она просит вас нарисовать несколько разных фигур и учит модель распознавать их. Это приложение реализовано на Swift Playground, не самой быстрой платформе. Но даже при таких условиях нейронная сеть учится недолго — на устройстве это занимает всего несколько секунд (вот как работает эта модель).

Если ваша модель тоже не очень сложна, как эта двухслойная нейронная сеть, вы уже можете проводить обучение на устройстве.

Примечание: на iPhone X у разработчиков есть доступ к 3D-модели пользовательского лица в низком разрешении. Вы можете использовать эти данные, чтобы обучить модель, которая выбирает эмодзи или другое действие в приложение на основе выражения лица пользователей.

Вот несколько других будущих возможностей:

  • Smart Reply — это модель от Google, которая анализирует входящее сообщение или письмо и предлагает подходящий ответ. Она пока не обучается на устройстве и рекомендует одни и те же ответы всем пользователям, но (в теории) она может обучаться на текстах пользователя, что значительно улучшит модель.
  • Распознавание почерка, которое будет учиться именно на вашем почерке. Это особенно полезно на iPad Pro с Pencil. Это не новая функция, но если у вас такой же плохой почерк, как и у меня, то стандартная модель будет допускать слишком много ошибок.
  • Распознавание речи, которое будет становиться более точным и подстроенным под ваш голос.
  • Трекинг сна/фитнес-приложения. Прежде чем эти приложения будут давать вам советы об улучшении здоровья, им нужно узнать вас. Из соображений безопасности этим данным лучше оставаться на устройстве.
  • Персонализированные модели для диалога. Нам ещё предстоит увидеть будущее чат-ботов, но их преимущество заключается в том, что бот может адаптироваться под вас. Когда вы говорите с чат-ботом, ваше устройство будет изучать вашу речь и предпочтения и изменять ответы чат-бота под вашу личность и манеру общения (например, Siri может учиться давать меньше комментариев).
  • Улучшенная реклама. Никому не нравится реклама, но машинное обучение может сделать её менее назойливой для пользователей и более прибыльной для рекламодателя. Например, рекламный SDK может изучать, как часто вы смотрите и кликаете на рекламу, и подбирать более подходящую рекламу для вас. Приложение может обучать локальную модель, которая будет запрашивать только рекламу, работающую для конкретного пользователя.
  • Рекомендации — это распространенное использование машинного обучения. Проигрыватель подкастов может обучаться на программах, которые вы слушали, чтобы давать советы. Сейчас приложения осуществляют эту операцию в облаке, но это можно делать и на устройстве.
  • Людям с ограниченными возможностями приложения могут помогать ориентироваться в пространстве и лучше его понимать. Я не разбираюсь в этом, но могу представить, что приложения могут помогать, например, различать разные лекарства при помощи камеры.

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

Разные сценарии обучения моделей

Перед применением модели вам нужно её обучить. Обучение нужно продолжать и далее, чтобы улучшать модель.

Существует несколько вариантов обучения:

  1. Отсутствие обучения на данных пользователя. Сбор собственных данных или использование публично доступных данных для создания единой модели. При улучшении модели вы выпускаете обновление приложения или просто загружаете в него новые параметры. Так делают большинство существующих приложений с машинным обучением.
  2. Централизованное обучение. Если ваше приложение или сервис уже требует данные от пользователя, которые хранятся на ваших серверах, и у вас есть к ним доступ, тогда вы можете осуществлять обучение на основе этих данных на своем сервере. Пользовательские данные можно использовать для обучения под конкретного пользователя или под всех пользователей. Так поступают платформы вроде Facebook. Этот вариант вызывает вопросы, связанные с приватностью, безопасностью, масштабированием и многие другие. Вопрос с приватностью можно решить методом «избирательной приватности» Apple, но и у него есть свои последствия.
  3. Коллаборативное обучение. Этот способ перемещает затраты на обучение на самих пользователей. Обучение происходит на устройстве, и каждый пользователь обучает небольшую часть модели. Обновления модели отправляются другим пользователям, так что они могут учиться на ваших данных, а вы — на их. Но это по-прежнему единая модель, и у всех в итоге оказываются одни и те же параметры. Главным плюсом такого обучения является его децентрализованность. В теории это лучше для приватности, но, согласно исследованиям, этот вариант может быть хуже.
  4. Каждый пользователь обучает собственную модель. В этом варианте лично я заинтересован больше всего. Модель может учиться с нуля (как в примере с рисунками и эмодзи) или это может быть обученная модель, которая настраивается под ваши данные. В любом случае модель можно совершенствовать со временем. Например, клавиатура начинает с уже обученной на определенном языке модели, но со временем учится предсказывать, какое предложение вы хотите написать. Минусом этого подхода является то, что другие пользователи не могут получить от этого пользу. Так что этот вариант работает только для приложений, которые используют уникальные данные.

Как осуществлять обучение на устройстве?

Стоит помнить, что обучение на данных пользователя отличается от обучения на большом объеме данных. Начальную модель клавиатуры можно обучить на стандартном корпусе текстов (например, на всех текстах Википедии), но текстовое сообщение или письмо будет написано языком, отличающимся от типичной статьи в Википедии. И этот стиль будет отличаться от пользователя к пользователю. Модель должна предусматривать эти виды вариаций.

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

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

С нашими текущими методами обучения настройка моделей на устройстве все ещё далека. Но не все потеряно. Простые модели уже можно обучить на устройстве. Такие классические модели машинного обучения, как логистическая регрессия, дерево принятия решений или наивный байесовский классификатор, можно быстро обучить, особенно при использовании методов оптимизации второго порядка, таких как L-BFGS или сопряженный градиент. Даже базовая рекуррентная нейронная сеть должна быть доступна для реализации.

Для клавиатуры может сработать метод онлайн-обучения. Вы можете проводить сеанс обучения после определенного количества слов, набранных пользователем. То же самое относится к моделям, использующим акселерометр и информацию о движении, где данные поступают в виде постоянного потока цифр. Так как эти модели обучаются на небольшой части данных, каждое обновление должно происходить быстро. Поэтому, если ваша модель небольшая и у вас не так много данных, то обучение будет занимать секунды. Но если ваша модель имеет больший размер или у вас много данных, тогда вам нужно проявить творческий подход. Если модель изучает лица людей в вашей галерее фото, у нее слишком много данных для обработки, и вам нужно найти баланс между скоростью и точностью алгоритма.

Вот ещё несколько проблем, с которыми предстоит столкнуться при обучении на устройстве:

  • Большие модели. Для сетей глубокого обучения текущие методы обучения проходят слишком медленно и требуют слишком много данных. Многие исследования сейчас посвящены обучению моделей на небольшом количестве данных (например, на одном фото) и за небольшое число шагов. Я уверен, что любой прогресс приведет к распространению обучения на устройстве.
  • Несколько устройств. Вероятно, вы пользуетесь не одним устройством. Ещё предстоит решить вопрос передачи данных и моделей между устройствами пользователя. Например, приложение «Фото» в iOS 10 не передает информацию о лицах людей между устройствами, поэтому обучается на всех устройствах отдельно.
  • Обновления приложения. Если ваше приложение включает обученную модель, которая подстраивается под поведение и данные пользователя, то что происходит, когда вы обновляете модель вместе с приложением?

Обучение на устройстве пока находится в начале своего развития, но мне кажется, что эта технология неизбежно станет важной в создании приложений.

 

Комментарии
Продолжить чтение

Наша рассылка

Каждому подписавшемуся - "1 час на UI аудит": бесплатный ускоренный курс для разработчиков веб и мобильных приложений!

Нажимая на кнопку "Подписаться" вы даете согласие на обработку персональных данных.

Популярное

X

Спасибо!

Теперь редакторы в курсе.