10 первых ошибок в карьере ML-инженера
Всем привет, Меня зовут Богдан Печёнкин, Я автор Симулятора ML.
Сегодня Я расскажу Вам о 10 ошибках, которые могут поджидать Вас в первые годы вашей карьеры в машинном обучении. Почти каждую из этих ошибок допускал Я сам и надеюсь, что Ваша осведомлённость о них после прочтения этого поста поможет избежать хотя бы часть из них.
Итак, приступим.
Ошибка 1. Начинать с машинного обучения
Научился пользоваться молотком — весь мир кажется гвоздями
Само машинное обучение никому не интересно. Заказчик заинтересован в увеличении прибыли, сокращении издержек и решении проблем пользователя. Если задачу можно решить простой эвристикой, написанной на коленке за два вечера, — зачем усложнять жизнь себе и другим, сжигая десятки рабочих часов на моделирование, оптимизацию, усложняя систему и увеличивая число мест, где что-нибудь может сломаться?
Порой константный бейзлайн для прогноза спроса (скажем, медиана продаж за 90 дней), который можно «деплоить» прямо SQL-запросом, надёжнее, чем градиентный бустинг, который долго обучается, много весит, должен где-то сохраняться и версионироваться, требует периодического дообучения и порождает ряд других инфраструктурных проблем. Притом прирост качества может оказаться всего 2–5% по сравнению с медианным прогнозом или линейной регрессией (что несущественно с учётом усложнения поддержки, когда речь идёт о построении нового сервиса).
Ошибка 2. Не писать дизайн-документ
Прежде чем начинать что-то делать, нужно понять, что ты собираешься делать.
Даже если вы берётесь за короткий проект в 2 недели, необходимо описать ваше намерение текстом. Я предпочитаю фреймворк Why-What-How.
Why? Почему возникла потребность в новом сервисе? Что за проблему мы решаем? Какую пользу мы хотим принести? Здесь вы описываете весь необходимый контекст и цели нового проекта.
What? Что этот сервис будет делать, каким будет результат его работы? На каких метриках это отразится? Как он будет взаимодействовать с существующими системами? Здесь мы описываем требования к сервису и критерии успеха.
How? Как мы достигнем поставленной цели? Как сформулируем проблему на языке машинного обучения? Какие данные нам нужны? Как оценим результат и поймём, что мы на что-то повлияли? Как будем проводить А/B-эксперимент?
Поговорив со всеми заинтересованными лицами и оформив 1-страничный документ, вы будете уверены, что все участники (вы, ваши коллеги, менеджер, заказчик и другие) правильно друг друга поняли, согласовали ожидания и говорят на одном языке.
Полноценный дизайн-документ для более долгосрочных ML-проектов требует более глубокой проработки и включает в себя
● цели проекта и формулировку проблемы, которую надо решить;
● анализ подобных решений по индустрии;
● описание онлайн и оффлайн метрик;
● описание необходимых данных и их разметки (где брать X, где брать Y);
● описание того, какие бейзлайны попробуем в первую очередь и как будем анализировать модель;
● как будет выглядеть пайплайн обучения модели и деплой;
● дизайн A/B-теста (включая сценарии, что будем делать, если просядут метрики, что-то отвалится, или возникнут другие критические проблемы);
●, а также шаги масштабирования и поддержка сервиса после раскатки.
Ошибка 3. «Тесты? Документация? — как-нибудь потом!»
Результат работы ML-инженера (как и любого другого разработчика) — это не только работающий код, но и всё, что помогает другим инженерам быстро разобраться в его логике, поддерживать, изменять и дополнять. Двумя важнейшими инструментами здесь являются документация и тесты.
Документация облегчает коммуникацию с другими командами, сохраняет актуальный контекст проекта и уменьшает Bus Factor (нет необходимости каждый раз дёргать вас, чтобы разобраться в части проекта, которую писали вы). Это особенно важно для ML-проектов, поскольку логика их работы понятна остальным меньше всего и требует больше пояснений.
Проектная документация описывает логику работы сервиса и протокол взаимодействия с другими сервисами, что крайне ценно как для коллег, которые не пишут код (менеджеры и заказчики), так и для коллег из других отделов (аналитики, backend-разработчики, дата-инженеры).
Документация к коду (которую мы пишем под названием класса или функции) даёт понять, что происходит внутри (включая формат входа и выхода), не читая сам код.
Многие откладывают написание или обновление документации до лучших времён, когда горящие фичи доедут до пользователей, а менеджер уйдёт в отпуск. В итоге новому сотруднику приходится лично опрашивать всех членов команды, чтобы разобраться как работает каждый компонент, тогда как при наличии хорошей документации он справился бы самостоятельно. Приятный бонус дизайн-документа, о котором мы рассказали выше: он помогает начинать вести документацию не с чистого листа. Если в вашем проекте (даже pet-проекте!) ещё нет документации, начните её сегодня.
Другой инструмент, не увеличивающий кодовую базу напрямую, но существенно влияющий на её качество, — это тесты. Популярно мнение, что код, включающий алгоритмы машинного обучения, «сделан из другого теста» и его трудно тестировать. В ML слишком много неопределённости, это что-то волшебное и неподатливое. На деле, ML-код можно и даже необходимо покрывать тестами, однако у них есть своя специфика.
Большую долю ML-проекта занимают данные и их обработка на разных этапах до и после обучения или применения моделей. Здесь работают стандартные тесты: unit-тесты, интеграционные и нагрузочные тесты, регрессионные тесты, мок-тесты, smoke-тесты и т. д.
Часть тестов, что касается конкретно моделей, нуждается в специализированных тестах: consistency тесты, negation тесты, тесты инвариантности, exact-value тесты, direction expectation тесты.
Покрытие кода тестами предотвращает ошибки в будущем и упрощает поддержку кода. Лучше потратить час на написание тестов сегодня, чем 4 часа в неопределённый момент в будущем на поиск и починку бага. Неочевидный бонус тестов в том, что они отчасти выполняют роль документации к коду, предоставляя запускаемые примеры использования той или иной функции: вот, что на входе, вот, что ожидается на выходе.
Ошибка 4. «Я птичка, мне такое сложно»
Ещё одно препятствие для роста — это страх перед сложностью:
«В Data Science много математики, поэтому я эта профессия не для меня»;
«Документация библиотеки на английском, поэтому я ничего не пойму»;
«Моей экспертизы недостаточно, чтобы написать дизайн-документ»;
«Scikit-learn, pandas и numpy писали сверхразумы, поэтому я не разберусь в их исходном коде»;
«Я не знаю Java/PHP/С++, поэтому я не смогу посмотреть в часть backend-кода, который обращается к моей ML-модели».
На деле оказывается, что в машинном обучении нет сложной математики; что технический английский не такой уж сложный и, если переводить слово за словом, довольно быстро запомнишь весь необходимый словарь; что дизайн-документ способен написать даже стажёр, пускай короткий и с разными неточностями, но уже вполне выполняющий свою основную функцию и предотвращающий множество проблем на стадии реализации.
В частности исходный код в наших любимых библиотеках не такой уж мудрёный (просто его много), и если внимательно разбирать строчку за строчкой, ты не только поймёшь, как всё работает под капотом, но и освоишь новые приёмы, не говоря уже о повышении качества твоего кода на Python. Ведь он состоит всего-навсего из списков, словарей, функций, классов, циклов, if-else и других знакомых вам кубиков Lego.
Если заглянуть в любимые библиотеки, код оказывается вовсе не сложным. Читая строчку за строчкой, легко поймёшь, что происходит, попутно открывая для себя новые приёмы.
Кроме того, в том же scikit-learn можно изучить множество референсов написания тестов для моделей машинного обучения. Перейдите по ссылке, это правда не сложно!
Ошибка 5. Говорить сложно о простом
Если вы не можете что-то объяснить 6-летнему ребёнку, вы сами этого не понимаете.
Говоря о сложности, другая распространённая ошибка — говорить с коллегами без ML-бекграунда на языке ML. В итоге у многих людей складывается впечатление, что ML инженеры и дата сайентисты — это выскочки, которые говорят на своём эльфийском языке и считают всех вокруг за идиотов. Будьте здесь исключением.
Освойте навык говорить просто о сложном. Это вам пригодится как на стадии защиты проекта до его реализации, так и во время презентации решения коллегам (например, после успешно проведённого A/B эксперимента). Мало кто любит ощущать себя глупым, поэтому избегайте сложных терминов абсолютно везде, где можно, чтобы не вставлять себе палки в колёса и упрощать коммуникацию с вами.
Секретный приём, который поможет вам говорить понятно, — это black-box мышление: говорите меньше о том, что происходит внутри сервиса, и фокусируйтесь на том, что снаружи: какие данные модель принимает на входе (например, просмотры и клики), на что влияет и какую ценность приносит бизнесу (модель показывает более релевантную рекламу, что увеличивает конверсию в покупку на X%).
Этот приём пригодится вам не только во время общения с коллегами, но и в обучении. Когда вы изучаете новый алгоритм, новую идею или читаете статью, сперва ищите ответ на вопросы: какую задачу это решает? что на входе и на выходе? где это работает и где не работает? как это использовать? –, а уже впоследствии, если в этом есть необходимость, погружайтесь в детали. К слову, такой практико-ориентированный подход к изучению машинного обучения сокращает объём необходимой математики (по аналогии, чтобы печь самые вкусные пирожки, не обязательно иметь степень доктора наук по органической химии).
Ошибка 6. Жить в Jupyter-тетрадках
Моделирование в работе ML-инженера занимает меньше 20% времени
Инструмент Jupyter-тетрадок замечателен. Он сильно понижает планку входа в Data Science и делает машинное обучение доступным. Например, тетрадки — отличный инструмент для EDA (когда нужно быстро посмотреть в данные и понять, «о чём они»), для подготовки отчётов, для эспериментирования с разными моделями и других ad-hoc задач (ad-hoc — «по случаю»).
Однако у всего этого есть и минус. Код в тетрадках — это всегда черновой код. Он неструктурирован (не разбит на файлы), его трудно версионировать, проводить код ревью, воспроизводить и переиспользовать (часто теряется последовательность, в которой нужно запускать ячейки, чтобы воспроизвести результат). Jupyter-код грязный, не покрыт тестами, в нём сложно ориентироваться другим. Это не production-ready код. Вы не обернёте этот код в Docker и не превратите в ML-сервис.
Jupyter — часто не ваш бро, когда дело касается серьёзных проектов.
Вместо этого как можно раньше (и во время обучения, и во время работы над реальным проектом) познакомьтесь с IDE (среда разработки; Мой фаворит VSCode).
Разбивайте код проект на модули, выносите воспроизводимые элементы в файлы (например, data.py, model.py, train.py, metrics.py).
Разберитесь с путями и импортами, чтобы ваш код мог воспроизвести любой инженер и у него попадали в область видимости все необходимые файлы.
Вынесите все необходимые сторонние библиотеки (и зафиксируйте их версии) в requirenments.txt, научитесь работать в виртуальном окружении (conda помогает это делать легко и быстро); познакомьтесь с Docker.
Заведите линтеры (в VSCode это делается в 2 клика): black, pylint, flake8. Это позволит контролировать форматирование кода и соблюдение конвенции PEP 8, что повышает качество и читаемость вашего кода. Также этому поспособствуют документация и указание типов, которые при беглом написании кода в Jupyter часто пропускаются.
Покройте код тестами, это делается просто и приятно. Pytest ваш лучший друг здесь.
В конечном итоге, чтобы ваш проект ожил и «начал приносить X денег каждые Y дней», его в любом случае придётся переносить в Python-файлы. Работа сразу в IDE, с одной стороны, будет вас дисциплинировать, с другой — сильно сокращает время превращения вашей модели в полноценный ML-сервис.
Ошибка 7. Учиться в отрыве от реальных задач
Теория без практики — рюкзак с учебниками по плаванию за спиной тонущего.
Многие кандидаты, приходящие на собеседования, вроде и всё знают, но когда даёшь конкретный кейс, теряются и не могут приложить знания и навыки к реальной задаче. Всё упирается в нехватку насмотренности. На Мой взгляд, обучать машинному обучению необходимо не на абстрактных задачах машинного обучения, а на бизнес-проблемах:
сервис рекомендаций на стриминговой платформе,
матчинг товаров на маркетплейсе,
динамическое ценообразование в приложении такси,
прогноз оттока на образовательной платформе,
антифрод в платёжной системе.
Обучаясь в отрыве от задач из индустрии, вы копите всё больше знаний, не формируя из них цельные структуры в голове, не тренируя интуицию, где их можно применить. Лучше всего превращает знания в навыки, как ни странно, практика: стажировка, пет-проекты, соревнования, хакатоны, симуляторы.
Andrej Karpathy (бывший директор по Искусственному Интеллекту в Tesla) даёт следующую рекомендацию, как стать экспертом в любом деле: учиться по запросу. Начинать работать руками как можно раньше, взяв конкретный проект или конкретную задачу и начав её решать. Как только вы сталкиваетесь с трудностью, восполняйте этот пробел в знаниях соответствующим уроком из курса или главой из учебника. Тогда эти знания будут привязываться к конкретной проблеме в вашем опыте, когда у вас был на них эмоциональный запрос («пока я не знал X, это не позволяло мне сделать Y»).
Ошибка 8. «В ML нормально не успевать в срок»
Долгое время у Меня было убеждение, что в ML давать точные эстимейты практически невозможно (эстимейты — оценки времени выполнения), ведь ML — это особая магическая область, где много неопределенности и много что может пойти не так.
Я расстался с этой иллюзией, когда начал пробовать: декомпозировать проекты на стадии, стадии на задачи, задачи на подзадачи. Разбив что-то большое, новое и незнакомое на знакомые элементы, мы ищем что-то похожее из нашего опыта (Мне помогает приложение для трекинга времени и последующий анализ статистики) и домножаем на 2 (или другой коэффициент, зависящий от степени неопределённости данного шага). Это уже даёт сносные оценки, с которыми можно работать.
Часто Must Have задачи в ML-проектах не требует длительного рисёрча и имеют довольно высокую степень определённости.
Eщё одним эффективным инструментом, помогающим не срывать сроки (не только в ML), являются приоритеты. Мне нравится MoSCoW фреймворк. Он заключается в разделении задач на следующие категории (+5 примеров для каждой):
Should Have — важные задачи, которые мы должны выполнить, но и без них уже что-то будет работать. Если мы их не успеем, будет очень больно, но не смертельно.
Настройка пайплайна для регулярного дообучения модели,
Углублённый EDA и анализ остатков модели,
Эксперименты с продвинутыми признаками,
Добиться ROC-AUC больше чем 0.9 (при требованиях в 0.8),
Написание юнит-тестов и документации проекта.
Could Have — то, что хорошо было бы сделать, но мы этим займёмся только если на это будет оставаться время. Сюда может входить рефакторинг
Покрытие сервиса мониторингом,
Перевод версионирования библиотек с pip на poetry,
Версионирование моделей (MLflow) и данных (DVC),
Рефакторинг проекта, оптимизация инференса до 50 ms,
Добавление линтеров (black, flake8) в CI/CD-пайплайн.
Часто Must Have задачи в ML-проектах не требуют длительного рисёрча и имеют довольно высокую степень определённости.
На стадии планирования мы закладываем львиную долю времени (например, 60–70%) на Must Have задачи, оставляя буфер (например, 30–40%) и заполняя его Should Have и Could Have задачами. Таким образом, если мы не успеем всё из критически важных (Must Have), мы пожертвуем Could Have или даже Should Have. Разумеется, такой метод планирования и бюджетирования времени также целесообразен далеко за пределами машинного обучения.
Ошибка 9. Раскатка без A/B-экспериментов
То, что нельзя измерить, нельзя улучшить
В это трудно поверить, но не для всех очевидна необходимость проведения A/B-тестов при выкатке нового продукта или новой версии существующего сервиса. A/B тесты необходимы для честного замера эффекта вашей работы (что суммарно позволит оценить в будущем, сколько денег вы и ваша команда принесли) и принятия решений на основе метрик и данных, а не вслепую («по интуиции»).
Если A/B-тесты ещё не проводились в компании, где вы работаете, подайте пример — начните это делать первым. Для самого первого A/B-теста достаточно:
Jupyter-тетрадки, чтобы оценить длительность эксперимента и/или размер минимального ожидаемого эффекта,
И несложной инструкции для backend-разработчика (по какой логике делить пользователей, куда перенаправлять, сколько будет длиться эксперимент).
Полноценный A/B-тест начинается с дизайна эксперимента: гипотезы, ключевых и контрольных метрики, стратегии разбиения пользователей, фиксации ошибок I и II рода, подбора стат.теста, оценки длительности эксперимента и детектируемого эффекта, а также проведения синтетических A/A и A/B-экспериментов, чтобы удостовериться, что мы всё сделали правильно.
Один из самых быстрых способов закрыть для себя вопрос А/В-тестов — это пройти Симулятор А/В от Александра Сахнова, где вы в короткие сроки научитесь разрабатывать оптимальный дизайн эксперимента, проверять гипотезы со сложными метриками и пользоваться современными методами повышения чувствительности тестов.
Ошибка 10. Браться за любой проект
Сказали делать — буду делать
И последняя ошибка, которую рассмотрим сегодня, — это слепо верить во всемогущество машинного обучения. Не каждый проект машинного обучения заслуживает того, чтобы появлиться на свет. Многие ML-проекты — мертворождённые дети. Они могли не начаться в принципе, если перед их стартом был бы проведён полноценный рисёрч, как следует оценён потенциальный аплифт и учтены все возможные риски.
Если этого не сделать, в частности, если на эту фазу в дизайн-документе уделить слишком мало времени (предвзято думая, что проект 100% стрельнет) — это может обернуться тем, что мы выясним это, когда будет слишком поздно, а на проект будут потрачены месяцы.
ML-инженер, который который берётся за всё, что скажут.
Маловероятно, что проект, за который вы берётесь, никто до вас ещё не делал. Ценность больших DS и ML-коммьюнити в том, что в них можно найти специалистов, которые уже реализовали проект, которым вы только начинаете заниматься. Изучайте большое количество статей, обращайте внимание на то, какого прироста по бизнес-метрикам удалось добиться. Оцените, с какими денежными оборотами и с каким числом пользователей имеет дело ваша компания. Где-то прирост выручки на 0.5% уже оборачивается десятками миллионов, а для какого-то небольшого сервиса и +10% не окупают инвестиции.
Наконец, полезным является разделение ML-сервисов на два лагеря:
Value-added сервисы. Те продукты, где машинное обучение не является жизненно важным, но на какое-то число процентов оптимизирует некоторый процесс в системе. Например, цены может выставлять и человек, поэтому динамическое ценообразование — это value-added сервис. Value-added сервисы дают количественное улучшение.
С другой стороны, существуют value-enabling сервисы. Речь идёт о продуктах, которые не могут существовать без машинного обучения (процессы, где ML жизненно важен). Например, нельзя построить поиск на маркетплейсе без алгоритмов машинного обучения, поэтому поиск часто является первым проектом для ML-команды на маркетплейсе. Value-enabling сервисы дают качественное улучшение.
Как можно раньше сориентируйтесь, где вы находитесь. Очевидно, value-enabling сервисы более критичны для бизнеса, имеют потенциал существенно увеличить выручку и обладают меньшим риском закрыться. Если же вы находитесь в value-added сервисе, дотошный анализ аналогов и их успехов поможет сформировать реалистичные ожидания для заказчика и заранее предотвратить потерю инвестиции, переключившись на проекты с меньшим риском.
Многие из этих шишек можно набить ещё до попадания на свою первую работу. Одно из мест, где можно это сделать — Симулятор ML. Здесь как в песочнице вы получаете опыт реальной работы ML инженера: от разработки бизнес-метрик и выгрузки данных — до деплоя ML-сервисов и проведения A/B-экспериментов.
Каждая задача Симулятора — это квест, который погружает в свою историю (e-com, ритейл, соц.сети, фин-тех, реклама) и свой продукт (ценообразование, рекомендашки, прогноз оттока, матчинг). Как персонаж в игре, он водит вас от инструмента к инструменту на инфраструктуре, приближенной к индустрии (ClickHouse, PySpark, MLFlow, FastAPI, Docker). Всё это вырабатывает насмотренность, формирует целостное представление, где и как применять машинное обучение, и набивает руку писать production-ready сервисы с нуля.
Помните, что не ошибается тот, кто ничего не делает. Начните свой карьерный путь с практики в Симуляторе ML.
