Fazendo o MCMC: use jags / stan ou implemente-o eu mesmo


13

Eu sou novo na pesquisa estatística bayesiana. Ouvi de pesquisadores que pesquisadores bayesianos implementam melhor o MCMC por eles mesmos do que usando ferramentas como JAGS / Stan. Posso perguntar qual é o benefício de implementar o algoritmo MCMC por si mesmo (em linguagens "não muito rápidas" como R), exceto para fins de aprendizado?


Como você mesmo pode escolher sua própria distribuição de proposta, escolha-a de modo que a Cadeia de Markov resultante dela converja o mais rápido possível para a posterior.

obrigado! É a única razão?
user112758

4
Se você é um pesquisador aplicado que deseja aprender mais Bayes usando-o para aplicativos, recomendo começar com JAGS ou Stan e, em seguida, passar a escrever seu próprio MCMC, se achar necessário. Lembre-se de que JAGS e Stan têm pontos fortes e limitações ligeiramente diferentes.
conjugateprior

obrigado! Sim, estou fazendo pesquisa aplicada. Você poderia me falar mais sobre as limitações do JAGS e Stan. Eu tentei o Stan pela primeira vez, mas acabei de descobrir que ele não possui recursos ou complementos de "monitoramento on-line" ou "amostra até convergir" - isso é irritante, posso tentar o JAGS agora.
user112758

Respostas:


26

Em geral, eu sugeriria fortemente não codificar seu próprio MCMC para uma análise bayesiana aplicada real. Isso é bastante trabalho e tempo e é muito provável que introduza bugs no código. Os samplers de caixa preta, como o Stan, já usam samplers muito sofisticados. Confie em mim, você não codificará um amostrador desse calibre apenas para uma análise!

Existem casos especiais em que isso não será suficiente. Por exemplo, se você precisasse fazer uma análise em tempo real (por exemplo, decisão do computador com base nos dados recebidos), esses programas não seriam uma boa ideia. Isso ocorre porque o Stan exige a compilação do código C ++, que pode levar consideravelmente mais tempo do que apenas a execução de um amostrador já preparado para modelos relativamente simples. Nesse caso, você pode escrever seu próprio código. Além disso, acredito que há casos especiais em que pacotes como Stan se saem muito mal, como os modelos de espaço de estados não gaussianos (divulgação completa: acredito que Stan se sai mal nesse caso, mas não sabe). Nesse caso, pode valer a pena implementar um MCMC customizado. Mas esta é a exceção, não a regra!

Para ser sincero, acho que a maioria dos pesquisadores que escrevem amostradores para uma única análise (e isso acontece, eu já vi) o faz porque eles gostam de escrever seus próprios amostradores. No mínimo, posso dizer que me enquadro nessa categoria (ou seja, estou decepcionado que escrever meu próprio amostrador não seja a melhor maneira de fazer as coisas).

Além disso, embora não faça sentido escrever seu próprio amostrador para uma única análise , pode fazer muito sentido escrever seu próprio código para uma classe de análises. Como os JAGs, Stan etc. são amostradores de caixa preta, você sempre pode acelerar as coisas se especializando em um determinado modelo, embora a quantidade de aprimoramento dependa do modelo. Mas escrever um amostrador extremamente eficiente desde o início é talvez de 10 a 1.000 horas de trabalho, dependendo da experiência, da complexidade do modelo etc. Se você está pesquisando métodos Bayesianos ou escrevendo software estatístico, tudo bem; é o seu trabalho. Mas se o seu chefe disser "Ei, você pode analisar esse conjunto de dados de medidas repetidas?" e você gasta 250 horas escrevendo um amostrador eficiente, é provável que seu chefe fique chateado. Por outro lado, você poderia escrever esse modelo em Stan em, digamos, 2 horas e ter 2 minutos de tempo de execução em vez do tempo de execução de 1 minuto alcançado pelo amostrador eficiente.


3
+1. Além disso, Stan não lida diretamente com alguns problemas que envolvem distribuições discretas; portanto, você precisa saber o suficiente para integrá-las, o que não é, por si só, simples; portanto, pode ser um caso em que a rolagem de suas próprias informações possa ajudar. Porém, acredito que o JAGS lida com esses casos diretamente, portanto, se você puder manter as diferentes filosofias de BUGS / JAGS e Stan em sua mente, seria melhor alternar entre elas.
Wayne

Além disso, Stan pode ter problemas em que uma métrica euclidiana diagonal não é adequada à geometria do posterior; este é o caso, inter alia, quando existe apenas uma região estreita e de formato estranho do posterior, que tem muita probabilidade. O resultado é que experimentar a parte posterior é como tentar andar de bicicleta ao longo de um precipício: você pode "cair" se fizer uma curva errada!
Sycorax diz Restabelecer Monica

2
+1. Minha recomendação geral para os alunos é codificá-lo no JAGS. Se isso não funcionar bem, codifique-o em Stan. Se isso não funcionar bem, comece a escrever seu próprio amostrador. Existem também alguns modelos, por exemplo, modelos espaciais, nos quais você pode usar os BUGS. E certos modelos, por exemplo, modelos de espaço de estados não gaussianos, nos quais você deseja usar o NIMBLE. O custo de oportunidade de começar escrevendo seu próprio amostrador é muito alto.
jaradniemi

Não entendo o caso "em tempo real" - se é possível ter um amostrador "já preparado", por que não é tão fácil usar um modelo Stan já compilado? Também me pergunto se algum MCMC é rápido o suficiente para aplicativos em tempo real.
Juho Kokkala

