HEBO: Huawei Noah's Ark Bayesian optimisation library and its research siblings

A monorepo of research outputs, not a single package

The first thing to understand about this repository is that it is a collection, not a library. The README describes the directory as containing official implementations for Bayesian optimisation, reinforcement learning and generative model works developed by Huawei Noah's Ark Lab, and it groups the entries under those three headings. Bayesian optimisation research alone takes nine slots, from HEBO and MCBO to NAP, RDUCB, AntBO, BOiLS, T-LBO, CompBO and AIRBO. Reinforcement learning research adds four more, robotics research one, and generative model research two.

The top-level entries reflect that layout. Alongside README.md and LICENSE sit the project directories AIRBO, Agent, AntBO, BOiLS, CompBO, EM-LLM, HEBO, MCBO, NAP, PMDB, RDUCB, RLLG, ROSLLM, SIMMER, SparsePO and T-LBO, along with .gitmodules, which tells you some of the content arrives as submodules rather than as plain files.

So the name of the repository overstates what you get from one import. If you came for the HEBO library, that is one directory among many, and the README says plainly that further instructions are provided in the README files associated to each project. That instruction is the actual entry point for anyone who wants to run something.

HEBO itself, the challenge winning optimiser

HEBO is the Bayesian optimisation library developed by Huawei Noah's Ark Decision Making and Reasoning lab, and the README identifies it as the winning submission to the NeurIPS 2020 Black-Box Optimisation Challenge. That distinction matters for how you read the code. This is a library that was entered into a public benchmark against other optimisers, which is a different claim from a general purpose tuning tool, and it is the reason the project is the most widely known part of the repository.

The name carries the technical description. HEBO stands for Heteroscedastic Evolutionary Bayesian Optimisation, and the directory is listed as HEBO, with its own README, its own images and its own instructions. Heteroscedastic means the surrogate is not assumed to have uniform noise across the search space, and evolutionary refers to the search strategy wrapped around the acquisition. Those two words are the summary of the method, and the rest of the design sits in the subproject documentation rather than in the top-level file.

For an engineer, the practical question is whether the surrogate and acquisition settings that made it competitive on a benchmark suit your objective function. The challenge entry tells you it performs against peer submissions on black-box tasks. It does not tell you it is the right choice for a noisy, expensive, categorical or mixed-variable space, which is what the sibling projects were built to explore.

The siblings cover the corners plain BO struggles with

The catalogue reads like a map of where Bayesian optimisation gets hard, and the subproject names carry the technique:

- [HEBO: Heteroscedastic Evolutionary Bayesian Optimisation](./HEBO)
- [MCBO: Framework and Benchmarks for Combinatorial and Mixed-variable Bayesian Optimization](./MCBO)
- [NAP: End-to-End Meta-Bayesian Optimisation with Transformer Neural Processes](./NAP)
- [RDUCB: High Dimensional Bayesian Optimisation with Random Decompositions](./RDUCB)

MCBO is a framework and benchmark suite for combinatorial and mixed-variable optimisation, released under the MIT licence. Its abstract describes the problem it targets: papers in that area often use non-diverse or non-standard benchmarks, and papers solving one primitive frequently omit comparison against baselines that use the same methods for the rest. The framework fixes that by allowing components to be combined freely, and the reported evaluation covers 47 implemented MCBO algorithms against seven existing MCBO solvers and five standard black-box optimisation algorithms on ten tasks, over 4000 experiments.

NAP takes a different angle, meta-learning across related tasks with transformer neural processes trained end to end with reinforcement learning. RDUCB attacks high dimensionality through random decompositions, and its abstract notes that data-driven learners of decompositions can be misled toward local decompositions that do not hold globally. AntBO and BOiLS move the same machinery into antibody design and logic synthesis, which tells you the same machinery is reused across very different domains.

Getting the code means reading the subproject README

There is no install command in the top-level README, and the honest way to describe the acquisition path is as documentation rather than as a package manager flow. The repository ships .gitmodules, so some directories are submodules that have to be initialised, and the top-level README states that further instructions are provided in the README files associated to each project. The subproject READMEs are where the install and usage steps live, and the top-level file gives you the map of which one to open.

