Quantum Machine Learning Examples: Hands-On Starter Projects with Qiskit and Cirq

Quantum machine learning gets a lot of hype, but the most useful way to approach it is as a set of small, testable experiments. If you are a developer, the fastest path to understanding QML is not memorizing theory first; it is building a few starter projects, measuring them honestly, and learning where quantum methods do and do not help. This guide walks through practical quantum machine learning examples using both quantum industry trends and hands-on workflows that mirror how teams evaluate modern tools in production-like settings. It also connects the learning path to broader quantum developer guides and realistic project framing so you can avoid the common trap of building demos that look impressive but tell you very little.

We will use Qiskit and Cirq because they are widely used, well documented, and practical for small experiments. You will see how to choose datasets, encode classical data into qubits, train simple models such as QSVM and VQC, and evaluate results against baselines. If you have ever wanted a Qiskit tutorial that feels like an engineering playbook instead of a toy demo, this is that guide. We will also compare how the same starter idea looks in Cirq so you can decide which stack fits your team’s workflow, simulator access, and long-term goals.

Pro tip: the best QML starter project is not the one with the most qubits. It is the one with a clear metric, a small dataset, and a baseline that is easy to beat—or easy to prove you cannot beat. That honesty is what turns a prototype into a credible engineering learning exercise.

1. What QML Is Good For, and What It Is Not

1.1 Start with the right mental model

Quantum machine learning is not a universal replacement for classical ML. In practice, most current QML work explores whether quantum circuits can represent certain functions compactly, or whether they can accelerate specific subroutines on specialized problems. That means QML is often most useful as an exploratory tool for learning representations, circuit design, and hybrid workflows. If your goal is production-grade fraud detection or image classification tomorrow morning, classical ML is still the default choice.

A good mindset is to treat QML like a research-backed sandbox for developers. This is similar to how teams in other technical domains use structured experimentation and proof-of-value before scaling an initiative. If you need a model for how to present technical work to stakeholders, the logic is close to the approach described in from portfolio to proof: define the outcome, measure it, and show the evidence rather than the buzzwords. QML becomes compelling when you can explain why a quantum approach was selected and what it achieved relative to a baseline.

1.2 Where quantum methods may help

There are a few promising areas where QML experiments are worth your time. Small-scale classification on structured datasets can help you understand feature maps and circuit expressivity. Kernel methods can be interesting when your feature space is rich and you want to test whether a quantum feature map changes separability. Variational models can also be useful as a learning playground for hybrid optimization, especially if you are interested in how parameterized circuits behave under noise and limited depth.

These experiments are less about claiming immediate quantum advantage and more about learning the shape of the toolchain. If you have worked on on-device AI, you already know that constraints can be a feature: limited resources force you to reason carefully about architecture, latency, and tradeoffs. QML imposes a similar discipline. The best projects are small enough to reason about, yet rich enough to expose the core mechanics of data encoding, circuit construction, and evaluation.

1.3 Where it is usually not appropriate

QML is usually not appropriate when you need a large-scale, low-latency, highly explainable model with stable deterministic training behavior. It is also not a great fit when your dataset is huge and noisy and the only metric that matters is throughput. In many cases, you will spend more time managing simulator limits, transpilation choices, and parameter tuning than you would solving the business problem directly. That does not make QML useless; it simply means the project must be framed as an exploration rather than a shortcut.

Think about QML the way procurement teams think about emerging platforms: the right question is not “is this advanced?” but “does this solve the specific problem better than the simpler alternative?” That mindset aligns with careful technical decision-making in areas like outcome-based procurement for AI systems, where the proof has to match the promised outcome. For QML, the proof is often educational, comparative, and methodical—not magical.

2. Starter Project 1: Binary Classification with QSVM

2.1 Project objective and dataset choice

The simplest and most educational starter project is a binary classification task using a Quantum Support Vector Machine (QSVM). Your objective is to classify two classes using a small dataset that can be visualized in 2D or 3D. Great candidates include a slice of the Iris dataset, synthetic moons, or a tiny subset of another tabular dataset with two informative features. The point is to keep the problem small enough that you can see whether the quantum feature map is doing anything useful.

A practical way to define the experiment is: “Can a quantum kernel separate these classes as well as a classical RBF kernel?” That gives you a baseline, a quantum variant, and a clear metric such as accuracy or F1. If you need a reminder that good technical content depends on the right framing, the logic is very close to the discipline used in high-quality comparison content: the setup has to be fair, narrow, and measurable.

2.2 Qiskit example: quantum kernel workflow

