Москва: проверенные б/у ноутбуки с гарантией и проверкой перед оплатой
+7 906 722-94-45

Главная → Статьи → MLflow: трекинг экспериментов и воспроизводимость

MLflow: как отслеживать эксперименты и повторять обучение

MLflow Tracking: runs, параметры, метрики и артефакты, автосбор метрик, сравнение прогонов и воспроизводимость обучения в команде.

Прямой ответ

MLflow Tracking — журнал экспериментов: каждый прогон обучения фиксируется как run с параметрами, метриками, артефактами и кодом окружения. Он решает практическую проблему «я вчера получил 0.91, но не помню, на каких данных и с какими настройками».

Базовые понятия:

  • Experiment — логическая группа прогонов, обычно одна задача.
  • Run — один запуск обучения с набором параметров и метрик.
  • Parameters — входные настройки: гиперпараметры, версия датасета, признак-инженерия.
  • Metrics — измеримые результаты; могут логироваться пошагово (кривые обучения) или один раз.
  • Artifacts — файлы: модель, графики, конфиги, примеры предсказаний.

Минимальный рабочий пример:

import mlflow, mlflow.sklearn
from sklearn.ensemble import HistGradientBoostingClassifier
from sklearn.model_selection import train_test_split
from sklearn.metrics import roc_auc_score

X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.2, random_state=42)

with mlflow.start_run(run_name="hgb-baseline"):
    params = {"max_depth": 6, "learning_rate": 0.08, "max_iter": 400, "random_state": 42}
    mlflow.log_params(params)
    mlflow.log_param("dataset_version", "v2026-10-15")

    model = HistGradientBoostingClassifier(**params).fit(X_train, y_train)
    auc = roc_auc_score(y_test, model.predict_proba(X_test)[:, 1])
    mlflow.log_metric("roc_auc", auc)

    mlflow.sklearn.log_model(model, artifact_path="model")

Что даёт трекинг на практике:

  1. Сравнимость прогонов. Таблица прогонов с сортировкой по метрике заменяет ручные заметки и скриншоты.
  2. Воспроизводимость. Зафиксированные параметры, версия датасета и окружения позволяют повторить результат спустя месяцы.
  3. Отслеживание деградации. История метрик показывает, что качество начало падать после изменения данных — см. мониторинг моделей и дрейф.
  4. Передача контекста. Новый участник команды видит, что уже пробовали и к какому выводу пришли.

Ограничения: MLflow сам по себе не гарантирует воспроизводимость — он фиксирует то, что вы залогируете. Случайное начальное состояние, неучтённая версия библиотеки или «плавающий» датасет сведут повтор на нет.

Практика: что логировать обязательно

Минимальный набор для каждого run:

  • идентификатор и версия датасета (хеш, дата среза, число строк);
  • полный набор гиперпараметров, включая random_state;
  • метрики на валидации и на тесте отдельно;
  • версия кода (git commit) и окружения;
  • модель как артефакт.
import subprocess
mlflow.log_param("git_commit", subprocess.check_output(["git","rev-parse","--short","HEAD"]).decode().strip())
mlflow.log_metric("train_rows", len(X_train))
mlflow.log_metric("test_rows", len(X_test))

Автосбор метрик. mlflow.autolog() для популярных библиотек пишет параметры, метрики и модель автоматически. Это удобно, но в продакшен-пайплайне лучше явное логирование: автосбор добавляет метрики, которые никто не читает, и маскирует пропущенные важные.

Организация прогонов:

  1. Один эксперимент — одна задача. Не смешивайте разные целевые переменные и разные продукты.
  2. Осмысленные имена прогонов. hgb-depth6-lr008 полезнее, чем run-37.
  3. Теги для статуса. Отмечайте прогоны как baseline, candidate, production — это упрощает выбор при выкатке через model registry.
  4. Не логируйте данные целиком. Артефакты — это модель, конфиг и выборки; полный датасет хранится в хранилище, а в трекинге остаётся его идентификатор.

Локальный и серверный режим. Для разработки достаточно mlflow ui с локальным каталогом. Для команды нужен сервер с общей БД и хранилищем артефактов; развёртывание удобно делать контейнером — см. локальный стек на docker-compose.

Практический сценарий: результат не воспроизводится

Контекст: коллега получил ROC-AUC 0.912 на задаче оттока; при повторе через две недели получается 0.874.

  1. Сверка параметров. В трекинге видно: параметры модели совпадают, но dataset_version не залогиран, а дата среза указана только в имени прогона.
  2. Проверка данных. Оказывается, витрина признаков пересчитывается ежедневно, и за две недели состав выборки изменился: добавились новые клиенты, часть признаков перестала заполняться.
  3. Исправление. Фиксируем датасет как неизменяемый срез с версией; логируем хеш среза и число строк; добавляем проверку схемы признаков перед обучением.
  4. Повтор. На зафиксированном срезе результат воспроизводится с точностью до четвёртого знака; расхождение исчезло.
  5. Профилактика. В пайплайн обучения добавлен шаг фиксации среза и сравнения схемы с эталоном; подбор гиперпараметров выполняется только на зафиксированных данных — см. кросс-валидацию.

Вывод: трекинг полезен настолько, насколько полны зафиксированные данные. Версия датасета — обязательный параметр прогона, иначе сравнение прогонов теряет смысл.

Как организовать эксперименты в команде. Полезны три соглашения. Первое — общий префикс имени прогона, отражающий этап: base-, feat-, tune-, final-. По префиксу видно, что именно менялось, и сравнение прогонов не превращается в угадывание. Второе — обязательный тег результата: baseline, candidate, rejected с причиной. Отклонённые гипотезы ценны не меньше успешных, потому что спасают команду от повторения тех же попыток. Третье — запись вывода в описание прогона одной фразой: что проверяли и к чему пришли. Через полгода эта фраза экономит часы.

Что делать с неудачными прогонами. Не удаляйте их. Прогон с ошибкой в данных или с расчётом метрики на обучающей выборке — это документированная ловушка. Гораздо полезнее пометить такой прогон тегом invalid и указать причину, чем потерять след и повторить ту же ошибку.

FAQ

Нужен ли MLflow для одного человека и пары моделей? Для пары экспериментов достаточно таблицы с параметрами. Трекинг окупается, когда прогонов десятки и нужно сравнивать их системно, либо когда модель уходит в продакшен и требуется история изменений.

Чем трекинг отличается от model registry? Трекинг фиксирует эксперименты, реестр управляет жизненным циклом конкретной модели: стадии, версии, переходы в продакшен. Обычно модель из удачного прогона регистрируется и далее живёт в реестре.

Как хранить большие артефакты? Артефакты кладут в объектное хранилище, а в трекинге остаётся ссылка. Локальный каталог подходит для разработки, но не для команды: он не переживает переезд и не даёт контроля доступа.

Можно ли логировать кривые обучения? Да, метрики можно писать по шагам, и UI покажет кривые. Это полезно для диагностики переобучения и выбора момента остановки, но увеличивает объём записей; для финальных прогонов достаточно итоговых значений.

Источники: MLflow docs (tracking), MLflow Python API, scikit-learn model persistence — ссылки в шапке.