Почему проваливаются Data Science-проекты: данные, сигнал, бизнес и production-реальность

А потом ничего не происходит. Модель не встраивают в продукт. Отчёт один раз показывают на встрече и забывают. Репозиторий лежит в GitHub, но никто не открывает его второй раз. Технически работа могла быть нормальной, но проект всё равно не дошёл до результата.

По опыту, почему ML-проекты проваливаются — вопрос редко про «плохой алгоритм». Чаще ломается то, что вокруг модели: нет нужных данных, слабый сигнал, мутная бизнес-задача, неверная метрика, data leakage, отсутствие baseline, непонятный путь в production и ноль ответственности после запуска. То есть не один большой провал, а цепочка небольших недосмотров.

В учебном проекте можно остановиться на фразе «модель обучилась». В production Data Science этого мало. Модель должна попасть в процесс, пережить новые данные, быть понятной тем, кто ею пользуется, и не развалиться через месяц.

Учебный проект и production-проект

Учебный проект обычно идёт по знакомой дороге: загрузили CSV, почистили данные, обучили модель, посчитали метрику, написали вывод. Для обучения это честный формат. Он помогает набить руку и увидеть механику машинного обучения.

В рабочем проекте быстро появляется второй слой. Кто будет пользоваться прогнозом? В какой момент? Что произойдёт, если модель ошибётся? Где лежат данные? Кто отвечает за обновление? Эти вопросы выглядят скучнее, чем подбор гиперпараметров, но именно они часто решают судьбу проекта.

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

Причина 1. Нет нужных данных

Один из самых неприятных сценариев начинается с фразы: «Данные у нас есть». Обычно после неё стоит сделать паузу и уточнить: какие именно данные, за какой период, где они лежат, кто даст доступ и можно ли получить их в тот момент, когда модель должна будет работать.

Потому что «данные есть» на практике может означать всё что угодно. Таблицы лежат в разных системах. Половина полей не заполнялась до прошлого квартала. История обрезана. Идентификаторы клиентов не стыкуются. Нужный признак появился только месяц назад. Доступ к CRM нужно согласовывать две недели.

Например, бизнес хочет предсказывать отток клиентов. На словах задача звучит понятно. Но для модели нужны история покупок, обращения в поддержку, тарифы, скидки, активность, даты, события продукта и факт ухода. Если половина этих данных не сохранялась или сохранялась в неудобном виде, проект начинает тонуть ещё до выбора алгоритма.

Отдельная боль — признаки, которые доступны задним числом, но недоступны в момент прогноза. В отчёте они есть. В ноутбуке они прекрасно улучшают качество. А в production API их нельзя получить быстро и стабильно. Такая модель хорошо выглядит на демо, но бесполезна в рабочем контуре.

Поэтому на старте я бы спрашивал не только «есть ли данные». Более честный вопрос звучит жёстче: можно ли использовать эти данные именно так, как потребует будущая система?

Причина 2. Данные есть, но в них нет полезного сигнала

Бывает и обратная ситуация: данных много. Таблицы тяжёлые, признаков десятки или сотни, всё выглядит «богато». Но модель не даёт качества. И это не всегда ошибка Data Scientist.

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

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

Сигнал — это связь между признаками и целевой переменной. Если её нет, XGBoost, нейросеть и три вечера hyperparameter tuning не превратят шум в рабочий инструмент. Можно получить красивую таблицу экспериментов, но не модель, которой стоит доверять.

Как заранее проверить сигнал

• Построить простую модель и сравнить её с наивным ориентиром.
• Проверить качество на отложенной выборке, а не только на train.
• Посмотреть стабильность признаков во времени.
• Обсудить с бизнесом, какие факторы действительно должны влиять на результат.

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

Причина 3. Задача плохо сформулирована бизнесом

Data Science часто начинается с расплывчатого запроса: «сделайте нам модель», «найдите инсайты», «предскажите клиентов», «улучшите продажи». Звучит активно, но для проекта этого мало. Непонятно главное: какое решение должно измениться после прогноза.

