Towards Data Science - Author Spotlight with Eugene Yan

eugeneyan

Начните здесь Статьи Выступления Прототипирование Обо мне

Towards Data Science — Author Spotlight с Eugene Yan

[ career writing datascience ] · 11 мин чтения

Недавно я дал интервью изданию Towards Data Science в рамках их серии Author Spotlight. У них были интересные вопросы, о некоторых из которых я раньше не писал, поэтому я решил поделиться этим и здесь. Есть ещё вопросы? Задавайте их на странице AMA!

• • •

Вы прошли довольно интересный карьерный путь в data science. От входа в профессию с дипломом по психологии до позиции в «ракетном» стартапе Lazada, а теперь — Applied Scientist в Amazon. Могли бы вы рассказать, как вы нашли свой путь в эту сферу?

Не помню, чтобы я изначально ставил себе целью карьеру в data science. Тогда меня в основном интересовало то, как люди воспринимают мир, принимают решения и ведут себя. Именно поэтому я и пошёл в психологию. Моей первоначальной целью после выпуска было стать промышленно-организационным психологом — помогать людям быть более продуктивными и счастливыми на работе. К сожалению, для свежих выпускников таких вакансий не было (возможно, я был недостаточно хорош, ха-ха).

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

В свободное время я проходил онлайн-курсы по статистике, SQL и R. Также я ходил на собеседования на начальные позиции, связанные с данными, и в итоге получил работу аналитика данных в IBM. В первый год я в основном работал над аналитическими проектами — например, строил дашборды для цепочек поставок и собирал и анализировал данные Twitter для брендов. Через год у меня появилась возможность присоединиться к команде workforce analytics, где я занимался прогнозированием спроса на вакансии и созданием внутреннего движка рекомендаций вакансий. Эта работа была близка к моей первоначальной цели — использовать данные, чтобы помогать людям на работе, просто я шёл к ней дольше.

Тем не менее появилась ещё одна возможность — присоединиться к e-commerce-стартапу (Lazada). Мне было любопытно, каково это — работать в стартапе, после государственной службы и IBM, и я решился. Я уже писал о том, как это произошло, и не буду повторяться здесь. (Lazada в итоге купила Alibaba, и после ещё одного периода работы в health-tech-стартапе я пришёл в Amazon.)

Какой ваш любимый проект или проект, которым вы особенно гордитесь?

Мой первый самостоятельный учебный проект навсегда останется моим любимым. В рамках того проекта я использовал данные, собранные с Amazon, чтобы построить ML-систему для классификации товаров — по тысячам категорий — на основе их названий. Подход к машинному обучению был «Bayes-ic» (байесовский), но он работал хорошо (top-3 accuracy 0.965). Со временем он расширился до классификации изображений и поиска по изображениям. (Части этого проекта потом использовались и в Lazada, чтобы помогать продавцам категоризировать товары.)

Я горжусь этой работой, потому что, когда я начинал, я почти ничего не знал о машинном обучении и программировании, и мне пришлось (очень сильно) напрягаться, чтобы всё заработало. Чтобы обучить и развернуть модель, мне пришлось научиться работать с AWS EC2, S3 и Route53. Чтобы запустить модель в работу, мне пришлось научиться оборачивать её в приложение на Flask, собирать простой фронтенд на Bootstrap и HTML и возиться с Nginx. Для классификации и поиска изображений мне пришлось научиться применять глубокое обучение для компьютерного зрения, а также использовать предобученные модели (например, VGG, ResNet) для transfer learning.

Я провёл много выходных, борясь с Python, Theano, HTML, AWS и так далее. Огромные усилия, которые я вложил в этот проект, наверное, и объясняют, почему я так им горжусь. То, что я узнал в процессе, резко ускорило моё обучение, а полученные навыки сказались и на продуктивности в работе.

Поиск похожих по виду диванов с «ямочками».

Вы написали множество статей на самые разные темы — от того, что показывает портфолио в data science, до поддержки моделей в продакшене и серии руководств по ML-системам в индустрии. Каков ваш процесс письма и столь продуктивного создания контента?

У меня где-то в заметках есть список потенциальных тем. Всякий раз, когда меня осеняет идея для статьи, я добавляю её туда — это, по сути, просто список заголовков. Например, недавно один друг жаловался на то, как трудно объяснять стейкхолдерам, что машинное обучение может и чего не может — я подумал, что это интересная тема, и добавил её в список. Я также получаю вопросы через свой опрос тем, AMA и из разговоров с друзьями.

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

Раз в неделю я выбираю заголовок, который мне сейчас интереснее всего исследовать. В начале недели я пишу базовый план статьи, в основном используя структуру Why, What, How (другая основная форма — это списки-перечисления). Цель — выплеснуть в этот черновик всё, что приходит в голову, не заботясь о языке, содержании, источниках и прочем. На это уходит примерно час-два.

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

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

Что вам больше всего нравится в написании таких статей?

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

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

