Part IV. Protocols and Algorithms

Variational Algorithms and Their Limits

A variational algorithm is a training loop with a quantum device inside it: a parameterized circuit, a measured objective, a classical optimizer, repeat. This chapter gives you the audit questions that decide whether such a loop produces utility or just consumes shots.

Listen to this chapter

Most variational-algorithm claims fail on benchmarking grounds, not quantum ones. The ansatz is rarely the weak link; the untuned classical baseline and the uncounted shot budget are.

This chapter treats variational algorithms as what they are — hybrid workflows with an optimizer, an ansatz, a noise model, and a sampling cost — and shows you how to evaluate one the way you would evaluate any machine-learning result that arrives with impressive charts.

Core concepts: variational algorithms, quantum utility, application baselines.

Notice where the loop pays: not in any single circuit, but in the repetition. Each optimizer step needs fresh estimates, each estimate needs many shots, and noise sits on every one of them.

A training loop with a QPU inside

Variational algorithms split the work between two machines. The quantum device prepares a parameterized state and returns estimates of an objective — typically an expectation value. The classical computer looks at those estimates and proposes new parameters. Around and around until the objective stops improving or the budget runs out.

The appeal for near-term hardware is real: the circuit can be shallow compared to what a fully fault-tolerant algorithm demands, and some noise can be absorbed into the optimization. But shallower is not the same as useful. Hard optimization surfaces, noise that warps the objective, data-loading costs that erase the claimed speedup, and very strong classical baselines all survive the move to shallow circuits.

What the loop measures

The quantum computer in this story is usually an expectation-value estimator. For an observable $A$ :

⟨ A ⟩ = ⟨ ψ ∣ A ∣ ψ ⟩

You never read $⟨ A ⟩$ directly; you estimate it from repeated measurements, with sampling error that shrinks like the inverse square root of the shot count. That single fact drives the economics of the whole approach. Estimating one objective may require summing many measured terms, each optimizer step needs its own estimates, and gradient-based training multiplies the cost again. A shallow circuit with a cheap price per run can still be an expensive algorithm.

For evaluating claims rather than running them, this book uses a decision checklist:

application_score = evidence_strength - baseline_gap - integration_risk - hardware_risk

It is not a law of nature. It is a forcing device: any memo that wants a build or invest decision must name its evidence, its baseline, and its risks explicitly.

Worked example: critiquing a quantum ML claim

A weak claim says:

Our variational quantum model outperforms classical machine learning.

A working critique replaces it with questions:

Task. What prediction, optimization, or simulation problem, exactly?
Metric. What score defines "outperforms"?
Dataset. How is data loaded, and how was it split?
Baseline. Which classical models were tried, and were they tuned as hard as the quantum one?
Ansatz. Which circuit family, and why that one?
Objective. Which expectation value is measured?
Noise. Simulator or hardware, and under what noise assumptions?
Validation. Can an outsider reproduce the result?
Decision. What evidence would change the conclusion?

Any claim that survives those questions is worth a second look. Most dissolve somewhere around "baseline."

Where the claims fail

The first trap is treating the words "hybrid" or "near-term" as evidence. They describe an architecture, not a result. The burden of proof never moves: beat a strong, tuned classical baseline on a task someone cares about, at a cost someone would pay.

The second trap is ignoring the known pathologies. Barren plateaus can flatten the objective's gradients until training stalls. Optimizer sensitivity means results can depend on initialization luck. And the shot cost of accurate estimation can turn a five-minute demo into a five-day campaign. A circuit can be shallow, fast to execute, and still untrainable or unaffordable.

The engineering view

If you have trained classical models, you already own most of the mental machinery. A variational algorithm is a noisy, expensive training loop:

choose an ansatz,
prepare the parameterized circuit,
measure the objective terms,
estimate gradients or use derivative-free updates,
optimize classically,
validate against the baseline,
repeat under noise and sampling limits.

Every step can inject bias, variance, or hidden cost. Standard ML discipline applies unchanged: held-out test sets, honest baselines, ablations, reproducibility, and metric choice that matches the buyer's problem. The quantum part adds exactly one new virtue to cultivate — counting circuit evaluations — and removes none of the old ones.

What this buys you in diligence

When a variational-algorithm startup or project asks for your money or your roadmap slot, ask four things. Is the baseline current and tuned? Is the data loading realistic, or does it assume an oracle nobody has? Do the hardware runs carry statistical weight, or are they a handful of shots on a good day? Does performance survive ablations?

If the evidence is a small simulator demo against weak baselines, the right decision is usually monitor or wait — and that is a fine answer. The discipline is not anti-quantum; it is what separates the few claims worth funding from the many that are not.

Exercise

Build an application baseline scorecard. Take one variational claim — a paper, a pitch, a blog post — and map it into ansatz, objective, optimizer, measurement plan, and validation path.

Baseline: name the best classical method the quantum workflow must beat, and how hard it was tuned.
Write: a scorecard using the application-score checklist: evidence strength, baseline gap, integration risk, hardware risk.
Check: describe the measured expectation value and its sampling burden, instead of quoting only a final accuracy number.
Decide: label the claim build, partner, monitor, wait, or avoid — and state which missing evidence would change the label.

Check your understanding

Without notes, critique a variational-algorithm claim by naming its ansatz, objective, baseline, noise assumption, and evidence gap. A passing answer spends more words on the baseline and the shot budget than on the circuit.

Oral defense: explain to a skeptical ML engineer why "the quantum layer is differentiable" is not, by itself, evidence of advantage.

If you get stuck

If your critique starts with the quantum method and never reaches the buyer's problem or the classical baseline, revisit Chapter 34 (Hamiltonian Simulation) for the workload-definition pattern — name the task, the precision, and the cost before believing anything — and Chapter 22 (Circuit Cost: Depth, Width, Gate Set, Connectivity) for the vocabulary to price the circuit.