Навіщо використовувати стратифіковану перехресну перевірку? Чому це не шкодить вигоди, пов'язаному з дисперсією?

Мені сказали, що корисно використовувати стратифіковану перехресну перевірку, особливо коли класи відповідей є неврівноваженими. Якщо одна мета перехресної перевірки - допомогти врахувати випадковість нашого вихідного зразка навчальних даних, то, безумовно, зробити так, щоб кожен складник мав однаковий розподіл класів, буде проти цього, якщо ви не впевнені, що ваш оригінальний навчальний набір мав репрезентативний розподіл класів.

Чи є моя логіка хибною?

EDIT Мене цікавить, чи шкодить цей метод корисності для резюме. Я бачу, чому це потрібно, якщо у вас є невеликий зразок / дуже незбалансовані класи / обидва, щоб уникнути не одного представника другорядного класу.

У статті " Яблуки до яблук" у дослідженнях перехресної валідації: Підводні камені при вимірюванні продуктивності класифікатора добре висуває ситуацію стратифікації, але, здається, всі аргументи є "Стратифікація забезпечує захист і більшу послідовність", але жодної гарантії не буде потрібно достатньо. дані.

Чи є відповідь просто "Ми використовуємо це з необхідності, оскільки рідко маємо достатньо даних". ?

Запуск завантажувачів прагне імітувати ефект нанесення нового зразка з сукупності, і не прагне забезпечити чіткі тестові набори (залишки після N від вибірки N із заміною).

Перехресне підтвердження RxK-кратних результатів забезпечує K різних тестових складок, але потім повторюється R разів для різних випадкових розподілів, щоб дозволити збереження припущень щодо незалежності для K-CV, але це втрачається при повторенні.

Стратифікована перехресна перевірка порушує головне, що мітки тестів ніколи не слід було б дивитись перед тим, як розраховувати статистику, але це, як правило, вважається нешкідливим, оскільки єдиним ефектом є збалансування складок, але це призводить до втрати різноманітності ( небажана втрата дисперсії). Це іде ще далі від ідеї Boostrap про побудову зразка, аналогічного тому, що ви могли б зробити природним чином для всього населення. Імовірно, головна причина стратифікації - це усунення дефектів в алгоритмах класифікації, оскільки вони занадто легко зміщуються через надмірну або недостатню представленість класів. На це менше впливає алгоритм, який використовує методи врівноваження (шляхом вибору або зважування) або оптимізує міркування, що відповідає правильному шансу (Kappa або, бажано, Інформація), хоча навіть такі алгоритми можуть "

Примушення кожної складки мати принаймні m екземплярів кожного класу, для деяких невеликих m - альтернатива стратифікації, яка працює як для завантаження, так і для CV. У нього є згладжування зсуву, що робить складки, як правило, більш врівноваженими, ніж можна було б очікувати.

Знову ансамблі та різноманітність: Якщо класифікатори, засвоєні на навчальних складках, використовуються для злиття, а не просто для оцінки похибки узагальнення, зростаюча жорсткість CV, стратифікований Bootstrap та стратифікований CV призводить до втрати різноманітності та потенційної стійкості порівняно з Bootstrap, вимушеним Bootstrap і вимушене резюме.

Можливо, ви можете подумати про це так. Скажімо, у вас є набір даних, де є 100 зразків, 90 у класі "A" та 10 у класі "B". У цьому дуже незбалансованому дизайні, якщо ви робите звичайні рандомізовані групи, ви можете закінчити побудову моделей на надзвичайно мало (і навіть НІКОЛИ!) З класу "B". Якщо ви будуєте модель, яка навчається за даними, де таких інших класів або навіть їх немає, іншого класу, як би ви могли очікувати, що вона спрогнозує більш рідкісну групу? Стратифікована перехресна перевірка дозволяє рандомізувати, але також гарантує, що ці незбалансовані набори даних мають деякі з обох класів.

Щоб зменшити занепокоєння щодо використання стратифікованого резюме з більш 'збалансованими' наборами даних, давайте розглянемо приклад з використанням коду R.

require(mlbench)
require(caret)
require(cvTools)

# using the Sonar dataset (208 samples)
data(Sonar)

# see the distribution of classes are very well balanced
prop.table(table(Sonar$Class))

> prop.table(table(Sonar$Class))

M         R 
0.5336538 0.4663462 

# stratified
# set seed for consistency
# caret::createFolds does stratified folds by default
set.seed(123)
strat <- createFolds(Sonar$Class, k=10)

# non-stratified using cvTools
set.seed(123)
folds <- cvFolds(nrow(Sonar), K=10, type="random")
df <- data.frame(fold = folds$which, index = folds$subsets)
non_strat <- lapply(split(df, df$fold), FUN=function(x) x$index)

# calculate the average class distribution of the folds
strat_dist <- colMeans(do.call("rbind", lapply(strat, FUN = function(x) prop.table(table(Sonar$Class[x])))))
    non_strat_dist <- colMeans(do.call("rbind", lapply(non_strat, FUN = function(x) prop.table(table(Sonar$Class[x])))))
strat_dist
> strat_dist
M         R 
0.5338312 0.4661688 
non_strat_dist
> non_strat_dist
M         R 
0.5328571 0.4671429 

Як бачите, у наборі даних, який добре збалансований, складки матимуть подібний розподіл за випадковим випадком. Тому стратифікований резюме - це просто міра впевненості в цих умовах. Однак, щоб вирішити дисперсію, вам слід ознайомитися з розподілами кожної складки. За деяких обставин (навіть починаючи з 50-50) у вас можуть виникнути складки, які мають розщеплення 30-70 випадковим чином (ви можете запустити код вище і побачити, що це насправді відбувається!). Це може призвести до погіршення моделі, оскільки не вистачало одного класу, щоб точно передбачити її, тим самим збільшуючи загальну дисперсію CV. Це, очевидно, важливіше, коли у вас є "обмежені" зразки, коли ви, швидше за все, мають дуже екстремальні відмінності в розподілі.

Тепер при дуже великих наборах даних стратифікація може не знадобитися, оскільки складки будуть достатньо великими, щоб все-таки містити принаймні хорошу частку класу 'рідше'. Однак обчислювальних втрат і реальних причин відмовитись від стратифікації немає, якщо ваші зразки не є збалансованими, незалежно від того, скільки даних ви маєте на мою особисту думку.