Datacast Podcast - Effective Data Science with Eugene Yan
В этом выпуске подкаста Datacast Юджин Ян (Eugene Yan) рассказывает ведущему Джеймсу о своём пути из психологии в data science: переход из госсектора в IBM, затем в Lazada, куда он попал благодаря выступлению о соревновании на Kaggle. Он делится опытом перехода от индивидуального специалиста (IC) к роли руководителя, объясняя, что задача лидера — не строить всё самому, а делать команду на 20-100% эффективнее. Отдельно обсуждаются вызовы при поглощении Lazada компанией Alibaba: жёсткий девятимесячный срок миграции с AWS на AliCloud, языковой барьер и режим работы 996. Юджин также рассказывает о применении Scrum и agile в data science, о том, как Lazada ранжирует товары, и о пользе pet-проектов вроде классификатора товаров. В конце он называет тех, чьей работой восхищается (Andrej Karpathy, Jeremy Howard, Hamel Husain), рекомендует книги (ISL, The Pragmatic Programmer) и советует начинать с проблемы и работать в обратном направлении (Working Backwards).
Подкаст Datacast — эффективный data science с Eugene Yan
[ datascience leadership career lazada ] · 17 мин чтения
James пригласил меня на непринуждённую беседу в свой подкаст, где мы поговорили о моём переходе из психологии в data science, моём опыте, лидерстве, а также о моих текстах об agile, машинном обучении в продакшене, культуре, писательстве и многом другом. James был отличным ведущим и помог мне звучать почти связно.
Главное из нашей беседы
Почему вы пришли в Lazada?
Ещё в 2012 году (когда была основана Lazada) электронной коммерции в Юго-Восточной Азии практически не существовало. Чтобы что-то купить, покупателям приходилось идти в обычный магазин — это неудобно для тех, кто живёт в сельской местности. И даже там, где была электронная коммерция, доступ к кредитам, логистике и надёжным продавцам был затруднён. Как купить товар и оплатить его? Как вернуть товар, если он вас не устроил? Именно эти проблемы и пыталась решить Lazada.
(Подкаст 9:03)
Как вы попали в Lazada?
Я участвовал в соревновании на Kaggle по классификации товаров (вместе с моим другом Weimin), и мы выступили вполне достойно. Затем у меня появилась возможность рассказать об этом на встрече сообщества, сооснователем которого был мой друг Kai Xin.
Так совпало, что у Lazada (тогда совсем новой) была та же проблема. Они связались со мной и пригласили на беседу. В то время это была очень маленькая команда (3 человека). Но всё звучало невероятно увлекательно, люди, с которыми я познакомился, были потрясающими, и я с нетерпением ждал возможности учиться у них. Подробнее здесь.
(Подкаст 10:18)
Не могли бы вы рассказать о своём пути из психологии в data science?
Мой путь нетипичен, и мне очень повезло.
При уходе из госсектора мне повезло, что IBM дала мне возможность для моей первой роли, связанной с данными. Затем, уже в IBM, мне очень повезло, что нанимающий менеджер команды глобальной workforce-аналитики искал человека с психологическим образованием, а я был единственным таким в своём наборе.
Потом, когда я рассказал о своём опыте на Kaggle на одной из встреч, мне снова повезло чисто случайно — у Lazada была ровно та же проблема. И они рискнули, взяв меня. А затем, уже в Lazada, у меня были замечательные коллеги и замечательные руководители, которые давали мне массу возможностей делать смелые вещи, быстро что-то строить и проводить эксперименты (и ошибаться). Конечно, они никогда не назвали бы это неудачей — они всегда говорили, что это урок.
Если попытаться выжать суть, то она такая: (i) пробуй много всего, и тебе повезёт примерно в 5% попыток, и (ii) ищи людей, которые дают тебе возможность делать отличную работу, и работай с ними.
(Подкаст 19:14)
Связанная статья: Мой путь: от выпускника-психолога до руководителя data science в Lazada
Вы выступаете на конференциях и митапах. Не могли бы вы поделиться парой советов со слушателями?
Если вы собираетесь чем-то делиться, делитесь тем, что вам по-настоящему небезразлично. Когда вы делитесь, вы становитесь маяком; это притягивает единомышленников, готовых это обсуждать. Не пытайтесь оседлать тренд и рассказывать о том, что модно — это ясно считывается аудиторией, и ей будет неинтересно. Это будет неискренне.
Как только у вас есть тема, которая вам небезразлична, делитесь о ней как можно больше. Представьте себя на месте слушателя. Какие детали были бы вам важны? Метрики? Результаты? Сколько клиентов удалось привлечь? Методология? Код (или репозиторий на GitHub)? Мне интересно всё перечисленное, особенно то, что не сработало. Поэтому я всегда стараюсь рассказывать о том, что не сработало, чтобы сэкономить аудитории время на экспериментах — эти уроки о том, что не сработало, очень ценны.
Когда вы делитесь, не превращайте это в лекцию; люди начнут отключаться через 5–10 минут. Вам нужно увлекать и давать общую картину и контекст. А затем уже можно углубляться. Но даже тогда не уходите слишком глубоко, иначе аудитория потеряет нить — у неё нет вашей экспертизы и знаний. Постарайтесь сопереживать аудитории и держать всё легко. Если они захотят узнать больше, они всегда смогут к вам обратиться.
(Подкаст 25:29)
Связанная статья: Как сделать убойное выступление по data science
Какие уроки вы извлекли из перехода от роли индивидуального специалиста (IC) к лидерству?
Честно говоря, в усвоении этих уроков мне очень помогли. Когда произошёл переход, я поговорил со своим руководителем, а также с его руководителем, и спросил их, что им от меня нужно.
Будучи IC, я всегда выкладывался на 100%, чтобы построить новую систему и улучшить клиентский опыт. Когда я перешёл на новую роль, меня научили, что я больше не могу вникать во все детали и строить всё сам — это не масштабируется с командой из 10+ человек. Вместо этого моя задача была — помочь каждому в команде стать на 20% (а то и на 100%) лучше. Тогда на 10 человек вся команда становится на 200% (или 1000%) лучше. Моя роль была в том, чтобы масштабировать команду, увеличивать отдачу, внедрять правильные практики, наставлять и помогать команде расти.
Вот почему я много пишу об agile и scrum. И почему я выступаю за такие практики, как написание one-pager для согласования со стейкхолдерами и обеспечение того, чтобы они действительно пользовались тем, что вы построили. Худшее, что можно сделать — потратить 3 человеко-месяца на то, чем они не будут пользоваться. (Клиент не получает выгоды, а вашей команде нечего предъявить.) Это некоторые из практик, которые я счёл ценными для моей команды и которыми хотел бы поделиться.
Я также научился проводить 1-on-1. Я спрашивал каждого, где он хочет быть через три года и как мы можем помочь ему к этому прийти (даже если это будет не в нашей команде или организации). Зная их интересы, я могу состыковать их с тем, что нужно организации. Многое из того, что я пытался делать, сводилось к поиску соответствия между мотивацией человека и потребностями организации.
В целом я больше не пытался оптимизировать или строить собственный проект. Вместо этого я пытался оптимизировать вклад всей команды в организацию: помочь людям расти, внедрить правильные процессы для повышения продуктивности, привить им хорошие привычки и научить лучше коммуницировать со стейкхолдерами.
Из-за этого стало сложно измерять мой собственный вклад. Я не построил это, я не построил то — всё было сделано командой. Но в итоге всё складывается удачно, ведь тебя оценивают по отдаче твоей команды, по тому, как люди выросли, по их удовлетворённости, удержанию и так далее.
(Подкаст 39:01)
Связанная статья: Мои первые 100 дней в роли руководителя data science
С какими сложностями вы столкнулись во время поглощения Lazada компанией Alibaba?
Немного контекста: Lazada была первым приобретением Alibaba за пределами Китая. Поэтому для них это был такой же опыт обучения, как и для нас.
Одной из сложностей были очень сжатые сроки. Нам дали девять месяцев на полную миграцию на их платформу. Это означало переход с AWS на AliCloud. А также использование их модели данных и схем, чтобы то, как покупатель, товар и отзыв представлены в Lazada, было в точности таким же, как во всей Alibaba. Нам также нужно было интегрировать их трекер, чтобы логи были согласованными, и использовать их инструменты для построения поискового движка и рекомендательной системы.
Ещё одной ключевой сложностью был языковой барьер. Команда Alibaba состояла в основном из носителей мандаринского, и лишь очень немногие из них говорили по-английски. А в моей команде половина не понимала мандаринский. Так что когда обсуждения шли на мандаринском, часть людей оказывалась исключена, и мне приходилось искать, как с этим справляться. Вся документация тоже была на мандаринском. Нам приходилось пользоваться Google Translate, и при этом 50% содержания терялось или искажалось.
Работа тоже была изматывающей — это был режим 996. Иногда, когда мы ездили в Ханчжоу, работали семь дней в неделю. А поездки длились по две недели подряд, с неделей отдыха между ними. Нам приходилось так делать, потому что это был действительно лучший способ работать — лично с твоим китайским коллегой, сидя рядом с ним. Даже сейчас я думаю, что только так мы и могли уложиться в девятимесячный дедлайн.
(Подкаст 44:20)
Не могли бы вы рассказать о keynote-докладе, который вы прочитали для OLX?
Сначала немного контекста об OLX Group. OLX — это глобальный онлайн-маркетплейс, представленный в более чем 40 странах. Это платформа для покупки и продажи услуг и товаров, включая автомобили, электронику, недвижимость и вакансии. Они стремительно расширялись в Европе, иногда через поглощения, и думали о том, как продолжать масштабироваться.
Главный вопрос, который у них был ко мне, звучал так: что мы централизуем, а что децентрализуем? Как Alibaba и другие игроки в Юго-Восточной Азии масштабируют свои платформы?
В случае Alibaba вся инфраструктура, модели данных, платформы и инструменты были в основном одинаковыми. Эти пакеты использовались множеством команд в разных подразделениях Alibaba, и Lazada тоже ими пользовалась. У нас также были стандартные гайдлайны. И если бы кто-то из Alibaba посмотрел на данные Lazada, он бы очень быстро в них разобрался. То, как мы представляем покупателей и товары, одинаково. Это сильно упрощает обмен знаниями между организациями и позволяет быстро итерировать.
А что же тогда было децентрализовано? Локальные команды работали над такими аспектами, как дизайн продукта и приложения, чтобы он соответствовал вкусам потребителей в Юго-Восточной Азии. Наша команда data science также работала над локальными кампаниями и борьбой с мошенничеством, которое немного отличалось от мошенничества в Китае.
Мы также обсудили феномен SuperApp и то, как он расцветает по всему Китаю и Юго-Восточной Азии. Очень интересно наблюдать бандлинг в Китае и Юго-Восточной Азии и обратное в США, где идёт анбандлинг. Подробнее здесь.
(Подкаст 47:51)
Вы производите впечатление евангелиста связки DS × Agile. Не могли бы вы рассказать об этом подробнее?
Я и не знал, что я евангелист data science и agile. Любопытно, как это вышло. Когда я общался с друзьями из индустрии, они удивлялись, что мои команды используют Scrum, и спрашивали, как это работало и работало ли вообще. Так много людей задавали одни и те же вопросы, что я решил просто написать об этом и выложить в сеть.
Когда я только начинал применять Scrum, я думал, что это очень строгий процесс из приоритизации, стендапов, демо, ретроспектив и так далее. Но по мере того как я применял его всё больше, я выделил несколько ключевых вещей, которые для меня важнее всего.
Во-первых, нужно думать о том, как итерировать быстро. Здесь помогает концепция тайм-боксинга. Например, построение рекомендательной системы может занять от двух месяцев до двух лет. Для меня и для наших клиентов лучше построить что-то быстро (за два месяца) и протестировать на клиентах. Возможно, это не сработает, но тогда мы итерируем. Это предпочтительнее, чем потратить на это два года и в итоге обнаружить, что оно тоже не работает.
Во-вторых, нужно проводить приоритизацию вместе с бизнесом. Например, вам может хотеться построить что-то эффектное, но если бизнесу это не нужно, то это не должно быть приоритетом. Важно понять, что нужно клиентам и бизнесу, а затем — как решить эти проблемы средствами data science. Не стоит пытаться построить что-то эффектное и просто надеяться, что людям понравится. Amazon делает это очень хорошо благодаря нашему процессу Working Backwards, в котором мы идём в обратном направлении — от проблемы или возможности клиента.
Кроме того, есть две практики, которые команды по-настоящему любят. Первая — демо. Демо невероятно увлекательны, и как только вы выстраиваете ритм, люди работают быстро и с энтузиазмом делятся (находками, результатами, хаками) и получают обратную связь.
Людям также нравятся ретроспективы. Ретроспективы — это отличный способ получить обратную связь от команды в нейтральной и объективной обстановке. Как лидер, вы должны обращать внимание на пункты из корзины «Что прошло плохо» (например, что на получение доступа к данным уходит три дня) и решать их. Если вы сможете решить эти проблемы, то повысите продуктивность всей команды. После 10–20 ретроспектив вы оглянетесь на то, с чего начинали, и осознаете, что команда выросла невероятно сильно.
(Подкаст 57:44)
Связанные статьи:
Конференция GovTech — Data Science и Agile: получится или нет? Data Science и Agile (что работает, а что нет) Data Science и Agile (фреймворки для эффективности) Что я люблю в Scrum для data science
Не могли бы вы рассказать о своём докладе «Как Lazada ранжирует товары»?
Прежде всего, кое-что, о чём я раньше не упоминал: моей целевой аудиторией для этого доклада были не участники конференции, а продавцы на нашей платформе. Я хотел рассказать, как мы ранжируем товары, чтобы они могли в этом разобраться и работать в рамках системы, давая покупателю наилучший опыт.
Чтобы построить эту систему, мы сначала разработали ранжирующую модель, которая присваивает оценку каждому товару на страницах категорий и поиска. В этом нет ничего особенного; мы использовали исторические данные о кликах, добавлениях в корзину и покупках, чтобы оптимизировать целевую метрику. Целью могла быть конверсия, выручка или привлечение клиентов, и её можно комбинировать в зависимости от вашей бизнес-цели. Но признаки оставались теми же.
Кроме того, Lazada стремительно росла и ежедневно добавляла множество новых продавцов и товаров. Поэтому я хотел показать продавцам, что мы работаем над функциями для помощи новым продавцам и товарам. Мы разбили это на задачу спроса и предложения и подошли к ней со стороны спроса. Мы пытались понять неудовлетворённый спрос через то, что покупатели искали, но не находили. Благодаря этому мы знали, чего покупатели хотят, но не могут найти — это и были новые товары, которые нам следовало ранжировать выше. Результаты оказались потрясающими, но также и потому, что проблема изначально была очень острой. В электронной коммерции богатые становятся богаче; топовые товары продолжают хорошо ранжироваться благодаря этому замкнутому циклу.
Мы также рассказали о том, как качество товара влияет на ранжирование. Я хотел показать продавцам, что нам небезразлично качество товара и что попытки обмануть покупателей далеко их не заведут. Продавцы могут пытаться обмануть покупателей, продавая товары очень дешёвые и очень низкого качества. Или продавцы могут заявлять о доставке за один день, тогда как фактический срок доставки может составлять неделю и больше. Или продавцы могут продавать контрафакт. Но всё это очень быстро всплывёт в отзывах, и мы будем понижать такие товары. Мы старались быть максимально прозрачными с продавцами в том, по каким критериям ранжируем, чтобы они понимали, как улучшить свой ранг.
(Подкаст 01:03:18)
Связанная статья: Strata x Hadoop 2016 — Как Lazada ранжирует товары
Вы писали о создании приложения-классификатора товаров — не могли бы вы рассказать подробнее?
Думаю, полезно понять контекст, почему я это сделал. Тогда у меня было два-три года опыта работы дата-сайентистом в индустрии и пройдено множество курсов. Но всё равно казалось, что чего-то не хватает. Поэтому я искал больше опыта и нашёл некоторые данные о товарах Amazon.
Благодаря этому проекту я многому научился. Во-первых, данные были не в формате csv и не помещались в память. Мне пришлось научиться парсить и преобразовывать эти json-данные в csv через подход без загрузки всего в память. Затем нужно было сделать очистку данных, feature engineering и построить модель машинного обучения — это было мне знакомо.
Дальше, когда мне нужно было задеплоить эту модель онлайн и сделать её публично доступной, я осознал, как много я не знаю об облаке и AWS. У меня также было мало опыта с GPU и фреймворками глубокого обучения; тогда я использовал Theano. Классификации изображений я уж точно не учился на онлайн-курсах. Я также освоил transfer learning, который тогда был для меня в новинку. Затем мне нужно было ещё разработать API и базовый фронтенд и развернуть всё это на инстансе EC2.
Процесс оказался невероятно полезным. Мне пришлось столькому научиться, и это помогло мне на работе, когда я сам должен был деплоить системы машинного обучения.
(Подкаст 01:19:04)
Связанные статьи:
Product Classification API. Часть 1: получение данных Product Classification API. Часть 2: подготовка данных Product Categorization API. Часть 3: создание API API классификации изображений запущен! Поиск по изображениям запущен!
Три человека в data science, чьей работой вы восхищаетесь?
Andrej Karpathy, директор по AI в Tesla. Я восхищаюсь тем, как он умеет применять свои исследования в реальном мире. Он также делится потрясающим контентом. Я многое узнал о ранних sequence- и текстовых моделях из его поста The Unreasonable Effectiveness of Recurrent Neural Networks. Он также поделился очень практичными советами в A Recipe for Training Neural Networks.
Jeremy Howard — он основал несколько компаний, а вместе с Rachel Thomas они стали сооснователями fast.ai. Они сделали глубокое обучение более доступным для программистов и хакеров. Мне нравится их педагогический подход — начинать с проблемы, показывать, что её можно решить, и только потом углубляться в детали. Я считаю, что такой подход лучше работает для многих учащихся. К сожалению, преподаватели часто начинают с теории, прежде чем перейти к применению, и учащемуся непонятно, как именно он будет это использовать.
Hamel Husain, Staff ML engineer в GitHub. Он создал множество ML-инструментов и контента вокруг MLOps. Думаю, это важно для дата-сайентистов, и недостаточно людей уделяют этому внимание. Недавно вместе с парой коллег он также выложил материалы о том, как делать MLOps на GitHub Actions. Вместе с Jeremy Howard они разработали FastPages, чтобы людям было проще публиковать блог-посты из Jupyter Notebook.
(Подкаст: 01:24:42)
Можете порекомендовать книгу для дата-сайентистов?
Сложно порекомендовать всего одну книгу. Но я могу рассказать о двух книгах, которые я дарю джуниор-дата-сайентистам, приходящим в мою команду.
Первая книга — Introduction to Statistical Learning (ISL). Я знаю, что многие ссылаются на Elements of Statistical Learning (ESL). У меня есть обе книги, я смотрю на них прямо сейчас, и ISL примерно вдвое тоньше ESL. Думаю, ISL гораздо более усвояемая и не отпугивает людей. Вполне реально, что если потратить на её изучение месяц-другой, можно полностью её понять. И как только вы её осилите, у вас сложится отличное понимание машинного обучения со статистической точки зрения. Если хочется чего-то с точки зрения computer science, возможно, стоит рассмотреть Artificial Intelligence авторства Peter Norvig.
Другая книга, которую я очень рекомендую и которую обожает почти каждый, кому я её давал, — это The Pragmatic Programmer. Это был первый потрясающий ресурс по программированию, который на меня повлиял. В нём рассказывается, как строить системы инкрементально, начиная со «скелета» и доводя его до работоспособного состояния от начала до конца, прежде чем заполнять детали. Я применил многое из того, что узнал из этой книги, к тому, как я строю системы машинного обучения.
(Подкаст: 01:28:16)
Что бы вы хотели сказать всем дата-сайентистам, если бы могли поделиться одной мыслью?
Я бы поделился подходом, который отлично работает для меня: когда вы строите ML-приложение, сначала сосредоточьтесь на том, как оно поможет людям. Как только вы это поймёте, идите в обратном направлении от этого. Действуя так, то, что вы построите, точно будет полезно клиентам, и вы окажете гораздо большее влияние — вероятно, в 2–10 раз большее. Начинайте с проблемы, а затем двигайтесь от неё в обратном направлении.
(Подкаст: 01:30:58)
James был отличным ведущим и помог мне звучать почти связно 😂 Мы обсудили мой переход из психологии в data science, опыт работы, лидерство, agile, машинное обучение в продакшене, культуру и так далее. Если 90 минут — это слишком долго, вот основные моменты: https://t.co/COUCGWd2zL https://t.co/RcEytgXek7 — Eugene Yan (@eugeneyan) 4 сентября 2020
Если этот материал оказался вам полезен, пожалуйста, цитируйте его так:
Yan, Ziyou. (Sep 2020). Datacast Podcast - Effective Data Science with Eugene Yan. eugeneyan.com. https://eugeneyan.com/speaking/datacast-eugeneyan/.
или
@article{yan2020datacast, title = {Datacast Podcast - Effective Data Science with Eugene Yan}, author = {Yan, Ziyou}, journal = {eugeneyan.com}, year = {2020}, month = {Sep}, url = {https://eugeneyan.com/speaking/datacast-eugeneyan/} }
Присоединяйтесь к 11 800+ читателям, получающим обновления о машинном обучении, RecSys, LLM и инженерии.