Всем привет, Меня зовут Богдан Печёнкин, Я автор Симулятора 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-сервис.

Вместо этого как можно раньше (и во время обучения, и во время работы над реальным проектом) познакомьтесь с 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 (или другой коэффициент, зависящий от степени неопределённости данного шага). Это уже даёт сносные оценки, с которыми можно работать.

Eщё одним эффективным инструментом, помогающим не срывать сроки (не только в ML), являются приоритеты. Мне нравится MoSCoW фреймворк. Он заключается в разделении задач на следующие категории (+5 примеров для каждой):

• Must Have – задачи критической важности, без которых не будет ничего работать.

  • ML System Design документ,

  • Сбор и чистка данных, выделение базовых фичей,

  • Построение валидации, имплементация метрик,

  • Обучение бейзлайна,

  • Деплой ML-сервиса и интеграция с бекендом.

• Should Have – важные задачи, которые мы должны выполнить, но и без них уже что-то будет работать. Если мы их не успеем, будет очень больно, но не смертельно.

  • Настройка пайплайна для регулярного дообучения модели,

  • Углублённый EDA и анализ остатков модели,

  • Эксперименты с продвинутыми признаками,

  • Добиться ROC-AUC больше чем 0.9 (при требованиях в 0.8),

  • Написание юнит-тестов и документации проекта.

• Could Have – то, что хорошо было бы сделать, но мы этим займёмся только если на это будет оставаться время. Сюда может входить рефакторинг

  • Покрытие сервиса мониторингом,

  • Перевод версионирования библиотек с pip на poetry,

  • Версионирование моделей (MLflow) и данных (DVC),

  • Рефакторинг проекта, оптимизация инференса до 50 ms,

  • Добавление линтеров (black, flake8) в CI/CD-пайплайн.

• Won’t Have – всё, что выходит за рамки текущей фазы проекта (или текущего спринта)

  • Добиться ROC-AUC больше 0.98,

  • Исправить все замечания линтеров по коду проекта,

  • Учесть проблему каннибализации продаж товаров,

  • Добавить учёт Real-Time фичей для рекомендаций,

  • Переписать наш фреймворк загрузки данных с нуля.

На стадии планирования мы закладываем львиную долю времени (например, 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% стрельнет) – это может обернуться тем, что мы выясним это, когда будет слишком поздно, а на проект будут потрачены месяцы.

Маловероятно, что проект, за который вы берётесь, никто до вас ещё не делал. Ценность больших 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.