Сейчас чистая субъективщина, но в мл имхо очень много вещей существует неоптимальных. Достаточно вспомнить  вопрос отбора переменных. Поэтому грамотно оценить перформанс модели - это здорово, конечно, но если это в N раз увеличивает затраченное время, то возникают вопросы, а надо ли это и не проще ли воспользоваться эвристиками, а потом просто мониторить качество модели в проде

Ведь можно просто построить плот скоров по фолдам для одной и другой модели, и на глаз принять решение, когда действительно перевес, это да

глаза устанут )

Ну если каждое изменение гп так смотреть, то глаз просто не хватит)

ну как бы лучше сделать так: если заниматься коссвалидацией, например, то разделить все на тренировочный набор и отложенный. отложенный вообще не трогать во время обучения. после оценки алгоритмов с кроссвалидацией на тренировочном сделать попарную оценку о статистической значимости их решений с помощью теста 5x2cv paired t test и потом те которые будут в группе статистически значимых с самыми высокими скорами проверить на отложенной выборке и выбрать тот который покажет лучший результат. так наверное http://rasbt.github.io/mlxtend/user_guide/evaluate/paired_ttest_5x2cv/

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

я эту схему из 3х частей не понимаю. чем контрольные данные лучше тестовых? это тот же самый фолд

Главный вопрос для меня на сегодня, а можно ли бутстрепом получать почти независимые выборки?

вот натюнили мы параметры на train-test, посмотрели на контроле, если не понравилось - опять идём тюнить, т.е. по контролю тоже идет тюнинг

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

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

потому что модель может переобучиться на сплитах, ну так если формально говорить

так мы с переобучением боремся как раз на этапе cv

Он не нужен ни для чего кроме как индикатор качества модели.

То есть генерим, отбираем фичи, подбираем гиперпараметры и тд по CV, а тест — это просто лакмусовая бумажка. Если у нас на cv 0.8, а на тесте выдало рок аук 0.6, то понимаем, что что-то не так.

Считай, как приватный лидерборд

ещё и путаница - по разному называют: validation, test, holdout.
а как такое возможно, это просто один из фолдов, на cv (если это не timeseries) скоры по фолдам не могут  так прыгать, cv как раз и показывает - как модель "в среднем" ведет себя на данных, которые не видела.

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

ну да, но всё равно, получается мы обучаем на train-test части несколько моделей, и сравниваем их на контроле - какая модель лучше. да, там скор будет отличаться от cv, но насколько оправдано сравнение моделей на одном фолде?

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