Error mitigation and debiasing

Debiasing is IonQ's built-in error mitigation, and it works at the compiler level. Instead of running one implementation of your circuit, IonQ creates many symmetric variations of it and runs those.

The idea is that a circuit can be implemented several equivalent ways, using different qubits and different gate decompositions, and each way carries a slightly different systematic bias. Run the variations and average them, and biases that depend on the particular implementation tend to cancel.

Debiasing does not fix everything, and IonQ does not claim it does. Debiasing targets systematic error, the kind that comes from how a particular implementation maps onto the machine. Error that is not implementation-dependent is untouched by it, so a debiased result is still a noisy result. It can be combined with other error mitigation techniques rather than replacing them.

Debiasing is available on all IonQ QPUs. It is not currently available on IonQ's cloud simulator, including the simulator with a noise model.

The 500-shot floor

For a job submitted in standard gates, IonQ enables debiasing by default at 500 shots or more, and it can be turned off. Below that it is not an option at all: with fewer than 500 shots debiasing is disabled automatically and cannot be turned on. A debiased job is divided into 25 executions, each one a different but equivalent implementation of the same circuit. A small shot budget therefore leaves each execution with too few shots to mean anything.

Shots come from your code, not from a control in the runner. Pass them to the run call. Leave the argument out and the backend's default applies, which is 1024, so debiasing is on unless you ask for fewer than 500. Set shots=100 and debiasing cannot run; IonQ does not allow it below 500 shots. See Running your code.

If you are writing your circuit with native gates rather than standard ones, the default flips: debiasing is off, and it can be switched on once the job has 500 shots or more. IonQ notes that you may want it on for a native-gate job if you are after maximum performance, and may prefer it off if your experiment requires a consistent qubit mapping.

Turning it off

Debiasing is set in code when you submit the job, not in a settings panel. On Qollab the backend is already created for you, so the run call is the only line that changes:

from qiskit_ionq import ErrorMitigation

# `backend` is pre-created in the Qollab Playground.
job = backend.run(qc, shots=1000, error_mitigation=ErrorMitigation.NO_DEBIASING)

In general IonQ recommends keeping debiasing on for medium and large circuits, to maximise performance, since job cost is not affected in those cases. For very shallow circuits or small test jobs, turning it off can give similar results while conserving credit. Cost is covered below.

How the executions are combined

Aggregation turns the measurements from the 25 executions into one result. By default they are combined directly into a single histogram, and the distribution you read is the average across all of them. The individual executions are not returned separately, so you see one result, not 25.

According to IonQ, that default suits any algorithm or result type. Sharpening, below, is the alternative.

Sharpening

Sharpening is an optional second way of aggregating the same executions. It needs a debiased job, because only a debiased job has several executions to combine, and it is off by default.

Debiasing is fixed when you submit the job; sharpening is chosen later, when you retrieve the result, so it post-processes counts that already exist. The other name for it is plurality voting: instead of averaging, all counts from each execution are assigned to that execution's highest-probability bitstring.

counts = job.result(sharpen=True).get_counts()

Sharpening is opt-in, and it only applies to a job that ran with debiasing. Request a sharpened result from a job that ran without it and you get an error.

IonQ recommends sharpening only for a narrow kind of result: a job whose expected distribution is one high-probability state or a small handful of them, or a job where the question is which state is most probable. On those, sharpening can amplify the signal you want and strip counts from low-probability states.

Where you need to quantify the relative probabilities of several states, sharpening will not improve the result, and IonQ warns that it could distort the true distribution and should not be used. Plurality voting collapses each execution to a single bitstring, which discards the relative probabilities those questions need. The exception is an execution with no clear highest-probability bitstring, whose shots are counted as they are.

What debiasing costs

Debiasing does not add circuits, shots or qubits to your job, and the gate count changes only a small amount, because the variations use different gate decompositions. It adds a small amount of classical overhead, which on a small job (few gates, few shots, or both) can be relatively significant. IonQ accounts for it by setting a higher minimum per-circuit-job cost for a system when debiasing is enabled. Larger jobs are already above that minimum, so their cost is not affected.

That is IonQ's pricing of the underlying job, not your Qollab credit charge. How credits work covers what you are asked to approve, and when.

Related

• How your circuit is compiled
• Compute backends
• How credits work
• Error reference