Below is a compact Qiskit-style workflow you can adapt. In practice, you will use a small dataset and a feature map like ZZFeatureMap. The kernel matrix is computed on a simulator or managed backend, and then a classical SVM uses that kernel matrix for classification.

import numpy as np
from sklearn.datasets import make_moons
from sklearn.model_selection import train_test_split
from sklearn.svm import SVC
from sklearn.metrics import accuracy_score

from qiskit.circuit.library import ZZFeatureMap
from qiskit.primitives import Sampler
from qiskit_machine_learning.kernels import FidelityQuantumKernel

X, y = make_moons(n_samples=60, noise=0.15, random_state=7)
X_train, X_test, y_train, y_test = train_test_split(
    X, y, test_size=0.3, random_state=7, stratify=y
)

feature_map = ZZFeatureMap(feature_dimension=2, reps=2)
sampler = Sampler()
qkernel = FidelityQuantumKernel(feature_map=feature_map, sampler=sampler)

train_kernel = qkernel.evaluate(x_vec=X_train)
test_kernel = qkernel.evaluate(x_vec=X_test, y_vec=X_train)

clf = SVC(kernel='precomputed')
clf.fit(train_kernel, y_train)
preds = clf.predict(test_kernel)
print('accuracy:', accuracy_score(y_test, preds))

What matters here is not the exact code syntax alone, but the workflow. You are encoding classical inputs into a circuit, measuring a similarity matrix, and letting a classical classifier consume that representation. That hybrid pattern is common across many QML experiments. It also mirrors how developers think about integrated systems in guides like developer checklists for compliant middleware: the value comes from the interface and data flow, not just the component itself.

2.3 Evaluation and baseline comparison

For QSVM, compare quantum kernel accuracy against a classical SVM with an RBF kernel. If the quantum result is slightly better on a tiny test set, do not celebrate too quickly; repeat across multiple random seeds and report mean and standard deviation. Accuracy alone can be misleading when classes are imbalanced, so also calculate precision, recall, and F1 score. If you have class probabilities, log AUC as well.

Useful evaluation questions include whether the kernel matrix is well-conditioned, whether performance changes with feature-map depth, and whether the result survives different train/test splits. If your quantum kernel improves one split but fails others, you probably learned about variance rather than advantage. That kind of disciplined analysis is exactly what robust benchmarking culture encourages, similar to the methodology behind a well-instrumented infrastructure playbook.

3. Starter Project 2: Variational Quantum Classifier with VQC

3.1 Why VQC is the right next step

After QSVM, the natural next step is a Variational Quantum Classifier, or VQC. This is a hybrid model where a parameterized quantum circuit is trained to minimize a loss function using a classical optimizer. VQC is especially useful as a learning project because it teaches you about ansatz design, parameter initialization, barren plateaus, and noise sensitivity. It is a stronger bridge between “I can run a circuit” and “I can train a model.”

For developers, VQC is often the first time QML feels like real model engineering. You have inputs, parameters, loss functions, and a loop that looks familiar if you have trained neural nets before. The difference is that the model is implemented as a circuit, and circuit depth can change both expressivity and trainability. That makes it a great candidate for a hands-on QML project that teaches the real tradeoff between circuit complexity and practical performance.

3.2 Qiskit example: building a VQC

Here is an approachable Qiskit implementation using a feature map and ansatz. The exact class names may vary depending on your installed version, but the model structure remains the same: encode the data, run the variational circuit, and optimize against a classification objective.

from qiskit.circuit.library import RealAmplitudes, ZZFeatureMap
from qiskit_machine_learning.algorithms.classifiers import VQC
from qiskit_machine_learning.optimizers import COBYLA
from qiskit_machine_learning.neural_networks import SamplerQNN
from qiskit.primitives import Sampler

feature_map = ZZFeatureMap(feature_dimension=2, reps=1)
ansatz = RealAmplitudes(num_qubits=2, reps=1)
sampler = Sampler()
optimizer = COBYLA(maxiter=50)

vqc = VQC(
    feature_map=feature_map,
    ansatz=ansatz,
    optimizer=optimizer,
    sampler=sampler,
)
vqc.fit(X_train, y_train)
score = vqc.score(X_test, y_test)
print('test score:', score)

When you run this experiment, focus on the full training curve rather than the final score alone. If training is unstable, try fewer repetitions, different optimizers, or better scaling of inputs. If the circuit is too shallow, it may underfit; if too deep, it may be slow or noisy. This is where practical qubit programming starts to feel more like engineering and less like theory.