Больше всего в письме мне нравится то, насколько оно масштабируемо. Письмо — это O(1). Требуется одинаковое количество усилий, чтобы написать для одного человека или для 10 000. Когда мне многократно задают один и тот же вопрос, я стараюсь написать об этом (например, как писать дизайн-документы по ML, в чём разница между различными ролями в data/ML). Как бонус, моё письмо подарило мне новых друзей — других ML-практиков, венчурных инвесторов, основателей стартапов и т. д. — и привело к нескольким интересным возможностям.

+1 за пост в блоге о вашем опыте в этом. — Dr. L λR Y-54 (@visenger) 10 декабря 2020

Твит выше привёл к материалу о рекомендательных системах реального времени.

Какого рода материалов в DS/ML вы хотели бы видеть больше?

(От TDS: контекст этого вопроса — общее ощущение, что большинство технических статей и туториалов, публикуемых онлайн, ужасны. Чтобы это улучшить, одна из моих целей как редактора — искать и публиковать «призрачное знание» от опытных практиков, а не очередной проходной пост о туториале или студенческом портфолио-проекте.)

Я человек практичный и люблю практический контент. Мне нравятся материалы, из которых я могу учиться на чужих успехах или ошибках и применять это в работе. Именно поэтому я собрал репозиторий applied-ml. Чтение о том, как другие компании подходят к ML-задачам и решают их, очень помогает мне, когда я проектирую собственные ML-системы. Тем не менее я хотел бы, чтобы люди больше делились тем, что НЕ сработало. Может, и не о каждом провальном эксперименте, но общие уроки о том, как не стоит подходить к задаче, сильно экономили бы время.

Мне также нравятся научные статьи, в которых авторы включают ablation-исследования. Удивительно (и немного грустно), как много мы можем сделать с глубоким обучением и при этом так мало знаем о том, как оно обучается.

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

У вас довольно подробная философия письма. Что бы вы посоветовали читателям, которые хотят улучшить своё письмо и выделиться онлайн, ведь всё больше инженеров начинают писать?

Начните. Просто начните.

Обычно я получаю на это два ответа: «А что, если я пишу плохо?» или «Но я ещё не нашёл свою нишу!»

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

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

Нельзя соединить точки, глядя вперёд; их можно соединить лишь оглядываясь назад. — Steve Jobs

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

Письмо — это на 80% подготовка и на 20% само письмо. Письмо даётся тяжело всем. Не вы находите свою нишу — ниша находит вас. Ваше письмо ничего не стоит, если оно бесполезно. Ваш голос — это не то, как вы пишете; ваш голос — это вы сами.

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

Многие вещи в жизни — это одновременно и одиночные, и многопользовательские игры. Письмо, например. Получать обратную связь и заводить новых друзей — многопользовательская часть; учиться и прояснять свои мысли — одиночная. Независимо от исхода в многопользовательской игре, в одиночной вы всегда выигрываете. — Eugene Yan (@eugeneyan) 5 мая 2021

Каковы ваши надежды на DS/ML-сообщество в ближайшие месяцы или пару лет?

Я хотел бы видеть, чтобы сообщество больше думало об ML-системах — а не только об ML-моделях — и о продакшен-стороне дел. У меня есть ощущение, что прямо сейчас большинство людей считают обучение и достижение хороших результатов на валидации финишной чертой (à la Kaggle).

Однако, чтобы ваша модель приносила пользу, нужно сделать гораздо больше. Вам надо настроить пайплайны данных, оркестрировать и планировать их, развернуть, тестировать, мониторить, масштабировать инфраструктуру под задержки и пропускную способность, иметь политики приватности данных, безопасности, дежурств (on-call) и так далее. Всё это занимает время — легко в 20–100 раз больше, чем обучение и валидация прототипа модели.

Вот цифра из ответа на Quora: «По одному проекту, над которым я работал: прототип исследовательского качества — 2 человеко-месяца. Версия продакшен-качества — 117 человеко-месяцев. При этом у прототипа были некоторые дополнительные функции, которых не было в продакшен-версии.» https://t.co/tqjlTjDgGf — Eugene Yan (@eugeneyan) 29 апреля 2021

«У прототипа были дополнительные функции, которых не было в продакшен-версии.»

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

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

То, как мы формулируем задачи, оказывает несоразмерно большое влияние на результаты. Это также относится к выбору правильных положительных и отрицательных меток — негативное сэмплирование — это малопонятное искусство. Полезно также думать о том, как ваша функция потерь коррелирует с офлайн-метриками валидации (recall@k, nDCG), как это коррелирует с онлайн-метриками A/B-тестирования (клики, конверсия) и с нижестоящими бизнес-метриками (выручка, пожизненная ценность клиента).

Если этот материал оказался вам полезен, пожалуйста, ссылайтесь на него так:

Yan, Ziyou. (Jun 2021). Towards Data Science - Author Spotlight with Eugene Yan. eugeneyan.com. https://eugeneyan.com/speaking/tds-author-spotlight/.

или

@article{yan2021towards, title = {Towards Data Science - Author Spotlight with Eugene Yan}, author = {Yan, Ziyou}, journal = {eugeneyan.com}, year = {2021}, month = {Jun}, url = {https://eugeneyan.com/speaking/tds-author-spotlight/} }

Присоединяйтесь к 11 800+ читателям, получающим новости о машинном обучении, RecSys, LLM и инженерии.