От бизнес-проблемы к ML-постановке

От бизнес-проблемы к ML-постановке

Любой ML-проект начинается не с кода и не с выбора модели — он начинается с вопроса: а что именно мы хотим предсказать и зачем? Без чёткого ответа на этот вопрос даже самая точная модель может не решить реальную проблему бизнеса.

1. Что такое ML-постановка задачи и зачем она нужна

ML-постановка задачи — это формализованное описание бизнес-проблемы в терминах машинного обучения. Грубо говоря, это договор между аналитиком и всеми остальными: командой, бизнесом, данными. Документ фиксирует несколько вещей:

• что модель должна предсказывать (таргет),

• каким типом задачи это является,

• какие данные доступны и в каких условиях,

• по каким критериям будем считать проект успешным. Почему это критично? Потому что ML-проекты чаще всего разваливаются не из-за плохих алгоритмов, а из-за размытого понимания задачи на старте. Команда тренирует модель с максимальной accuracy — а бизнес в итоге не видит роста выручки. Или модель показывает отличные метрики на отложенной выборке, но в продакшене опирается на признаки, которые физически недоступны в момент предсказания. МL-постановка — это именно то, что позволяет выявить такие расхождения до того, как потрачены недели работы. Важно понять: постановка задачи — не бюрократический артефакт. Это рабочий инструмент, который помогает задать правильные вопросы в самом начале. Когда постановка сделана хорошо, все последующие решения — выбор признаков, модели, метрик — становятся логичными и обоснованными. Когда постановки нет или она размыта, проект рискует превратиться в бесконечный цикл переделок.

2. Таргет, тип задачи и ограничения по данным

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

Таргет (целевая переменная) — это то, что модель должна выдавать на выходе. Определить его правильно важнее, чем выбрать алгоритм. Формулировать таргет нужно не абстрактно («предсказать поведение клиента»), а конкретно: какая величина, за какой горизонт, в каких единицах. Хорошие вопросы для фиксации таргета:

• Что именно мы хотим знать о каждом объекте?

• Это конкретное число или принадлежность к группе?

• Когда это значение становится известным в реальности? Последний вопрос критичен — о нём подробнее в разделе про ловушки.

Классификация или регрессия: как выбирать

Выбор типа задачи вытекает из природы таргета, а не из предпочтений команды. Если таргет — категория или метка, задача — классификация. Примеры: уйдёт клиент или нет (0/1), к какой группе риска относится заявка, какой товар выберет пользователь из каталога. Если таргет — числовое непрерывное значение, задача — регрессия. Примеры: цена аренды квартиры в рублях, ожидаемый объём продаж магазина за неделю, время до отказа оборудования в часах. Граница иногда размытая. Представьте задачу «оценить вероятность покупки». Вероятность — число от 0 до 1, но саму задачу при этом решают классификатором, который выдаёт это число как вероятность класса. Поэтому смотреть нужно не только на тип переменной, но и на то, как результат будет использоваться: нужен порог для принятия решения — классификация, нужно само число — регрессия или ранжирование. Ограничения по данным: что стоит зафиксировать сразу

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

• Объём разметки. Если размеченных примеров тысяча, а не миллион, это меняет выбор модели и стратегию валидации.

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

• Доступность признаков в продакшене. Признак может быть в обучающей выборке, но не поступать в систему в момент инференса — тогда он нерабочий.

• Правовые ограничения. GDPR, требования к обезличиванию, ограничения на использование биометрии или геолокации — всё это фиксируется здесь. Практика: пройдитесь по каждому потенциальному источнику данных и задайте вопрос «а будет ли это доступно в момент, когда модель делает предсказание?». Если ответ «нет» — признак выбывает ещё до начала моделирования.

3. Критерии успеха: бизнес-метрика и ML-метрика

Когда таргет определён и тип задачи выбран, встаёт следующий вопрос: по чему мы поймём, что модель работает достаточно хорошо? Ответ здесь всегда двухуровневый. Первый уровень — бизнес-метрика. Это то, ради чего вообще запускается проект. Примеры: снизить отток клиентов на 15%, увеличить конверсию в покупку, сократить операционные расходы на ручную обработку заявок. Бизнес-метрика измеряется не на модели, а на результатах её применения в реальной системе. Второй уровень — ML-метрика. Это то, что можно посчитать на данных до выхода в продакшен: Recall, Precision, AUC, RMSE, MAPE и так далее. ML-метрика — это прокси бизнес-метрики: мы оптимизируем её, веря, что она коррелирует с реальным результатом. Проблема возникает именно здесь. ML-метрика и бизнес-метрика — разные вещи, и между ними не всегда прямая связь. Классический пример рассогласования: команда оптимизирует accuracy на несбалансированной выборке оттока (95% клиентов не уходят, 5% уходят). Модель, которая всегда предсказывает «не уйдёт», даёт 95% accuracy — отличный результат по ML-метрике. Но ни одного уходящего клиента она не поймает, и бизнес-цель — удержание — не достигается вообще. Чтобы этого избежать, нужно при составлении постановки явно зафиксировать обе метрики и связь между ними. Формулировка может быть такой: «ML-метрика — Recall по классу 1 ≥ 0.75 при Precision ≥ 0.6, что позволяет охватить достаточно уходящих клиентов для кампании удержания и не перегружать колл-центр ложными тревогами». Здесь видно, как ML-решение переводится в бизнес-эффект. Ещё одна частая ситуация: бизнес формулирует требование в виде бизнес-метрики («увеличить выручку»), а аналитик берёт удобную ML-метрику, не проверяя связь. В итоге модель улучшается по RMSE, но решение, которое из неё строится, не меняет поведение пользователей — и выручка стоит на месте. Практическое правило: прежде чем выбирать ML-метрику, задайте вопрос «как предсказание модели будет использоваться в системе и какое действие из него следует?». Ответ на этот вопрос почти всегда подсказывает правильную метрику. Для задачи с порогом принятия решения (позвонить или нет, выдать кредит или нет) важны Precision и Recall. Для задачи ранжирования — NDCG или MAP. Для прогноза числового значения с допустимым процентным отклонением — MAPE.

