Skip to main content
While many different error mitigation methods can be used when running jobs on IonQ’s trapped-ion QPUs, debiasing is a general error mitigation technique that is built into our platform. Debiasing doesn’t address all sources of error in our systems, but it can help reduce the effect of systematic error on result fidelity. This technique also provides the option to aggregate results via sharpening, a postprocessing technique that can further reduce error for certain types of applications. You can find more details about debiasing in our 2023 arXiv paper (where this technique is referred to as “symmetrization”). More error mitigation settings and techniques will also be available in the future.

​
What is debiasing?

Debiasing, sometimes called symmetrization or diversification, is a compiler-level error mitigation strategy that works by creating and running many symmetric variations of a given circuit. Debiasing reduces the overall impact of stochastic noise on the computed result — the deterministic inaccuracies largely cancel out while random noise does not get amplified. This approach effectively mitigates the impact of hardware control errors and qubit decoherence, which are major sources of imperfection in modern quantum technologies. Debiased mapping relies on identifying certain symmetries that arise at multiple levels of quantum computer hardware and using them to generate variant circuit implementations. That is, we identify and create variations of a circuit that should be identical on a noiseless machine, but in practice are not due to stochastic error. Different qubit assignments, gate decompositions, and pulse sequences can all be used to create variant implementations. Example of ideal and per-execution results for a quantum circuit run with debiasing In this simplified example, a two-qubit circuit that should give an equal distribution of 00 and 11 measurements is run using four different qubit pairs on a four-qubit system, with each qubit assignment giving a slightly different result. In practice, when a quantum job is run with debiasing, we require at least 500 shots which are automatically divided into 25 executions, each with a different but equivalent implementation of the same circuit (including qubit assignments but also other types of variants). If there is a specific qubit pair whose fidelity has drifted out of calibration, or a pulse sequence that happens to amplify noise in the context of the circuit, these errors won’t be present in every execution, so their effect on the overall result quality will be reduced. Debiasing is very general and very efficient. It adds a small amount of classical compute overhead for generating the circuit variants, separately running each variant on the QPU, and aggregating results. However, it doesn’t increase the number of circuits, shots, qubits, or gates required (except for small changes in gate count related to different gate decompositions).

​
Default settings and availability

Debiasing is available for all IonQ QPUs, but it is not currently available for the IonQ Quantum Cloud simulator, including the simulator with noise model. Debiasing can’t be used for jobs with fewer than 500 shots, since each execution needs a meaningful number of shots. For any job with fewer than 500 shots, debiasing is automatically disabled and cannot be turned on. For jobs submitted to the IonQ Quantum Cloud in standard QIS gates, debiasing is enabled by default for jobs with 500 or more shots, but it can be turned off. For jobs submitted to the IonQ Quantum Cloud using IonQ’s native gateset, debiasing is disabled by default. However, it can be turned on if the job has 500 or more shots. You may want to turn on debiasing for a native-gate job if you are looking to maximize performance, but you may prefer not to use it if your experiment requires a consistent qubit mapping.
Some integrations and cloud partners may have different default settings or require more shots for debiasing.

​
Effect on job cost

While debiasing doesn’t increase the number of circuits or shots in the job, it adds a small amount of classical overhead which can be relatively significant for small jobs (few gates and/or few shots). To account for this, the minimum per-circuit-job cost for a system is higher when debiasing is enabled. However, for larger jobs, the job cost is not affected by debiasing. Our resource estimator tool, job estimate API endpoint, and dry run job submission option all take the debiasing setting into account when estimating job cost. You can use any of these tools to determine whether turning debiasing on or off will change the expected cost of a job. In general, we recommend keeping debiasing on for medium and large circuits in order to maximize performance, since it will not affect job cost in these cases. However, for very shallow circuits or small test jobs, turning debiasing off can give similar results while conserving credit.

​
How to use debiasing

In the IonQ v0.3 API, the create job request should include "error_mitigation": { "debias": True } or "error_mitigation": { "debias": False }. In the IonQ v0.4 API, debiasing is in the create job request under the “settings” field. 
"settings": { "error_mitigation": { "debiasing": False } }
In Qiskit, import ErrorMitigation from qiskit-ionq and pass error_mitigation=ErrorMitigation.DEBIASING or error_mitigation=ErrorMitigation.NO_DEBIASING when calling backend.run(). In Cirq, pass error_mitigation={"debias": True} or error_mitigation={"debias": False} when calling service.run() or service.create_job(). Here’s several examples of a “Hello world” circuit with 1000 shots where debiasing is turned off (overriding the default, where it would be turned on): 
from qiskit import QuantumCircuit
from qiskit_ionq import IonQProvider, ErrorMitigation

