Ax: What happens to subsequent trials when an output constraint(s) is not satisfied?

[jangkj09]

With Service API, the function I am optimizing returns two metrics (e.g. m1 and m2), and I have defined one as the objective (m1) and placed an output constraint on the other (m2 <= x).
During the trials, if the output constraint is not satisfied, how is this recorded and how is this information used in a subsequent trial?
Is this information taken into consideration when sampling the next arm?

[lena-kashtelyan]

~Please clarify what you mean by: "During the trials, if the output constraint is not satisfied"~

~You shouldn't be getting trials that don't satisfy the constraints. Are you? If so, please include code snippet of how you set up your experiment and what trials you are seeing.~

Update: I see, I misunderstood your question. You are asking what happens if a trial ends up not satisfying an outcome constraint after evaluation. I believe that the answer is that that information is used to produce future trials that are more likely to satisfy the outcome constraint and that the trial that did not satisfy it will never be considered 'best' on the experiment.

cc @qingfeng10 if she wants to add anything re: methodology of taking into account trials that did not satisfy outcome constraints.

[jangkj09]

Thanks, this clarifies a lot.
Just two more things:

1. The way I have it set up, when the output constraint is not satisfied the other metric (the objective, i.e. m1) defaults to 0. will the model to generate future values use that value of 0?

1. I just want to understand it in more detail, but is there any reference for the mechanism which tries to ensure that future trials will be produced which satisfy the outcome?

[qingfeng10]

Re: taking into account trails that do not satisfy constraints / or trails that satisfy constraints but objective values are not great

In each trial, the method takes data from all the past trails and builds GP model to capture the relationship between metrics and your tuning parameters. Therefore, although some trials are not great in terms of optimization goal, they help to learn the relationship so the optimization can avoid the bad region.

Method-wise, it's based on bayesian optimization (https://ax.dev/docs/bayesopt.html) As we are getting more trials, you will converge to a global optimal. If your outcome constraint is feasible, the best trial from running the Service API will satisfy the outcome with best objective.

[lena-kashtelyan]

The way I have it set up, when the output constraint is satisfied the other metric (the objective, i.e. m1) defaults to 0. will the model to generate future values use that value of 0?

Did you meant "when the output constraint is not satisied"? I'm not sure I understand what you are asking.

[jangkj09]

Right, it should be "when the output constraint is not satisfied".

@qingfeng10 I understand that this is Bayesian optimization, but I suppose Ax is taking the outcome constraints and transforming it into some constrained form of BO
I was wondering how this is being implemented (e.g. if it's calling BoTorch, then how is it calling it?) and if there is an example of customizing this part?

[lena-kashtelyan]

Then re: constraints, @qingfeng10's answer should hopefully help. There is more information at botorch.org, also.

We have some documentation on specific type of BayesOpt we use here. Also, here is a tutorial for setting up a custom BoTorch model in Ax, and you can read through the BotorchModel and botorch_defaults.py to see how Ax calls BoTorch. #293 and #363 might also be of interest to you –– as discussed in those, the process of setting up a custom BoTorch model is Ax is fairly cumbersome, but will soon be simplified with some work currently underway.

Feel free to reopen the issue or start a new one if you have more question!