Rétro-test ou validation croisée lorsque le processus de création de modèle était interactif

J'ai quelques modèles prédictifs dont je voudrais tester les performances (c.-à-d. Prendre mon jeu de données, le «rembobiner» à un point antérieur dans le temps et voir comment le modèle aurait fonctionné de manière prospective).

Le problème est que certains de mes modèles ont été construits via un processus interactif. Par exemple, en suivant les conseils des stratégies de modélisation de la régression de Frank Harrell , dans un modèle, j'ai utilisé des splines cubiques restreintes pour gérer les associations non linéaires possibles entre les caractéristiques et la réponse. J'ai attribué les degrés de liberté de chaque spline en fonction d'une combinaison de connaissances du domaine et de mesures univariées de la force de l'association. Mais les degrés de liberté que je veux accorder à mon modèle dépendent évidemment de la taille de l'ensemble de données, qui varie considérablement lors des contre-tests. Si je ne veux pas choisir séparément les degrés de liberté à chaque fois que le modèle est testé à nouveau, quelles sont mes autres options?

Pour un autre exemple, je travaille actuellement sur la détection des valeurs aberrantes via la recherche de points avec un effet de levier élevé. Si j'étais heureux de le faire à la main, je regardais simplement chaque point de données à fort effet de levier, vérifiais sainement que les données étaient propres et les filtrais ou les nettoyais à la main. Mais cela repose sur un tas de connaissances de domaine, donc je ne sais pas comment automatiser le processus.

J'apprécierais des conseils et des solutions à la fois (a) au problème général de l'automatisation des parties interactives du processus de construction de modèles, ou (b) des conseils spécifiques pour ces deux cas. Merci!

Pour info, cela pourrait être plus approprié pour SE.DataScience, mais pour le moment, je vais y répondre ici.

Il me semble que vous pourriez être dans une situation où vous n'aurez d'autre choix que d'écrire un script qui implémentera vos solutions. N'ayant jamais travaillé avec des splines, ma connaissance de celles-ci est strictement théorique, alors soyez indulgent et faites-moi savoir s'il y a quelque chose que je ne vois pas.

D'une manière générale, il semble que vous ayez quelques éléments différents que vous devrez résoudre pour mettre en œuvre cela.

1.) Déterminer les paramètres du modèle de manière dynamique. Vous avez mentionné précédemment que vous avez utilisé une combinaison de connaissances du domaine et de mesures univariées. Cela me semble être quelque chose que vous devriez pouvoir gérer heuristiquement. Vous devrez convenir dès le départ d'un ensemble de règles que votre programme mettra en œuvre. Cela peut ou non être une tâche triviale, car vous devrez réfléchir sérieusement aux implications potentielles de ces règles. Cela peut vous obliger à revisiter chaque étape de votre processus et à cataloguer non seulement les décisions, mais aussi les raisons de ces décisions.

2.) Mise en œuvre effective de votre programme. Afin de rendre vos tests de performances correctement dynamiques et faciles à maintenir et à modifier à l'avenir, vous devrez réfléchir à la façon dont vous allez les structurer. Vous souhaiterez probablement utiliser une sorte de boucle pour votre estimation prédictive des performances du modèle principal, de préférence avec une longueur définissable par l'utilisateur afin de permettre une plus grande flexibilité à l'avenir. Vous souhaiterez également probablement écrire des fonctions distinctes pour chaque action que vous souhaitez que votre programme entreprenne, car cela facilitera le test des fonctionnalités, ainsi que la maintenance et la modification de votre programme à l'avenir. Vous aurez, au minimum, probablement besoin de fonctions pour la sélection de l'ensemble de données (c'est-à-dire uniquement les périodes qui se sont «écoulées» au moment du contre-test), le nettoyage et la validation (auxquelles vous devrez vraiment penser,

Votre question sur la détection et la gestion des valeurs aberrantes relève également de ces deux préoccupations et je m'efforcerais de l'implémenter en écrivant des boucles plus petites dans votre boucle de programme principale qui continueraient à "nettoyer" et à réinstaller le modèle jusqu'à ce qu'il atteigne un point où vous seriez satisfait il (qui encore une fois, vous devrez vous définir).

Si cela semble être une grosse tâche, c'est parce que c'est; les gens ont écrit des bibliothèques de logiciels entières (parfois très lucratives) afin d'effectuer ce genre de tâche. Au-delà de cela, il est difficile d'offrir des conseils plus spécifiques sans en savoir plus sur vos processus, la structure des données et le langage de programmation dans lequel vous avez effectué votre travail jusqu'à présent.

Si tout cela vous est utile et que vous aimeriez que je développe sur tout cela, commentez, faites-le moi savoir, et je serais plus qu'heureux de le faire.

Plutôt que d'essayer de comprendre comment automatiser vos efforts de réglage manuel du modèle, je contournerais ce problème tous ensemble en examinant les apprenants à faible variance qui nécessitent beaucoup moins de réglage, même si cela a un coût d'augmentation du biais du modèle. Vous voulez avoir confiance en vos résultats de backtest qui se résument en grande partie à une faible variance d'échantillonnage dans vos prévisions, et l'introduction d'un processus de réglage automatisé au-dessus d'un apprenant qui a déjà une variance d'échantillonnage elle-même va à l'encontre de cet objectif. Il peut sembler que la queue remue le chien ici, mais tout ce qui nécessite un réglage minutieux (manuel ou automatisé) n'est pas un excellent candidat pour un environnement de backtest IMO vraiment honnête.