Как понять, что задачу вообще стоит решать с помощью ML 🧠
Когда в компании появляется идея использовать машинное обучение, очень легко сразу перейти к обсуждению моделей. Какой алгоритм взять, какие признаки добавить, какую метрику оптимизировать, где хранить эмбеддинги, нужен ли CatBoost, нейросеть или LLM. Но сильная ML-задача начинается не с модели. Она начинается с проверки, есть ли здесь вообще повторяемая проблема, данные, бизнес-действие и понятный способ измерить результат.
Представьте запрос: «Давайте предсказывать, какие клиенты скоро уйдут». На первый взгляд звучит как нормальная ML-задача. Но перед разработкой модели нужно задать несколько вопросов, иначе команда рискует сделать технически аккуратное решение, которое не изменит бизнес-процесс.
📌 Есть ли повторяемое решение? Если каждый случай уникален и требует ручного экспертного разбора, модель может оказаться слабым инструментом. ML особенно полезен там, где есть много похожих объектов, повторяющиеся решения и закономерности, которые можно извлечь из данных.
📌 Есть ли данные о прошлом? Чтобы предсказывать отток, нужно понимать, кто ушёл раньше, какие признаки были известны до ухода, какие действия компания предпринимала и что произошло после. Если данные неполные, размечены задним числом или содержат утечки, модель может показать хорошую метрику в эксперименте, но плохо работать в реальности.
📌 Что изменится после предсказания? Это один из самых важных вопросов. Если модель нашла клиента с высоким риском оттока, что произойдёт дальше: звонок менеджера, скидка, персональное письмо, изменение тарифа, передача в отдельный сегмент. Если на предсказание не завязано действие, оно не создаёт ценности.
📌 Можно ли измерить эффект? Недостаточно сказать, что модель должна быть точной. Нужно заранее понять, какая бизнес-метрика должна измениться: отток, выручка, конверсия, время обработки, количество ручных проверок, стоимость ошибки. Иначе команда будет спорить о ROC-AUC, хотя бизнесу важно совсем другое.
📌 Сколько стоят ошибки? В одних задачах страшнее пропустить проблемный объект, в других страшнее ошибочно пометить нормальный объект как проблемный. Например, в антифроде пропущенная мошенническая операция может стоить денег, а ложная блокировка может испортить клиентский опыт. Поэтому выбор метрики и порога должен зависеть не только от математики, но и от экономики процесса.
Хороший признак, что ML здесь действительно уместен: у команды есть повторяемая задача, достаточно данных, понятное действие после предсказания, измеримая бизнес-метрика и понимание стоимости ошибок. Если хотя бы одного элемента нет, это не значит, что модель точно не нужна. Но это значит, что сначала нужно доработать постановку задачи.
Главный вывод простой: ML не должен быть способом сделать задачу более модной. Он должен быть способом улучшить конкретное решение внутри конкретного процесса. Поэтому перед вопросом «какую модель обучать» почти всегда должен идти другой вопрос: «что изменится в бизнесе, если модель окажется права».
Когда в компании появляется идея использовать машинное обучение, очень легко сразу перейти к обсуждению моделей. Какой алгоритм взять, какие признаки добавить, какую метрику оптимизировать, где хранить эмбеддинги, нужен ли CatBoost, нейросеть или LLM. Но сильная ML-задача начинается не с модели. Она начинается с проверки, есть ли здесь вообще повторяемая проблема, данные, бизнес-действие и понятный способ измерить результат.
Представьте запрос: «Давайте предсказывать, какие клиенты скоро уйдут». На первый взгляд звучит как нормальная ML-задача. Но перед разработкой модели нужно задать несколько вопросов, иначе команда рискует сделать технически аккуратное решение, которое не изменит бизнес-процесс.
📌 Есть ли повторяемое решение? Если каждый случай уникален и требует ручного экспертного разбора, модель может оказаться слабым инструментом. ML особенно полезен там, где есть много похожих объектов, повторяющиеся решения и закономерности, которые можно извлечь из данных.
📌 Есть ли данные о прошлом? Чтобы предсказывать отток, нужно понимать, кто ушёл раньше, какие признаки были известны до ухода, какие действия компания предпринимала и что произошло после. Если данные неполные, размечены задним числом или содержат утечки, модель может показать хорошую метрику в эксперименте, но плохо работать в реальности.
📌 Что изменится после предсказания? Это один из самых важных вопросов. Если модель нашла клиента с высоким риском оттока, что произойдёт дальше: звонок менеджера, скидка, персональное письмо, изменение тарифа, передача в отдельный сегмент. Если на предсказание не завязано действие, оно не создаёт ценности.
📌 Можно ли измерить эффект? Недостаточно сказать, что модель должна быть точной. Нужно заранее понять, какая бизнес-метрика должна измениться: отток, выручка, конверсия, время обработки, количество ручных проверок, стоимость ошибки. Иначе команда будет спорить о ROC-AUC, хотя бизнесу важно совсем другое.
📌 Сколько стоят ошибки? В одних задачах страшнее пропустить проблемный объект, в других страшнее ошибочно пометить нормальный объект как проблемный. Например, в антифроде пропущенная мошенническая операция может стоить денег, а ложная блокировка может испортить клиентский опыт. Поэтому выбор метрики и порога должен зависеть не только от математики, но и от экономики процесса.
Хороший признак, что ML здесь действительно уместен: у команды есть повторяемая задача, достаточно данных, понятное действие после предсказания, измеримая бизнес-метрика и понимание стоимости ошибок. Если хотя бы одного элемента нет, это не значит, что модель точно не нужна. Но это значит, что сначала нужно доработать постановку задачи.
Главный вывод простой: ML не должен быть способом сделать задачу более модной. Он должен быть способом улучшить конкретное решение внутри конкретного процесса. Поэтому перед вопросом «какую модель обучать» почти всегда должен идти другой вопрос: «что изменится в бизнесе, если модель окажется права».