Перевірка витримки проти перехресної перевірки

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

Перехресна перевірка K-кратна, здається, дає кращі наближення до узагальнення (оскільки вона проводить тренування та тестує кожну точку). Отже, чому б ми використовували стандартну перевірку витримки? Або навіть говорити про це?

Я єдиний здогад - це те, що ви можете тримати три години роботи з програмуванням; інше займає тиждень в принципі і півроку на практиці.

У принципі це просто, але написання коду стомлене та трудомістке. Як чудово сказав Лінус Торвальдс, "погані програмісти турбуються про код. Хороші програмісти турбуються про структуру даних та їх зв'язки". Багато людей, які займаються статистикою, погані програмісти, не з їхньої вини. Ефективність перехресної перевірки k-fold (і, маючи на увазі, таким чином, що не дуже страшно налагоджувати та використовувати не один раз) в R вимагає неясного розуміння структур даних, але структури даних, як правило, пропускаються в "вступ" до статистичного програмування "навчальні посібники. Це як стара людина, яка користується Інтернетом вперше. Це насправді не важко, для того, щоб розібратися вперше, потрібно зайвих півгодини або близько того, але він абсолютно новий, і це робить його заплутаним, тому його легко проігнорувати.

У вас є такі питання: Як реалізувати витримування з перевірки в R . Жодне правопорушення не призначалося запитувачеві. Але багато людей просто не грамотні. Те, що люди взагалі роблять перехресну перевірку, достатньо, щоб зробити мене щасливим.

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

Утримування часто використовується синонімом перевірки з незалежним тестовим набором, хоча існують вирішальні відмінності між розділенням даних випадковим чином та розробкою експерименту перевірки незалежного тестування.

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

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

1. вирішити поділ (наприклад, робити випадкове присвоєння справ)
2. міра
3. дані вимірювань та довідники навчальних випадків => моделювання \ ні вимірювання, ні посилання на тестові приклади не передаються особі, яка моделює.
4. остаточна модель + вимірювання витриманих випадків => прогнозування
5. порівняйте прогнози з посиланням на витримані випадки.

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

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

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

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

OTOH, у невеликих розмірах вибірки, витримка не є можливим: вам потрібно провести достатньо тестових випадків, щоб результати тесту були досить точними, щоб можна було зробити необхідний висновок (пам’ятайте: 3 правильних з 3 тестових випадків для класифікації означає а двочленний 95% -ний довірчий інтервал, який знаходиться значно нижче 50:50 здогадів! 100 (тестових) випадків потрібні для належного вимірювання пропорції (наприклад, частки правильно передбачених випадків) з корисною точністю.

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

$k$$n$$n$$k$$k$

Отже, щоб відповісти на запитання:

1. Навіщо говорити про це? Педагогічно. Варто подумати про перевірку витримки як особливий - і лише іноді корисний - варіант інакше досить корисного методу з багатьма, багатьма варіаціями.

2. $n$$k$

$n$$k$$n$$k$$n$

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

Просто хотілося додати кілька простих рекомендацій, які Ендрю Нг згадав у нашому класі CS 229 в Стенфорді щодо перехресної перевірки. Це практики, яких він дотримується у власній роботі.

$m$$m\le 20$

$20 < m \le 100$$k \le m$

$100 < m \le 1,000,000$$(k = 5)$$m > 10,000$ , скористайтеся перехресною валідацією витримки.

$m \ge 1,000,000$$(k = 5)$

Коротка відповідь:

$k=5$

• складні моделі
• кінцеві результати, які повинні дотримуватися обмежень дійсності

Ви можете розслабитися для:

• навчання на дійсно великих наборах даних
• навчання простих моделей
• прототипування, коли час є проблемою

Деякі з вас згадували, що програмування цього в R може бути проблемою. Я рекомендую вам ознайомитись з пакетом "mlr" . Він поєднує різні пакети в єдиний інтерфейс, а також забезпечує дійсно вдосконалені методи перестановки та оцінки продуктивності.

Подивіться: http://mlr-org.github.io/mlr-tutorial/release/html/resample/ та: http://mlr-org.github.io/mlr-tutorial/release/html/performance/ index.htm

Ще одне пояснення - те, що реальне резюме насправді - це зламати зміщення відхилення відхилення:

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

У Holdout є проблема з ухилом і дисперсією:

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

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

Оскільки розмір навчального та тестового набору визначає один одного, це залишає перед нами компроміс: песимістичний упередженість та велика дисперсія.

$k$$\frac{k-1}{k}$ даних використовується для навчання в кожній ітерації) та вирішення дисперсії помилки тесту шляхом переустановки. Після всіх ітерацій ми перевірили ефективність кожного спостереження за набором даних з одним учнем. Очевидно, що для цього потрібно більше часу на обчислення, ніж простого проведення.

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

Все це корисні коментарі. Просто врахуйте ще одне. Якщо у вас є достатня кількість даних, використання Hold-Out - це спосіб оцінити конкретну модель (конкретну модель SVM, конкретну модель CART тощо), тоді як якщо ви використовуєте інші процедури перехресної перевірки, ви оцінюєте методології (за ваших проблемних умов ), а не моделі (методологія SVM, методологія CART тощо).

Сподіваюся, це корисно!

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

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

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

Моє особисте уподобання - це брати дані валідації з усього набору даних, тому замість того, щоб брати єдиний 10% шматок з голови або хвоста даних, я беру 2% з 5 балів у наборі даних. Це робить дані перевірки трохи репрезентативнішими в цілому.

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