Fonction de coût pour valider les modèles de régression de Poisson

Pour les données de comptage que j'ai collectées, j'utilise la régression de Poisson pour construire des modèles. Je le fais en utilisant la glmfonction dans R, où j'utilise family = "poisson". Pour évaluer les modèles possibles (j'ai plusieurs prédicteurs) j'utilise l'AIC. Jusqu'ici tout va bien. Maintenant, je veux effectuer une validation croisée. J'ai déjà réussi à le faire en utilisant la cv.glmfonction du bootpackage. D'après la documentation de, cv.glmje vois que, par exemple, pour les données binomiales, vous devez utiliser une fonction de coût spécifique pour obtenir une erreur de prédiction significative. Cependant, je n'ai encore aucune idée de la fonction de coût appropriée family = poisson, et une recherche approfondie sur Google n'a donné aucun résultat spécifique. Ma question est de savoir si quelqu'un a de la lumière sur la fonction de coût appropriée cv.glmdans le cas de poisson glm.

En supposant qu'il n'y a rien de spécial dans votre cas particulier, je pense qu'il y a un bon argument pour utiliser la valeur par défaut (Mean Square Error) ou utiliser la moyenne de l'erreur des journaux, ou même l'erreur chi-carré.

Le but de la fonction de coût est d'exprimer à quel point vous êtes "bouleversé" par de fausses prédictions, en particulier ce qui vous dérange le plus. Ceci est particulièrement important pour les réponses binaires, mais peut être important dans n'importe quelle situation.

Erreur quadratique moyenne (des réponses)

$C = \frac{1}{n}\sum_i (Y_i-\hat Y_i)^2$

En utilisant le MSE, vous êtes également sensible aux erreurs d'en haut et d'en bas et également sensible aux prédictions grandes et petites. C'est une chose assez standard à faire, et donc je ne pense pas que ce serait mal vu dans la plupart des situations.

Erreur quadratique moyenne (des réponses du journal)

$C = \frac{1}{n}\sum_i (\ln Y_i-\ln \hat Y_i)^2$

Étant donné que vous travaillez avec des données de comptage, on pourrait affirmer que vous n'êtes pas symétrique ni indifférent à la taille. Être absent de 10 comptes pour une prédiction de 10 est très différent d'une prédiction de 1000. Il s'agit d'une fonction de coût quelque peu "canonique", car vous avez fait correspondre les coûts jusqu'à la fonction de liaison. Cela garantit que les coûts correspondent à la distribution de variance supposée dans le modèle.

Erreur chi carré

$C = \frac{1}{n}\sum_i \frac{(Y_i-\hat Y_i)^2}{\hat Y_i}$

Une troisième façon serait d'utiliser l'erreur du chi carré. Cela pourrait être particulièrement intéressant si vous comparez votre GLM à d'autres modèles basés sur le nombre - en particulier s'il existe des facteurs dans votre GLM. Semblable aux réponses du journal des erreurs, cela évoluera avec la taille, mais il est symétrique autour du nombre prévu. Vous évaluez maintenant la qualité de l'ajustement en fonction du pourcentage d'erreur.

Sur la discrétion

La question cite l'exemple de documentation où ils ont une variable de réponse binaire, utilisez donc une fonction de coût différente. Le problème pour une réponse binaire est que le GLM prévoit un nombre réel compris entre 0 et 1, même si la réponse est toujours exactement 0 ou 1. Il est parfaitement valable de dire que plus ce nombre est proche de la réponse correcte, meilleure est la prévisions, mais souvent, les gens ne veulent pas cela. Le raisonnement étant que l'on doit souvent agir comme si c'était 0 ou 1, et donc prendre tout ce qui est inférieur à 0,5 comme prévision pour 0. Dans ce cas, il est logique de simplement compter le nombre de "mauvaises" prévisions. L'argument ici est que pour une question Vrai / Faux, vous ne pouvez jamais avoir raison ou tort - il n'y a pas de gradation de l'erreur.

Dans votre cas, vous avez des données de comptage. Ici, il est beaucoup plus courant d'accepter des prédictions qui ne sont pas sur le même support que la réponse. Une prévision de 2,4 enfants par famille par exemple, soit 9,7 décès par an. Habituellement, on n'essaierait pas de faire quoi que ce soit à ce sujet, car il ne s'agit pas d'avoir «raison» ou «tort», aussi près que possible. Si vous devez vraiment avoir une prédiction qui est un entier, peut-être parce que vous avez un taux de comptage très très bas, alors il n'y a aucune raison que vous ne puissiez pas arrondir la prédiction en premier et compter le "nombre entier" ou l'erreur. Dans ce cas, les trois expressions ci-dessus s'appliquent toujours, mais vous devez simplement arrondir premier.$\hat Y$