Baseline, benchmark и ablation study: как проверить ML-исследование

Практический разбор baseline, benchmark и ablation study: как проверить сопоставимость ML-эксперимента, найти слабое сравнение и воспроизвести минимальную проверку.

В ML-статье легко увидеть таблицу, где новая модель обгоняет старую на несколько десятых, и принять это за доказательство прогресса. Но сама разница ещё ничего не гарантирует. Нужно понять, с чем сравнивали модель, одинаковую ли задачу решали все участники и какое изменение действительно дало прирост. Для этих трёх вопросов служат baseline, benchmark и ablation study.

Эти термины связаны, но не взаимозаменяемы:

baseline — конкретная точка отсчёта: простое правило, прежняя система или признанная модель;
benchmark — договорённость о задаче: данные, split, метрика, протокол обучения и способ подсчёта результата;
ablation study — контролируемая серия вариантов, где компонент убирают или заменяют, сохраняя остальные условия насколько возможно.

Хорошая статья отвечает на все три вопроса. Сильный baseline показывает, есть ли практический выигрыш. Честный benchmark делает числа сопоставимыми. Ablation помогает проверить объяснение авторов: действительно ли результат связан с заявленным компонентом, а не только с большим бюджетом, иной предобработкой или удачным seed.

Baseline — это проверяемая точка отсчёта

Для классификации самый нижний sanity check может вообще игнорировать признаки и всегда выбирать частый класс. В scikit-learn для этого есть DummyClassifier. Если сложная модель не превосходит такое правило на подходящей метрике, сначала стоит проверить данные, split и реализацию, а не увеличивать число слоёв.

Одного слабого baseline обычно недостаточно. Полезная лестница сравнений выглядит так:

тривиальное правило, которое ловит ошибку постановки;
простая обучаемая модель на тех же признаках;
прежняя production-система или общепринятый метод;
сильная опубликованная модель, воспроизведённая по тому же протоколу.

Baseline обязан получать те же входные данные и оцениваться тем же кодом. Нельзя обучить новую модель на дополнительном корпусе, а старую оставить без него и приписать весь прирост архитектуре. Нельзя сравнивать F1 новой работы с accuracy из чужой таблицы. Нельзя настраивать свою модель по test set, а baseline запускать с параметрами по умолчанию.

Простой baseline полезен не потому, что он обязательно победит. Он даёт поведение, которое можно понять и отладить. Руководство Google Rules of ML отдельно рекомендует начинать с простой модели и надёжного pipeline: такая версия фиксирует базовые метрики и помогает проверить более сложную систему.

Benchmark — не просто название датасета

Фраза «мы тестировали на Dataset X» ещё не определяет эксперимент. Один и тот же набор данных может иметь несколько официальных split, разные правила удаления дублей и разные метрики. Результат меняется и от того, усредняются ли классы macro- или micro-способом, включены ли дополнительные данные, сколько запусков выполнено и как выбирался checkpoint.

Минимальный контракт benchmark содержит:

Часть	Что нужно зафиксировать
Задача	Что является входом, целью и единицей одного примера
Данные	Точная версия, лицензия, фильтры и недопустимые источники утечки
Split	Готовые идентификаторы train/validation/test или воспроизводимый алгоритм
Метрика	Формула, направление улучшения, averaging и обработка пропусков
Обучение	Бюджет, число эпох, ранняя остановка, scheduler и seeds
Выбор модели	По какой validation-метрике выбирают параметры и checkpoint
Отчёт	Число запусков, разброс, вычислительные ресурсы и ошибки

Benchmark позволяет сравнение только внутри соблюдённого контракта. Если новая работа изменила размер изображений, добавила внешний корпус или выбрала другой split, это может быть полезным экспериментом, но число уже нельзя ставить в одну колонку без пояснения.

Отдельная опасность — незаметная адаптация к test set. Даже если его метки не подаются оптимизатору, многократный выбор идей по итоговому score превращает test в часть разработки. Для честной финальной проверки test должен использоваться редко, а решения приниматься по train и validation.

Ablation проверяет механизм утверждения

Предположим, авторы добавили новый модуль, увеличили модель, изменили аугментации и удвоили время обучения. Итоговый результат вырос. Из такого сравнения нельзя узнать, что сработало. Ablation раскладывает пакет изменений на варианты.

Для системы с базовым encoder, модулем A и регуляризатором B таблица может выглядеть так:

