New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
VI - Variational Inference support #498
Comments
For the first step (I know it is more complicated than this) One idea is to use InferenceData as is, but for VI results don't have chain dimension. Also mean and other statistics would go under one group (e.g. Then for VI specific plots, diagnostics and stats would be under ps. better names than those, please cc. @avehtari @dustinvtran @kyleabeauchamp @yaochitc @esennesh |
That's interesting. It is quite helpful to have vi support. |
|
What is the current status of ArviZ support for variational inference output? |
Is anybody currently working on this? I have an immediate need for this functionality (specifically for Stan output) that I'm going to write some custom code for but I'm happy to take a stab at a PR for general use later. cc @mortonjt |
Maybe a weird suggestion here, but my current thinking is that a good "standard data structure" for VI would be an object that supports, say, Given such an object and the That seems like a not very helpful response, so more concretely:
|
Is there a reason we need access to the sampling and log-density functionality of a VI model? e.g. when we need samples from a posterior represented by a PPL, we wrap an object from the PPL in a suitable We implicitly support such MC draws from posteriors right now, where the semantic distance between the methods used to obtain those draws is enforced by the function call. e.g. I guess what I'm asking is whether we will actually need the log-prob function or sample function of a VI method often enough to warrant creation of a new |
Thanks, @sethaxen -- well put! Maybe two issues I'm still stuck on are
Maybe more globally, I tend to think about using samples to approximate integrals as one approach, and am a little anxious to expand the scope of this project to (directly) include approximating families of distributions. I think your answer is more pragmatic, though, and if users of VI libraries would use |
Hi, I think @gibsramen and I were erring on the more practical approach. I agree @ColCarroll , the ideal approach is to have the actual function form serialized to disk (and keep track of all of the variational parameters). But from a short-term dev perspective, I'm not sure how practical this is, particularly for complex variational distributions. In the short-term, I think treating arviz objects as wrappers to samples from a posterior distribution is already extremely useful, enabling evaluation of many of the metrics provided in arviz. I can't immediately comment on the semantic distinction. From a user perspective, does it matter what algorithm generated the posterior samples? If so, then perhaps it is worthwhile to consider abstractions to provide a taxonomy for these use cases. |
To support VI we need to decide what different aspect we should implement.
Data structure
We probably need a special data structure for VI results.
It could contain:
Functions
Also, our current functions need to throw a warning/exception if the VI results try to use mcmc specific functions.
I think we don't need to support 100% of VI capabilities before starting.
Libraries
Libs we should support
Output from libs:
Stan (ADVI)
The text was updated successfully, but these errors were encountered: