Il percorso di un algoritmo quantistico
Perché il simulatore non basta.
Quando si sviluppa un algoritmo quantistico, la prima fase di testing avviene quasi sempre su un simulatore classico. È inevitabile: i simulatori sono gratuiti, deterministici, privi di rumore e permettono di ispezionare lo stato interno del sistema in modo impossibile sull’hardware reale. PennyLane offre dispositivi come `default.qubit` (simulatore statevector puro) e `default.mixed` (che permette di modellare il rumore).
Ma un circuito che funziona perfettamente su simulatore può fallire in modo significativo su hardware reale. Non perché il codice sia sbagliato, ma perché i QPU (Quantum Processing Unit) fisici operano in condizioni che il simulatore ideale ignora. Capire questo gap è fondamentale per chiunque voglia portare un algoritmo quantistico dalla ricerca alla produzione.
Le fonti di errore sull'hardware reale.
Decoerenza: i qubit fisici sono sistemi quantistici estremamente fragili. L’interazione con l’ambiente circostante (vibrazioni termiche, campi elettromagnetici, imperfezioni del substrato) causa la perdita progressiva della coerenza quantistica. Ogni qubit ha un tempo di coerenza T1 (rilassamento) e T2 (sfasamento) tipicamente nell’ordine dei microsecondi sui processori superconduttori IBM. I circuiti troppo profondi (con troppe porte sequenziali) non riescono a completare l’esecuzione prima che il sistema decoera.
Errori di gate: nessuna porta quantistica fisica è perfetta. I gate a due qubit (CNOT, CZ) hanno tipicamente una fedeltà del 99-99.5% sui migliori processori attuali — suona molto, ma su un circuito con 50 gate a due qubit l’errore accumulato diventa rilevante.
Shot noise: a differenza di un simulatore statevector che calcola esattamente le probabilità, un QPU reale produce risultati probabilistici. Ogni esecuzione del circuito (shot) produce una misura binaria. Per stimare i valori attesi degli osservabili occorrono centinaia o migliaia di shot, e la varianza statistica influisce sulla precisione dell’ottimizzazione.
Errori di readout: misurare un qubit introduce ulteriori errori. Un qubit nello stato |1⟩ può essere letto come |0⟩ con una certa probabilità, e viceversa. Esistono tecniche di mitigation (readout error mitigation) che correggono questo effetto statisticamente.
Connettività limitata: i qubit di un processore reale non sono tutti connessi tra loro. Su IBM Eagle (127 qubit), la mappa di connettività è un grafo sparso. Una CNOT tra due qubit non adiacenti richiede l’inserimento di porte SWAP aggiuntive, che aumentano la profondità del circuito e l’errore complessivo.
Il pipeline pratico: dalla prototipazione all'esecuzione
Fase 1 — Sviluppo su simulatore statevector
Si parte sempre su `default.qubit` di PennyLane (o equivalente). L’obiettivo è validare la logica del circuito: l’encoding dei dati, la struttura variazionale, la funzione di costo. In questa fase si usano pochi qubit e si verifica che l’ottimizzatore converga.
Fase 2 — Simulatore con noise model
Prima di passare all’hardware, si introduce un modello di rumore realistico. PennyLane permette di usare noise model calibrati sui processori IBM reali tramite integrazione con Qiskit.
Questo step rivela spesso problemi che il simulatore ideale nascondeva: circuiti troppo profondi, parametri ottimizzati per condizioni irrealistiche, encoding incompatibili con l’hardware.
Fase 3 — Transpilazione e ottimizzazione del circuito
Prima di inviare il circuito a un QPU reale, il compilatore lo “transpila”: traduce le porte native del circuito nelle porte fisicamente implementabili dal processore target, e ottimizza il routing dei SWAP. È possibile controllare il livello di ottimizzazione (0–3 in Qiskit). Un circuito ben transpilato può ridurre significativamente il gate count.
Fase 4 — Esecuzione su IBM Quantum
PennyLane supporta l’esecuzione diretta su IBM Quantum tramite il plugin `pennylane-qiskit`. Con un account IBM Quantum (gratuito per ricerca, a pagamento per accesso premium), è possibile inviare job a processori come IBM Eagle, Heron o Falcon.
I job vengono accodati e i risultati restituiti con i conteggi delle misurazioni. Su circuiti variazionali, il loop di ottimizzazione classico interagisce iterativamente con il QPU , ogni step dell’ottimizzatore richiede una o più esecuzioni del circuito.
MLflow per il tracking degli esperimenti.
In un workflow di ricerca quantum, la riproducibilità è critica. MLflow entra qui come sistema di experiment tracking: ogni run registra i parametri iniziali, la struttura del circuito, il backend usato, il noise model, i valori della loss ad ogni iterazione, i parametri finali ottimizzati e i risultati delle misurazioni.
Questo permette di confrontare sistematicamente risultati su simulatore vs hardware reale, identificare regressioni e costruire una knowledge base degli esperimenti condotti nel Quantum Labs.
Il gap simulatore-hardware come campo di ricerca
Ridurre il gap tra performance simulata e performance reale è uno dei problemi aperti più interessanti del quantum computing applicato. Le tecniche di error mitigation (zero-noise extrapolation, probabilistic error cancellation) permettono di correggere parzialmente gli effetti del rumore senza richiedere error correction completa. Nel mio laboratorio applico queste tecniche sistematicamente e i risultati sono parte del workflow che descriverò nei prossimi articoli.