Active Learning for Experiment Planning — Operating Quantum Computers

Quantum experiments are expensive, noisy, and sequential. Running a grid search across pulse parameters, variational angles, compilation settings, or mitigation knobs wastes scarce capacity. Active learning and Bayesian optimization provide a better operating pattern: use previous observations to choose the next experiment that is most likely to improve knowledge or performance.

Tools such as BoTorch, Ax, Optuna, and related optimization frameworks are general-purpose, but their core loop maps well to quantum experiment planning: propose, run, observe, update, and constrain. [R145]

Diagram loads as you read

Active Learning for Experiment Planning · Figure 1

View diagram source

flowchart LR
    Prior[Prior model] --> Propose[Propose experiment]
    Propose --> Run[Run quantum or simulator experiment]
    Run --> Observe[Observe result and uncertainty]
    Observe --> Update[Update model]
    Update --> Propose

Optimization targets

Active learning can optimize many quantum operational objectives:

Diagram loads as you read

Optimization targets · Figure 2

View diagram source

flowchart TB
    Objectives[Experiment objectives] --> Algorithm[Algorithm performance]
    Objectives --> Calibration[Calibration quality]
    Objectives --> Compilation[Compilation settings]
    Objectives --> Mitigation[Mitigation parameters]
    Objectives --> Scheduling[Scheduling policy]
    Objectives --> Cost[Cost and energy]

Examples:

Domain	Tunable variables	Objective
VQE	ansatz parameters, optimizer settings	lower estimated energy
QAOA	depth, angles, mixer choice	better objective sample
calibration	pulse amplitude, duration, frequency	higher fidelity
compilation	layout seed, routing method, optimization level	lower error-weighted depth
mitigation	extrapolation scale, shot allocation	lower bias with acceptable variance

Closed-loop experiment planner

Diagram loads as you read

Closed-loop experiment planner · Figure 3

View diagram source

sequenceDiagram
    participant Planner as Planner
    participant Policy as Policy engine
    participant Runtime as Runtime
    participant Warehouse as Warehouse
    participant Model as Surrogate model

    Planner->>Policy: Request candidate approval
    Policy-->>Planner: Approved candidate set
    Planner->>Runtime: Submit selected experiment
    Runtime-->>Warehouse: Store result and metadata
    Warehouse-->>Model: Provide observation
    Model-->>Planner: Updated posterior and acquisition score

The planner should not bypass policy. It should ask for candidate approval before execution.

Exploration versus exploitation

Diagram loads as you read

Exploration versus exploitation · Figure 4

View diagram source

flowchart LR
    Candidate[Candidate experiment] --> Score[Acquisition score]
    Score --> Exploit[Expected improvement]
    Score --> Explore[Uncertainty reduction]
    Score --> Cost[Execution cost]
    Score --> Risk[Operational risk]
    Exploit --> Decision[Selection]
    Explore --> Decision
    Cost --> Decision
    Risk --> Decision

Quantum platforms often need exploration early and exploitation after an operating region is discovered. The scheduler can encode this with budgets:

exploration budget;
exploitation budget;
safety budget;
replication budget.

Safety constraints

Active learning is dangerous if the planner can propose unsafe or invalid experiments.

Diagram loads as you read

Safety constraints · Figure 5

View diagram source

flowchart TB
    Candidate[Candidate] --> Static[Static constraints]
    Candidate --> Dynamic[Dynamic constraints]
    Static --> S1[parameter bounds]
    Static --> S2[target compatibility]
    Static --> S3[pulse safety]
    Dynamic --> D1[calibration freshness]
    Dynamic --> D2[queue and budget]
    Dynamic --> D3[recent incidents]
    S1 --> Gate[Safety gate]
    S2 --> Gate
    S3 --> Gate
    D1 --> Gate
    D2 --> Gate
    D3 --> Gate

The planner should produce candidate sets; the platform should own admission.

Multi-objective planning

Quantum operations rarely optimize one variable.

Diagram loads as you read

Multi-objective planning · Figure 6

View diagram source

flowchart LR
    Candidate[Candidate] --> Fidelity[Fidelity]
    Candidate --> Cost[Cost]
    Candidate --> Time[Queue time]
    Candidate --> Energy[Energy]
    Candidate --> Risk[Risk]
    Fidelity --> Pareto[Pareto frontier]
    Cost --> Pareto
    Time --> Pareto
    Energy --> Pareto
    Risk --> Pareto

A candidate with slightly lower estimated performance may be preferred if it is much cheaper, faster, safer, or more reproducible.

Batch active learning

QPU access often arrives in windows. Batch active learning chooses a set of candidates before all new observations are available.

Diagram loads as you read

Batch active learning · Figure 7

View diagram source

flowchart TB
    Model[Current model] --> Batch[Batch candidate generator]
    Batch --> Diversity[Diversity constraint]
    Batch --> Correlation[Correlation control]
    Batch --> Budget[Budget constraint]
    Diversity --> Submit[Submit batch]
    Correlation --> Submit
    Budget --> Submit

Batch selection should avoid near-duplicate experiments unless replication is the point.

Replication policy

Active learning optimizes for learning. Science still needs replication.

Diagram loads as you read

Replication policy · Figure 8

View diagram source

flowchart LR
    Promising[Promising result] --> Replicate{Replication required?}
    Replicate -- no --> Continue[Continue exploration]
    Replicate -- yes --> Repeat[Repeat under controlled conditions]
    Repeat --> Confirm{Confirmed?}
    Confirm -- yes --> Promote[Promote finding]
    Confirm -- no --> Investigate[Investigate instability]

Promote only replicated results into evidence packages used for product or external claims.

Human review points

Diagram loads as you read

Human review points · Figure 9

View diagram source

flowchart TB
    Planner[Planner] --> Autonomous[Autonomous low-risk loop]
    Planner --> Review[Human review]
    Review --> HighCost[High cost]
    Review --> HighRisk[High physical risk]
    Review --> Claim[Claim-impacting result]
    Review --> NewRegion[Unexplored parameter region]

Autonomy should expand with demonstrated safety. It should not expand because humans are bored of reviewing proposals.

Operating rule

Use active learning to reduce waste, but keep policy, safety, replication, and claim review outside the optimizer.