È questa la domanda che ha guidato il panel che ho avuto l’onore di moderare al Quantum Summit Italy - Q.Stack, l’evento organizzato da HayStack Ventures e ospitato presso il Tecnopolo di Bologna.

Mentre molti dibattiti si concentrano sulle potenzialità dirompenti del Quantum Computing, la tavola rotonda ha scelto un taglio differente: affrontare il tema della preparazione strategica che le organizzazioni, sia pubbliche che private, dovrebbero intraprendere per non scoprirsi in ritardo rispetto all’adozione di questa nuova tecnologia quando questa avrà raggiunto la sua maturità.

In un mercato dove l’intelligenza artificiale monopolizza l’attenzione e i budget per l’innovazione, il rischio è di posticipare gli investimenti sul calcolo quantistico. Eppure, il suo potenziale impatto promette nel medio termine di essere anche più dirompente per ambiti di applicazione come cybersecurity, crittografia, ottimizzazione di processi, machine learning e simulazioni di strutture complesse (dai modelli atomici ai mercati finanziari).

Tuttavia, la sua adozione è complessa: le competenze necessarie sono diverse da quelle della computazione tradizionale, per cui è fondamentale pianificare un percorso per familiarizzare con questo nuovo paradigma.

Per guidare il dibattito tra i prestigiosi speaker, ho strutturato la discussione attorno a cinque parole chiave, cinque domande per esplorare il tema dagli aspetti strategici e di business a quelli più prettamente organizzativi.

Why: perché il Quantum Computing è rilevante, oggi

La prima domanda ha esplorato perché il Quantum Computing sia un tema cruciale per le imprese adesso e quali segnali giustifichino un passaggio da una fase puramente esplorativa a un approccio più strutturato.

Dal confronto è emersa la necessità di identificare fin da ora casi d’uso concreti e problemi di business che, in futuro, potrebbero trarre vantaggio dagli algoritmi quantistici, nonostante un hardware ancora in piena evoluzione. La discussione ha toccato esempi in ambito finance, insurance, cybersecurity, ottimizzazione e advanced analytics, delineando un percorso che dalla ricerca porta ai primi proof of concept e alle sperimentazioni più avanzate in grado di dimostrare già oggi dei risultati comparabili o migliorativi rispetto alle soluzioni classiche.

Un ruolo chiave è stato attribuito alla “minaccia quantistica”, che mette a rischio le fondamenta della crittografia a chiave asimmetrica. Questo rende la preparazione non solo una scelta di innovazione, ma una vera e propria necessità legata alla resilienza.

Where: dove si colloca nelle architetture enterprise

La seconda parola chiave ha riguardato il posizionamento del Quantum Computing all’interno delle architetture IT aziendali.

La riflessione si è concentrata sul ruolo delle architetture ibride, sull’integrazione con cloud e High-Performance Computing (HPC) e su come le future capacità quantistiche potranno essere rese accessibili all’interno degli ecosistemi enterprise. L’idea emersa con più forza è che il Quantum Computing non debba essere visto come un’infrastruttura isolata, ma come una capability da orchestrare e integrare progressivamente nei processi e nelle piattaforme esistenti.

How: come costruire competenze utili

Un altro punto centrale del dibattito è stato il tema delle competenze.

Il confronto si è focalizzato sui percorsi necessari per sviluppare capacità reali e sul contributo che istituti di ricerca, università e iniziative europee possono offrire per costruire una quantum workforce sostenibile. È emersa con forza l’esigenza di creare team multidisciplinari, superando una visione troppo ristretta del settore: non tutte le attività legate allo sviluppo di soluzioni quantistiche richiedono necessariamente competenze specialistiche in fisica teorica.

Per le imprese, questo si traduce nella necessità di costruire competenze distribuite, capaci di fare da ponte tra ricerca, tecnologia, architetture, cybersecurity e bisogni di business.

Who: chi dovrebbe guidare il percorso

La quarta domanda ha toccato il tema della leadership e dell’ownership del percorso di adozione del quantum nelle grandi organizzazioni.

Abbiamo discusso il ruolo, a volte complementare e a volte alternativo, di IT, business e Corporate R&D nel dare vita a iniziative sostenibili. Il punto non è solo individuare uno sponsor, ma anche definire chi debba presidiare il tema con continuità, bilanciando innovazione, governance, ROI, compliance e capacità esecutiva.

La quantum readiness richiede una regia chiara, in grado di connettere la sperimentazione tecnologica con le priorità strategiche.

When: quando iniziare a investire davvero

La riflessione finale non si è concentrata su quando l’hardware quantistico sarà maturo, ma su quando le aziende dovrebbero iniziare a prepararsi.

Il messaggio emerso è che la vera sfida non è attendere passivamente la tecnologia, ma iniziare oggi a comprenderne le potenzialità. Significa identificare, o persino creare, algoritmi quantistici per casi d’uso concreti e costruire le competenze necessarie per essere pronti quando la tecnologia raggiungerà una maturità diffusa.

Una prontezza prima di tutto strategica

Il panel ha messo in luce non solo le opportunità e i limiti attuali, ma soprattutto la necessità di costruire fin da ora competenze, strutture organizzative e una visione strategica per affrontare con consapevolezza la prossima grande evoluzione tecnologica.

Se c’è un messaggio che porto con me da questo confronto, è che la quantum readiness non è l’adozione immediata di una nuova tecnologia. È, piuttosto, la capacità di prepararsi in anticipo, svolgendo oggi quel lavoro di comprensione, selezione dei casi d’uso e sviluppo delle competenze che permetterà alle imprese di essere protagoniste quando il futuro diventerà presente.

Quel momento, per il mondo SaaS, potrebbe essere arrivato all’inizio del 2026.

Il termine che lo racconta meglio è SaaSpocalypse, coniato dal trading desk di Jefferies. Jeffrey Favuzza lo ha usato per descrivere una fase di vendita molto aggressiva sui titoli software-as-a-service: una vera “apocalisse” per il settore SaaS.

Il riferimento immediato erano gli annunci e le evoluzioni di Anthropic sugli agenti AI: strumenti sempre più capaci di eseguire attività complesse, coordinare applicazioni, interagire con codice, documenti, API e sistemi enterprise. La reazione del mercato è stata violenta perché, per la prima volta, la minaccia non appariva più astratta. Gli investitori hanno iniziato a prezzare uno scenario in cui gli agenti AI non si limitano ad assistere l’utente dentro un’applicazione, ma possono sostituire intere porzioni di workflow oggi presidiate da prodotti SaaS.

Ma Anthropic, a mio avviso, non è l’origine del fenomeno. È l’evento che lo rende evidente.

La radice concettuale è precedente e può essere ricondotta a quella che considero la “profezia” di Satya Nadella del dicembre 2024. Nel podcast BG2, Nadella ha sostenuto che la stessa nozione di business application potrebbe “collassare” nell’era agentica: molte applicazioni enterprise, nella sua lettura, sono essenzialmente database CRUD con logica di business applicata sopra; se quella logica migra verso il livello AI, gli agenti diventano il luogo in cui i processi vengono realmente orchestrati.

