Краткое изложение избранных выступлений и извлеченных уроков

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

An ML Fairytale — основной доклад Вики Бойкис

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

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

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

Мораль этой истории заключается в том, что, как специалисты по работе с данными, мы все являемся вектореллами.

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

Ad astra per aspera: «К звездам через трудности»

Положительным моментом этой истории является то, что надежные основы строятся на продвинутой работе. Те скучные основы, которые вы не увидите в средствах массовой информации (кроме NormConf!), являются основами, которые, если их освоить, приведут к более продвинутой (и потенциально более продуктивной) работе.

Как перевести на PM и обратно — Кэти Бауэр

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

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

Общая эвристика, которой поделилась Кэти, заключалась в том, чтобы планировать свою работу в соответствии с позиционированием продукта:

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

Утрачено при переводе

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

Вам нужно тщательно выбирать сражения:

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

Просто используйте одну большую машину для обучения модели и логического вывода — Джош Уиллс

Джош Уиллс поделился своим путешествием из:

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

В начале своей карьеры Джош работал над стеком аналитики, в который входили MySQL, Pearl и R. Он довольно хорошо разбирался в этом стеке, но его менеджер дал ему совет: «Будьте осторожны с тем, в чем вы хороши. Это указывало на то, что если он продолжит этот путь и станет еще лучше в этом, он может закончить тем, что будет администрировать базы данных MySQL до конца своей карьеры. Эта история подчеркивает основную мысль доклада: если вы хорошо разбираетесь в построении крупномасштабных распределенных конвейеров, вы можете забыть, что никогда не хотели добиться успеха в Spark и Kubernetes — вы хотели научиться решать важные проблемы ML.

За этим последовали интересные личные истории, которые привели Джоша к следующим выводам о том, почему одна большая машина для машинного обучения — это правильное решение, которое может принять почти каждый:

  1. Это полезная эвристика для выявления важных проблем. Если ваш менеджер просит вас поработать над чем-то, что кажется важным, но рассматривает инвестиции, скажем, 12 долларов в час для большого инстанса EC2 на AWS, то это хороший показатель того, что эта проблема машинного обучения не так важна, как кажется. быть. Важные проблемы требуют специальной инфраструктуры, инструментов и соответствующих ресурсов.
  2. Стоимость одной большой машины — это функция, а не ошибка. Когда вы тратите много денег на выделенную машину для машинного обучения, это подтверждение того, что вы работаете над чем-то значимым, и вам нужно сосредоточиться, довести дело до конца и отключить ресурсы, когда вы закончите. Создание экономичной масштабируемой до нуля инфраструктуры для обучения и экспериментов с машинным обучением часто отвлекает, решая вокруг проблему. Если проблема, которую вы решаете, не оправдывает затрат на одну виртуальную машину, достаточно ли эффективна эта работа для бизнеса? Стоит ли вообще решать эту проблему?
  3. Выберите скучную технологию, потому что она позволяет вам сохранить ваши инновационные токены. Каждая компания имеет ограниченное количество инновационных токенов для использования новой платформы, создания собственного хранилища данных и т. д. Эксперименты с новой технологией легче оправдать, если запустить ее на одном компьютере, не неся затрат на распределенная система, например решение проблем координации сети или сервера/кластера. Например, вы все еще можете запустить Ray или Dask на одной большой машине, если хотите протестировать ситуацию. Исключив распределенные системы из общей картины, вы сможете сохранить взаимозаменяемость ваших инновационных токенов.
  4. ML сам по себе сложен, нет необходимости добавлять распределенные системы, чтобы еще больше усложнить задачу. Джош упомянул анекдот о том, что Stripe до сих пор обучает свои модели машинного обучения на одной машине.
  5. Сделайте цикл обратной связи быстрым. Устранение неполадок в распределенных системах затруднено. Сделать то же самое на одном компьютере можно так же просто, как запустить htop и объединить его с tail журналов. Эти две простые команды CLI дают вам больше информации о том, что происходит в процессе обучения машинному обучению, чем любой инструмент MLOps, например, как работа распределяется между ядрами, использование памяти для каждого процесса и исследование причин зависания определенного процесса.

Как выбрать правильный тип экземпляра в общедоступном облаке?

  1. Выберите экземпляр с максимальным объемом ОЗУ, чтобы в памяти идеально помещались все необходимые данные.
  2. Получите больше хранилища. Стандартный экземпляр EC2 имеет только достаточный базовый объем диска, необходимый для работы виртуальной машины, а не хранилище, необходимое для хранения данных и промежуточных результатов. Чтобы решить эту проблему, подключите к своему инстансу большой том EBS.
  3. Если вы не используете компьютер, выключите его, сделайте снимок тома EBS, сохраните его, сохраните все промежуточные данные на S3 и очистите, выключив или прервав работу экземпляра.

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

Не делайте невидимую работу — Крис Албон

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

Проблема:

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

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

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

Решение:

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

  • Создайте простой журнал личной активности в своем приложении для создания заметок
  • Добавьте короткие заметки о том, что вы делали в определенный день, и отправьте их себе в виде сообщения Slack.
  • Старайтесь писать по 2-3 строчки в день любым удобным для вас способом, чтобы начать письменную запись.
  • Посетите bragdocs.com для получения дополнительной помощи по этому вопросу.

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

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

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

Спасибо, НормКонф!

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