3.3 What to log during training

For VQC, log the optimizer loss, final accuracy, parameter count, circuit depth, and runtime. If you have access to a simulator benchmark setup, compare the same circuit under different noise models or transpilation settings. Capturing both functional and performance data helps you understand whether the model is learning or merely wandering toward a local minimum. The same habit appears in operational analytics, such as real-time dashboarding, where the right metric at the right time prevents expensive misreads.

4. Starter Project 3: Data Encoding Experiments

4.1 Why encoding matters more than most beginners think

In quantum machine learning, encoding is not a side detail; it is the front door of the entire model. Classical data must be mapped into qubit states using angle encoding, amplitude encoding, basis encoding, or data re-uploading strategies. The same dataset can behave very differently depending on the encoding you choose. That means a “bad” result may reflect a weak encoding strategy rather than an inherently poor quantum approach.

If you are building a serious starter project, test at least two encodings. Angle encoding is usually easiest to reason about because feature values become rotation angles. Amplitude encoding is compact but harder to prepare and often more costly in practice. Data re-uploading can boost expressivity by injecting the same features multiple times across layers, which often works well in small hybrid circuits.

4.2 Practical encoding comparison

A simple experiment is to run the same classification task with angle encoding and compare it to a deeper re-uploading circuit. Measure accuracy, runtime, and circuit depth. If the deeper circuit performs no better, you have learned something important: more quantum complexity does not automatically improve outcomes. That result is not a failure; it is exactly the kind of evidence a good developer should want.

For broader technical context on evaluating tools and tradeoffs, it helps to think the way teams do when they compare platforms with real constraints. The decision process is similar to choosing between devices or configurations in pieces like midrange versus flagship comparisons: the best option is the one that solves your specific problem with the least unnecessary complexity.

4.3 Cirq example: angle encoding with parameterized rotations

Cirq shines when you want a lightweight, explicit circuit-first workflow. You can define a small classifier circuit that uses parameterized rotations to encode features, then simulate measurement outcomes and post-process them classically. This is especially useful for learning the mechanics of qubit programming because the circuit structure is very visible.

import cirq
import numpy as np

q0, q1 = cirq.LineQubit.range(2)

x = np.array([0.2, 1.1])
params = cirq.Symbol('theta')

circuit = cirq.Circuit(
    cirq.ry(x[0])(q0),
    cirq.ry(x[1])(q1),
    cirq.CNOT(q0, q1),
    cirq.rz(params)(q0),
    cirq.measure(q0, q1, key='m')
)

sim = cirq.Simulator()
result = sim.run(circuit, repetitions=100)
print(result)

In Cirq, you often build the model behavior by explicitly designing the circuit and then wrapping optimization around it. That makes it a good fit for teams that want low-level visibility into gate operations and simulation behavior. If you are exploring broader workflow patterns, it can be useful to compare the model-building mindset here with other integration-heavy engineering work such as enterprise app lifecycle changes, where product decisions and platform behavior both matter.

5. Choosing the Right Dataset for a QML Starter Project

5.1 Keep the dataset small, balanced, and interpretable

The best beginner datasets for QML are small, balanced, and easy to visualize. You want to see whether quantum encoding changes the geometry of the problem, so a dataset with 2-6 features is usually ideal. Two-dimensional synthetic datasets are especially helpful because you can plot them before and after transformation, then compare decision boundaries. If the dataset is too large or too messy, you lose the ability to reason about what the circuit is doing.

Good starter datasets also have a clear baseline result from classical ML. That makes it possible to interpret the quantum model as an experiment instead of a standalone artifact. When you are deciding whether to run a project locally or on a managed cloud stack, the same logic appears in other technical selection guides like a wait-or-buy decision framework: scope first, then pick the right tool.

5.2 Recommended starter datasets

For QSVM, the classic two-moons dataset is excellent because it is non-linear but still small enough to inspect visually. For VQC, a binary Iris subset is a strong option because it is familiar and easy to benchmark. For encoding experiments, synthetic Gaussian blobs can help you test whether your circuit can learn separability under different feature maps. If you want a slightly more realistic tabular task, sample a small subset from a standard classification dataset and reduce it with PCA before encoding.

A useful rule is to start with fewer than 100 samples and no more than 4 encoded features. This keeps simulation times manageable and makes your model easier to debug. If your circuit only works on a heavily engineered subset, that may still be useful as a learning milestone. Just be explicit about the narrow scope when you document the results.

5.3 Data preparation checklist

