What Is Quantum Machine Learning?

Educational disclaimer. This is a business-level explainer, not a specification. The method is described by analogy; the papers cited under each claim carry the real thing. Service limits, free tiers and hardware names are snapshots from the day this was written and will drift. Treat the Kipu Quantum Hub and the linked papers as the single source of truth.

The model you have already tuned flat

Somewhere in your organisation there is a model that someone defends in a monthly review. It scores credit applications, or flags a pump before it fails, or ranks compounds before the lab spends a week on them. It works. It has worked for two years. And over the last four quarters it has moved by less than a point.

You have tried the obvious things: more capacity, more trees, a longer hyperparameter search, class weights, calibration. Each pass buys a fraction of a point and costs a week. The learning curve against training-set size has gone flat, which is the clearest signal there is that the constraint has left the model and moved into how your columns present what they hold. Your plateau is a representation limit, not a tuning limit, and tuning cannot fix it, because tuning searches over the features you already have.

So this session is about one instrument aimed at that gap, Kipu's Rimay service, which computes extra input columns for a model you already own. Two things it does not do, both load-bearing. It does not remove the tuning work, it widens the range your tuning has to move in. And it does not substitute for more data, which is the right answer whenever more data exists; it is for the problems where the rows you need are the rare ones, the four hundred failures recorded in nine years, the ninety toxic compounds, the two hundred defaults in a portfolio of good loans.

Rimay is a service you subscribe to on the Kipu Quantum Hub, listed in the same marketplace as Kipu's quantum optimizers. It is a product with a service boundary rather than a paper.

How it works, and where the quantum computer sits

Quantum machine learning is the use of a quantum processor somewhere inside a machine-learning pipeline, whether to represent the data, to fit the model, or to make the prediction. In the form that runs on today's hardware, it writes your existing columns into a lattice of interacting qubits, runs a short pulse sequence over it, and hands back the measured correlations as extra input columns for an ordinary classical model.

The first question a data scientist asks is whether production now depends on a quantum computer, and the answer is no. End-to-end quantum machine learning would put a processor in the request path, so every prediction waits in a hardware queue. That is unusable in industry: queue times you do not control, latency measured in minutes rather than milliseconds, and deployments that are frequently air-gapped or on-premise by policy. Nobody runs a fraud check that way, and neither do we. Feature extraction puts the processor in the training path only. Slow, scheduled, expensive compute in the training path is something your organisation already tolerates, and the surrogate described at the end of this page is what carries the result across to serving.

The second question is how much there is to build, and the answer is one additional call in a pipeline you already run. Data in, enriched columns back, your model unchanged.

A quantum processor computes some columns; a scikit-learn, XGBoost or PyTorch model your team already operates consumes them alongside the columns you already had. The prediction is still made by your model, and what lands on your disk is a NumPy array.

The encoding is one qubit per feature, and that is the whole of it. Nine columns of a predictive-maintenance table become nine qubits, each feature's value setting that qubit's bias, and seventeen columns come back: one measured value per qubit, plus eight feature-pair correlations rather than the thirty-six a full grid would give. Which pairs come back is set by the extraction itself, not by your data, which is why the count grows roughly in step with the feature count instead of with its square, and also why reordering your input columns changes which pairs you get back. The free simulator tier caps you at fifteen features, so nine fits and a wide customer table does not.

Underneath that sits the claim this whole page turns on, and it is deliberately narrow. Rimay re-presents structure that is already there in a form weak models can use better than the original columns. It adds nothing that was not in the table when you uploaded it. It does not discover interactions, it does not recover work a feature engineer did, and any pitch that promises new information is describing something else. Whether the model you intend to feed can use the re-presentation is a separate question, and the answer is a property of that model.

Which models gain, and against what

Two stories fit a gain on a table that already carries expert features, and they carry opposite commercial consequences: did Rimay find the physics, or was it shown them?

We ran the experiment that settles that discovery question, because it is the one an evaluator should demand. Two Rimay extractions on the same 3,000 rows of AI4I 2020, a public predictive-maintenance benchmark, same split, same five models, same nested cross-validation over fifteen splits, Holm-corrected across the family. The only difference between them is whether Rimay's input contained the three features a domain expert had hand-built: a temperature difference, a power term and an overstrain term.

Denied the expert features, nothing. No model shows a significant gain. And there was never anything to find: on this benchmark the expert's temperature difference is literally column one minus column zero, both already present, so the physics is a representation convenience rather than hidden information. A method that claimed to discover it would be claiming to discover a subtraction.

