-
Notifications
You must be signed in to change notification settings - Fork 346
Description
In Section S.3.B of:
Hickman, R. J.; Aldeghi, M.; Häse, F.; Aspuru-Guzik, A. Bayesian Optimization with Known Experimental and Design Constraints for Chemistry Applications. arXiv:2203.17241 [cond-mat] 2022. https://dx.doi.org/10.48550/arXiv.2203.17241
they performed a multi-objective optimization with one objective as a black box and another objective (cost) that is analytically calculated, but that I think was also represented as a black box. A quick search led me to:
Olofsson, S.; Mehrian, M.; Calandra, R.; Geris, L.; Deisenroth, M. P.; Misener, R. Bayesian Multiobjective Optimisation With Mixed Analytical and Black-Box Functions: Application to Tissue Engineering. IEEE Trans. Biomed. Eng. 2019, 66 (3), 727–739. https://doi.org/10.1109/TBME.2018.2855404.
where they rederived a few multi-objective acquisition functions to consider one black box objective and one analytic objective.
This topic is related to #745, except that the analytic objective is actually an objective to be optimized rather than a non-linear constraint on the input parameters. This idea of mixed analytical and black box functions is pretty common in the physical sciences, where one seeks a tradeoff between increasing (often several) difficult-to-model performance metrics and lowering monetary cost. Monetary cost as part of a multi-objective optimization is something that's been on my mind, and now I am realizing some of the difficulties of efficiently implementing it.
I've considered a few things:
- (Inefficiently) treat the analytic objective as a black-box model. Quoting @Balandat "why do we learn the constraint if we already know it in closed form?"
- Use ModelListGP with "enough" noise-free training data to sufficiently learn the (often linear) analytic monetary cost function, which may actually be easy in some cases, but the comment directly above still applies here
- Try to use/adapt the acquisition function from https://doi.org/10.1109/TBME.2018.2855404
- EDIT: treat it as a constraint on the input parameters with an unrealistically high bound (I'm not sure if the soft constraint penalty gets larger as the constraint violation worsens, and I think it's possible this could completely throw off the candidate generation - not really sure)
Any thoughts/suggestions?