Choosing between maximization & minimization with BoTorch acquisition functions

[AdrianSosic]

🚀 Feature Request

Hi, I've been running into the same question as already raised in #402. It seems the issue has been simply closed, without actually addressing the problem?

I'd love to understand:

• Why is the maximize argument only available for some of the acquisition function classes and not simply for all?
• Regarding the proposed alternative of going via an AcquisitionObjective: has this idea been dropped in the meantime? At least, I can't find anything that offers an easy user-facing functionality to accomplish it 🤔

Of course, I could come up with a manual workaround, e.g. using a posterior transform, but interface-wise I think this defeats the purpose. I'd rather expect that there should be a consistent way to trigger minimization that does not depend on the particular acquisition function class at hand. And having something simple like maximize=False that does not require setting up other objects seems like the ideal solution to me.

[saitcakmak]

Hi @AdrianSosic. The current acquisition functions that support this argument support it for legacy reasons. We do not believe adding maximize option to other acquisition functions justifies the maintenance work it requires. Please refer to my answer in #2316 for current options for minimization in BoTorch.

[saitcakmak]

For a self-contained discussion, here are the options for minimization (summarized from #2316):

• Negate the observations of the function that is being minimized, and maximize the negative of the function.
• For Gaussian posteriors, one can define a PosteriorTransform that negates the posterior mean.
• For MC acquisition functions, use an MCAcquisitionObjective (or MCMultiOutputObjective for MOO), such as a LinearMCObjective with negative weights, to negate the posterior samples.

[AdrianSosic]

Hi @saitcakmak, I wonder why I didn't find that issue myself 🤔 Anyway, thanks for the quick answer 👍🏼

I understand your point that there are alternatives available (which are exactly the options I would have used for my workaround), and of course I (have to) accept that you are not planning to add the maximize flag. However, I also have to say that I don't consider the listed options to be real alternatives (in terms of usability) and I also don't find the argument against the maximize flag very convincing. I'm sure you've already thought about this, but I thought I'd just share my view here and you can take from it whatever you consider useful:

• Why I don't find the argument of unjustified maintenance work convincing: Either, the solutions offered by the alternatives are easy / trivial to implement (which is basically what you imply if you sell them as "alternatives"). If that's the case, then also implementing the maximize flag, which then applies these alternatives behind the scenes hidden from the user, should be minimal work, i.e. there would be no "maintenance burden". Or, the alternatives are not so straightforward as you make it sound and some nontrivial code logic needs to be maintained. But if that's the case, then it's clear that the options are not real alternatives to the maximize flag, and the workload implenting those should not be imposed on the user.
• Negating the observations of the functions is not a real alternative to me. It comes with side-effects, for instance, the constructed surrogate model will then also be inverted, and if you want to use its predictions, you need to invert its output again in a nontrivial way (using posterior transforms etc). So basically you are only delaying the point where more heavy machinery becomes necessary.
• If I ignore the "negation" option for the above explained reason, what remains is not a single solution that can be applied to all cases but rather a set of alternatives that need to be selected case by case (i.e., for Gaussian posteriors, I need to apply a posterior transform, for non-Gaussian MC acqfs, a different strategy is required ...). That basically brings us to a situation where every user will need to implement the same kind of switching logic, just to get minimization running (<-- this is what I'll have to do now in my code base, unfortunately 😢)
• The fact that I'm already the third person or so opening the same issue shows that people keep running into the same problem and that the interface is not very clear. The typical sequence of events is that a user will start with simple acquisition functions like EI, set up their workflow, eventually switch to more complex functions, and then suddenly get the error that there is no maximize flag, which is the point where people will be surprised and start wondering.

Perhaps some of this can convince you of the benefits 🙃 In the meantime, I'll start working on my manual workaround

[saitcakmak]

Hi @AdrianSosic. You do have some valid points there but I still don't believe that the value add justifies the cost. I'll not go into this here but the cost of adding a feature goes much beyond the effort required for implementing it initially.

I also don't believe maximize is the right kwarg to support broadly. It works for single objective, but how about multi-objective or scalarized objectives? Do we need to support a separate maximize kwarg for each objective? The acquisition objective can handle both of these use cases.

In the end, this boils down to the design philosophy of Ax & BoTorch. BoTorch is a library that offers a series of BO components that an advanced user is responsible for putting together to serve their needs. It is mainly intended for a researcher audience where flexibility is key. For e2e experiments, where the convenience of experiment setup is a lot more important, we recommend using Ax. In Ax, the appropriate BoTorch components will be created under the hood, and you can specify whether an objective should be maximized or minimized while setting up the experiment. It will also handle many BoTorch best practices by default and try to deliver the best performance (we're actively working on improving our defaults). We also have tutorials demonstrating how to use custom BoTorch model or acquisition function in Ax.

[AdrianSosic]

Hi @saitcakmak, one quick follow-up:

I understand your argument that maximize is maybe not the right way in all possible contexts. I wonder, though, if making it at least a standard way for AnalyticAcquisitionFunction would improve the user interface. As far as I can see, all AnalyticAcquisitionFunctions except the ScalarizedPosteriorMean accept the keyword. And the latter could also easily accept it but the current suggested way is to negate the passed weights. This has the consequence that maximize cannot be exposed via the base class, even though all its subclasses effectively support the corresponding operation.

Adding the keyword to ScalarizedPosteriorMean would allow to cleanly expose the option also in the base class, and it wouldn't harm having it as an option to ScalarizedPosteriorMean, where the implementation is really trivial. Overall, this would give rounder interface to the user. What do you think?