Обратное тестирование или перекрестная проверка, когда процесс построения модели был интерактивным

У меня есть несколько прогностических моделей, производительность которых я хотел бы протестировать (например, взять мой набор данных, «перемотать» его к предыдущему моменту времени и посмотреть, как модель будет работать перспективно).

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

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

Я был бы признателен за советы и решения как (а) общей проблемы автоматизации интерактивных частей процесса построения модели, так и (б) конкретных рекомендаций для этих двух случаев. Спасибо!

К вашему сведению, это может быть более подходящим для SE.DataScience, но пока я отвечу здесь.

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

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

1.) Определение параметров модели в динамическом режиме. Вы ранее упоминали, что использовали комбинацию знаний предметной области и одномерных мер. Это кажется мне чем-то, что вы должны уметь обрабатывать эвристически. Вы должны будете с самого начала согласовать набор правил, которые будет реализовывать ваша программа. Это может быть или не быть тривиальной задачей, поскольку вам придется серьезно подумать о возможных последствиях этих правил. Это может потребовать от вас повторного посещения каждого шага вашего процесса и внесения в каталог не только решений, но и причин этих решений.

2.) На самом деле реализации вашей программы. Чтобы тестирование производительности было должным образом динамичным, его было легко поддерживать и модифицировать в будущем, вам нужно подумать о том, как вы собираетесь его структурировать. Вы, вероятно, захотите использовать какой-то цикл для прогнозной оценки производительности вашей основной модели, предпочтительно с определяемой пользователем длиной, чтобы обеспечить большую гибкость в будущем. Вы также, вероятно, захотите написать отдельные функции для каждого действия, которое должна выполнять ваша программа, поскольку это облегчит тестирование функциональности, а также поддержку и изменение вашей программы в будущем. Как минимум, вам, вероятно, понадобятся функции для выбора набора данных (т. Е. Только периоды времени, которые «прошли» на момент тестирования на истории), очистки и проверки (о которых вам действительно придется подумать,

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

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

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

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