Ошибиться с предиктивной аналитикой чаще всего можно в трёх местах: в данных, в проверке и в использовании. В данных модели подсказывает будущее, которого в момент решения ещё нет. В проверке записи перемешивают, и модель показывает отличный результат на прошлом, но не работает на новом. В использовании прогноз не связан с решением, которое он должен менять, и остаётся красивой цифрой в отчёте.
Защита одна: до обучения записать, какое решение прогноз меняет и когда оно принимается, проверять модель по времени на периоде, которого она не видела, и сравнивать с простым правилом. Как мы строим такие модели, описано на странице «Предиктивная аналитика», а здесь разбираем сами ошибки.
Четыре ошибки, из-за которых прогноз не работает
Почти все неудачные проекты предиктивной аналитики сводятся к одному из четырёх сценариев. Они не зависят от выбранного алгоритма и повторяются в самых разных задачах, от закупок до оттока клиентов. Ниже они собраны в виде таблицы, по которой удобно проверить собственный проект.
| Ошибка | Как выглядит | Чем кончается | Как поймать |
|---|---|---|---|
| Утечка из будущего | В данных есть признак, который становится известен уже после события | На проверке модель почти идеальна, в работе бесполезна | Для каждого признака ответить: известен ли он в момент, когда принимается решение |
| Проверка перемешиванием | Записи делятся на обучающие и проверочные случайно | Модель видит будущее при обучении, оценка завышена | Делить по времени: обучение на раннем периоде, проверка на более позднем |
| Нет простого соперника | Результат модели не сравнивается с правилом или прошлым значением | Непонятно, нужна ли модель вообще | Сначала посчитать базовую линию: «как в прошлый раз», среднее по группе, текущее правило |
| Прогноз без решения | Модель считает, но никто не знает, что с цифрой делать | Отчёт читают, поведение не меняется, польза равна нулю | Записать решение, срок, исполнителя и цену ошибки до обучения |
Что именно предсказываем: цель, горизонт и момент решения
Постановка задачи в предиктивной аналитике состоит из трёх вещей, и ошибка в любой превращает хорошую модель в бесполезную.
- Цель. Одно событие или величина с точным определением. «Клиент уйдёт» ничего не значит, пока не записано, что считается уходом: отсутствие заказа за какой срок, закрытие договора, отказ от продления.
- Горизонт. На какой срок вперёд смотрим. Прогноз поломки станка за день до неё бесполезен, если ремонт готовится неделю.
- Момент решения. В какой день и час человек или система получит прогноз и что в этот момент уже известно. Именно он определяет, какие данные можно использовать.
Пример для закупок: цель — спрос на позицию в ближайший цикл поставки, горизонт равен сроку поставки плюс интервал между заказами, момент решения — день формирования заказа. Все признаки берутся по состоянию на этот день: остатки, цены, акции, известные к нему. Подробный разбор на примере склада лежит на странице «Прогнозирование спроса».
Для оборудования цель и момент другие: вероятность отказа узла за ближайший период по показаниям, снятым до текущего момента. Как это устроено в промышленности, описано на странице прогнозного обслуживания.
Ловушки в данных: что искажает историю
Даже если признаки подобраны честно, сама история может отличаться от того, что будет завтра. Типичные ловушки собраны в таблице.
| Ловушка | Пример | Как проверить |
|---|---|---|
| Данные после события | Поле «причина закрытия заявки» заполняют после решения, а прогноз нужен в момент поступления заявки | Для каждого признака найти время его появления в системе, а не только значение |
| Исправление задним числом | Остатки и цены в учёте поправили через неделю, и модель обучается на исправленном, а в работе получит неисправленное | Брать срез, каким он был на дату решения, или хранить журнал изменений |
| Цензурирование | По недавним клиентам ещё неизвестно, ушли они или нет, и они попадают в «не ушли» | Исключить записи, по которым срок наблюдения не прошёл |
| Спрос равен продажам | При дефиците продажи ниже спроса, и модель учится недопродавать | Отметить периоды без товара, не включать их в обучение как «нулевой спрос» |
| Смещение отбора | Решение принималось только по тем, кого проверяли вручную, и модель видит только их | Сравнить состав обучающих записей с составом тех, на кого прогноз будет применяться |
| Дубликаты и разные определения | Один клиент заведён трижды, «активный клиент» в двух отделах означает разное | Согласовать определения, объединить дубликаты, записать правила в документ |
Большинство этих ловушек не видно в самих числах, поэтому их находят разговором с теми, кто ведёт данные. На обследовании мы просим показать, как заполняется каждое поле и кто его меняет и когда, а не только выгрузить таблицу.
Как проверять: по времени, против простого правила и по группам
Проверка по времени
Единственный честный способ — имитировать работу. Берём прошлый момент, обучаем модель только на том, что было известно до него, строим прогноз на горизонт и сравниваем с тем, что случилось. Затем сдвигаем момент вперёд и повторяем несколько раз: так видно, стабильна ли модель, или ей повезло на одном периоде. Случайное перемешивание записей этого не даёт.
Базовая линия
Каждый результат сравнивается с простым правилом: «как в прошлом периоде», «среднее за последние недели», действующая практика сотрудников. Если модель обыгрывает его незначительно, сложность не оправдана. Если не обыгрывает совсем, остаётся правило, и это нормальный результат проекта.
Не одна цифра
Одна общая метрика скрывает провалы. Смотрим качество отдельно по группам: новые и давние клиенты, крупные и мелкие позиции, разные склады, сезоны. Смотрим не только среднюю ошибку, но и худшие случаи, и смещение: систематически ли модель завышает или занижает. Для вероятностей проверяем калибровку: когда модель говорит «семьдесят процентов», событие должно происходить примерно в семи случаях из десяти. Подробнее о том, что значит уверенность модели, написано в статье «Порог уверенности модели».
Проверка в тихом режиме
Перед тем как прогноз начнёт влиять на решения, его запускают параллельно: он считает, пишется в журнал, люди его не видят. Через один-два цикла сравнивают с фактом. Это дешёвая страховка от расхождения между обучающими и боевыми данными.
Порог и цена ошибки: как выбрать, когда считать «да»
Если прогноз выдаёт вероятность («клиент уйдёт с вероятностью такой-то»), то решение «действовать или нет» принимается порогом. Порог не берут «по умолчанию, где пятьдесят на пятьдесят». Его выбирают по цене двух видов ошибок.
| Вид ошибки | Что случилось | Чем платим | Пример |
|---|---|---|---|
| Ложная тревога | Прогноз сказал «да», события не было | Лишнее действие: звонок, заказ, осмотр, скидка | Лишний выезд на осмотр узла, который был исправен |
| Пропуск | Прогноз сказал «нет», событие произошло | Потеря: простой, отток, дефицит, штраф | Станок встал без предупреждения |
Дальше считается просто. Если пропуск стоит в несколько раз дороже ложной тревоги, порог ставится ниже, и тревог будет больше. Если действие по тревоге дорого (скидка, выезд), порог выше. Важно, что исполнитель способен обработать столько тревог, сколько получит: если менеджер успевает позвонить двадцати клиентам в неделю, прогноз с сотней тревог бесполезен независимо от точности. Поэтому порог связывается с ёмкостью процесса, и вместе с прогнозом показывается очерёдность: сначала самые вероятные и самые дорогие случаи.
Цены ошибок называет бизнес, а не специалист по данным. Если они неизвестны, это само по себе результат обследования: до модели нужно выяснить, сколько стоит каждая ошибка хотя бы по порядку величины.
Когда предиктивная аналитика не нужна
Бывают случаи, когда честный ответ — «модель здесь не нужна». Это не провал, а экономия бюджета.
- Решение не зависит от прогноза. Закупка идёт по минимальной партии поставщика, и любой прогноз приведёт к тому же заказу.
- Мало истории или она не повторяется. Процесс изменился, и прошлое больше не похоже на будущее. Данных за один-два цикла недостаточно для проверки по времени.
- Правило не хуже модели. Простая формула или экспертное правило даёт тот же результат и понятнее сотруднику.
- Нет исполнителя. Тревоги некому обрабатывать, или у процесса нет времени отреагировать.
- Ошибка недопустима. Если одна ошибка влечёт тяжёлые последствия и нет человека для проверки, автоматический прогноз без контроля не подходит.
Мы не обещаем заранее, что модель окажется лучше правила. Выигрыш показывает проверка на ваших данных, и если его нет, мы так и пишем.
Как внедрять, чтобы прогноз работал и после запуска
Хорошая модель в работе устаревает: меняются клиенты, цены, процессы. Чтобы прогноз не превратился в тихо ошибающуюся цифру, вокруг него нужны несколько вещей.
- Журнал прогноз и факт. Каждый прогноз записывается с датой и версией модели, а когда приходит факт, фиксируется расхождение. Без журнала качество нельзя ни проверить, ни показать.
- Владелец. Названный человек отвечает за модель, и другой за решение, которое она меняет. Без владельца сигналы о падении качества никому не адресованы.
- Откат к простому правилу. Если качество упало или входные данные сломаны, система переходит на базовую линию, а не продолжает выдавать цифры.
- Решение остаётся за человеком там, где ошибка дорога. Прогноз предлагает, человек подтверждает, правки пишутся в журнал.
Как следить за моделью в работе и когда переобучать, описано в статье «Что такое MLOps простыми словами» и на странице «MLOps и развёртывание моделей».
Что делаем мы и с чего начать
Начинаем с обследования данных и постановки: 200 000 ₽ и 2–3 недели за один процесс и один источник данных, 350 000 ₽ и 3–4 недели, если данные в нескольких системах. На выходе записанные цель, горизонт и момент решения, список ловушек в ваших данных, базовая линия на истории и вилка бюджета на следующие ступени. Обследование вычитается из первого этапа, если продолжаете с нами. Цены по ступеням — на странице «Тарифы».
Дальше лёгкий пилот на выборке (150 000–400 000 ₽, 2–8 недель) с проверкой по времени и сравнением с правилом, затем при необходимости тяжёлый пилот (400 000–1 200 000 ₽, 2–3 месяца) в рабочем окружении. На любой ступени можно остановиться: исходники лежат в вашем репозитории с первого коммита. Работаем в вашем контуре. Мы не занимаемся банковским скорингом и не обещаем точность заранее: она измеряется на ваших данных. Общий порядок описан на странице «Разработка модели машинного обучения».
Частые вопросы
Что такое утечка данных в предиктивной аналитике?
Это ситуация, когда признак содержит информацию, известную только после события, которое прогнозируется. Модель получает подсказку из будущего, показывает отличное качество на проверке и не работает в реальности. Защита: для каждого признака проверять, известен ли он в момент решения.
Почему нельзя проверять модель на случайной части данных?
При случайном делении обучающие и проверочные записи оказываются из одного и того же времени, и модель опирается на закономерности, которые в будущем могут исчезнуть. Честная проверка идёт по времени: обучение на раннем периоде, оценка на позднем.
Как понять, что модель лучше простого правила?
Посчитать оба варианта на одном и том же проверочном периоде и сравнить по метрикам, важным для решения, а также по группам и худшим случаям. Если разница мала или нестабильна, остаётся правило. Это нормальный результат проекта.
Как выбрать порог для прогноза-вероятности?
По цене двух видов ошибок и по ёмкости процесса: сколько тревог исполнитель способен обработать. Цены называет бизнес. Порог выбирается на проверочной выборке и пересматривается, когда меняются цены ошибок или нагрузка на исполнителя.
Сколько истории нужно для предиктивной аналитики?
Жёсткого числа нет. Нужно достаточно циклов процесса, чтобы проверить модель по времени несколько раз, и достаточно событий, которые прогнозируются. Для редких событий и сезонных процессов требования выше. Точный ответ даёт обследование данных.
Нужно ли переобучать модель и как часто?
Да, данные и процессы меняются. Частота определяется скоростью изменений и показаниями мониторинга, а не календарём. Каждая новая версия сравнивается с текущей, а к прежней можно вернуться по записанной процедуре.
Что делать, если данных мало или они плохие?
Начать с правила и сбора данных: определить, что и как нужно записывать, чтобы через несколько циклов проверить модель. Иногда главный результат обследования — список того, что исправить в учёте, и отказ от модели сейчас.
Сколько стоит проект по предиктивной аналитике?
Обследование — 200 000 ₽ за один процесс и 350 000 ₽ за несколько систем, оно вычитается из первого этапа. Лёгкий пилот — 150 000–400 000 ₽ за 2–8 недель, тяжёлый — 400 000–1 200 000 ₽ за 2–3 месяца. Вывод в эксплуатацию — от 1 500 000 ₽ этапами по 300 000–700 000 ₽, сопровождение — от 20 000 ₽ в месяц.