4. Алгоритм перевода бизнес-проблемы в ML-постановку: разбор кейсов и ловушки

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

1. Сформулировать бизнес-цель — одним предложением, без жаргона ML.

2. Определить таргет — что именно предсказываем, за какой горизонт, в каких единицах.

3. Выбрать тип задачи — классификация или регрессия, исходя из природы таргета и того, как результат будет использоваться.

4. Перечислить доступные данные и проверить каждый источник на доступность в момент инференса.

5. Зафиксировать бизнес-метрику и ML-метрику, явно объяснить связь между ними.

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

Кейс 1: предсказание оттока клиентов телеком-компании

Бизнес-цель: снизить отток — удерживать клиентов до того, как они уйдут к конкуренту. Таргет: уйдёт ли клиент в течение ближайших 30 дней — бинарная метка (0 / 1). Тип задачи: бинарная классификация. Данные: история звонков, платёжная история, обращения в поддержку. Ограничение: данные с задержкой 7 дней — самые свежие 7 дней недоступны в момент обучения и предсказания. Метрики: бизнес-метрика — процент удержанных клиентов; ML-метрика — Recall по классу 1 ≥ 0.75 при Precision ≥ 0.6. Recall важен, потому что пропустить уходящего клиента дороже, чем лишний раз позвонить; порог Precision не даёт перегружать колл-центр ложными срабатываниями.

Кейс 2: прогноз стоимости аренды квартиры

Бизнес-цель: автоматически оценивать объявления об аренде, чтобы помочь арендодателям назначить рыночную цену. Таргет: цена аренды в рублях в месяц — числовое непрерывное значение. Тип задачи: регрессия. Данные: площадь, район, этаж, год постройки дома. Ограничение: обучающая выборка содержит только московские объявления — модель не обобщается на другие города. Метрики: бизнес-метрика — доля объявлений, у которых предложенная моделью цена отклоняется от рыночной менее чем на 10%; ML-метрика — MAPE ≤ 8%. Связь прямая: MAPE 8% примерно соответствует нужной доле объявлений с приемлемым отклонением. ---

Эти два кейса хорошо контрастируют: в первом важно не пропустить событие (акцент на Recall), во втором важна точность числового прогноза (акцент на MAPE). Одна и та же процедура постановки — разные выводы из неё. ---

Ловушка 1: таргет, недоступный в момент инференса (data leakage)

Самая дорогостоящая ошибка в постановке задачи — включить в признаки данные, которые появляются только после наступления события, которое мы предсказываем. Модель обучается «подглядывая в будущее» и показывает нереалистично высокое качество на исторических данных, но в продакшене немедленно деградирует. Пример: в задаче предсказания оттока в признаки попадает «количество жалоб за последние 3 дня». Если жалоба была подана уже в день ухода клиента, этот признак недоступен за 7 дней до события — именно столько нужно, чтобы успеть среагировать. В обучающей выборке он есть, в реальной системе его нет. Как проверять: для каждого признака задайте вопрос «в какой момент времени это значение становится известным?». Если ответ — «после наступления таргетного события» или «позже, чем нужен прогноз», признак нельзя использовать.

Ловушка 2: неточная формулировка таргета ведёт к неверному типу задачи

Иногда задача сформулирована достаточно расплывчато, чтобы её можно было решать двумя разными способами — и команда выбирает удобный, а не правильный. Типичная ситуация: бизнес говорит «предскажи сумму покупки». Аналитик думает: «Разобью на бакеты — до 1000, 1000–5000, больше 5000 — и сделаю классификацию, так проще». Но бизнесу нужно точное число для расчёта персонального предложения. Классификация по бакетам здесь теряет информацию и не решает реальную задачу. Как избежать: перед фиксацией таргета уточните у стейкхолдера, как именно предсказание будет использоваться в системе. Вопрос «что вы будете делать с этим числом?» часто сразу снимает неопределённость. Если нужно принять бинарное решение — рассматривайте классификацию. Если нужно само число для расчёта — регрессия.