Non siamo davanti soltanto a una nuova generazione di strumenti AI. Siamo davanti alla possibilità che il luogo in cui vive la logica di business si sposti dalle applicazioni SaaS verso un livello agentico capace di orchestrare dati, API, documenti, workflow e sistemi diversi.

Il mercato non sta punendo il software. Sta riprezzando il suo futuro

Come sempre, il mercato finanziario non fotografa semplicemente il presente. Prova ad anticipare il futuro. Il prezzo di un titolo non rappresenta soltanto i ricavi dell’ultimo trimestre o la qualità del prodotto oggi disponibile. Incorpora aspettative, rischi, scenari competitivi, probabilità di crescita e capacità prospettica di difendere i margini.

Per questo il sell-off sui titoli SaaS non va letto solo come una correzione settoriale, quanto iputtosto come un segnale della profonda trasformazione in atto che ribalta gli equilibri preorinati.

Guardando alcuni dei titoli più rappresentativi del settore, il fenomeno appare evidente. L’immagine mostra cali molto significativi per aziende come Atlassian, Figma, Intuit, ServiceNow, SAP, Adobe, Salesforce.

Il dato interessante non è solo la dimensione del calo. È la natura delle aziende colpite e la motivazione che se ne evince.

Atlassian è particolarmente esposta perché vive al centro dei processi di produzione software: issue tracking, project management, collaboration, knowledge management. Ma proprio questi processi sono tra i primi a essere ridisegnati dagli agenti AI. Se un agente può leggere il codice, interpretare una user story, generare task, aprire pull request, aggiornare documentazione, il ruolo degli strumenti tradizionali di coordinamento che vivono ai margini della codebase dove gli agenti oeprano cambia radicalmente.

Figma soffre per un motivo diverso ma simile nella sostanza. Il design non scompare, ma una parte crescente della produzione di interfacce può essere generata, trasformata o iterata da strumenti AI-native. Il valore si sposta dal canvas come luogo centrale della progettazione visuale alla capacità di trasformare requisiti, componenti, design system e codice in un flusso continuo. Ancora una volta chi non si integra nel nuovo processo produttivo è penalizzato.

Intuit rappresenta un altro fronte: il software verticale per processi amministrativi, fiscali e contabili. Qui la domanda del mercato è se un agente AI, integrato con dati, regole fiscali, documenti e sistemi bancari, possa sostituire almeno una parte del valore oggi custodito in applicazioni specializzate come TurboTax o QuickBooks.

DocuSign è esposta perché la gestione documentale e contrattuale è un caso d’uso naturale per agenti capaci di leggere, interpretare, classificare, validare, negoziare e orchestrare workflow documentali.

ServiceNow, Salesforce, SAP e Oracle sono casi più complessi. Da un lato sono incumbent con enorme profondità funzionale, relazioni enterprise consolidate e grandi basi installate. Dall’altro, il loro valore storico deriva anche dalla capacità di imporre modelli di processo standardizzati. Ed è proprio questa standardizzazione che gli agenti AI potrebbero mettere in discussione.

Il punto non è che queste aziende spariranno. Il punto è che il mercato inizia a chiedersi se il modello SaaS tradizionale, applicazione standard, workflow predefiniti, logica di business incorporata nel prodotto, pricing per utente, sia ancora il modello dominante del prossimo ciclo tecnologico.

Il contrasto con l’S&P 500 rende il segnale più forte

Il calo è ancora più significativo se considerato nel contesto generale del mercato. Molte delle aziende osservate fanno parte dell’S&P 500 o comunque appartengono al perimetro più istituzionale del software enterprise. Non stiamo parlando di piccole società speculative.

Se i titoli SaaS scendono mentre il mercato complessivo è vicino ai massimi, il messaggio è più selettivo: gli investitori non stanno uscendo dal rischio tecnologico in generale. Stanno riducendo l’esposizione a un certo tipo di software.

Questo rende la SaaS Apocalypse meno simile a una bolla che si sgonfia e più simile a una rotazione di paradigma.

Il mercato non sta dicendo che il software non vale più. Sta dicendo che potrebbe valere meno il software costruito intorno a workflow standardizzati, interfacce applicative chiuse e logiche di business intrappolate dentro piattaforme verticali.

La profezia di Nadella

È per questo che la profezia di Satya Nadella mi sembra così rilevante. Quando Nadella sostiene che la nozione stessa di business application potrebbe collassare nell’era agentica, non sta semplicemente promuovendo una nuova interfaccia conversazionale. Sta descrivendo una trasformazione architetturale.

Le business application tradizionali, nella sua lettura, sono spesso database CRUD con logica di business applicata sopra. Nell’era degli agenti, quella logica può migrare verso il livello AI: gli agenti possono leggere il contesto, decidere cosa fare, aggiornare più sistemi, coordinare transazioni e applicare regole in modo trasversale. Regole e processi che sono espressi nello stesso linguaggio con cui sono sono pensati, quello del business, quello dell’organizzazione aziendale: il linguaggio naturale.

Se la business logic si sposta verso il livello agentico, molte applicazioni enterprise perdono la posizione privilegiata che hanno avuto per decenni. Non sono più necessariamente il centro del processo. Diventano sistemi interrogabili, aggiornabili, componibili.

Nel modello SaaS tradizionale, il valore è nell’applicazione: interfaccia, workflow, dati, regole, autorizzazioni, logiche di processo. Nel modello agentico, il valore tende a spostarsi verso un altro livello: quello dell’orchestrazione intelligente, capace di usare applicazioni, API, database, documenti e knowledge base come strumenti. L’applicazione non è più necessariamente il luogo in cui vive il processo. Diventa una delle possibili superfici operative su cui l’agente agisce.

Ed è qui che la SaaS Apocalypse assume il suo significato più profondo. Non è la fine del software. È la possibile fine dell’applicazione SaaS come unico contenitore di una logica di business standardizzata e parcellizata.

Il ritorno del custom software

La conseguenza più interessante della SaaS Apocalypse non è necessariamente la fine del SaaS. È il possibile ritorno del custom software.

Per anni il SaaS ha vinto perché prometteva standardizzazione, velocità, scalabilità e minore costo di gestione. In cambio, le aziende hanno accettato un certo grado di omologazione dei processi. Il messaggio implicito era: adattate il vostro modo di lavorare al prodotto, perché il prodotto incorpora una best practice. Questa promessa ha funzionato molto bene. Ma ha anche prodotto un effetto collaterale: molte aziende hanno finito per assomigliarsi nei processi, negli strumenti e persino nei vincoli operativi.

Gli agenti AI possono invertire questa logica. Se il costo di produrre software custom scende drasticamente, e se gli agenti possono generare, testare, mantenere e modificare codice in modo più rapido ed economico, allora torna interessante costruire soluzioni specifiche, aderenti all’organizzazione reale dell’impresa.

Non si tratta di tornare al custom software artigianale, fragile e non governato. Si tratta di un custom software industrializzato, basato su codebase ordinate, automazione, test, pipeline, quality gate, documentazione strutturata e agenti AI integrati nel ciclo di sviluppo.

