Фиксация набора оценки и правил сравнения перед сопоставлением моделей

Контекст и рекомендации

Набор оценки должен быть зафиксирован до сравнения любых моделей. Это означает запись сплитов, подмножеств, весов, метрик и их направлений в файле или конфигурации. Библиотека Hugging Face Evaluate предоставляет инструменты для согласованной загрузки и вычисления метрик, в то время как параметр scoring в scikit-learn определяет правила оценки для выбора модели. Оба инструмента поддерживают воспроизводимую оценку, если правила задокументированы. Рекомендуется создать спецификацию оценки, в которой точно указано, какие примеры используются, какие метрики вычисляются и как агрегируются результаты. Без этого два разных запуска или два автора могут получить разные числа, которые невозможно сравнить. Спецификация должна включать порядок агрегации, например, средневзвешенное значение по подмножествам, и правило, согласно которому модели сравниваются на одних и тех же сплитах. Это предотвращает случайные изменения в предобработке или порядке данных, которые могли бы изменить вывод. Цель состоит в том, чтобы сделать эксперимент воспроизводимым, а сравнение - прозрачным.

Спецификацию оценки следует хранить в файле (например, YAML или JSON), чтобы ее можно было версионировать и повторно использовать. Файл должен содержать список сплитов, подмножеств, весов, метрик и правил сравнения. Например, эксперимент по классификации может использовать два подмножества, A и B, с весами 0.6 и 0.4, и две метрики, точность (accuracy) и полноту (recall), обе с направлением на максимизацию. Правило сравнения гласит, что используются одни и те же сплиты, каждое подмножество отображается отдельно, а агрегат является средневзвешенным. Этот файл становится единственным источником истины для эксперимента. Когда запускаются две модели, обе считывают одну и ту же спецификацию, поэтому результаты напрямую сопоставимы. Отчет должен включать показатели по подмножествам и агрегат, а не только последний. Таким образом, можно увидеть, что модель, победившая в среднем, проигрывает на критическом подмножестве. Спецификация также фиксирует направления метрик, чтобы агрегация была осмысленной.

Библиотека Hugging Face Evaluate и API скоринга scikit-learn являются практическими инструментами для этого процесса. Evaluate позволяет единообразно вычислять метрики на наборах данных. Параметр scoring в scikit-learn определяет правила оценки моделей для кросс-валидации и поиска параметров. Обе библиотеки поддерживают концепцию того, что оценка - это набор правил, а не просто одно число. Важно записывать эти правила в файл, чтобы одни и те же входные данные всегда приводили к одним и тем же результатам. Это особенно важно при участии нескольких авторов или проведении множества запусков. Спецификация должна быть доступна всей команде и служить основой для финального отчета. В отчете должны быть представлены необработанные данные по подмножествам, агрегированное значение и правила сравнения. Это делает эксперимент проверяемым, а выводы - обоснованными.

Пример в задаче демонстрирует двух классификаторов с точностью 0.91 против 0.89, но на подмножестве B полнота падает с 0.78 до 0.62. Если сообщается только агрегированный показатель, эта потеря незаметна. При фиксированной спецификации отчет показывает и агрегат, и разбивку по подмножествам, что делает сравнение прозрачным. Тот же принцип применим к любой области, где используются несколько подмножеств или метрик. Набор оценки должен быть зафиксирован, правила записаны, а отчет должен содержать детализацию. Это предотвращает распространенную ошибку выбора модели на основе одного числа, которое скрывает важные сбои. Спецификация должна быть создана до начала эксперимента, а не после получения результатов. Это гарантирует справедливость сравнения и то, что выводы основаны на предварительно зарегистрированных правилах.

eval_spec:
  splits: [train, validation, test]
  subsets:
    A: {weight: 0.6}
    B: {weight: 0.4}
  metrics:
    accuracy:
      direction: maximize
    recall:
      direction: maximize
  comparison:
    same_splits: true
    report_per_subset: true
    aggregate: weighted_average

Обоснование и компромиссы

Единая итоговая метрика упрощает ранжирование, но скрывает распределение ошибок по подгруппам, временным горизонтам и типам ошибок.

Компромисс очевиден: запись правил требует дополнительных усилий на начальном этапе, но один агрегат может изменить ранжирование, если учесть критическое подмножество. Написание файла спецификации занимает минуты; обнаружение того, что модель дает сбой на миноритарной подгруппе после развертывания, занимает недели. Асимметрия затрат говорит в пользу спецификации.

В примере модель X имеет точность 0.91, а модель Y - 0.89. На подмножестве B полнота падает с 0.78 у модели Y до 0.62 у модели X. Если агрегат - это средневзвешенная точность по подмножествам A и B с весами 0.6 и 0.4, модель X набирает 0.91 в целом, а модель Y - 0.89. Разница в агрегате составляет всего 0.02, однако разрыв в полноте на подмножестве B составляет 0.16 - это существенное различие, которое скрывает одно число.

Фиксированная спецификация заставляет отчет выводить и агрегат, и разбивку по подмножествам. Без спецификации аналитик может выбрать модель X на основе более высокого агрегата и пропустить провал по полноте на подмножестве B. Со спецификацией сравнение становится прозрачным, и сбой становится видимым до развертывания.

# Evaluation spec used for model comparison
spec = {
    "splits": ["train", "validation", "test"],
    "subsets": {"A": 0.6, "B": 0.4},
    "metrics": {"accuracy": "maximize", "recall": "maximize"},
    "aggregate": "weighted_average"
}

# Example: compare two models on the same splits with per-subset reporting
# Model X: accuracy 0.91, recall on subset B 0.62
# Model Y: accuracy 0.89, recall on subset B 0.78
# The aggregate alone hides the subset B failure for Model X

# The same spec is used for both models so the comparison is fair
# Report per-subset scores and the weighted aggregate
# This prevents a high aggregate from hiding a low score on a critical subset

Конкретная иллюстрация

Рассмотрим два классификатора, оцениваемых на наборе данных, разделенном на подмножество A (60% примеров) и подмножество B (40% примеров). Модель X достигает точности 0.91 на A и 0.90 на B. Модель Y достигает точности 0.88 на A и 0.90 на B. Средневзвешенная точность составляет 0.6 * 0.91 + 0.4 * 0.90 = 0.906 для модели X и 0.6 * 0.88 + 0.4 * 0.90 = 0.888 для модели Y. Модель X побеждает по агрегату с разницей в 0.018.

Теперь изучим полноту конкретно на подмножестве B. Модель X имеет полноту 0.62 на B, в то время как модель Y имеет полноту 0.78 на B. Разрыв составляет 0.16, что значительно больше разницы в агрегированной точности (0.018). Если подмножество B представляет критически важную миноритарную группу, где пропуск положительных результатов обходится дорого, кажущееся преимущество модели X является иллюзорным.

Фиксированная спецификация гласит, что полнота на подмножестве B должна сообщаться отдельно, а правило сравнения требует видимости по подмножествам. Когда отчет генерируется на основе спецификации, агрегат и полнота по подмножествам отображаются рядом. Читатель видит, что модель X выигрывает по общей точности, но сильно проигрывает по полноте на подмножестве B, и может принять обоснованное решение, не полагаясь на одно число.

Этот рабочий пример показывает, почему спецификация важна с операционной точки зрения. Без нее аналитик вычисляет одно число точности, видит 0.91 против 0.89 и выбирает модель X. Со спецификацией тот же аналитик обязан показать разбивку, и сбой полноты на подмножестве B становится невозможно проигнорировать.

eval_spec:
  splits: [train, validation, test]
  subsets:
    A: {weight: 0.6}
    B: {weight: 0.4}
  metrics:
    accuracy:
      direction: maximize
    recall:
      direction: maximize
  comparison:
    same_splits: true
    report_per_subset: true
    aggregate: weighted_average

# Model X: accuracy 0.91, recall on subset B 0.62
# Model Y: accuracy 0.89, recall on subset B 0.78
# Aggregate alone hides the subset B failure for Model X
# The report must show per-subset scores and the weighted aggregate

Ограничения применимости

Этот подход не заменяет отдельный финальный тестовый набор при настройке гиперпараметров. Он сам по себе не обеспечивает статистическую значимость; для малых или шумных различий требуется формальный тест. Результаты остаются сопоставимыми только в том случае, если набор оценки и правила остаются неизменными, так как изменение сплитов или весов требует нового сравнения. Также это не отменяет необходимости выбора стратегии валидации (например, кросс-валидации или хронологических сплитов) в зависимости от типа данных. Метод предполагает наличие нескольких подмножеств или метрик и то, что решение основывается на сравнении моделей. Он не может гарантировать, что средневзвешенный агрегат является правильной бизнес-целью, и не выравнивает пространства эмбеддингов или не устанавливает истинность релевантности без парных энкодеров и независимых эталонных меток.

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

eval_spec:
  splits: [train, validation, test]
  subsets:
    A: {weight: 0.6}
    B: {weight: 0.4}
  metrics:
    accuracy:
      direction: maximize
    recall:
      direction: maximize
  comparison:
    same_splits: true
    report_per_subset: true
    aggregate: weighted_average