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

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

Проблема полягає в тому, що деякі мої моделі були побудовані за допомогою інтерактивного процесу. Наприклад, слідуючи порадам у Стратегії моделювання регресії Франка Харрелла , в одній моделі я використовував обмежені кубічні сплайси для обробки можливих нелінійних асоціацій між ознаками та відповіддю. Я виділив ступені свободи кожного сплайну на основі поєднання доменних знань та універсальних заходів міцності асоціації. Але ступінь свободи, яку я хочу дозволити своїй моделі, очевидно, залежить від розміру набору даних, який різко змінюється при повторному тестуванні. Якщо я не хочу вручну вибирати ступінь свободи кожен раз, коли модель підтверджується, які ще мої варіанти?

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

Я вдячний порадам та рішенням: (a) загальної проблеми автоматизації інтерактивних частин процесу побудови моделі, або (b) конкретних порад для цих двох випадків. Дякую!

FYI, це може бути більш підходящим для SE.DataScience, але поки що я відповім на це тут.

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

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

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

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

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

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

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

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