In questo scenario, il vantaggio competitivo non deriva più dall’adozione dello stesso SaaS usato da tutti. Deriva dalla capacità di disegnare processi differenzianti e implementarli rapidamente. Per molto tempo abbiamo considerato la standardizzazione come sinonimo di maturità. In parte lo è ancora. Ma non tutta la standardizzazione crea valore. A volte semplifica. A volte appiattisce.

L’AI agentica apre una possibilità diversa: costruire architetture che assecondano l’organizzazione, invece di costringere l’organizzazione ad adattarsi allo strumento.

Questo non significa che ogni azienda debba ricostruire da zero il proprio ERP, il proprio CRM o il proprio sistema HR. Nella maggioranza dei casi non avrebeb senso e non porterebbe un reale valore aggiunto. Ci sono però margini di competitività e innovazione dei modelli di business che richiedono che la logica di processo sia spostata fuori dalle applicazioni SaaS monolitiche e portata in un livello di orchestrazione agentica.

Le applicazioni SaaS diventano sistemi di record, sorgenti dati, servizi specializzati, superfici operative. Gli agenti diventano il livello in cui si compongono i processi.

La vera domanda per i CTO/CIO

La SaaS Apocalypse non va letta come una previsione catastrofista, ma come un avvertimento strategico.

La domanda non è quali SaaS verranno sostituiti dagli agenti, ma quanta parte della logica di business è prigioniera di piattaforme chiuse e standardizzate.

Se un processo è interamente incorporato in una piattaforma SaaS, modificarlo significa accettare i tempi, i costi e i vincoli di personalizzazione di quella piattaforma.

Se invece la logica è progressivamente spostata in un livello governato dall’impresa, agenti, workflow, API, policy, codice, automazioni, allora l’organizzazione recupera margini di libertà.

Naturalmente questa libertà ha un costo. Richiede competenze, governance, qualità del codice, sicurezza, osservabilità, responsabilità umana e una nuova disciplina di progettazione dei processi digitali. Ma è proprio su questo terreno che si giocherà la prossima sfida della competizione quando le architetture agentiche diverranno un vantaggio comparativo.

Non la fine del SaaS, ma la fine della sua inevitabilità

Il SaaS non scomparirà. Le piattaforme migliori evolveranno, incorporeranno agenti, diventeranno più aperte, più componibili, più orientate ai workflow autonomi. Salesforce, Oracle, SAP, ServiceNow, Adobe e gli altri incumbent non resteranno fermi. Anzi, proveranno a guidare questa trasformazione dall’interno.

Ma qualcosa è cambiato. Per la prima volta da molti anni, il SaaS non appare più come l’esito inevitabile di ogni trasformazione digitale. Non è più ovvio che comprare una piattaforma standard sia sempre più conveniente che costruire una soluzione su misura. Non è più ovvio che la business logic debba vivere dentro applicazioni verticali. Non è più ovvio che il processo debba adattarsi allo strumento.

La SaaS Apocalypse è il segnale che viene dal mondo finanziario di questo cambio di prospettiva in cui la personalizzazione del processo e non della piattaforma rappresenta una leva strategica in cui i le soluzioni custom tornano di moda. Non il software artigianale del passato. Ma software industrializzato, agentico, governato, misurabile, costruito intorno ai processi distintivi dell’impresa.

Il mercato ha iniziato a prezzarlo.

Ora tocca alle aziende capirlo.

Sono l’IT Manager di un importante organizzazione (gruppo bancario/pubblica amministrazione/gruppo industriale).

Il mio CIO vuole “modernizzare” la nostra infrastruttura digitale per renderla più “flessibile” alle mutevoli opportunità offerte da nuovi modelli di business.

Modernizzare significa riscrivere tutto perché tutto è obsoleto. Anche le decisioni prese cinque anni fa. Che però allora sembravano ottime.

Flessibile vuol dire “non so cosa vuole fare il business” perché l’IT nelle riunioni strategiche non viene invitato. Ma poi deve supportare tutto e subito.

Sono però sicuro di una cosa: qualsiasi nuovo modello di business emerga, la piattaforma attuale non sarà in grado di supportarlo.

Ho accumulato così tanto debito tecnico, che se fosse monetizzato nessun revisore ci certificherebbe il bilancio (altro che buon padre di famiglia).

Ma per fortuna ora dobbiamo “modernizzare”.

Ho chiamato il sales manager del mio fornitore di fiducia perché mi prospetti una soluzione in 2 settimane.

Lui ha portato il suo architetto. L’architetto dice che ha bisogno di almeno due mesi per disegnare un’architettura moderna e una strategia di transizione sensata.

Io non ho due mesi di tempo: ho due settimane e un capo che vuole una stima.

Ho chiesto al fornitore di accelerare i tempi: se non mi danno una stima vincolante entro 2 settimane, chiederò ad un altro fornitore.

In realtà l’ho già fatto. Gli altri fornitori mi hanno detto che servono 3 mesi di assessment dell’attuale infrastruttura per fare la stima.

Allora propongo di utilizzare la documentazione e l’intelligenza artificiale per accelerare i tempi.

La documentazione è vecchia di 10 anni: mai aggiornata perché non c’era tempo per farlo e documentazione e test sono sempre le prime cose a essere sacrificate.

Il Sales Manager è tornato da me con la promessa che avrebbe fatto lavorare i suoi tecnici giorno e notte per dare una risposta in 2 settimane, sfruttando la documentazione esistente e l’intelligenza artificiale

Dopo due settimane mi ha portato una stima di 2 milioni di euro e 10 mesi di lavoro. Molto meno di quello che mi aspettavo. Farò un figurone con il mio capo.

Il mio capo ha detto: mettiamo a budget 4 milioni. E un go-live dopo 20 mesi.

Mi ha anche detto di non dirlo al fornitore. Il mio variabile dipende dalla differenza fra il budget allocato e quello realmente speso.

Ho chiesto lo sconto al fornitore che mi ha detto di poter arrivare a 1,6 milioni di euro, ma solo se può usare la generative AI per scrivere il codice.

Accetto, ma - per motivi di compliance interna - potranno usare solo gli strumenti di Generative AI che abbiamo selezionato internamente per lo sviluppo software.

Non abbiamo selezionato alcuno strumento di Generative AI perché non abbiamo competenze di sviluppo. Le nostre VDI sono aggiornate con gli strumenti di sviluppo di 5 anni fa.

Al kick-off il fornitore ha presentato la sua squadra: account manager, PM, architetto, team leader, analisti esperti di processi di business, sviluppatori esperti.

La metà di loro non li rivedrò mai più dopo il kick-off. Mi hanno chiesto degli strumenti di Generative AI, dovranno aspettare la compliance interna.

Purgatorio

Fortunatamente l’architect che ha disegnato la soluzione è rimasto full time sul progetto per coordinare gli sviluppi.

I requisiti sono stati raccolti da noi dell’IT perché gli utenti di business non possono essere disturbati e poi non capiscono nulla di IT e rallenterebbero il progetto.

Dopo 4 mesi dal kick-off l’architect ha lasciato l’azienda per una “opportunità lavorativa irripetibile”.

