objective for qNegIntegratedPosteriorVariance

[AdrianSosic]

Hi, I wonder: is there a reason why qNegIntegratedPosteriorVariance does not accept an objective argument?

[Balandat]

qNegIntegratedPosteriorVariance is aimed about reducing uncertainty in the outcome(s) globally. But I guess if you had an "objective" transforming the outcomes you could minimize the variance of that. qNegIntegratedPosteriorVariance accepts a PosteriorTransform that you should be able to do use for this purpose:
https://github.com/pytorch/botorch/blob/4632c36bf6f74387b9a7064c2ce491a5a3d22f95/botorch/acquisition/active_learning.py#L55

This would have to return a transformed posterior, with that the variance computation here should do the right thing*: https://github.com/pytorch/botorch/blob/4632c36bf6f74387b9a7064c2ce491a5a3d22f95/botorch/acquisition/active_learning.py#L113-L117

*However, looking at the code there seems to be some implicit assumption that if a PosteriorTransform is provided the model should be multi-objective, which is probably not what we want, so we may need to fix that:
https://github.com/pytorch/botorch/blob/4632c36bf6f74387b9a7064c2ce491a5a3d22f95/botorch/acquisition/active_learning.py#L119-L124

To implement a generic transform, you probably just want to define a custom PosteriorTransform class. If you want to pass a generic objective function you could have that take that in and then return a TransformedPosterior: https://github.com/pytorch/botorch/blob/4632c36bf6f74387b9a7064c2ce491a5a3d22f95/botorch/posteriors/transformed.py#L16

Hope this helps, let me know how it goes.

[AdrianSosic]

Hi @Balandat, thanks for the quick reply. What you wrote pretty much summarized my own thoughts so far (I also saw the alternative to use a custom posterior transform). While this might work, the context of my request is actually a bit broader. I'm currently extending our own botorch wrapper with a more flexible transform interface, which is why I'm going through the different available options in BoTorch. Here are a few things I stumbled over:

1. Yes, qNIPV is about global variance reduction but (as far as I know) there's nothing in that criterion that requires Gaussianity. So, as you mentioned, wouldn't it make sense to use the existing machinery to also enable the objective channel for it?
2. Apart from the "why not do it" part above, there is also a design issue that bothers me a little: to me, it seems that qNIPV is sort of an exception to the rule. In my code, I could basically easily get along with all acquisition functions using a logic like is_analytic -> use posterior_transform and otherwise -> use objective. However, because qNIPV does not accept an objective it's the only acquisition function I've encountered so far for which I need to devise custom logic a la if isinstance(acqf, qNIPV), which to me indicates that the interface is incomplete.
3. I have seen this conversation here about the difference between objectives and posterior transforms, and I understand the part about sampling. However, when I use a PosteriorTransform that produces a TransformedPosterior (as you suggested above) that is purely sample-based, i.e. where the optional mean_transform and variance_transform arguments are omitted, how is that conceptually different from an objective at all? 🤔

Curious to hear your thoughts!

[Balandat]

I could basically easily get along with all acquisition functions using a logic like is_analytic -> use posterior_transform and otherwise -> use objective

So qNegIntegratedPosteriorVariance is kind of an interesting case. While the integration of the variance is done via (q)MC, the computation of the posterior itself is analytic. The Objective setup generally operates on samples from the posterior, but here we don't need those samples b/c we have the quantities we need (variances) in analytic form (at least we do for unit or affine objectives).

One could use an Objective and then leverage that to MC-compute the posterior variances at each point as well, but that would mean - assuming we don't want to do that for the analytic case - that we'd have to have some branching logic in the acquisition function logic that does different things whether an objective is provided or not. I guess that is possible but it's also no the cleanest setup and would also differ from all the other acquisition functions. In the current implementation, we can leverage the existing PosteriorTransform setup to achieve this without branching logic in the acquisition function.

I am not necessarily saying this is a better design. I'd be happy to consider changing this setup if someone wanted to take a stab at redesigning this.

[AdrianSosic]

Hi @Balandat, thank you again for taking the time to answer 🏆

I can follow your argument and understand your point about the branching, but I think it somewhat compares apples to oranges because the considered scope is a different one. What I mean is that the "branching" you're describing in fact also exists for the other acquisition functions, just not in the form of an "if" statement but in form of different subclasses.

You see, when I compare the existing qNIPV class to, say, expected improvement, it is actually much more like regular EI than qEI, despite having the q in the name because – as you said – it relies on an analytic posterior and is thus limited to affine transformations. But for non-affine transformations we have qEI, while there is no corresponding counterpart for qNIPV – which in a sense would be a "double-q" qqNIPV if you know what I mean 😄

So I could rephrase my argument/request by saying there is no qNIPV version for non-affine transformations. I'll leave it to you to interpret if this now means that an corresponding class or an internal branching statement is missing. All I'm saying is that I can take your we don't need those samples argument and add to it: yes, like in regular EI, but not for arbitrary transformations, for which you've already added qEI.

I hope it's understandable what I mean 🙃

[Balandat]

Yeah, I see what you're saying. I'd be willing to review a PR that adds an objective arg to qNegIntegratedPosteriorVariance and does the proper MC estimation of the variance. This will require some care similar to how the MC samplers are used in the other acquisition functions when sampling from the posterior though.

[AdrianSosic]

Great 👍 I'm currently OOO but will try to implement it next week