BayBE: A Bayesian Back End for Design of Experiments in Python

The problem BayBE is built around

Most Python optimization libraries assume you can call a function. Give it a vector, get a number back, repeat a few hundred times. BayBE assumes the opposite. Its README frames the target as finding good parameter configurations within complex parameter search spaces, and the examples it lists are chemical reaction conditions, materials and formulations, 3D shape optimization, virtual simulations, model hyperparameters, and espresso machine settings. Every one of those is a case where an evaluation is expensive, sometimes manual, and often arrives after a delay. You cannot run a thousand evaluations overnight, and you may not be able to run two at once. The library's stated goal is a general-purpose toolbox for Bayesian Design of Experiments that makes the procedure accessible for real-world experiments. The audience is therefore experimentalists and process engineers who write Python, plus the data scientists supporting them, rather than the machine learning practitioner looking for a drop-in optimizer.

Search spaces as first-class objects, not arrays

The central design decision in BayBE is that the search space is described declaratively instead of being implied by a NumPy array or a scikit-learn search space. The README points to a hybrid search space that mixes continuous and discrete parameters in one campaign, and to a constraints component used to exclude undesired or impossible configurations, with a maximal number of mixture components given as the example. That matters more than it sounds. In a formulation problem, the constraint that components must sum to a fixed total is not something you can express by clamping a vector after the fact, because clamping moves you off the constraint. BayBE also documents a CustomDiscreteParameter for capturing relationships between categories through custom encodings, and a SubstanceParameter with built-in chemical encodings for chemistry-related parameters. Those two are the clearest sign of who the library is for: a generic optimizer would treat a solvent name as an arbitrary label, while BayBE lets you supply a representation that reflects chemical similarity. The trade-off is that you must learn the parameter taxonomy before you can describe your problem, and a search space you describe badly will produce recommendations that look reasonable and are not.

Objectives, surrogate models and the campaign loop

The objective layer separates the raw measurement from the thing being optimized. The README documents target transformations for specifying a desired target value, and multiple-target handling through Pareto optimization or desirability scalarization. Those are different answers to a common situation: you care about yield and purity, or about strength and cost, and you do not want to collapse them into one number by hand. Pareto keeps a set of non-dominated candidates; desirability scalarization folds them into a single score. The surrogate layer is where the Bayesian part lives, and the README notes that custom surrogate models can be registered to inject mechanistic process understanding. That is a real capability and also a real burden, since a custom surrogate has to be correct enough for the acquisition step to trust it. Transfer learning is documented as a way to use data from similar campaigns to accelerate optimization, which is the feature most likely to be misused: it only helps if the previous campaign is genuinely similar in parameterization, not merely in topic.

Getting a campaign running

The README advertises serialization as the mechanism for storing BayBE objects and using API wrappers, and an asynchronous workflow for campaigns with partial measurements and pending experiments. Those two together define the deployment shape. A campaign is not a loop in a script; it is an object that persists between measurement rounds, is asked for recommendations, and is later updated with the results that have come back. The asynchronous concept page is the one to read if your experiments run in parallel or take days, because the recommendation logic has to account for experiments that are underway but not yet measured. The README also points to an active learning concept for acquiring training data for model building, and to bandit models for AB testing, which are separate modes from straightforward optimization. The documentation site, the API reference and the contributing guide are the three links given at the top of the README. I have not run any of this, so I am not going to print a command sequence that I cannot trace to the material; the concrete entry points are in the documentation site and the API reference rather than in the README body.

Where BayBE is the wrong tool

The clearest limitation is structural. BayBE is a back end for design of experiments, and the README's own framing is about campaigns that balance exploitation of known-good regions against exploration of unknown ones. If your evaluation is cheap and fast, that balance is wasted effort. A grid search, a random search, or a plain scikit-learn optimizer will get you an answer with far less setup, because you do not have to declare a search space, choose a surrogate, pick an acquisition strategy and manage a campaign object. The second limitation is operational. Serialization and the asynchronous workflow are documented as features, which implies that campaigns have state worth persisting and that concurrency is a supported mode. Both add moving parts. A team that runs one experiment at a time and keeps results in a spreadsheet will get no benefit from either. The third is that the feature list is broad: active learning, bandits, Pareto and desirability objectives, transfer learning, custom surrogates, chemical encodings. Breadth here means decisions. Nothing in the README tells you which acquisition strategy to choose for a given problem, and choosing badly is a silent failure, since you still get recommendations, just worse ones.

How it differs from a general-purpose optimizer

The natural comparison is scikit-optimize, or any of the Bayesian optimization libraries that expose a minimize function taking an objective callable. The difference is not the underlying mathematics, which is Bayesian optimization in both cases. It is where the domain knowledge is allowed to live. In a minimize-style library, the search space is a list of dimensions and any structure beyond that has to be encoded into the objective function or the bounds. In BayBE, the structure is declared up front: constraints that exclude impossible configurations, custom encodings for categorical parameters, chemical encodings for substance parameters, custom surrogates that carry mechanistic understanding. That is a better fit for a chemist describing a formulation and a worse fit for someone who just wants the minimum of a function they can call. The second difference is the unit of work. A minimize-style library optimizes a function; BayBE runs a campaign, with pending measurements and persisted state. If your measurements come back in a batch a week later, the campaign model is the one that matches reality.

Licence and maintenance

BayBE is licensed under Apache-2.0, per the badge in the README and the repository metadata. That is a permissive licence, and it is worth noting that it is not a copyleft one, which matters if you intend to embed the library in a product. I am not a lawyer and this is not legal advice; read the licence text at the link in the README if the distinction affects your distribution plans. On maintenance, the repository is not archived and the most recent push recorded is 2026-09-10. The release history shows 0.15.0 in June 2026, preceded by 0.14.3 in February 2026 and 0.14.2 in January 2026. The version numbers are still in the 0.x range, so the maintainers have not declared a stable API, and the cadence of patch releases within the 0.14 line suggests fixes land regularly. The practical cost of that is upgrade work: pin your version, read the release notes before moving, and expect that a serialized campaign object may not load cleanly across a minor version bump. The README does not state a support policy or a deprecation window, so that risk is unquantified from the material available.

Editorial conclusion

Adopt BayBE if your problem is a campaign with mixed continuous and categorical parameters, constraints, and measurements that arrive in batches over days or weeks, and if you are willing to model the search space explicitly before the first recommendation. Do not adopt it if you want to point it at an existing objective function and let it run unattended, or if you need a single-target minimizer with no notion of a campaign. Before committing, verify two things in the documentation: how your parameter types map onto the available parameter classes, and whether the asynchronous workflow matches how your measurements actually arrive. The serialization concept page is the next thing to read, because it determines whether a campaign can survive a process restart.

Official sources

1. emdgroup/baybe on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases