Привет, Хабр! ?
Позвольте представиться: я — Настя, Data Scientist и TeamLead в одной вполне себе серьезной компании (когда чистишь данные в 3 ночи, чувствуешь себя совсем не серьезно, но это детали). Веду свой скромный телеграм‑канальчик, где делюсь болью, радостью и абсурдом нашей необъятной профессии. И вот сегодня хочу вынести на ваш суд тему, которая не дает спать спокойно не только мне, но и многим моим коллегам.
Помните тот трепетный момент, когда вы только начинали свой путь в Data Science? Я — очень хорошо. Картинка была радужной: ты — повелитель нейросетей, твои модели творят магию, а бизнес‑задачи падают к ногам, поверженные точностью в 99.9% (ну или хотя бы 97%).
Курсы, будь то знаменитые онлайн‑платформы или университетские программы, учат нас прекрасному: бустинги, метрики, градиентный спуск, SVM, k‑means, сверточные слои... Это наш фундамент, наш джентельменский набор. И да, именно за этим набором охотятся 90% рекрутеров на собеседованиях. Создается стойкое ощущение, что я и интервьюер одновременно загуглили «Топ-50 вопросов на DS собеседовании» и теперь ритуально их отрабатываем. Ну, must have, что уж тут.
Но потом ты выходишь из уютного мира clean data и идеальных датасетов в дикие джунгли реального проекта. И здесь начинается магия настоящей работы. Та самая, про которую не снимают вдохновляющие ролики. А порой многие именно тут и бросают этот, казалось бы увлекательный и перспективный карьерный путь в мир ML...

Из чего на самом деле состоит моя работа (спойлер: это не только XGBoost)
1. «Где взять данные?» или Квест «Найди то, не знаю что»
На курсах: «Вот вам датасет iris.csv. Предскажите класс цветка». На крайний случай - папочка с примерами данных.
В реальности: Данные живут в 15 разных базах, у каждой свои правила доступа. Половина — в устаревших хранилищах, про которые все забыли. Ключи для join-ов где-то потерялись в 2021-м. А те данные, что есть, оказывается, логировались с ошибкой в течение полугода.
Но это лишь цветочки. Главная боль начинается, когда вообще нет инфраструктуры для сбора нужных данных. Ты не можешь собрать их руками, потому что их просто не существует в природе в том виде, в каком тебе нужно. Приходится работать с тем, что есть: обучаешь модель на том, что смог наскрести по сусекам, и она на тестовых данных выдает те самые 99%, от которых глаза сияют, как у ребенка на Новый год.
А потом выкатываешь ее на продакшен... и оказывается, что данные в реальном мире — это совсем другой зверинец. Там такие признаки и такие распределения, которых ты даже представить не мог, потому что не было возможности их собрать и посмотреть. Модель, видевшая только «правильных» уток, смотрит на продешного утконоса (полуутка-полубобра) и уверенно называет его бульдозером. И ты понимаешь, что не можешь сделать хорошую модель не потому, что ты плохой специалист, а потому что неизвестно, как собрать выборку, хоть сколько-нибудь похожую на продакшен. А как ее размечать — это вообще отдельный квест, про который тоже заранее не узнаешь. Так что да, моя работа — это на 80% data archaeology, где я с кисточкой пытаюсь откопать черепки данных и собрать из них хоть что-то осмысленное.
2. «А что вообще нужно бизнесу?» или Игра в испорченный телефон
Прелестный диалог, который случался если не с вами, то с вашим коллегой точно:
— Бизнес: «Нам нужно предсказывать отток клиентов!»
— Я (сияя от счастья): «Отлично! Это же классическая задача бинарной классификации!»
— Через месяц, после сдачи модели:
— Бизнес: «Супер! А теперь покажите, кого именно из этих клиентов нужно удерживать? И как? И сколько на это можно потратить? И почему ваша модель сказала, что наш самый прибыльный клиент — оттокер?»
Оказывается, часто бизнес лишь абстрактно понимает, что ему «надо что-то с ИИ». Задачи ставятся размыто или даже некорректно. «Хотим умную рекомендашку» — это может означать что угодно: от простого сопутствующего товара до сложнейшей системы ранжирования с учетом тысяч факторов.
Самое веселое начинается, когда ни мы, ни бизнес не можем заранее придумать кристально чистую метрику успеха. «Ну, там как-то видно будет, по деньгам», — говорят они. А в голове у меня уже проносится ужас: как я буду A/B тестить свою модель, если непонятно, что мерить?
И вот ты уже не божество данных, а дипломат-зануда, который ходит по митингам и пытается на живом языке объяснить, что:
а) решение — это не одна волшебная модель, а целый сложный pipeline;
б) для него нужны совсем другие данные и другая разметка;
в) то, что просили, не сработает, а вот это вот — странное и непонятное — сработает, и вот почему.
Спасать бизнес от него самого — это не проходили на курсах. Это сакральное знание.
3. «Собери мне пайплайн» или рост в архитектора
Вот он, момент истины! Моя модель готова. Точность 98%! Jupyter Notebook ликует, метрики сияют, и кажется, вот он — финиш. Я — Мастер Науки о Данных! Ан нет. Именно в этот момент раздается голос моего внутреннего (а потом и реального) проджект-менеджера: «Круто! А теперь давайте это вот всё… production».
И тут мой скромный цветочек model.fit() сталкивается с ураганом реального мира. Я быстро понимаю, что data scientist во мне временно откладывают в сторону, а на сцену выходит архитектор — тот, кто должен спроектировать не просто pipeline, а целую экосистему, где этому ML жить и процветать.
Внезапно мой рабочий стол выглядит не как блокнот с формулами, а как диаграмма из кучи квадратиков и стрелочек. Я проектирую инфраструктуру:
Где будут жить данные? Data Lakehouse или классический DWH? А может, и то, и другое? Как данные будут поступать туда, очищаться и преобразовываться?
Где будут тренироваться тяжелые модели? Нужно проектировать ML-кластер, считать нагрузку, выбирать инстансы с GPU, предугадывать нагрузку и закладывать возможность масштабирования. Чтобы не получилось, что на обучение модели в проде уходит три недели, потому что мы сэкономили на железе.
Как всё это будет взаимодействовать? Нужно продумать, как фичи будут поступать из хранилища признаков (Feature Store) в модель, как модель будет общаться с бэкендом, куда будут сыпаться логи и как мы будем мониторить всё это хозяйство.
И вот я уже сижу на скамье новых курсов - по System Design и ML System Design, штурмую новые виды конференций и книг в освоении гранита проектирования.
И это уже не про код на Python. Это про выбор технологий, расчеты нагрузок, распределение ресурсов и бесконечные дискуссии с DevOps-ами и инженерами данных (было бы хорошо, если бы они были ещё). Потом ты вместе с командой поднимаешь всю эту конструкцию, по кирпичику, и перекладываешь свое решение на нее, как переезжаешь в новый, только что построенный дом, где ты сама и была архитектором.
И здесь кроется главная тонкость: эта инфраструктура должна быть спроектирована с учетом специфики машинного обучения. Недоточно просто запустить Docker-контейнер. Нужно:
Задуматься о воспроизводимости экспериментов: чтобы любой DS мог получить ту же самую модель с теми же данными и гиперпараметрами.
Организовать версионирование не только кода, но и данных и моделей (спасибо, DVC, MLFlow!).
Настроить мониторинг не только метрик CPU/RAM, но и data drift и concept drift, чтобы вовремя заметить, что мир изменился и модель пора переучивать.
И знаете что? Это — самый кайфовый этап! Да, это сложно. Да, иногда хочется кричать «Я ведь DS, я для красоты мысли сюда пришла!». Но именно здесь рождается не просто модель, а реальный, работающий продукт. Ты видишь, как твое творение живет, дышит и приносит пользу. Ты растешь из маленького data scientist’а в настоящего ML-архитектора, который видит картину целиком: от бизнес-требований до финальной строки лога в продакшене.
И понимаешь, что настоящее машинное обучение — это на 20% придумать гениальный алгоритм, а на 80% — построить систему, которая позволит этому алгоритму выжить в суровом реальном мире.