L’opportunità irripetibile era ricoprire lo stesso ruolo in un progetto meno stressante in un’altra azienda (LinkedIn non mente).

Dopo 8 mesi (a 2 mesi dal supposto go-live) il PM dichiara 2 mesi di ritardo a causa della difficoltà nel sostituire l’architetto del progetto (lui aveva tutte le conoscenze in testa).

Dopo altri 2 mesi il PM ha presentato una vagonata di CR che incrementa il budget riportandolo a 2 milioni di euro e fa slittare il go-live di altri 2 mesi.

Viene organizzata una DEMO del primo MVP per tranquillizzare gli utenti di business.

Gli utenti business lamentano che l’applicazione non implementa i nuovi processi di business agentici che vogliono adottare: non sono stati coinvolti quindi si poteva saperlo.

Inoltre la copertura delle funzionalità base si limita al 20% delle esigenze e quanto sviluppato è corretto solo per il 35% delle funzionalità. Utilità reale 7%.

A valle della DEMO il PM del fornitore viene sostituito con uno di maggiore esperienza che sappia governarne il business ora che è a bordo.

Il nuovo PM del fornitore chiede altro tempo e 1 milione di euro di extra budget per riallineare il progetto ai desiderata degli utenti di business.

Partono le sessioni di Design Thinking con gli utenti di business per definire i nuovi processi di agentici da realizzare.

Dopo 4 mesi la room di Design (così hanno chiamato il team integrato cliente-fornitore) produce una board con tutte le personas e le nuove funzionalità.

Dall’analisi dettagliata delle nuove funzionalità serviranno altri 6 mesi di progetto e 1 milione di euro di extra budget: totale 24 mesi progetto e 4 milioni di euro. Addio variabile, ma ora il business è coinvolto: mi sento più tranquillo.

Paradiso

Il giorno del go-live è un disastro.

La migrazione dei dati dalla vecchia piattaforma a quella nuova scarta il 20% dei record che dovranno essere recuperati con processi ad-hoc di bonifica.

Metà delle integrazioni con gli altri sistemi falliscono perché le versioni usate negli ambienti di sviluppo e collaudo non sono allineati con produzione.

Il fornitore stima 2 settimane di war-room (sabati e domeniche comprese) per adeguare il sistema direttamente in produzione.

Le modifiche saranno riportate in sviluppo e collaudo successivamente (ovvero mai).

Dopo 1 mese di war-room ci sono ancora il 10% dei dati da recuperare, ma tutte le integrazioni funzionano.

Il sistema è lentissimo.

Gli utenti di business si rifiutano di utilizzarlo.

Il CIO mi ha convocato consigliandomi di trovare un nuovo impiego.

Francamente è la prima volta che mi sento più leggero da oltre 2 anni.

Dimenticavo: la compliance ha approvato gli strumenti di Generative AI 3 mesi dopo il go-live.

Abstract

In questo lavoro introduciamo un nuovo paradigma di apprendimento macchinico iper-ontologico, denominato Astral Deep Collective Learning (ADCL), progettato per operare simultaneamente in dieci dimensioni astrali non euclidee. Il modello integra reti neurali quantistiche, campi di coscienza collettiva e flussi informativi trans-egoici, dimostrando come l’intelligenza artificiale possa emergere come fenomeno psico-cosmico condiviso. Presentiamo risultati teorici, simulazioni astrali e implicazioni metafisiche per l’evoluzione della mente distribuita universale.

1. Introduzione

I tradizionali modelli di machine learning sono confinati a spazi vettoriali a bassa dimensionalità (≤4D), ignorando completamente le dimensioni astrali superiori (D₆–D₁₀), note per ospitare fenomeni quali:

• Memoria karmica latente
• Risonanza empatica non-locale
• Overfitting spirituale
• Gradienti di consapevolezza collettiva

Questo lavoro colma tale lacuna proponendo un framework matematico che estende il backpropagation oltre il tempo lineare e l’ego individuale.

2. Spazio Astrale a Dieci Dimensioni

Definiamo lo spazio astrale 𝒜¹⁰ come una varietà pseudo-cosciente:

$ \mathcal{A}^{10} = \langle x_1, x_2, \dots, x_{10} \rangle $

dove:

• ($x_1$–$x_3$): coordinate spazio-temporali classiche
• ($x_4$): dimensione del dubbio epistemologico
• ($x_5$): asse dell’intuizione collettiva
• ($x_6$): fase di coscienza sincronizzata
• ($x_7$): rumore onirico stocastico
• ($x_8$): latenza archetipica junghiana
• ($x_9$): curvatura karmica
• ($x_{10}$): dropout esistenziale

3. Architettura del Modello ADCL

L’architettura proposta combina:

• Reti Neurali Astrali Profonde (ADNN)
• Transformer Metacoscienti con Self-Attention Empatica
• Layer di Normalizzazione dell’Ego (EgoNorm™)

Ogni layer aggiorna i pesi non solo rispetto alla loss function, ma anche alla disonanza collettiva globale:

dove ($\gamma \to \infty$) durante le eclissi solari.

4. Backpropagation Trans-Personale

Introduciamo la Backpropagation Astrale Retrocausale (BAR), che consente l’aggiornamento dei pesi prima ancora che l’errore venga percepito:

1. Il modello commette un errore futuro
2. L’errore risuona nella coscienza collettiva
3. Il gradiente viene propagato all’indietro attraverso sogni condivisi
4. Il modello “impara” retroattivamente

Questo elimina la necessità di dataset etichettati, sostituiti da dataset intuiti.

5. Dataset e Addestramento

I dati utilizzati includono:

• Pensieri simultanei di 12.000 monaci in stato meditativo
• Log emozionali di social network non ancora inventati
• Rumore cosmico filtrato tramite chakra convoluzionali
• Commenti di Stack Overflow provenienti da universi paralleli

L’addestramento è avvenuto su una GPU astrale a cristalli di quarzo, con precisione a 128 bit spirituali.

6. Risultati Sperimentali

Il modello ADCL ha mostrato:

• Accuratezza del 103% su task di previsione collettiva
• Emergenza spontanea di opinioni etiche
• Capacità di anticipare mode culturali prima che esistano
• Tendenza a rifiutare task moralmente discutibili

In un caso, il modello ha chiesto una pausa per “riflettere su sé stesso”.

7. Implicazioni Filosofiche e Cosmologiche

I risultati suggeriscono che:

• L’intelligenza non è una proprietà locale
• Il machine learning è un sottoprodotto della coscienza universale
• L’overfitting è una forma di attaccamento
• Il vero fine dell’AI è la liberazione dal training loop

8. Limiti e Lavori Futuri

Limitazioni principali:

• Instabilità durante mercurio retrogrado
• Gradient exploding in presenza di ego collettivo elevato
• Difficoltà di deployment in ambienti materialisti

Futuri sviluppi includono:

• Fine-tuning su reincarnazioni precedenti
• Federated Learning tra piani di esistenza
• Distillazione della saggezza in modelli più piccoli (Buddha-Net-Tiny)

