QASM-Eval porta OpenQASM 3 nei benchmark per AI quantum con 100 task di test, 4.000 di training e un risultato che pesa: Llama-3-70B fine-tuned raggiunge l’85% di pass@1, cioè risposte corrette al primo tentativo, sopra GPT-5.2 few-shot al 78%. Il paper, pubblicato su preprint pubblicato su arXiv il 28 aprile 2026 da Zhenxiao Fu, Lei Jiang e Fan Chen, non misura la capacità generica di scrivere codice quantistico: misura se un modello sa completare programmi OpenQASM 3 che parlano con l’hardware.
La tensione è tutta qui. I modelli linguistici di grandi dimensioni (LLM) hanno già imparato a produrre Python, SQL, JavaScript e frammenti Qiskit abbastanza plausibili da entrare nei workflow di sviluppatori e ricercatori. Ma il quantum computing non vive solo di circuiti astratti. Nell’era NISQ, dove i processori quantistici soffrono rumore, decoerenza e calibrazioni instabili, il codice utile deve controllare misure a metà circuito, feedback classico, tempi di esecuzione e impulsi fisici. Se l’AI sbaglia questi livelli, produce un esperimento che non corrisponde alla macchina.
Come funziona OpenQASM 3 oltre i circuiti
OpenQASM 3 è un linguaggio di programmazione quantistica pensato per descrivere non solo una sequenza di gate, ma anche ciò che accade vicino al dispositivo fisico. La specifica ufficiale include tipi classici, misure, istruzioni di timing, delay, barrier, blocchi di calibrazione e descrizioni pulse-level, cioè a livello degli impulsi inviati al dispositivo. In pratica, OpenQASM 3 prova a tenere insieme due mondi che nei tool più alti restano spesso separati: l’intenzione algoritmica e i vincoli del backend quantistico.
Il paper QASM-Eval parte da questo punto tecnico. Gli autori sostengono che i dataset precedenti per LLM e quantum programming restano concentrati sui circuiti, quindi non testano le caratteristiche più difficili del linguaggio: logica classica, scheduling temporale e controllo degli impulsi. QASM-Eval costruisce quattro famiglie di task: 25 di logica classica, 25 di timing, 25 di pulse control e 25 complessi, con scenari come quantum error correction, dynamical decoupling e calibrazione.
“a hardware-aware intermediate representation that links algorithms to physics”
Fonte: dal paper QASM-Eval, arXiv 2605.30358
Ogni problema contiene un programma di sfondo e una sezione TODO in linguaggio naturale che il modello deve trasformare in codice OpenQASM 3 corretto. Gli autori non chiedono al modello di inventare un algoritmo quantistico da zero; gli chiedono di completare la parte critica del programma rispettando oggetti, registri, durate, frame, waveform e condizioni già presenti. È un test vicino al lavoro di chi integra software e hardware quantistico: leggere vincoli, non rompere il contesto, produrre codice eseguibile.
La verifica automatica usa tre livelli. Il primo controlla la sintassi con il parser OpenQASM ufficiale e ispeziona l’AST, l’albero strutturale del programma. Il secondo simula lo stato quantistico finale, usando estensioni costruite sopra Qiskit e QuTiP. Il terzo calcola una timeline virtuale per verificare i vincoli di scheduling. Nei task complessi, un output passa solo se supera sia il controllo sullo stato sia quello sul tempo.
Perché OpenQASM 3 mette in crisi gli LLM generalisti
I risultati sperimentali spiegano perché QASM-Eval è più interessante di un benchmark di nicchia. Nel test complessivo, GPT-5.2 Thinking in zero-shot arriva al 54% di pass@1, DeepSeek-V3 al 37%, Llama-3.3-70B-Instruct al 27% e Llama-3.1-8B-Instruct al 24%. Il numero non dice che questi modelli non sanno programmare. Dice che quando la programmazione entra nello strato hardware-facing del quantum, la familiarità con pattern di codice generici non basta.
La categoria più rivelatrice è quella dei task complessi. Senza esempi, GPT-5.2 passa solo l’8% dei problemi complessi; DeepSeek-V3, Llama-70B e Llama-8B restano tra 0% e 0%. Qui il modello deve allineare logica classica, timing e pulse control nello stesso programma. Basta usare un costrutto valido nel punto sbagliato, applicare una durata incoerente o ignorare una condizione sul frame per fallire.
Il few-shot cambia la traiettoria. Con tre esempi per problema, GPT-5.2 sale dal 54% al 78% complessivo e dall’8% al 64% sui task complessi. Ma il salto più netto arriva dal fine-tuning, cioè l’addestramento mirato del modello su esempi del dominio. Con LoRA su QASM-Eval, Llama-70B raggiunge l’85% complessivo e il 64% sui task complessi. Llama-8B sale dal 24% al 52%, avvicinando GPT-5.2 zero-shot.
Questo dato ridimensiona un’idea comoda: per i domini tecnici basta mettere un modello più grande davanti a documentazione migliore. QASM-Eval suggerisce una risposta diversa. Nei linguaggi dove la sintassi incorpora vincoli fisici, i modelli specializzati possono battere sistemi generalisti più potenti se ricevono esempi costruiti sul dominio giusto.
I limiti di OpenQASM 3 generato dagli LLM
Il paper non vende l’automazione come risolta. Gli autori mostrano che il fine-tuning migliora soprattutto l’eseguibilità sintattica. Per Llama-70B, gli errori di sintassi scendono da 311 nella configurazione base a 91 con few-shot e a 8 dopo fine-tuning su QASM-Eval. È un risultato forte, ma indica anche il confine del progresso: rendere il codice parsabile non significa renderlo sempre fedele all’esperimento.
Le difficoltà si spostano verso semantica e timing. Nei task che richiedono vincoli temporali, il modello deve produrre un programma che non solo compili, ma rispetti una relazione tra operazioni, delay, stretch e durata del backend. Gli autori osservano che Llama-8B non migliora in modo netto sugli errori di timeline, mentre Llama-70B li riduce dopo il fine-tuning. La scala del modello aiuta, ma non elimina il problema.
Anche la verifica ha un margine di incertezza. Il sistema automatico viene confrontato con esperti umani su 100 soluzioni generate da GPT-5.2: i due giudizi coincidono in 92 casi, con un coefficiente di Cohen kappa pari a 0,837. È un buon livello di affidabilità, non una garanzia assoluta. Le 8 divergenze nascono soprattutto da ambiguità nel modo in cui i prompt TODO descrivono il requisito.
La domanda che nessun benchmark può evitare è semplice: quante aziende useranno un assistente AI per generare codice quantistico senza avere un verificatore altrettanto rigoroso accanto al modello? In un ambiente software tradizionale, un test fallito costa tempo. In un laboratorio quantistico, una timeline sbagliata può consumare accesso macchina o produrre dati sperimentali difficili da interpretare.
Cosa cambia per l’Italia tra AI e quantum
Chi segue questo spazio da vicino sa che il punto italiano non è solo avere modelli migliori. È costruire competenze, infrastrutture e procedure in tempo utile perché il quantum non resti confinato nei laboratori. La Strategia italiana per le tecnologie quantistiche, pubblicata dal MUR, identifica quattro assi: sviluppo scientifico e industriale, ecosistema nazionale integrato, internazionalizzazione e sicurezza, governance misurabile. QASM-Eval si inserisce nel secondo e nel quarto: senza strumenti di verifica, formazione e standard tecnici, l’AI nel quantum resta demo.
Il contesto infrastrutturale esiste. CINECA presenta EuroQCS Italy come il primo sistema EuroHPC di quantum computing in Italia, basato su tecnologia ad atomi neutri di Pasqal e integrato con Leonardo al Tecnopolo DAMA di Bologna. Il progetto prevede una roadmap 2026-2029 e un upgrade nel 2027 per operazioni ibride digitali e analogiche. Per università, centri di ricerca e imprese, questo significa che la programmazione quantum-hybrid diventerà meno teorica e più operativa.
Qui un benchmark come QASM-Eval interessa anche fuori dall’accademia. Le aziende italiane che lavorano su materiali, logistica, farmaceutica, energia, cybersecurity o ottimizzazione non compreranno valore dal quantum solo tramite hardware. Avranno bisogno di sviluppatori capaci di collegare modelli AI, simulatori, workflow HPC e QPU, cioè unità di elaborazione quantistica. In questa filiera, OpenQASM 3 può diventare uno dei punti di contatto tra ricerca e applicazioni AI, soprattutto nei settori AI regolati dove verificabilità e tracciabilità contano quanto la performance.
“La mancanza di competenze adeguate frena l’adozione dell’IA”
Fonte: ISTAT, Imprese e ICT 2025
Il dato ISTAT 2025 è il freno da tenere in vista. Le imprese italiane con almeno 10 addetti che usano almeno una tecnologia di IA sono salite al 16,4%, raddoppiando l’8,2% del 2024. Ma tra le aziende che hanno valutato l’AI e poi non hanno investito, il 58,6% indica la mancanza di competenze come ostacolo.
Per i professionisti italiani, la lezione operativa è concreta. Chi sviluppa AI per domini scientifici deve imparare a leggere benchmark non come classifiche, ma come mappe dei punti di rottura: sintassi, semantica, verifica, integrazione con hardware. Chi guida aziende o team R&D deve chiedere fornitori e partner non solo quale modello usano, ma come validano l’output quando il codice controlla processi fisici.
QASM-Eval non dimostra che gli LLM sono pronti a programmare computer quantistici in autonomia. Dimostra qualcosa di più utile: con dati mirati e verificatori seri, un modello specializzato può superare un generalista più potente in un dominio dove la precisione non è un ornamento. Secondo ISTAT, nel 2025 l’83,6% delle imprese italiane con almeno 10 addetti non usa alcuna tecnologia di IA.
Fonti citate
- QASM-Eval: A Dataset to Train and Evaluate LLMs on OpenQASM-3 Beyond Quantum Circuits , arXiv, 28 aprile 2026.
- Content Moderation , arXiv, consultato il 1 giugno 2026.