Вкладена перехресна перевірка для вибору моделі

Як можна використовувати вкладені перехресні перевірки для вибору моделі ?

З того, що я читаю в Інтернеті, вкладене резюме працює наступним чином:

• Існує внутрішній цикл резюме, де ми можемо провести пошук по сітці (наприклад, запустивши K-кратно для кожної доступної моделі, наприклад, комбінація гіперпараметрів / функцій)
• Є зовнішня петля CV, де ми вимірюємо продуктивність моделі, яка виграла у внутрішній складці, на окремій зовнішній складці.

В кінці цього процесу ми закінчуємо моделями ( K - кількість складок у зовнішній петлі). Ці моделі є тими, хто виграв у пошуку сітки у внутрішньому резюме, і вони, ймовірно, різні (наприклад, SVM з різними ядрами, навчені з можливо різними можливостями, залежно від пошуку в сітці).$K$$K$

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

Тож як я можу використовувати вкладене резюме для вибору моделі?

Також я читав теми, які обговорюють, як вибір вкладеної моделі корисний для аналізу навчальної процедури. Які типи аналізу / перевірки я можу зробити з оцінками, отриманими від зовнішніх складок K?

Як вибрати модель із цього [зовнішнього перехресного підтвердження]?

Коротка відповідь: Ви цього не робите.

Розгляньте внутрішню перехресну перевірку як частину процедури встановлення моделі. Це означає, що підганяння, включаючи пристосування гіперпараметрів (саме там криється внутрішня перехресна перевірка), подібно до будь-якої іншої процедури моделювання епіляції.
Зовнішня перехресна валідація оцінює ефективність підходу цієї моделі. Для цього ви використовуєте звичайні припущення

• $k$model.fitting.procedure
• $k$
  

$k$

Тож як я можу використовувати вкладене резюме для вибору моделі?

Внутрішнє резюме робить вибір.

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

$k$

• Якщо у вас немає однакових даних тестування: як потім ви хочете стверджувати, що результати тестування узагальнюються до ніколи не бачених даних, це не може змінити значення.
• Не мають однакових даних про навчання:
  • якщо моделі стабільні, це не має значення: тут стабільна означає, що модель не змінюється (сильно), якщо дані тренувань "збурені", замінивши кілька випадків іншими випадками.
  • якщо моделі нестабільні, важливі три міркування:
    1. $k$
    2. $k$
    3. Якщо нестабільність є справжньою проблемою, ви не можете екстраполювати ефективність для "реальної" моделі.

Що підводить мене до вашого останнього питання:

Які типи аналізу / перевірки я можу зробити з оцінками, отриманими від зовнішніх складок K?

• перевірити стабільність прогнозів (використовувати ітераційну / повторну перехресну перевірку)

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

• перевірити різницю між внутрішньою та зовнішньою оцінкою обраної моделі. Якщо є велика різниця (внутрішня істота дуже надмірно оптимістична), існує ризик, що внутрішня оптимізація не спрацювала добре через надмірну обробку.

update @ user99889 питання: Що робити, якщо зовнішній резюме виявить нестабільність?

Перш за все, виявлення у зовнішньому циклі CV, що моделі не дають стабільних прогнозів у цьому відношенні, насправді не відрізняється від виявлення того, що помилка прогнозування занадто висока для програми. Це один із можливих результатів перевірки (або перевірки) моделі, що означає, що модель, яку ми маємо, не відповідає своєму призначенню.

У коментарі, відповідаючи на @davips, я думав вирішити нестабільність у внутрішньому резюме, тобто як частину процесу оптимізації моделі.

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

Однак тут є одна особливість, що IMHO може виправдати подальшу зміну "остаточної" моделі після ретельного врахування точних обставин : Оскільки ми виявили перевиконання, будь-яка запропонована зміна (менша кількість df / більш обмежувальна чи агрегаційна) моделі буде орієнтуватися на менший розмір (або принаймні гіперпараметри, які менш схильні до перевиконання). Суть незалежного тестування полягає у виявленні перевиконання - недостатність може бути виявлена ​​за даними, які вже використовувались у навчальному процесі.

Тож якщо ми говоримо, скажімо, про подальше зменшення кількості прихованих змінних в моделі PLS, яке було б порівняно доброякісним (якщо запропонована зміна була б абсолютно іншим типом моделі, скажімо, PLS замість SVM, усі ставки будуть відключені ), і я би був ще більш розслабленим щодо цього, якби я знав, що ми все-таки перебуваємо на проміжному етапі моделювання - адже якщо оптимізовані моделі все ще нестабільні, не виникає сумніву, що більше справ потрібно. Крім того, у багатьох ситуаціях вам з часом потрібно буде виконати дослідження, призначені для належного випробування різних аспектів ефективності (наприклад, узагальнення даних, отриманих у майбутньому). Все-таки я наполягаю на тому, що потрібно повідомити про повний процес моделювання, і що про наслідки цих пізніх змін потрібно ретельно обговорити.

Крім того, агрегація, що включає та оцінює показники аналогового резюме з мішків, буде можливою за вже наявними результатами - що є іншим типом "післяобробки" моделі, який я хотів би вважати доброякісним тут. Знову ж таки, було б тоді краще, якби дослідження були розроблені з самого початку, щоб перевірити, чи агрегація не дає переваги перед окремими прогнозами (це ще один спосіб сказати, що окремі моделі є стабільними).

Оновлення (2019): чим більше я думаю про ці ситуації, тим більше я віддаю перевагу підходу "вкладеної перехресної перевірки, очевидно, без гніздування" .

Крім відмінної відповіді на цебелеїтів (+1), основна ідея полягає в тому, що перехресне підтвердження використовується для оцінки ефективності методу підгонки моделі, а не самої моделі. Якщо вам потрібно здійснити вибір моделі, вам потрібно виконати це незалежно у кожному складі процедури перехресної перевірки, оскільки це невід'ємна частина процедури підгонки моделі. Якщо ви використовуєте процедуру вибору моделі на основі перехресної перевірки, це означає, що ви закінчилися вкладеною перехресною валідацією. Корисно врахувати мету кожної перехресної перевірки - одна призначена для вибору моделі, а друга для оцінки продуктивності.

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

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