Rent The Runway оценивается в 700 миллионов долларов и скоро станет единорогом. Я присоединился к ней в 2012 году, чтобы довести науку о данных до небольшой компании с менее чем 50 сотрудниками в главном офисе, обслуживающей 2 миллиона клиентов. В пик, кроме меня, у нас было еще два младших специалиста по данным. Когда я ушел в феврале этого года, РТР обслуживал 8 миллионов клиентов. Программа членства, одним из основателей которой я был и к которой вернулся в прошлом году, выросла почти до половины общего дохода. Для сравнения, в настоящее время у конкурента, доступного только для членства, около 70 специалистов по данным.

Масштабирование никогда не бывает простым, даже для Amazon и Google. Но сделать это вдумчиво и с меньшими ресурсами, безусловно, труднее.

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

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

Наука о данных для розничной торговли?

В 2012 году это не было очевидным вопросом. Но руководители РТР знали, что они принадлежат к другой породе.

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

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

Его часто называют Netflix of Fashion, но примечательным отличием является то, что ставки очень высоки. Если вы смотрели первые 15 минут и фильм вам не понравился, пропустите его, и вам не испортят ночь. Если платье не подходит покупательнице на свадьбу, на которую она собирается (или является невестой), она, скорее всего, не вернется.

Rent The Runway - это бизнес, связанный с модой, технологиями, проектированием, цепочкой поставок, обратной логистикой, аналитикой и химчисткой.

Такие проблемы требуют нестандартных решений для масштабирования. Нам нужен был самодельный ML ручной прокатки. Меня пригласили из-за моего предыдущего опыта работы с Barnes & Nobles.

Машинное обучение в RTR

Вот несколько продуктов данных, которые я написал и подготовил.

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

Насколько мне известно, персонализированный заказ каруселей и модных товаров уникален для нас (включая Netflix и Spotify). Это позволяет получать рекомендации почти в реальном времени и выполнять быструю персонализацию. Для начала, я запустил это за 30 рабочих дней, используя прошлую работу!

Персонализированные рекомендации по мероприятиям для нашего бизнеса по меню (сделано с Энтони, очень талантливым специалистом по данным, теперь на Google Maps)

Вам также могут понравиться рекомендации (с Анной, теперь ETL в Spotify)

Сорт "Women Like Me" в помощь с Fit (с Kaleigh, теперь Google)

Прогнозирование спроса, управление запасами, прогнозирование цен (многие, в первую очередь Энтони и Роб, одни из самых быстрых учеников, которых я встречал)

Найдите платье по изображению (с Гейбом, гуру баланса работы и путешествий, и Сэнди, теперь в Google) и расширению браузера (с Низаром, теперь в Betterment и Sandy)

