Кейс про слой, которого не видно в учебниках: между сырым потоком с оборудования и обучающей выборкой стоит валидация, и именно она определяет, будет модель работать или нет.
В нём же — периоды обслуживания и замены датчиков.
Отказы
около 40 случаев за 3 года
Крайне несбалансированная выборка.
Задержка
решение раз в 5 минут
Реального времени не требуется — это батч.
Прежде чем читать разбор, попробуйте спроектировать систему сами — по этим требованиям. Дальше будет видно, что вы учли, а что нет.
Разбор по шагам
1Почему прототип с AUC 0.94 не поймал ни одного отказа
Разбор начинается не с модели, а с того, что попало в выборку.
Утечка через обслуживание: перед каждым отказом оборудование останавливали, и датчики выдавали характерные нули. Модель выучила «нули → отказ» — сигнал, которого в предсказания ещё нет.
Пропуски заполнены средним: у датчика давления среднее по всем режимам — физически невозможное значение, которого не бывает ни при одном режиме работы.
Залипшие датчики отдавали одну и ту же константу неделями; для модели это стабильный нормальный режим.
Разные единицы: часть датчиков после замены отдавала бары вместо килопаскалей — те же числа, другой физический смысл.
На практике
Все четыре причины — не про модель. Ни одна не лечится сменой архитектуры, и все четыре видны в данных, если их проверять.
2Контракт на источник: физика как проверка
У промышленных данных есть то, чего нет у веб-логов, — физические границы.
Проверка
Пример правила
Что делать при нарушении
Физический диапазон
Давление ∈ [0, 25] бар
Отбросить точку, поднять счётчик
Скорость изменения
Температура меняется не быстрее 5 °C/мин
Пометить как , не удалять
Единицы измерения
Датчик объявляет единицы в схеме
Остановить приём с источника
Частота
Не более 2 с между точками
Пометить как неполное
Залипание
Константа дольше 10 минут при работающем насосе
Пометить датчик неисправным
Проверки ставятся на границе приёма, а не перед обучением: чем позже поймана поломка, тем больше витрин и моделей успело её впитать. Инструменты вроде Great Expectations, Soda или dbt tests описывают такие правила декларативно.
На практике
Правило приёмки: должен падать при нарушении контракта, а не тихо писать мусор дальше. Молчаливое «пропустим и почистим потом» и приводит к моделям с 0.94, которые ничего не ловят.
3Типы дефектов и что с каждым делать
«Пропуск» — это пять разных ситуаций, и лечатся они по-разному.
Дефект
Как выглядит
Обработка
Короткий пропуск (< 5 с)
Потеря пакета
Линейная интерполяция плюс флаг
Длинный пропуск (минуты)
Обрыв связи
Не восстанавливать: исключается из выборки
Залипание (stuck-at)
Идеально постоянное значение
Помечать датчик неисправным, не использовать
Одиночный
Скачок на порядок и возврат
Медианный фильтр по короткому окну
Медленный уход среднего
распределения по датчику, перекалибровка
Обслуживание
Нули или шум при остановке
Разметить и исключить: это не рабочий режим
Ключевой приём — маска пропуска как отдельный признак. Сам факт «датчик молчал 40 минут» несёт информацию об оборудовании, и её нельзя терять при восстановлении значений.
На практике
Заполнение средним допустимо для табличных данных, но не для физического процесса: среднее давление по всем режимам не соответствует ни одному реальному режиму работы. Для временных рядов честнее интерполяция на коротких промежутках и исключение — на длинных.
4Признаки: только то, что известно в момент предсказания
Каждый признак проверяется вопросом «а он существовал за 24 часа до отказа?».
Окна назад: агрегаты за 1, 6, 24 часа — медиана, квантили, размах. Медиана и квантили устойчивы к остаточным выбросам, среднее — нет.
Только прошлое: интерполяция сплайном или скользящее среднее с центрированием смотрят в будущее. На обучении это даёт прекрасные метрики, в проде — ничего.
Доля валидных точек в окне как качества измерения.
Отношения между датчиками: ток при данном давлении — физически осмысленная связь, которая ломается раньше, чем любой отдельный показатель.
Валидация — только по времени: обучение на прошлом, проверка на будущем, разрыв между ними не меньше горизонта предсказания. Случайное разбиение здесь даёт утечку автоматически, потому что соседние секунды почти идентичны.
5В проде: те же проверки плюс наблюдение за датчиками
Данные ломаются постоянно, и это нормальный режим работы, а не инцидент.
Те же правила контракта применяются к потоку в проде — иначе модель получит на вход то, чего не видела при обучении.
Мониторинг по датчикам, а не только по модели: доля валидных точек, доля залипаний, распределение значений. Замена датчика видна как резкий сдвиг распределения.
Дрейф: сравнение распределений с обучающим окном; сработавший тест — повод для расследования, а не автоматического .
Идемпотентность: ретраи и дозагрузки не должны порождать дубликаты — иначе агрегаты в окнах поедут.
На практике
Отдельный дашборд «здоровье источника» окупается быстрее модели: большинство инцидентов оказываются поломкой датчика или обновлением прошивки, а не деградацией алгоритма.
Развилки и выбор
На собеседовании ценится не сам выбор, а объяснение, почему отклонены остальные варианты.
Чинить битые значения или выбрасывать окна?
✓Чинить только короткие пропуски, длинные — выбрасывать
Три года истории дают достаточно данных, чтобы позволить себе выбрасывать сомнительные окна. Восстановленные значения на длинных промежутках — это выдумка, на которой модель учится уверенности там, где данных не было.
Что отклонено и почему
Заполнять всё интерполяцией — Модель получает гладкие правдоподобные ряды и учится на них как на измерениях.
Выбрасывать любое окно с дефектом — При 3 000 датчиков хотя бы один почти всегда неисправен — выборка схлопнется.
Где ставить проверки качества?
✓На границе приёма, до записи в хранилище
Пойманная на входе поломка стоит одного алерта; она же, найденная через месяц в витрине, стоит переобучения всех моделей, которые её впитали.
Что отклонено и почему
Перед обучением — К этому моменту мусор уже разошёлся по витринам и дашбордам.
В коде модели — Проверки дублируются в каждом проекте и расходятся между собой.
Как валидировать модель при 40 отказах за 3 года?
✓Разбиение по времени плюс оценка по стоимости, а не по AUC
При такой редкости события AUC почти не отличает хорошую модель от бесполезной. Считается ожидаемая экономия: пойманные отказы против стоимости ложных остановов.
Оценка по accuracy — Предсказание «отказа не будет» даёт точность около 99.99 % и нулевую пользу.
Что ломается в проде
Утечка через режим обслуживания
Состояния оборудования, сопровождающие остановку, коррелируют с отказом идеально — и недоступны за 24 часа до него. Периоды обслуживания нужно размечать явно и исключать.
Замена датчика меняет распределение
Новый датчик может отдавать другие единицы, другую точность или другое смещение. Без журнала замен это выглядит как дрейф процесса и приводит к переобучению на артефакте.
Дубликаты после ретраев
Повторная загрузка без ключа идемпотентности удваивает точки в окне: агрегаты уезжают, а в логе всё выглядит успешно.
Время не там, где кажется
Локальное время, переход на летнее время и часы датчика, ушедшие на минуты, ломают выравнивание рядов между источниками. Хранить и считать надо в UTC, а расхождение часов — мониторить.
Метрика считается на очищенных данных
Если валидационная выборка прошла ту же ручную чистку, что и обучающая, метрика описывает лабораторию, а не прод. В валидации должны остаться те дефекты, которые будут в реальном потоке.
По чему видно, что система здорова
Метрика
Значение
Зачем
Доля валидных точек
по каждому датчику
Основной индикатор здоровья источника.
Нарушения контракта
число за сутки по правилам
Рост — поломка источника, а не модели.
Пойманные отказы
recall при фиксированной частоте тревог
Считается на разбиении по времени.
Стоимость ошибок
экономия от ремонта минус потери от ложных остановов
Метрика, по которой принимается решение о внедрении.
Дрейф признаков
PSI или KS относительно обучающего окна
Сигнал к расследованию.
Что спрашивают по этому кейсу
Модель показала AUC 0.94 и не поймала ни одного отказа. Ваши гипотезы по порядку проверки.
Датчик отдаёт одно и то же значение три дня. Как это поймать автоматически и что дальше?
Чем заполнять пропуски в показаниях давления и почему не средним?
Как построить валидацию при 40 положительных примерах за три года?
Где в этом пайплайне поставить проверки качества и почему именно там?