1
E eu não estou familiarizado o suficiente com Stan para saber o que exatamente exige a compilação de novos modelos, mas não é difícil imaginar que seja qual for a restrição, existe um modelo dinâmico que, à medida que novos dados são recebidos, o modelo se torna mais complexo e assim seria necessário recompilar. Eu acho que métodos não paramétricos (em que o espaço do parâmetro cresce com o tamanho da amostra) se encaixariam nesse critério? Mas pode haver maneiras inteligentes de contornar isso.
Cliff AB

6

Esta questão é primariamente baseada em opiniões, mas acho que há o suficiente aqui. Escreva uma resposta. Pode haver muitas razões para codificar o amostrador de uma pessoa para um problema de pesquisa. Aqui estão alguns deles

  1. Proposta: como o fcop sugeriu em seu comentário, se a amostra for MH, codificar seu próprio amostrador permite que você brinque com as distribuições de propostas para obter o melhor amostrador de mixagem.

  2. Flexibilidade: Em programas criados, pode não dar a flexibilidade que você deseja. Você pode querer começar com um valor aleatório específico ou usar uma estrutura de semente específica.

  3. Compreensão: codificar seu próprio amostrador ajuda a entender o comportamento do amostrador, fornecendo informações para o processo da cadeia de Markov. Isso é útil para um pesquisador que trabalha no problema.

  4. Ônus: se os dados nos quais estou fazendo toda a minha inferência bayesiana vierem de um programa que não codifiquei, o ônus da inferência não estará mais em mim. Como pesquisador, gostaria de assumir total responsabilidade dos métodos / resultados que apresento. O uso de métodos embutidos não permite que você faça isso.

Provavelmente há mais razões, mas estas são as quatro que me fazem codificar meus próprios samplers.


6
Eu diria que o motivo da "confiança" é discutível: Stan é de código aberto e tem muitos contribuidores; portanto, várias pessoas consultaram seu código-fonte e, portanto, é improvável que haja erros sérios. Por outro lado, se você fizer isso sozinho, sempre poderá ignorar o erro que criou - e todo mundo comete erros; é apenas uma questão de número de linhas de código que você escreve ...
Tim

@ Tim eu concordo. Mudei esse ponto para refletir o que estava tentando dizer. Obrigado.
Greenparker

5
+1 para o argumento de entendimento. No entanto, o argumento Onus parece um pouco exagerado. Quase tudo o que você codifica dependerá da linguagem estatística de outra pessoa, biblioteca de álgebra linear, gerador de números aleatórios etc. etc.
conjugateprior

@conjugateprior Absolutamente de acordo. É por isso que minha resposta foi na primeira pessoa. Esta foi puramente a minha opinião.
Greenparker

4

Eu dei um +1 à resposta de Cliff AB. Para adicionar um pequeno detalhe, se você deseja trabalhar em um nível mais baixo, mas não no nível do código-tudo-você-mesmo, você deve procurar o pacote LaplacesDemon . O autor original foi brilhante, mas parece ter caído da grade, e o pacote foi adquirido por outra pessoa. (É no Github, eu acredito.)

Ele implementa um número impressionante de algoritmos usados ​​no MCMC e as vinhetas incluídas valem a leitura, mesmo que você não use o pacote. Praticamente qualquer tipo de amostrador sobre o qual você leu. Você codifica de uma maneira diferente de BUGS / JAGS ou Stan, e está tudo em R, mas muitas vezes é tão eficiente que é competitivo.


1
Plugue sem vergonha: você também pode usar [nimble] (r-nimble.org) que permite personalizar seu MCMC (por exemplo, usar um classificador de fatia para esse nó, atualizar o bloco para esse grupo de nós etc.) sem a necessidade de reescrever este amostradores sempre. E você também pode escrever seus próprios samplers para serem implementados diretamente! Divulgação: Eu costumava trabalhar neste projeto.
Cliff AB

@CliffAB: Parece semelhante LaplacesDemon, se você estiver familiarizado com isso. Fico feliz em ouvir sobre nimbletambém. Vou pelo menos fazer o download. (Embora as várias vinhetas do LaplacesDemon possam valer o download, mesmo que você use o ágil.) ... Ohhh, acabei de acessar a página. Se o SMC for fácil de usar, vou me tornar um grande fã. O único pacote R que vi que faz o SMC é terrivelmente complexo.
Wayne

@CliffAB: Uau, depois de ler o nimblesite, é bastante impressionante. Por que nunca ouvi falar disso? Parece uma ótima opção para pessoas acostumadas à linguagem de modelagem BUGS / JAGS. Obviamente, eles farão as melhores comparações possíveis no site, mas ainda gosto até agora. (Excepto que com rstanarme brms, que utilizam Stan sob o capuz, o campeão facilidade de uso-em-R seria Stan.)
Wayne

ainda é muito novo: a v0.1 foi lançada, acho que há mais de 2 anos? E a SMC foi um grande motivador para o projeto: o PI publicou consideravelmente em filtros de partículas e ficou aborrecido ao escrevê-las do zero todas as vezes. Mas estive um pouco com o trabalho atual para acompanhar o estado atual dos amostradores SMC; quando saí (quase dois anos atrás), tínhamos acabado de montar uma muito primitiva.
Cliff AB

1
Basta dizer este papel arXiv que você pode estar interessado em.
Cliff AB
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.