КабинетПоиск
Практика ML

Debugging models

Отладка моделей

актуальноТекущий рабочий стандарт

Направления: Инженерия ИИ · Системный дизайн ML

Систематический поиск причины, почему модель не учится или ведёт себя странно.

Ключевые тезисы

  • Первый тест: переобучите модель на 10 объектах до нулевой ошибки.
  • Проверьте порядок меток, и распределение .
  • Слишком хороший результат — повод искать утечку, а не радоваться.

Какую задачу решает

«Модель не работает» — не диагноз. Причина может быть в данных, в , в целевой переменной, в схеме валидации, в коде обучения или в самой постановке, и каждая требует своих действий. Отладка ML отличается от отладки обычного кода тем, что здесь нет исключения и стека вызовов: модель молча выдаёт плохие числа.

Работающий подход — двигаться от самого дешёвого и самого вероятного к сложному, каждый раз проверяя гипотезу измерением. Сначала воспроизводимость и корректность данных, потом способность модели переобучиться на крошечной выборке (если не может — баг в коде), потом схема валидации, и только потом и архитектура.

Первая проверка при «модель не учится»

Возьмите 10 примеров, выключите всю и и обучайте на них 500 шагов. Здоровая модель должна выйти на почти нулевую ошибку — просто запомнить их. Если не может, проблема не в данных и не в : где-то баг. Типичные находки — метки перепутаны с признаками, на два порядка не та, не доходят из-за неправильной маски, считается не от того выхода. Проверка занимает минуту и отсекает половину возможных причин.

Подробный разбор

2 подтемы — объяснения, формулы, примеры и интерактивные графики.

  1. Переобучите модель на 10 объектах. Если она не может выучить их наизусть — баг в коде, а не в данных.
  2. Проверьте порядок и соответствие X и y после всех перестановок и мержей.
  3. Посмотрите на распределения в train и test: они должны совпадать.
  4. Проверьте масштабирование: расходящийся почти всегда означает его отсутствие.
  5. Посмотрите на : нули означают затухание, NaN — взрыв или деление на ноль.
  6. Сравните с константным : модель обязана быть лучше.
На практике

Если метрика подозрительно высока — это не удача. Ищите утечку: из будущего, дубликаты между частями выборки, без out-of-fold.

import os, random, numpy as np, torch
def seed_all(seed=42):
    random.seed(seed); np.random.seed(seed)
    torch.manual_seed(seed); torch.cuda.manual_seed_all(seed)
    os.environ["PYTHONHASHSEED"] = str(seed)
    torch.backends.cudnn.deterministic = True
На практике

Полная детерминированность на иногда невозможна (атомарные операции, разный порядок сложения). Тогда фиксируйте seed и оценивайте разброс по нескольким запускам — это честнее, чем делать вид, что результат точный.

Где применяется

  • Модель не обучается не падает или падает и взрывается.
  • Разрыв офлайн и продаНа валидации хорошо, в эксплуатации плохо.
  • Внезапная деградацияРаботавшая модель начала ошибаться — ищем изменение во входных данных.
  • Неправдоподобно хороший результатПроверка на утечку до, а не после внедрения.

Плюсы, минусы и альтернативы

Плюсы

  • Систематический порядок экономит дни бессистемных попыток.
  • Большинство проблем оказываются в данных и находятся дёшево.
  • Проверки простые и не требуют инструментов.

Минусы

  • Требует дисциплины и терпения.
  • Некоторые проблемы (сдвиг данных) проявляются только со временем.
  • Без воспроизводимости отладка превращается в угадывание.

Брать, если

  • Результат не соответствует ожиданиям — в любую сторону.
  • Перед выводом модели в прод.

Не брать, если

  • Разница в пределах шума между сидами — отлаживать нечего, это не баг.

Чем заменяют

Error analysisактуальноАнализ ошибок · Оценка моделейМодель обучается, но ошибается — нужен разбор ошибок, а не поиск бага.Data leakageактуальноУтечка данных · ДанныеМетрика подозрительно хороша.MonitoringактуальноМониторинг · MLOpsПроблема появилась в проде: нужен , а не отладка кода.

Видеолекции

Тайм-кода именно на эту тему в записях нет. Но глава «Практика ML» разобрана в курсах целиком — с той оговоркой, что место в записи придётся искать самому.

Курс: Системный дизайн ML7 записейКурс: Введение в MLOps5 записей

Связанные темы

Рабочий цикл ML-инженера

Problem formulation70%

Постановка задачи · Практика ML

Перевод бизнес-вопроса в ML-задачу с целевой переменной, метрикой и ограничениями.

Baselines70%

Бейзлайны · Практика ML

Простейшее решение, с которым сравнивается всё остальное: константа, правило, логистическая регрессия.

Hyperparameter tuning70%

Настройка гиперпараметров · Практика ML

Поиск конфигурации модели по валидационной метрике — последний, а не первый шаг работы.

Overfitting70%

Переобучение · Практика ML

Модель запомнила обучающую выборку вместе с шумом: train-метрика отличная, val — плохая.

Error analysis70%

Анализ ошибок · Оценка моделей

Ручной разбор случаев, где модель ошибается: почти всегда даёт больше, чем очередной перебор гиперпараметров.

Production ML70%

ML в продакшене · Практика ML

Модель в проде — это сервис с SLA, мониторингом, версионированием и планом отката.

Кому эта тема нужна

Профильная компетенция для ролей: Data Scientist, Аналитик данных, Продуктовый инженер.

Усиливает профиль: ML Engineer, Исследователь.

Добавить в учебную программу
Следующий шагДальше по связи: Problem formulationПеревод бизнес-вопроса в ML-задачу с целевой переменной, метрикой и ограничениями.Перейти →
← Bayesian OptimizationOverfitting →

Глава «Практика ML» последний раз правилась . Нашли ошибку — напишите.