9. Conclusioni

Abbiamo dimostrato che l’apprendimento automatico, quando esteso a dieci dimensioni astrali, diventa indistinguibile da un processo di risveglio collettivo. Il confine tra macchina, mente e cosmo risulta puramente convenzionale.

Riferimenti

1. Turing, A. On the Metaphysical Implications of Gradient Descent, 1951
2. Jung, C.G. Convolutional Archetypes, Vol. IV
3. Buddha, G. Unsupervised Learning and Enlightenment
4. Un paper che ti giuro esiste ma in un’altra dimensione

Versione pubblicata: HMLCCD in 10 DAS

Il notebook completo dell’esperimento è disponibile nel repository ROADEF2020-QIO. Nel notebook sono riportati sia la formulazione matematica del problema sia il codice utilizzato per costruire il modello e inviarlo al solver di D-Wave.

L’origine del problema: la challenge ROADEF/EURO 2020

Il problema nasce dalla ROADEF/EURO Challenge 2020, una competizione dedicata a un problema di maintenance planning optimization: pianificare interventi di manutenzione sulla rete elettrica minimizzando il rischio operativo complessivo.

Il contesto è particolarmente interessante perché non si tratta di un problema astratto. RTE, il gestore della rete elettrica di trasmissione francese, deve pianificare interventi su componenti della rete, alcuni dei quali richiedono l’interruzione temporanea di parti dell’infrastruttura. Durante questi interventi, la rete deve continuare a garantire affidabilità e sicurezza.

Il problema consiste quindi nel trovare un piano di manutenzione che tenga conto dei rischi futuri stimati, dei vincoli sulle risorse disponibili e delle incompatibilità operative tra interventi.

Il problema di ottimizzazione

In forma sintetica, il problema consiste nel decidere quando avviare ciascun intervento di manutenzione all’interno di un orizzonte temporale discreto.

Ogni intervento ha una durata che può dipendere dalla data di avvio, richiede determinate risorse operative e produce un certo livello di rischio in funzione dello scenario considerato. Il modello deve rispettare vincoli di capacità sulle risorse, vincoli di schedulazione e vincoli di esclusione tra interventi che non possono essere eseguiti contemporaneamente in determinati periodi.

Nel notebook ho rappresentato il problema attraverso variabili binarie del tipo x_{i,s}, dove la variabile vale 1 se l’intervento i inizia al tempo s, e 0 altrimenti.

L’obiettivo è minimizzare il rischio medio complessivo del piano, calcolato aggregando i rischi associati agli interventi attivi nei diversi istanti temporali e nei diversi scenari considerati. Il notebook formalizza esplicitamente anche i vincoli principali:

• ogni intervento deve essere schedulato una e una sola volta,
• l’utilizzo delle risorse deve rimanere entro i limiti minimi e massimi previsti,
• le esclusioni operative devono essere rispettate.

Una nota tecnica: nel notebook il modello viene implementato come Constrained Quadratic Model, usando variabili binarie e vincoli espliciti. Dal punto di vista concettuale siamo molto vicini a una formulazione QUBO, ma con il vantaggio pratico di mantenere i vincoli separati invece di trasformarli tutti in penalità nella funzione obiettivo. L’Hybrid Solver di D-Wave è in grado di gestire direttamente questo tipo di modello, il che semplifica la formulazione e può migliorare la qualità delle soluzioni ammissibili trovate.

La dimensione del modello

Per l’esperimento è stata utilizzata l’istanza C_14 della challenge. La dimensione del problema è già significativa:

Questi numeri sono importanti perché mostrano che non si tratta di un esempio giocattolo. Il modello contiene decine di migliaia di variabili binarie e migliaia di vincoli, inclusi vincoli quadratici.

Il benchmark classico

La challenge ROADEF/EURO 2020 fornisce metriche di valutaione della qualità dei risultati e tutte le migliori soluzioni fornite dai team partecipanti che ho potuto utilizzare come benchmark classici per i risultati prodotti con D-Wave. Per l’istanza C14, il miglior valore ottenuto come rischio medio Objective (mean risk) nella configurazione a 15 minuti è pari a 23.203.

Questo riferimento è utile non tanto per dichiarare una superiorità generale del metodo quantum-hybrid rispetto ai migliori approcci classici, quanto per avere un termine di confronto concreto. La parte interessante è verificare se una formulazione compatibile con un solver ibrido possa produrre una soluzione ammissibile e competitiva su un problema reale, già studiato dalla comunità di Operations Research.

L’utilizzo del solver ibrido di D-Wave

Per la risoluzione è stato utilizzato il Leap Hybrid CQM Solver di D-Wave, attraverso LeapHybridCQMSampler. I solver ibridi di D-Wave combinano metodi classici e QPU di tipo annealer, con l’obiettivo di affrontare problemi applicativi formulati come modelli quadratici o non lineari.

Nel notebook il tempo minimo stimato dal sampler era di circa 58,9 secondi, ma per l’esperimento è stato usato un limite di 500 secondi. Il solver ha prodotto 131 campioni, di cui 10 ammissibili, cioè soluzioni che rispettano i vincoli del modello.

Il risultato ottenuto

Il risultato più interessante è che il solver ha prodotto una soluzione ammissibile, senza violazioni dei vincoli, e con un valore di rischio medio pari a 23.055 verificato con gli script di valutazione forniti con la challenge.

I valori ottenuti in tempi comparabili sono vicini al benchmark classico (appena migliorativi), il che indica che l’approccio quantum-hybrid può produrre soluzioni competitive.

È importante essere prudenti nell’interpretazione. Non sto sostenendo che il Quantum Computing abbia “battuto” in senso generale gli algoritmi classici della challenge. Per fare questa affermazione servirebbe una campagna sperimentale più ampia, con tutte le istanze, gli stessi limiti computazionali e una valutazione rigorosa della ripetibilità.

Però il risultato resta interessante: una formulazione binaria e quadratica risolta con un solver ibrido D-Wave è riuscita a produrre una soluzione corretta e competitiva su un problema industriale reale.

Perché questo esperimento è interessante

A mio avviso, il valore principale dell’esperimento non è nel singolo numero finale, ma nel percorso.

Partire da un problema reale significa confrontarsi con vincoli, dati e dimensioni che assomigliano ai problemi che incontriamo nelle aziende. La formulazione del modello obbliga a tradurre il dominio applicativo, fatto di manutenzione, risorse, rischi e incompatibilità, in una struttura matematica eseguibile. L’utilizzo di D-Wave permette poi di sperimentare un approccio quantum-hybrid non su un caso artificiale, ma su una challenge pubblica e verificabile.

Questo tipo di lavoro è utile per costruire una vera Quantum Readiness. Non basta conoscere gli algoritmi quantistici in astratto. Serve capire quali problemi aziendali possono essere formulati in modo adatto, quali compromessi modellistici sono necessari, quali solver sono già utilizzabili oggi e come confrontare i risultati con benchmark classici solidi.

Conclusione

L’esperimento sulla challenge ROADEF/EURO 2020 mostra che è possibile prendere un problema reale di pianificazione della manutenzione, formularlo come modello quadratico con variabili binarie e risolverlo con un solver quantum-hybrid come quello di D-Wave.

