Устраните повторяющиеся болевые точки, поняв основные закономерности

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

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

  1. временная перегрузка,
  2. встреча с параличом,
  3. булавочные фабрики,
  4. чрезмерное развитие, основанное на резюме, и
  5. ПРИСЛУШИВАНИЕ.

(Конечно, этот список не претендует на полноту, и не все элементы в списке относятся исключительно к области науки о данных.)

Готовый? Давайте углубимся.

Специальная перегрузка

Каждый специалист по данным знает специальные запросы. Это запросы от сотрудников и заинтересованных сторон, такие как…

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

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

👉 Что делать вместо этого:

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

  • Во-первых, это уменьшает количество переключений контекста для вас. Переключение контекста обходится дороже, чем кажется: «20-минутный перерыв во время работы над проектом влечет за собой два переключения контекста; на самом деле это прерывание приводит к потере нескольких часов действительно продуктивной работы», — пишет Дэйв О’Коннор в Проектирование надежности сайта: как Google управляет производственными системами.
  • Во-вторых, он посылает правильное сообщение. Если вы сразу же позаботитесь о специальных запросах, люди могут воспринять это как приглашение обращаться к вам с дополнительными специальными запросами в будущем. Это не та позиция, в которую вы хотите себя поставить.

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

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

Паралич встречи

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

👉 Что делать вместо этого:

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

Пропустите экземпляр повторяющейся встречи и посмотрите, что произойдет. Иногда вы оказываетесь в списке приглашенных на серию повторяющихся встреч, даже если не уверены, действительно ли требуется ваше присутствие. У главного инженера Amazon Стив Хьюн есть полезный совет на этот случай: одну неделю просто не приходите на следующую встречу и смотрите, что произойдет. Если никто не спросит, где вы были, это означает, что вы можете навсегда удалить эту серию встреч из своего календаря. Если люди спрашивают о вашем отсутствии, извинитесь и скажите, что вернетесь в следующий раз.

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

Булавочные фабрики

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

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

👉 Что делать вместо этого:

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

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

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

Чрезмерное развитие, основанное на резюме

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

👉 Что делать вместо этого:

Поэтому хорошая стратегия состоит в том, чтобы максимально упростить производственные системы и оставить дикие идеи для исследовательских проектов, которые могут привести к публикациям. Инженер LinkedIn Staff ML Брэндон Рорер говорит об этом так:

«Совет по стратегии машинного обучения: если у вас есть проблема, создайте два решения — глубокий байесовский преобразователь, работающий в многооблачной среде Kubernetes, и SQL-запрос, построенный на наборе вопиюще упрощенных предположений. Поместите один в свое резюме, другой в производство. Все идут домой довольные».

ВНИМАНИЕ

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

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

👉 Что делать вместо этого:

  • Всегда следуйте научному методу. Прежде чем проводить какие-либо эксперименты, всегда четко формулируйте гипотезу. Это может быть так просто, как: «Я предполагаю, что модель BERT лучше, чем мешок слов, потому что в этой проблеме важен контекст слов, а не только их частота». Экспериментирование без гипотезы — это не наука, это лженаука.
  • Оцените дисперсию. Вместо того, чтобы просто измерять точность модели на тестовом наборе, попробуйте также оценить ее дисперсию, чтобы знать, насколько статистически значимы изменения. Вы можете оценить дисперсию, например, путем начальной загрузки, то есть создания нескольких измерений из разных случайных подмножеств (с заменой) тестового набора.
  • Не полагайтесь на офлайн-показатели, которые легко обмануть. Всегда принимайте окончательное решение о запуске на основе производительности онлайн-модели.
  • Задокументируйте все. Даже если эксперимент оказался неудачным (он не улучшит производительность модели), задокументируйте, что вы пробовали, почему вы это делали и что вы нашли. Оставленный такой бумажный след поможет вам понять и сообщить позже, как вы пришли к окончательному выбору модели, и не позволит вам (и другим) снова попробовать то же самое.

Последние мысли

Давайте резюмируем эти 5 антипаттернов и их соответствующие разрешения следующим образом:

  1. избегайте специальной перегрузки: практикуйте объединение прерываний,
  2. избегайте паралича встреч: уходите с встреч, которые на самом деле не требуют вашего присутствия,
  3. избегайте фабрик по производству булавок: работайте в организациях, поддерживающих сквозное владение моделями,
  4. избегайте чрезмерного развития, ориентированного на резюме: оставляйте дикие идеи для своих исследовательских работ, а не для производства, и
  5. избегайте придираться: всегда следуйте научному методу и формулируйте гипотезу до проведения каких-либо экспериментов.

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

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

📫 Подпишитесь и получайте мою следующую статью прямо на ваш почтовый ящик.
💪 Стань участником Medium и разблокируйте неограниченный доступ.
📖 Получите мою электронную книгу, 50 страниц, заполненных практические советы по машинному обучению из траншей.