Использование искусственного интеллекта для получения постов в Instagram и уточнения с помощью Humans, прежде чем показывать его как обзор платья (с хинди, Кэролайн и Сэмом, прочтите об этом «https://sanealytics.com/2016/09/09/human-in-ai- петля/")

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

Сложность

В работе над чем-то классным хорошо то, что каждый хочет помочь. Это обоюдоострый меч.

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

Давайте добавим еще одного человека (скажем, Infra). Необходимо три линии связи. Каждый должен идти в ногу со всеми.

Как насчет 4 человек? Оказывается, нам нужно 6 линий связи. Это немного преувеличение, потому что не всем действительно нужно разговаривать со всеми, но все же существуют сложные зависимости. Я сначала компьютерный ученый, поэтому, к сожалению, я делаю O (N) для развлечения. А что, если вы добавите еще одного человека / команду?

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

Стремитесь к простоте.

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

Над чем работать

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

Как только вы поймете и проанализируете, в чем заключаются проблемы, вам нужно рассказать о них заинтересованным сторонам бизнеса. Я серьезно. Относитесь к этому как к презентации венчурного инвестора. Ему нужно что-то, что показывает потенциал роста (в конце концов, у вас есть данные). Затем небольшая демонстрация POC. Его нужно запускать только на вашем ноутбуке. Наконец, вы получите ресурсы, время на дорожную карту и друзей-хоббитов для путешествия.

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

Для рекомендаций пользовательского уровня пять лет назад мне пришлось установить хранилище данных MPP (mySQL - ›Vertica), написать какой-то сложный код для приема больших текстовых файлов и показать, что на самом деле существуют отдельные кластеры пользователей. Я сделал блестящую демонстрацию приложения на R, чтобы показать, какими будут их записи. Затем я протестировал его по электронной почте, чтобы показать огромный рост (двузначные цифры) в рейтинге кликов, чтобы заинтересовать людей.

Древняя пословица: без данных невозможно заниматься наукой о данных

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

О, кстати, английский язык здесь бесполезен, но это то, на чем должно быть сообщение (и повторяться снова и снова). Я научился избегать точности. И я никогда не смогу объяснить AUC простым английским языком. Так что это их исключает.

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

Совет: зацикливайтесь на этом, но не слишком сильно… любой выбранный вами показатель со временем станет неверным. Так что выберите один и двигайтесь дальше.

Стратегии KISS (Keep It Simple Stupid)

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

No

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

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

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

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

Вам необходимо отделить исследования от производства, что на языке бизнеса означает «не может потерпеть неудачу». Линейные модели легко отлаживать, редко выходят из строя и очень хорошо масштабируются. Они также мотивируют вас вернуться к этому позже и наглядно улучшить его (с точки зрения доходов) с помощью правильной модели для решения проблемы.

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

Отзыв

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

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

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

Команда

У вас есть успех. Поздравляю! Куда вы вкладываете деньги после того, как «дайте пять»?

Именно здесь многие компании ошибаются и слишком быстро наращивают команду.

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

Я считаю, что вам нужно больше специалистов по ETL, аналитиков и инженеров, чем Data Science / ML. Этот ответ подходит не для всех этапов. Так что относитесь к этому с недоверием.

Другая проблема заключается в том, что помимо длительных исследований (износ одежды с течением времени), работа с данными имеет тенденцию быть неоднородной. Компания из 20 инженеров может выполнить около 5 проектов за квартал. Только один из них, скорее всего, будет делать ставку на машинное обучение. Всегда есть другие конкурирующие приоритеты.

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

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

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

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

Так что, может быть, ищите и то, и другое. Если вы не разбираетесь в науке о данных, вас могут заставить выбрать один из этих вариантов. Забавно то, что графические дизайнеры хотят работать в Apple, у которой уже есть отличный UX, не скажем, Amazon. Люди не всегда видят открытые зеленые поля.

Сотрудничайте с не-инженерами. Я основал внутреннюю команду RTR DeepDress, в которую вошли все люди в компании, интересующиеся применением ИИ для решения модных проблем. Расширение для браузера, Instagram и некоторые другие идеи продуктов родились из этого. Дизайнеры UX были более чем счастливы поработать над этим, потому что они были вовлечены в создание идей.

Хорошие идеи приходят отовсюду. Уточнить.

Хорошие заборы - хорошие соседи

Серверная часть RTR стандартизирована для JAVA. Изначально я писал свои модели на C ++ с R для анализа (в 2012/13 году изменение данных python отсутствовало). Затем я перешел к написанию их на JAVA или Scala (в то время я предпочитал), чтобы интегрировать их с продуктами, которые создавала инженерия. Положительным моментом было то, что все, что я писал, - это класс, а связка данных и т. Д. - все в области инженерии. Так что входной барьер был невелик.

Это была ошибка.

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

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

Итак, нам нужны SLA. Примечательно, что некоторые из них:

  • Соглашение об уровне обслуживания безотказной работы. Разработчикам может потребоваться 99% времени безотказной работы, но помните, что машинное обучение - это «исследование», и мы хотели бы часто его менять. Так что мы этого не добьемся. Скажем, время безотказной работы SLA, которое мы обязуемся, составляет 90%
  • SLA с задержкой: инженерная служба вызывает службу машинного обучения, но, скажем, прогноз требует слишком много времени, чтобы ответить. Как долго это слишком долго? Давайте остановимся на 200 мс. Возможно, нам нужно будет чаще нажимать на это (скажем, 95%).
  • Соглашение об уровне обслуживания для прогнозирования: как скоро будут обновлены рекомендации? Модель для таких женщин, как я?
  • Соглашение об уровне обслуживания в реальном времени: должен ли этот продукт данных быть в реальном времени? Что бы вы потеряли, если бы это было почасово? Ежедневно?
  • Вопрос в 2 часа ночи: кто просыпается, когда это не удается? Что они делают? Это особенно важный вопрос для моей команды плюс двое.
  • Соглашение об уровне обслуживания с параллелизмом

Это выглядит ужасно. Ни один технический директор не подпишет этот контракт, и помните, что она - один из ваших инвесторов, так что вам это нужно!

Первая стратегия - это разделение ответственности (одобрено KISS).

Для инженеров это означает, что им не нужно разбираться в модели. Runbook говорит, перезапустите. И при запуске сервис подберет предыдущую версию модели, которая предположительно работала несколько часов назад. Никто не должен отлаживать код ML в 2 часа ночи. Кроме того, попутно вы можете заснуть, потому что это не проблема, если оно заживает само.

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

Вторая стратегия для этого - кодировать для надежности с помощью проверок и тестов. Если что-то не удается, развертывание модели должно завершиться ошибкой. Извините за тизер, но я расскажу о нем в части 3.

В-третьих, найдите изящные откаты. И резервные варианты для этих резервных вариантов. Например, если кто-то заходит на главную страницу, чьи рекомендации мы не вычислили, что они должны увидеть? Новинка, кому порекомендовать? Что они должны увидеть, если служба не работает?

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

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

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

В-четвертых, развертывать ежедневно, ежечасно и непрерывно. Это потому, что ваши автоматические тесты / проверки хороши ровно настолько, насколько вы их запускаете. И небольшая команда вряд ли повторно запустит модель прошлого года и совершенно не захочет исправлять проблему, которая первоначально произошла 2 месяца назад, но до сих пор никто этого не заметил. Непрерывное развертывание обнаружит проблему, когда она произойдет, и вернется обратно из-за вышеуказанного механизма отката.

Еще одна причина - поймать более коварные проблемы. Иногда исходные данные, новая функция, что-то еще, неизвестное вам, ломают вашу модель. Лови их, когда они случаются.

В-пятых, какую бы технологию / модель / язык вы ни выбрали, в следующем месяце он выйдет из моды. Наука о данных - быстро развивающаяся область, и даже в области глубокого обучения в прошлом году было как минимум 5 различных библиотек. Итак, конструкция позволяет переключать детали. У нас есть вещи, работающие на R / C ++, python и Scala. Я расскажу об этом подробнее во второй и третьей частях серии.

В-шестых, ML не может решить все. Надеюсь, вы уловили эти крайние случаи на этапе построения модели (большие размеры, низкий уровень запасов, низкая история и т. Д.). Иногда вы справедливо игнорируете проблему, потому что она может быть не слишком большой, или ставите вокруг нее ограждения (в идеале). В любом случае это должно быть отражено в отчете.

Это подводит меня к седьмой и последней стратегии этой публикации: то, что измеряется, исправляется. Или сделайте это чужой проблемой. Одноразовые сложные информационные продукты, зависящие от данных, которые использует только этот продукт, - это рецепт катастрофы. Поддерживайте согласованность модели данных с тем, что использует кто-то другой (представление о клиентах, продуктах и ​​т. Д.). Таким образом, когда они обнаружат проблему и исправят ее, ваша проблема также будет исправлена.

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

Сейчас я работаю над собственным розничным AI-стартапом Виревол. В настоящее время мы нанимаем специалистов по продуктам, продажам, UX, интерфейсным инженерам и машинному обучению (конечно). Обычно я пишу на https://sanealytics.com/ и пишу в Твиттере на https://twitter.com/analyticsaurabh

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

Увидимся в следующий раз…