Quantum error mitigation can improve the usefulness of noisy-circuit results without requiring full fault-tolerant error correction. This practical quantum error mitigation tutorial gives you a repeatable workflow for establishing a baseline, calibrating measurements, applying techniques such as zero-noise extrapolation and dynamical decoupling, and deciding whether an accuracy gain justifies the extra circuit executions and analysis.
Overview
Near-term quantum hardware produces results affected by gate errors, measurement errors, decoherence, crosstalk, and device-specific operating conditions. A simulator can help validate circuit logic, but an ideal simulator does not reproduce every error found on a quantum processing unit (QPU). Error mitigation addresses this gap by processing noisy results to estimate what the circuit might have produced with less noise.
Mitigation is different from quantum error correction. Error correction uses additional qubits and fault-tolerant procedures to detect and correct errors during computation. Error mitigation generally leaves the circuit architecture mostly intact and instead uses calibration, repeated executions, modified circuits, or classical post-processing. It can reduce bias in an expectation value or probability distribution, but it also adds sampling cost and can increase statistical uncertainty.
The central question is therefore not “Which technique removes all errors?” It is: Does the mitigated result improve a defined metric enough to justify its overhead? A useful benchmark compares at least four outputs:
- An ideal or high-quality reference, when one is available.
- A noisy, unmitigated hardware or noise-model result.
- A mitigated result.
- The execution and analysis cost of producing each result.
For background on circuit size and execution planning, see the Quantum Circuit Resource Estimation guide. Before using a cloud QPU, also review the Quantum Hardware Job Submission Checklist.
How to estimate mitigation benefit
Start by choosing one metric. For an expectation value, a simple absolute error is:
absolute error = |measured result − reference result|
If the reference value is known, compare the unmitigated and mitigated errors:
improvement = unmitigated error − mitigated error
A positive improvement means the mitigated estimate is closer to the reference. You can also express relative improvement when the unmitigated error is not close to zero:
relative improvement = improvement ÷ unmitigated error
For classification or sampling tasks, use a task-specific metric such as success probability, total variation distance, parity accuracy, energy error, or objective-function value. Do not assume that a visually smoother histogram is more accurate. Mitigation must be evaluated against a reference, an analytically known answer, a classically simulable small instance, or a controlled noise model.
Record overhead separately. A practical estimate is:
total shots = number of circuit variants × shots per variant
Readout-error mitigation may require calibration circuits in addition to the application circuit. Zero-noise extrapolation (ZNE) requires multiple versions of the circuit at different effective noise levels. Dynamical decoupling may use the same logical circuit but add pulses, which can increase duration and introduce additional compilation constraints.
| Technique | What it targets | Typical overhead | Important limitation |
|---|---|---|---|
| Readout-error mitigation | Measurement assignment errors | Calibration circuits and classical correction | Calibration can become expensive as the measured system grows |
| Zero-noise extrapolation | Noise accumulated during circuit execution | Several noise-scaled circuit executions | Extrapolation can amplify sampling uncertainty |
| Dynamical decoupling | Some idle-time and decoherence effects | Additional pulses and scheduling constraints | It does not correct every gate or readout error |
| Symmetry verification | Results that violate known circuit symmetries | Extra measurements or post-selection | Discarding results can reduce effective sample size |
Use one technique first when diagnosing a circuit. Combining several methods can help, but it makes attribution harder. If you combine them, benchmark the individual steps as well as the final pipeline.
Inputs and assumptions
1. Circuit structure
Record logical qubit count, measured qubits, gate count, two-qubit gate count, depth, measurement locations, and the transpiled circuit for the target backend. The logical circuit is not enough: mapping and transpilation can change depth, connectivity, and gate composition. The Quantum Compiler Basics guide explains why this distinction matters.
2. Reference result
Choose the strongest practical reference. For a small circuit, use an ideal statevector or exact calculation. For a larger circuit, use a classically simulated noisy model, a trusted lower-depth version, a known symmetry, or a high-shot reference if appropriate. Label the reference clearly; a noisy simulator is not an ideal truth source.
3. Baseline execution
Run the unmitigated circuit with a fixed shot count and record the backend, compilation settings, layout, seed or reproducibility controls when available, execution time, and result format. Keep the baseline close in time to the mitigated run when hardware conditions can change.
4. Measurement calibration
Readout mitigation usually estimates how prepared computational-basis states are observed. Calibration quality depends on the selected qubits, calibration age, shot count, and the correction model. Check whether the SDK uses a full assignment model, a factorized approximation, or another method. Avoid treating the calibration matrix as permanent: it describes a measurement process under particular conditions.
5. Noise-scaling plan
For ZNE, select a small set of scale factors and a scaling method supported by your toolchain. Scaling can involve gate folding or another transformation. Confirm that the transformed circuits remain valid for the target backend and that the effective noise ordering is meaningful. Extrapolation is a model, not a direct observation of a noiseless device.
6. Hardware-versus-simulator controls
Run the same logical experiment in an ideal simulator, a noise-model simulator, and hardware where possible. Keep qubit mapping, measurement convention, circuit version, and observable definition consistent. A simulator can isolate assumptions, while hardware reveals device-specific behavior. Neither should automatically be treated as a substitute for the other.
Worked examples
Example A: Readout mitigation for a small measured circuit
Suppose an ideal reference gives an expectation value of 0.80. The unmitigated hardware estimate is 0.68, so the absolute error is |0.68 − 0.80| = 0.12. After measurement calibration and classical correction, the estimate is 0.75. Its absolute error is 0.05.
The estimated improvement is therefore 0.12 − 0.05 = 0.07, or about 58% of the original error. This result is useful only if the calibration circuits and corrected application data used a defensible shot budget. Repeat the experiment with more than one shot count if you need to distinguish a stable improvement from sampling variation.
Example B: Zero-noise extrapolation
Assume three noise-scaled executions produce expectation estimates of 0.61, 0.66, and 0.70 at increasing noise scales. A simple extrapolation model estimates the value at zero noise. The exact fit depends on the selected scaling factors and model, so do not calculate an extrapolated value by averaging the three numbers. Fit the model, retain the uncertainty, and compare the result with the unmitigated baseline.
If each of the three variants uses 4,000 shots, the application portion requires 3 × 4,000 = 12,000 shots, excluding calibration, queueing, and compilation overhead. If the extrapolated answer is closer to the reference but has a substantially wider confidence interval, report both facts. A point estimate without its uncertainty can make mitigation appear more reliable than it is.
Example C: Choosing between methods
Consider a circuit with long idle periods and a noticeable readout bias. Test readout mitigation and dynamical decoupling independently before combining them. If readout mitigation reduces the final metric error while dynamical decoupling does not, use the simpler workflow unless another metric benefits from the pulse sequence. If each method helps independently but the combination does not improve further, the added overhead is difficult to justify.
Log every run using a consistent record:
- Experiment: circuit name, version, observable, and reference method.
- Backend: simulator or QPU, qubit layout, compilation settings, and execution date.
- Noise controls: calibration timestamp, mitigation method, scale factors, pulse or scheduling options.
- Sampling: shots per circuit, number of variants, rejected samples, and total shots.
- Results: raw estimate, mitigated estimate, uncertainty, reference, absolute error, and improvement.
- Decision: keep, revise, or reject the mitigation method and why.
When to recalculate
Recalculate the benchmark whenever the circuit, compiler output, backend, qubit layout, shot budget, or mitigation implementation changes. Revisit it after SDK or cloud-platform releases that alter supported mitigation methods, transpilation, pulse controls, measurement handling, or result formats. Hardware calibration changes are also a reason to repeat measurement calibration and the unmitigated baseline.
For a reusable project, schedule a periodic review at least twice a year, and sooner when results are close to a go/no-go decision. Recalculate after changing the observable or success metric, because a technique that improves an expectation value may not improve a probability distribution or optimization objective.
Use this action sequence for the next noisy-circuit run:
- Freeze the circuit version and define the metric.
- Generate an ideal or otherwise defensible reference.
- Run an unmitigated baseline and record its full configuration.
- Measure or model the relevant error source.
- Apply one mitigation technique and estimate its shot overhead.
- Compare error, uncertainty, runtime, and total executions.
- Repeat on a second run or shot budget before adopting the method.
Mitigation is worthwhile when it produces a reproducible improvement for the task you actually care about. Keep the experiment log with the project, because backend behavior, compiler output, SDK APIs, and benchmark results are inputs—not fixed constants.