Normalize your features before encoding, because many circuit encodings assume bounded or scaled inputs. Split your data with stratification so both classes remain represented in train and test sets. Save the exact random seed, preprocessing steps, and train/test split so you can reproduce your results later. This reproducibility discipline matters just as much in QML as it does in other workflow-heavy domains like secure OCR pipelines.

6. Metrics That Actually Matter in QML

6.1 Accuracy is necessary but not sufficient

Accuracy is the easiest metric to report, but it rarely tells the whole story. In QML, you should also evaluate precision, recall, F1 score, ROC AUC, runtime, and circuit complexity. If the model is slower than the classical baseline and only matches accuracy, that may still be a worthwhile educational result, but it is not a compelling performance claim. Always compare against a classical model with the same dataset and a similarly disciplined validation method.

When possible, track variability over multiple trials. QML experiments are sensitive to random seeds, optimization paths, and simulator settings. A model that wins once and loses five times is not ready for stronger claims. This is why careful metrics design is so important in technical content, much like the rigor required when teams turn a research insight into a usable deliverable.

6.2 Quantum-specific metrics to log

Beyond classical ML metrics, quantum experiments should log circuit depth, number of qubits, transpilation level, shot count, and noise settings. If you are using a kernel method, inspect the kernel matrix quality and whether it is numerically stable. If you are using a variational model, look at convergence behavior, parameter sensitivity, and whether training plateaus early. These details help you understand whether a result is robust enough to repeat.

Another useful metric is simulator cost. A quantum simulator benchmark can reveal whether a circuit is tractable at your chosen depth and qubit count. That matters because a model that runs in seconds on two qubits may become impractical as you scale. If you want to think in terms of operational cost and tradeoff visibility, the mindset is similar to real-time visibility tooling: what you measure shapes what you can improve.

6.3 A simple benchmark template

For every experiment, record: dataset, preprocessing, encoding method, model type, optimizer, number of qubits, number of layers, simulator type, shots, metric values, and classical baseline. Then summarize the result in one sentence: “On the two-moons dataset, a 2-qubit VQC with angle encoding achieved X accuracy versus Y for the baseline, with Z runtime.” That level of reporting is enough for a useful portfolio piece and far more credible than vague claims about quantum superiority.

7. Qiskit vs Cirq for QML Starter Projects

7.1 When Qiskit is the better choice

Qiskit is usually the better choice if your goal is to explore a fuller QML stack with ready-made machine learning components. It has a strong ecosystem for feature maps, kernels, variational algorithms, primitives, and access to IBM Quantum backends. That means it is often faster to get from idea to working example. For developers who want a guided starting point, Qiskit feels closer to a complete tutorial path.

Qiskit is also a good fit when you want to compare simulator and hardware behavior with minimal friction. That makes it attractive for teams trying to understand the path from prototype to cloud-executed workflow. It is a little like choosing a platform with enough structure to move quickly without losing control, which is why many teams prefer a framework with a clearer path from demo to deployment.

7.2 When Cirq is the better choice

Cirq is often the better choice if you value explicit circuit control, lightweight abstractions, and strong integration with Google’s quantum ecosystem. It is excellent for learning how gates, moments, and measurements fit together in a circuit. For starter QML projects, Cirq is especially useful when you want to prototype the encoding and measurement pieces yourself rather than leaning on higher-level ML wrappers.

If you are teaching qubit programming fundamentals or building a minimal simulator-first project, Cirq can feel more transparent. That transparency helps when you want to reason about each circuit operation and debug the effect of a single gate. If your team already thinks in circuit diagrams and low-level instrumentation, Cirq can be the cleanest place to start.

7.3 Practical decision table

Choosing between them is less about one being universally better and more about what you want to learn. If you want a structured quantum developer guide with reusable primitives, Qiskit is often the fastest route. If you want deeper visibility into circuit mechanics, Cirq offers a strong foundation. Many teams eventually use both, because the skills are complementary rather than mutually exclusive.

8. Simulator Benchmarking and Performance Reality

8.1 Why simulator benchmarks are part of the project

In quantum computing, simulator performance is not just an implementation detail. It directly affects iteration speed, cost, and how many experiments you can run before you hit practical limits. When you benchmark a circuit, you are learning how depth, qubit count, and shot counts affect runtime and stability. This is one of the most useful skills for anyone exploring quantum technology trends in a practical context.

Benchmarking also helps you avoid false confidence. A tiny circuit may look fast and elegant, but once you add repetitions, noise, or larger feature maps, performance can degrade quickly. Measuring early keeps you honest. It is the same discipline that matters in resilient systems work, where you build for observability before scale becomes painful.