Fed them, the re-presentation beats the expert's own columns, for one model. Naive Bayes gains +0.0394 average precision over the expert-augmented table itself, 0.6650 to 0.7045, at p 6.1e-05 after Holm correction, on a chain that runs 0.5487 raw, 0.6650 with the expert's physics, 0.7045 with Rimay's re-encoding of it. Logistic regression gains +0.0180 and is marginal. Linear SVM is not significant. And the two models with capacity lose significantly: RBF-kernel SVM -0.0506, gradient boosting -0.0476.

There is a live analogy for the shape of that, and it needs its boundary in the same breath. The better your engine is tuned, the more a turbocharger adds: the measured gains are largest on a table that already carries engineered structure, and empty on one that does not. But the analogy stops at the strong models, where this is not a smaller gain, it is a measured loss. Say both halves or say neither.

And the ceiling belongs on the same slide as the gain. Gradient boosting on the expert table alone reaches 0.9420, above every quantum arm in the experiment. The measured gains lift weak models to about 0.70. Nothing here beats the best classical model available on this dataset.

The rule underneath is older than quantum computing. Heaton generated sixteen families of engineered feature and measured how well four regression models reproduced each one unaided; random forests and gradient boosting reproduce almost all of them on their own, having most difficulty with only three (arXiv:1701.07852, v2, 2020). The model you are feeding decides which new columns are worth supplying at all. He tested regression rather than classification, so read it as the frame rather than as a transferred measurement.

The losses have a mechanism, and it is dilution rather than bad signal. Every added column costs variance in the fit. An RBF kernel computes a distance across all dimensions at once, so uninformative width degrades the metric directly; gradient boosting already selects its own split variables, so extra columns mostly add noise to that choice. A model that had already extracted the structure pays the width and receives nothing for it.

And it is one dataset out of four

AI4I is the sole gainer of four benchmarks we tested. On Pima, naive Bayes loses 0.032 and the loss survives Holm. On UNSW-NB15, every model is negative under both protocols. On Cleveland, which has the cleanest column identity of the four and a balanced class prevalence, no positive result survives under any protocol at all. Wherever the AI4I gain is quoted, that second clause has to travel with it. The pattern is consistent with the mechanism rather than mysterious: AI4I is the one table of the four that carried hand-built structure for the extraction to re-present.

One protocol changes the picture without rescuing it. Keeping every raw column and using a Fisher ranking, computed on the training fold only, to decide which quantum columns to add removes the damage on every dataset, where four other selection methods made it worse. But only 2 of 16 cells survive Holm correction, both of them AI4I. That is a measured protocol worth knowing about, not yet a recommendation, and it needs a confirmation run on data that was not used to develop it.

Better results, so quantum advantage?

Here is the number a vendor slide would show you, from a separate campaign of ours: 700 rows, one held-out split of 140 carrying 50 failures, a logistic regression. Failure-class F1 moves from 0.740 to 0.780. Accuracy moves by 2.9 points. Write down what you would expect to survive a proper repeat.

Almost none of it. On the same split the ranking quality barely moves, average precision 0.843 against 0.851, and a McNemar test on the paired predictions counts three rows that only the classical model got right against seven that only the hybrid did. That is p = 0.34. Nothing here is significant.

Two distinct things were being conflated, and separating them is most of the skill. Average precision measures the ranking; F1 and accuracy measure the ranking after you have chosen a threshold. A four-point move at one operating point, on top of a ranking that moved by less than a hundredth, is a threshold artifact. Ask which of the two a quoted improvement is, every time, including when it is ours.

The threshold view cuts the other way too, and it is the commercially interesting direction. Your application does not consume the average of the curve, it consumes one point on it, and that point is usually pinned by the business: a failure you must not miss fixes the recall you have to run at, and everything you then care about is the precision available there, because at a fixed recall extra precision is fewer false alarms per caught failure, and false alarms are what your maintenance crew actually pays for. Two curves that sit nearly on top of each other on average can still differ usefully in the one region you are forced to operate in. So read the curve region-first: fix the recall your cost structure demands, read off the precision of each arm there, and price the difference in your own units. On the run above that reading was not significant either way, which is the honest answer for that campaign; the point is the method, and it is also the reason a whole-curve average can undersell or oversell a model for your specific decision.

The fair estimate needs every row measured. An 80/20 split only ever tests you on 20 percent of what you hold, so most of your data goes into training and is never scored. Predicting every row exactly once, out of fold, from a model that never saw it, recovers the rest. Then correct for the fact that you tried several models: with five candidates, the chance that one of them clears p = 0.05 by luck alone is roughly one in four, and a Holm correction across the family is what stops you from reporting that piece of luck as a result.

