Por que existem recomendações contra o uso de Jeffreys ou anteriores baseados em entropia para os amostradores MCMC?

Em sua página wiki , os desenvolvedores do estado de Stan:

Alguns princípios que não gostamos: invariância, Jeffreys, entropia

Em vez disso, vejo muitas recomendações de distribuição normal. Até agora, usei métodos bayesianos que não dependiam de amostragem e fiquei feliz por ter entendido por que foi uma boa opção para as probabilidades binomiais.$\theta \sim \text{Beta}\left(\alpha=\frac{1}{2},\beta=\frac{1}{2}\right)$

É claro que este é um conjunto diversificado de pessoas com uma série de opiniões se reunindo e escrevendo um wiki. Resumo eu sei / entendo com alguns comentários:

• Escolher o seu anterior com base na conveniência computacional é uma justificativa insuficiente. Por exemplo, usar uma versão beta (1/2, 1/2) apenas porque permite atualização conjugada não é uma boa ideia. Obviamente, depois de concluir que ele possui boas propriedades para o tipo de problema em que você trabalha, tudo bem e você também pode fazer uma escolha que facilita a implementação. Existem muitos exemplos em que escolhas padrão convenientes acabam sendo problemáticas (consulte Gamna (0,001, 0,001) antes que permita a amostragem de Gibbs).

• Com o Stan - diferentemente do WinBUGS ou JAGS -, não há nenhuma vantagem particular em conjugar (condicionalmente) os anteriores. Portanto, você pode ignorar um pouco o aspecto computacional. Porém, não inteiramente, porque com antecedentes com cauda muito pesados ​​(ou antecedentes impróprios) e dados que não identificam bem os parâmetros, você encontra problemas (não é realmente um problema específico de Stan, mas Stan é muito bom em identificar esses problemas e avisar o usuário). em vez de amostrar alegremente).

• Às vezes, Jeffreys e outros antecedentes de "pouca informação" podem ser impróprios ou difíceis de entender em grandes dimensões (não importa derivá-los) e com dados esparsos. Pode ser que isso tenha causado problemas demais para os autores nunca se sentirem confortáveis ​​com eles. Depois de trabalhar em algo, você aprende mais e se sente confortável, daí a inversão ocasional de opinião.

• Na configuração de dados esparsos, o anterior realmente importa e se você pode especificar que valores totalmente implausíveis para um parâmetro são implausíveis, isso ajuda muito. Isso motiva a ideia de priors fracamente informativos - não de anteriores verdadeiramente informativos, mas com mais apoio a valores plausíveis.

• De fato, você pode se perguntar por que alguém se incomoda com os anteriores não informativos, se temos muitos dados que identificam os parâmetros muito bem (pode-se usar a máxima probabilidade). É claro que existem muitas razões (evitando patologias, obtendo a "forma real" dos posteriores etc.), mas em situações de "abundância de dados" parece não haver argumento real contra priores fracamente informativos.

• Talvez um pouco estranhamente um N (0, 1) seja um precedente surpreendentemente decente para coeficiente em regressão logística, Poisson ou Cox para muitas aplicações. Por exemplo, isso é muito aproximadamente a distribuição dos efeitos do tratamento observados em muitos ensaios clínicos.

Eles não fornecem nenhuma justificativa científica / matemática para isso. A maioria dos desenvolvedores não trabalha com esse tipo de anteriores e prefere usar anteriores mais pragmáticos / heurísticos, como anteriores normais com grandes variações (o que pode ser informativo em alguns casos). No entanto, é um pouco estranho que eles estejam felizes em usar as versões anteriores do PC, que são baseadas na Entropia (divergência de KL), depois que começaram a trabalhar neste tópico.

Um fenômeno semelhante aconteceu com o WinBUGS , quando os desenvolvedores recomendaram o como um não informativo para parâmetros de precisão, pois se assemelha à forma do Jeffreys anterior. Esse prior tornou-se o anterior padrão para os parâmetros de precisão. Mais tarde, foi demonstrado ( por Gelman! ) Que eles podem ser altamente informativos.$Gamma(0.001,0.001)$