Faire MCMC: utiliser jags / stan ou l'implémenter moi-même

Je suis nouveau dans la recherche sur les statistiques bayésiennes. J'ai entendu des chercheurs dire que les chercheurs bayésiens mettaient mieux en œuvre MCMC par eux-mêmes plutôt que d'utiliser des outils comme JAGS / Stan. Puis-je demander quel est l'avantage d'implémenter l'algorithme MCMC par soi-même (dans des langages "pas assez rapides" comme R), sauf à des fins d'apprentissage?

bayesian mcmc

— user112758
source

Parce qu'alors vous pouvez choisir vous-même votre propre distribution de propositions, vous devez la choisir de telle sorte que la chaîne de Markov qui en résulte converge aussi vite que possible vers la partie postérieure.

Merci! Est-ce la seule raison?

— user112758

Si vous êtes un chercheur appliqué qui veut en savoir plus sur Bayes en l'utilisant pour des applications, je recommanderais de commencer par JAGS ou Stan, puis de passer à l'écriture de votre propre MCMC si vous en avez besoin. Gardez à l'esprit que JAGS et Stan ont des forces et des limites légèrement différentes.

— conjugateprior

Merci! Oui, je fais de la recherche appliquée. Pourriez-vous m'en dire plus sur les limites de JAGS et Stan. J'ai d'abord essayé Stan, mais je viens de découvrir qu'il n'a pas de fonctionnalités ou de modules complémentaires de "surveillance en ligne" ou "d'échantillonnage jusqu'à la convergence" --- c'est ennuyeux, je peux essayer JAGS maintenant.

— user112758

Réponses:

En général, je suggérerais fortement de ne pas coder votre propre MCMC pour une véritable analyse bayésienne appliquée. C'est à la fois beaucoup de travail et de temps et très susceptible d'introduire des bogues dans le code. Les échantillonneurs Blackbox, tels que Stan, utilisent déjà des échantillonneurs très sophistiqués. Croyez-moi, vous ne coderez pas un échantillonneur de ce calibre pour une seule analyse!

