An optical tweezer array for quantum computing is a precision instrument with dozens of independently controlled degrees of freedom: per-site trap depth, trap frequency, beam pointing angles, laser frequencies for cooling and trapping, and the timing relationships between all of these. When one degree of freedom drifts, it affects qubit quality in ways that are often subtle, correlated, and system-specific. Writing a rule-based controller that handles all drift scenarios correctly is impractical because the drift manifold is too high-dimensional and the correlations between degrees of freedom are not known analytically.
Our calibration agent takes a different approach. Rather than trying to model the physics of drift from first principles, we train a model directly on historical drift data from the system itself and use the learned model to drive predictive corrections. This post describes the architecture in detail, including the design choices we made and the ones we revised after initial deployment.
Observation space
The model's observation vector at each time step consists of three categories of measurements.
Direct sensor readings: temperature at four points on the optical table frame and one point near the vacuum chamber; magnetometer output at two locations; atmospheric pressure at the lab exterior. These are read at 1 Hz and provide ambient environmental context to the model. They do not directly measure qubit parameters but correlate with drift timescales and amplitudes in ways the model learns to use.
Per-site trap frequency estimates: from the parametric heating probe sequence described in our calibration overview post, we extract trap frequencies for a spatial subset of 20 sites at each monitoring cadence. Measuring all 100 sites at every cycle would consume too much experiment time, so we use a spatial downsampling strategy that ensures at least one site is measured in each spatial region of the array. The full 100-site map is reconstructed by the model from the sparse measurements using spatial correlation priors learned from historical full-array scans.
Gate performance metrics: at each experimental checkpoint, we run a short randomized benchmarking sequence on a small set of representative qubit pairs. The average gate error rate extracted from these runs is included in the observation vector as a direct performance feedback signal. This closes the loop from environmental drift through hardware parameters to observable qubit performance.
The prediction architecture
The core prediction model is a GRU (gated recurrent unit) network with two recurrent layers of 128 hidden units and a linear output layer. Input at each timestep is the 60-dimensional observation vector. Output is a predicted 10-minute drift trajectory for each monitored degree of freedom, at 1-minute resolution.
We chose GRU over LSTM for this application because our drift timescales are typically in the 5-60 minute range, which falls in a regime where LSTM's extra memory gates do not provide meaningful benefit over GRU's simpler reset and update mechanism. The shorter gradient path in GRU also trained faster with less tendency to overfit on our relatively limited dataset of approximately 180 days of operational history.
A transformer architecture was evaluated as an alternative. On offline prediction accuracy metrics, the transformer outperformed the GRU by a modest margin on a held-out validation set. However, the transformer had 4x the parameter count, which introduced two practical problems: slower inference at the real-time cadence we need (the model must complete inference in under 50 ms to stay within the control loop budget), and higher sensitivity to distribution shift when operating in conditions slightly outside the training distribution. GRU's simpler inductive bias made it more robust in deployment. This may change as we collect more training data and as hardware accelerators make transformer inference cheaper.
Actuator selection and correction policy
Given a predicted drift trajectory, the correction policy selects which actuators to activate and by how much. The available actuators are: individual AOM frequency setpoints (one per trap beam path) for per-site trap depth adjustments, a tip-tilt mirror controller for global beam pointing with 1 kHz closed-loop bandwidth, and the clock laser cavity lock setpoint for qubit frequency corrections up to a few kilohertz.
The policy architecture is a separate feed-forward network trained to minimize predicted future gate error given the current drift trajectory prediction. This separation of prediction and correction proved important in practice. An end-to-end architecture that predicted corrections directly from observations without the intermediate drift trajectory suffered from poor generalization to novel drift patterns, because the end-to-end network had no incentive to learn an interpretable representation of drift. The two-stage architecture also lets us debug the system: if corrections are unexpectedly large, we can inspect the drift trajectory prediction to understand what the model thinks is happening, and check whether that prediction is reasonable given the observed sensor data.
Corrections are applied with a dead-band to avoid continuous micro-adjustments that might themselves introduce noise. The dead-band threshold for each actuator was tuned empirically by running the system with progressively smaller thresholds and identifying the point where further threshold reduction stopped improving gate performance and started increasing noise floor. Below a certain correction amplitude, the actuator noise from the AOM driver electronics exceeds the correction benefit.
Handling distribution shift
One of the hardest problems in deploying a learned model for continuous real-time control is distribution shift: the system state at deployment may not resemble the training distribution. In our case, the main distribution shift scenarios are seasonal lab temperature extremes (winter heating and summer air conditioning create drift patterns not present in autumn or spring training data) and hardware modifications (adding or replacing optical components changes the drift characteristics of the system).
We addressed seasonal shift by including data from full seasonal cycles in the training set. This required waiting through one full year of operation before the model was reliable enough for unattended use during temperature extremes. In the initial deployment period, the model performed well but required manual review during the first summer and winter temperature peaks. By the second year, with full seasonal training data, these edge cases were handled without intervention.
Hardware modification shift is harder. Each time we modify the optical system, the drift correlation structure changes in ways that are not well-predicted by the pre-modification model. Our current practice is to flag modification events and enter a re-learning period of 72 hours during which the model operates with a wider uncertainty envelope and more conservative correction thresholds. After 72 hours of new data, the model is fine-tuned on the post-modification history and returned to normal operation. Fine-tuning is significantly faster than full retraining, taking approximately 20 minutes on our control hardware GPU.
What the model does not learn
It is worth being explicit about what our approach does not cover. The model predicts and corrects smooth, slow drift. It does not handle sudden discrete events: a laser mode hop, a fiber coupling failure, a vacuum leak, or a power line transient. These events produce observation vectors that are far outside the training distribution and trigger model uncertainty flags that pause corrections and alert the operator. The event detection uses a simple anomaly score on the observation vector: if the Mahalanobis distance from the predicted observation to the actual observation exceeds a threshold calibrated during normal operation, the model flags an anomaly.
The model also does not correct for errors introduced by the correction mechanism itself. AOM frequency adjustments change the trap depth, which changes the motional state distribution of atoms in the trap, which in turn affects gate fidelity through the thermal motion mechanism. These second-order effects are not modeled explicitly and contribute a small systematic error. We quantified this by comparing gate fidelity under active correction to gate fidelity under manual calibration with identical trap parameters. The difference falls below measurement precision for current benchmarks but may become relevant at higher gate fidelities.
Lessons from the first year of deployment
The most important lesson is that the observation space design matters more than the model architecture. Our first deployment used only trap frequency and laser frequency in the observation vector. It worked but showed systematic failures on hot afternoons when the air conditioning in the building cycled on its daily schedule, causing a specific drift pattern not well-represented in the training data. Adding the environmental sensor readings and retraining resolved this immediately, because the temperature and pressure sensors provided exactly the causal context the model was missing.
The second lesson is that real-time feedback from gate performance metrics is not optional. Without the gate performance signal in the observation vector, the model sometimes made corrections that were directionally correct on trap frequency but missed correlated changes in the phase calibration, resulting in similar overall gate error despite correct trap parameters. Including the gate performance metric as an observation gives the model a direct objective signal and naturally handles correlations between drift axes that would otherwise require explicit modeling.
A note on what this approach is not: we are not solving the fundamental physics of decoherence. We are making a practical engineering system work reliably by automating the human expertise that previously kept it calibrated. Whether "AI calibration" is the right framing depends on who you ask. From a physics standpoint, it is a learned feedback controller. From an operational standpoint, it is what lets a research group run experiments on Thursday that they could not have run without a physicist in the lab on Wednesday night.