provider = IonQProvider()
qpu_backend = provider.get_backend("qpu.forte-1")

# Create a basic Bell State circuit:
qc = QuantumCircuit(2, name="Qiskit job without debiasing")
qc.h(0)
qc.cx(0, 1)
qc.measure_all()

# Submit the circuit to IonQ Forte:
job = qpu_backend.run(
    qc,
    shots=1000,
    error_mitigation=ErrorMitigation.NO_DEBIASING
)

​
Aggregating job results over executions

When a job is run with debiasing, we also provide two options for combining the results from the different executions (circuit variants) that were run. The default aggregation can be used with any type of algorithm, application, or result type, while sharpening provides an option for additional post-processing that can amplify signal for results that should have a small number of high-probability states. Debiasing enables sharpening by splitting the job into distinct executions, but sharpening is not required when using debiasing.

​
Default - averaging

By default, the measurements from each execution are directly combined into one histogram, providing a probability distribution that represents the average over all executions. The results from each individual execution are not provided separately, but the overall result reflects the combination of all executions. This approach (debiasing without additional post-selection) is versatile and can be used for most, if not all, types of algorithms and applications.

​
Sharpening

Optionally, the results from each execution can be combined via sharpening (also known as plurality voting). With this option, all counts from each execution are assigned to the highest-probability bitstring from that execution. For jobs where the expected probability distribution features one or a few quantum states, or where you are trying to identify the highest-probability quantum state, sharpening can amplify the desired signal and remove counts for low-probability states. Example of per-execution voting and averaged vs sharpened results In this simplified visualization, where each symbol represents a different measured quantum state, the job was split into five executions, each with four shots. For averaging (left), the result is aggregated by counting the overall occurrences of each symbol. With sharpening (voting, right), we take the most frequently occurring symbol from each row (execution), which yields two rows for the green triangle, two rows for the blue diamond, and one row which is skipped because there is no “winner” in the voting. The result is a histogram where all of the probability is assigned to the 00 and 11 states, matching the ideal distribution for the example circuit. For applications with a more complex probability distribution, or where you need to quantify the relative probabilities of several different states, sharpening will not improve the result. In these cases, sharpening could distort the true probability distribution and should not be used. As a safeguard, if an execution has no clear highest-probability bitstring during sharpening, the shots from that execution are automatically counted as-is (just as when sharpening is not used), rather than discarded as in the above example.

​
Retrieving job results with sharpening

While debiasing is set “on” or “off” when the job is submitted, sharpening is an option used for result retrieval. When retrieving the results from a job that was run with debiasing, you can always choose to apply sharpening or not (or you can retrieve the result both ways for comparison). If you request a sharpened result from a job that was not run with debiasing, you’ll receive an error.
Sharpening is “opt-in”: the default setting is always to retrieve the result without sharpening.
In the IonQ v0.3 API and the IonQ v0.4 API, use the query parameter sharpen to retrieve a job result with sharpening. In Python, this looks like passing params={"sharpen": True} to the request call. Note that the specific request URL format is different between v0.3 (.../{job_id}/results) and v0.4 (.../{job_id}/results/probabilities). In Qiskit, use job.result(sharpen=True).get_counts() rather than job.get_counts() to retrieve a job result with sharpening. In Cirq, use job.results(sharpen=True) to retrieve a job result with sharpening. In all of these examples, setting this value to False or omitting it will give the default, non-sharpened result. Here’s several examples of retrieving a sharpened job result, given a job ID: 
from qiskit_ionq import IonQProvider

provider = IonQProvider()
qpu_backend = provider.get_backend("qpu.forte-1")
job_id = "..."

# Retrieve the job
job = qpu_backend.retrieve_job(job_id)

# Retrieve the sharpened result
result_sharpened = job.result(sharpen=True).get_counts()
print(result_sharpened)

# Retrieve the averaged (unsharpened) result
# This is equivalent to just doing job.get_counts()
result_averaged = job.result(sharpen=False).get_counts()
print(result_averaged)

​
Summary and recommendations

Debiasing can be used with any type of quantum circuit job, as long as the job has 500 or more shots. For jobs submitted in QIS gates, debiasing is on by default; for jobs submitted in IonQ native gates, debiasing is off by default. While debiasing doesn’t address all types of error, it doesn’t add overhead in qubits, gates, or shots. For large circuits, debiasing can improve result quality and won’t increase job cost (though it may increase cost for small jobs). It can also be combined with many other types of error mitigation. Sharpening is an optional post-selection technique for aggregating the results from a debiased job. It can amplify signal in cases where the expected result contains one or a few high-probability states. For more detail about debiasing, refer to our 2023 arXiv paper. Stay tuned for more error mitigation options and techniques that will be available for our systems in the future!
⌘I