Il y a des cas particuliers où cela ne sera pas suffisant. Par exemple, si vous deviez effectuer une analyse en temps réel (c'est-à-dire une décision informatique basée sur des données entrantes), ces programmes ne seraient pas une bonne idée. En effet, Stan nécessite la compilation de code C ++, ce qui peut prendre beaucoup plus de temps que l'exécution d'un échantillonneur déjà préparé pour des modèles relativement simples. Dans ce cas, vous souhaiterez peut-être écrire votre propre code. De plus, je pense qu'il y a des cas particuliers où des paquets comme Stan font très mal, comme les modèles d'espace d'état non gaussiens (divulgation complète: je crois que Stan fait mal dans ce cas, mais je ne sais pas). Dans ce cas, il peut être utile d'implémenter un MCMC personnalisé. Mais c'est l'exception, pas la règle!

Pour être tout à fait honnête, je pense que la plupart des chercheurs qui écrivent des échantillonneurs pour une seule analyse (et cela arrive, je l'ai vu) le font parce qu'ils aiment écrire leurs propres échantillonneurs. À tout le moins, je peux dire que je tombe dans cette catégorie (c'est-à-dire que je suis déçu que l'écriture de mon propre échantillonneur ne soit pas la meilleure façon de faire les choses).

De plus, même si cela n'a pas de sens d'écrire votre propre échantillonneur pour une seule analyse , il peut être très logique d'écrire votre propre code pour une classe d'analyses.. Étant donné que les JAG, Stan, etc. sont des échantillonneurs à boîte noire, vous pouvez toujours accélérer les choses en vous spécialisant pour un modèle donné, bien que le degré d'amélioration dépend du modèle. Mais écrire un échantillonneur extrêmement efficace à partir de zéro représente peut-être 10 à 1 000 heures de travail, selon l'expérience, la complexité du modèle, etc. Si vous faites des recherches sur les méthodes bayésiennes ou que vous écrivez des logiciels statistiques, c'est bien; c'est ton boulot. Mais si votre patron dit "Hé, pouvez-vous analyser cet ensemble de données de mesures répétées?" et que vous passez 250 heures à écrire un échantillonneur efficace, votre patron sera probablement contrarié. En revanche, vous auriez pu écrire ce modèle dans Stan en, disons, 2 heures et avoir eu 2 minutes de temps de fonctionnement au lieu du temps de 1 minute atteint par l'échantillonneur efficace.

— Cliff AB
source

+1. De plus, Stan ne gère pas directement certains problèmes impliquant des distributions discrètes, vous devez donc en savoir suffisamment pour les intégrer, ce qui n'est pas en soi simple, ce qui pourrait être un cas où le déploiement de la vôtre pourrait aider. Je crois que JAGS gère ces cas directement, donc si vous pouvez garder les philosophies différentes de BUGS / JAGS et Stan séparées dans votre esprit, il serait préférable de simplement basculer entre eux.

— Wayne

De plus, Stan peut avoir des problèmes où une métrique euclidienne diagonale n'est pas bien adaptée à la géométrie du postérieur; c'est le cas entre autres quand il n'y a qu'une région étroite et de forme bizarre de la partie postérieure qui a beaucoup de probabilité. Le résultat est qu'échantillonner le postérieur, c'est comme essayer de faire du vélo au bord d'une falaise: vous pourriez "tomber" si vous prenez un mauvais virage!

— Sycorax dit Réintégrer Monica le

+1. Ma recommandation générale aux étudiants est de le coder dans JAGS. Si cela ne fonctionne pas bien, codez-le dans Stan. Si cela ne fonctionne pas bien, commencez à écrire votre propre échantillonneur. Il existe également certains modèles, par exemple des modèles spatiaux, où vous pouvez utiliser des bogues. Et certains modèles, par exemple les modèles d'espace d'état non gaussiens, où vous souhaitez utiliser NIMBLE. Le coût d'opportunité de commencer par écrire votre propre échantillonneur est tout simplement trop élevé.

— jaradniemi

Je ne comprends pas le cas "en temps réel" - s'il est possible d'avoir un propre échantillonneur "déjà préparé", pourquoi n'est-il pas aussi facile d'utiliser un modèle Stan déjà compilé? Je me demande également si un MCMC est assez rapide pour des applications en temps réel.

— Juho Kokkala du

Et je ne connais pas suffisamment Stan pour savoir ce qui nécessite exactement la compilation de nouveaux modèles, mais il n'est pas trop difficile d'imaginer que quelle que soit la restriction, il existe un modèle dynamique tel que, à mesure que de nouvelles données arrivent, le modèle deviendrait plus complexe. et donc une recompilation serait nécessaire. Je pense que les méthodes non paramétriques (dans lesquelles l'espace des paramètres croît avec la taille de l'échantillon) répondraient à ces critères? Mais il peut y avoir des moyens intelligents de contourner cela.

— Cliff AB

Cette question est principalement basée sur l'opinion, mais je pense qu'il y en a assez ici, écrivez une réponse. Il pourrait y avoir de nombreuses raisons de coder son propre échantillonneur pour un problème de recherche. En voici quelques uns

Proposition: Comme le suggère fcop dans leur commentaire, si l'échantillon est MH, le codage de votre propre échantillonneur vous permet de jouer avec les distributions de proposition pour obtenir le meilleur échantillonneur de mixage.
Flexibilité: les programmes intégrés peuvent ne pas vous donner la flexibilité que vous souhaitez. Vous pouvez commencer par une valeur aléatoire spécifique ou utiliser une structure de départ spécifique.
Comprendre: coder votre propre échantillonneur vous aide à comprendre le comportement de l'échantillonneur, donnant un aperçu du processus de chaîne de Markov. Ceci est utile pour un chercheur travaillant sur le problème.
Fardeau de la preuve: si les données sur lesquelles je fais toute ma déduction bayésienne proviennent d'un programme que je n'ai pas codé, alors la responsabilité de la déduction ne m'appartient plus. En tant que chercheur, je voudrais assumer l'entière responsabilité des méthodes / résultats que je présente. L'utilisation de méthodes intégrées ne vous permet pas de le faire.

Il y a probablement plus de raisons, mais ce sont les quatre qui me font coder mes propres échantillonneurs.

— Greenparker
source

Je dirais que la raison de la "confiance" est contestable: Stan est open-source et a beaucoup de contributeurs, donc plusieurs personnes ont regardé son code source et il est donc peu probable qu'il comporte de sérieux bugs. D'un autre côté, si vous le faites par vous-même, vous pouvez toujours ignorer le bogue que vous avez fait - et tout le monde fait des bogues, c'est juste une question de nombre de lignes de code que vous écrivez ...

— Tim

@Tim, je suis d'accord. J'ai changé ce point pour refléter ce que j'essayais de dire. Merci.

— Greenparker

+1 pour l'argument Comprendre. Cependant, l'argument Onus semble un peu exagéré. Presque tout ce que vous codez vous-même dépendra du langage statistique de quelqu'un d'autre, de la bibliothèque d'algèbre linéaire, du générateur de nombres aléatoires, etc.

— conjugateprior

@conjugateprior Absolument d'accord. C'est pourquoi ma réponse a été à la première personne. C'était purement mon opinion.

— Greenparker

J'ai donné un +1 à la réponse de Cliff AB. Pour ajouter une petite friandise, si vous voulez travailler à un niveau inférieur mais pas au niveau du code tout-vous-même, vous devriez fouiller pour le package LaplacesDemon . L'auteur original était brillant, mais semble avoir disparu de la grille, et le paquet a été repris par quelqu'un d'autre. (C'est sur Github, je crois.)

Il implémente un nombre impressionnant d'algorithmes utilisés dans MCMC et les vignettes incluses valent la peine d'être lues même si vous n'utilisez pas le package. À peu près n'importe quel type d'échantillonneur que vous lisez, il l'a fait. Vous codez d'une manière différente de BUGS / JAGS ou Stan, et tout est en R, mais souvent c'est tellement efficace qu'il est compétitif.

— Wayne
source

Plug sans vergogne: vous pouvez également utiliser [nimble] (r-nimble.org) qui vous permet de personnaliser votre MCMC (c'est-à-dire d'utiliser un échantillonneur de tranches pour ce nœud, un programme de mise à jour de bloc pour ce groupe de nœuds, etc.) sans avoir à réécrire ce samplers à chaque fois. Et vous pouvez également écrire vos propres échantillonneurs à implémenter directement! Divulgation: je travaillais sur ce projet.

— Cliff AB

@CliffAB: Cela ressemble à LaplacesDemon, si vous êtes familier avec cela. Heureux d'en entendre parler nimbleégalement. Je vais au moins le télécharger. (Bien que les multiples vignettes de LaplacesDemon puissent valoir le coup d'être téléchargées même si vous utilisez Nimble.) ... Ohhh, je viens de visiter la page. Si son SMC est facile à utiliser, je deviendrai un grand fan. Le seul package R que j'ai vu qui utilise SMC est horriblement complexe.

— Wayne

@CliffAB: Wow, après avoir lu le nimblesite Web, c'est assez impressionnant. Pourquoi n'en ai-je jamais entendu parler? Cela ressemble à une excellente option pour les personnes habituées au langage de modélisation BUGS / JAGS. Bien sûr, ils feront les meilleures comparaisons possibles sur le site Web, mais je l'aime toujours jusqu'à présent. (Sauf qu'avec rstanarmet brms, qui utilisent Stan sous le capot, le champion de la facilité d'utilisation en R serait Stan.)

— Wayne

c'est encore très nouveau: la v0.1 est sortie je pense il y a un peu plus de 2 ans? Et SMC a été un énorme facteur de motivation pour le projet: le PI a fait de nombreuses publications sur les filtres à particules et était ennuyé de les écrire à partir de zéro à chaque fois. Mais j'ai été un peu avec le travail en cours pour suivre l'état actuel des échantillonneurs SMC; quand je suis parti (il y a près de deux ans), nous venions de mettre en place un très primitif.

— Cliff AB

Dites simplement ce papier arXiv qui pourrait vous intéresser.

— Cliff AB