Разработка модели машинного обучения на заказ: прогноз, классификация, поиск аномалий

Проверка по времени, а не перемешиванием

Случайное деление записей подмешивает будущее в обучение: модель видит строки, идущие после проверяемых, и оценка выходит лучше, чем будет в работе. Поэтому учим на прошлом, проверяем на более позднем периоде и двигаем границу несколько раз: устойчивый результат повторяется, случайный нет. Горизонт проверки равен горизонту решения: за сколько дней до отказа или просрочки предупреждение ещё что-то меняет. Если времени в данных нет, например тип обращения, часть записей целиком откладываем для проверки. Разбор для склада — в статье «Как прогнозировать спрос на складе».

Утечка данных

Утечка — это когда в признаках оказалось то, что на момент решения ещё не было известно: статус заказа, который проставляют после отгрузки, остаток, пересчитанный задним числом. Модель выучивает подсказку и показывает отличное качество, а в бою подсказки нет. Ищем так: по каждому признаку спрашиваем, когда он становится известен, проверяем по времени и с подозрением относимся к слишком хорошему результату. Вторая форма — соседние по времени записи одного объекта, например кадры подряд, в обучении и в проверке.

Приёмка без одной красивой цифры

Единая цифра ошибки скрывает важное. В протокол приёмки входят:

• сравнение с правилом и статистическим методом на тех же периодах: модель принимается, только если выигрыш повторяется при каждом сдвиге границы;
• качество по сегментам, а не в среднем: крупные клиенты, ходовые позиции или основной режим оборудования скрывают провал на редких случаях;
• для классификации и риска: полнота (доля найденных настоящих случаев) и точность тревог (доля верных тревог) по каждому классу отдельно, иначе при редком классе модель, всегда отвечающая «обычный», выглядит точной;
• для поиска аномалий: число ложных тревог за неделю и доля известных событий из журнала, замеченных заранее;
• виды ошибок и их цена, смещение: пропущенный отказ и ложная тревога стоят по-разному, а модель может систематически завышать или занижать;
• поведение на периодах с акциями, сменой режима или поставщика;
• доля случаев, которые модель не решает сама, и что с ними происходит.

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

• Событий единицы. За всю историю несколько отказов, просрочек или случаев брака: сложную модель не на чем обучить, а проверка состоит из одного-двух случаев. Достаточно порога и ручного разбора.
• Класс определяется одним признаком. Если брак почти всегда совпадает с выходом параметра за допуск, достаточно допуска: модель добавит сопровождение, но не точность.
• Решение нужно объяснить. Отказ клиенту, остановка линии, спорная операция: правило читается мастером и аудитором, а ответ сложной модели нужно объяснять отдельно.
• Причина вне данных. Исход определяют решения, которых в данных нет: поставщика сменили по звонку, режим изменили устно. Модель покажет историю, а не причину.
• Данные записаны не так, как нужно. Причины ремонтов не фиксируются, исход заявки проставляется задним числом, нормальный режим не отмечен. Сначала порядок в данных, потом модель.

• Обучение одной командой. Скрипты, описание среды и версия обучающих данных: обучение можно повторить без нас и получить модель сопоставимого качества.
• Словарь признаков. Для каждого признака записано, откуда он берётся и когда становится известен: по нему ищут утечку при следующей правке.
• Контрольный набор. Отложенный период, не использованный при настройке. Новая версия не выходит в работу, если она хуже действующей на этом наборе и на свежем периоде; набор дополняем свежими данными, прежний сохраняем.
• Порог переобучения. Значение метрики или доли спорных случаев, при котором модель пора обучать заново, записано в акте. Считается на свежих данных, по которым факт уже известен: на неподвижном контрольном наборе качество не меняется.
• Откат и владелец. Предыдущая версия хранится, а сотрудник, получающий сигнал о падении качества, назван по имени.

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