Мне больше нравится вопрос не «можем ли мы построить модель оттока?», а «что мы сделаем, если модель скажет, что клиент, скорее всего, уйдёт?». Позвонит оператор? Дадим скидку? Отправим письмо? Исключим из рекламной кампании? Передадим менеджеру?

Если действия нет, модель становится украшением отчёта. Иногда красивым, иногда технически сложным, но всё равно украшением.

Хорошая постановка задачи должна отвечать на четыре вопроса:

• Какое бизнес-решение мы хотим улучшить?
• Кто будет использовать результат модели?
• Что изменится в процессе после прогноза?
• Как мы поймём, что проект окупился?

Если после прогноза никто ничего не делает, проект лучше честно назвать исследованием. Это не плохо само по себе. Плохо, когда исследование продают внутри компании как внедрённое ML-решение.

Причина 4. Модель оптимизирует не ту метрику

ML-метрики нужны. Без них модель нельзя сравнивать и улучшать. Но метрика в ноутбуке не всегда совпадает с тем, что нужно бизнесу.

Можно поднять accuracy и ухудшить пользовательский опыт. Можно снизить RMSE, но не получить денег. Можно увеличить recall, а потом завалить отдел продаж тысячами ложных лидов. Формально модель стала «лучше». В процессе стало хуже.

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

Базовые ML-метрики я отдельно разбирал в статье «Важные метрики в Data Science: что это и зачем?». Для production я бы добавил к ним ещё один вопрос: какое решение будет принято на основе этой метрики?

Причина 5. Data leakage создаёт иллюзию качества

Data leakage — неприятная штука именно потому, что сначала всё выглядит прекрасно. Модель показывает отличное качество, графики радуют, validation почти сияет. А потом выясняется, что в обучении случайно использовалась информация из будущего или признак, которого в рабочем прогнозе не будет.

Простой пример: мы предсказываем, уйдёт ли клиент, и случайно добавляем признак, который появляется уже после ухода. На validation модель сияет. В production она бесполезна, потому что такого признака в момент прогноза ещё нет.

Подробно эту тему я разбирал в статье «Data leakage в Data Science: что это и почему оно ломает модель». Здесь достаточно запомнить практическую вещь: leakage часто делает провальный проект «успешным» ровно до первой встречи с новыми данными.

Если качество выглядит слишком хорошим, особенно на живых бизнес-данных, я бы сначала проверил leakage. И только потом радовался.

Причина 6. Нет baseline, поэтому непонятно, стало ли лучше

Ещё одна частая ошибка — сразу идти в сложную модель. CatBoost, нейросеть, ансамбли, подбор параметров. Всё серьёзно. Но без baseline непонятно, стало ли лучше.

Baseline может быть грубым: среднее значение, самый частый класс, прошлое значение, простое бизнес-правило, линейная модель. Он не обязан быть красивым. Его задача — дать точку отсчёта.

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

Для отдельного разбора есть статья «Baseline модель для Data Science: с чего начать и какую выбрать». В production baseline особенно полезен: бизнесу нужно понимать, почему новая система лучше старого правила, а не просто дороже и сложнее.

Причина 7. Валидация не похожа на будущий запуск

Модель может хорошо пройти случайный train/test split и всё равно провалиться после запуска. Такое часто случается, когда данные зависят от времени, пользователей, регионов, рекламных кампаний или изменений в продукте.

Если мы обучаемся на будущем и тестируемся на прошлом, перемешиваем временные события или случайно допускаем одних и тех же пользователей в train и test, качество будет завышено. На бумаге всё выглядит спокойно. В реальном запуске модель встречает другой мир.

Поэтому мало знать только train/test split. Нужны ещё кросс-валидация, временная валидация и групповые разбиения. Выбор зависит от того, как модель потом будет использоваться.

Хорошая валидация должна отвечать на вопрос: как модель поведёт себя на данных, которых она ещё не видела, в условиях, похожих на будущий запуск?

Причина 8. Модель не дошла до production

