Supondo que nada de especial no seu caso em particular, acho que há um bom argumento para usar o padrão (Mean Square Error) ou usar a média do erro dos logs ou mesmo o erro do qui-quadrado.
O objetivo da função de custo é expressar o quão "chateado" você está com previsões erradas, especificamente o que "errado" o incomoda mais. Isso é particularmente importante para respostas binárias, mas pode ser importante em qualquer situação.
Erro quadrado médio (de respostas)
C=1n∑i(Yi−Y^i)2
Usando o MSE, você é igualmente sensível a erros de cima e de baixo e igualmente sensível a previsões grandes e pequenas. Isso é uma coisa bastante padrão a se fazer e, portanto, não acho que seria desaprovado na maioria das situações.
Erro do quadrado médio (de respostas do log)
C=1n∑i(lnYi−lnY^i)2
Como você está trabalhando com dados de contagem, pode-se argumentar que você não é simétrico nem indiferente ao tamanho. Estar fora de 10 contagens para uma previsão de 10 é muito diferente de uma previsão de 1000. Essa é uma função de custo um tanto "canônica", porque você correspondeu os custos até a função de link. Isso garante que esses custos correspondam à distribuição de variação assumida no modelo.
Erro Qui-quadrado
C=1n∑i(Yi−Y^i)2Y^i
Uma terceira maneira seria usar o erro do qui-quadrado. Isso pode ser particularmente atraente se você estiver comparando seu GLM com outros modelos baseados em contagem - principalmente se houver fatores no seu GLM. Semelhante às respostas do log de erros, ele será dimensionado com o tamanho, mas é simétrico em torno da contagem prevista. Agora você está avaliando a qualidade do ajuste com base no erro percentual.
Sobre a discrição
A pergunta cita o exemplo da documentação em que eles têm uma variável de resposta binária, portanto, use uma função de custo diferente. O problema para uma resposta binária é que o GLM preverá um número real entre 0 e 1, mesmo que a resposta seja sempre exatamente 0 ou 1. É perfeitamente válido dizer que quanto mais próximo o número da resposta correta, melhor previsão, mas muitas vezes as pessoas não querem isso. O raciocínio é que muitas vezes é preciso agir como se fosse 0 ou 1 e, portanto, levará menos de 0,5 como uma previsão para 0. Nesse caso, faz sentido simplesmente contar o número de previsões "erradas". O argumento aqui é que, para uma pergunta Verdadeiro / Falso, você só pode estar certo ou errado - não há gradação de erro.
No seu caso, você tem dados de contagem. Aqui é muito mais comum aceitar previsões que não têm o mesmo suporte que a resposta. Uma previsão de 2,4 filhos por família, por exemplo, ou 9,7 mortes por ano. Normalmente, não se tenta fazer nada a respeito, porque não se trata de estar "certo" ou "errado", o mais próximo possível. Porém, se você realmente precisa ter uma previsão que seja um número inteiro, talvez porque tenha uma taxa de contagem muito muito baixa, não há motivo para não arredondar a previsão primeiro e contar o "número inteiro" ou o erro. Nesse caso, as três expressões acima ainda se aplicam, mas você simplesmente precisa arredondar primeiro.Y^
cv.glmnet
no pacoteglmnet
usatype.measure="deviance"
para a família Poisson.