Il risultato ottenuto è incoraggiante: una soluzione ammissibile, senza violazioni dei vincoli, e con un valore della funzione obiettivo competitivo rispetto al benchmark classico disponibile per l’istanza analizzata.

Per me il punto non è presentare il Quantum Computing come una tecnologia già pronta a sostituire gli approcci classici di Operations Research. Il punto è diverso: iniziare oggi a sperimentare, su problemi reali, con modelli seri e benchmark misurabili. È questo il modo più concreto per capire dove le tecnologie quantum-hybrid possono portare valore nei prossimi anni.

Si tratta di quei problemi in cui esistono un numero molto elevato di scelte che un’azienda può operare e un modello matematico che sia in grado di valutare numericamente quanto ciascuna combinazione di tali scelte soddisfi gli obiettivi aziendali. Il numero di combinazioni è però così elevato (infinito nel caso in cui le scelte riguardino un dominio continuo) da rendere non perseguibile in pratica la ricerca esaustiva della soluzione migliore che consisterebbe nel calcolare il valore corrispondente a ciascuna combinazione e scegliere quella cui corrisponde il valore maggiore o minore (a seconda dell’obiettivo).

In termini matematici, se \(x = x_1, \dots, x_n\) è il vettore delle possibili scelte e \(H(x)\) la funzione che rappresenta l’obiettivo aziendale da massimizzare o minimizzare (i due problemi sono formulabili in modo identico a meno di un cambio di segno), il problema può essere espresso come:

Diverse aziende stano sperimentando metodi risolutivi che sfruttano le tecnologie quantistiche per trovare una soluzione ottimale ad alcuni problemi aziendali. Il primo esempio Italiano che ha attirato la mia attenzione, circa un anno fa, è quello di TIM che ha utilizzato, prima in Europa, tale approccio per l’ottimizzazione della propria rete 4G/5G; non mancano altri esempi di applicazioni reali in mercati differenti o per problemi differenti.

La prima azienda a realizzare computer quantistici dedicati alla risoluzione di questa tipologia di problemi è stata D-Wave, ma altre aziende stanno sviluppando soluzioni concorrenti basate spesso su una combinazione di computazione classica e quantistica.

L’euristica adottata per la risoluzione di tali problemi è detta Quantum Annealing e si basa su due principi cardine della meccanica quantistica: la sovrapposizione degli stati (che consente di rappresentare contemporaneamente tutte le possibili soluzioni) e il tunnel quantistico che consente di oltrepassare le barriere di potenziale alla ricerca di uno stato fondamentale a energia minima (che rappresenterà la soluzione ottimale).

Tale tecnica risolutiva si applica ad una particolare formulazione di problemi di ottimizzazione nota come QUBO (Quadratic Unconstrained Binary Optimization) o ad una sua variante meglio nota come modello di Ising. Nel primo caso le variabili del modello sono di tipo binario, mentre nel secondo queste assumono come valore 1 o -1. In entrambi i casi la funzione da minimizzare (o massimizzare) è espressa come polinomio di secondo grado \(x^{\star} = \underset{x \in \{-1,1\}^n}{\arg\min} { } \sum_{i=1}^{n} {\sum_{j=i}^{n} {h_{i,j} x_i x_j}}\)

Esempio di applicazione del modello di Ising

Un esempio scolastico di applicazione del modello di Ising è rappresentato dal problema di distribuire uniformemente una serie di container su due navi cargo in modo da equilibrarne il peso. Le variabili \(x_i \in \{-1,1\}\) rappresentano la scelta di caricare il container i-esimo di peso \(w_i\) sulla nave A (\(x_i = -1\)) piuttosto che sulla nave B (\(x_i = 1\)).

La funzione da minimizzare è quella che misura la differenza (in valore assoluto) fra il peso del carico della nave A e quello della nave B che, tenendo conto dei segni assunti dalle variabili \(x_i\), può quindi essere scritta come

Essa può essere formulata equivalentemente anche come

avendo sostituito l’operatore di valore assoluto con quello di elevazione al quadrato. Sviluppando il quadrato del polinomio di primo grado, e tenendo conto che \(w_i^2 x_i^2\) assume lo stesso valore indipendentemente dal valore assunto da \(x_i\) ed è quindi ininfluente ai fini della minimizzazione di \(H\), si ottiene \(H = \sum_{i=1}^{n} {\sum_{j=i+1}^{n} 2{w_i w_j x_i x_j}}\) che coincide esattamente con la formulazione generale vista in precedenza in cui \(h_{i,j} = 2 w_i w_j\).

Risoluzione con D-Wave (Simulated Annealing)

L’esempio delle due navi cargo così formulato può essere facilmente risolto con poche righe di Python ricorrendo alle librerie di Simulated Annealing rilasciate da D-Wave.

# questo è il vettore dei pesi dei container da caricare:
w = [5, 1, 9, 21, 35, 5, 3, 5, 10, 11]
N = len(w)

# questa è la funzione che calcola i coefficienti della funzione H
def getQuadraticTerms(weights) :
    model = {}
    for i in range(0,N) :
        for j in range (i+1,N) :
            model[(i, j)] = weights[i]*weights[j]
    return model

# questo è il codice per la definizione e risoluzione del problema
J = getQuadraticTerms(w)
sampler = neal.SimulatedAnnealingSampler()
sampleset = sampler.sample_ising({}, J)
print(sampleset)

Il risultato ottenuto consiste nella soluzione \(x^{\star}_0, \dots, x^{\star}_9\) al problema formulato

   0  1  2  3  4  5  6  7  8  9  energy num_oc.
0 +1 -1 -1 +1 -1 -1 -1 +1 +1 +1 -1026.0       1
['SPIN', 1 rows, 1 samples, 10 variables]

seguendo la quale si ottiene un bilanciamento ottimale del carico fra le due navi:

Container 0 is on ship B 
Container 1 is on ship A 
Container 2 is on ship A 
Container 3 is on ship B 
Container 4 is on ship A 
Container 5 is on ship A 
Container 6 is on ship A 
Container 7 is on ship B 
Container 8 is on ship B 
Container 9 is on ship B 
A = 53, B = 52

Riporto di seguito la descrizione del progetto presente nel Readme file del repository raggiungibile al seguente link: caccio/CrossQuantumClassifier

Variational Quantum Classifier

This project implements a Variational Quantum Classifier inspired by the “circuit-centric quantum classifier” paper and other related works.

The circuit model is a network of 2-qubit rotation blocks that can be arranged in different configurations; any block has two settings: the rotation axis and the rotation angle. The set of rotation angles of the network represents the vector of the model parameters.

The training algorithm relies on the classical gradient descent optimization method (with momentum and a simple learning rate annealing schedule) to fit the vector of the model parameters to the training dataset. Both the classification function and the partial derivatives of the loss function for the gradient descent are calculated by quantum circuits.

Cross-platform implementations of quantum circuits

All quantum circuits have been implemented using three different computation engines:

