info

This document discusses non-API components of Ax, which may change between major library versions. Contributor guides are most useful for developers intending to publish PRs to Ax, not those using Ax directly or building tools on top of Ax.

Generation Strategy

The Generation Strategy is an entry-point to the methodology layer in Ax: it allows for pre-specification of all optimization algorithms and for the dynamic conditions for transitions between them. It is essentially a finite state machine for methods Ax will use in the course of a given optimization.

An example generation strategy consists of three "generation nodes":

• "Sobol": Quasi-random initialization node for the first few trials (samples initial points in the search space before any trials finish and their data becomes available);
• "Transfer-Learning BayesOpt": Node with Bayesian optimization with Transfer Learning that leverages data from pre-existing experiments as well as from the current one;
• "BoTorch": Standard Bayesian optimization node to use if no previous experiments are available to transfer knowledge from.

A generation strategy typically acts as an "experiment contract" and reflects how Ax will generate subsequent trials depending on the current state of the experiment. Notably, not all GenerationNodes within a GenerationStrategy must be traversed. Before proceeding, we recommend ensuring familiarity with Internal Organization of Ax: Experiment + Trials.

Generation Node

A GenerationNode represents a single "generation purpose" that applies at a specific point in the course of an experiment. GenerationNodes directly interfaces with the Adapters that expose the underlying methodologies (via Generators). GenerationNodes can be thought of as producers of new trials for a given experiment.

Node Transitions

Generation strategies transition between nodes via transition edges, made up of transition criteria: A TransitionCriterion represents a condition for whether a transition should occur between two nodes in a GenerationStrategy. Examples include:

• Is there enough data to start AI-driven optimization, e.g. with Bayesian optimization?
• Is data from previous experiments available?
• Is the optimization currently configured for a single or multiple objective(s)?

All transition criteria along a given edge must be met for the GenerationStrategy to proceed to the destination node.

Can a GenerationNode have outgoing transition edges to different nodes?

Yes, competing edges are possible. They will both be defined on the source GenerationNode and their order on that node’s transition_criteria attribute will indicate priority. The GenerationStrategy will transition to the target node of the first edge where all transition criteria are met at a given point in the experiment.

Specifying a custom GenerationStrategy to the API

Typically, configuring common aspects of the GenerationStrategy through the Client.configure_generation_strategy API method is recommended (see corresponding recipe).

It’s possible to specify a fully custom GenerationStrategy via Client.set_generation_strategy (see Utilizing custom Generators via Modular BoTorch Interface, but this usage is not part of the Ax backward-compatible API and backward compatibility is not guaranteed: the method or its input could thus change between minor versions in the future.

Advanced features

Generation strategies include a number of advanced, optional features which are not required for typical use cases, but can be useful for more exotic setups.

External Generation Node

Additionally, Ax provides an ExternalGenerationNode abstraction, which enables seamless support for non-Ax methodologies. A GenerationStrategy might be composed of both ExternalGenerationNodes and regular Ax GenerationNodes, or entirely of one type. When defining an ExternalGenerationNode, two abstract methods must be implemented: update_generator_state(), which updates the state of generation methods, and get_next_candidate() which retrieves the next suggested candidate from custom methods.

Input Constructors

"Input constructors" define the logic for dynamically computing certain GenerationNode settings based on the current experiment state. For example, target task when using a MultiTaskGP or a number of arms to produce from a given GenerationNode given the output of other GenerationNodes.