What out-of-fold coverage does not do is manufacture a result. Take the 3,000-row run from the section above and score it the other way, at a chosen operating point rather than by ranking, and watch what accumulating coverage does: naive Bayes, the one model whose ranking gain was significant, settles at a stable null, logistic regression's p-value rises rather than falls, and the only sequence that sharpens into significance is the RBF SVM, which crystallises into a clear loss. Coverage does not manufacture significance, it sharpens whatever the truth is. A protocol you would only run if it helped is not a protocol.

The other control is classical. Nystroem kernel approximation and degree-two polynomial expansion manufacture relational columns classically for the price of some CPU time, and on our own probes Rimay came out statistically level with Nystroem. Any quantum feature-extraction claim has to clear that bar, ours included, and an evaluation that compares quantum features only against raw features is measuring the wrong thing.

So a pilot that would settle the question has a specification: enough positives that fold-to-fold variance is smaller than the effect you want, out-of-fold prediction rather than one split, a matched classical expansion and a tuned baseline as controls, a pre-registered metric, and a correction across everything you tried. A vendor who cannot describe their evaluation in those terms is quoting a number that is not yet a result.

What the published evidence supports

Four published results are worth citing, each with its baseline in the same row and its publication status stated.

Read the first row for what it is: it beats a named commercial product on a public third-party benchmark where that product is one of the published baselines, and it is a preprint, so introduce it as one. The third row is the one to quote carefully, because its headline is the quantum-only feature set while everything else on this page is about quantum columns added alongside your own, and that hybrid configuration peaked slightly lower. The fourth is the only peer-reviewed row, and what it establishes is that the pipeline works rather than how much of the result the quantum stage carries.

Two boundaries, stated before anyone else finds them. Our own results are all free simulator, ibm_aer, at 500 or 2,000 shots depending on the run and never a quantum processor; across 346 Rimay executions reachable on the Hub, not one ran on a quantum processor, so no QPU-backed Rimay evidence exists, and the published wins above come from research pipelines rather than from the shipping service. And there are no published Rimay numbers on enterprise business records: no churn, no payment delay, no supplier risk. If your question is what this does on your customer table, nobody has published that and the experiment has to be run.

Feature width is the axis that separates the two. Our nulls sit at nine to fifteen features; the published wins sit at 120 to 156. Sample counts do not separate them, since 171 molecules and 702 images are smaller than our runs. As a capability rather than as evidence, the managed service reaches 25 features on its simulator backend and 133 to 156 qubits on named IBM Heron processors, with up to 20,000 samples; the free simulator tier is 15 features and 3,000 samples. Both expose the shot count as a request parameter.

The surrogate, and why serving stays classical

The architectural promise from the top of this page has a measured version. Kipu's off-line framework runs the quantum processor once, over a small subsample of the training data chosen so that its distribution represents the full set, then trains a lightweight classical surrogate on what came back. Everything after that is classical: ordinary inference latency, ordinary MLOps cadence, no hardware queue at prediction time.

On the published satellite case, the classical surrogate reached the same 87 percent accuracy as the fully quantum pipeline at at least fivefold fewer quantum executions, from a 200-of-1,000 subsample (arXiv:2605.19801, preprint). One bookkeeping note so the page does not double-count: that fully quantum pipeline is the tree-genus result from the table above, re-reported by the surrogate paper as its reference point. The two 87s on this page are one experiment, not two.

Separately, on the breast ultrasound case the surrogate retained AUC 0.932 against the full pipeline's 0.937, and the paper itself flags that as a qualifier. Those are two results on two benchmarks; there is no single percentage that describes the surrogate, and a sentence fusing them would be inventing one. What can go wrong is the subsample, and the paper says so: one that is biased or sparse makes the surrogate extrapolate badly, and inputs falling outside the covered region need to be flagged rather than scored.

Your move

Three ways on, in increasing order of commitment.

The cheapest costs an hour and does not involve us. Take the model that has gone flat, hold its features fixed, and plot the validation metric against training-set size and against model capacity. If it responds, your ceiling is not in the representation and you have saved yourself a project. If it is flat, you have the first half of a business case.

The second is to run the classical control before the quantum one. A degree-two polynomial expansion and a Nystroem kernel approximation take an afternoon between them, and whatever they score is the bar. On our own probes the quantum columns did not clear it.

The one that costs a morning and decides the most is the pilot specification: name the dataset, count the positives, check whether the table already carries engineered structure, name the classical control, name the metric, and write down in advance what result would make you stop. Then check that against the width caps above. If your label count or your column count cannot support the experiment, that is a result worth having in writing, and it is far cheaper to reach here than in month four.

The Rimay product page covers the service boundaries and where it runs. Session two, quantum optimization, covers the evidence discipline this page inherits. The full curriculum is on the Academy page.

The definition, three ways