Dans une édition récente de Techniquement parlant , nous avons vu comment incorporer des variables dérivées du text mining dans un modèle prédictif afin d'améliorer les performances du modèle. (Si vous n'avez pas regardé la présentation, vous voudrez peut-être le faire avant de poursuivre la lecture.) L'étude de cas s'est davantage concentrée sur l'exploration de texte que sur la modélisation prédictive. Examinons donc maintenant deux étapes principales de modélisation qui n'ont pas été abordées : à savoir : valider le modèle et noter de nouvelles observations.
Validation du modèle
En modélisation prédictive, il est crucial de tester la précision du modèle avant de l'utiliser pour générer des prédictions. Nous voulons nous assurer que notre modèle n'est pas « surajusté », capturant avec précision les données sur lesquelles il a été formé mais générant des prédictions inexactes pour des données qu'il n'a jamais vues auparavant. Un excellent mème capturant le concept de surapprentissage circule sur Internet depuis un certain temps déjà.
Une façon de vérifier le surajustement consiste à mettre de côté ou à « conserver » un sous-ensemble de nos données, à entraîner le modèle sur les données restantes, puis à tester le modèle sur l'ensemble à conserver. Nous mesurons les performances de prédiction du modèle sur les données d'entraînement et d'exclusion, et si nous constatons une baisse importante de la précision entre l'entraînement et les ensembles de tests, nous avons la preuve que notre modèle est surajusté.
Nous avons en fait utilisé cette procédure de validation lors de la création du modèle Bootstrap Forest dans l'étude de cas, même si nous l'avons passé sous silence. Un tableau des mesures d’ajustement du modèle issues de la procédure de validation se trouve ci-dessous. JMP fournit un certain nombre de mesures permettant de comparer les performances de l'entraînement et des ensembles de tests (si vous êtes curieux, lisez-les ici ); nous avons vu Entropy RSquare et Misclassification Rate pour le groupe de test dans la présentation. Aucune des mesures ne montre une forte baisse des performances entre la formation et le test (bien qu'il y ait quelques légères baisses sur quelques mesures, ce qui n'est pas inhabituel), nous concluons donc que notre modèle n'est pas surajusté.
Vous remarquerez peut-être quelque chose : il y a également une colonne « Validation » dans ce tableau. Ça parles de quoi? En réalité, nous divisons ici nos données en trois sous-ensembles : formation, validation et test. Dans notre modèle Bootstrap Forest, l'ensemble d'entraînement est utilisé pour trouver les meilleures divisions dans chaque arbre de décision, tandis que l'ensemble de validation est utilisé pour décider quand arrêter de faire de nouvelles divisions dans chaque arbre ainsi que quand arrêter de créer de nouveaux arbres. Autrement dit, l'algorithme d'ajustement du modèle continue tant que chaque nouvelle division ou arbre entraîne une amélioration des performances sur l'ensemble de validation. Une fois que les performances sur l’ensemble de validation se stabilisent, l’algorithme s’arrête. (Vous vous souvenez de cette statistique Entropie RSquare ? C'est la statistique de validation utilisée dans ce processus.) Une fois l'algorithme arrêté, la précision du modèle résultant est évaluée à l'aide de l'ensemble de test. Dans JMP Pro , tout cela se produit automatiquement en spécifiant une colonne de validation dans la fenêtre de spécification du modèle, comme vous l'avez vu dans la présentation .
Tous les modèles ne nécessitent pas une validation en trois parties comme celle-ci. Il est uniquement nécessaire pour les modèles qui utilisent une procédure d'ajustement itérative et un sous-ensemble de données distinct (l'ensemble de validation) de décider quand arrêter l'ajustement. Pour les modèles qui n'impliquent pas de procédure d'ajustement itérative – par exemple la régression logistique, que nous aurions pu utiliser ici – seuls des ensembles de formation et de test sont nécessaires.
JMP Pro propose un moyen simple de diviser nos données pour la validation du modèle. Nous avons utilisé l'utilitaire Make Validation Column, qui effectue un échantillonnage aléatoire ou pseudo-aléatoire (sans remplacement) sur nos données pour créer chaque sous-ensemble, les sous-ensembles étant enregistrés dans une colonne de validation dans notre table de données.
Ici, nous avons utilisé un échantillonnage aléatoire stratifié pour créer nos sous-ensembles, ce qui est expliqué dans le paragraphe en haut de la deuxième capture d'écran. Il y avait un fort déséquilibre dans quelques-unes de nos variables catégorielles et nous voulions éviter une situation dans laquelle, par exemple, peu ou aucune des violations aggravées se retrouvaient dans l'ensemble de test. Cela serait problématique, car nous devons voir comment le modèle fonctionne en cas de violations aggravées pour obtenir une mesure valide de l'exactitude du modèle.
Vous pouvez voir dans le rapport de distribution interactif ci-dessous que nous avons une représentation correspondante de chaque colonne de stratification dans nos trois sous-ensembles de données. Avec près de 40 000 lignes de données, il y a de fortes chances que nous nous serions bien passés sans utiliser la stratification, mais ce n'était pas une mauvaise idée de jouer la sécurité. La stratification est l'une des nombreuses procédures d'échantillonnage pseudo-aléatoire que l'utilitaire Créer une colonne de validation peut implémenter (voir ici pour plus).
L'utilitaire Make Validation Column a déposé une colonne nommée « Validation » dans notre tableau de données (qui est disponible en téléchargement sur la page de présentation Techniquement parlant), et nous l'avons ensuite introduit dans la plateforme Bootstrap Forest pour déclencher le processus de validation. Nous n'avons trouvé aucune preuve de surajustement, donc en supposant que nous sommes satisfaits de la précision globale du modèle, nous sommes prêts à l'utiliser pour générer des prédictions pour (« noter ») de nouvelles observations.
Noter de nouvelles observations
Imaginons que nous ayons un groupe d'infractions au code du bâtiment qui viennent d'être commises et que nous souhaitons attribuer à chacune d'entre elles une probabilité de pénalité financière, que nous utiliserons pour pondérer chaque montant de pénalité imposée dans nos projections financières. Par exemple, une pénalité imposée de 1 000 $ pour une infraction avec une probabilité de pénalité de 0,7 donnerait lieu à un paiement prévu de 700 $. Bien entendu, le défendeur paiera en fin de compte soit 1 000 $, soit 0 $, mais en moyenne, pour de nombreuses violations, la somme de nos projections devrait se rapprocher de notre revenu final (nous l'espérons). Nous obtenons les probabilités de pénalité de notre modèle Bootstrap Forest, mais ce modèle a pris comme entrées les scores de l'analyse thématique. Nous devons donc appliquer nos nouvelles violations à travers les deux modèles. Il ne s’agit pas d’une pratique rare consistant à utiliser le résultat d’un modèle comme entrée dans un autre.
JMP peut générer des modèles sous forme de formules de colonnes vers la table de données d'origine (sous les options du triangle rouge dans les plates-formes de modélisation), et ils s'exécuteront sur toutes les nouvelles données que nous ajoutons à la table. Pour noter de nouvelles observations, nous ajoutons simplement les nouvelles violations à notre tableau, et les scores des sujets et les probabilités de pénalité sont calculés automatiquement par les formules de colonnes. Nous créons ensuite une nouvelle formule de colonne qui multiplie les probabilités de pénalité par les montants des pénalités imposées, et nous obtenons nos paiements projetés. Ci-dessous, nous avons des projections pour 1 000 nouvelles violations. Nous prévoyons que cela nous rapportera environ 1,84 million de dollars de revenus, même si environ un tiers de ce total ne représente que les 100 paiements les plus importants projetés dans cette queue positive. L’exactitude de nos projections dépendra en grande partie de ce qui adviendra de ces violations.
(Un aparté : nous avons décrit la méthode pointer-cliquer pour noter les observations, mais la notation pourrait être facilement automatisée via des scripts en JSL (JMP Scripting Language). Le modèle pourrait également être déployé en dehors de JMP dans un langage tel que Python ou JavaScript, avec la capacité de JMP Pro à écrire du code de notation dans d'autres langages.)
Et cela met en lumière peut-être la question la plus importante de toutes : quelle est réellement la qualité de nos projections ? Nous avons des statistiques d'ajustement comme Entropy RSquare pour capturer les performances du modèle, mais ce que nous vraiment ce qui compte, c’est l’exactitude des projections financières. En pratique, nous aurions évalué cela dans le cadre de la phase de création du modèle en générant une projection de revenus pour notre ensemble de test et en la comparant aux revenus réels que nous avons observés. Nous ne l'avons pas fait ici car, malheureusement, les données disponibles ne contenaient pas les montants des pénalités initialement imposées, mais seulement les montants finaux après jugement. (Dans l’exemple de notation ci-dessus, nous avons simplement imaginé certains montants de pénalité initialement imposés à des fins explicatives.)
Une pensée d'adieu
Même si nous avons atteint notre objectif – un modèle qui attribue des probabilités de pénalités financières aux nouvelles violations – un projet comme celui-ci n'est jamais vraiment réalisé. Au fil du temps, de nouveaux types ou tendances de violations peuvent apparaître, de nouvelles politiques peuvent modifier la relation entre les caractéristiques des violations et le paiement des astreintes, ou les probabilités de paiement des astreintes pourraient simplement changer au fil du temps en raison de facteurs non mesurés tels que la capacité de répression ou la clémence. Les tendances au fil du temps dans le graphique ci-dessous pourraient suggérer cette dernière solution. (La largeur de la ligne représente le nombre total d'infractions par an, ce qui montre clairement que nous ne disposons pas encore de suffisamment de données en 2020 pour nous fier à l'augmentation soudaine de cette année.)
Pour de nombreuses raisons possibles, notre modèle peut devenir moins précis avec le temps. Nous devrions réajuster périodiquement nos modèles d'analyse thématique et de forêt d'amorçage, en incorporant les données les plus récentes (et peut-être en supprimant les données plus anciennes) pour garantir que nos prédictions restent exactes.