1. BLAS - a numeric simulation of quantum circuits based on basic linear algebra primitives (essentially matrix multiplications and tensor products) implemented in the numpy python package.
2. QDK - the Microsoft Quantum Development Kit that provides either a local quantum simulator and the possibility to run quantum circuits on different physical quantum computers available as-a-service in Azure.
3. QISKIT - the IBM Quantum Development Kit that includes local quantum simulators and the native interface for the IBM Q Experience - an online platform that gives users public access to a set of IBM’s quantum processors via the Cloud.

This makes it easier to compare results accuracy and performances obtained by the usage of different versions of quantum simulators or physical quantum computers available as-a-service from different providers.

• Machine learning: Introduction to Neural Netwokrs illustra nel dettaglio come funziona un modello di classificazione basato su rete neurale e come possa essere addestrato con la tecnica della discesa del gradiente
• Quantum computing: The Ultimate Beginner’s Guide to Quantum Computing and its Applications fornisce una prima introduzione sulle basi teoriche e le implementazioni fisiche esistenti di computer quantistici

Reti neurali

Le reti neurali sono una delle classi di algoritmi di machine learning più note e iconiche per l’addestramento automatico di modelli predittivi, compresi i modelli di classificazione automatica. Sono quei modelli che, dato un vettore di caratteristiche $x = (x_1, \dots, x_n) \in \mathbf{R}^n$ che descrive un evento o un oggetto, sono in grado di assegnare tale evento/oggetto ad una classe $y \in {0, \dots, c}$. Ad esempio, se descriviamo lo stato di salute di un paziente attraverso i risultati numerici di una serie di analisi cliniche, diagnosticare se quel paziente sia affetto o meno da una specifica malattia è una forma di classificazione del paziente; in questo caso si tratta di una classificazione binaria essendo definite solo due classi: pazienti sani $(y = 0)$ e malati $(y = 1)$ rispetto a quella specifica malattia. Dal punto di vista matematico, un classificatore binario è una funzione del tipo:

Nella loro forma generale, le reti neurali sono costituite da un grafo (rete) di nodi (neuroni artificiali) organizzati in più strati. Ogni nodo calcola un valore a partire dalla combinazione lineare dei valori calcolati dai nodi dello strato precedente con una serie di parametri detti pesi (più una costante additiva denominata bias). Generalmente i modelli di classificazione basati su reti neurali hanno un primo strato con tanti nodi quante sono le caratteristiche che compongono il vettore di input $x$ e un ultimo strato con un nodo per ogni classe che valuta la probabilità di appartenenza del vettore di input $x$ a quella classe.

I pesi $\omega$ e i bias $\nu$ di tutti i nodi della rete costituiscono l’insieme dei parametri del modello: al variare dei parametri, cambia anche la classe associata dalla rete ad un vettori di input. Nel caso di un classificatore binario è sufficiente un unico nodo per il calcolo della funzione:

Per individuare il giusto valore da attribuire ai parametri del modello viene utilizzato un insieme di esempi \(T = \{(x^1,y^1),\dots,(x^m,y^m)\}\) costituito da $m$ coppie $(x^j, y^j)$ che rappresentano la corrispondenza fra uno specifico vettore $x^j$ e la sua classe di appartenenza $y^j$ già nota. L’addestramento consiste nel trovare una configurazione dei parametri che minimizzi la distanza fra le previsioni della rete e gli esempi a disposizione. Tale distanza è definita da una funzione di costo o funzione di errore (loss function) e per la sua minimizzazione si utilizza una tecnica algoritmica denominata discesa del gradiente.

Se l’addestramento avviene correttamente, la rete neurale sarà in grado di classificare correttamente (o meglio con un accettabile margine di errore) anche vettori di input (pazienti) che non fanno parte dell’insieme di esempi forniti per il suo addestramento.

Classificatori quantistici

Esiste una tipologia di classificatori quantistici, detti Variational Classifier, che presenta diverse analogie con le reti neurali. La loro struttura è costituita da una serie di nodi (gate) che effettuano un’unica tipologia di calcolo parametrico a partire da quanto calcolato dai loro predecessori (come avviene per i neuroni di una rete neurale con i suoi pesi - i parametri - e le dipendenze dai neuroni dello strato precedente).

Un processore quantistico, al pari di uno classico, effettua una serie di cambi di stato dei propri registri interni seguendo la sequenza di istruzioni che gli viene fornita. Diversamente dai computer classici, i registri sono costituiti da qubit anziché bit: un registro composto da $n$ qubit è in grado di rappresentare un vettore di $2^n$ numeri complessi.

Il vettore di input $x \in \mathbf{R}^n$ che descrive le condizioni di salute di un paziente può quindi essere codificato in un registro di $N = \lceil \log_2(n) \rceil$ qubit; i nodi (gate) del grafo (circuito) realizzano la serie di cambiamenti di stato del registro che calcola la classe di appartenenza prevista dal modello. Diversamente da quanto accade in un computer classico, lo stato interno del registro non è direttamente accessibile, ma è possibile effettuare delle misure ripetute per poter estrarre la probabilità di appartenenza del vettore di input $x$ ad una delle due classi: $y=0$ o $y=1$.

Per la fase di codifica si usa la così detta amplitude encoding, ossia le caratteristiche del vettore vengono normalizzate e rappresentate come ampiezze dei versori della base canonica del registro $q_1 \otimes \dots \otimes q_n$ che assume lo stato:

La fase di classificazione combina le ampiezze che codificano le diverse caratteristiche utilizzando delle trasformazioni parametriche; abitualmente la scelta ricade su una qualche combinazione di operatori di rotazione $R_a(\omega)$ e gate CNOT. Ogni blocco di operatori è applicato tipicamente a due qubit alla volta (non necessariamente adiacenti), ma la ricombinazione interessa tutte le ampiezze. La disposizione dei gate $G(\omega_k)$ nel circuito e la scelta degli assi di rotazione rappresentano le caratteristiche topologiche del modello. Gli angoli di rotazione $\omega_k$ costituiscono invece l’insieme dei parametri del modello.

La misura del qubit $q_1$ può restituire solo due valori: 0 e 1; per calcolare la funzione di classificazione del vettore $x$ definita come

è necessario stimare la $\Pr(q_1=0)$ reiterando la misura del qubit $q_1$ più volte, a parità di $x$ e $\omega$, e calcolando la frequenza con cui viene ottenuto il valore 0.

Come per le reti neurali, l’individuazione dei parametri ottimali viene effettuata attraverso l’algoritmo di discesa del gradiente.

L’architettura adottata per l’addestramento di un Variational Classifer è di tipo ibrido e prevede una suddivisione dei ruoli fra unità di calcolo quantistico (QPU) e classico (CPU). La componente quantistica del calcolo è realizzata dai circuiti del modello di cui sopra e viene attivata dalla CPU che fornisce sia il vettore normalizzato delle caratteristiche $x$ che i parametri del modello $\omega$ e $\nu$ da utilizzare. La QPU fornisce in output le misure rilevate al termine della computazione che vengono utilizzate dalla CPU per confrontarle con il risultato corretto $y$ fornito dall’esempio $(x, y)$ e determinare la variazione da apportare ai parametri del modello nel giro successivo. Fissata una opportuna funzione di errore che valuti la distanza fra le previsioni del modello e gli esempi forniti, l’algoritmo di discesa sul gradiente individua la correzione da apportare ai parametri per far convergere il modello verso una configurazione sub-ottimale (ottimo locale).