8.2 What to benchmark

Benchmark circuit compile time, execution time, memory use, and parameter sweep cost. If you are comparing Qiskit and Cirq, keep the dataset, encoding, and number of measurement shots constant. Then compare how each framework handles the same experiment. The result may not be that one is “faster” in a universal sense; rather, one may be easier for your specific workflow, hardware target, and debugging style.

For a beginner-friendly benchmark, use a 2-qubit or 3-qubit circuit with 10 to 50 repeated runs. Then increase complexity one step at a time. Watch for performance cliffs when you add entanglement, more encoding layers, or a larger ansatz. This helps you see the real cost of expressivity, which is one of the key lessons in all practical quantum computing work.

8.3 How to report results clearly

Report benchmark results with context: simulator type, machine specs, shot count, transpilation level, and whether you used noise. If you share numbers without that context, they are almost impossible to interpret. A clean benchmark summary should tell another engineer exactly what to reproduce and what to expect. That is the kind of clarity expected in strong technical publishing, similar to the discipline of trustworthy content in infrastructure optimization guides.

9. A Practical Build Path for Your First QML Portfolio Project

9.1 Suggested workflow from idea to publishable project

If you want one portfolio-ready QML project, build it in three phases. First, choose a binary classification dataset and run a classical baseline. Second, implement a QSVM and a VQC, keeping the problem size small. Third, compare results using a consistent set of metrics and document the tradeoffs. That sequence gives you a clear narrative and a credible engineering story.

To make the project feel complete, include visualizations of the dataset, the quantum feature map or circuit, training curves, and a results table. Then write a short reflection section explaining what worked, what didn’t, and what you would try next. This is the difference between a notebook exercise and a real professional artifact. If you need inspiration on turning technical work into something presentation-ready, study how teams transform raw work into measurable outcomes in guides like proof-focused portfolios.

9.2 Good deliverables for developers and IT teams

For technical audiences, the best deliverables are a repository with reproducible code, a concise README, and a notebook or script that can be rerun in under an hour. Include installation instructions, environment setup, and a “results interpretation” section. If you can, add a small benchmark table comparing simulator runtime or backend execution time. That will make your project more useful than a generic demo.

Teams that already build integrated systems may appreciate the structure because it resembles other compliance or workflow-oriented engineering tasks, such as integration checklists. The pattern is the same: define inputs, establish guardrails, measure outputs, and document assumptions. QML rewards this kind of disciplined engineering.

9.3 When to stop and call it “enough”

Stop iterating when further changes only produce marginal metric shifts and no new insight. The goal of a starter project is to learn a set of core patterns: encoding, circuit construction, optimization, evaluation, and benchmark interpretation. If the answer is “QML is not better for this dataset,” that is still a valuable result. In fact, a negative result with a clear explanation is often more credible than a shaky claim of improvement.

That restraint is part of good technical judgment. It keeps your work focused and prevents you from overfitting the project narrative to a preferred conclusion. In the long run, that is how you build trust as a quantum developer.

10. FAQ: Quantum Machine Learning Examples with Qiskit and Cirq

Conclusion: Build Small, Measure Honestly, Learn Fast

The best quantum machine learning examples are not the flashiest ones. They are the ones that teach you how to build a reproducible pipeline, how to choose the right data encoding, and how to judge whether a quantum model is actually useful. Qiskit is often the fastest route for structured starter projects like QSVM and VQC, while Cirq is excellent for circuit-first experimentation and low-level visibility. If you approach QML as an engineering discipline rather than a headline generator, you will learn much more and produce work that is genuinely worth showing.

As you continue, keep your projects small, your metrics honest, and your comparisons fair. Explore the space with curiosity, but document everything like a professional. That is how you go from experimentation to expertise in qubit programming.

Related Reading

• From Research to Revenue: How Quantum Companies Go Public and What That Means for the Market - See how the quantum ecosystem is maturing from lab work to commercial adoption.
• Branding Your School's Quantum Club: Using Qubit Kits to Build Identity and Engagement - A practical look at making quantum ideas accessible to new learners.
• Veeva + Epic Integration: A Developer's Checklist for Building Compliant Middleware - Useful for thinking about disciplined integration workflows and documentation.
• Infrastructure Choices That Protect Page Ranking: Caching, Canonicals, and SRE Playbooks - A strong model for measuring and reporting technical systems responsibly.
• The Evolution of On-Device AI: What It Means for Mobile Development - Helpful context for understanding constrained compute and practical model tradeoffs.