Очень знакомый финал: модель обучена, ноутбук готов, презентация прошла, все сказали «классно». А дальше тишина. Нет API, нет интеграции, нет сервера, нет владельца, нет процесса обновления. Проект есть. Продукта нет.

Здесь Data Science упирается в инженерию. Нужно понять, как модель будет принимать запросы, где она будет жить, как получит признаки, кто посмотрит логи, что делать при ошибке, как выкатывать новую версию и как откатываться назад.

Полный путь от ноутбука до сервиса я разбирал в статье «Развёртывание модели машинного обучения в продакшене». Если внедрение не продумано заранее, проект часто заканчивается на самом интересном месте: модель уже есть, а системы вокруг неё нет.

Причина 9. Нет мониторинга, retraining и владельца системы

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

Production-модель требует сопровождения:

• логов запросов и ошибок;
• мониторинга latency и стабильности API;
• отслеживания data drift и model drift;
• периодического retraining;
• версий модели и возможности отката;
• понятного владельца, который отвечает за здоровье системы.

Без владельца модель быстро становится ничьей. А ничьи production-системы стареют тихо: сначала чуть хуже качество, потом странные жалобы от пользователей, потом срочный разбор, почему система месяцами принимала плохие решения.

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

Как заранее снизить риск провала Data Science-проекта

Риск нельзя убрать полностью. Data Science всегда работает с неопределённостью: мы исследуем данные, ищем сигнал, проверяем гипотезы и часто узнаём неприятные вещи уже по дороге. Но риск можно сделать управляемым.

• Начинать с бизнес-решения. Сначала понять, какое действие изменится, потом выбирать модель.
• Провести data audit. Проверить наличие, качество, доступность и актуальность данных до моделирования.
• Построить baseline. Простая точка отсчёта часто экономит недели лишней работы.
• Проверить leakage. Особенно если качество выглядит подозрительно хорошо.
• Выбрать метрику вместе с бизнесом. Не каждая ML-метрика полезна для реального решения.
• Подумать о deployment заранее. Если модель нужна в продукте, путь до API, batch-процесса или другого production-контура должен быть виден с начала.
• Работать маленькими итерациями. Лучше быстро проверить простую честную версию, чем три месяца строить сложную конструкцию без обратной связи.

Чек-лист перед стартом DS-проекта

Перед тем как уходить в моделирование, я бы прошёлся по такому списку. Он не спасёт от всех ошибок, но хорошо отрезвляет на старте.

• Понятно, какое бизнес-решение должен улучшить проект.
• Есть владелец задачи со стороны бизнеса.
• Известно, кто будет использовать результат модели.
• Есть данные, нужные для обучения.
• Понятно, какие данные будут доступны в момент рабочего прогноза.
• Проверены пропуски, задержки, дубли, утечки и странные значения.
• Построен baseline.
• Выбрана метрика, связанная с бизнес-эффектом.
• Валидация похожа на будущую эксплуатацию.
• Есть план внедрения: API, pipeline, сервер или batch-процесс.
• Есть план мониторинга и переобучения.
• Понятно, когда проект будет считаться успешным, а когда его нужно остановить.

Почему это важно для портфолио Data Scientist

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

Сильнее выглядит проект, где видно мышление: какая была задача, какие ограничения у данных, почему выбрана именно эта метрика, что было baseline, где мог появиться leakage, как модель можно было бы внедрить и что нужно мониторить после запуска.

Даже учебный проект можно оформить серьёзно. Не притворяться, что это production, а честно показать следующий инженерный шаг.

Для этого хорошо подходит подход из статьи «Портфолио и пет-проекты Data Scientist для трудоустройства»: проект должен показывать мышление, а не только факт запуска библиотеки.

Вывод

Data Science-проекты редко проваливаются потому, что Random Forest был недостаточно случайным, а градиентный бустинг недостаточно градиентным. Обычно причина прозаичнее: модель оторвали от данных, бизнеса, пользователей и инженерной среды.

Я бы смотрел на DS-проект целиком: вопрос, данные, baseline, валидация, метрики, внедрение, мониторинг и обновление. Именно здесь проходит граница между «я обучил модель» и «я довёл решение до результата».