The repository language listed for the project is Jupyter Notebook, and the artefacts referenced in the README are images and paper results rather than a packaged API. The MCBO section, for example, points at paper_results directories of result images, which is what a research codebase usually looks like when it has been released alongside a paper rather than prepared for a package index.

Two concrete facts are worth carrying into your evaluation. First, the code is available in the repository itself, at the path huawei-noah/HEBO, and the MCBO licence statement names that path explicitly, so you do not need a separate artefact. Second, the release history is thin: the newest listed release is v0.3.4 from 2022-11-22, while the last push to the default branch was on 2026-10-12. In other words the code moves on the branch without being tagged, which means you should pin to a commit rather than to a version number.

What the benchmark work says about model fit and trust regions

One practical lesson is documented in the MCBO abstract, and it is about what to prioritise when you tune an optimiser. The stated findings are that a superior combination of MCBO primitives outperforms existing approaches, and that the significance of model fit and the use of a trust region stand out. If you take one design rule from this repository, it is that the surrogate quality and the search region have more influence on the outcome than the choice between acquisition functions.

The NAP abstract adds a second, more cautionary point about the same machinery. It reports that training transformer-based neural processes from scratch with reinforcement learning is challenging because supervision is insufficient and rewards are sparse, and it formalises that with a combinatorial analysis of regret as a reward signal. The fix described is an auxiliary task that pushes part of the architecture towards learning a valid probabilistic model as an inductive bias. The authors report state of the art regret results on standard hyperparameter optimisation tasks, along with results on mixed-integer programming tuning, antibody design and logic synthesis for electronic design automation.

The two statements together sketch a realistic picture. These methods are not plug and play optimisers that converge on any objective. The reported gains come with training procedures, auxiliary losses and careful design, which is the price of the flexibility.

Limits worth knowing before you build on it

The obvious limit is documentation depth. The top-level README is a catalogue with abstracts, so the details you need to run anything, including how the surrogate is configured and how the acquisition is tuned, are inside the subproject files rather than in one place you can scan.

The licence situation needs care too. The licence for the whole repository is listed as unknown, while the MCBO project states that it makes its library available under the MIT licence. Subprojects therefore do not obviously share one licence, and a decision about shipping a derivative has to be made per directory after reading that directory's own README and LICENSE. That is not legal advice, it is simply a consequence of the monorepo layout.

Versioning is the third wrinkle. With one listed release from 2022 and pushes continuing to the branch through 2026, there is no tagged line to upgrade along, and changes to the subproject READMEs or code arrive without a changelog. Submodules add one more moving part, since a submodule pointer is a separate commit from the content it points at. None of that is unusual for research code, but it is a cost you take on when the code becomes a dependency rather than a script you run once.

Who should use which directory

Pick the project that matches the shape of your problem rather than the one with the most impressive abstract. If you have a continuous, expensive, noisy objective and want a working acquisition and surrogate loop, HEBO is the entry point, and its NeurIPS 2020 challenge win is the reason to look there first. If your variables are categorical, integer or mixed, read MCBO, which exists precisely because that corner was under-benchmarked, and note that it is the subproject with a clear MIT licence statement.

If you want to learn how a meta-acquisition function can be trained, NAP is a research artefact with a reinforcement learning training loop, not a library you wire into a service. RDUCB is worth reading if your dimension count is the bottleneck, and its question of whether data-independent decomposition sampling suffices is an open research direction in the paper as presented.

For the generative model and safe reinforcement learning directories, ROSLLM, SIMMER, PMDB, SparsePO, RLLG and EM-LLM, the same rule holds. They are code published with papers, each with its own README, and they share no common API with the optimiser. The repository is best read as a reading list with runnable code attached.

Editorial conclusion

Adopt the HEBO subproject when you need a proven Bayesian optimisation loop and want to reproduce the NeurIPS 2020 challenge winner rather than assemble your own surrogate and acquisition code. Stay with the wider repository for the research, not the tooling, since most sibling directories are paper code with no shared package. Before you import anything, read the README inside the subproject you care about for its own install steps, check the licence of that specific directory because the top-level licence for the repository is listed as unknown, and confirm your dependencies can be satisfied for the notebooks the project ships as its primary language.

Frequently asked questions

Official sources

1. huawei-noah/HEBO on GitHub
2. Issues
3. README
4. Releases