Вариант	Encoder	A	B	Бюджет	Score
Базовый	прежний	нет	нет	10 GPU·ч	0,811
Только A	прежний	да	нет	10 GPU·ч	0,824
Только B	прежний	нет	да	10 GPU·ч	0,815
Полный	прежний	да	да	10 GPU·ч	0,829

Такая таблица проверяет вклад A и B в заданных условиях. Она не доказывает, что A необходим для любой модели или любого датасета. Компоненты могут взаимодействовать: эффект A отдельно и вместе с B бывает разным. Поэтому для ключевых взаимодействий нужны дополнительные варианты, а не только последовательное удаление деталей из готовой системы.

«Убрать слой и не переобучать модель» и «обучить архитектуру без слоя с нуля» отвечают на разные вопросы. Первый эксперимент измеряет чувствительность уже обученной сети к повреждению. Второй сравнивает способность двух вариантов обучаться при заданном бюджете. Статья должна назвать выбранный вопрос.

Минимальный воспроизводимый пример

Ниже — учебный протокол для встроенного набора scikit-learn. Это копия набора Breast Cancer Wisconsin (Diagnostic) из UCI Machine Learning Repository, DOI и рекомендуемая атрибуция которого указаны в карточке источника. На дату проверки карточка указывает лицензию CC BY 4.0. Пример не является медицинским инструментом: данные нужны только для небольшой воспроизводимой демонстрации.

Мы сравниваем dummy baseline, логистическую регрессию и условную ablation, где из входа удаляется группа первых десяти признаков. Каждый вариант заново обучается на одинаковом split.

from collections import defaultdict
from statistics import mean, pstdev

from sklearn.datasets import load_breast_cancer
from sklearn.dummy import DummyClassifier
from sklearn.linear_model import LogisticRegression
from sklearn.metrics import balanced_accuracy_score
from sklearn.model_selection import train_test_split
from sklearn.pipeline import make_pipeline
from sklearn.preprocessing import StandardScaler

X, y = load_breast_cancer(return_X_y=True)
scores = defaultdict(list)

for seed in range(10):
    X_train, X_test, y_train, y_test = train_test_split(
        X,
        y,
        test_size=0.25,
        random_state=seed,
        stratify=y,
    )

    variants = {
        "dummy": (DummyClassifier(strategy="prior"), X_train, X_test),
        "full": (
            make_pipeline(StandardScaler(), LogisticRegression(max_iter=2_000)),
            X_train,
            X_test,
        ),
        "without_first_feature_group": (
            make_pipeline(StandardScaler(), LogisticRegression(max_iter=2_000)),
            X_train[:, 10:],
            X_test[:, 10:],
        ),
    }

    for name, (model, train_features, test_features) in variants.items():
        model.fit(train_features, y_train)
        prediction = model.predict(test_features)
        scores[name].append(balanced_accuracy_score(y_test, prediction))

for name, values in scores.items():
    print(f"{name:29} {mean(values):.3f} ± {pstdev(values):.3f}")

Этот код полезнее одного случайного запуска, но всё ещё не является строгой оценкой новой научной гипотезы. Десять разных random split показывают чувствительность к разбиению, однако используют один и тот же небольшой датасет. Для статьи нужно заранее выбрать протокол, не менять его после просмотра результата и хранить сырые значения всех запусков.

Удаление первых десяти признаков тоже не доказывает причинную ценность каждого из них. Группы коррелируют, размер входа меняется, а оптимальные параметры могут различаться. Корректный вывод здесь узкий: «при данном pipeline и этих десяти split вариант без указанной группы показал такой-то результат».

Как читать таблицу результатов

Проверка начинается не с самой большой цифры, а с пяти вопросов.

1. Совпадает ли контракт

У всех строк должны совпадать данные, split, метрика и правила выбора модели. Если не совпадают, различия нужно вынести в отдельную колонку. Ссылка на результат из другой статьи не гарантирует совпадение версии кода и preprocessing.

2. Достаточно ли силён baseline

Сравнение только с dummy показывает, что задача вообще обучаема, но не доказывает научную новизну. Для неё нужен простой компетентный метод и актуальные сопоставимые работы. Если авторы исключили очевидного конкурента, важно понять почему.

3. Одинаков ли бюджет

Больше параметров, данных, времени или попыток hyperparameter search — самостоятельные причины улучшения. Их нельзя скрывать внутри названия архитектуры. Иногда справедливее показать два сравнения: при равном бюджете и при лучшем доступном качестве.

4. Видно ли распределение

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

5. Поддерживает ли ablation текстовый вывод

Если статья утверждает, что помогает новый loss, должен существовать вариант без него при остальных равных условиях. Если ablation меняет одновременно loss, данные и schedule, она не изолирует причину.

Типичные ошибки

Слабая соломенная точка отсчёта. Новую систему сравнивают только с устаревшим или намеренно простым методом.
Разные preprocessing pipeline. Нормализация, токенизация или фильтрация дают преимущество одной строке.
Утечка test set. Идеи и параметры многократно выбирают по финальной метрике.
Cherry-picking seed. Публикуют лучший запуск вместо заранее заданного агрегирования.
Ablation без повторного обучения. Повреждение готовой сети выдают за вклад компонента в процесс обучения.
Один фактор за названием. «Новая архитектура» одновременно получает больше данных и вычислений.
Benchmark как абсолютная истина. Высокий score на узком наборе переносят на production, другой язык или другую группу пользователей без проверки.

Что работа не доказала

Даже честная таблица baseline и ablation не доказывает, что метод будет лучше на других данных, при ином бюджете или в production. Она поддерживает только узкий вывод внутри зафиксированного benchmark-контракта. Такой эксперимент также не устанавливает причину улучшения, если варианты различаются чем-то ещё, кроме заявленного компонента.

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

Карточка проверки перед выводом

Заполните короткую карточку для ключевой таблицы статьи:

Гипотеза:
Основной baseline:
Почему baseline сопоставим:
Датасет и версия:
Split и защита от утечки:
Метрика и averaging:
Бюджет обучения и подбора:
Число независимых запусков:
Ablation, изолирующая заявленный компонент:
Сырые результаты и код:
Самый узкий вывод, который поддерживает эксперимент:

Если половина полей остаётся пустой, таблицу рано использовать как доказательство. Она может быть интересным предварительным сигналом, но степень уверенности должна соответствовать протоколу.

Что считать хорошим результатом

Хороший ML-эксперимент не обязан ставить рекорд. Он обязан позволять проверить, что сравнивается одна задача, что точка отсчёта разумна и что вывод не шире наблюдения. Иногда честный итог звучит так: компонент почти не меняет среднее качество, но снижает разброс; либо выигрывает только при большом бюджете; либо уступает простому baseline на малых данных. Такие отрицательные и условные результаты помогают принять инженерное решение лучше, чем одна выделенная жирным цифра.

Baseline отвечает «лучше чего?». Benchmark — «при каких правилах?». Ablation — «за счёт какого изменения?». Только вместе они превращают таблицу метрик из витрины в проверяемое свидетельство.

Обучающая, валидационная и тестовая выборки без утечки данных — Модель оценивают на примерах, которые не влияли на её настройку. Для этого данные разделяют на обучающую, валидационную и тестовую части.
Метрики регрессии: MAE, MSE, RMSE и R² — Метрика регрессии превращает набор ошибок в одно число, но разные формулы отвечают на разные вопросы. Выбор между MAE, MSE, RMSE и R² должен учитывать единицы измерения, цену…
Метрики классификации: accuracy, precision, recall, F1 и ROC-AUC — Одна доля правильных ответов редко описывает классификатор полностью. Accuracy, precision, recall, F1 и ROC-AUC по-разному учитывают ошибки и пороги.
Переобучение и недообучение модели: как увидеть и исправить — Хорошая модель должна переносить найденную закономерность на новые данные. Переобученная модель запоминает детали и шум train-выборки, а недообученная не описывает даже основные…

Источники

Формат и права

Формат: Авторский разбор

Атрибуция

Самостоятельный редакционный разбор ЯдроКода по публикации о программе воспроизводимости NeurIPS, документации scikit-learn, инженерному руководству Google и работе об ablation-исследованиях. Учебный код использует набор Breast Cancer Wisconsin (Diagnostic), Wolberg et al., UCI Machine Learning Repository, DOI 10.24432/C5DW2B, CC BY 4.0. Текст, таблицы и программный пример созданы редакцией.

Код, данные и иллюстрации

Таблицы и код подготовлены редакцией; изображения и код первоисточников не копируются. Встроенную копию набора UCI scikit-learn загружает локально; источник и лицензия зафиксированы отдельно.

Загружаем научный разбор