Настоящий ML-зоопарк: Где же мои единороги?
И вот тут мы подходим к главному. В больших, живых проектах те самые «классификация/регрессия/кластеризация» — это редко конечная цель. Это кирпичики, точнее это лишь малая часть из них. А из этих решений строится целый зоопарк более сложных систем - многоуровневые архитектуры:
Кандидаты (Candidate Generation): Как из миллионов товаров или видео выбрать несколько сотен, которые хоть как-то могут быть интересны пользователю? Никакой одной супермоделью тут не обойтись.
Ранжирование (Learning to Rank): А теперь эти сотни кандидатов нужно выстроить в идеальном порядке. Не просто по вероятности клика, а учитывая долгосрочную engagement-стратегию, диверсификацию и кучу других факторов.
Матчинг (Matching): Как в dating-сервисах или на рынках B2B — связать два объекта наилучшим образом. Это уже не про «предсказать класс», а про «найти пару».
Рекомендации: Целая экосистема из разных моделей, работающих вместе.
И самое главное — единственно правильного ответа здесь нет. Нет той самой статьи на Towards Data Science, которая даст вам готовое решение. Есть только ваш опыт, креативность и постоянные эксперименты.
Так что же, курсы — зло?
Абсолютно нет! Это наша «розовая ваниль» — необходимая база, без которой никуда. Они дают язык, на котором мы говорим, и инструменты, которые мы используем. Порог входа в профессию повышается, а курсы помогают сформировать базу и натаскать мозги на ML специфику.
Так что, дорогие хабравчане, я и правда очень хочу узнать ваше мнение!
Согласны ли вы с этим разрывом между курсами и реальностью? Или вам повезло с проектами?
Какой самый неожиданный и «некнижный» навык оказался critical для вашей работы? Умение выбивать доступ к данным? Или, может, искусство перевода с языка бизнеса на язык математики?
Стоит ли курсам меняться и добавлять «грязные» реальные кейсы, или основа — это святое, а всему остальному научимся только в бою?
Давайте обсудим в комментариях смешные, грустные и поучительные истории из нашей жизни. Обещаю, все прочитаю! И, если вам интересно посмотреть на мир Data Science через призму моего взгляда, буду рада видеть вас в своем телеграм-канале — там я делюсь тем, что обычно остается «за кадром» больших проектов.
kneaded
Вот поэтому я и есть дата инженер - я отвечаю за вопросы "где, как, какие данные вытащить, похожие на production", а так же проектирую где данные будут храниться, по какой логике обновляться, обвешиваю какими-то дополнительными флагами / признаками для облегчения работы аналитиков, data scientist специалистов и прочих. Естественно с мониторингом, devops практиками и прочее
Я решаю всю боль описанную в статье. Хороший специалист я? Ну наверное, но оплачиваются выше DS а не DE
Zotovaa Автор
Дааа, порой создается ощущение, что один специалист отдувается за нескольких. И так и хочется разделить работу на роли DA, DE, DS, MLOps и прочие - но не всегда удается набрать такую команду или получить добро для этого найма. Поэтому приходится закрывать смежные сферы, и часто говорят, что востребованные спецы такими и должны быть.
Data-инженер - очень важный специалист в команде!