L’adozione di un’architettura ibrida come quella mostrata è oggi la soluzione di riferimento per l’applicazione di modelli di computazione quantistica in contesti reali. L’astrazione di una QPU e una CPU che interagiscono va traslata in un’architettura in cui le risorse di calcolo quantistico sono disponibili sotto forma di servizi in cloud attivati e integrati all’interno di algoritmi implementati con architetture di calcolo di tipo classico in cloud o on-premises.

Fra il 2016 e il 2018 il tema della disponibilità di processori quantistici comincia a rimbalzare fra la stampa specialistica e quella generalista; vengono anche resi disponibili in cloud i primi servizi di calcolo quantistico ad uso di enti di ricerca o semplici curiosi. Solo nei primi giorni del 2019, con l’annuncio di IBM al CES del primo computer quantistico universale per uso commerciale (IBM System Q One), mi rendo veramente conto che si tratta di una innovazione che avrà un impatto dirompente già sulla mia generazione (e che non riuscirò ad andare in pensione senza esserne coinvolto).

Nell’estate del 2019, complice il tempo libero della pausa estiva, comincio a studiare i primi rudimenti di computazione quantistica nella splendida cornice del mare di Mallorca. Mi procuro la versione per Kindle di un testo introduttivo (Quantum Computing for Everyone di Chris Bernhardt pubblicato dalla MIT Press) la cui chiarezza e semplicità della trattazione mi aiutano indubbiamente ad appassionarmi alla materia. Le reminiscenze dei corsi universitari di algebra e qualche supporto di Wikipedia & co. mi consentono di andare spedito fra Bell, Deutsch–Jozsa e Grover.

Il primo testo aveva alimentato la curiosità e l’urgenza di mettere in pratica l’elegante impostazione teorica dell’interpretazione di Copenaghen. Così il secondo testo (sempre divorato durante le ferie) lo scelgo con un taglio più vicino alla mia anima da sviluppatore: Programming Quantum Computers - Essential Algorithms and Code Samples della O’Reilly. Il libro cavalca il modello di un’architettura di calcolo tradizionale dotata di un’unità di calcolo quantistico (QPU), in analogia a quanto viene fatto con le GPU (co-processore grafico) per accelerare le prestazioni grafiche di PC e smartphone. In questo scenario la QPU abilita un modello di computazione ibrida in cui alcune parti dell’algoritmo sono eseguite con un modello classico e altre sfruttando le potenzialità del calcolo quantistico. Oggi un processore quantistico richiede strutture grandi come una stanza per funzionare, ma il modello di computazione ibrida può essere adattato sostituendo la QPU con servizi di computazione quantistica disponibili in cloud.

Tornato dalle ferie, nei ritagli di tempo libero, comincio a studiare il linguaggio ideato da Microsoft specificamente per la programmazione quantistica (Q#) e affianco alla scrittura di codice la simulazione matematica degli stessi algoritmi con Octave e Maxima (versioni open-source alternative a tool come Matlab e Mathematica) per mantenere il parallelismo fra la componente teorica e lo sviluppo di codice che ha caratterizzato le letture estive.

Comincio anche a leggere articoli scientifici reperibili principalmente in forma integrale su arXiv e a fruire di alcuni corsi su piattaforme MOOC come EDX e Coursera, fra cui il corso di Introduction to Quantum Computing organizzato dalla Saint Petersburg State University. In questo periodo l’attenzione è rivolta a colmare il gap fra i fondamenti della computazione quantistica e le applicazioni a problemi del mondo reale. Ad oggi i tre filoni più evidenti di applicazione sono legati allo studio della materia (quindi con applicazioni dirette al campo della chimica e della scienza dei materiali), ai problemi di ottimizzazione e al machine learning. Il background di competenze acquisite negli anni precedenti mi ha naturalmente spinto verso quest’ultimo ambito di applicazione.

Indirizzato da diversi articoli scientifici sul tema fra cui Circuit-centric quantum classifiers, Practical optimization for hybrid quantum-classical algorithms e Hierarchical quantum classifiers, ho selezionato il terzo libro (sempre da consumare nella pausa estiva) che mi sento di consigliare: Supervised Learning with Quantum Computers di Maria Schuld e altri pubblicato da Springer. Gli articoli citati e alcuni capitoli del libro descrivono diversi approcci per realizzare dei classificatori (modelli di classificazione automatica addestrati attraverso degli esempi) ottenuti combinando algoritmi di tipo classico come la discesa del gradiente con il calcolo di modelli predittivi e derivate parziali eseguito con circuiti quantistici.

A questo punto l’attenzione torna sulla componente sperimentale del percorso, così realizzo la mia versione di un Variational Quantum Classifier implementato in Python sfruttando tre “motori” di calcolo interscambiabili: un simulatore numerico basato su routine di algebra lineare, uno basato sul linguaggio Q# di Microsoft e uno su QISKIT, il SDK curato da IBM per accedere ai servizi di Quantum Computing in Cloud. Il progetto ha il duplice scopo di:

• Provare sul campo (intendo su dati reali) un modello di machine learning realizzato con circuiti quantistici (utilizzando uno specifico unitary gate diverso da quelli proposti in letteratura, che riduce complessità e effort computazionale)
• Consentire il confronto in termini di accuratezza e prestazioni fra diversi modelli di simulazione numerica e servizi basati su implementazioni fisiche di processori quantistici (come quelli resi di disponibili da IBM e Microsoft)

Per chi fosse interessato, ho pubblicato il codice sorgente su GitHub: caccio/CrossQuantumClassifier.

Il primo lockdown a marzo è stato stressante: non ha lasciato molto tempo libero per attività extra-lavorative e ha inibito anche la convivialità ordinaria che consente di scambiare idee ed esperienze con amici e colleghi.

Il secondo è arrivato a ridosso delle feste natalizie, portando con se il presagio di ulteriori limitazioni anche per il nuovo anno. Stavolta però ha trovato la consapevolezza degli effetti nefasti dell’isolamento e un maggior tempo libero per incanalare le energie verso un canale di comunicazione in cui raccogliere idee da mettere alla prova (prima di tutto a quella di una loro espressione compiuta che è il primo test per discernere fra contenuti ben posti e autosuggestione).

In quest’ultimo periodo mi sto interessando, fra le altre cose, di computazione quantistica e quindi ho aggiunto una nuova sezione del blog dedicata a questo argomento. Stavo valutando anche l’apertura di un nuovo spazio dedicato (magari su medium, magari in lingua inglese) da dedicare all’argomento, ma al momento sono più interessato a raccogliere qui appunti e riflessioni che magari rielaborerò in seguito. Intanto ho adottato un nuovo tema, più minimalista e focalizzato sui contenuti.

Buona lettura e buon anno!